Method and system for an improved reservation system optimizing repeated search requests

Abstract

The method according to a preferred embodiment of the present invention allows an improved travel request service to end-users who request proposals for a trip from a Global Distribution System (GDS). This uses a new travel request which comprises a wider range for each search parameter than previous travel requests from the prior art. The new travel request includes many different ranges of parameters in the same travel request whereas the prior art travel request has to be repeated for each different requested value for each search parameter. The method according to a preferred embodiment of the present invention provides a combination of two modules, a master module and a worker module, to carry out the improved travel request service

Description

technical field

[0001] The present invention relates to the field of reservation systems, and more particularly to methods and systems for optimizing repetitive search requests on large-scale computing platforms. Background technique

[0002] Existing state of the art reservation systems are often based on dedicated global distribution systems (GDS), as for example airline reservation systems provide flight search applications for shopping operations such as flight bookings. A flight search request from a customer requires an exhaustive search of the GDS data. This involves a lot of computation and can take some time. In order to minimize delays, customers usually have very little freedom: they must specify the departure and arrival city, departure and return dates, carrier, and class of travel for the requested journey. While this is good for system performance and response time, it is not ideal for users who certainly value a more user-friendly interaction with more free...

Examples

example 1

[0079] Example 1: Products of the pre-order system

[0080] We consider products dedicated to pre-order system support. For each flight solution matching the specified pair of city and carrier, it calculates the lowest applicable price for all combinations of departure date and layover time. The calculation relies on all data automatically submitted to the GDS through the intermediary of the price list publisher. Recommendations are returned only if there are seats available on the flight. Since checking for vacant seats is resource intensive, it is only done for queries that have the customer's partner as the carrier.

[0081] By creating a single request, due to business rules, the separation module is able to identify the partners in the request and flag these requests to enable "empty seat check".

[0082] The optimization module merges journey requests to prevent redundancies caused by date combinations. The merge operation utilizes an optimized plugin that takes into...

example 2

[0083] Example 2: Product of revenue management system

[0084] We consider products dedicated to yield management support. For each flight solution that matches a given market, it calculates the lowest applicable price for all combinations of departure date, layover time, advance purchase conditions, and reservation code (hereafter referred to as RBD). The same RBD must be used throughout the trip. This calculation relies on all data automatically submitted to the GDS through the intermediary of the price list publisher. Calculations for requests with a departure date within the next 45 days must rely on all data manually submitted to the GDS by the customer during office hours of the day.

[0085] The optimization module bundles date combinations and advance purchases to optimize the calculation of journey solutions. When merging, it applies business rules to separate requests with departure dates within the next 45 days. Its processing is delayed until after the client ...

technical field

[0001] The present invention relates to the field of reservation systems, and more particularly to methods and systems for optimizing repetitive search requests on large-scale computing platforms. Background technique

[0002] Existing state of the art reservation systems are often based on dedicated global distribution systems (GDS), as for example airline reservation systems provide flight search applications for shopping operations such as flight bookings. A flight search request from a customer requires an exhaustive search of the GDS data. This involves a lot of computation and can take some time. In order to minimize delays, customers usually have very little freedom: they must specify the departure and arrival city, departure and return dates, carrier, and class of travel for the requested journey. While this is good for system performance and response time, it is not ideal for users who certainly value a more user-friendly interaction with more free...

Examples

example 1

[0079] Example 1: Products of the pre-order system

[0080] We consider products dedicated to pre-order system support. For each flight solution matching the specified pair of city and carrier, it calculates the lowest applicable price for all combinations of departure date and layover time. The calculation relies on all data automatically submitted to the GDS through the intermediary of the price list publisher. Recommendations are returned only if there are seats available on the flight. Since checking for vacant seats is resource intensive, it is only done for queries that have the customer's partner as the carrier.

[0081] By creating a single request, due to business rules, the separation module is able to identify the partners in the request and flag these requests to enable "empty seat check".

[0082] The optimization module merges journey requests to prevent redundancies caused by date combinations. The merge operation utilizes an optimized plugin that takes into...

example 2

[0083] Example 2: Product of revenue management system

[0084] We consider products dedicated to yield management support. For each flight solution that matches a given market, it calculates the lowest applicable price for all combinations of departure date, layover time, advance purchase conditions, and reservation code (hereafter referred to as RBD). The same RBD must be used throughout the trip. This calculation relies on all data automatically submitted to the GDS through the intermediary of the price list publisher. Calculations for requests with a departure date within the next 45 days must rely on all data manually submitted to the GDS by the customer during office hours of the day.

[0085] The optimization module bundles date combinations and advance purchases to optimize the calculation of journey solutions. When merging, it applies business rules to separate requests with departure dates within the next 45 days. Its processing is delayed until after the client ...

Images