WO2001013299A2

WO2001013299A2 - Online reservation system and method

Info

Publication number: WO2001013299A2
Application number: PCT/US2000/021949
Authority: WO
Inventors: Hong-Minh Pho
Original assignee: Travel Services International, Inc.
Priority date: 1999-08-12
Filing date: 2000-08-10
Publication date: 2001-02-22
Also published as: WO2001013299A3; AU7056900A; WO2001013299A8

Abstract

An advanced online reservation system that provides many of the services a traveler would expect from a travel agent is described. The online reservation system constructs a fare ladder (i.e. a listing of fares corresponding to the traveler's requested itinerary) that shows available fares, that is, fares for which seats are still available. The fare ladder can include fares listed by selected airlines, and special contract fares. The online reservation system translates Computerized Reservation System (CRS) codes used by professional travel agents into language that is more easily understood by a typical traveler. The online reservation system also checks rules associated with available, discounted, and/or negotiated fares to produce a list of qualified fares. The traveler can choose to view qualified or non-qualified fares.

Description

ONLINE RESERVATION SYSTEM AND METHOD Field of the Invention This invention relates generally to online reservation and ticketing systems, and, more particularly, to Internet- based airline reservation and ticketing systems. Background of the Invention

Online reservation systems, such as systems that allow travelers to use the Internet to make airline reservations, are fast, convenient, and cost-effective. These online systems allow the user (i.e., a traveler or agent) to avoid the inconvenience of calling several airlines in order to find the best price or best itinerary. Moreover, the online systems are available twenty-four hours a day, allowing the user to book reservations even when traditional travel agencies are closed. Unfortunately, online systems to date are typically little more than primitive computerized versions of the airline published fare listings. For example, most airlines provide a limited number of "bargain" seats on each flight. These bargain seats are subject to certain rules and restrictions. Once the limited number of bargain seats for a given flight are sold out, a traveler must purchase a more expensive seat. Nevertheless, current online reservation systems will continue to list the bargain seats even when none remain available. This confuses travelers and complicates the process of finding an available flight for a listed fare.

Summary of the Invention The invention solves these and other problems by providing an advanced online reservation system that provides many of the services expected from a travel agent. In one embodiment, the online reservation system shows those fares that are not already sold-out. This greatly benefits the user by allowing the user to make an informed choice, based on reasonably current information regarding the seats that are still available.

In one embodiment, the list of fares presented to the user also includes special contract fares (net fares) available from a Travel Service Provider (TSP). These net fares are usually specially discounted fares negotiated between the carrier and the TSP based on contracts between the carrier and the TSP. These net fares are typically not listed in the publicly available list of published fares provided by the carrier. Access to the net fares is a special benefit conferred on those users using the online service to select flights and book tickets. Thus, access to the net fares benefits both the traveler and the TSP operating the online reservation system. A wise traveler will continue to use the online reservation system due to the possibility of obtaining the benefit of one of the net fares.

In one embodiment, the online reservation system qualifies the net fares. That is, the online reservation system checks the net fares against the contract rules that regulate the net fares to obtain those net fares that qualify under the rules of the contract. Then the online reservation system removes the fares that do not qualify from the list of fares presented to the user. In one embodiment, the online reservation system constructs an integrated fare ladder, the integrated fare ladder being a combined list of qualified net fares and a list of available published fares. The traveler, knowing that the listed fares are available, can make an informed choice of a desired flight based on price and flight times.

In one embodiment, the online reservation system translates Computerized Reservation System (CRS) codes used by experienced professional travel agents into language that is more easily understood by a typical user.

In one embodiment, the online reservation system allows the user to obtain delivery of tickets by electronic transmission (e-tickets) or conventional shipping (paper tickets). In one embodiment, the online reservation system allows the user to specify a seat preference (e.g. isle, window, etc.). In one embodiment the online reservation system allow the user to specify a meal preference. In one embodiment, the online reservation system checks rules associated with available, discounted, and/or negotiated fares. Typical rules include minimum length of stay, Saturday-night stay, advance purchase, etc. The rules are used to produce a list of qualified flights, that is, flights for which the traveler's itinerary qualifies. The user can choose to view qualified or non qualified fares.

In one embodiment, the online reservation system helps the user search for low-cost fares by providing fares for itineraries that are similar to the itinerary requested by the traveler, such as itineraries for airports near the airports selected by the traveler, itineraries for dates near the dates selected by the traveler, etc.

In one embodiment, the online reservation system obtains information regarding contract fares from a net fares database. In one embodiment, the online reservation system obtains fare information by issuing multiple parallel requests to a computerized reservation system. In one embodiment, the online reservation system is used by travel sales agents working for a travel agency and selling tickets to customers.

Brief Description of the Drawings The above and other aspects, features, and advantages of the present invention will be more apparent from the following description thereof presented in connection with the following drawings.

Figure 1 is an overview of an Internet-based airline ticketing system, showing interactions between a user, the Internet, the booking engine, customer service, and ticket fulfillment.

Figure 2A is a flowchart showing a general overview of the booking and ticketing process including the step of building a fare ladder.

Figure 2B is a flowchart showing a more detailed view of the elements of building a fare ladder. Figure 3, consisting of Figures 3A and 3B, is a flowchart of the process of building a fare ladder from various electronic databases and processing the fares to obtain available and/or qualified fares.

Figure 4 is a flowchart showing screen transitions used in accessing the online reservation system to purchase tickets.

Figure 5 illustrates a user-login screen.

Figure 6 illustrates a new-member profile screen. Figure 7A illustrates a flight-search screen wherein a user enters a desired travel itinerary.

Figure 7B illustrates the flight-search screen from Figure 7A, wherein the booking engine has provided a drop-down dialog box for selecting a desired airport for a city served by multiple airports.

Figure 8 illustrates a fare-ladder screen showing available fares and prices corresponding to the itinerary entered by the user.

Figure 9, consisting of Figures 9A and 9B, illustrates a booking-tickets screen.

Figure 10, consisting of Figures 10A and 10B, illustrates a booking-confirmation screen.

Figure 11 is a block diagram showing an application architecture for the online booking system.

Figure 12 is a block diagram showing application call flow in the online booking system. Figure 13 is an object interaction flow diagram showing object flows for a user query.

Figure 14 is an object interaction flow diagram showing object flows for a fare ladder query.

Figure 15 is an object interaction flow diagram showing object flows for creating itineraries.

Figure 16 is an object interaction flow diagram showing object flows for pricing a PNR.

Figure 17 is an object interaction flow diagram showing object flows for booking. Figure 18 is a screen flow hierarchy for a fare management system used to maintain a contract fare database showing a first-level screen and its first sub-level.

Figure 19 is a screen flow hierarchy for a fare management system used to maintain a contract fare database showing a maintain-contract screen and its first sub-level.

Figure 20 is a screen flow hierarchy for a fare management system used to maintain a contract fare database showing a view-zones screen and its first sub-level.

Figure 21 is a screen flow hierarchy for a fare management system used to maintain a contract fare database showing a view-matrices screen and its first sub-level.

Figure 22 shows a query screen for use by a travel sales agent as part of an advanced user interface.

Figure 23 shows a rules view of an integrated fare ladder screen for use by a travel sales agent as part of an advanced user interface.

Figure 24 shows a time view of an integrated fare ladder screen for use by a travel sales agent as part of an advanced user interface.

Figure 25 shows a discount details screen for use by a travel sales agent as part of an advanced user interface. Figure 26 shows an unrestricted availability screen for use by a travel sales agent as part of an advanced user interface.

Figure 27 shows a pricing screen for use by a travel sales agent as part of an advanced user interface.

Figure 28 shows a more net fares screen for use by a travel sales agent as part of an advanced user interface. Figure 29 shows a "more published fares" (best 3) screen for use by a travel sales agent as part of an advanced user interface.

Figure 30 shows a flexing screen for use by a travel sales agent as part of an advanced user interface.

Figure 31 shows a booking screen for use by a travel sales agent as part of an advanced user interface. Figure 32 illustrates an alternate embodiment of the user-login screen shown in Figure 5.

Figure 33, consisting of Figures 33A and 33B, illustrates an alternate embodiment of the new-member profile screen shown in Figure 6.

Figure 34A illustrates an alternate embodiment of the flight-search screen wherein a user enters a desired travel itinerary, as shown in Figure 7A. Figure 34B illustrates the flight-search screen from Figure 34A, wherein the booking engine has provided a drop-down dialog box for selecting a desired airport for a city served by multiple airports.

Figure 35, consisting of Figures 35A, 35B and 35C, illustrates an alternate embodiment of the fare-ladder screen, shown in Figure 8, showing available fares and prices corresponding to the itinerary entered by the user.

Figure 36, consisting of Figures 36A, 36B, and 36C, illustrates an alternate embodiment of the booking- tickets screen shown in Figure 9.

Figure 37 shows an alternate embodiment of the query screen for use by a travel sales agent as part of an advanced user interface shown in Figure 22.

Figure 38 shows an alternate embodiment of the rules view of an integrated fare ladder screen, as shown in Figure 23, for use by a travel sales agent as part of an advanced user interface. Figure 39 shows an alternate embodiment of the time view of an integrated fare ladder screen shown in

Figure 24, for use by a travel sales agent as part of an advanced user interface.

Figure 40, consisting of Figures 40A and 40B, shows an alternate embodiment of a flight selection screen for use by a travel sales agent as part of an advanced user interface.

Figure 41, consisting of Figures 41A, 41 B, and 41 C, shows an alternate embodiment of the booking screen, as shown in Figure 31, for use by a travel sales agent as part of an advanced user interface.

In the drawings, the first digit of any three-digit element reference number generally indicates the number of the figure in which the referenced element first appears. The first two digits of any four-digit element reference number generally indicate the figure in which the referenced element first appears.

Detailed Description Figure 1 is a overview illustrating the basic element of an online reservation and ticketing system 107 that can be used, for example, to purchase airline tickets. As shown, a user 100 uses a computer 102 to communicate through the Internet 104 to a booking engine 106. The booking engine 106 allows the user 100 to enter an itinerary, view a list of airline flights, and select a desired flight. The system 107 can also be used by professional travel sales agents. The booking engine 106 communicates with a fulfillment system 112. The fulfillment system 1 12 provides tickets to the user 100 either as paper tickets (via mail. Federal Express, etc.) or electronic tickets (via email). The fulfillment system 112 also provides email confirmation of the booking to the user 100. The user 100 also uses the Internet 104 to communicate (e.g. via email) to a customer service system 110. The customer service system 110 provides email back to the user 100 and optionally telephone service to the user 100. An online reservation system 107 includes the booking engine 106 combined with the fulfillment system 112.

The booking engine 106 constructs an integrated fare ladder in one embodiment, the integrated fare ladder being a combined list of available published fares and qualified net fares (from a list of unqualified net fares). As described in more detail below, the available fares are those published fares that are not currently sold out. Qualified net fares are special (usually unpublished) fares that are provided under contracts between the air carriers and the Travel Service Provider (TSP) that operates the online reservation system. In some instances, the qualified net fares are so special (e.g. so deeply discounted) that the TSP is not allowed to disclose the name of the carrier until the user 100 has purchased the tickets. The integrated fare ladder significantly improves the ability of the user 100 to choose a desirable final itinerary and price because the user 100 will not be confused by seeing flights that are already sold-out, and the user 100 will have access to the qualified net fares. As discussed above, net fares are special contract fares negotiated between the carrier and the TSP. Access to the net fares is a special benefit conferred on those users using the online service to select flights and book tickets. The booking engine 106 qualifies the net fares by checking the net fares against the contract rules that regulate the net fares to obtain those net fares that qualify under the rules of the contract. The online reservation system removes the fares that do not qualify from the list of fares presented to the user. The booking engine 106 also translates Computerized Reservation System (CRS) codes used by professional travel agents into language that is more easily understood by a typical user.

In one embodiment, the booking engine 106 also helps the user search for low-cost fares by providing fares for itineraries that are similar to the itinerary requested by the user, such as itineraries for airports near the airports selected by the user, itineraries for dates near the dates selected by the user, etc. In one embodiment, the booking engine 106 displays fares from airports that are located within an area defined by a specified distance from the airport requested by the user 100. In one embodiment, the booking engine 106 displays fares for travel times within a specified time (e.g. a specified number of days) from the time requested by the user 100.

The fulfillment system 1 12 provides an email (e.g. SMTP) confirmation for successful ticket pre-purchases. The term pre-purchase is herein defined as creation of a Passenger Name Record (PNR). A PNR is a record on a CRS that contains information related to a specific booking, in other words, a booking record. (A sample PNR is given in

Appendix A.) The confirmation email provides an immediate automated response feature to PNR creation, and it reduces customer service calls for lost confirmation information.

Figure 2A is a flowchart illustrating the basic steps used in connection with the elements show in Figure 1 to book an airline flight. Figure 2A begins in a process block 202 wherein the user 100 logs into the online reservation system 107. Once the user 100 is logged in, the process advances to a process block 204 where the user 100 enters an itinerary. Once the itinerary has been entered, the process advances to a process block 206 where the booking engine 106 builds a fare ladder using data from one or more databases and one or more computerized reservation systems. Once the fare ladder has been built, the process advances to a process block 210 where the fares are displayed for the user 100. Once the fares are displayed, the process advances to a process block 212 where the user selects a desired fare, whereupon the process advances to a process block 214. Alternatively, the user can reject the fares listed on the fare ladder 212 and cause the process to return to the itinerary process block 204.

Figure 2B is a flowchart showing additional details of building the integrated fare ladder in the process block 206. Construction of the integrated fare ladder includes obtaining a list of fares from one or more computerized reservation systems, determining which fares are available, qualifying the available fares, and calculating a final fare price. The final fare price includes available discounts that the travel agent or online booking system is able, or willing, to provide to the user 100. The final fare price also includes applicable taxes, service fees, etc.

In the process block 214, the user's credit card and other information is used to purchase tickets corresponding to the fare selected by the user 100. The flight reservation corresponding to the purchased tickets is booked as a PNR in a computerized reservation system (see e.g. Appendix A). Tickets are purchased for a party, typically including the user 100, one or more adults, and/or one or more children. The user 100 can also enter information such as the names of other people in the party, seat preferences (e.g., isle, window, etc.) for each person in the party, and meal preferences for each person in the party.

Once tickets have been purchased, the process advances to a process block 216 where the tickets are delivered to the user 100 either as an electronic ticket or actual paper tickets (delivered by mail or other carrier). Figure 3 is a flowchart showing details of the get-fare process block 206 shown in Figures 2A and 2B. As shown in Figure 3, the itinerary is provided to a first retrieve block 302 and a second retrieve block 318. The first retrieve block 302 obtains a primary list of net fares from a net fare database 304. The primary list of net fares includes fares that correspond to the itinerary. The primary list of net fares is provided to a get-available-itineraries block 306. The get-available-itineraries block 306 issues one or more parallel requests to a first computer reservation system (CRS) 308. Data from the first CRS system 308 is used to determine which fares in the primary list of net fares are still available and construct a list of available net fares. Available net fares include those fares for which seats are still available. By accessing the first CRS 308, the get-available-itiπeraries block 306 builds the list of available fares based on current data from the first CRS 308.

The list of available net fares is provided to a check-rules block 310. The check-rules block 310 checks the fares in the list of available net fares and culls those fares that violate terms of the net fare contracts (see e.g., the text in connection with figures 18-2). A contract can include, for example, routing rules, flight number (or flight sequences numbers, e.g., sequences that specify groups of flights by a range of flight numbers) rules, series rules, advance purchase rules, minimum stay rules, overnight-Saturday rules, etc. Results from the check-rules block 310 are provided to a prepare-list block 312. The prepare-list block 312 generates a list of qualified net fares, that is, net fares that qualify under the contract rules. The list of qualified net fares is provided to a merge block 314. In one embodiment, rules that do not depend on particular routes or flight number are applied before flight availability is checked and rules that do depend on particular routes or flight numbers are checked after flight availability is checked. For example, rules regarding advance booking, minimum stay, overnight-Saturday stay, and the like, can be applied and used to eliminate certain flights without reference to a particular fight number or route. Thus, such rules can conveniently be applied before checking flight availability. Whereas, rules relating to specific routes or flight numbers are conveniently applied after checking for flight availability.

Returning to the second retrieve block 318, the retrieve block 318 retrieves a list of preferred carriers (e.g. airline carriers) from the preferred carrier database 322. The list of preferred carriers is provided to a get-validated- fares block 320. The get-validated-fares block 320 obtains a list of the lowest available and available (validated) published fares for the preferred carriers from a second CRS 324. The first CRS 308 and the second CRS 234 can be the same system or systems. For example, in one embodiment, the first CRS 308 system includes the Amadeus and Sabre GDS systems, and the second CRS system 324 includes the Sabre GDS system. The process block 320 issues one or more requests to the CRS system 324. In one embodiment, one or more of the requests issued by the process block 320 to the CRS system 324 are issued in parallel in order to speed-up the process of generating the validated fares list.

The list of validated fares obtained in the process block 320 is provided to an apply-discount block 326. The apply-discount block 326 obtains fare discount data from a discounted fare database 330 and applies available discounts to the fares in the provided list of validated fares. Typically, not all of the validated fares are discountable, but those that are, are discounted. The discounted fares and fares for which no discount is available, are provided to a build-list block 328, which builds a list of discounted-available fares (the discounted-available fares list contains both the discountable and undiscountable fares). The list of discounted-available fares is provided to the merge block 314.

The merge block 314 merges the list of discounted-available fares from the process block 314 and the list of qualified net fares from the process block 328 into a merged list of fares. The merged list of fares is sorted by price to produce a sorted list. The sorted list is provided to a yield block 316. The yield block 316 adjusts the fares in the sorted list as desired to produce a list of adjusted fares. The list of adjusted fares is provided to the display block 210 and there displayed as a fare ladder (as shown in Figure 8).

Net, discounted, and published fares can be included in the creation of the fare ladder. The fares include estimated tax calculations. In one embodiment, fare requests are allowed to occur a minimum of five calendar days from the date of travel. In one embodiment, fare requests are allowed for travel the following day. Only available fares and flights are listed in the fare ladder. "Blending" rules allow for open jaw fares created through city blending rules.

The process shown in Figure 3 includes the following acts:

1. A browser in the computer 102 sends a request to an Active Server Page (ASP) with date, origin, and destination information (the process block 204 sends itinerary information to the process block 206). 2. Get preferred carriers from the database 322. The preferred carriers, in some cases, have agreed to provide a specific discount to their published fares as applied in the process block 326 using discounts defined in the database 330. The preferred carriers are listed in a ranked list of discount carriers (process block 318). 3. Get negotiated (net) fares. The net fares are special fares that have been arranged (contracted) with the carrier and are usually not listed in a CRS database. The net fares are subject to availability and contract rules arranged between the carrier and the online reservation system 107. (Process block 302). 4. Make calls to the CRS for fares. The number of preferred carriers returned in Step 2 and an application- level configurable flag typically determine the number of calls to make. In addition, a global flag determines whether an additional unrestricted (no carrier specified, best fare for that market) call is made. The system also makes "Availability" calls to Amadeus to find information on flight availability for the net fares returned in Step 2. The number of these calls to make is determined by an application- level configurable flag. (Process block 308). 5. Take published fares that came from Sabre, determine if any discounts from the database 330 should be applied, and apply the applicable discounts stored in the database 330. (Process block 326). In one embodiment, contract information data (either as a net fare contract or a discount contract) is stored in the net fares database 304 and the discount fares database 330. Contract information data includes, for example, the data listed in Table 1 below. In one embodiment, the contract information is entered and maintained using a graphical interface as described in connection with the screen flow diagrams in Figures 18-21.

Authoring Airline

Contact Type-Net or Discount

Minimum and Maximum days to book before departure

Ticket and wait intervals

Number of children and infants per adult

Contract Effective and End Dates

Sharing and Frequent Flier Airlines

Open Jaw, Advance Seat and Name Change restrictions

Booking CRS

Fare Basis for Routing

Outbound and Return Blackout Days

Fees for Cancellation, Changes, Day of Week Travel, Stopovers, Open Jaws

Entry of airport and city code that indicate a zone that defines Outbound and Destination Pairs

Definition of Seasoπality

Blackout Dates

Rule text to display to a use (i.e. a traveler and/or TSP personnel)

Class of Service

Passenger and Trip Types

Minimum stay. Maximum stay, and Travel Complete-by Dates

Flight and Routing Rules

Negotiated Fares for a specified From-Zoπe, To-Zone, and Season

Discount Range and Amount of Discount for a specified From-Zone, To-Zone, and Season

Table 1.

In Table 1., a fare basis includes an identification code (ID) in a CRS for the fare. Fare Types include net fares, commission-override fares, published fares, and the like. A zone is typically a grouping of cities or airports.

The check-rules block 310 uses the contract "rules" listed in Table 1 and checks the available fares provided by the get-fares block 306 to determine which of the available fares meet the contract rules for that fare. Those fares that meet the contract terms are considered to be "qualified" fares, that is, fares that the user 100 is qualified to purchase. Similarly, the apply-discounts block 330 uses the contract "rules" listed in Table 1. and checks the available fares provided by the get-available block 324 to determine if any discounts can be applied. Those fares that meet the contract rules can be discounted, as allowed by the contract. Note that the TSP can choose to apply some, all, or none of the allowable discount.

The process of Figure 3 is illustrated by the following hypothetical example: consider a traveler wishing to fly from Los Angeles (LAX) to New York City (NYC) on July 12, 2000 (a Wednesday) and returning on July 14, 2000 (a Friday). Further, assume the traveler is booking the flight on July 10, 2000. (Note: Travel times have been eliminated from the present example in order to simplify the presentation. One of ordinary skill in the art will understand that typically, a traveler will also specify a range of desired departure and arrival times). The following net fares are returned from the net fares database 304 (in the step 302):

1. Airline A $500 net (requires overnight Saturday stay )

2. Airline A $550 net (requires seven-day advance booking)

3. Airline A $650 net (no restrictions)

4. Airline B $600 net (no restrictions)

In the step 306, the above net fares are checked for availability. Assume that the flights on Airline B are sold out for July 12 and 14, but that all of the flights on Airline A are available, thus, the result of step 306 is the following list.

1. Airline A $500 available net (overnight Saturday stay )

2. Airline A $550 available net (seven-day advance booking)

3. Airline A $650 available net (no restrictions) In the step 310, the flights 1 and 2 above are eliminated because they violate the contract rules (flight 1 is eliminated because the traveler is not staying over a Saturday night, and flight 2 is eliminated because the traveler is not booking at least seven days in advance. Thus, the only available net fare flight that qualifies under the contract rules is flight 3 above.

1. Airline A $650 qualified available net In the step 318, a list of preferred carriers is retrieved from the preferred carrier database. For the present example, assume that carriers A, B, and C are preferred carriers between NYC and LAX. The list of preferred carriers is provided to the step 320 to retrieve the available published fares for the above hypothetical itinerary. Assume the following published fares are available (not sold out):

1. Airline A $800 available published 2. Airline B $850 available published

3. Airline C $850 available published

4. Airline D $1050 available published

The above list of available published fares is provided to step 326 to apply possible discounts. Assume for example, that the travel service provider has negotiated a 10% discount on all flights on airline C. Then the 10% discount is provided in step 326 to generate the following list of discounted available published fares:

1. Airline A $800 discounted available published

2. Airline B $850 discounted available published

3. Airline C $765 discounted available published (10% discount)

4. Airline D $1050 available published The lists from step 312 and step 328 are combined and sorted in step 314 to produce the following list of fares for the fare ladder:

1. Airline A $650 qualified available net

2. Airline C $765 discounted available published (10% discount)

3. Airline A $800 discounted available published 4. Airline B $850 discounted available published

5. Airline D $1050 available published

Figure 4 is a block diagram showing the screen flow in one embodiment of a user interface provided by the booking engine 106. The user interface is provided to allow the user 100 to navigate through the ticketing process shown in Figure 2. The first screen seen by the user 100 is a user-login screen 402. If the user 100 is a new user of the system 107, then the screen flow advances from the user-login 402 to a user-profile screen 412; otherwise, screen flow advances from the user-login screen 402 to a flight-search screen 406. In the user-profile screen 412, the user 100 enters certain personal information such as name, email address, etc. Screen flow then advances from the user-profile screen 412 to the flight-search screen 406. In the flight-search screen 406, the user 100 enters itinerary information and the screen flow then advances to a fare-ladder screen 408 where the fare ladder (generated as described in connection with Figure 3) is displayed. If the user 100 selects a fare displayed in the fare-ladder screen 408, then screen flow advances to a booking-tickets screen 414; otherwise, screen flow returns to the flight-search screen 406. From the booking-tickets screen 414, if the user 100 selects to buy a ticket, then screen flow advances to the booking-confirmation screen 418; otherwise, screen flow returns to either the fare-latter screen 408 or the flight-search screen 406.

The screen flow diagram shown in Figure 4 is representative of the normal flow used by the user 100 to select and book tickets. As shown in Figures 5-10 (listing the various screens) the user can also return to the user- profile screen 412 at almost any time. The user 100 can also transition to a help screen from most of the available screens. In addition, the user 100 can use the "forward" and "back" buttons provided on most Web browsers to alter the screen flow.

The user interface described by the screen flow diagram shown in Figure 4 provides:

• A user profile configured to provide a storage vehicle to maintain profile information about the user 100 and allow only registered users access the online system 107.

• A front-end interface that masks complex fare and flight search requests to the CRS and other databases. • A vehicle to expedite the placement of a travel booking.

■ A vehicle to produce, as a function of booking, a standard PNR.

• Confirmation to the user 100 as to the details of the booking.

• A tool for the user 100 to receive confirmation that he/she has placed a valid booking. This creates an emailed duplicate to the confirmation page. In one embodiment, the user interface and front-end functionality is based on an HTML model using active server pages (ASP). Some data, such as a saved member-ID and password, are stored on the computer 102 using cookies.

Figure 5 illustrates one embodiment of the user-login screen 402. The user-login screen 402 includes a new- member button 502, a member-ID field 504, a password field 506, a save-password checkbox 508, and an enter button 510. If the user 100 is a new user, then the user 100 clicks the new-member button 502 to transition to the user-profile screen 412. If the user 100 is an existing member then the user 100 enters his/her member-ID into the member-ID field 504 and his/her password into the password field 506. If desired, the user can click the save- password check box 508 to cause the password and member ID to be saved on the user's computer 102 for future use. After entering the member-ID and password 506 into the appropriate fields, the user 100 clicks the enter button 510 to transition to the flight-search screen 406.

The profile screen 412, shown in Figure 6, includes a first-name field 602, a middle-initial field 603 (optional), a last-name field 604, an email-address field 605, a street-address field 606 (and optionally 607), a city field 68, a state drop-down listbox 609, a ZIP code field 610, a country drop down listbox 611, and a telephone- number field 612. The user 100 enters the proper information in the fields 602-612. One embodiment includes a "forgotten-password" feature to allow a user who has forgotten his or her password to login. In the forgotten-password feature, the user 100 defines a user-defined question and a corresponding user-defined answer. If the user 100 forgets the password, then the user invokes the forgotten- password feature. The forgotten-password feature asks the user with the user-defined question. The user 100 answers with his or her correct email address, first and last names, and the answer to the user-defined question. If the email, first and last names, and answer to the user-defined question are correct, then the system sends the password to the user 100 via email.

One or more airline fields such as an airline field 624, in combination with one or more frequent-flier number fields such as a flier-number field 626, allow the user 100 to enter frequent-flier numbers for various airlines.

The user-profile screen 412 also includes a user-name field 630, a password field 631, and a password- confirmation field 632 to allow the user 100 to enter a user-name and a password. The save user name and password check box 640 allows the user to indicate that the user-name and password are to be saved on the user's computer 102 for future use. An information-request checkbox 642 allows the user 100 to request information about travel specials and services via the email address entered in the email-address field 605. A terms-assent checkbox 644 is clicked by the user 100 to indicate that the user 100 agrees to terms and conditions of membership. In one embodiment, the email-address field 605, user-name field 630, and the^' password fields 631-631 are the only fields that must be entered by the user 100.

Figure 7 shows the flight-query screen 406, which includes a new-search button 702, an edit-profile button 704, and a get-help button 706. The new-search button 702 resets and clears the fields of the flight-search screen 406. The edit-profile button 704 returns the user 100 to the user-profile screen 412. The get-help button 706 sends the user 100 to a help screen.

The flight-search screen 406 includes an outbound leaviπg-from field 710, an outbound going-to field 71 1, an outbound departing-date field 712, an outbound departing-day field 713 and an outbound departing-time field 714. The screen 406 also includes an inbound leaving-from field 722, an inbound going-to field 724, an inbound departing date field 723, an inbound departing-time field 728, and an inbound departing-day field 726. In fields 710-714 the user 100 enters itinerary information about the outbound leg of the trip. In the fields 720-724 the user 100 enters itinerary information about the inbound (return) leg of the trip. The fields 720-724 can be left blank for a one-way trip. An adult-count field 730 and a children-count field 732 are provided to allow the user 100 to specify the number of adults and children, respectively, in the party. An airline-preference listbox 734 is provided to allow the user 100 to select one or more preferred airlines. The flight search page 406 allows the user 100 to select between two search options. The first search option, indicated by a button 736, allows the user 100 to search for flights based on lowest available fares for the dates and times specified in the fields 710-714 and 720-724. Alternatively in one embodiment, the second search option, indicated by a button 738 allows the user 100 to search for flight based solely on the itinerary specified in the fields 710-714 and 710-724 without respect to price. A continue-search button 740 allows the user 100 to advance to the fare-ladder screen 408. A cancel button 742 is provided to allow the user 100 to cancel the flight-search screen 4076. A group of calendar fields 750 shows monthly calendars for the current month and several months following. A view-year button 752 allows the travel 100 to view a 12-month calendar.

Figure 7B shows the flight-search screen 406 described in Figure 7A with the addition of a dropdown listbox 715 attached to the outbound going-to field 711. The listbox 715 is typically provided when the user 100 enters the name of a city that has several airports when the user has misspelled the city name. For example as shown in Figure 7B, if the user enters Phoenix, then the drop-down box 715 list three airports in the Phoenix area. Similar drop-down boxes are provided for the fields 710, and 720-721 as need.

Figure 8 shows the fare-ladder screen showing a first (e.g., lowest, or closest to itinerary) fare-option group 802 and a second lowest fare-option group 803. For each fare the fare-ladder screen 408 shows a price, a departure time and an arrival time. For each fare the fare-ladder screen also shows either an airline (and flight number), or an indication that the fare is a special negotiated fare (e.g., "special rate", "special fare", "major US carrier", etc.). Fares are listed as special, without listing an airline, in situations where the special rate contract prohibits listing the airline). The type of aircraft is also shown. The above fields are provided for both the outbound leg and the inbound (return) leg of the trip. The first fare-option group 802 provides a buy-tickets button 804. The second fare-option group 803 provides a buy-tickets button 854. The fare ladder shown in Figure 8 shows two possible itineraries, however, had more flights been available, then more itineraries would be listed. In one embodiment, a selected number (i.e., the first 10) itineraries are listed. In one embodiment, all available itineraries are listed. Figure 9 shows the booking-tickets screen 414, which includes the new-search button 702, the edit-profile button 704 and the get-help button 706. In one embodiment, an optional change-search button is also provided to allow the user to change to a new search strategy. The booking-tickets screen 414 also shows a total-price field 902, and a price-breakdown group 904. The price-breakdown group 904 includes the type of ticket, a fare, taxes, and quantity for each ticket. The booking-tickets field 414 also lists information concerning travel dates, travel times, outbound/inbound departure and arrival times, outbound/inbound departure and arrival airports, outbound/inbound departure in arrival times, etc.

The booking-tickets screen 414 also includes a first-name field 952, a last-name field 953, a frequent-flyer field 954, a seat-preference field 955, and a meal preference field 956 for each passenger in the party. The booking-tickets screen 414 includes a payment-method drop-down list 962 to allow the user 100 to specify the type of credit card use for payment, a card-number field 961, an expiration-month field 962, and an expiration-year drop-down list 963. Cardholder information is provided using a cardholder-name field 964, a home- phone field 965, a business-phone field 966, and an email-address field 967. A delivery-type listbox 970 is provided to allow the user 100 to select a delivery type, (e.g., electronic tickets, actual (physical) tickets, etc.). Actual tickets are mailed to the user 100 as specified by a first-name field 971, a middle-initial field 972, a last-name field 973, street address fields 974, 975, a city field 976, a state field 977, a zip-code field 978, and a country field 979.

Once the user has provided information needed in the fields 960-979, the user 100 clicks a purchased- tickets button 999 to effect purchase of the airline tickets.

The booking-confirmation screen 418, shown in Figure 10, includes a confirmation number 1002. The booking-confirmation screen 418 also confirms the information entered in the booking-tickets screen 414 including flight information (full itinerary), passenger information, billing information, fare price, change fees, cancellation fees, etc.

Figure 11 is a block diagram showing an application architecture for the online reservation system 107. As shown in Figure 1 1, a router 1102 routes information from the Internet 104 to a Web farm 1104. The Web farm 1104 includes one or more servers such as servers 1 106-1108 shown in Figure 11. Each Web server 1106-1108 includes an application server and a broker client. The broker clients communicate with a queue/broker server 11 10. The queue/broker server 1110 communicates with one or more pool managers 1 120 through 1122. The pool managers 1120-1122 manage pool requests to the first and second CRS 308, 324 shown in Figure 3.

The Web servers 1106 to 1108 also communicate with one or more session servers 1 1 12 and one or more database servers 1 1 16. In one embodiment, the database server manages an Oracle™ database.

Authentication and security components of the system validate that a user cannot masquerade as another user and can only execute functions authorized for that user. The system uses a password login and a list of permissions to implement authentication. This helps to ensure that components of the system behave as intended and may not be compromised by unintended or malicious use. Information about the authenticated users, including permission information, is stored in the user's session. The session mechanism is designed to make it difficult for a user to masquerade as another user or switch to another user's session. This is achieved via two mechanisms. First, a session is identified by a session key (in one embodiment, the session key is a decimal number sequentially allocated to new web sessions). A check key is assigned with every session key. The check key is a highly random unpredictable number generated for every session key. All session queries require the correct check key also be supplied. Second, session queries from an active server require that an HTTPHEADERS field be included. The HTTPHEADERS field contains data defined for the HTTP ALL in a standard CGI environment definition and includes a web browser IP address and hostname information. A portion of this HTTP meta information is checked for consistency against the information registered when the session key is created. Session requests that appear to originate from different user machines will be rejected. The session creation process is started when an HTTP request is made for a page or action and the current session key is stale, invalid, or absent. The entry page for the site will contain a link to the main menu page with no session key. The system responds by creating new session information (session key and check key) with no user information and sending a login form to the user. The original HTTP request is serialized and included in hidden fields on the login form. The user then enters a username and password and submits the form to the server along with the new session information and original request data. If authenticated, the server responds to the login by sending an

HTTP redirect to the browser. The redirect is to the originally requested page (the main menu for new users). The browser then requests the original page, but with a new session indicating that the user has been authenticated.

Figure 12 shows an application flow block diagram for the application server 1 108. As shown in Figure 12, the user's computer 102 uses the Internet 104 to communicate with an active server page (ASP) 1202 (or a group of active server pages 1202). The ASP 1202 communicates with a bus.object macro 1204. The bus.object macro 1204 communicates with a bus.object fares engine 1208 (an instantiation of the fares engine 106 shown in Figure 1 ), and a parallel infrastructure module 1206. The parallel infrastructure module 1206 communicates with one or more computerized reservation systems, including the CRS 308 and the CRS 324. The bus.object fares macro 1208 communicates with a database 1210 (i.e., the net fares database 304 and the preferred carrier database 322 shown in Figure 3) to obtains fares and fare discount contracts.

The macro 1204 component is a "router"-type object that is used to initialize other objects and kick-off the retrieval of fare information from both the database 1210 and the CRS 1212, 1214 through the use of multiple functional components (i.e., Airfares.dll, Sabcrs.dll, etc.). This object determines the number of best-three calls (Pub/Disc fares) and Availability Calls (Net fares) to do based on user input and the values in the application-level, global configuration tables. It then launches these CRS requests (both best-three and Availability) in parallel by using the parallel-messaging component 1206. Once the data is retrieved, the macro 1204 sorts and filters the fares. The macro 1204 is also where the price adjustment functionality (shown in the process block 316) is housed. The macro 1206 is also used to prepare fare information just before it is routed to a booking component 1220.

To access the CRS, the system 107 uses a pool manager 1120, such as the pool manager 1 120 (or the pool managers 1 121 , 1122). In one embodiment, the pool manager 1 120 is an ActiveX server written in Visual Basic 5.0, which wraps the manufacturer API for SABRE™ and INNOSYS™ or UDP™ API for Amadeus™ so that it can farm-out dynamic connections to a client.

The pool manager 1120 is different than traditional CRS usage, where one client permanently owns a single connection to the CRS. By placing a pool manager 1120 in between the client and the CRS, it is possible to assign a connection on an as-needed basis. The pool manager 1 120 allows one client with many connections. When the connections are released, an entirely different client can use them later.

The queue/broker server 1110 is an object in front of the pool managers 1120-1122 to decide which pool manager 1120-1122 to route a request to. The server 1110 can send the request to the least busy pool manager 1120-1 122, thus providing load balancing.

The queue/broker server 1110 places pending requests in a queue. By placing pending requests in a queue, the requests do not get immediate failure if the pool manager 1120 has no resources to give. Instead, the requests wait in the queue for a set period of time until the pool manager 1120 can get to them. Thus comes queuing.

If certain high priority requests should be serviced before other, lower priority requests, thus, priority levels are assigned to requests in the queue. For example, in one embodiment, booking requests are higher priority than flight availability requests.

In one embodiment, when the pool manager 1120 loads, it creates a reference count for each service it supports (e.g., SABRE, AMADEUS, etc.). The reference count is equal to the number of available resources in that service. Each broker references that reference count directly by name. When a client requests a connection to the

CRS, the client requests the connection through the broker, which in turn requests the connection of the pool manager 1 120. When the broker hands out a connection, it decrements the reference count. When a client releases a connection, that count is increased.

If a client requests an Amadeus connection from the pool manager 1120 and there are none to give, the reference count is zero and the client request is blocked, waiting in a queue (so to speak), until another client frees a resource to it.

In an alternate embodiment, the broker is a thread-per-object server with three classes, SERVER, CLIENT, and MONITOR. The broker registers both server and client request with the QUEUE so it can handle connection requests. The broker server class is the class that a pool manager 1120 will create a reference to. Each server creates a separate instance of a SERVER.CLS, which in turn gets added to a collection within the QUEUE. It has two functions: 1 ) register and 2) get-status. The Pool manager 1120 passes a reference to itself to the register function. The register function places the entire SERVER.CLS in the server collection in QUEUE. The get-status function allows the pool manager 1 120 to check the status of the queue before it places itself in it. The broker client class is the class that a client wanting a connection to the CRS registers itself with. Each client passes a reference of itself to the class. This allows a pool manager 1 120 reference to eventually be passed along back to the client application. The client class has two functions: get-connection and queue-count. The client application passes a reference to itself, a priority, and a time-in-queue to the get-connection function. The get- connection then adds itself to the collection of client requests in the queue. When the QUEUE serves this request, it passes back an object reference of a pool manager 1120 to get-connection, which will pass that reference back to the client application. A Queue-count allows the client application to check how many items are waiting in queue. An option priority tag can be passed in and the count to return only the count of objects in the queue that match that priority.

Figure 13 is an object interaction flow diagram 1300 showing one embodiment of object flows for a fare ladder query. The object interaction flow provides an overview of the key scenarios in the context of command flow traces. The diagram 1300 begins when the user enters an input query 1301. If the input query 1301 is a travel agency name, then a search-agencies actor 1310 first invokes a function Agencies.GetList 1302 to retrieve the list of Agencies that match the agency name entered by the user. The search-agencies actor 1310 then invokes a function Agents. GetList 1303 to get the list of corresponding Agents. Agents. GetList uses a function Agent.GetByld, which retrieves, using an agent ID, agent information and summary information for each order associated with the agent. The return data includes, an agent name, an agent title, a telephone number, and an email address. The return data also includes agency information, including, an agency ID, an agency name, an agency telephone number, an agency IATA code. The return information also includes order information including the number of orders associated with the agent, an order number for each order, a creation date for each order, an origin airport code, a destination airport code, travel dates, and an ID of a first PNR for the order. A function Agent.Create creates a new Agent in the database. Input information includes an agent name, agent title, telephone number, email address, fax number and an agency ID.

If the input query 1301 is an agent's name, then a search-agents actor 1311 first invokes a function Agents.GetList 1304 to retrieve the list of Agent IDs that match the agent's name. The search-agents actor 131 1 then invokes a function Agency. GetBylD 1304 to get a parent Agency for each Agent.

If the input query 1301 is a passenger's name, then a search-passengers actor 1312 first invokes a function PNR.GetPaxList 1306 (get passenger list) to retrieve a list of PNRs that match the search passengers request. The list of PNRs is provided to a function Agent.GetBγlD to get a parent Agent ID for each PNR. Each parent agent ID is provided to a function Ageny. GetBylD to get parent Agent for each Agent. If the input query 1301 is a PNR ID, then a get PNR by ID actor 1313 invokes a function PNR. GetBylD 1307 to retrieve the PNR.

The function PNR.GetPaxList is part of a module PNR, as described in connection with Figure 17. The module PNR is used to maintain PNR information internal to the system. The module PNR includes functions to create a PNR, retrieve a PNR, add flights to a PNR, add passenger information to PNR, add payment information to a PNR, etc.

Figure 14 is an object interaction flow diagram 1400 showing object flows for a fare ladder query. In the diagram 1400, the user provides search criteria 1401 (e.g., Origin, Dest, Dates, etc.) to a Get Fares actor 1410. GetFares 1410 invokes a function Fares. GetDiscouπtedPubFares 1402 to get the relevant published fares. The actor GetFares 1410 also invokes a function Fares.GetNegotiatedFa.es 1403 to get the relevent negotiated fares. The actor GetFares 1410 invokes a function CRS.GetAvailability 1404 to get available flights that match the search criteria 1401. The actor GetFares 1410 invokes a function Fare.FilterFlights 1405 for each fare to get the sub-set of available flights that qualify for the fare.

The function Fares. GetDiscountedPubFares is part of a "Fares" module. The Fare module is used to obtain fare information for display to a travel representative or the user 100. The Fare module includes a query function GetNegFareDrillDown (get negotiated fare drill down) that retrieves detailed information on the rules under which a negotiated fare passes or fails, and information in general about the negotiated fare (the database information stored with respect to a negotiated fare is discussed in connection with Figures 18-21 ). This function is typically used by the presentation layer of the online reservation system to get detailed information on a fare, including rules violations for the fare drill-down screen display element. The Fare module also includes a query function GetPubFareDrillDown (get published fare drill down) to retrieve detailed information on the published fare.

The Fare module also include a function "Filter flights" to find flights applicable to a negotiated fare. Given an index key to a fare, an index key to an agency, and a list of flights, this function matches the flights against the fares rules and returns the list of flights with each flight marked as qualifying or not qualifying under the rules associated with the fare. The filter-flights query is used by the query function GetFares to generate fare information with corresponding flight availability in a format driven by the preferences of the user. This query is used after flight availability has been retrieved to determine the list of flights that apply to fares.

A query function GetBounds is used to determine alternate dates for a specific fare based on that fare, the direction of the flight (outbound or inbound), and the date of the flight. This function is used by the flight-availability screen elements situated below the fares list on the fare ladder screen. The purpose of the query is to retrieve a list of alternate travel dates based on the rules associated with the selected fare and the other journey date.

The Fare module also includes the query function PriceNegPNR to price an itinerary that is based on negotiated fares.

The Fare module also includes a query function ApplyDiscountToPubPNR to apply a discount to an itinerary based on published fares. This query is used by the Priceltiπerary function to generate the price for an itinerary that is based on a published fare.

The Fare module also includes a query function GetNegotiatedFa.es that retrieves an unordered list of negotiated fares. This function is invoked by the GetFares function to retrieve the list of fares with flight availability information for the fare ladder screen display.

The Fare module also includes a query function GetDiscountedPubFares that retrieves an unordered list of discounted published fares. This query is invoked by the GetFares function to retrieve the list of fares with flight availability information for the fare ladder screen display.

A module "FareLadder" is used to generate the fare ladder. The module FareLadder includes a function GetFares that generates the list of fares for the fare ladder screen display. This function mixes available fares, flight availability, and display preferences to generate the list of fares based on the following sequence of steps: 1. Get available negotiated and published fares using GetNegotiatedFares and GetDiscountedPubFares using the user's criteria as input.

2. Get the list of airlines for which net fare flight availability will be checked using either: the first three distinct airlines occurring on the list of fares; or a fixed list of airlines.

5 3. Get availability for the defined discount airlines with the user's original criteria as input.

4. Get an unbiased (any airline) flight availability with the user's original criteria as input.

5. Match the flight availability with the fares and sort the fares by increasing fare of the leading passenger.

6. The fares are displayed with the maximum availability listed for fares on both inbound and outbound legs.

A module "Flights" is used to obtain flight availability information from the CRS. Given an airline, origin, o destination, date, and time; the Flights module will access a interface to the CRS to retrieve flight availability. A function FlightAvailability is provided to retrieve flights and availability using a list of possible originating airports and a list of possible destination airports. The use of two lists is useful when the origin and destination codes are city or airport codes belonging to multi-airport cities (i.e., IAD, DCA, BWI in WAS and LGW, LHR in LON). The FlightAvailability function can be invoked by GetFares to populate the fare ladder screen and/or to populate a fare- 5 shopping screen directly from the presentation layer (without using GetFares).

Figure 15 is an object interaction flow diagram 1500 showing object flows for creating itineraries. In one embodiment, the user selects outbound and inbound flights from a fare ladder or the user adds flights to an outbound/inbound list from flights listed in a shopping cart. In either case, an actor AddToBasket 1510 invokes a function Basket.AddFlights to add the selected flights to the itinerary. 0 The module "basket" is used to facilitate the processes of fare crunching (fare crunching is the process of pricing of multiple itinerary combinations formed from a set of possible outbound and inbound flights. Basket maintains the list of inbound and outbound flights and does the flight fare crunching. A function "create-basket" creates a new empty flights basket. Inputs to the create-basket function include: an identifier that identifies a travel company and a list of passenger count records. Each passenger count record indicates the type of passenger and the 5 passenger count for each passenger type. The basket function "add-flights" adds a new flight record to the basket.

Each flight record includes: a direction (e.g., inbound, outbound, etc.) and a list of flight segments.

A function "price itinerary" prices an itinerary in the basket. This function prices an itinerary by invoking the appropriate discounting or pricing functions for published or negotiated fares. Inputs to the price-itinerary function include an itinerary type (that indicates whether the itinerary is based on negotiated or published fares), a list of flight 0 records, a list of flight segments, and a list of passenger count records. If the itinerary is based on a negotiated fare, this module completes the task by invoking a query to the fare component of the system. Otherwise, the fare is obtained from a published fare in the CRS and the fare module is invoked to apply an appropriate discount to the CRS fares.

In one embodiment, the user selects one or more outbound and inbound flights and a SelectFlights actor 5 1511 then invokes a module Basket.AddFlights 1510 to add selected flights to the itinerary. In one embodiment, the user selects "Step" to invoke a Step actor 1512. The Step actor 1512 invokes a function Basket.Getltinerary 1504 to get an itinerary at a user-specified time and invokes a module Basket.PricePNR 1506 to price the itinerary. The priced itinerary is returned to the user. In one embodiment, the user selects "Crunch" to invoke a Crunch actor 1513. The Crunch actor 1513 invokes a function Basket.Getltineraries 1505 to get itineraries and invokes the module Basket.PricePNR 1506 to price each itinerary and return the sorted list by price to the user.

Figure 16 is an object interaction flow diagram 1600 showing object flows for the module Basket.PricePNR 1506. For negotiated fares, the module Basket.PricePNR 1506 invokes a module CRS.Validate 1602 and a module Fare.PriceNegotiatedFare 1603 to confirm availability and price the fare respectively. For published fares, the module Basket.PricePNR 1506 invokes a module CRS.Price 1604 and a module 1605 Fare.ApplyPubDiscount to confirm availability and price the fare respectively.

Figure 17 is an object interaction flow diagram 1700 showing object flows for booking. To book an itinerary, the user selects the itinerary and requests that it be booked by calling a function Create Booking. The booking process first confirms the itinerary by calling Basket.PricePNR to price and validate the PNR. CreateBooking calls PNR commands PNR.AddFlights to add the selected itinerary, PNR.AddPassengers, and PNR.AddOSI/SSR to capture passenger and seat preferences information and Add Payment to capture payment information, respectively.

Finally, CreateBooking calls a function CRS.BookPNR to book the completed PNR in the CRS. Contract Management

In one embodiment, contract information data (either as a net fare contract or a discount contract) is stored in the net fares database 304 and the discount fares database 330. Contract information data includes, for example, the data listed in Table 1 above.

Figure 18 is a screen flow hierarchy for a fare management system used to maintain a contract fare database showing a fare-management screen 1801 and its first sub-level. The first sub level includes an open- contract screen 1802, a maintain-contract screen 1803, and a synchronize screen 1804. The fare-management screen 1801 is the highest-level screen in the fare management system. Using menu commands, buttons, and the like, the user can transition to the open-contract screen 1802, the maintain-contract screen 1803, and the synchronize screen 1803. In one embodiment, the user uses a menu command "File:New" to create a new (blank) contract and transition to the maintain-contract screen 1803 to edit the fields and enter data into the new contract. The user uses a menu command "File:0pen" to transition to the open-contract screen 1802, and a menu command "File:Synchronize" to transition to the synchronize screen 1804. The synchronize-screen 1804 is used to synchronize a local contract fare database with a global (e.g., a corporate) contract fare database. Data elements for the synchronize-screen 1804 include a name of the TSP company that can own contracts and a text key identifying a contract within an individual TSP company. Commands include a button to get all contracts for the specified travel company (by using the name of the travel company) and a button to get one contract for the specified travel company (using the text key identifying a contract). The open-contract screen 1802 provides a list of available contracts. The user selects a contract (e.g., by double clicking on an item in the list of contracts) to transition to the maintain-contract screen 1803 to edit the fields of the selected contract.

The maintain-contract screen 1803 provides a number of data-entry/display fields (described below) and a number commands (activated by selecting menu items, pressing buttons, etc.) to allow the user to perform operations or transition to other screens. For example, the maintain-contract screen 1803 includes a save command to allow the user to return a contract all its related data to the local contract database. A print command allows the user to print a contract definition.

Figure 19 is a screen flow hierarchy showing the maintain-contract screen 1803 and its first sub-level screens, including a view-zones screen 1901 , a view-matrices screen 1902, a maintain-rules screen 1903, a maintain- mix screen 1904, a maintaiπ-dates screen 1905, a view-seasons screen 1906, an insert-contract screen 1907, an insert-zone screen 1908, an insert-season screen 1909, and an insert-matrix screen 1910. In one embodiment, transitions to the screens 1901-1910 are provided by menu commands from the maintain-contract screen 1803.

Data elements of the maintain-contract screen 1803 used to open a new local contract include a contract ID (a unique key identifying the contract within the owning TSP company), a contract description (a short text description of the contract), the authoring airline (the airline that made the contract with the owning TSP company), and the name of the TSP company which owns the contract.

The maintain-contract screen 1803 also includes data fields for specifying the effective date (the first flight date for the contract), the end date (the last flight date for the contract), a list of airlines allowed for booking the contract, a list of airlines allowed for booking the contract under frequent flyer plans, the number of productivity or

"tour conductor" tickets provided under the contract, free form text notes for the contract, a contract type (e.g., DISCOUNT, NET fare, or COMMISSION override), the commission paid by the airline on the contract, a second markup (the percent or dollar amount to add to a net fare when calculating a fare display). The mark-up is added after the matrix level mark-up and before any mark-up amount defined for a travel agency group. It is intended to provide a way to cover excess costs for a contract (such as city ticket office messenger charges), and a season type (either DEPART

DATE, FLIGHT DATE, or FLIGHT HIGHER), and a fare basis (either FORMULA, DESTINATION, or VALUE). The season type defines rules for determining fare seasonality. DEPART DATE uses the origination departure date for determining season. FLIGHT DATE uses the flight departure date for determining seasonality. FLIGHT HIGHER uses the flight date to try to find a matching season name, but will bump to a higher season if needed. The fare basis describes how the contract defines the fare basis code to use when ticketing. One embodiment also includes an open jaw policy (e.g.,

"Single Destination," etc.).

A save-local button saves the current contract and all related data to the local database. A publish-to- central button causes the fare management system to sign on to a server that hosts the central database and updates the central database entries for the current contract. The maintain contract screen 1803 also provides fields for specifying booking rules, including the following fields:

• Min book before departure: specifies the minimum amount of time required to book before departure.

• Max book before depart: specifies the maximum amount of time required to book before departure.

• Minimum advance purchase: specifies the minimum amount of time before departure that a flight may be ticketed.

• Maximum advance purchase: specifies the maximum amount of time before departure that a flight may be ticketed.

• Must Ticket After Reservation: specifies the number of days after a reservation within which tickets must be issued.

• Infants per Adult: specifies the number of infants allowed per travelling adult.

• Children per Adult: specifies the number of children allowed per adult.

• Infants plus Children per Adult: specifies the total number of infants plus children allowed per adult.

• Infant Return Policy: specifies a rule for calculating infant age for a return trip (either "Departure Age" or Return Age"). Departure age means once an infant always an infant. Return age means the age at the actual time of flight. If a child turns 2 (or 3) during the trip, the return age rule means that a child seat must be booked.

• Outbound Blackout Days: specifies the days on any outbound leg for which the contract cannot be used.

Return Blackout Days: specifies the days on any return leg for which the contract cannot be used. Total Stopovers: specifies the total number of allowed stopovers. Total Free Stopovers: specifies the total number of free stopovers. Outbound Stopovers: specifies the total number of outbound stopovers. Outbound Free: specifies the number of free outbound stopovers. Return Stopovers: specifies the number of return stopovers. Return Free: specifies the number of free return stopovers.

Booking CRS: specifies the CRS required for booking the contract (typically this value should be Default" to allow the system to determine a booking CRS based on system costs or availability).

Fare Basis for Routing: specifies a "wildcard" fare basis code for performing CRS routing queries. Open Return Duration: specifies the number of days or months allowed for an open return. Accompany Travel: specifies the number of additional people required to travel with the first user in order to qualify for this fare (a value of zero indicates that the passenger is traveling alone). In one embodiment, the lead-time fields (minimum book, maximum book, minimum advance, and maximum advance) described above have a "Per Contract" column and a "Per TSP Policy" column. The fare quote engine will use the values from the TSP policy column when displaying general fare quotes. If a particular date falls between the

Contract and TSP Policy dates, then the late book fee amount from the travel agency profile group is added to the fare for a drill-down display.

In one embodiment, fields are also provided to specify a ticket-by date, a "TAW Hurry" Interval, a "TAW long" interval, and a "TAW short" interval.

One embodiment also includes fields to specify a fee based on an "outbound day of the week," a fee based on a "return day of the week," a fee based on an "outbound weekend day," and a fee based on a "return weekend day."

In one embodiment, the lead-time fields are defined as being of type "Day Text." Day Text fields require entry in a way that can be converted to units of days or business days. Days refer to calendar days. Business days refer to Monday through Friday.

Data Elements. In one embodiment, check boxes allow the user to specify whether advanced seat selection is allowed, and whether a name change in a PNR is allowed for the flight.

Finally, the maintain-contract screen 1803 also includes data fields to specify fees, including the following fields.

• Outbound Day of Week: specifies which days of the week (if any) are used for applying the outbound day of week fee. • Fee Outbound Day of Week: specifies a dollar amount of fee to add to a fare quote for travelling outbound (first leg) on the specified outbound days of the week.

• Return Day of Week: specifies which days of the week (if any) are used for applying the Return day of week fee.

• Fee Return Day of Week: specifies a dollar amount of fee to add to a fare quote for travelling outbound (first leg) on the specified return days of the week.

• Adult Stopover: specifies a fee for a voluntary adult stopover.

• Child Stopover: specifies a fee for a voluntary child stopover.

• Cancel Fee: specifies a fee charged to TSP for canceling a ticketed reservation prior to departure.

• Change Fee: specifies a fee charged to TSP for changing or re-issuing a ticket prior to departure. • Est. Tax to Add: specifies an estimated tax to add for any fare display using this zone.

• Ext. Tax Description: is a text description of the zone's estimated tax for a drill-down and rules display. In one embodiment, the various data fields of the maintain-contract page 1803 are separated into tabbed pages to reduce the size of the maintain-contract page 1803 and to reduce the amount of data on the screen at any one time.

The view-zones screen 1901 allows the user to view a list of origination zones and a list of destination zones (that is, geographic zones) by specifying groups of airport or city codes. Each zone is specified by a zone name and a list of the cities (specified as city codes) and/or airports (specified using airport codes) for that zone. Delete buttons allow the user to delete selected zones from the list. New zones are added, and existing zones are modified by using a maintain-zone screen 2001 reached (as illustrated in Figure 20) by a transition from the view-zones screen 1901. In one embodiment, the maintain-zone screen 2001 is reached by double-clicking a zone from either the origination zone list or the destination zone list in the view-zones screen 1901.

The maintain-zone screen 2001 allows the user to add cities or airports to a zone or remove cities or airports from the zone. In one embodiment the user adds cities/airports to the zone by selecting cities/airports from a list of available cities/airports and pressing an add button. The user deletes cities/airports from the zone by selecting cities/airports listed in the zone and pressing a delete button. Add-all and delete-all buttons are provided to add all available cities/airports or delete all cities/airports respectively. An "Est. Tax to Add" field allows the user to specify an estimated tax to add for any fare display using this zone. An "Ext. Tax Desc." field allows the user to specify a description of the zone's estimated tax for a drill-down display and a rules display.

Returning to Figure 19, the view-seasons screen 1906 allows the user to view a list of contract seasons. Each entry in the list of contract seasons is a season and includes the following columns: • Group: specifies a group name for (e.g. "High," "Shoulder," "Low", etc.)

• Sort: specifies a relative sort order of this group name in the list (for fare grid to get "High" higher than "Shoulder") and the sort order specifies the fare selection for "FLIGHT HIGHER" seasonality contract types.

• Name: specifies the name of the season for display on fare grids. • Start Date: specifies the first date of the season.

• End Date: specifies the last date of the season.

• Notes: is a text description of the season.

An update button updates the in-memory copy of the seasons in the list after verifying that no dates overlap between rows, and re-displays the season list sorted by sort order and start date. A delete button allows the user to delete a selected season from the list.

The maintaiπ-dates screen 1905 allows the user to view and specify special contract dates. Each row in a list of special dates includes the following data elements:

• Direction: specifies a direction of the trip leg (either Outbound, Return, or both). • . From Date: specifies a beginning date of a blackout or special processing period. • To Date: specifies an ending date of a blackout or special processing period.

• Description: is a text description of a special date period.

• Booking Allowed: is a true or false value indicating whether booking is allowed for the specified date and direction. • Fee: specifies, if booking is allowed, the fee due to the airline for booking during the special date period.

A delete button allows the user to delete a selected row from the list. An update button allows the user to update items in the list.

The view-mix screen 1904 allows the user to view and specify special airline and location mixes (e.g. American Airlines to Asia, British Airways to London, etc.). The view-mix screen 1904 provides a list of currently allowed mixes for this contract and a list of all possible mixes from the local database for this contract. Using add and delete buttons, the user can add or delete allowed mixes to the list of allowed mixes.

The maintain-rules screen 1903 allows the user to view and modify a list of special rules for this contract (e.g., special rules can include, for example, "there are no refunds possible for this ticket," "a cancellation fee applies," etc.) Each rule includes a rule number that can be used as an identifier for the rule. The rule number also controls the sort-order of the rules in the list of rules. Each rule includes a "Display to" field the specifies whether the rule is visible to the customer only, to travel service personnel only, or to both. In one embodiment, each rule includes a summary text (a short description of the rule) and a full rule text (a full description of the rule).

The view-matrices screen 1902 allows the user to view a list of the fare matrices for the contract (the actual entries in the fare matrices are viewed and modified using an edit-fares screen 2101 described in connection with Figure 21 below). The view-matrices screen 1902 allows the user to view and modify the following data associated with each matrix:

• Matrix Number: specifies a number the serves as a matrix ID and specifies the sort location of the matrix in the list of matrices. • Matrix Name: specifies a text name of the matrix.

Passenger Type: a code describing applicable passenger types (e.g. adult, child, etc.).

Trip Type: a code describing applicable trip types (e.g., round trip, open jaw, one way, etc.).

Description: a textual description of the matrix.

Last Modification: specifies the date and time of the last modification to this matrix. • First Markup Amount: specifies a percent or dollar amount to add to a net fare when calculating a fare display (this amount is typically added to the net fare before all other mark-ups).

• First Markup Type: specifies whether the first markup amount is percentage or a dollar amount.

A view-details button is used to transition to a set-matrix details screen 2103 and edit the details of a selected matrix. An edit-fares button is used to transition to the edit-fares screen 2101 and edit the fare entries in a selected matrix. An edit-discounts button is used to transition to an edit-discounts screen 2103 and edit the fare entries in a selected matrix. The transitions to the set-matrix details screen 2103, the edit-fares screen 2101, and the edit-discounts screen 2103 are illustrated in Figure 21.

The edit-fares screen 2101 is used to edit the actual fare entries in a fare matrix. In one embodiment, each fare matrix is a two-dimensional spreadsheet-type matrix. The rows of the spreadsheet are indexed by an origination zone (that is, the zone the flight originates from). The columns are indexed by both a destination zone (that is, the zone the flight is going to) and the season. (The origination/destination zones are specified according to entries in the origination/destination zone lists shown in the view-zones screen 1901, and the seasons are specified according to the seasons list in the view-seasons screen 1906.) As indicated above, the columns of the fare matrix have a two-level index based on a destination zone (the first index) and a season (the second index). The user adds a row to the spreadsheet by specifying an origination zone and pressing an "add from" button. The user adds a column to the spreadsheet by specifying a destination zone and a season group and then pressing an "add to" button. The add button adds the specified row or column after checking for duplicates. Each entry (cell) in the spreadsheet is a fare from the origination zone to the destination zone for the specified season. Fares are entered directly into the spreadsheet by selecting a cell in the spreadsheet (the spreadsheet is also called a fare grid or matrix). Delete buttons are provided to delete rows and columns from the spreadsheet.

The edit-discounts screen 2102 allows the user to enter a fare range as a low price and a high price, a discount (as a percent or dollar amount). The discounts are applied on a per-matrix basis. In other words, the user selects a fare matrix from a list of fare matrices (on the view-matrices screen 1902) and then presses the edit discounts button on view-matrices screen 1902 to transition to the edit-discounts screen 2102 and specify the discounts for the selected fare matrix. The edit-discounts screen 2102 show a list of discounts, each entry in the list includes the following data:

• Low Price: specifies the low value of a published fare range to which a discount should be applied.

• High Price: specifies the high value of a published fare range to which a discount should be applied. • Discount: specifies the discount to be applied (either as a percentage or a dollar amount).

The set-matrix-details screen 2103 allows the user to specify various additional attributes for a fare matrix. To access the set-matrix-details screen 2103, the user selects a fare matrix from the list of fare matrices on the view- matrices screen 1902, and then presses the "matrix details" button on the view-matrices screen 1902 to transition to the set-matrix-details screen 2103. The fields of the set-matrix-details screen 2103 include: • Matrix Number: specifies the number of the matrix.

• Matrix Name: specifies the name of the matrix.

• Class of Service: specifies a single class of service that applies for this matrix.

• Required flight numbers: specifies a list of single flight numbers or flight number "wild card" ranges for required flights for a fare. • Prohibited Flight Numbers: specifies a list of single flight numbers or flight number "wild card" ranges for flights which cannot be used for a fare.

• Required Routing: specifies one or more "wild card" routing strings indicating a required itinerary routing for a fare. • Prohibited Routing: specifies one or more "wild card" routing strings indicating prohibited itinerary routing for a fare.

• Minimum Stay: specifies a number of days, a single day name, or a single day name followed by the word "NIGHT" (e.g., "Saturday NIGHT")

• Maximum Stay: specifies a number of days or a specific date. Returning to Figure 19, the insert-contract screen 1907 is used to load a contract into memory from the local contract database. The data fields of the insert-contract screen 1907 include a travel company name, a contract name, and a description. The user presses an "insert" button to erase the current contract and load a new contract (including zones, seasons, and matrices) into memory from the local database. The insert-zone screen 1908 is used to load zone data from the local database. The data fields of the insert-zone screen 1908 include:

• TSP Company: specifies a name of the travel company that owns the contract containing the desired zone to be loaded.

• Contract Name: specifies the name (of ID) of the contract containing the desired zone to load.

• Zone Name: specifies the zone name key identifying the zone within the specified contract. • Description: specifies a text description of the contract.

The user enters the company name, contract name, and zone name, and then presses an insert button to load the specified zone from the local database.

The insert-season screen 1909 is used to load a season into memory from the local contract database. The data fields of the insert-season screen 1909 include: • TSP Company: a name identifying the travel company owning the contract containing the desired season.

• Contract Name: a contract name key identifying the contract that contains the desired season.

• Season Name: specifies the name of the season to load.

The user enters the company name, contract name, and matrix name, and then presses an insert button to load the specified fare matrix from the local database.

The insert-matrix screen 1910 is used to load a matrix into memory from the local contract database. The data fields of the insert-matrix screen 1910 include:

• TSP Company: a name identifying the travel company owning the contract containing the desired fare matrix. • Contract Name: a contract name key identifying the contract that contains the desired matrix.

• Season Name: specifies the name of the matrix to load.

The user enters the company name, contract name, and matrix name, and then presses an insert button to load the specified matrix from the local database. One embodiment also includes a fare-basis screen to allow the user to specify a list of fare basis rules. Each fare basis rule includes a rule number, a rule type (e.g., ALLOW or PROHIBIT), and a definition of how the rule is applied to a fare basis.

One embodiment also includes a time-of-day rules screen to allow the user to specify a list of rules based on the time of day. Each time of day rule includes a rule number, a begin time, an end time, a direction (e.g., outbound or return), and a rule type (e.g., ALLOW or PROHIBIT). In one embodiment, the time-of-day rules screen can be accessed from the view-matrices screen 1902.

In one embodiment, the view-matrices screen 1902 and the set-matrix-details screen 2103 are combined. In one embodiment, the matrix details include a minimum stay, a travel-complete date, and maximum stay.

The Advanced User Interface The screens shown in Figures 5-10 are convenient for use by a consumer or non-professional. In one embodiment, shown in Figures 22-31, the user interface to the system described above is adapted for use by a relatively more advanced user such as, for example, a travel sales agent working in a call center provides travel information to a customer (the caller). Figure 22 shows an initial query screen 2200 where the user fills in information about the caller. The user enters information on the query screen 2200 such as the Origin, the Destination, the Dates, the Passenger Type, the Trip Type. The user then clicks either a "Get Fares" button or a "Get

Flights" button, and the user advances to an integrated fares display screen shown in Figures 23 and 34.

Figure 23 shows an integrated fares display as a rules view 2300 that lists fares according to how well the fares qualified under the rules. Figure 24 shows an integrated fares display as a time view 2400 that lists fares according to travel times. The integrated fare displays 2300, 2400 show the user the net fares in the market as well as the cheapest published itineraries based on data from a CRS (such as, for example, the SABRE "Bargain Finder

Plus" program). In addition, the booking engine 106 applies any available discounts to the published fare to produce the lower fare. The booking engine 106 runs one query on the CRS for the top three airlines for which discounts are available. The booking engine 106 also runs additional CRS queries for other airlines. The results are displayed in the integrated fares list. If the user wants to view more negotiated fare itineraries for a listed airline, then the user can click a

"More" button placed on each line of the fare list. The user can select and book an itinerary directly from the screens

2300 or 2400 by clicking a "book it" button corresponding to the desired fare.

If the user would like to be "coached" to a bigger discount that can apply on a particular airline, the user can click a "details" button and advance to a discount-details screen 2500 (shown in Figure 25). The discount-details screen 2500 shows ways that the caller can qualify for bigger discounts. To build the discount details screen 2500, the booking system 106 calls the FareLadder routine GetNegotiatedFares to get net fares for the requested itinerary. The contract rules such as minimum stay, maximum stay, etc. are checked in the function GetNegotiatedFares.

In one embodiment, there are negotiated fares that did not qualify for the dates specified and those negotiated fares were less expensive than available offerings, the user can be "coached" to that better fare by selecting the "Details" button to go to the details screen 2500. The details screen 2500 shows ways that the traveler can qualify for the less expensive fare.

The booking engine 106 calls GetAvailabilitγ for the first three qualifying net fare airlines. In one embodiment, the availability requests are made to the CRS in parallel. The CRS (e.g., Sabre or Amadeus) is typically selected based on the call center the user belongs to. Querying availability typically requires requesting CRS availability on 6 access sessions for 3 airlines for outbound and return flights. The FareLadder module calls the

FilterFlights function for each qualifying net fare, for each outbound and return flight, to determines which of the available flights qualify for the net fare based on flight number and routing rules. The departure and arrival times of the first available qualifying outbound and return flight are displayed for that net fare in the fare ladder on the screen 2500. If no available flight qualifies for the net fare, and a qualifying flight is sold out for that net fare class, then a "Sold Out" status is presented for that fare item. If no available or sold out flight qualifies for the net fare, then a

"Not Available" status is presented for that fare item.

The FareLadder module then calls GetNegotiated Fares to determine which carriers have a negotiated fare for the desired market (that is, the desired cities or airports). The FareLadder module then selects the three least- expensive contracts to check available itineraries. If GetNegotiatedFares returns more than 3 carriers, then a status line is displayed to indicate the remaining carriers that have a net fare in that market (this typically occurs infrequently and the user can request these carriers by explicitly re-querying with these net fare carriers in the query screen 2200). The FareLadder module calls GetBest3 to get a specified number (e.g., 3, 4, 5, or more, etc.) of the best itineraries for the top set of ranked discount carriers. (For convenience, and without limitation, the present disclosure assumes the specified number of itineraries is three). In one embodiment, the top set of ranked carriers is the to five carriers). The FareLadder module also calls GetBest3 Itineraries with no carriers specified. Each GetBest3 request returns three itineraries and corresponding fare and tax information for each passenger type. The FareLadder module removes duplicate itineraries and groups the itineraries by airline. For each group of itineraries by airline, FareLadder calls GetBestDiscounts. GetBestDiscounts returns, for each itinerary, the following: the Original Published Fare; the Discount; the Discounted Fare; the Apply Discount Flag (Before or After); the Discount Type (amount or percentage); and the Discount Internal Key. The FareLadder module sorts the fares (net fares, discounted fares, and published fares) and displays the results. In one embodiment, the fares are sorted from lowest to highest.

For a net fare, the fare is displayed in a Price column and the estimated tax is displayed in an Estimated Tax column. If the user selects Details, the details screen 2500 is displayed and the FareLadder module calls FareDrilldown with the Fare Item Index as a parameter so that the Fare Detail rules can be displayed. If the user selects More, the FareLadder module calls a function FareLadder with the Fare Item Index as a parameter so that the outbound and return available flights that qualify for the fare can be displayed.

For a published fare, the fare is displayed in the Price column and the Tax + PFCTax is displayed in the Est.

Tax column. If the user selects Details, the FareLadder module calls a function FareLadder. Discounts with the Fare Item Index as a parameter so that the discount rules for that fare item can be displayed. Discounts calls GetDiscounts and highlights the applied discount. If the user selects More, the FareLadder module calls a function

FareLadder.Moreltins (more itineraries) with the Fare Item Index as a parameter so that the group of itineraries for that carrier can be displayed.

The user can also select to go to an unrestricted-availability screen 2600 (shown in Figure 26) to view flights without regard to availability. In the screen 2600, the user can select outbound and return flights to make an itinerary, and price the itinerary using the pricing screen 2700 (shown in Figure 27).

To display the screen 2600, the booking engine 106 first determines the availability for each airline in the query and displays a list of flights (marking the available flights). If the users wants to flex the date (i.e., adjust the date to find a better price) the user clicks a "GO TO FLEX" button to re-request availability for the new dates. If the user selects an outbound flight and a return flight and selects the "Price It" option then the pricing screen 2700 is displayed. The price displayed in the pricing screen 2700 is determined by first accessing the CRS to find the lowest fare for any available class. Then the function GetBestDiscount is called to obtain a discounted fare. If the user selects a "Book It" option, then the booking engine 106 begins the actual booking process with the selected itinerary.

On a more net fares screen 2800 (shown in Figure 28), the user can explicitly select alternative flights that qualify for a net fare item. The user can choose the outbound and return flights for an itinerary. Further, the user can decide to change dates and times by clicking an "adjust" button to adjust the dates and times.

The more net fares screen 2800 shows the qualifying available outbound or return flights. If the user selects the "adjust" option, then the booking engine 106 calls a function More.GetlπdependentBounds to get a list of dates for which the outbound flights can be flexed, while still qualifying for the listed net fare. After the user selects a date and clicks the Adjust option, the More module re-queries Availability and FilterFlights for the selected net fare item and displays the new set of qualifying outbound flights. After the user selects an outbound flight, the user can choose to flex the return flight. A function GetLockedBounds is called to find a list of dates for which the return flights can be flexed, while still qualifying for the net fare. After the user selects a date and clicks the Adjust option, the module More re-queries Availability and FilterFlights for the specified net fare item and display the new set of qualifying return flights. The user then selects a return flight and proceeds to select the Sell It option to book the itinerary.

As another alternative, by using a "More published fares" screen 2900 (shown in Figure 29) the user can explicitly select alternative itineraries, with discounts, by selecting an itinerary and clicking a "book it" button.

Further, the user can decide to change dates and times by clicking the "go to flex" button to go to a best3 screen By using the best3 screen 3000 (shown in Figure 30), the user can adjust the dates and times by changing the desired outbound and return dates and times and then clicking an "adjust date and time" button. The booking engine 106 will then re-query the CRS for the three best itineraries with discounts on the new dates. Once the result are obtained from the CRS, the user can explicitly select alternative itineraries with discounts by clicking the "book it" button to transition to the booking screen 3100.

The best3 screen 3000 operates by displaying the best three itineraries for the carrier listed in the selected published fare items. The user can adjust the dates and times and then clicks the Adjust button to re-request and display the best three itineraries sorted by the discounted price.

The booking screen 3100 is shown in Figure 31. After the user has selected an Itinerary (from any of the above screens) and clicked on the "Book It" option, the user is presented with the booking screen 3100. Here the user captures customer, payment and shipping information needed to complete the PNR.

To book an itinerary, the booking engine 106 first calls a function Verify Price to re-price the itinerary in case flexing causes new price changes. The itinerary and price are then displayed in invoice format. The user captures and validates the customer information, payment information, and shipment information. After the user has entered and verified the information with the customer, then the user can click a button "Book It" to create a PNR. A successful booking returns a CRS Locator and the Booking module saves a minimum PNR record (Sales Agent Id, CRS Locator, Booking Date and Time, Price) to the database.

Through the foregoing description and accompanying drawings, the present invention has been shown to have important advantages over current airline reservation and ticketing systems. While the above detailed description has shown, described, and pointed out the fundamental novel features of the invention, it will be understood that various omissions and substitutions and changes in the form and details of the illustrated system may be made by those skilled in the art, without departing from the spirit of the invention. Therefore, the invention should be limited in its scope only by the following claims.

Appendix A

A sample PNR in Amedeus™ format.

5 - TST RLR -

RP/SAN1S2102/SAN1S2199 F9/RM 16AUG99/0303Z Y2TWDA

SAN1S2199/0862GN/16AUG99 1.BR0WNL0W/D0NNA(ADT)

2 F9520Q05MAR7SEADENHK1 635A1005A ^*1A/E* o 3 F9422Q05MAR7DENATLHK1 1110A405P 1A/E*

4 F9403Q21MAR2ATLDENHK1 700A810A *1A/E*

5 F9803Q21MAR2DENSEAHK1 845A1030A *1A/E* 6AP619-718-6700-A

7 AP 561-123-1234-H s 8TKTL15AUG/SAN1S2102

9 SSR SEAT F9 UC1 SEADEN/A/ARPT 0NLY/N/S2

10 SSR SEAT F9 UC1 DENATL/A/ARPT 0NLY/N/S3

11 SSR SEAT F9 UC1 ATLDEN/A/ARPT 0NLY/N/S4

12 SSR SEAT F9 UC1 DENSEA/A/ARPT 0NLY/N/S5 0 13 RM AGENTID^* DBROWNLOW

14RMFLYCHEAPC0M

15 RM 2820 CAMINO DEL RIO SOUTH

16 RM SUITE 300

17 RM SAN DIEGO CA 92108 USA 5 18RMPAXTYPE:ADT

19RMNUMPAX:1

20 RM BASE FARE: 331.48

21 RM TAX US: 24.86

22 RM TAX PFC: 22 o 23 RM TOTAL FARE: 378.34

24 RM FQ 378.34/331.48/378.34/22/0/24.86/0/0/0/0/0/3.95/1 /F9/N0 NE/TTL 382.29

25 RMW EMAIL-DBROWNLDW(AT)AMADEUS.NET

26 RMW DT-SHIPPING 3.95 5 27 RM "AG4000

28 RM *OB50

29 Rll WE ARE NOT RESPONSIBLE FOR LOST OR STOLEN TICKETS

30 Rll FOR DISCOUNT AUTO RENTALS IN EUROPE CALL AUTO-EUROPE

31 Rll AT 800-223-5555 o 32 Rll THANK YOU FOR BOOKING WITH THE TRAVEL COMPANY

33 FE PAX VIA FRONTIER ONLY NON-REF/60 USD CHGPLTY FEES APPLY /S2-5

34 FP CCAX372800000000003/0401

35 AB PHONE* 561-123-1234 5 36 AB DONNA BROWNLOW

37AB6771 SW120ST

38 AB MIAMI FL 33129

39 AM DONNA BROWNLOW

40 AM 6771 SW 120 ST 0 41 AM MIAMI FL 33129

42 AM DELIVERYTYPE* 3.95 SHIPPING FEE

43 AM DEUVERYAMT^* 3.95 AM PHONE^* AM AMOUNT^* 382.29 AM CCAX372800000000003/0401

Appendix B An alternate embodiment of a sample PNR

-TSTRLRHFRMSC -^•< RP/SAN1S2102/BWI1S211G UA/RM 4AUG00/2229Z ZVZQ2N<

1.BR0WNL0W/D0NNA (ADTX

2 UA1278 Q 20AUG 7 MIAIAD HK1 122P350P *1A/E*< 3 UA7540 Q 20AUG 7 IADEWR HK1 420P542P ^*1A/E*<

4 UA1041 V 30AUG 3 LGAMIA HK1 M 750P1044P ^*1A/E*<

5AP619-718-6700-A<

6 AP 561-123-1234-H<

7AP561-266-1234-B< 8TKTL04AUG/SAN1S2102<

9 SSR SEAT UA UC1 MIAIAD/W/ARPT CKIN/N/S2<

10 SSR SEAT UA KK1 IADEWR/09CN,P1/RS/NS SGMT/RS/S3<

11 SSR SEAT UA KK1 LGAMIA/20FN,P1/RS/NS SGMT/RS/S4<

12 RM AGENTID* AMA1 AMADEUS 1 USER< 13 RM WARNING: QUOTED PRICE DIFFERENT THAN BOOKED PRICE <

14 RM QUOTED BASE FARE: 266.97 / BOOKED BASE FARE: 255.81 <

15 RM RESERVATION PLACED BY DONNA BROWNLOW <

16 RM TRAVEL 800 <

17 RM 2820 CAMINO DEL RIO SOUTH < 18 RM SUITE 300 <

19 RM SAN DIEGO CA 92108 USA <

20 RM PAX TYPE: ADT

21 RM NUM PAX: 1 <

22 RM BASE FARE: 255.81 < 23 RM TAX US: 20.03 <

24 RM TAX PFC: 27.66 <

25 RM TOTAL FARE: 303.5 <

26 RM FQ 303.5/255.81/303.5/27.66/0/20.03/0/0/0/0/4.4/0/1/UA/NO NE/TTL 307.9 < 27RMWDT-E-TKT4.4<

28 Rll WE ARE NOT RESPONSIBLE FOR LOST OR STOLEN TICKETS <

29 Rll FOR DISCOUNT AUTO RENTALS IN EUROPE CALL AUTO-EUROPE <

30 Rll AT 800-223-5555 <

31 Rll THANK YOU FOR BOOKING WITH THE TRAVEL COMPANY < 32 FE PAX FLTS/DTS/UA 0NLY/S2-4 <

33 FP "CHECK <

34 AB PHONE* 561 -123-1234 <

35 AB DONNA BROWNLOW <

36 AB 220 CONGRESS PARK AVE < 37 AB MIAMI FL 33124

Claims

Claims:

1. An online reservation system that provides many of the services a user would expect from a travel agent, the system comprising: a connection to a computerized reservation system; a preferred carrier database; a discounted fares database; a net fares database; and a booking engine configured to construct a fare ladder using information from said preferred carrier database, said discounted fares database, said computerized reservation system, and said net fares database, said fare ladder comprising available flights corresponding to a requested itinerary.

2. The online reservation system of Claim 1, wherein said fare ladder includes fares listed by selected airlines and special contract fares available from a travel agent.

3. The online reservation system of Claim 1, wherein said booking engine is further configured to translate codes used by said computerized reservation system into language that is more easily understood by a typical user.

4. The online reservation system of Claim 1, further comprising a fulfillment system configured to deliver electronic tickets and an email confirmation.

5. The online reservation system of Claim 1, further comprising a fulfillment system configured to deliver paper tickets and an email confirmation.

6. The online reservation system of Claim 1, wherein said booking engine is further configured to allow said user to specify a seat preference.

7. The online reservation system of Claim 1, wherein said booking engine is further configured to allow said user to specify a meal preference.

8. The online reservation system of Claim 1, wherein said booking engine is further configured to check contract rules associated with a contract fare and eliminate fares from said fare ladder that violate said contract rules.

9. The online reservation system of Claim 1, wherein said booking engine is further configured to apply discounts to fares in said fare ladder according to data from said discounted fares database.

10. A method for online ticketing comprising the acts of: retrieving net fares from a net fare database, said net fares corresponding to a requested itinerary; and determining qualified fares by checking said net fares against contract rules corresponding to said net fares.

11. The method of Claim 10, further comprising the act of determining which of said qualified fares are not sold out.

12. The method of Claim 10, further comprising the act of displaying said qualified fares.

13. The method of Claim 10, further comprising the act of searching for fares from alternative airports.

14. The method of Claim 13, wherein said alternative airports comprise airports near a departure airport.

15. The method of Claim 13, wherein said alternative airports comprise airports near an arrival airport.

16. The method of Claim 13, wherein said alternative airports comprise airports in a zone corresponding to a departure airport.

17. The method of Claim 13, wherein said alternative airports comprise airports in a zone corresponding to an arrival airport.

18. The method of Claim 10, further comprising the act of selecting a list of available published fares corresponding to said itinerary, said available fares selected from published fares listed in said computerized reservation system.

19. The method of Claim 10, further comprising the act of merging said qualified fares and said available published fares into a merged fare list.

20. The method of Claim 19, further comprising the act of displaying said merged fare list.

21. A method comprising the acts of: retrieving net fares from a searchable computerized net fare database; and determining available fares by using a computerized reservation system to determine which of said net fares are not sold out.

22. The method of Claim 21, further comprising the act of displaying said available fares.

23. The method of Claim 21, further comprising the acts of determining qualified fares by checking said available fares against contract rules corresponding to said net fares.

24. The method of Claim 21, wherein said act of determining available fares comprises checking two or more computerized reservation systems.

25. The method of Claim 21, further comprising the act of translating codes produced by said computerized reservation system into plain language to be read and understood by a typical user.

26. The method of Claim 21, further comprising the act of booking a flight .

27. The method of Claim 26, further comprising the act of providing electronic tickets.

28. The method of Claim 26, further comprising the act of delivering paper tickets.

29. The method of Claim 26, further comprising the act of allowing said user to specify a meal preference.

30. The method of Claim 26, further comprising the act of allowing said user to specify a seat preference.

31. The method of Claim 26, further comprising the act of allowing said user to specify a meal preference for at least one person in a party traveling with a specified traveler.

32. The method of Claim 26, further comprising the act of allowing said user to specify a seat preference for at least one person in a party traveling with a specified traveler.

5 33. The method of Claim 21, wherein said act of determining available fares comprises checking two or more computerized reservation systems.

34. The method of Claim 21, further comprising the acts of determining qualified fares by checking said available fares against contract rules corresponding to said net fares, and selecting available published fares, said available fares selected from published fares that are not already sold-out. o

35. The method of Claim 34, further comprising the act of merging said qualified fares and said available published fares into a merged fare list.

36. The method of Claim 35, further comprising the act of displaying said merged fare list.

37. The method of Claim 23, further comprising the act of discounting said available published fares according to discount contract stored in a contract database. s

38. The method of Claim 36, further comprising the act of not revealing to traveler an airline name for a discounted fare until said traveler has purchased a ticket for said airline.

39. The method of Claim 21, further comprising the act of establishing a plurality of connections with said computerized reservation system and allocating said connections from said plurality on an as-needed basis to service requests for data from said computerized reservation system. 0

40. The method of Claim 39, further comprising the act of loading a pool manager to manage said plurality of connections.

41. The method of Claim 40, further comprising the act of creating at least one semaphore for each computerized reservation system.

42. A method comprising the acts of: 5 retrieving published fares from a computerized reservation system; determining available fares by using said computerized reservation system to determine which of said published fares are not sold-out.

43. The method of Claim 42, further comprising the act of retrieving net fares from a net fare database, said net fares corresponding to unpublished fares. o

44. The method of Claim 43, further comprising the act of constructing a net fare list, said net fare list comprising said net fares that qualify under contract rules governing said net fares.

45. The method of Claim 43, further comprising the act of checking contract rules corresponding to said net fares.

46. The method of Claim 45, wherein said act of checking contract rules comprises checking for 5 blackout dates.

47. The method of Claim 45, wherein said act of checking contract rules comprises checking a class of service.

48. The method of Claim 45, wherein said act of checking contract rules comprises checking a zone.

49. The method of Claim 45, wherein said act of checking contract rules comprises checking a season.

50. The method of Claim 45, wherein said act of checking contract rules comprises checking a discount range.

51. The method of Claim 45, wherein said act of checking contract rules comprises checking a discount range for a specified zone.

52. An apparatus comprising, a computer processor operatively connected to a memory and a program loaded into said memory, said program configured to retrieve net fares from a net fare database, said net fares corresponding to a requested itinerary, said program further comprising means for determining qualified fares by checking said net fares against contract rules corresponding to said net fares.

53. An apparatus comprising, a computer system operatively coupled to a memory and a software system loaded into said memory, said software system configured to retrieve published fares from a computerized reservation system and determine available fares by using said computerized reservation system to determine which of said published fares are not sold-out.

54. An apparatus comprising, a computer processor operatively connected to a memory and a program loaded into said memory, said program configured to retrieve net fares from a net fare database and determine available fares by using a computerized reservation system to determine which of said net fares are available.

55. The apparatus of Claim 54, further comprising means for managing a net fares contract.

56. The apparatus of Claim 54, further comprising a contract management system configured to manage one or more net fare contracts.

57. The apparatus of Claim 54, further comprising a contract management system configured to manage one or more discount contracts.

58. The apparatus of Claim 54, further comprising a contract management system configured to manage airfare contract information.

59. The apparatus of Claim 58, said contract management system comprising a list of zones.

60. The apparatus of Claim 58, said contract management system comprising a list of seasons.

61. The apparatus of Claim 58, said contract management system comprising means for specifying airline and location mixes.

62. The apparatus of Claim 58, said contract management system comprising means for entering a fare matrix.

63. The apparatus of Claim 58, said contract management system comprising a fare matrix.

64. The apparatus of Claim 63, said fare matrix associated with a first markup amount.

65. The apparatus of Claim 63, further comprising means for entering said fare matrix and data associated with said fare matrix.

66. The apparatus of Claim 63, wherein said fare matrix is configured as a spreadsheet-type matrix indexed by an origination zone and a destination zone.

67. The apparatus of Claim 63, wherein at least one index of said fare matrix is a two-level index based on a destination zone and a season.

68. The apparatus of Claim 63, further comprising at least one discount associated with said fare matrix.

69. The apparatus of Claim 68, said at least one discount limited by a low price.

70. The apparatus of Claim 68, said at least one discount limited by a high price.

71. The apparatus of Claim 63, said matrix associated with a list of prohibited flight numbers.

72. The apparatus of Claim 63, said matrix associated with a list of required flight numbers.

73. The apparatus of Claim 63, said matrix associated with at least one prohibited routing.

74. The apparatus of Claim 63, said matrix associated with at least one required routing.

75. A method for managing one or more discount contracts for use with an airline flight reservation system comprising: entering a list of one or more zones; entering a list of one or more seasons; and entering at least one fare matrix, said fare matrix indexed by an origination zone and a destination zone, said fare matrix comprising fares corresponding to said origination zone and said destination zone.

76. The method of Claim 75, further comprising entering a list of one or more seasons.

77. The method of Claim 75, further comprising specifying airline and location mixes.

78. The method of Claim 75, further comprising associating at least one markup amount with said fare matrix.

79. The method of Claim 75, wherein said fare matrix is configured as a spreadsheet-type matrix.

80. The method of Claim 75, wherein at least one index of said fare matrix is a two-level index based on said destination zone and a season.

81. The method of Claim 75, further comprising at least one discount associated with said fare matrix.

82. The method of Claim 81, said at least one discount limited by a low price.

83. The method of Claim 81, said at least one discount limited by a high price.

84. The method of Claim 75, said matrix associated with a list of prohibited flight numbers.

85. The method of Claim 75, said matrix associated with a list of required flight numbers.

86. The method of Claim 75, said matrix associated with at least one prohibited routing.

87. The method of Claim 75, said matrix associated with at least one required routing.

88. The method of Claim 75, wherein said zone is a geographic zone according to airports.

89. The method of Claim 75, wherein said zone is a geographic zone according to cities.