AU2011236120B2 - Booking system and method - Google Patents

Abstract

- 76 The present invention relates to a method and airline booking system 13 for converting fare rules into computer code for efficient fare validation and/or for calculation of sundry costs.

Description

Regulation 3.2 AUSTRALIA PATENTS ACT, 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT ORIGINAL Name of Applicant: AIR NEW ZEALAND LIMITED Actual Inventors: ACKERMAN, JONATHAN; HARDWICK-SMITH, LIZ Address for service A J PARK, Level 11, 60 Marcus Clarke Street, Canberra ACT in Australia: 2601, Australia Invention Title: BOOKING SYSTEM AND METHOD The following statement is a full description of this invention, including the best method of performing it known to us.

-2 FIELD OF THE INVENTION The present invention relates to booking systems for the airline industry. BACKGROUND OF THE INVENTION 5 Traditionally, when a customer wanted to book airline flights to travel to and from a destination, they visited a travel agent who assisted them in researching the availability and cost of flights. The customer then booked the flights through the travel agent and received tickets some time later when processing was complete. Due to the advent of the internet, many airlines now provide online booking systems 10 that enable customers to access flight information directly from their own computers over the internet. Such systems enable customers to check the cost and availability of flights, and book flights which meet their requirements. SUMMARY OF THE INVENTION 15 The present invention provides modifications to existing airline booking systems which improve the service provided to customers. The object of another embodiment of the invention is to provide an indication of sundry costs when displaying flight costs 20 Described herein is a method of determining fares for display to a user using a booking system comprising the steps of: converting fare rules into computer code, storing the computer code, receiving flight criteria from a user, identifying candidate fares satisfying the flight criteria received from the user, and retrieving and executing the computer code to determine which of the candidate fares satisfy the fare rules embodied by the computer code. 25 Preferably the fares comprise one or more associated costs for purchasing/booking a journey. Preferably the step of converting fare rules into computer code comprises the steps of: retrieving data defining fare rules, generating interim code that defines the fare rules, from the interim code, generating the computer code, the computer code defining the fare rules. 30 Preferably the computer code is compiled. Preferably the step of executing the computer code to determine which of the candidate fares satisfy the fare rules embodied by the computer code comprises the steps of: selecting a candidate fare identifying a fare rule to be applied to the selected candidate fare, obtain and execute computer code defining the fare rule, obtaining information for applying -3 the fare rule, executing a validator specified by the computer code, the validator utilising the obtained information on the candidate fare to determine whether or not the candidate fare satisfies a fare rule defined by the computer code. Preferably each fare ruled defined by the computer code has two or more categories, 5 wherein a validator applies each category and further comprising the steps of: executing one or more further validators specified by the computer code, the one or more further validators utilising the obtained information on the candidate fare to determine whether or not the candidate fare satisfies one or more fare rules defined by the computer code, and identifying the candidate fare as one that is valid. 10 Preferably the method comprises the steps of: selecting a further candidate fare, retrieving information on the further candidate fare, executing one or more validators specified by the computer code, each validator utilising the obtained information on the further candidate fare to determine whether or not the candidate fare satisfies one or more fare rules defined by the computer code, identifying the further candidate fare as one that is valid. 15 Preferably the candidate fares relate a constructed fare, and if all candidate fares are valid, the constructed fare is flagged as one possible to present to a user. Preferably the interim code defines one or more fares rules, and contains identifiers that identify portions of the interim code that specify a fare rule and aspects of that fare rule, the step of generating the computer code from the interim code, comprises the steps of: 20 parsing the interim code, generating a hierarchy of code generators relating to the portions of the interim code identified by the identifiers, executing each code generator to generate computer code relating to the portion of the interim code to which the code generator relates, wherein each code generator at a higher level in the hierarchy utilises code generated by a code generator directly below in the hierarchy. 25 Preferably the interim code defines one or more fares rules, and contains identifiers that identify portions of the interim code that specify a fare rule and aspects of that fare rule, the step of generating the computer code from the interim code uses one or more code generation processes to, each process generating a subset of the computer code from a subset of the interim code, wherein each code generation process is assigned a logical position in a 30 hierarchy, and wherein the computer code generated by a lower code generation process in the hierarchy is passed to a higher code generation process in the hierarchy, wherein when generating computer code, the higher code generation process utilises the code generated by the lower code generation process.

-4 Preferably interim code data defines fare rules comprising a number of categories, each of which comprises criteria and wherein a code generation process is used for each category, which can extract data from the interim code relating to that category, and generate computer code from that data. 5 Preferably the hierarchy is a tree structure of code generation processes, and the tree structure is traversed in order to generate code with the code generation processes. Described herein is a method of generating code defining fare rules for determining fares available for display to a user using a booking system comprising the steps of: retrieving data defining fare rules, generating interim code that defines the fare rules, wherein the 10 interim code defines one or more fares rules, and contains identifiers that identify portions of the interim code that specify a fare rule and aspects of that fare rule, parsing the interim code, generating a hierarchy of code generators relating to the portions of the interim code identified by the identifiers, executing each code generator to generate computer code relating to the portion of the interim code to which the code generator relates, wherein each code 15 generator at a higher level in the hierarchy utilises code generated by a code generator directly below in the hierarchy. Preferably the obtained information is one or more of: journey option(s) related to the candidate fare, and itinerary information relating to the candidate fare. Preferably the method is executed at least partially in an airline booking system. 20 Preferably a candidate fare is or forms part of a fare construction. Described herein is a method of identifying and presenting fares to a user, the method comprising the steps of receiving flight criteria specified by a user, receiving computer code from a database, the computer code being generated from fare rules to embody the fare rules, selecting candidate fares satisfying the flight criteria received from the user, executing the 25 computer code to determine which of the candidate fares that satisfy the fare rules embodied by the computer code, and presenting the relevant candidate fares that satisfy the fare rules to a user. Described herein is a computer system adapted to generate code defining fare rules for determining fares available for display to a user using a booking system, the computer 30 system comprising: a database containing data defining fare rules, a first code generator module connected to the database and adapted to retrieve data from the database and generate interim code defining fare rules, a second code generator module connected to retrieve interim code from the first code generator, the second code generator adapted to generate computer code from the interim code, the computer code defining the fare rules.

-5 Preferably the interim code defines one or more fares rules, and contains identifiers that identify portions of the interim code that specify a fare rule and aspects of that fare rule, and wherein the second code generator module is adapted to: parse the interim code, generate a hierarchy of code generators relating to the portions of the interim code identified by the 5 identifiers, operate each code generator to generate computer code relating to the portion of the interim code to which the code generator relates, wherein each code generator at a higher level in the hierarchy utilises code generated by a code generator directly below in the hierarchy. Preferably the interim code defines one or more fares rules, and contains identifiers 10 that identify portions of the interim code that specify a fare rule and aspects of that fare rule, and wherein the second code generator module comprises one or more code generators, each code generator being adapted to generate a subset of the computer code from a subset of the interim code, wherein each code generator is assigned a logical position in a hierarchy, and wherein the computer code generated by a lower code generator in the hierarchy is passed to a 15 higher code generator in the hierarchy, wherein when generating computer code, the higher code generator utilises the code generated by the lower code generator. Preferably interim code data defines fare rules comprising a number of categories, each of which comprises criteria and wherein the second code generator module comprises a code generator for each category, each of which can extract data from the interim code 20 relating to that category, and generate computer code from that data. Preferably the hierarchy is a tree structure of code generators, and the tree structure is traversed in order to generate code with the code generators. Preferably the computer code is stored in the database and the computer system further comprises a search engine connected to the database, wherein the search engine 25 adapted to receive flight criteria specified by a user and identify candidate fares satisfying the flight criteria, and wherein the search engine can execute the computer code to determine which of the candidate fares satisfy the fare rules embodied by the computer code. Preferably the search engine comprises one or more validators to execute the computer code to determine which of the candidate fares satisfy the fare rules embodied by 30 the computer code, the search engine is adapted to: select a candidate fare based on received user criteria, identify a fare rule to be applied to the selected candidate fare, obtain and execute the computer code defining the fare rule, obtain information for applying the fare rule, execute one or more validators specified by the computer code, each validator utilising -6 the obtained information on the candidate fare to determine whether or not the candidate fare satisfies a fare rule defined by the computer code. Preferably the fares comprise one or more associated costs for purchasing/booking a journey. 5 Preferably the computer code is compiled. Preferably the interim code is a markup language. Preferably the computer code is java code. Preferably the computer system is or is integrated with an airline booking system. Preferably a candidate fare is or forms part of a fare construction. 10 Described herein is a booking system comprising a computer system adapted to receive flight criteria from a user, the computer system comprising a processor for converting fare rules into computer code, a store for storing the computer code, and a computer program running on the computer system that operates the computer system to: select candidate fares satisfying the flight criteria received from the user, and retrieving and executing the computer 15 code to determine which of the candidate fares that satisfy the fare rules embodied by the computer code. In one aspect the present invention may be said to consist in a method of providing sundry costs to a user operating a booking system comprising: receiving input, from a user interface 20 on a user computer, specifying journey criteria for a desired journey, on a computer system, identifying candidate fares satisfying the journey criteria from one or more databases containing fare information, the candidate fares being associated with the journey, generating and returning information to the user interface to display candidate fares on a fare construction presentation page, receiving input, from a user interface, selecting a candidate 25 fare, calculating sundry costs for the selected candidate fare from sundry costs data retrieved from a database, and generating and returning information via an asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction presentation page. 30 Preferably the fares are displayed on a first sub-portion of the user interface, and the sundry costs are displayed on a second sub-portion of the user interface. Preferably the sundry costs can be one or more of taxes, levies and surcharges.

-7 Preferably the method further comprises the step of displaying a total journey price comprising the selected candidate fare for the journey and the displayed sundry costs for the selected candidate fare. 5 In another aspect the present invention may be said to consist in a method of providing sundry costs to a user operating a booking system comprising: receiving input, from a user interface on a user computer, specifying journey criteria for a desired journey, on a computer system, identifying candidate fares satisfying the journey criteria from one or more databases containing fare information, the fares being associated with the journey, calculating sundry 10 costs for one of the candidate fares from sundry costs data retrieved from a database, generating and returning information to the user interface to display sundry costs for the candidate fare, and candidate fares on a fare construction presentation page, receiving input, from a user interface, selecting another candidate fare, calculating sundry costs for the selected candidate fare from sundry costs data retrieved from the database, and generating and 15 returning information via an asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction presentation page. In another aspect the present invention may be said to consist in a booking system that 20 provides sundry costs to a user comprising: one or more databases containing fare information and data for calculating sundry costs, a computer system with an asynchronous transfer engine adapted to: receive journey criteria from a user interface for a desired journey, identify candidate fares satisfying the journey criteria received from the user, the candidate fares being associated with the journey, generate and return information to the user interface 25 to display the candidate fares on a fare construction presentation page, receive input, from a user interface, selecting a candidate fare, calculate sundry costs for the candidate fare from sundry costs data retrieved from a database, and generate and return information via the asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction page. 30 Preferably the fares are displayed on a first sub-portion of the user interface, and the sundry costs are displayed on a second sub-portion of the user interface. Preferably the sundry costs can be one or more of taxes, levies and surcharges.

-8 Preferably the user interface is further adapted to display a total journey price comprising the selected candidate fare for the journey and the displayed sundry costs for that journey. 5 Preferably when displaying the sundry costs for the journey on the second sub-portion of the user interface, the user interface is further adapted to update the user interface to display a total journey price comprising the selected fare associated with a selected journey and the displayed sundry costs for that fare. 10 In another aspect the present invention may be said to consist in booking system that provides sundry costs to a user comprising: one or more databases containing fare information and data for calculating sundry costs, a computer system with an asynchronous transfer engine adapted to: receive journey criteria from a user interface for a desired journey, identify candidate fares satisfying the journey criteria received from the user, the candidate fares being 15 associated with the journey, calculate sundry costs for one of the candidate fares from sundry costs data retrieved from a database, generate and return information to the user interface to display sundry costs for the candidate fare, and the candidate fares on a fare construction presentation page, receive input, from a user interface, selecting another candidate fare, calculate sundry costs for the selected candidate fare from sundry costs data retrieved from 20 the database, generate and return information via the asynchronous transfer engine to the user interface, to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction page. Described in this specification but not claimed is a booking system including: a computer system for receiving flight criteria from a customer, a computer program for 25 selecting all fares satisfying the flight criteria received from the customer, a user interface for displaying those fares to the customer, wherein the user interface displays at least two tabs, wherein one tab includes the fares for a first class and the other tab displays the fares for a second class. Described in this specification but not claimed is an interface for booking system 30 including: a first tab for displaying fares to a customer that satisfy flight criteria received from the customer, and at least one further tab for displaying fares to a customer relating to another class. Described in this specification but not claimed is a method including: receiving flight criteria from a customer, selecting all fares satisfying the flight criteria received from the -9 customer, displaying those fares to the customer in a tab in a user interface, and further displaying at least one more tab, wherein the tab includes the fares for another class. In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of 5 providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art The term "comprising" as used in this specification means "consisting at least in part 10 of". Related terms such as "comprise" and "comprised" are to be interpreted in the same manner. To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The 15 disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the invention will be described with reference to the 20 drawings, of which: Figure 1 is a block diagram showing the architecture of a booking system, Figure 2 is a flow chart showing operation of the booking system, Figure 3 is a block diagram showing the architecture of a fare rules maintenance system that generates fare rules for use by the booking system, 25 Figures 4a, 4b is a flow chart showing the fare rule generation process, Figure 4c is a flow chart showing the fare rule application process, Figure 5 shows the code generation logical hierarchy, Figure 6 is a flow chart showing how the customer obtains taxes and levies for a flight, 30 Figures 7a to 7c are screen shots of the user interface displaying flight fares including taxes and levies, Figure 8 is a block diagram showing the taxes and levies calculation application and its interrelationship with the webserver and client application, - 10 Figure 9 is a flow diagram showing the taxes and levies calculation process, Figure 10 is a process diagram showing how the booking system obtains taxes and levies for display to a customer, Figures 11 a to 11 c are screen shots of the user interface displaying fares for different 5 classes in different tabs, Appendix A show XML code for fare rules, and Appendix B shows code generated from the XML code. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 10 Overview of Booking System Figure 1 shows an overview of an internet accessed booking system 13 according to one embodiment of the invention which implements functionality according to the invention. The system is accessed by a customer via a computer 1 connected to the internet 2. The 15 system might comprise several interconnected computer sub-systems that might reside at the same or different physical locations. A web server 3 hosts a website, which includes a presentation layer 14 for enabling the user to access the booking system 13 via their computer 1. The presentation layer 14 includes among other things a graphical user interface for displaying information to a user over the internet and retrieving information from a customer. 20 The web server 3 also includes back end applications for transferral of information between the web server and various other components of the system. The website and web server act as a conduit that transfers information between the customer computer 1 and the booking system 13. The web server 3 is connected to a computer system 4 which runs a search/quote 25 engine and a summary costs engine. The search/quote engine 5 is adapted to receive user entered information from the web server 3 and utilise this information to obtain information on scheduled airplane flights, available seats on those flights and the respective costs for those flights which meet the customers requirements in accordance with their criteria entered. The term "fare" will be used to generally refer a cost associated with booking or purchasing a 30 journey and associated service class on a flight. A journey might correspond to several flights that will get a customer to their destination (and back again if necessary). The journey is the set of flights which that transport the customer to their desired location. The term "flight" is used generally to indicate a seat available for purchase or booking on a particular scheduled airplane flight. The search/quote engine has access to a database 12 containing generated - 11 code relating to fare rules implemented by the airline. This will be described in detail later with reference to Figures 3-5. The sundry costs engine 6 calculates the required sundry costs (such as taxes, levies and/or surcharges) associated with the flights that are returned by the search/quote engine. 5 These sundry costs need to be added to the cost of the flight itself, to provide a total cost for a particular fare. The search/quote engine 5 and sundry costs engine 6 will be described in further detail later. The search/quote engine 5 accesses a reservation system 8 via an middleware interface 7. The middleware acts as an interface between the internet/web side of the system 10 13 and the reservation system 8 which is maintained and operated by the airline or other provider of the flights. The reservation system holds information relating to flights provided by the airline, the various seat allocations for those flights along with associated availabilities, times, costs and the like. The system also allows for ticketing and seat management, and also is the definitive record of bookings of the available flights. Those skilled in the art will 15 understand the purpose and make up of the reservation system and it need not be explained in further detail here. Also provided in the system is a loyalty module 9 for recording the accumulation of loyalty points in relation to bookings, and also the redemption of loyalty points for bookings. An online services identity module 10 connected with both the internet and the loyalty 20 module provides a security layer to ensure the redemption of loyalty points occurs only to authorised customers. This aspect of the system will also be understood by those skilled in the art. A brief overview of how the system operates will be provided with reference to Figure 2. A customer who wishes to investigate available flights and their costs with the 25 intention of booking flights to and from a destination can access a booking system, step 20, over the internet via their PC 1. Once they have accessed the website the web server provides a graphical user interface which asks for required information to enable the system to return possible flights and their costs, step 21. This information will include for example, the starting point and destination of the desired journey, the preferred dates of travel, number of 30 travellers, the class of travel and any other criteria for indicating the customer requirements. The presentation layer 14 of the website hosted on the web server 3 then passes the information to the search/quote engine 5, step 22. The search/quote engine obtains flight availability from the reservation system 8 and fare rule information from fare rules database 12, step 23, and processes this information to generate a set of possible fares (that is, available - 12 flights and associated costs) that meet the customer's search criteria. In particular, it processes each fare in turn, and if it meets the fare rules, step 24, it is added to a set of fares for presentation to the customer, otherwise it is discarded. This process will be described further in detail with reference to Figures 3-5. 5 The sundry costs engine 6 then calculates the taxes, levies and other surcharges relating to those flights, step 25, and this information is all provided to the web server 3 which displays the information, step 26, using the presentation layer 14. The system then waits, step 27, and a user can then select a desired flight and proceed with booking the flight, step 28. The customer then enters required details including their name address and the like and also 10 payment details, such as a credit card number. This is passed from the presentation layer to the reservation system 8 via the middleware layer 7. The reservation system 8 then books the selected flights and confirmation is provided back to the customer, step 29, via the web interface. Should the customer wish to accumulate or redeem loyalty points, they enter their identification and authorisation details on the online services identity module, and then the 15 loyalty module processes the loyalty points as required. Search/Quote Engine for Obtaining Fares and Applying Fare Rules The search/quote engine 5 will be described in further detail. In general, the engine 5 receives flight criteria from the customer via the web server and uses this to construct fares 20 that meet the criteria. In particular, the engine 5 retrieves flight availability data meeting the requirements from the reservation system 8, and uses this data to construct combinations of flights (fare constructions) that could carry the customer to and from their destination in accordance with their requirements. The application also retrieves from the reservation system 8 availabilities for those flight constructions. The fares are retrieved from database 12 25 via the search/quote engine 5. This results in fare constructions, where each fare construction comprises one or more available flights meeting the customer's criteria, along with the associated cost for those flights. The manner in which fares are constructed and the processes required for doing are known to those skilled in this area of technology and need not be described further here. 30 This process produces a set of constructed fares which meet the criteria of the customer's search. While a constructed fare might relate to an available flight, the airline has fare rules that determine whether or not a particular fare is available under particular circumstances, and therefore whether it can be offered for sale to a customer under those circumstances. For example, a particular fare might only be offered during a specific period, - 13 so cannot be offered to the customer if they wish to travel outside this period. A large number of such fare rules exist. The use of fare rules in this manner is well known to those in the airline industry. Therefore, the search/quote engine 5 then needs to determine which of those fares in 5 the set of constructed fares can be validly offered and therefore presented to the customer. To do so the search/quote engine 5 processes each constructed fare to determine which of the fares meet the fare rules under the particular circumstances and can be validly offered for sale and should be passed to the customer. Once each constructed fare has been processed in this manner, the set of valid fares is passed to the web server 3 for presentation to the customer. 10 The database 12 accessed by the search/quote engine includes generated code which is compiled by the search/quote engine 5 and is executed to process the constructed fares in accordance with the fare rules. The manner in which the computer data is generated for the database will be described with reference to Figures 3 and 4a. As described above, the airline generates and 15 maintains rules which determine whether a fare on a flight is valid for a particular set of conditions. For example, a particular fare associated with a flight may only be valid during a particular season or in combination with another fare. A particular fare associated with a flight has a set of categories which it must satisfy. The categories are determined by the airline industry and each category contains a number of criteria that must be met by a fare in 20 order to satisfy the category. The airline may determine the particular criteria under any category, and also can stipulate which particular fares associated with flights have to satisfy which categories. The categories are generally industry standard. The airline continually updates 40 these criteria and through a graphical user interface 30 maintains them on a maintenance database 31 containing the fare rules and also batches of updated rules which are 25 ready for publication. An integrator 32 is coupled to the maintenance database 31 and when a batch is ready for publication it extracts the fare rules contained therein step 41. The integrator 32 then converts the batch of fare rules into an interim code, which can be in a markup language (such as XML) or another suitable document or code type step 42. The XML document which 30 defines the fare rules is then placed in a message queue 33 which is polled by an updater module 34, step 43. Upon polling, the updater retrieves any XML documents in the queue step 44. This system provides an asynchronous transfer of information which prevents corruption of data if there is a failure in connections between components of the system at any point. The updater 34 generates code from the XML document, the computer code providing - 14 code for compilation and execution by the search/quote engine 5 as described above. The computer code can be any suitable code, such as Java code. The code embodies the fare rules in a way that enables the search/quote engine 5 to efficiently apply fare rules to fares. The updater then provides the code to a staged database 35, step 45 and subsequently the live 5 database 12 after testing. The staged database is offline and can be accessed by system maintenance personnel by an offline presentation layer 37 and quote engine 38 to test the data and ensure that it works correctly. The live database 12 can be accessed by the presentation layer 14 and the quote engine 5 of the booking system 13 and is therefore used in processing queries for a customer. 10 The manner in which the updater generates code from the XML document will be described with reference to Figures 4c, 5. A simplified example of some XML code which defines the fare rules contained in a fare batch that has been extracted from the maintenance database is as follows: 15 <fare batch> <rule id="5001"> <sequence> <fare basis>TAM1Y</fare basis> <origin>NZ</origin> 20 <dest>US</dest> <category 3> <start date>1DEC</start date> <end date>31DEC</end date> </category 3> 25 </sequence> </rule> </fare batch> The code that is generated in respect of the XML document by the updater 34 is 30 shown below. This code being used by the search/quote engine 5 to compile and execute a processing means to determine if fares are valid or not. If (fare basis ="TAM1Y" and flying "NZ" to "US") (if not - 15 Validate Cat 3 ("1DEC","31DEC") Return false ) Return true 5 Each fare batch contains a number of rules identified by a unique ID of which one is shown above. Each rule is an identification number that is associated with a particular fare, as described above. The rule stipulates which categories must be met by the fare in order to be valid. The next portion of the XML document includes a sequence which specifies the fare 10 basis and the origin and destination ports for the flight. The next portion of the fare batch states the category or categories associated with the rule along with criteria that must be satisfied in order to meet the category requirement. For example, as shown above, the category 3 requires the start date and the end date of the flight to be between 1 December and 31 December. It will be appreciated that the fare batch may include a large number of rules, 15 each rule containing numerous sequences and each sequence containing numerous categories. The simplified version shown above is provided by way of example only. The updater then takes the XML document decodes it, step 46, generates a logical hierarchical tree structure of code generators, step 47, and then traverses the tree to generate the computer code. Each code generator in the updater 34 is an object, each one relating to 20 one tag of the fare batch, e.g. the rule, sequence, category or the like. Each object has a generate code method which can take a portion of the XML code and generate the required programming code for storage in the database 12. The code generators are arranged in a tree structure 51 shown in Figure 5 which logically shows the manner in which the XML data is processed to generate the code. For 25 example, first of all the category 3 object 53 generates code relating to the associated fare rule shown in the XML file step 48. This is then passed to the sequence object 52, step 49, which generates code step 50 in relation to the tags of the XML document. The code generated by the category 3 object is embedded in the sequence generated code where required. Similarly the rule object 55 generates code, step 50, relating to the XML data under the rule ID tag and 30 embeds any code generated by the sequence object 52 in the required place. The final generated code shown where the portions of the code generated by each object are identified. There will be code generators objects for each tag that might exist in the XML, but only a small selection are shown in Figure 5 for clarity. It will be appreciated that the generated code shown is provided by way of example only and is a simplified version. The actual - 16 generated code will longer and based on the XML data which contains many more elements. A typical example of XML data is shown in appendix A, with corresponding computer code shown in appendix B after conversion. Preferably, the The computer code in the database 12 is generated from XML data defining the fare 5 rules as described earlier. A separate portion of computer code is created for each fare rules. The computer code embodies the respective fare rule and can be compiled by the search/quote engine 5 and executed in order to process fare constructions and determine their validity or otherwise. Each fare construction may comprise several individual fares that enable the customer to reach their destination. For example where a customer wishes to travel from 10 Invercargill to Los Angeles, they first require an internal domestic flight from Invercargill to Auckland, the international hub which corresponds to one fare, and then a second flight from Auckland to Los Angeles which relates to another fare. Various combinations of available fares between Invercargill and Auckland and then Auckland and Los Angeles may be put together, each combination forming a fare construction. The fares specify price options for 15 price flights that a customer can take. Journey options relate to the actual physical flights available to take a customer to their desired journey. For any requested journey, there might be a number of different combinations of actual flights that could get the customer to their destination (and back again if relevant). Each journey option relates to one set of flight combinations that gets the customer to their destination (and back again), i.e. that provides 20 their requested journey. Therefore, when a customer enters details requesting a journey to a destination (and/or return), the system first determines the journey options, each being a combination of flights that can take the customer to the destination (and back again if required). Then, the system determines for each journey option, one or more constructed fares, each comprising one or more fares. Each constructed fares define pricing options, for 25 putting a purchase price to the journey option, should the customer wish to take it. Using the fares, the journey options can be priced. The constructed fare, however, might not be valid or applicable for a particular journey option. Therefore, this must be determined before the journey (i.e. the possible journey options) and possible price(s) for each journey option (specified by a constructed fare) is presented to the user. Note, a set of flights forming a 30 journey option might not correlate directly to a fare or fares in the constructed fare. For example, a fare might specify the price option for a flight from city A to city B. The actual journey option might use two flights to get from city A to city B, the first going from city A to interim city C, and the second from city C to city B.

- 17 An example of possible fares for use in such a construction is shown below. It will be appreciated that in any one journey there may be a large number of individual fares that could be arranged in various combinations to form a number of fare constructions for a particular journey. It will be assumed that these relate to one journey option. 5 1 fare aki-lax rt bus $5000 nzd 5001 2 add on ivc-akl rt bus $50 nzd 3 fare aki-lax ow econ $2000 nzd 6001 4 fare aki-lax ow econ $199 nzd 5001 10 Each fare in a fare construction will have an associated rule which is identified by a unique ID. This associated rule indicates which categories of rules must be satisfied in order for that particular fare to be validly offered as part of the fare construction. There are an international set of standard categories, as will be known to those skilled in the art. As 15 described earlier, each category has a number of criteria that must be satisfied by the fare in order for the fare to satisfy the category. And the fare must satisfy each of the categories associated with it by the rule in order to be validly offered. The individual criteria specified under each category are maintained and specified by the airline in accordance with their requirements. 20 The search/quote engine 5 has category validator objects for each international standard category. The search/quote engine 5 processes fare constructions in the following manner. Referring to Figure 6, it first obtains the fare construction for a journey option. It then processes each fare of that fare construction in turn. First, it identifies the rule associated with the fare. It then obtains computer code embodying the fare rule associated with the fare 25 from the database 12, step 60, and then obtains all other necessary data to process fare constructions, such as the fare, party details, itinerary, journey options and the like, step 61. The computer code for a rule might specify several categories which define requirements the fare must satisfy to be valid. This might relate to various factors, such as date of travel, the actual physical flights of the journey options, and other factors. For a fare in a fare 30 construction the code calls and applies all the category validators in turn, step 62, relating to the categories it must satisfy as identified by the rule. For example in relation to the fare between Auckland and Los Angeles with the rule ID 5001, the fare might have to satisfy - 18 categories 3 and 16. As the generated fare rule code is executed, the category 3 validator is called to validate the fare. Various information (input criteria) is passed to the validator object such as the constructed fare, the itinerary, the party information, journey option and the like and other information required in order to process the fare rules. The validator then 5 validates the particular input criteria (i.e. sees if all specified requirements are met) to determine whether the fare satisfies the category. A small example of the generated code which calls the category 3 validator is shown below. If (fare basis ="TAM1Y" and flying "NZ" to "US") 10 (if not Validate Cat 3 ("1DEC","31DEC") Return false ) Return true 15 To satisfy the category the flight between New Zealand and the US must occur between 1 December and 31 December. If the input itinerary of the customer satisfies that query, then the validator returns a match which indicates that the fare meets that category, step 63. If not, step 64, the fare is discarded as invalid and the next fare is processed, step 66. The next validator is then called by the computer code for the fare rule. A similar process is 20 carried out with a category 14 validator, step 65, 62, 63, and if that also returns a match the fare is indicated as being valid. The engine then moves on to the next fare in the set of constructed fares, and determines if it's valid for the input criteria. This is done for all fares of a constructed fare. If all fares are valid, then the entire constructed fare is valid for the journey options, and it could be presented to the customer. An entire constructed fare is 25 usually processed together, rather than the individual components, as whether or not a constructed fare meets the requirements may be dependant of the relationship between the individual fares of the construction. If a constructed fare meets all the requirements then it is flagged as valid and can be presented to the user, step 67. All other constructed fares are also processed in the same manner, step 66, for all other journey options. Note, a journey option 30 might have several possible constructed fares, none, some or all of which might be valid for that journey option. If none are valid, then the journey options cannot be presented to the user, because there are no valid fares for that journey option.

- 19 Generating efficient computer code from fare rules enables the constructed fares to be processed much more quickly than if this was done on the raw fare rule data. The compiled computer code works more efficiently, than if the raw fare rules were interpreted on the fly each time they had to be processed. Preferably, the first time a fare rule is used, the computer 5 code is generated and compiled and used. The next time that fare rule is required, the already compiled computer code is reused. Providing and Updating Sundry Costs A further embodiment of the invention will be described with reference to Figures 6 10 10. This part of the invention overcomes drawbacks of existing booking systems. The total price of the fare that is presented by a booking system includes the actual cost of the flight itself, along with added sundry costs which might be things like airport taxes, levies, surcharges and the like. Sundry costs are not fixed and are dependant upon many factors such as the airports used and the number of flights taken in a particular itinerary. Therefore, when 15 flying from one point to a destination the sundry costs may differ depending on how the fare is constructed. Typically, when a range of constructed fares are presented to a user it is difficult or extremely process intensive to calculate the sundry costs for every constructed fare. Therefore, to overcome this, existing booking systems do not show the sundry costs in the initial stages, but rather just show the actual flight cost for each of the fare constructions 20 presented to the customer. When the customer selects a desired flight which they wish to book, the booking system then calculates the sundry cost for that particular fare construction and adds it to the cost of the actual flights comprising the fare construction in order to provide a final price. This method of proceeding is undesirable as it means the customer is not aware of the total price they will pay when they select any particular fare construction. Further, it is 25 not even possible to provide a rough indication of what a sundry cost will be prior to actual calculation as they differ depending on various circumstances surrounding a particular fare construction. The present embodiment of the invention provides the user with sundry costs for any selected fare construction prior to booking actually being undertaken. This allows the user to 30 inspect the total cost for a range of selected fare constructions prior to committing to booking any particular one of those fare constructions. This provides an advantage over existing systems which only provide a final price including sundry costs when a commitment to book a particular flight is actually made.

- 20 Figure 6 shows a flow chart indicating one method of how the customer obtains an indication of sundry costs prior to booking. The customer first inputs their journey search criteria, step 60, as described previously in relation to Figures 1 and 2, and the system constructs and presents a range of fare constructions to the user that meet that criteria in the 5 manner described previously, step 61 a. The system also determines a default selection of fare constructions from those presented and calculates the taxes and other sundry costs associated with that default selected fare construction, step 62. The user is therefore presented with the flights that meet their criteria along with the flight costs, and for one particular fare construction they are also provided with the sundry costs and an optional total figure, step 65. 10 For example as shown in Figure 7a, three fare constructions (each with multiple costs) are shown between Los Angeles and Auckland all including the actual flight cost, (e.g.70). The default selected fare 71 also includes the calculated sundry cost 72. Referring back to Figure 6, should a customer wish to find the total price for another fare they can select that fare, step 63, and they can obtain the sundry costs for it, step 64. For example referring to 15 Figure 7b, in this case the customer has selected the third fare construction 73, step 63, and the sundry costs associated with that fare construction are calculated, step 64, and displayed 74, step 65. In a preferred embodiment of the invention the presentation layer 14 or user interface presented to the user is not completely updated. Rather only the portion of the screen 20 showing the sundry costs (e.g. 75) is updated showing the new sundry costs. This prevents the user having to wait for an entire web page to be downloaded and refreshed. However, it would be possible for the invention to work by refreshing the entire page. The user can continue to select other fare constructions, step 66, and by doing so receive the sundry costs associated with any fare construction and therefore the total price. This can continue until the 25 user has viewed all the fare constructions including sundry costs or has found a fare that suits their requirements. It will be appreciated that the default sundry costing presented initial, step 62, is determined in the same manner as steps 64 -65, except that a default fare is used, rather than the customer selecting a fare for sundry cost calculation. After doing so the user can proceed to use the booking system 13 in the usual manner, 30 for example booking an actual fare. In this case the user books the third fare construction by clicking the continue with credit card button and is provided with the full cost and itinerary on a booking page as shown in Figure 7c. The processing continues in the usual manner. Note that while the full price is not shown in total in Figure 7a or 7b it could do if required. Also - 21 note that in the final booking page, the final price may differ slightly from that presented in the fare construction selection pages, due to rounding processes which are standard in the art. Figure 8 shows a block diagram of the sundry costs calculation engine 6 and its interrelationship with the client application 80 on the customer's computer 1 via the web 5 server 3. The structure of the software and its interrelationship with the client application enables calculation and presentation of fares and the associated sundry costs prior to actual booking of any particular fare. The engine 6 retrieves sundry cost data or information from the maintenance database 11. The maintenance database is kept up to date by personnel in the airline operating the system to provide the latest sundry costs, such as taxes, levies and 10 surcharges as they are received from various sources. The sundry costs are known to those skilled in the art, and include things such as airport taxes, security taxes, fuel surcharges and other levies imposed by airports, governments and airlines. Depending on where a particular plane flies and lands, various sundry costs will be incurred in accordance with those stipulated by the airports and countries in which the flight lands or flies. The sundry costs maintenance 15 database 11 includes information relating to the type of sundry costs that may need to be applied, the actual costs associated with it, and rules for determining whether or not the sundry costs should be applied in a particular circumstance. This information is retrieved by the sundry cost engine 6 and is passed to a rules engine 81 which determines which sundry costs should be applied. To do so it also receives the relevant information on the fare 20 construction for which sundry costs are to be calculated and any other necessary information required to determine which sundry costs should be applied to those fare constructions. The rules engine 81 could be any suitable rules engine, such as DROOLS. An example of a tax/levy rule which might be applied is shown below. 25 <rule name="Airport Security Charge - (EZ)"> <parameter identifier="segment"> <class>Segment</class> </parameter> 30 <java: condition>!segment.getTaxes () . containsTax("EZ")</java: condition> <java: condition> port. getCountryForPort (segment. getDeparturePort () . equals ("FJ") </java: condition> <java: condition> 35 !port. getCountryForPort (segment. getArrivalPort () . equals ("FJ") </java: condition> -22 <java:consequence> System.out.println("CON - Aiport Security Charge - (EZ)"); segment.getTaxes() .add("EZ","Aiport Security Charge - (EZ)", "FJD", 5 5.0, segment.getJourney().getAdultCount(),0,0); </java:consequence> </rule> <rule name="Fuel Surcharge - NZ POS - NZ to AU/CK/FJ/NF/NC/PF/TO/WS 10 (YQ)"> <parameter identifier="segment"> <class>Segment</class> </parameter> 15 <java:condition>!segment.getTaxes().containsTax("YQ")</java:condition> <java:condition> segment.getJourney().getPosCountry().equals("NZ") </java:condition> <java:condition> 20 port.getCountryForPort(segment.getDeparturePort()).equals ("NZ") </java:condition> <java:condition>port.getCountryForPort(segment.getArrivalPort()).equals("AU 25 port.getCountryForPort(segment.getArrivalPort()).equals("CK") || port.getCountryForPort(segment.getArrivalPort()).equals("FJ") || 30 port.getCountryForPort(segment.getArrivalPort()).equals("NF") || port.getCountryForPort(segment.getArrivalPort()).equals("NC") || port.getCountryForPort(segment.getArrivalPort()).equals("PF") || 35 port.getCountryForPort(segment.getArrivalPort()).equals("TO") || port.getCountryForPort(segment.getArrivalPort()).equals("WS") </java:condition> 40 <java:consequence> System.out.println("CON - Fuel Surcharge - NZ POS - NZ to AU/CK/FJ/NF/NC/PF/TO/WS - (YQ)"); -23 segment.getTaxes().add("YQ","Fuel Surcharge - NZ POS - NZ to AU/CK/FJ/NF/NC/PF/TO/WS - (YQ) - Adults + Children", "NZD", 50.00, segment.getJourney().getAdultCount(), segment.getJourney().getChildCount(), 0); 5 // taxes for infants segment.getTaxes().add("YQ","Fuel Surcharge - NZ POS - NZ to AU/CK/FJ/NF/NC/PF/TO/WS - (YQ) - Infants", "NZD", 1.00, 0,0,segment.getJourney().getInfantCount()); 10 drools.modifyObject(segment); </java:consequence> </rule> 15 <rule name="Fuel Surcharge - NZ POS - International Sector - (YQ)" salience="-10"> <parameter identifier="segment"> <class>Segment</class> </parameter> 20 <java:condition>!segment.getTaxes().containsTax("YQ")</java:condition> <java:condition>segment.getJourney().getPosCountry().equals("NZ")</java:con dition> 25 <java:condition> !port.getCountryForPort(segment.getArrivalPort()).equals ("NZ") || !port.getCountryForPort(segment.getDeparturePort()).equals("NZ") </java:condition> 30 <java:consequence> System.out.println("CON - Fuel Surcharge - NZ POS - International Sector - (YQ)"); segment.getTaxes().add("YQ","Fuel Surcharge - NZ POS - International 35 Sector - (YQ) - Adults + Children", "NZD", 60.00, segment.getJourney().getAdultCount(), segment.getJourney().getChildCount(), 0 ); drools.modifyObject(segment); 40 </java:consequence> </rule> It will be appreciated that other rules engines would employ other mechanisms for coding rules. This would be a set of rules obtained from the rules maintenance database and - 24 is implemented in the rules engine to determine whether or not it should be applied to a particular fare construction. The first rule is for a security charge that is imposed at Fiji airport. This is one rule of many that will be processed to determine whether it is relevant to the particular fare construction. First, this rule determines whether a security charge has 5 already been applied to the fare construction. If not then determines whether the fare construction includes a flight which departs form Fiji airport, and then if so further determines that the traveller did not actually arrive by airline at Fiji airport. If all these conditions are met then the airport security charge is added as a sundry cost to the fare construction. If any of those conditions are not met, then the security charge is not added to the fare construction. In 10 this case the charge is 5 Fijian dollars. An example of a fuel surcharge rule is also indicated above. The rules for sundry costs and the manner in which they are applied will be understood by those skilled in the art, and the rules shown above are therefore provided by way of example only. Once all the rules have been processed the GET SUNDRY COSTS method 82 applies the various sundry costs that have been determined to the fare construction 15 price. This information is then passed through to the web server 3 via a web service 86 or similar. As mentioned previously, in the preferred embodiment of the invention when a sundry cost is returned for display to the user the web server does not refresh the entire fare construction presentation page. Rather it only refreshes the particular portions (e.g. 74) of the 20 web page that display the costs, and updates these with the freshly updated costs. This is achieved through asynchronous internet transfer technologies, such as an AJAX implementation 84, 86 or any other suitable means. The AJAX implementation resides in the web server 86 and in the client application 80 where it is coupled with the user interface 85 operating on the client application 80. The AJAX implementation enables information to be 25 transferred asynchronously between the booking system 13 and the browser client 80 and only update portions (e.g. 74) of the client interface as required. More particularly, the user interface displays constructed fares and when user selection is made to determine taxes for another fare construction a call is sent back to the booking system 13 via the AJAX implementation. While doing so the fares and prices already presented to the customer on the 30 client application user interface remain on display. The AJAX client 84 then sends the request to the sundry cost engine 6 via the web server 3 and then receives the calculated costs as described previously. It then passes these costs onto the user interface layer 85 whereby the portions (e.g.74) of the user interface that display sundry costs are updated with the new sundry costs that have been freshly calculated. At this point the portions of the screen that - 25 show the actual cost of the particular selected flight are also updated to show the costs of the newly selected flight relating to those sundry costs. Figure 9 shows how the sundry costs are actually processed in the rules engine 81. Firstly the sundry costs engine 6 receives the sundry costs information from the maintenance 5 database 11 including types of costs, the value of those costs and rules for determining when to apply the costs step 90. These are then passed to the rules engine step 91 which carries out processing. In particular it retrieves each rule in turn such as that shown above and determines if it applies to the particular fare construction step 93. If it does, then the sundry cost is added to the total costs of the fare construction step 94, and the rules engine then 10 determines if another sundry cost rule exists step 95 and if so that is processed in the same manner steps 92-95. Once all sundry cost rules have been processed the information is passed onto the sundry cost generation method, step 96, and these are all passed on to the web server for transfer to the client application 80, step 97. Figure 10 shows a process diagram of how the system calculates these costs. First of 15 all the user sends a search query 100, and receives back a page of HTML or similar 101 including fares. The customer then operates the client application 81 to request taxes 102 or other sundry costs, and these are calculated and passed back by the system 13 via the AJAX implementation where they are displayed on the client application 81. Upon booking, the system then does a repricing 104 where it adds sundry costs 105 and also rounds the cost 20 appropriately. The final price 106 is passed to the customer and displayed. Using Multiple Tabs to Display Fares In one embodiment of the invention, the booking system 13 provides the customer with fares in multiple classes in response to the query, as will be described with reference to 25 Figures 1la-l id. As described in relation to the flow chart in Figure 2, the customer can enter various criteria indicating the type of flight they require for travel. The booking system 13 then returns a set of possible flights satisfying the criteria that are displayed to the user for inspection, and booking. As part of the criteria, the customer may specify a class of travel, 30 such as service class. For example the class may be first class, business class, economy class, premium economy or any other class of travel provided by the airline. Generally the customer will select a certain class based on the budget they have for travel, their travel - 26 requirements and their desired level of comfort they require during travel. For example, if a customer is more concerned with cost they are likely to select economy class as this will generally provide cheaper fares for any particular flight, although with a reduced level of service. 5 In existing booking systems, the booking system will only return fares that correspond to the class selected by the traveller. However, in this embodiment of the present invention the booking system 13 will provide fares of other classes that otherwise meet the customer's flight requirement. This provides the airline with the ability to up-sell a better class and higher price of flight to the customer. 10 This embodiment of the invention works in the following way. Once a customer enters their travel criteria, the booking system will determine all the fares that meet the criteria in the usual way as explained previously. This will include ensuring that any flights meet the class criteria entered by the customer. However, in this embodiment of the invention the system will also determine flights for other classes not selected by the customer, but that 15 meet all other criteria (apart from class) selected by the customer. This information is passed to the presentation layer 14 on the web server 3. The presentation layer then generates a graphical user interface which displays all the fares for all the classes to the user Figures 11 a 1 c. However, the fares for a particular class are shown in separate tabs, and the user can select the tab of the class for which they wish to view the available fares. For example with 20 reference to Figure 1 la in this case the customer has requested economy class flights between Auckland and Los Angeles. The 113 flights meeting that criteria are displayed to the user in a screen with a tab indicated economy 110. However the system has also determined flights which meet the same criteria for premium economy and business class. These fares are hidden from view initially but are contained in tabs that can be selected by the user. 25 For example, referring to Figure 1 lb the user has selected the premium economy class tab 111 and in doing so is presented with a range of flights 112 in premium economy that meet their criteria. Similarly, in Figure 11 c the user has selected the business class tab 114 and in doing so is presented with all flights 115 meeting the criteria that fall within business class. In this way the user can be presented with flights of other classes that fall within their 30 other criteria they have selected. Where a customer selects another class as their criteria, for example premium economy then economy and business class will be shown. Where business class is selected as a criteria in the initial search, economy and premium economy classes will also be provided. It will be understood by those skilled in the art that this embodiment of the - 27 invention could be applied to other classes of travel. It will also be appreciated that this presentation of fares in tabs representing each class could also be provided where a user does not select a desired class of travel at all. While in the preferred embodiment all classes of travel are determined together when 5 processing the user's search query, alternatively they could be determined as and when a user selects a tab relating to a particular class.

<Batch Baclid=-"244"> <Change> APPENDIX A <FareRule Nodeld="2712"> <Tari f Id>IPRP</ Tariff Id> <RuleId>TCATl9</RuleTd> <Category4> <Category> <Sequence> <SequenceNumber>lc/SequenceNumber> <LocationOne> <Type>C</Type> <Code>AKL</Code> </LocationCne> <LocationTwo> <Type>C</Type> <code>HNL</Code> </LocationTwo> <-areidentifier>HFN1Y</FareTdentifier> N>oAppicablc/ </Sequence> <Sequence> <SequenceNumber>2</Sequenceimber> <Fareldenti fier>HFNlYe/Fareldentifier> <Relationa t lTndicaior> <And>f alse</And> <Cat4DataTable> <FlightResLricti on> <Validiry>valid</Validity> <Flig htRestriccionRow> <Carrier>NZ</Carrier> <FlightOne>5</FlightOne> <Fl IghtTwo>6</FightTwo> </FlightRestrictionRow> <F ightRestrictionRow> <Ca.rrier>NZ</Carrier> <FlightOne>9000</Flightone> <FlightTwo>9999</FlightTwo> </FlightRestrictionRow> <FlightResrictionRow> <Carrier>NZ</Carrier> -28 - <FlightTwo>699</FlightTwc> </FlightRestrictionRow> <FlightRestrictionRowy <Carrier>NZ</Carrier> <FliahtOne>5000</Flightone> <FlightTwo>5999</FlightTwo> </FlightRestrictionRow> <FlightPestrictionRow> <Carrier>NZ</Carrier> <Fliqhtne>8000</FlightOne> <PlightTwo>8999</FlightTwo> </Fli ghtRestrictionRow> </Flight-Restr-iction> </Cat 4DataTable> </Relationailndicator> </Sequence> <Segquence> <SequenceNumber>3 </SequenceNunber> <Fareldentifier>WFN1Y</areen-tifier> <Relat iona lIndicator> <And>false< /And> <Cat4DazaTable> 'sPlighbRwaiL r iuLlusi> <Validity>Valid</Validity> CFl ightRestri ct ionRow> <Carri er>NZ</Carri er> <FlightCne>1</FliyhtCne> < /FlightResrictionRw> <FlightRestrictionRcw> <Carrier>NZ</Carrier> <FlightOne>2</FlightOne> </FlightRestrictionRw> <FlightRestrictionRow> <Carrier>NZ</Carrier>, <FliqhtOne>9000</FlightOne> <FlighttTwoy99994/FlightTwoy a</Fligjhtestrictionow> <FlightRestrictionRowy <Carrier>NZ</Carrier> <Flightone>400</FlightOne> -29 - </FlightRestrictionRow> <FiightRestrictionRow> cCarrier>NZc/Carrier> <Fiight~ne>EOO0c/Flightone> <FSightTwo>5999c/plightTwo> < /Pligh'-tRe st r crtjoRow> cFlightRestrictcnRow> <Carrie r>NZc /carrier> cFlightCne>8oooc/pF ightons> <FlightTwo>8999c/FlightTwo> < / FlighlResmri ct tonRow> </FiightRestiriction> c/Cat42ataTabis> </RelIat iona] I.ndicator> -7 Sequ.-ence> <Secjuence,> <SequenceNumber>4</ SequenceN-Unber > <Fars~Identitier>DFlYc/Farelent 0 i~fjer> <Relation al~ndicatcr> <c4nd~ false c/And> <Cat4lData'rable> <Pi ig]hRestrict ion> <Validiuty>Valid</Valiaity> <RFIJightRestriccionpow> < Cariler>NZ</Ca-riLer> Fliglmonc-- -G</ Fliahtone>. -/FiihtRestrictlonpow> Fli ghtRestricriionRow> <Carrier>NZc/lCarrier> <cFigbLG-ne>l1</Ull1 ghtoie> K /FlightRestrlcrxion~ow> <PlightResr riot icriRow> -cCarrier>NZ< /Carrier> <F'lightonez'S/Ri igtOne> 'cFihtLlestricuionRcow> <F1 igltResztrict ionRow. <Carrier>Nz< /Carrier> c Fi.iqbt one >2 1</ -'ligjuOne > <c/Fliqht~es t rictjiorizow> <FliltRestri ctionpo(w> - 30 - Si iqhtOne>23c/Vlighlone> c/ FliohtRestrictionP~ow> <F qltRPp-f-r ctionPow>, <Carrier>NZc/Carrier> <cPlisht0-ne> 27c</F'lig~htCnep> c/FlightResrriotionzow> cFlightRestrictionRow> cCarrier>tNZc/Carrier> <Flightone>SOO0c/Flighc~ne> cFlighzTwo>9999c/FlighcTw 0 > </FliqhtRestricctonRcw> cFliohcRestrietionRow> <Carrn er>NZ c/Carrier> <Pl iqhtC--e>4OO</IElighto~ne> <cPltghtau> 6 9 9<IF!ighTo> </Flightwestrictinzow> cFlightRestrictzionRo~w> cCarnier>NZc /Carnier> cF-1.ightTwo>S 9 9 9< /Flight'ywo> <c/FlightResunictiongow> cFliqhtRestri cionocw> <Carrier>NZ / Carrier> <Flighu One>BOC0c/Flig5htOne> ctli ghtTwc <>8SS9c/Flihj'wo> K /FlightResnLicinw> c/Fl ighteestriet ion> c/Cat 4flata-Tble> </Neaeiona iI rnc cator, c./sequence> <Seqiience> <Seq-lence~um bey>5</sPequencequwrber> cveare._fden>if ier WAMlY</pareldentif ie-r> <E el ationallIndicator> <And> false c/And> crat4DataTable> cFiiqhnRestriccioni> cValidity>Natvalidc/valJidiry> <Fiighttestrictio'nRcw> cCarrier>NZc /Cerrier:> - 31 - </FlightRestrictionRow> <FlightRestrictionRow> <Carrier>NZ</Carrier> <FlightOnes2</Flightone> </FlightRestrictionRow> </Fligh2taMeri cwion </Cat4DataTable> </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber>6</SequenceNumber> <FareIdentitie-r>TAMOW</FareIdentifier> <Relationallndicator> <And>falsec/And> <Cat4DataTable> <FlightRestriction> <Validity>NotValid</Validity> <FlightRestrictionRow> <Carrier>NZ</Carrier> < Flightone>6</Flightone> </FlightRestrictionRow> </FlightRestriction> c/Cat4DataTable> </ReIatio-nal indicator> </Sequence> <Sequence> <SequenceNumber>7< /Sequencember> C LocatiOne> < Type>C</Type> <Code>AKL</Code> </LocationOne> cLocationTwo> <Type>C< /Type> <Code>HNL</Cude> </LucationTwo> 7Fa r I dEanti- f ieruuIAMOW/FTredenifer> <NotApplicable/> c/Sequence> <Sequence> <SequenceNumber>8 < /Sequencelumber> -32 - <Relational Indicator> <And>falae</And> <Cat4DataTable> <Fli.ahtRestriction> <Validity>Valid</Validicy> <FlightRestrictionRcw> <Carrier>NZ</Carrier> <FlightOne>2< /Flighcone> </FlightReszrictionRcw> <FlightRestricticnRw> <Carrier>NZ</Carrier> <Flifgh:One>9000</Fliahtcre> <-Ii ghtTwoa,9 9 99 </PF light Two </FlightRestricto-Row,> <Fl ightRestrictionRow> <Carrier>NZ</Carrier> <FlightOne>400</ Flightone> <FlihsTwo>699</FlightTwo> </FlightRestrictionRow> <FlightRestricti onRow> <Carrier>NZ</Carrier> <Flightone>5000</FliogtOne> <FlijhtTwo>5999 </Fl, ightTwo> </FlightnestrictionRow> <FlightRestrictionRow> <Carrier>NZ</Carrier> <FlightOne>8000</lightcne> <PlightTwo>8999</Flightmwo, </FlightRestrictionRow> </FlightRescriction> </Cat4DataTablc> </Relationallndicator> </Sequence> </Catcegory> </Category4> <Categoryll> <Category> <Sequence> <SequenceNunber>le/SequenceNuner> <FareTdentifier>GTEST</Faredn- ti s - 33 - <Relationalrndicator> <CaCllDataTable> <FirstDate>o1ApRO5</FirstDate> CLastDate>15APR06</LastDate> <Directionality2>B</Directionality2> </CatilDataTable> </RelationalIndicator> <Relationalindicator> <Cat11DataTable> <FirstDate>04MAyo6</FirstDate> <LastDate>04MAY06<e/Last]Date> <Directionality2B</Directionalitv2> </Cat 1 lDataTable> </Relational Indicator> </Sequence> <Sequence> <SeguenceNuimer>2e/SequenceNumber <Fareldentifier>GTEST</FareIdentifier <JourneyType>RT</JourneyType> <RelationalIndicator> <CatllDataTable> <FirstDate>30APR06</FirstDate> <LastDate>30APR06</LastDate> <Directioniality2>B</Di-rectional ity2> </CatllDataTable> </Relational Indicatorm <Relational Indicator> <Cat11DataTable> <LastDate>O1JUNO6</LastDate> <Directionality2>o</Directloraltv> </Catl1Data1'able> c/RelationIal Indicator> <RelationalIndicator> <Cat11DaLaTable> <FirstDate>04JUNo6</FirslDate> <LastDate>04JUN06</bastDate> <Directional ity2>IC/Directionality2> </CatllDataTable> c/RelationalIndicator> - 34 c-CatllDataTable> <EtrstDate>1SJULOEC/pirstDate>, cLastDate>2scTUzosc/Lasc-Dace> cDireCr-iona lity2 >B</DirectionalIicy2 > c/CatjIpatarable> c/RPeIationalrnajCator> <Relational IndicatoDr>: cCatllData'Lable> <Firs: Date>O2AUGO06c/rirstnaue> cLastDace>OSAUGQ6c/Lastpace> <Direct ionality2 >0</DLirect ionality2> c/CatzTaaaable> </Relaticnllnaicator> <Relat ioDnalmodicat or> <CatllDataTable> <FiratDate>olSsposc/FjrstDate> -. Last-Date>DSSEPOG< /Lasppau-e> <cDi rect nn-raiity2 I -z/i3ccifa±±<Ii y2 < /Cati I.1LataTabie&> </Re la lural Indicator> </Sequence> <Sequence> <SequenceNun-ber >3 < /SequenceNumnber> <F'areldeit ifier>LAMOJ </Fareldenptifter> <Relaci onallndi cacr> <Cat llDaria'able> <Ei htocationj> <'Pyre> C</Ty-pe> <FligbcLocation2> <Ty-pe >C</Ty-pe> <a2ode>SFOc/Code> </Fl1cshtLocat-'cn2> <FirstDate>1MARO6/r'sspate> a LastDate>2lrARc6c/Lastna:re > </CatlIJDa'-Table> <Cat-IlDataTable> cFliarhtjc aticulj> <Code>AKL</Code> </FlightLocation1> <FlightLocation2> <Type >C</Type> <Code>SFO</Code> </FlightLocation2> <FirstDate>OIAPR06</PirstDate> <LastDate>12APR06</LasLDate> <Directionality2>0</Directionality2> c/Cat11DataTable> <CatilDataTable> <FlightLocation1> <Type>C</Type> <COde>AKL</Cods> </FlightLocation1> <Flightl-ocation2> <Type>C</Type> <Code>LAX</Code> </FlightLocation2> <FirstDaLe>l0MAR06</Fi rstDate> <LasLDate>14MAR06</LastDate> <Directionaliuy2 >O< /Directionality2> </Cat11DataTable> Cat lDatarabie> <FlightLocation> <Code>AKL</Code> </FlightLocationi> <FightLocaion2> <Type>C</Type> <Ccde>LAX</Code> </I'FlightLocation2> <FirstDate >17MAR06</FirsLate> <LastDate>20MAR06</LastDate> <Directionality2 >0</Direct ionality2> </CatllDataTable> <Cat11DacaTable> <FlightLocation1> <Type>C</Type> <Cade>AKL< /Code> - 36 - <PlightLQcatiOn2> cTyu)e>c</Type> <Code>LAXc/Coae> c/PlicghrLocat lan2> c1,irstDate>22MARo6</Fi-rstuate> <LaSt~ate>27ARo 6</LastDaze> <Direct ionalityD >Q</D~irecticonali'tv,2> </CatalData'2aule> <Catill-ataTable> cFiightLccacionI > <Type>C</Type> <Code>AKL</Cod . <c/Flight! ocau-ioni > <FTight-Loctioy- 2 > < ype>Cc/Type:: <Code>SFD</Code> c/FlighcLcatAon2> <FirsrDate>9MAjRQ 6</F-,irstoace>7 <LaszzDa~e >J4MAROS</LastDate> <Direct ionai.ity2>O</Direcctioia lityD> </Catliuataoable> <Cat tlfa tafabe> <F1iigbtLucaticril> <Ty-pe>C</Type> <Code>AKL</Code> < /FiqbtrLoca~L or±±> <YliyhtLocati en> <iType>c /Fy-pc-,> <Ciode>LAXc/Ccdc> c/Fl. ghrLecat ±=2 > <FirsrJ~ate>120EC0 5</ Firsct:)as?~> <LasuDarce>31JAN07 /Lestflata> <DlrectI on-ality2>rc/04 re .ta.lna2±ty2 > K/'CzA kA I U&Luariao e > <CatiioataTabie> cFligbtLocationa> <Type >Cc /Type> <Code >AKLc/Code> c</FlighotLocatilcnl> <Fligbtlocation2> - 37 - -typ=eu</lype> <Code>SFO</Code> </FiightLocation2> <FirstDate>09DEC06</Firstuate> <LastDate>28JAN07</LastDate> <Directionality2 >I</Directio-nality 2 > </CatliDataTable> <CatllDataTable> CFlightLocation1> <TVpe>C</Tvpe> <Code>AKL</Ccde> </FlightLocationl> <FlightLocation2> <TyDe>C< /Type> COde-LJAX< /code> </FlightLocation2> <FirstDate>30MAR06</FirstDate> <LastDate>4APR06</LastDate> <Dfirectionality2>O</Directionalitv2> </Cat11DataTable> </Relationalndicator> </Sequence> </Category> </Categoryll> <Categjory! 9> <Category> <Sequence> < SequenceNumber>l< /Sequence~umrber-> <FareIdentifirl>UAMTYc/FareIdentifier> <Rel ationalIndicatar> <Catl9DataTable> <PaxType >CNN</Paxvrype> <MinimumAge>2< /MinimumAge> <MaxiimuiAge> 2< /MaximumAge> <Amount Amoun'c="425' ur yd NZD"/ </Cat19DataTable> <Cat19DataTable> <PaxType>INF</PaxType> <Minimutmege>0<c/MinimnumAge> <Maxim-mAge>0</MaximumAge> <Amour Amount--25r Ctarnycue="Nzu / - 38 - </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber>2 </SequenceNumber> <FareIdentifier>DAM1Y</paredertifier> <RelationalIndicator> <Cat19DataTable> CPaxType>INF</PaxType> <MinimumAqe>0< /MinimujAge> <MaximnuraAge>O< /MaximumAge> <Discount>0.1</Discount> </Cat19DataTable> <Cat19DataTable> <PaxType>CNN</PaxType> <Minimum-Age>2 < /MinimumAge> <MaximumAge >2< /MaximumAge> -Dicount>C .67c/Discunc> </Cat19DataTable> </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber>3< /Sequenceumber> <KareIdentifJer>AMlY</F'aresdentifier> <Relational Inldicator> <Cat19DataTable> <PaxType>CNNC/PaxType> <MinimumAge >2< /MinimurnAge> <Max imumkge>2< / MaximumAge> <Discount>0.75</Discount> </Cats9DataTable> <Catl9DataTable> < PaxType>INFC /PaxType> <MinimumAge>0</MinimuimrAge> <MaximumAge >0</Ma ximuinAge> <Discount>0. 2</Discount> </Catl 9DataTable> </Relationalsndicator> </Sequence> <Sequence> <SequenceNumber>4</SecuenceNumber> - 39 - CRelationalIndicator>, <Cat19DataTable> <PaxType>INF</PaxType> <MinimumAge>O</MinimumAge> <MaximumAge>0</MaximumAge> <Discount>0.15</Discount> </Cat19DataTable> <Cat19DataTable> <PaxType>CNN</PaxType> <MinimumnAge >2< /MinimumAge> <MaximumAge>2</Maximumkge> <Discount>0.65</Discount> </Catl9DataTable> c/RelationalIndicator> c/Sequence> <Sequence> <SequenceNumber>5</SequenceNumber> <FareIdentifier>EAMY</FareIdentifier> <RelaTionalIndicator> <Cat19DataTable> PawType>Ccc/pcxType> <MinimumAge>2</MinimumAge> <MaximumAge>2</MaximumAge> <Discount>0. 8</Discount> c/Cat19DataTable> <Catl9DataTable> <PaxType>INF</PaxType> <MinimumAge>0</MinimumAge> <MaximumAge>0</MaximumAge> <AmontrAmount="195 CurrencyCcde="NZD c/Catl9DataTable> </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber>6</SequenceNumber> <Fareidentifier>VAMIY</Farevdentifier> <Relationallndicator> <Cat19DataTable> <PaxType>INF</PaxType> <MfinimumIrAge>0<l/MinimumAge> -40 - <Discount>0. 05</Discount> </Cat19DataTable> <Catl9DataTable> <PaxType>CNN</PaxType> <MinimumAge>2</Minimumge > <MaxinumAge>2< /MaximumAge> <Discount>l< /Di scournt> </Catl9DataTable> </Relationallndicator> </Sequence> <Sequence> <SequenceNumber>7 </SequenceNumber> <Fareldentifier>TAMlY< /FareIdentifier> <Relationallndicator> <Cat19DataTable> <PaxType>CNN</PaxType> <MinimumAge>2 </MinimuAge> <MaximumAge >2< /MaxirmumAqe> <Discount>O.5</Discount> c/Cat19DataTable> <Cati9Datal'able> <PaxType>INF</PaxType> <M i4numArs> /MinimumAge> <MaximmAge>o< /Maximu-mAge> <Discount>0.25</Discounc> </Cat19D)atamable> </Re lat ional TIdi c at r> K/Sequence> <Sequience> <SequenceNuTer>8< /SequenceNumber> <Far eIdentif ier>BAM1YCl/FareIdentitfier> <Relationallndicator> <Cat19DataTable> <LastTravelDate>31TMARO6</LastTravelDate> <PaxType>CNN</PaxType> <MI'inimurLAge>2</MinimumAgeo> <MaximumAge>2 </MaximumAge > <Discount>0.75K/Discount> </Cat1.9DataTable> <Cat 19Data'able> -41 - <PaxType >INFC/PaxTyps> <MinimnurnAge>o </MinoimurrAge> <MaximumAge >Qc/MaximuwrAge> <Di scount>O. ic/Discount> c/Cati;DataTable. </Relational -naicatcr> <Reiatio-nalindicator> cCratl9PataTable> <7irsrTrav-eiDate>OlAPRC Ec/P -rsLTravelat Le> <tastTravelDate>30PO/Lsraeat > c PoxType z'CNN<c/PaxType <Amount Acr~27UCirny~~ </Cfli9Datarnable> <Catl900t-aTabie> <cFirstTraveDte>1APROG</Fi±sTraej) KLastT'raxrellate>3 OAPROSC/LastTravelDate> <PaxType >INFc /Paxmype> <JdlflffLkrge > 0< / Vi-Ii mUMAqei> <Maximunmjcgep c/MaximuwAge> </at] 3 Da ta Dab] c/e az nnal1 Idicator7> <Reatrionaziinjic 3 tox> <COO l9DateTaLle> cFirsc':'raven-Pae>olMAY0/iritTrvlae <PaxType>cN< /PaxType> cMiinimrniAcje->2<c/Mqir-mumrge> <Maxi mo-m.Age>2< /Maximw umAye> <Disccunt>0.

7 </Discount> cL/Cat 2 DauTabie> <C7at 9Daal'ji> <Firs LTraVe1%Tte >OWMAYOG</Pi]2StTravaelDate <PaxType >INFc /PaxType> cMintimumAge>o< /MinimiumAge> <PlaximumAqe>O<c/Maximumzaqe> <ciscouno>o 2 3 c/Discount> </CatISDataTable0> - 42 - <Sequence> <SequenceNumber>9</SequenceNumber> <FareIdentifier>CAMOW</Farerdentifier> <RelationalIndicator> <Catl9DataTable> <PaxType>INF</PaxType> <MinimumAge >0< /MinimunAge> <MaximumAge > 0< /MaximumAge> <Discount>0.15</Discount> </Catl9DataTable> <Cat19DataTable> <PaxType>CNN</PaxTvpe> <MinimurnAge>2</MinimumAge> <MaximunAge>2 < /MaximumAge > <Discount>0.6</Discount> </Catl9DataTable> </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber> 10< / SequencePu-mber> <FareIdentifier>WAMOW</FareIdentif ier> <Relat-ionalIndicator> <Ca-19Datayable> <PiaxType>CNN</PaxTyee> <MinimumnAge >2< /Mi na mumAge> <MaximfumAge >2< /KMaxinmukge y <Discount>0.9</Discount> </Cat1.9DataTable> <Cat19DataTabley <PaxType>INF</PaxType> <MininuuAge>0o</MinimumAqe> <MaximumAge>0 </MaximumAge> <Discount>0.4</Discount> </Cat129DataTable> </ReiationalIndicator> c/Sequence> <Sequence> <SequenceNumnber>12</SequenceNumber> <Locat ionOne> <Type>c</Type> -43 c/Locae-ionone> cLocacionwwo> cType>N</Type> c/LoeacioiTwc> cF'areIdentifier>GTEsT< /Fareidentitier-. <Re!lat iona' Tjdi Cator> cCatl9DataTable> cDirecttanalityl>3c/sireczio~naiityi>: <PaX'TYPe>CNN< /PaxType-> <MirliumAge >2< /Mi ninumAge> c'4axirnuraege> 2< /MaximumnrrLoe> cDisccunt>O. Bc/Discount> </Cat l9Datarable> <Catl9Da!t-aTabne> <13irecc ionaieYLI-3c/sj.rscc iona1±c yi > cPaxType>INFc/Faxwy-pe> <MifamurnAge>oc /Minimum~ge> cMaximumAge>oc/:a4xnmuvge> <Disccunt>O. 2 </Discount> c/Catl9Dau-aTsble> </Relac innaiIndi cater> cPelIet ionall -di cato(.r> <Cati9flarawabie> cC irecticdnai ityI>4</'irecticnaleyJ_> <ParTyne >CNN</P XT-ype> cMininurL7ge->2 c/Mi ntimt,-rnAqe> <M,'axirnuirso 5>2< /MaximurrAga> cCatiDazaable> <Pa'-xiype->INF< /Paxrype> <Min imuzriAge >o / Mio irnuAge > < "MaximkumlAq >0< /MsxtrnuraAqe> <DisCoun:>O, 15c/Discoijint> c/CauiSDacaTabie> </Reiationalrnaicauur>, c/Sequence> <Sequence> - 44 - <LocationOns> <Type>N</Type> <Code>NZc/Oode> c/L~ocation(Dne> cLOCationrnwo> cType>Wc/Type> cCode>usc/Code> S/LocaticnTwo. cFareldentiffier>GTEST< /ParfeIderiifiers <Relationall 7 ,dicator> <Catl9oatayab3]e, cDilrelt ionalic LV>s</Directionalityl > <PaxType >CNFc/ PaxType> < MinirnumAqe >2c </Minirnumzge> <ilaxiMuvnAge>2 c /Maximu,,mAge > <Discouft>. 65c/Disco)untc> c/Ca'-19DataTaL-ie> <Catl9Datalable> <DirectionaL icy) >3</DirectiOn alicya> K PaxType>TNF</ PaxType> <Plinim'anA3el 01 /MinimurnAge > <-MaxiURnunge >0< /MaxirunAge > <is~cuint>Q. 1 5 c/is(Cunt> </CatlIPDa'tarnble > 'RelaiinaJ Indicator> </Sequence> <sen-ce> <Fareldenti fiter>QA~dlYc/Farelaeiitit iel. <flei] a: iOnalindicaor> <CatI9DataIable> <FaxwType >INF< /PaxTyce> <Max imuamAge>Cc/MsximuampAe> < Discour>O.1<,/oiscoullu> c/Carisuataaaphe> <Caul9Datarable> cPaxType>CNw</ PoxType> c<fMaxirnmAge>2 </Maxi mumplge>, -. 45- </Cat19DataTable> </RelationalIndicator> </Sequence> <Sequence> <SequenceNumber>15</SequenceNumber> CFareIdentifier>YAl41Y</FareIdentifier> <Relationalindicator> <Cat19DataTable> <PaxType>CNN</PaxType> >Minimumagoe 2 -/MinimnumtgQ> <MaximumAge>2< /MaximumAge> <Discount>0.75</Discount> </Catl9DataTable> <Catl9DataTable> <PaxType>INFC/PaxType> <MinimumAge>0 </MinimurAge> <Max iumAge>0</MaximurAge> <Discount>0.3</Disccunt> </Cat1 9DataTable> </Relationallndicator> </Sequence> <Sequence> <SequenceNumber>l6<c/SequenceNumber> <Fareidentif ier>VAMOW</FareIdentifier> <Relat ionialIndicator> CCat19DataTable> <PaxType>INF</PaxType> <Minimumtge>O</MinimumnAge> <MaximrumAge>O< /MaxirmumAge> <Discount>0. l<C/Discount> </Ca t 19DaraTable> <CatI9Data Table> <PaxType>CNN</PaxType> <MinimunAge>2</MinimumAqe> <MEximumAge>2</MaximumAge> -DivcountO - . 9/Discount> </Cat19DataTable> </RelationalIndicator> </Sequence> </Category> -46 - <Rela: innal Indicator> <C'atl9DataTabie> cPax~rype>INF< /PaxType> cMtn-imumE g>0O<7Mjnjimn~qg> clvaximumAge>GOc/Maximumkge> cDisco~unzz>O.mc</D~sc 000 2,t> c/CatSDatamabIe> <Cam l9DataTab)le> c PaxT-vpe >CNNc/ PaxTyne> <MininurnAye >2< /Minmvr ,rAge> cYjaxiruAe> /axmno> <Discounjt>O 75</Discount> </Catw9DaraTabie> c/Relational1 TnrV li r </CateqorvAsslrnption> c/Cateooryli> </FareRuie> c/Change> <BPatch> chRQ> -47 - APPENDIX B Fare Rule (FareTariffld= IPRP, RueId= TCAT19) import nz.coairn2.isquote.nnging rammnmaai. import nz.co.airnz.isquote.engine.farerules.*: import nz.co.airnz.isquote.engine.farertiles.catll.*; import nz.co.airnz.isquote.engine-farerules.cat19.*; import nz.co.airnz.isquote.engine.farerules.cat.*; public class FareRulePreview { public boolean runRule (JourneyInfo journey, ConstructedFare constructedFare, JourneyOption journeyOption, RuleState ruleState) CateaoryState categoryState = ruleState.getCategory11(); if ((!categoryState.isCodedCategory() && (!cateyoryState-isNotApplicable())) categoryState.setCodedCategory(true); if (Sequencesnacches (categoryState, journey, constructedFare, null, null, null., null, 'GTEST", Fare.,FT_ONU_WAY)) boolean sequencePassed = false; if (!acncDnscI) categoryState.setLocalRelevantindicator(false); if (Categoryll~validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, null, journeyoption, 401APROG", '15APR06", categoryState, false)) if (categoryStateisLocalRelevantlIndicator() sequencePassed = true; -48- I if (Isequencepassed) { categoryStee.setLocalRelevantIndicator(false); if (Cateqoryll.validatejcurnpy, null, null, null, null, null, null, null, null, null, null, null, null, null, null, journeyoption, "4MAYO6", "C4MAYOG", categoryState, false)) if (categoryState.isLocalRelevantlndicator() sequencePassed = true; } it (sequencePassed && categoryState,isRelevantTables()) return false; } else if (Sequence-matches(categorystate, journey, constructedFare, null, null, null, null, "GTEST", Fare-FT RETURN)) { boolean sequencePassed = false; if (sequencePassed) { categoryState.setccalRelevantlndicator(false); if (Categoryll.validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, null, journeyoption, "30APRCG, 030APR06", categoryState, false)) if ( sequencePassed = true; } if (!sequencePassed) -49categoryState.setLocalRel evantIndicator(false); if (Categoryll.validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, Directionality.DIR OUTBOUND, journeyOption, "01JUN06", 101JUN06", categoryState, false)) it (categorystate.isLocalRelevantIndicator() sequencePassed = true; if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Categoryll-validate(journey, null, null, null, null, null, null, null, nul, null, nail, null, null, null, Directionality.DIRINBOUND, journey ption, "4JUN06", "04JUN05", categoryState, false)) if (categoryState.isLocalRelevantlIndicator() sequencePassed = true; } it (!sequencePassed) categoryState.setlocalRelevantIndicator(false); if (Categoryll-validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, null, journeyOptlon, '5JUL06", "29JUL06" , categoryftate, false)) if (categoryStateisLocallelevantlndicator()) sequencePassed = true; -50 - } if (!sequencePassed){ categoryState.setLocalRelevantIndicator (false); if (Categoryll.validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, Directionality.DIROUTBOUND, journevOption, '02AUG06", "09AUG06", categoryState, false)) if (categoryState-isLocalRelevantndicator()) sequencePassed = true; if (!sequencePassed) categoryStata-setLocaleIevantIndicator(false) if (Categoryll.validate(journey, null, null, null, null, null, null, null, null, null, null, null, null, null, Directlionality.DIRINBOUND, journeyOption, "O1SSPOG", "ISSEPOG6, categoryState, false)) if (categoryState.isLocalRelevantIndicator() sequencePassed = true; } if (sequencePassed && categorystase.isRelevantTabes( return false; else if (Sequence.matcihes (categoryStace, journey, constructedFare, null, null, null, null, "LAM3" null)) -51 boolean sequencePassed = false; if (!sequencePassed) { categoryState-setLocalRelevantndicator(false), if (Categoryll.validate(journey, null, null, null, null, "C", 'AKL", "'c, "320", null, null, null, null, null, Directionality.DIROUTBOUND, journeyOption, "18MAR06", "21MAR06", categoryState, false) Categoryll.validate (journey, null, null, null, null, "C", "AKL", "C", "SFO", null, null, null, null, null, Directionality.DIR_OUTBoUND, journeyOption, "01APR06", "12APR06", cateqoryState, false) Categoryll-validate'journey, null, null, null, null, "C", "AKL" , "C", "LAX", null, null, null, null, null, Directionality.DIR OUTBOUND, journeyoption, "lOMAROC", "iW4MAkO", -aLegoryscare, false) Categoryll-validate(journey, null, null, null, null, "C", "AKL", "C', "LAX', null, null, null, null, null, Directionality.DIROUTBOUND, journeyOption "17MARO6", "20MAR06", categoryState, false) Categoryll.validate(journey, null, null, null, nul , "C", "C" , "LAX", null, null, null, null, null, Directionality. DIR OUTBOUND, journeyOption "22MAR06", "27MAR06", categoryState, false) Category1I1validace (journey, null, null, null, null, "C", "AKL", " ", "SF0", null, null, null, null, null, Directionality.DIROUTBOUND, journeyOption, "09MAR06", "14MAR06, categoryState, false) Categoryllvalidate (journey, null, null, null, null, "C", 'AKL", HC , "LAX", null, null, - 52 null, null, null, Directionality.DIRINBOUND, journeyOption, "12DEC06", "31JAN07", categoryState, false) Categoryll.validate(journey, null, null, null, null, "C", "AKL", "C", "SFO", null, null, null, null, null, Directionality.DIR INBOUND, journeyOption, "09DEC06", "28JAN07", categoryState, false) Categoryll.validate(journey, null, null, null, null, "C", "AKL', "C", "LAX", null, null, null, null, null, Directionality.DIR_OUTBOUND, journeyOption, "301MAR06", "C4APROG", category0tate, false) { if (categoryState-isLocalRelevantlndicator ()) sequencePassed = true; if (sequencePassed && categoryState.isRelevantTables() { return false; CategoryState categoryState = ruleState.getCategory19()T if ((!categoryState.isCodedCategory()) && (!categoryState.isNotApplicable )) categoryState-setCodedCategory(true); if (Seguencematches (categoryState, journey, constructedrare, null, null, null, null, "DAlY", null)) boolean sequencePassed = false; - 53 if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PTCHILD, 2, 2, "N", null, '425", "NZD", null, categorvState, false) Categoryl9.validate (journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT INFANT, C, 0, 'N", null, '225', "NZD", null, categoryState, false)) if (categoryState.isLocalRelevantIidicator() sequencePassed = true; } ) else if (Sequencernatches(categoryState, journey, constructedFare, null, null, null, null, 'DAM1Y", null)) { boolean sequencePassed = false; if (IsequencePassed) { categoryState.setLocalRelevantlndicator(false); if (Categoryl9.validate(journey, null, null, null, null, null, null, null, null, null, Journeylnfo.PT INFANT, 0, 0, "x'N, ".1", null, null, null, categoryState, false) Category19.validate (journey, null, null, null, null, null, null, null, null, null, JourneyInfo,PT C-TLD, 2, 2, "N'", " .7" null, null, null, categoryState, false)) if (categoryState.isLocalRelevantlndicatorc()) sequencePassed = true; } - 54 else if (Sequence.matches(categoryState, journey, constructedFare, null, null, null, null, "HAflY" null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantlndicaror(false); if (Categoryl9.validate(journey, null, null, null, null, null, null, null, null, null, Journeyinfo.PT CHILD, 2, 2, "N", "0.75 null, null, null, categoryState, false) Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT_INFANT, 0, 0, "N", "0.2', null, null, null, categoryState, false)) if (categoryState.isLocalRelevantIndicator()) sequencePassed = true; } else if (Scqucncc.ratchos (categorystate, journey, constructedFare, null, null,ll, l, null, "MAMilY" null)) boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, null, null, null, null, null, Journeylnfo.PTINFANT, 0, 0, "N", "0.15", null, null, null, categoryState, false) Categuryl9.validate (journey, null, null, null, null, null, null, null, null, null, Journeylnfo.PT CHILD, 2, 2, 'N", '0.65", null, null, null, categoryState, false)) -55 if (categoryStatelisLocalRelevartIndicator() sequencePassed = true; } else if (Sequence.matches(categoryState, journey, constructedFare, null, null, null, null, "EAMlY", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalpelevantindicator (false) if (Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT CHILD, 2, 2, "N", '0.9", null, null, nul, categoryState, false) J| Category19lvalidate(journey, null, null, null, null, null, null, null, null, null, Journeyinfo-PTINFANT, 0, 0, "N", null, "195", "NZD", null, categoryState, false)) if (categoryEJtae.iaocalRlevnoudicaLor()) sequencePassed = true; } else if (Sequence-matches(categorySrate, journey, constructedgare, null, null, null, null, "VAMiY", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevancindicator(false); if (Categoryl9.validate (journey, null, null, null, null, null, null, null, null, null, JourneyInto.PT INFANT, 0, 0, "N', "0 . -56 null, nill null, categorystate, faloc) J Categoryl9.vaiidate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PTCHILD, 2, 2, "Nu, P"", null, null, null, categoryState, false)) { if (categoryState.isLocalRelevantIndicator() sequencePassed = true; else if (Sequence.matches(categoryState, journey, constructedFare, null, null, null, null, "TAMlY", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT_CHILD, 2, 2, "N", "0.5", null, null, null, categoryState, false) Category19.validate (journey, null, null, null, null, null, null, null, null, null, JOuLJtEU.FT_INFANT, D, U, "N", "0_25", null, null, null, categoryState, false)) if (categoryState.isLocalRelevantmndicator()) sequencePassed = true; } } else if (Sequence.matches(categoryState, journey, constructedFare, null, null, null, null, "BAMlY", null)) { boolean sequencePassed = false; if (!sequencePassed) -57 categoryState.setLocalRelevant Indicator(false); if (Categoryl.validate(journey, null, null, null, "31MAR06", null, null, null, null, null, Journeylnfo.PTCHILD, 2, 2, "N', "0.75", null, null, null, categoryState, false) Categoryl.validate(journey, null, null, null, "31lAR06", null, null, null, null, null, Journeylnfo.PTINFANT, 0, 0, "N", "0.1", null, null, null, categoryState, false)) if (categorvState.isLocalRelevantIndicator() sequencePassed = true; if (HsequencePassed) categoryState.setLocalRelevantIndicator(false); if (Categoryl9.validate(journey, null, null, '01APR06", "30APROG, null, null, null, null, null, JourneyInfo.PT_CHILD, 2, 2, "N", null, "217", null, categoryState, false) Categoryl9.validate(journey, null, null, "01APR06", "30APR06", null, null, null, null, null, .ourneynfo.DT INFANT, 0, 0, "N, 1", null, null, null, categoryState false)) if (categoryState.isLocalRelevanIuldicator() sequencePassed = true; if (UsequoncePassed) categoryState.setLocalRele-vrantIndicator(false); -58 if (Categoryl.vaalidate(journey, null, null, "01MAY06", null, null, null, null, null, null, Journeylnfo.PTCHILD, 2, 2, "N", 'o_7n1, null, null, null, categorystate, false) Category19.validate :journey, null, null, "01MAY06", null, null, null, null, null, null, JourneyInfo.PT_INFANT, 0, 0, "N", "0-154, null, null, null, categoryState, false)) { if (categoryState.isLocalRelevantIndicator()) sequencePassed = true; } } else if (Sequence-matches(categoryState, journey, constructedFare, null, null, null, null, "CAMOW", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantlndicator(false); if (Categoryl9.validate (journey, null., null, null, null, null, null, null, null, null, JourneyInfo . PTINFANT, 0, 0, "N", a0 .15 " null., null, null, categorysta-e, false) Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo. PT CHILD, 2, 2, "N' - "( n" null, null, null, categorystate, false)) if (categoryState-isLocalRelevantxndicator()) sequencePassed = true; 1 else if (Sequence.matcies(categoryState, journey, constructedFare, null, null, null, null, "WAMOW", - 59 null)) { boolean sequencePassed = false; if (!seauencePassed) ( categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, null, null, null, mul. nulI Journeyrnfo.PT CHIIZD, 2, 2, "N", "0.9", null, null, null, categoryState, false) Category19. validate (journey, null, null, null, null, null, null, null, null, null, JourneyInfn.PT INFANT, 0, 0, "N", "04" null, null, null, categoryState, false)) if (categoryState.isLocalRelevantIndicator() sequencePassed = true; else if (Sequence.matches(categorystate, journey, consrructedFare, "C", "SFO", "N", "NZ", 'GTEST", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, "C", "SFO1, ',", "NZ", Directionality.DIR ORIGIN LOC1, JourneyInfo,.PTCHILD, 2, 2, "N", 0.8" null, null, null, categorystate, false) | Category19.validate(journey, null, null, null, null, "C", "S 0, "N", "NZ", Directionality.R_ORIGIN LOCI, Journeylnfo. PT_INFANT, 0, 0, "N", "0. 2", null, null, null, categoryState, false)) -60 if (categoryState.isoocalRelevantIndicator() sequencePassed = true; } if (!sequencePassed) { categorState-setLocalRelevantIndicator(false); if (Category19.validate (journey, null, null, null, null, C, " " "NZ" Ulrectionality.DIRORIGINLOC2, JourneyInfo.PT_CHILD, 2, 2, 'N", "0.65", null, null, null, categoryState, false) | Categoryl9.validate (journey, null, null, null, null, "C", "S8FO"!, "N", "-NZ"I Directionality.DIp_ORIGIN_LOC2, Journeylnfo.PTINFANT, 0, 0, "N1, "0.13, null, null, null, categoryState, false)) if (categoryState.isLocalRelevantIndicator) sequencePassed = true; else if (Sequence.natchestcategoryState, journey, constructedYare, "N", "NZ", "N", "US", "GTEST", null)) boolean seauencePassed = false; if (IsequencePassed) { categorytate-setLocalRelevJantndicator(falte); if (Categoryl9.vaalidate(journey, null, null, null, null, "N" , "NZ" , "N, "US", Directionality.DIR ORIGIN_LOC1, Journeylnfo.PT CHITLD, 2, 2, "N", "0.65", null, null, null, categoryState, false) Category19. validate (journey, null, null, null, - 61 null, "N", NZ", "N", "US", Directionality.DIRORIGINLOCl, JourneyInfo.PT INFANT, 0, 0, "N", "0,15", null, null, null, categaryState, false)) if (categoryState.isLocalRelevantxndicator() sequencePassed = true; } else if (Sequence-matches(categoryState, journey, constructedFare, null, null, null, null, "QAMlY". null)) boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantindicator(false); if (Category9.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT_INFANT, 0, 0, "N", ",l", null, null, null, categoryState, false) Cacegoryl9.validate(journey, null, null, null, null, null, null, null, null, null, JourneyTnfo.PT_ChILD, 2, 2, "N", "0.9", null, null, null, categoryState, false)) if (categoryState.isLocalRelevantindicator()) { sequencePassed = true; } else if (Sequence.matches(categorystate, journey, constructedFare, null, null, null, null, "YAMlY", null)) ( boolean sequencePassed = false; if (IsequencePassed) categorytate-ctLocalnclevantlndicator falie); -62 if (Categoryl9.validate (journey, null, null, null, null, null, null, null, null, null, Journeylnfo.PT_CHILD, 2, 2, "N", "0.75", null, null, null, categoryState, false) Category19.validate(journey, null, null, null null, null, null, null, null, null, JourneyInfo.PT INFANT, 0, 0, 'N", "0.3" null, null, null, categoryState, false)) { if (categoryState-isLocalRelevantindicator()) { sequencePassed = true; }uelse ir wequence.matcnes(categoryState, journey, constructedFare, null, null, null, null, "VAMOW", null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category19.validate(journey, null, null, null, null, null, null, null, null, null, Journeyinfo- PT INFANT, 0, C, "N", "'.1", null, null, null, catecryState, false) Category19.validate(journey, null, null, null, null, null, null, null., null, null, Journeynfo.PT_CHILD, 2, 2, 'N", 10.8", null, null, null, catecryState, false)) if (categoryState.isLocalRelevantIndicator() sequencePassed = true; } - 63 if (!categoryState.isRelevantTables() boolean sequencePassed = false; if (!sequencePassed) { categoryState.serLocalRelevantIndicator(false); if (Category1 validate (journey, null, null, null, null, null, null, null, null, null, JourneyInfo. PT INFANT, 0, 0, "N", "0.1", nuli, null, null, categoryState, false) j Category19.validate(journey, null, null, null, null, null, null, null, null, null, JourneyInfo.PT_CHILD, 2, 2, 'N", "0.75", null, null, null, categoryState, false)) { if (categoryState.isLocalRelevantIndicatoro) ULLe CategoryState caregoryState = ruleState.getCategory4() if ((!categoryState.isodedCategory()) && (icategoryStateliszNotApplicable()) categoryState-setCodedCategory(true); if (Sequence.matches(categorystate, journey, constructedbare, "C", "AKL", "C"', "HNL", '"HYF", null)) categoryState.setNotApplicable(true); } else if (Sequence.matches(categoryState, journey, constructeduare, null, null, null, null, "FFN1Y" null)) { boolean sequencePassed = false; - 64 if (!seauencePassed) { categoryState.setLocalRelevantIndicator(false); if (Category4.validate (journey, journeyOption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, srue, FlightRestriction-VALID, new FlightRestriction[] { new FlighRestriction("NZ", new Integer("5"), new Integer("6")), new FlightRestriction("NZ", new Integer("9000"), new Integer(".9999')), new FlightRestriction("NZ" new lnteger(1400"), new Integer("699")), new FlightRestriction(NZ", new Integer("5000"), new Integer("5999')), nnw PlirhtRestriction(NZ" new Integer("8000"), new Integer("8999)), }, false, null, categoryState, false)) if (categoryState-isLocalkelevantIndicator(h) sequencePassed - true if ((!sequencePassed) && categoryState.isRelevantTables) return false; else if (Sequence-matches(cazegoryState, journey, constructedFare, null, null, null, null, "WFNlY, null)) ( - 65boolean sequencePassed = false; if (!seauencePassed) ; categoryState~se LocalRelevantjndicator(false); if (Category4.validate(journey, journeyoption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, true, FlightRestriction-VALID, new FlightRestriction[l ( new FlightRestriction("NZ, new Integer("1"), null), new FlightRestriction('NZ", new Integer("2"), null), new FlightRestriction ("Z" new Integer("9000"), new Integer("9999")), new PlightRestriction("Z"u new Integer("400"), new Integer("699")), new FlightRestriction("NZ" new Integer("000), new Integer("599), new FlightRestriction("NZ", new Integer('8000), new integer('8999")), }, falon, null, cateJOrLySLSLe, false) if (catecoryState.isLocalRelevant Indica tor()) sequencePassed = true; if ((!sequencePassed) && categoryScate.isRelevantTableso) return false; -6Belse if (Sequence.matches(cateoaryState, journey, constructedFare, null, null, null, null, ,DFNIy, null)) { boolean sequencePassed = false; if (!sequencePassed) { categoryState.setLocalRelevantlndicator(false); if (Category4. val(aejourney, journeyOption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, true, FlightRestriction.VALID, new FlightRestriction[] ( new FlightRestriction("NZ", new Integer("6'), null), new FlightRestriction(NZ", new Integer("1"), null), new FlightRestriction("NZO, new Integer("5"), null), new FlightRestrict ion("Z', new Integer("21"), null), new FlightRestriction ("NZ", new Integer("23"), null;, new FlightRestriction("NZ" new Integer("27"), null), new FlightRestriction("NZ", new Integer("9000"), new Integer("9999f)), new FlightRestriction ("NZ", new Tnteger("400"), new integer("699")) now Flightnestrictin" new Inteqer("5000"), new Integer("B999)), new FliqhtRestriction("NZ" new Integer("8000"), - 67 new Inteqer("8999)), f }, false, null, categoryState, false)) { if (categoryState.isLocalRele)vantlndicator() sequencePassed = true; } if ((IsequencePassed) && categoryState.isRelevantTables()) { return false; } else if (Sequence.matches(categoryState, journey, constructe-dPr, null, null, null, null, "WATIPy null)) { boolean sequencePassed = false; if (IsequencePassed) { categoryState-setLocalRelevantIndicator(false); if (Category4-validate(lourney, journeyoption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, true, PlightRestrict ion.NOT VALID, new FlightRestriction[}i new Flightfestriction("N12, new lnteger('"1), null), new FlightRestriction ('INZ", new Integer("2"), null), }, false, null, categorystate, false) if (categoryState-isLocalRelevantlndicacor()) sequencePassed = true; } if ((!UsequencePassed) && categoryState.isRelevantTables())( -68 return false; else if (Sequence.matches(categorystate, journey, constructedFare, null, null, null, null, "TAMOW" null)) { boolean sequencePassed = false; if (!sequencePassed) categorvState.setLocalRelevantindicator(false); if (Category4.validate~journey, journeyoption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, true, FlightRestricticn.NOT_VAID new FlightRestrirrin(J new FlightRestriction("NZ", new Integer('6"), null), }, false, null, categoryState, false)) if (categoryState.isLocalRelevantIndicator()) sequencePassed = true; if ((IsequencePassed) && categoryState.isRfelevantTables() return false; else if (Sequence.matches(categoryState, journey, constructedFare, "C", "AT,""," "HNL", "HAMOW" null)) { categoryState~setNotApplicable(true); else if (Sequence.matches(categorystate, journey, constructedP'are, null, null, null, null, "HArMoWI, null)) { boolean sequencePassed = false; -69 if (lsequencePassed) { categoryState~setLocalRelevantlndicator(false); if (Category4.validate(journey, journeyOption, null, null, null, null, null, null, null, null, null, false, null, null, null, null, null, null, false, null, null, null, false, null, null, true, FlightRestriction.VALID, new FlightRestriction[] { new FlightRestriction("NZ", new Integer('2"), null), new FlightRestriction'NZ"1 new integer("9000 ), new Integer('9999")), new FlightRestriction("NZ, new Integer("400"), new Inteqer("699")), new FlightRestriction("NZ" new Integer("5000"), now Integer(I"so99 ) new FlightRestriction("NZ new Integer(2BO") new Integer("8999") }, false, null, categoryState, false)) { if (categoryState.isLocalRelevantrndicator() sequencePassed = true; if ((!sequencePassed) && categoryState.isRelevantTables()) return false; -70 return true; - 71 -

Claims (13)

1. A method of providing sundry costs to a user operating a booking system comprising: receiving input, from a user interface on a user computer, specifying journey criteria 5 for a desired journey, on a computer system, identifying candidate fares satisfying the journey criteria from one or more databases containing fare information, the candidate fares being associated with the journey, 10 generating and returning information to the user interface to display candidate fares on a fare construction presentation page, receiving input, from a user interface, selecting a candidate fare, calculating sundry costs for the selected candidate fare from sundry costs data retrieved from a database, and 15 generating and returning information via an asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction presentation page.

2. A method according to claim 1 wherein the fares are displayed on a first sub-portion 20 of the user interface, and the sundry costs are displayed on a second sub-portion of the user interface.

3. A method according to one of claims 1 or 2 wherein the sundry costs can be one or more of taxes, levies and surcharges. 25

4. A method according to any one of claim 1 to 3 wherein the method further comprises the step of displaying a total journey price comprising the selected candidate fare for the journey and the displayed sundry costs for the selected candidate fare. 30

5. A method of providing sundry costs to a user operating a booking system comprising: receiving input, from a user interface on a user computer, specifying journey criteria for a desired journey, 73 on a computer system, identifying candidate fares satisfying the journey criteria from one or more databases containing fare information, the fares being associated with the journey, calculating sundry costs for one of the candidate fares from sundry costs data 5 retrieved from a database, generating and returning information to the user interface to display sundry costs for the candidate fare, and candidate fares on a fare construction presentation page, receiving input, from a user interface, selecting another candidate fare, calculating sundry costs for the selected candidate fare from sundry costs data 10 retrieved from the database, and generating and returning information via an asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction presentation page. 15

6. A booking system that provides sundry costs to a user comprising: one or more databases containing fare information and data for calculating sundry costs, a computer system with an asynchronous transfer engine adapted to: receive journey criteria from a user interface for a desired journey, 20 identify candidate fares satisfying the journey criteria received from the user, the candidate fares being associated with the journey, generate and return information to the user interface to display the candidate fares on a fare construction presentation page, receive input, from a user interface, selecting a candidate fare, 25 calculate sundry costs for the candidate fare from sundry costs data retrieved from a database, and generate and return information via the asynchronous transfer engine to the user interface to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction page. 30 74

7. A system according to claim 6 wherein the fares are displayed on a first sub-portion of the user interface, and the sundry costs are displayed on a second sub-portion of the user interface. 5

8. A booking system according to one of claims 6 or 7 wherein the sundry costs can be one or more of taxes, levies and surcharges.

9. A booking system according to any one of claim 6 to 8 wherein the user interface is further adapted to display a total journey price comprising the selected candidate fare for the 10 journey and the displayed sundry costs for that journey.

10. A booking system according to any one of claims 6 to 9 wherein when displaying the sundry costs for the journey on the second sub-portion of the user interface, the user interface is further adapted to update the user interface to display a total journey price comprising the 15 selected fare associated with a selected journey and the displayed sundry costs for that fare.

11. A booking system that provides sundry costs to a user comprising: one or more databases containing fare information and data for calculating sundry costs, 20 a computer system with an asynchronous transfer engine adapted to: receive journey criteria from a user interface for a desired journey, identify candidate fares satisfying the journey criteria received from the user, the candidate fares being associated with the journey, calculate sundry costs for one of the candidate fares from sundry costs data 25 retrieved from a database, generate and return information to the user interface to display sundry costs for the candidate fare, and the candidate fares on a fare construction presentation page, receive input, from a user interface, selecting another candidate fare, calculate sundry costs for the selected candidate fare from sundry costs data 30 retrieved from the database, generate and return information via the asynchronous transfer engine to the user interface, to display the sundry costs for the selected candidate fare on the user interface without refreshing the fares on the fare construction page. 75

12. A method of providing sundry costs to a user operating a booking system as hereinbefore described and with reference to the figures. 5

13. A booking system that provides sundry costs to a user as hereinbefore described and with reference to the Figures.