WO1989007798A1

WO1989007798A1 - Travel management system

Info

Publication number: WO1989007798A1
Application number: PCT/US1989/000684
Authority: WO
Inventors: Mark L. Ahlstrom; James G. Grindeland; Bruce J. Mayer; Kurt B. Sleighter
Original assignee: Systemone Holdings, Inc.
Priority date: 1988-02-22
Filing date: 1989-02-21
Publication date: 1989-08-24
Also published as: AU3203589A; EP0401283A1

Abstract

A remote data base (13) containing flight schedule and fare information is accessed from a local computer terminal (12). Limitations on the applicability of the fare information are inferred from a locally stored expert rule base. A locally stored travel policy can be applied to the retrieved information to select a plurality of potentially preferred flight/fare alternatives. The flight/fare alternatives are displayed for selection of a preferred itinerary.

Description

___. i -

TRAVEL MANAGEMENT SYSTEM

Technical Field This invention relates to data processing methodology and apparatus for accessing flight scheduling, fare, and fare limitations information, and sorting and scoring selected flight schedules and fares from the accessed information in accordance with a predetermined travel policy. In particular, it pertains to such a system that derives fare limitations and combinability of separate flight and fare alternatives into a flight itinerary through the application of an expert rule base to standard fare basis codes.

Background Art Deregulation of the airline industry has resulted in the proliferation of varied flight schedules and fares, each with its own particular set of eligibility requirements. Electronic data base services have assisted in the dissemination of flight schedule and fare information, but the effectiveness of such data availability has been limited by its own unmanageable volume.

U.S. Patent Application Serial No. 008,223, assigned to the assignee of the present invention and incorporated herein by reference, describes a system that can access flight scheduling and fare information, and automatically apply a predetermined travel policy to select a preferred travel itinerary from the accessed information. The system described in the '223 application obtains flight data from a compendium of flight schedule and fare information, such as the Official Airline Guide. Electronic Edition, maintained by the Official Airline Guides, Inc. of 2000 Clearwater Drive, Oak Drive, Illinois 60521, and reads flight scheduling information and fare information directly from the compendium's data base. Fare limitation information (such as advance purchase requirements) is also read directly from the compendium's data base. Fare limitation information is displayed from such data bases in plain English form, and the system described in the '223 patent application discloses a means for parsing and processing the plain English limitation information.

Flight information compendiums, such as the Of icial Airline Guide. Electronic Edition, are maintained as an information service only. As such, the information they include is limited to the information most likely to be used in the most common travel circumstances. Computer- reservation systems, such as the System One Computer Reservation System, maintained by System One, Inc., Houston, Texas, are the systems ^'actually used by the airlines in maintaining and using their flight schedule, fare, and fare limitations information. Accordingly, a travel management system capable of accessing a computer reservation system, rather than a compendium of such information, would have an expanded capability for the selection of preferred travel itineraries.

Computer reservation systems present fare limitation information in plain English language, just as is done in flight information compendiums. The extensive quantity of fare limitation information contained in computer reservation systems, however, makes it impractical to process such information by parsing and processing the plain English. A travel management system that could take advantage of all of the fare limitation information stored on a computer reservation system fare limitation data base. while reducing the time required to process such information, would be a decided advantage.

Summary of the Invention The travel management system disclosed herein provides a method for reading and storing the flight schedule, fare, and fare limitations information maintained on a remote computer reservation system for processing in accordance with a predetermined travel policy. The invention takes advantage of the particular structure and organization in which flight schedule, flight fare, and fare limitations information are maintained within computer reservation systems to reduce processing time.

Flight schedule/availability, flight fare, and fare limitation information are maintained in separate data bases within computer reservation systems. Flight schedule/availability information includes the dates and times which flights are scheduled to depart and arrive specified origination and destination points, and the availability of seating on the flight by fare class. Flight fare information includes the fare amount, a fare basis code, information as to whether the fare is for a one way or a round trip, and certain limited information concerning the applicability of the fare. Complete fare limitation information is maintained in a separate data base and is presented in plain English. The present invention precludes the necessity of querying the fare limitations data base each time the system is used to select a preferred travel itinerary, through the use of an expert rule base that infers the fare limitations from the fare basis codes maintained in the fare data base. Valuable processing time is saved by inferring fare limitations from the fare basis codes, rather than directly accessing the fare limitations data base.

The present invention also includes a unique way for determining whether flight/fare alternatives for any segment of a trip can be combined with flight/fare alternatives for the other segments of a trip. Maintenance tools are provided for keeping the expert rule base current.

Brief Description of the Drawings

Fig. 1 is a schematic view of the system in accordance with the present invention.

Fig. 2 is a flow chart depicting the overall operation of the present invention. Fig. 3 is a flow chart depicting in greater detail the read information step 28 of Fig. 2.

Fig. 4 is a flow chart depicting in greater detail the evaluate fares step 46 of Fig. 3.

Figs. 5a and 5b combine to present is a flow chart depicting in greater detail the analyze fare code step 62 of Figure 4.

Figs. 6a, 6b, 6c, and^' 6d combine to present a flow chart depicting in greater detail the display results and selection step 30 of Figure 2. Figs. 7a and 7b combine to form a flow chart depicting a maintenance tool for the expert rule base employed by the invention.

Detailed Description of the Drawings Referring to the drawings, a system for accessing and processing remotely stored flight travel data 10 includes a locally operated computer system 11 aving terminal 12, memory storage disk 13, printer 14, and communications modem 15. Modem 15 is connected via telecommunication lines 16 to a remotely maintained computer system 17. The computer system 17 includes communications interface equipment 18, and computer 19. The remote computer system is preferably a travel reservation system such as that used by major airlines for processing schedule, fare, and reservation information, and includes a flight schedule/availability data base 20, fare data base 21, and fare limitations data base 22. While the system is shown in conjunction with a remote computer system, it will be understood that the analyzing, sorting, and scoring functions of the system could be applied to locally stored flight information.

Referring to Fig. 2, operation of the system 10, in its broadest sense, is depicted in flow chart form. The operator of the system 10 inputs a travel origin and a final destination for each segment of a travel itinerary, and the time the travel will occur, at the local computer terminal, step 24. The operator next presses a connect key, step 26, thereby establishing a connection between the local computer system 11 and the remote computer system 17. Flight scheduling information, fare information, and flight fare limitation information stored in the remote computer system data base can be read by the local computer system 11, step 28. (As will be explained in detail below, an expert rule based stored at the local computer system 11 precludes the need to access the fare limitations data base each time the travel management system is used.) Once requested information is received from the remote computer system 17, the information is analyzed, scored, and sorted in accordance with the expert rule base and travel policy information stored on disk storage 13, step 30. The operator can select displayed results, and combine flight/fare alternatives recommended by the travel policy software to create a selected travel itinerary, step 32. The read information function of step 28 of Fig. 2 is set forth in greater detail in Fig. 3. The type of trip (i.e., one way, round trip, circle trip) is determined at step 34 from the data .input by the operator at step 24. The trip type information is later used in evaluating the data retrieved from the remote data base. Test 36 determines whether there are segments of the trip to process. In that regard, it will be appreciated that a trip is comprised of one or more segments, each segment representing a city pair consisting of an origin city and a destination city. For purposes of test 36, processing consists of obtaining flight schedule and fare information for each trip segment. If no segments have been entered by the operator, program flow is returned from test 36 to step 24, Fig. 2 where the operator is prompted to input travel origin and destination points. When all trip segments have been processed, program flow is directed to step 30, where information on the trip segments is analyzed and sorted. If there are segments to be processed, program flow is directed to step 38, where scheduling data comprising a listing of flights between cities of each respective trip segment, for the travel times requested, is obtained from the flight schedule data base 20.

Scheduling data can be obtained for a specified range of departure times or arrival times, and the range of time can be expanded if no flights are found in the initially specified range. Co-pending U.S. Patent Application Serial Number 008,223 describes a method for obtaining scheduling data, based on an expanding range of departure or arrival times, that can be employed at step 38.

Once all of the scheduling information available for a given segment has been obtained, program flow is directed to test 40, to determine if any scheduled flights have been found for the trip segment and times under consideration. If there are no flights, program flow is_ directed to block 36 to determine whether there are additional trip segments to process. (Similarly,if there are flights, program flow is returned to step 36 once fare data has been obtained for all such flights.) If the scheduling data recovered from the remote data base reveals there are flights scheduled for the trip segment and times requested, program flow is directed to step 42 for recovery of fare data from the remote data base for each of the flights found. It will be appreciated that a single flight will have multiple fares available (i.e., first class, coach class, advanced purchase, etc.), such that a plurality of fare alternatives will be applicable to a single flight, thereby providing a plurality of flight/fare alternatives. The fare data obtained from the fare data base 21 includes the flight fare code, fare amount, information as to whether the fare is a one-way or round trip fare, and limited information concerning applicability restrictions on the fare code.

Program flow is next directed to test 44 for processing of the fare data recovered from the remote data base for each scheduled flight under consideration. If all fares for the scheduled flight under consideration have been processed, program flow is returned to step 40 to determine whether there are additional scheduled flights for the trip segment under consideration for which fare data is required.

Each fare of each flight retrieved from the remote data base represents a flight/fare alternative that may be applicable to the trip segment under consideration. Whether or not a flight/fare alternative is a viable travel option for the given trip segment is determined by directing program flow to step 46, the evaluate-fares step. The fare evaluation process of step 46 is set out in detail in Figs. 4 and 5.

The fare evaluation process begins at test 48 for a determination of whether the fare under consideration is a round-trip or one-way fare. If the fare under consideration is a round trip fare, program flow is directed to test 50 where it is determined whether round trip fares should be considered based upon the trip type determination made in step 34. If the trip type was determined in step 34 to be other than a one-way trip, program flow is directed to step 54, otherwise program flow is directed to the next available fare line . If the fare under consideration is not a round trip fare, program flow is directed to test 52 where it is determined whether enough one way fares have already been reviewed to make inquiries on further one way fares redundant. If further one way fares are to be considered, program flow is directed to step 54, otherwise program flow is returned to step 44 to determine whether there are additional flight/fare alternatives to consider.

It will be recalled that certain limited data concerning applicability of restrictions on a fare code are presented with the fare data from the remote fare data base. The limited data is separate from, and a subset of, the complete applicability limitations data that is presented in plain English from the remote data base limitations file 22. Step 54 evaluates the limited applicability information that is retrieved from the fares data base in order to determine the preliminary applicability of the fare. For instance, the fare data may indicate that the fare is valid only for a certain day, or that advance purchase must be made a certain number of days in advance of the flight. If the travel plans under consideration are not for the day the fare is valid, or if advance purchase requirements cannot be met, the flight/fare alternative would be inapplicable. If it is determined at step 54 that limitations contained in the fare data make the flight/fare alternative under consideration inapplicable, the flight/fare alternative under consideration is rejected, and program flow is returned to step 44 for consideration of the next flight/fare alternative.

Program flow is directed from step 56 to the analyze fare code step 62, if the flight/fare alternative under consideration is for the appropriate round-^trip or one-way type, and if the applicable restrictions within the fare data do not preclude further consideration of the flight/fare alternatives. The analyze -fare code step 62 determines whether there are any limitations on the applicability of the flight/fare alternative under consideration, by application of an expert rule base to the fare code obtained from the fare data base 21 in step 44. Fare limitation information is obtained from the expert rule base rather than accessing the fare limitations data base 22 to directly derive the fare limitations.

The expert rule base is premised on the relationship between fare codes and fare applicability limitations. Fare codes consist of from up to 12 alphanumeric characters. Through accepted industry usage, certain fare code patterns are predominantly associated with the same limitations on the applicability of the fare. (For instance, the characters "AP14" in the fare code MAP14 always indicate that the ticket must be purchased 14 days before the flight departure date) .

The airline industry has developed several hundreds of variations of limitations on the applicability^' of fares. Examples of limitations commonly used are advance purchase requirements, requirements to travel on specific days or specific times, and penalties assessed for cancelling the flight reservation. The expert rule base employed at step 62 is able to infer which of the hundreds of possibilities of fare limitations apply to a given flight/fare alternative. As its input, the rule base considers six factors derived from the system user, and from the schedules data base 20 and fares data base 21 of the remote computer system. The factors include the departure. airport, the arrival airport, the carrier, the fare direction (either outbound or inbound) , open jaw travel direction (travel that does not depend on air travel for each segment of the trip is known in the industry as "open jaw" travel), and the fare basis code. Each of the rules in the expert rule base considers each of the above mentioned input variables, and the rule applies to the flight/fare alternative under consideration if the input variables match the requirements of the rule. For instance, the rule may indicate that travel on certain days at certain times is required for the fare to be applicable. If the input variables of the rule are met the limitations inferred by the rule may be attached to the flight/fare alternative under consideration. ^■ Alternatively, the limitations inferred from the rule can be analyzed to determine whether the flight/fare alternative can be immediately disqualified from further consideration.

^• Referring to Figure 5, execution of the rule base is . initialized by setting the output of the rule base to NULL and setting a pointer to the first rule in the rule base. Program flow is directed to test 66 for one-at-a-time selection of the rules for consideration. Each rule for which all input variables are met will be activated, and the action specified by the rule will be executed. For instance, the fare limitations reflected in the rule will be attached to the flight/fare alternative under consideration if the requirements of the rule so indicate. When all rules in the rule base have been considered for the fare in question, program flow is returned to test 60, Fig. 4. Tests 68-80 consider each of the rule input requirements one-at-a-time to determine whether a particular rule will be activated. Test 68 determines whether the depart city condition of the rule matches the depart city for the flight/fare alternative under consideration. If the depart city condition of the rule is not satisfied, program flow is directed to test 66 for consideration of the next rule- in the rule base. If the depart city condition of the rule is satisfied, program flow is directed to test 70 where it is determined whether the arrive city condition of the flight/fare alternative matches the arrive city condition of the rule. If the arrive city condition is not met, program flow is returned to test 66 for consideration of the next rule. Program flow is directed in a similar manner to tests 72, 74 and 76 for a determination of whether the carrier, the fare direction, and open jaw travel direction conditions of the flight/fare alternative under consideration are met.

Rather than requiring an exact match as an input^, condition to a rule, the match fare code patterns step 77 analyzes the fare code with a standard pattern matching technique (such as a GREP-style pattern matching method) for the occurrence of recognizable patterns. For instance, if the patter AP14 is found anywhere in a fare code (such as QAP14NR) , a rule can be activated indicating an advance purchase requirement applies to the flight/fare alternative under consideration.

If no pattern is found between the fare code under consideration and the rule in question, program flow is directed to step 66 by test 78 for consideration of the next rule. If a pattern is found, program flow is directed to step 79 for marking of the characters used in the pattern matching. In that regard, it will be appreciated that specific alpha-numeric characters can present different meanings depending on the pattern they appear in. Once specific characters have been determined to appear in a given pattern, they can be marked at step 79 so that they will not be reanalyzed as being in a different pattern. The rules can be ordered within the rule base so that the first pattern which a character is identified as belonging to will be the correct pattern for that character. Program flow is next directed to step 80, where predetermined variable information can be extracted from the fare code. For example, the pattern "AP" within a fare code always indicates that an advance purchase requirement pertains, with numeric characters indicating the number of days required for the advanced purchase (i.e., API4 would require an advance purchase of 14 days) . Rather than have a separate rule for each advance purchase requirement (i.e., AP7, AP14, etc.), the variable data pertaining to the number of days can be recovered from the fare code under consideration. 5 Program flow is next directed to test 82 where the actions required by the rule are addressed one at a time. Actions required by a rule may include attachment of a limitatrbn to the flight/fare alternative under consideration. Alternatively, the action may indicate that τ_0 subsequent rules in the rule base may be skipped over if the rule under consideration applies, or the limitations inferred by a rule may be analyzed immediately to disqualify a flight/fare alternative.

Program flow is directed to step 84, where the τ_5 variable data recovered at step 80, if any, is inserted into the rule. Program flow is directed to step 86, where the action is executed. Test 87 determines whether the flight/fare alternative can be immediately disqualified because of the limitation implied by the rule, and returns

20 program flow to step 44 for consideration of the next fare, if the flight/fare alternative is so eliminated.

Once all of the rules in the rule base have been examined for the fare in question, program flow is returned to test 60, Fig. 4. Test 60 considers availability

25 information to determine whether there are seats available for the fare in question. If there are available seats, the fare data is saved in step 61, and program flow is directed to test 44 to consider the next fare. If no seats are available, the fare is discarded and program flow is

30 directed to test 44 for consideration of the next fare.

Once each of the flight/fare alternatives is ascertained from the remote data base, communications with the remote data base can be terminated.

Very often, the most economical flight/fare

35 alternative for a given segment of a trip is a round trip fare. A round trip fare in one segment may be used. however, only if it is combinable with at least one flight/fare alternative in every other segment of the trip. Fare basis codes fall into one or more combinability categories. Associated with each fare basis code is a list of combinability tokens indicating the combinability categories into which the fare basis code falls. Fare basis codes must share at least one combinability token in order to be combinable with each other. Combinability rules contained in the expert rule base assign combinability tokens to each flight/fare alternative under consideration depending upon the combinability categories into which the fare basis codes fall. In order to recommend a travel itinerary which takes advantage of round trip fares, the system must determine whether there are combinability tokens that are common to at least one flight/fare alternative in each segment of the trip.

Figs. 6-8 depict the display and selection step 32 in greater detail. At step 88, the system compiles a list of all unique combinability tokens associated with fare basis codes in the first segment. The system takes the first combinability token from the list (step 90) and in step 92 compiles a list of all fare basis codes in other segments which share the same combinability token. Program flow is directed to test 94 where the system determines whether there is at least one fare code from each segment which shares the same combinability token. If the combinability token is not common to at least one fare code in each segment of the trip, the combinability token is removed from each fare code in each segment with which it is associated (step 96) , and program flow is directed to test 100 to determine whether there are additional combinability tokens in the list of unique combinability tokens. If the combinability token is shared by at least one fare basis code in each segment, the fare basis code is marked as acceptable and program flow is directed to test

100 to determine whether there are more combinability i I

- 14 -

tokens to consider. Once all combinability tokens have been considered, program flow is directed to step 102 where all fare basis codes not found to be acceptable are removed from the list of fares to be considered for selection. In step 104 the system recompiles a list of all unique combinability tokens in segment one which were found to be combinable with other trip segments. " In step 106 the system then removes any combinability tokens in other segments which are not contained in the list compiled in step 104. The system then scores the flight/fare alternatives at step 30 to determine which of the available flight/fare alternatives found is the most desirable. U.S. Patent Application Serial No. 008,223, referred to above, describes a method for scoring the flight/fare alternatives that can be employed at step 30.

Program flow is next directed to step 108 where each combinability token is retrieved from the list of unique combinability tokens compiled in step 104, Fig. 5. The system aggregates the scores of the highest scoring flight/fare alternative in each segment which uses the retrieved ^'combinability token (step 110) and compares the aggregate score for the combination under consideration to the aggregate score of the highest scoring combination previously considered by the system. The aggregate score and associated combinability token for the highest scoring combination as yet considered by the system is retained in step 112. Program flow is directed to test 114 where it is determined whether each entry in the list of unique combinability tokens has been considered by the system. As long as there are entries yet to be considered in the list of unique combinability tokens, program flow is directed to step 108 for consideration of the next combinability token, otherwise program flow is directed to step 116.

Steps 116, 118 and 120 describe the format in which recommended flight/fare alternatives are displayed to the user. The flight/fare alternatives from each segment which combined to produce the highest aggregate score are displayed on the terminal screen in inverse video, and the status of those flight/fare alternatives is set to "selected," step 116. Remaining flight/fare alternatives which share the associated combinability rule pointer with the selected flight/fare alternatives are displayed on the terminal screen as highlighted, and the status of those flight/fare alternatives is set to "combinable," step 118. In step 120, the status of all other flight/fare alternatives is set to "non-combinable, " i.e., flights which are not combinable with the currently selected flight/fare alternative. Non-combinable flight/fare alternatives are displayed on the screen as low lighted.

Program flow is directed to test 122, Fig. 7 where the flight/fare alternative selection process takes place. Currently selected, combinable and non-combinable flight/fare alternatives are displayed for each segment. As mentioned above, selected flight/fare alternatives are displayed in inverse video, combinab-le flight/fare alternatives are displayed as highlighted, and non- combinable flight/fare alternatives are displayed as low lighted. If the user chooses flight/fare alternatives which have been initially selected by the system, the selection process is complete, otherwise, program flow is directed to test 124. Test 124 determines whether the user has selected a flight/fare alternative which is currently combinable. If the user selects a currently combinable flight/fare alternative the status of the currently selected flight/fare alternative is changed to "combinable," and that alternative is displayed on the screen as highlighted, step 126. Program flow is directed to step 128 where the status of the combinable flight/fare alternative is changed to "selected," and the selected flight/fare alternative is displayed on the screen in inverse video, and the selection process is complete. If the user selects a flight/fare alternative which is currently non-combinable (i.e., not combinable with flight/fare alternatives selected by the system) , program flow is directed by test 124 to step 130 where the system issues a warning message that selection of the flight/fare alternative in question may change the selected and combinable flight/fare alternatives in other segments of the trip. Program flow is directed to test 132 where the system determines whether' the user actually wishes to select the non-combinable flight/fare alternative. If the user decides not to select the flight/fare alternative in question, the selection process is complete, otherwise program flow is directed to step 134.

In step 134, the status of the selected flight/fare alternative is changed from "non-combinable" to "selected," and the selected flight/fare alternative is displayed on the screen in inverse video. In steps 136-150 the system redetermines the combinable and non-combinable status at the displayed flight/fare alternatives by determining which flight/fare alternatives in other segments are combinable with the flight/fare alternative selected by the user. A list of combinability tokens associated with the selected flight/fare alternative is compiled of step 136. Program flow is directed to step 138 where the system retrieves a combinability token from the list of tokens compiled in step 136. The system aggregates the scores of the highest scoring flight/fare alternative in each segment which uses the retrieved combinability token (step 140) . Program flow is directed to step 142 where the aggregate score for the combination under consideration is compared to the aggregate score for the highest scoring combination previously considered by the system. The aggregate score and associated combinability token for the highest scoring combination as yet considered by the system are retained in step 142. Program flow is directed by test 144 to step 138 if there are more combinability tokens to consider, otherwise program flow is directed by test 144 to step 146. In step 146, the status of the flight/fare alternatives which combined to produce the highest aggregate score is set to "selected, " and the selected flight/fare alternatives are displayed on the screen in inverse video. Program flow is directed to step 148 where the status of flight/fare alternatives which share the associated combinability token with t'he selected flight/fare alternatives are displayed on the screen as highlighted, and the status of those flight/fare alternatives is set to "combinable". Program flow is directed to step 150 where the status of all other flight/fare alternatives is set to "non-combinable," and the non-combinable flight/fare alternatives are displayed on the screen as low lighted. Fig. 9 and Fig. 10 combine to depict a maintenance tool for the rule base wherein all the fare limitations data and fare codes for a selected market or markets are compared with the rule base to determine whether all fare codes, and their limitations, in the market are addressed by the rule base. The list of markets to be considered may be randomly generated by the system from a file of city codes, or may be supplied by the user. The system examines the first market to be considered, step 152. Program flow is directed to step 154 where the system queries the host schedules data base 20 for all airlines serving the market under consideration. Program flow is directed to step 156 where the system queries the host fare data base 21 for all fare codes used by the airlines serving the market under consideration. Program flow is directed to step 158 where the system determines from the host fare limitations data base 22 all rules that apply to each flight/fare code alternative within the market under^■consideration. In step 160, the system extracts advance purchase data, booking class, combinability rule pointers and day/time restrictions for each flight/fare code alternative. The information derived in steps 154-160 is written to a file in step 162 for consideration at step 166. Program flow is directed to test 164 where the system determines whether there are additional markets to process. If there are additional markets to process, program flow is directed to _; step 152 where fare code information concerning the next market is obtained.

When all markets have been considered, program flow is directed by test 164 to step 166 where a line of information from the input file created at the step 162 is read by the system. Program flow is directed to step 168 where the airline, market and fare code from the line of information under consideration are passed to the fare code analyzer routine, steps 62-86. The fare limitations determined to be applicable by the fare code analyzer routine are compared to the actual limitation information contained in the input file, step 170, and any discrepancies are written to appropriate output files depending upon the type of limitation involved. In this

- manner, the system is able to identify fare codes which are not correctly analyzed by the rule base, so that appropriate modifications to the rule base can be made.

Program flow is directed to test 174 where the system determines whether there is another line of data in the input file to process. If there are more data lines to process, program flow is directed to step 166 for consideration of the next flight/fare code alternative. Once all data in the output file has been processed, program flow is directed to block 176 where information concerning the new fare codes encountered by the system is written to a log file. The log file contains such information as the airline, fare code, the first date on which the fare code was encountered by the system and the last date on which the fare code was encountered by the system.

Claims

We claim :

1. A method for determining travel itineraries from a travel data base having separate schedule, fare, and fare limitations data files, comprising the steps of: compiling an expert rule base having a plurality of rules, the rules in the rule base pertaining to fare limitations maintained in said fare limitations data file and having predetermined individual activation criteria; retrieving data on scheduled flights from said schedule data file for a desired travel time to obtain available scheduled flights between a selected origin and destination points; retrieving fare data from said fare data file for each of said available scheduled flights to present at least one flight/fare alternative; and comparing the fare data for said flight/fare alternative against the individual activation criteria of each of said rules to determine whether the fare limitations of each of said rules are applicable to said flight/fare alternative, whereby the applica¬ bility of said flight/fare alternative is determined without accessing said fare limita¬ tions data file.

2. The invention as claimed in claim 1, said fare data including fare codes and said activation criteria including fare code criteria, said step of comparing said fare data against said activation criteria of each of said rules including the step of comparing said fare codes for said flight/fare alterna- tive against said fare code criteria.

3. The invention as claimed in claim 2, said fare code comprising an alpha numeric code word, said step of comparing said fare codes for said flight/fare alternative against said fare code criteria including the step of analyzing the alpha numeric code word with a pattern matching technique.

4. The invention as claimed in claim 1, includ¬ ing the step of periodically updating the expert rule base by retrieving fare limitations data from said fare limitations data files and comparing the rules of the rule base to the fare limitations data.

5. A method for displaying a plurality of scheduled flight/fare alternatives for the travel segments of a round trip travel itinerary comprising the steps of: simultaneously displaying at least some of said flight/fare alternatives; visually distinguishing the preferred flight/fare alternative for each travel segment of said travel itinerary from the remaining of said flight/fare alternatives; determining which of said remaining flight/fare alternatives are combinable _ with said preferred flight/fare alternatives to create a round trip travel itinerary; visually distinguishing said combinable remaining flight/fare alternatives from said preferred flight/fare alternatives and the remaining flight/fare alternatives that are not combinable with said preferred flight/fare alternatives.

6. The invention as claimed in claim 5, includ¬ ing the step ^"of determining the preferred flight/fare alternative in accordance with a predetermined travel policy.

7. The invention as claimed in claim 6, includ- ing the step of overriding said predetermined travel policy and selecting one of said flight/fare alterna¬ tives as the preferred flight/fare alternative.