JP5841240B2 - Method and system for an improved reservation system that optimizes repeated search requests - Google Patents

Description

  The present invention relates to the field of reservation systems, and more particularly to a method and system for a massive computing platform that optimizes repeated search requests.

  State-of-the-art reservation systems are typically based on dedicated global distribution systems (GDS), for example airline reservation systems that provide flight search applications for shopping businesses such as flight reservations. Flight search requests from clients require an exhaustive search of GDS data. This requires a huge amount of calculation and takes some time. In order to minimize this delay, clients usually have little freedom. That is, they need to specify the name of the city of departure and destination, the date of departure and return, the operating airline, and the cabin class for the requested trip. While this is advantageous for system performance and response time, it is not optimal for customers who will clearly prefer a more user-friendly interaction with a wider range of freedom in parameter selection.

  Another business domain pioneered by airlines and travel agents, where improved user request management comes in handy, is so-called pre-shopping. This means an activity that needs to query the database through the reservation system, but does not necessarily result in a regular reservation. These activities are extremely important for airlines or travel agents. This is because even if these do not immediately lead to revenue, they can affect the future choices of potential customers. Tools that can provide zero-latency responses to client queries with a high degree of freedom will be highly appreciated. For example, suppose a client requests information about a flight departing from Paris, between June and September, for a two-week period, to a sunny place. In a normal flight search application, the client needs to specify the exact destination and make as many requests as the desired destination and possible date combinations.

  Another possible application could be a booking system with a revenue management process aimed at increasing profitability, rather than simply increasing flight booking. Example: An airline relies on the price of a comprehensive price for its planned flight (for example, a flight for all cities over the entire period), as well as its price based on a computer model based on booking forecasts. May want to adapt. With conventional systems, this approach is very complex and requires significant resources and operator effort.

  Yet another possible application is fee analysis for static purposes. In other words, based on the latest information applied to the GDS, it will follow up the changes in the ticket price of its own. Example: Evaluating the submitted price through a comparison of the price provided and the travel price calculated from the rules, a comparison of the current and previous prices for similar items, and a comparison with your own cost estimate.

  A common feature of the above application example is that it requires a very large amount of relevant flight recommendations. For example, pre-shopping applications require a wide range of solutions to provide attractive results to clients, and revenue management applications rely on this model because of their dynamic pricing policies that rely on this model. The fee analysis application requires an exhaustive flight recommendation list to efficiently track price transitions.

  In contrast to the shopping business domain, the purpose of these applications is not booking. For this reason, the calculation required to generate the flight recommendation does not need to be performed for each client inquiry, and the accuracy of the response can be obtained at the expense of response time. Because flight recommendations do not need to be recalculated for each client inquiry, these precalculations by GDS can be extended to a period of several hours. Also, because these applications rely on pre-computed flight recommendations, GDS can extend the data processing required to enter the system over a period of several hours.

  A known method of implementing the above application is a so-called transactional external shooter. In order to provide an exhaustive feed to the pre-shopping system or revenue management system, the customer can shoot a series of transactions to the shopping application provided by GDS. The transaction to be shot needs to include a combination of all desired departure dates, all desired markets, etc. Such a method has obvious drawbacks. For example, a slight increase in inquiries results in a massive combinatorial complexity increase, increasing the number of transactions that customers must shoot. The shot transaction corresponding to the global request collects the common parts needed for the calculation of each transaction: duplicate check, duplicate data access and duplicate processing are performed. The higher the calculated data, the higher the cost (in terms of resource consumption) of these duplicate operations. Even if the shot application provides an extended calendar or multiple choice type selection, the opportunity for optimization is still partial due to the lack of global awareness of all the transactions to be shot. For the customer, more processing time is required to calculate the results. For GDS, unnecessary resource consumption is induced for the calculation of the overlap. In addition, since the shooter is located external to the GDS, resource consumption is not under management. Also, since the data required for pre-shopping, revenue management or fee analysis is enormous, an unexpectedly large amount of traffic poses a risk of violating service level agreements with other customers.

  Another known way to implement a pre-shopping system is to capture shopping traffic and update the system. For any transaction requested by a client for reservation purposes, if it satisfies the pre-shopping system request, the result is returned to both the client and the pre-shopping server. The disadvantage of this prior art is that the customer has no control over the data used for the calculation. Therefore, there is no guarantee that the results are exhaustive and it cannot be fed into the revenue management system. Furthermore, capturing traffic is a static approach and is not applicable to specific constraints. Pre-shopping and revenue management systems can only use the characteristics of existing products.

  In order to guarantee the effective processing of the above-mentioned high volume data without requiring heavy operator work and unacceptable resource consumption, it is improved that a massive search can be performed while avoiding duplication of useless queries. A reservation system would be required.

  US Pat. No. 5,495,606 discloses a method for improving the search process in a database. This system can be added to existing systems in the prior art to improve the processing time of existing systems. US Pat. No. 5,495,606 discloses a system comprising a plurality of query processing modules that can operate in parallel. Each inquiry processing module includes a master inquiry processor and a slave processor. The master query processor receives the query and sends a response back to the end user. The master query processor has a query splitter for splitting the query into a plurality of split queries. The master inquiry processor also has a scheduler for allowing the already divided inquiry to be processed on an appropriate slave processor. Each slave inquiry processor transmits each divided inquiry to a specific database management module to access the database in a read-only configuration. As a result, all already divided queries can be processed in parallel by each query processing module, and the processing time is optimized. Since the database has a read-only configuration, the database is not updated during the processing of the divided query; this improves the processing time of the divided query. The method disclosed in US Pat. No. 5,495,606 requires a very powerful data processing system with multiple processors and does not provide a solution to the problem of possible duplicate search requests. The same query may be repeated multiple times because it does not involve optimization of the requested request.

U.S. Pat.No. 5,495,606

  One object of the present invention is to mitigate at least some of the problems associated with prior art systems.

  According to one aspect of the present invention, a method for generating a travel solution that is priced in response to an unbound travel inquiry in a reservation system, the reservation system comprising: Having access to a plurality of travel databases containing information about rates, each travel query includes a set of preference information, each preference information relating to a parameter selected from the plurality of parameters, The method includes receiving a plurality of travel queries, each travel query associated with a user, and pre-processing the plurality of travel queries, extracting at least one simple request element from each query. The plurality of request elements according to a step and at least one parameter Sorting, and if there are more than one request elements containing the same preference information for the same at least one parameter, removing duplicate request elements, and the plurality of request elements Pre-processing comprising: dividing into subsets according to predetermined criteria; transferring each subset of request elements to a processing module executing said request element that queries said plurality of databases; Collecting results from the processing module and issuing a response to the user for each travel query.

  According to a second aspect of the present invention, a system is provided comprising one or more components adapted to perform the method described above.

  According to a further embodiment of the present invention there is provided a computer program comprising instructions for performing the above method when executed on a computer.

  The method according to the preferred embodiment of the present invention provides an improved travel request service to end users requesting travel proposals from the Global Distribution System (GDS). This uses a wider range of new travel requests for each search parameter than conventional travel requests in the prior art. A new trip request includes a wide range of parameters in the same trip request, whereas a conventional trip request needs to repeat each different request value for each search parameter.

  The method according to the preferred embodiment of the present invention provides a combination of two modules, a master module and a worker module, to perform an improved travel request service. The master module extracts travel requests from all users. The master module divides the travel query into single requests and eliminates duplicate travel requests to obtain optimized travel requests. The master module then forwards the optimized travel request to the worker module. Depending on the content of the optimized travel request, the worker module directly executes the corresponding processing module, such as a travel processing module, an availability processing module, a fee engine processing module, etc. for the requested computation. As a result, the worker module will provide search results based on the optimized travel request. The worker module then sends the result of the optimized travel request to the master module. The master module then displays the results to the end user.

  The method according to the preferred embodiment of the present invention is based on a two-module implementation consisting of a master module and a worker module for handling a wide range of travel queries from users. The master module analyzes all travel queries from all users and provides optimized travel requests. The worker module processes the optimized travel request and sends it to a specific processing module.

Data calculation methods for feed purposes for pre-shopping, revenue management and fee analysis interact with other GDS subsystems already used in the shopping business (travel solution process, availability checking process, fee process, etc.) To do.
Some of the advantages that can be obtained with a preferred embodiment of the method include the following:
-The products provided by the platform enable feeding into a pre-shopping and revenue management system with completeness and consistency.

Thanks to the business rules that implement business logic and applicable plug-ins, the present invention provides customers with short delivery times. For GDS, it is easy to support a new type of application for flight and pricing at scale.
-For GDS, resource consumption is streamlined, and costs are reduced, thanks to optimization of data computation.
-In addition, resources are under control. Resources can be dynamically allocated according to the volume to be processed and the time restrictions to be observed without reaching system limits.

Reference will now be made, by way of example, to the accompanying drawings in which:
FIG. 2 illustrates a massive computing platform for a reservation system according to one embodiment of the invention. FIG. 2 illustrates a general purpose computer system adapted to support the method of the preferred embodiment of the present invention. Fig. 2 shows the software components of a system implementing a preferred embodiment of the invention, and an overall view for all the steps of the method according to the preferred embodiment of the invention. Fig. 2 schematically shows various steps of the method according to the invention. Fig. 2 schematically shows various steps of the method according to the invention. Fig. 2 schematically shows various steps of the method according to the invention. Fig. 2 schematically shows various steps of the method according to the invention. Fig. 2 schematically shows various steps of the method according to the invention. Fig. 2 schematically shows various steps of the method according to the invention. Figure 5 is a flow chart for method steps of a process according to one embodiment of the invention.

  FIG. 1 illustrates a subsystem 101 specialized for large scale calculations of flights and prices, according to a preferred embodiment of the present invention. Data processing is separated from shopping traffic that is specialized for booking.

  This subsystem manages queries with a high degree of freedom instead of transactions used in reservation applications. This degree of freedom applies to: for example, date combinations (departure date for all days of a year and all return dates from the date of departure to several weeks later), geographical zone of origin and destination , The requested commercial airline (one, multiple or all of the possible airlines for the requested city pair), all available booking codes, any passenger type, etc.

  Since low latency is not essential for such data calculations, the time frame may be different from real time. Thus, processing and resource consumption can be extended over longer time frames. The return of results is also extended over the time frame.

  In a preferred embodiment of the present invention, the subsystems are organized according to a batch model that can dynamically instantiate resources to handle large amounts of data. The subsystem optimizes data processing based on global query analysis. Also, the subsystem is general purpose and expandable. Different business logic can be easily plugged into the subsystem to satisfy various customer requirements (pre-shopping, revenue management, fee analysis).

  In a preferred embodiment of the present invention, the subsystem 101 includes one or more massive masters 103 and a plurality of massive workers 105. The massive master 103 analyzes the query globally and then breaks it down into optimized requests. These requests are then processed by one or more massive workers, and the results are fed back to the sender's massive master, which assembles the results from the massive workers into a travel solution plus price.

  Referring to FIG. 2, a general purpose computer of the system (eg, computer, reservation server, massive master server, massive worker server, database management subsystem, router, network server) is indicated at 250. The computer 250 is formed by a plurality of units connected in parallel to the system bus 253. Specifically, one or more microprocessors 256 control the operation of computer 250; RAM 259 is used directly as working memory by microprocessor 256, and ROM 262 stores the basic code for bootstrap of computer 250. Peripheral units are clustered around each local bus 265 (by each interface). In particular, the mass memory includes a hard disk 268 and a drive 271 for reading a CD-ROM 274. In addition, the computer 250 includes an input device 277 (eg, keyboard and mouse) and an output device 280 (eg, monitor and printer). A network interface card 283 is used to connect the computer 250 to the network. A bridge unit 286 provides an interface between the system bus 253 and the local bus 265. Each microprocessor 256 and bridge unit 286 can operate as a master agent that requests access to the system bus 253 for information transmission. The arbiter 289 manages permission of access to the system bus 253 with mutual exclusion. The same is true if the system has a different topology or is based on another network. In other cases, the computer may have a different structure, include equivalent units, or be composed of other data processing entities (such as PDAs and cell phones).

  In a preferred embodiment of the present invention, the subsystem performs a global analysis aimed at identifying relevant redundancies in the query to avoid useless reprocessing. In processing, merging redundant query parts must be efficient in terms of resource consumption and in terms of access to the data being processed. Subsystems need to meet functional and technical requirements at the same time, i.e. while complying with service level agreements established with customers (time constraints, quality), operational requirements ( Listing management, ripple effects on other components) must also be observed on the other side. The subsystem of a preferred embodiment of the present invention includes the following two types of servers.

That is, a massive master that hosts the global intelligence needed to optimally manage inputs and outputs.
A massive worker that implements the business logic of each product plugged into the massive computing platform.

FIG. 3 illustrates a process flow according to a preferred embodiment of the present invention. This global flow can be divided into the following six steps / work that can be performed in parallel:
-Split (SPLIT): Here, the massive master extracts all single requests from customer inquiries.
-OPTIMIZATION: Here, the massive master performs a global analysis to merge requests smartly.
-ASSIGNATION: Here, the massive master sends a request smartly to the massive worker.
-COMPUTATION: Here, the massive worker handles the optimized request.
-Streaming: Here, a massive worker manages the result volume.
-Aggregation (AGGREGATION): Here the massive master groups the results according to customer inquiries.

  Each step is detailed in the following paragraphs.

  FIG. 4 schematically shows a split operation, ie an operation for extracting a single request from an inquiry received by a customer. A split operation consists of converting a query into a single request. A single request is logically equivalent to a transaction with no degrees of freedom: information about date, geography, passenger, and airline.

  The input management module 401 detects the set of inquiries posted by the customer. If a query is no longer received at some point, it can also be decided to process a series of previously processed queries. This prevents the customer from being forced to post a set of queries within a predetermined period (eg, every day). The input management step can also determine the frequency of processing each query: for example, once a day or multiple times a day. The input management module 401 also determines the task instantiation to process the input volume. The resources required for the next step are evaluated according to the number of inquiries and the time frame established with the customer. This ensures that large data can be calculated within a constrained delay range.

  The input check module 403 checks input from both a syntactic and semantic viewpoint. Since this step is product dependent, different plug-ins are added to manage different types of inputs. New plug-ins are added for new products or new product versions.

  Extraction module 405 extracts a single request from the semantic information provided by the customer in the query. This extraction depends on both the product and the input provided by the customer. This step is therefore pluggable. In addition, business rules can be applied to some functional constraints of customers.

  Examples of business rules that apply in this context: requesting better quality availability of domestic market travel (eg polling availability to airlines).

  FIG. 5 schematically illustrates an optimization operation, i.e. performing a global analysis on a customer request. Once a single request is generated, at another stage, redundant portions are merged for computational optimization purposes. This operation consists of a plurality of steps described below.

  The global analysis module 501 identifies redundant words in a single request. For efficient optimization, this step is based on a plug-in that defines for each product the most relevant redundant words to group.

  The merging module 503 groups single requests in order to avoid redundant processing. Multiple smart merging is possible. The grouping is based on both product specific plug-in optimization rules and business rules that meet customer functional constraints.

  Business rule example: Request grouping is based on the processing timeframe desired by the customer. Domestic market requests must be processed after the end of work time, ie after the last possible manual update. On the other hand, requests from other markets can be processed immediately.

  For queries that are processed regularly, the main part of the results generated is the same in each process. The heuristic model 505 statistically identifies requests that will produce the same results that were returned to the customer in the previous process. These requests are not processed. In this way, unnecessary price calculation is reduced. This module saves resource consumption. However, a high level of accuracy is guaranteed for global results.

  FIG. 6 schematically shows an allocation operation, ie, what drives the request processing. Once the first merged request is generated, it is processed. The allocation operation is executed in parallel with the above-described steps, and drives the allocation of requests to the massive workers according to the resources. This operation consists of a plurality of steps described below realized by different modules. The request provider module 601 selects a request to be sent to the massive worker according to the inquiry that generated the request. The purpose of this module is to make it possible to return the results of inquiries to the customer sequentially. A request is selected to calculate the global result of the query. Once the result of a query is calculated, a request relative to another query is selected. Another selection criterion is the processing time frame that is approved for each merged request. For example, some request processing is delayed after office hours. This also refers to the last manual update to the data used for the result calculation.

  The pacing and priority module 603 controls the activity of massive workers according to available resources by avoiding overload conditions. It also manages the priority between requests to be processed. For example, if a set of queries is requested in Fast Track mode, it needs to be processed at a higher priority than the standard set of queries. More resources are allocated exclusively for the calculation of such queries.

  A massive worker targeter module 605 selects a massive worker farm in which the request is to be processed. This choice is based on both a technical perspective (massive worker resource availability) and a functional perspective (there is a massive worker farm dedicated to some markets / products / customers).

  FIG. 7 schematically shows a charge calculation operation, that is, business logic. The massive worker implements the business logic of all products by the method according to the preferred embodiment of the present invention.

  A request decryption module 701 decrypts the optimized request provided by the massive master. This process is driven by calling a different module that already exists in the GDS. The module that is called and the order in which the call is made depends on the product. Each called module is based on an applicable plug-in specific to each product.

  The travel processing module 703 performs the calculation of the requested flight solution. The module is responsible for identifying the trip combination from the date, geography and option information provided in the request. Travel processing relies on the latest update data.

  The availability processing module 705 implements checking the availability of the travel solution. To obtain a better quality level, the request can be processed directly by the airline and relied on more current data.

  The charge engine processing module 707 performs the price calculation of possible solutions for the request according to the information and options given in the request. If only a better solution is requested, the module will compare prices and keep only the best.

  FIG. 8 schematically shows a streaming operation, ie managing raw results. In order to manage the enormous volume generated by the calculation, the operation requires optimization for both communication with the massive master and storage of results. Several modules on the massive master, described below, enable this optimization.

  The compression module 801 reduces the size of the result, thereby reducing the communication volume between the massive worker and the massive master. In addition, the volume of stored data is reduced. Since this operation consumes processing resources, it is applied only when the gains for communication and storage resources are significant.

  The division / buffering module 803 also enables optimization of resource consumption.

  If the resulting volume of the generated result is too large, it is split into multiple bundles. In this way, communication between the massive master and the data storage is performed simultaneously.

  If the resulting volume is too low, it is buffered until it is suitable for management by the massive master. Communication becomes more efficient. This is because only a few storage modules are needed to handle a certain volume.

  The massive master targeter 805 selects a massive master. This choice is based on both a technical perspective (resource availability at the massive master) and a functional perspective (there is a massive worker farm dedicated to some markets, products, and customers).

FIG. 9 schematically illustrates the management of aggregation operations, ie customer input.
As query results are generated, they need to be aggregated and sent back to the customer in the proper format.

  The result aggregate module 901 converts raw results from massive workers into price-oriented results. Results are aggregated in response to customer inquiries: customers get answers to their questions, not chaotic results. For example, if a customer has requested a solution in a query for a specific market, with several options for departure dates throughout the year, the answer will include all options included in the query. And all solutions corresponding to all departure dates are aggregated. Define the format in which plug-ins are expected for each product and each customer.

  The Diff module 903 is a price packaging option for selecting a result that has changed since the previous processing. Only new, updated or reduced results are sent back to the customer. Differentiation criteria according to products are defined by plug-ins. This option allows for efficient network transfer between GDS and customers. Moreover, since it is sufficient to manage a smaller volume, the load on the customer system is reduced.

  The compression and encryption module 905 enables efficient and secure network transfer by reducing the volume sent back and guaranteeing the resulting confidentiality.

  A trickling return module 907 periodically transfers by grouping the global results of processed queries. Thereby, a return is extended over a long time.

  Because the resulting volume is massive, customers cannot wait for the end of the process to integrate the results into a pre-shopping or revenue management system. Therefore, an initial result is generated and sent back several minutes after the start of processing. The transfer is spread over the processing time. This allows results to be gradually integrated into the customer's pre-shopping or revenue management system.

Example of use

Example 1: Product for a pre-shopping system Consider a product that specializes in input to a pre-shopping system. Such calculates the lowest price for all departure dates and length of stay for each flight solution that matches a specified city pair and airline. Calculations are based on all data automatically submitted to GDS by intermediate tariff publishers. Recommendations will only be returned if there are seats remaining on the flight. This operation is limited to inquiries when the customer's partner is an airline, as many resources are consumed to determine the number of remaining seats.

  By creating a single request, the split module can identify partners for the request, thanks to business rules, and can flag those requests to allow for a seat check.

  The optimization module merges trip requests to prevent redundancy due to date combinations. The merge operation uses a plug-in that takes into account the optimization of the processing of the price engine specific to the product.

Example 2: Product for a revenue management system Consider a product specializing in input to a revenue management system. Such will calculate the minimum price for all departure dates, length of stay, early purchase conditions and Reservation Booking Code (RBD) for each flight solution that matches the specified market. . The same RBD must be used throughout the journey. Calculations are based on all data automatically submitted to GDS by intermediate tariff publishers. The calculation of requests with a departure date within 45 days is based on all data manually submitted to GDS by the customer during business hours.

  The optimization module bundles date combinations and early purchases to optimize the calculation of the travel solution. At the time of merging, the module applies business rules to isolate requests with departure dates within 45 days. Processing for these will be delayed until after business hours in order to capture manual updates submitted to GDS. The fare calculator module uses a specialized travel processing plug-in to return the correct RBD to the flight solution. Since the product is not limited to shopping or pre-shopping, the availability processing plug-in is not used.

  Since this product returns thousands of results (due to a combination of date, early booking, RBD) as an optimized request, the streaming module will split the raw results on the massive worker.

  The method described above is also illustrated in FIG. The method begins at bullet 1001 and proceeds to box 1003 where a travel inquiry is received by the system. Such inquiries are made by a user seeking information about travel availability, fees, time, or general matters that are not necessary to complete a reservation, i.e., pre-shopping information. In the preferred embodiment of the present invention, the system that receives the query and queries the database to satisfy the query from the user is separate from the actual reservation system, but those skilled in the art It will be appreciated that the two systems (pre-shopping and booking) can be integrated. Once a travel inquiry is received, control returns to box 1005 for pre-processing of the inquiry. The event that calls the preprocessing or triggers the start of the preprocessing can be based on several factors and can even be customized by the system administrator or individual users. For example, pre-processing can be performed at predetermined time intervals (eg, every day or at the end of every hour), or automatically when a critical number of queries are received or when maximum capacity is reached. Can be done or requested by an administrator or user. According to a preferred embodiment of the present invention, the preprocessing of the travel query involves a global analysis that breaks the query into simple request elements (also referred to as single requests in FIG. 3), which makes the database query optimal. It becomes. In the preferred embodiment of the present invention, each query is analyzed by a massive master (pre-processing module) to extract one or more simple request elements. These simple request elements are then rearranged and sub-set (optimized in FIG. 3) according to predetermined criteria that take into account multiple factors and business rules as described with respect to FIG. 5 to avoid redundancy. (Also called a request). This preprocessing continues until all travel queries have been preprocessed (step 1700). Once the request has been optimized, the massive master assigns each subset to the appropriate massive worker and forwards the request to the correct massive worker (step 1009). After that, each massive worker makes an inquiry to the database regarding, for example, a travel fee, travel availability, etc. in order to satisfy the user's request. The results for the query are collected, sent back to the massive master, and the response is provided to the user who submitted the travel query (step 1011). In the preferred embodiment of the present invention, the results are aggregated by the massive master as described above before it is provided to the user. Thereafter, the process ends at step 1013. In the above example described with reference to FIG. 10, the system performing the method has one massive master and multiple massive workers, but other aspects are possible. For example, when there are more than one massive masters working in parallel, or when one massive worker processes multiple subsets. Also, the massive worker and the massive master do not necessarily need to correspond to different physical machines, and may be applications that function on the same system.

  It will be understood that modifications and changes may be made to the above without departing from the scope of the present disclosure. Of course, one of ordinary skill in the art can make numerous changes and modifications to the above solution to meet local and specific requirements. Although the present disclosure has been described with a certain degree of specificity with reference to preferred embodiments, various omissions, substitutions, and changes in form and detail, and other embodiments are possible, and the present disclosure It is expressly intended as a general matter of design choice that the specific elements and / or method steps described in connection with the embodiments disclosed in may be incorporated into any other embodiments.

  Similar considerations apply if the program (which can be used to implement each embodiment of the present disclosure) is constructed in a different manner or if additional modules or functions are provided; The memory structure can be of other types or can be replaced by an equivalent entity (not necessarily a physical storage medium). Furthermore, the presented solution is also suitable to be implemented in an equivalent way (including similar or additional steps and even out of order). In any case, the program is suitable for use by or in connection with a data processing system such as external or resident software, firmware or microcode (object code or source code). Further, the program can be provided on any computer usable medium, and the medium can be any element suitable for storing, transmitting, propagating, or transferring including the program. Examples of such media include fixed disks (which can be pre-loaded with a program), removable disks, tapes, cards, wires, fibers, wireless connections, networks, broadcast waves, etc .; It can be of the magnetic, optical, electromagnetic, infrared or semiconductor type.

  In any case, the solution according to the present disclosure is suitable for execution by a hardware structure (eg, integrated into a chip or semiconductor material) or a combination of software and hardware.

Claims (12)

A method for pre-calculating travel solutions priced in response to unbound travel queries in a reservation system, wherein the reservation system is organized according to a batch model and includes a calculation subsystem including a processing module, the reservation system Has access to a plurality of travel databases containing information relating to travel availability and prices in response to a plurality of parameters, each travel query includes a set of preference information, wherein each preference information is the plurality of parameters In relation to a parameter selected from:
The computing subsystem receives a plurality of travel queries in which each travel query is associated with a user;
The computing subsystem pre-processing the plurality of travel queries;
Extracting at least one simple request element from each query;
Sorting the plurality of request elements according to at least one parameter;
Removing duplicate request elements when there are more than one request elements containing the same preference information for the same at least one parameter;
Statistically identifying request elements that are likely to produce the same results as the previous calculation, and not further processing the request elements;
Pre-processing, comprising: dividing the plurality of remaining request elements into subsets according to predetermined criteria;
The computing subsystem forwards each subset of request elements to a processing module that executes the request elements that query the plurality of databases;
The computing subsystem collecting results from the processing module and issuing a response to the user for each travel query.   The method of claim 1, wherein results collected from the processing module are aggregated before issuing the response to a user.   The method according to claim 1, wherein the step of executing the request elements of each subset of the request elements is performed in parallel by a plurality of processing modules.   The method of claim 3, wherein the step of dividing the plurality of request elements includes assigning each subset to one of the plurality of processing modules according to a predetermined criterion.   The method according to claim 1, wherein the step of pre-processing the plurality of travel queries is performed in parallel by a plurality of pre-processing modules. For each request element result, the processing module selects one of a plurality of pre-processing modules as the result to be forwarded for aggregation and sending the response to the user. The method of claim 5, further comprising:   The method according to claim 1, wherein the plurality of parameters includes a date and a geographical location. The method according to claim 1, wherein the result collected from the processing module is divided into a plurality of bundles when the volume of the result exceeds a predetermined threshold. The method according to any one of the preceding claims, wherein the results collected from the processing module are buffered and further processed only when a predetermined minimum data volume is reached. The computing subsystem further includes a difference module, and the method includes:
The difference module collects from the processing module the results that have changed since the previous calculation;
Sending back only the changed result to the user;
10. The method according to any one of claims 1 to 9, comprising: When running on a computer, the computer program includes instructions for executing the steps of the method according to any one of claims 1-10. A data processing system for managing pre-shopping travel queries, the data processing system having access to a plurality of travel databases containing information on travel availability and rates according to a plurality of parameters, each 11. The travel query includes a set of preference information, each preference information is associated with a parameter selected from the plurality of parameters, and the system performs the method of any one of claims 1-10. A system comprising one or more components adapted to do so.

Images