CN107527103B

CN107527103B - Data warehouse for mining search query logs

Info

Publication number: CN107527103B
Application number: CN201710473912.4A
Authority: CN
Inventors: B·拉都; R·A·阿库纳阿格斯特
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2016-06-21
Filing date: 2017-06-21
Publication date: 2023-09-05
Anticipated expiration: 2037-06-21
Also published as: CN107527103A; SG10201912862TA; SG10201704879XA

Abstract

A system, method and computer program for mining search query logs. The data warehousing system includes a query database storing data related to search queries, a reservation history database storing data related to reserved products, and a data warehousing application that extracts and processes the search queries and the reservation data from the query and reservation history databases to generate statistical data. The data warehousing application generates historical queries, reservations, and specific flight pick-up curves based on the extracted statistics. A weighted average of the historical queries and the reservation pickups that provide a best fit to the flight-specific pickups is determined. The weighting factors that produce the best fit are then used to predict the demand for future flights.

Description

Data warehouse for mining search query logs

Technical Field

The present invention relates generally to computers and computer software, and more particularly, to methods, apparatus and computer program products for analyzing large amounts of data related to search queries received by a travel management system.

Background

The travel industry has grown significantly over the past decades, which has led to an increase in the number of travel providers and the amount of data to be managed between these providers. As the number of providers increases, intermediaries that provide travel management systems are emerging. These travel management systems manage communications between travel providers and end users, thereby enabling users of travel agency systems, airline reservation systems, and travel websites to retrieve information from a large number of travel provider systems.

These users often submit low-fare search (LFS) queries when searching for flights. LFS queries typically define a start point, a destination, and one or more dates and/or times when traveling between the start point and the destination is desired. The travel management system typically responds to these LFS queries by determining a set of one or more flights between the origin and destination and a fare that may be used with each flight. The fare may be determined by a fare engine that uses fare data published by a fare data provider, such as an airline fare publishing company (ATPCO), to calculate the fare. The search results typically include a travel option list including flight and fare information.

LFS queries are often used to identify potential flights at an early stage of the planned itinerary. Thus, users typically submit multiple LFS queries prior to selecting and subscribing to (book) flights. Travelers without a specific travel plan may also submit queries to determine where they want to travel, or simply for curiosity. Thus, the number of LFS queries received by the travel management system may exceed the number of slots of the final reservation by a factor of many. Because of the large number of LFS queries received, it may be difficult for the travel system to manage the LFS queries and typically discard the LFS queries after they have responded. Thus, conventional travel management systems are unable to provide detailed information about LFS queries that have been received for a period of time.

Accordingly, there is a need for improved systems, methods, and computer program products for managing and analyzing LFS queries to improve the ability of travel management systems to track and provide information related to LFS queries.

Disclosure of Invention

In an embodiment of the present invention, a data warehouse system is provided. The system includes one or more processors and a memory coupled to the processors. The memory stores first data of a first database including query log records and instructions that, when executed by at least one processor, cause the system to receive a plurality of search queries. Each search query may be received at a time of receipt and may define a departure time and a start-destination pair. The instructions may also cause the system to determine, for each search query, a time until departure from a time of receipt of the search query to a time of departure and store, in a query log record associated with the origin-destination pair, second data indicating the time of receipt of the search query and the time from departure. Each query log record may also indicate, for a start-destination pair associated with the query log record, a number of slots and a time from departure associated with each slot.

In another embodiment of the present invention, a method of processing a transaction is provided. The method may include receiving, by a data warehouse system, a plurality of search queries. Each search query may be received at a time of receipt and may define a departure time and a start-destination pair. The method may further comprise: for each search query, determining a time until departure from a time of receipt of the search query to a time of departure and storing second data indicating the time of receipt of the search query and departure in a query log record associated with the origin-destination pair. Each query log record may be stored in a first database and may be associated with a start-destination pair indicating a number of slots and a time from departure associated with each slot.

In another aspect of the invention, the instructions may further cause the system to define an index comprising a plurality of fields, each field corresponding to a respective origin-destination pair. Each field may define a location in the first database of each query log record associated with a respective origin-destination pair.

In some examples, the search query is a low fare search query.

In another aspect of the invention, the instructions may further cause the system to receive a request to provide statistics for a time period for a corresponding origin-destination pair. In response to receiving the request, one or more query log records are retrieved from the first database. Each of the retrieved one or more query log records is associated with a respective origin-destination pair and may include data related to a search query defining a respective departure time that falls within the time period. The system may extract second data from each of the retrieved query log records, generate a first pick-up curve based on the second data, the first pick-up curve depicting an intensity of the search query for the respective origin-destination pair relative to a time from departure during the time period, and predict a need for a vacancy for the respective origin-destination pair using the first pick-up curve.

In some examples, the departure time defined by each of the one or more query log records has elapsed when the request is received.

In another aspect of the invention, the time period may cover a plurality of departure intervals (intervals), and instructions cause the system to predict, using the first pick-up curve, a need for slots for respective origin-destination pairs by querying the second database for third data defining a plurality of subscriptions to slots for respective origin-destination pairs that have departed during the time period. The system may also generate a second pick-up profile using the third data, the second pick-up profile depicting a predetermined number of times during the period of time relative to a time from departure. The system may generate a third pick-up profile that is a weighted average of the first pick-up profile and the second pick-up profile. A third pick-up curve may then be used to predict the need for room for the corresponding start-destination pair.

In another aspect of the invention, the instructions may further cause the system to determine, for at least one departure interval covered by the time period, a target pick-up curve for a respective origin-destination pair, determine a weight factor that provides a best fit between a third pick-up curve and the target pick-up curve, and predict, for a future departure interval, a need for room for the respective origin-destination pair using the third pick-up curve with the weight that provides the best fit.

For example, for at least one departure interval covered by the time period, determining a fourth pick-up curve for the respective origin-destination pair; determining a weight factor that provides a best fit between the third pickoff curve and the fourth pickoff curve; and predicting the demand for vacancies for the corresponding origin-destination pair for the future departure interval using a third pickup curve having weights providing the best fit, wherein the fourth pickup curve is the target pickup curve.

In another aspect of the invention, for each future departure interval, for a respective origin-destination pair scheduled to depart during the future departure interval, a partial pick-up curve is determined for a search query satisfied by a respective travel plan, a third pick-up curve having a best fit to the partial pick-up curve is determined, and using the third pick-up curve having a best fit to the partial pick-up curve, a demand for vacancies is predicted for the respective origin-destination pair for the future departure interval.

In another aspect of the invention, the respective origin-destination pair may be one of a plurality of origin-destination pairs comprising the travel network, and a separate first pick-up curve is generated for each of the plurality of origin-destination pairs for each departure interval.

In other aspects of the invention, each departure interval may cover a day, and/or the time period may cover a year.

In another embodiment of the present invention, a computer program is provided. The computer program (e.g., in the form of a computer program product) may include a non-transitory computer readable storage medium and program code stored on the medium. The program code, when executed by one or more processors, may cause the processors to receive a plurality of search queries. Each search query may be received at a time of receipt and may define a departure time and a start-destination pair. For each search query, the program code may cause the processor to determine a time until departure from a time of receipt of the search query to a time of departure, and store second data indicating the time of receipt of the search query and the time from departure in a query log record associated with the origin-destination pair. Each query log record may indicate, for a start-destination pair associated with the query log record, a number of slots and a time from departure associated with each slot.

The foregoing summary may provide a simplified summary of some embodiments of the invention in order to provide a basic understanding of some aspects of the invention discussed herein. This summary is not intended to provide an extensive overview of the invention, nor is it intended to identify any critical or essential elements or to delineate the scope of the invention. The sole purpose of the summary is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with a general description of the invention given above and the detailed description of the embodiments given below, serve to explain the embodiments of the invention.

FIG. 1 is a schematic diagram of an exemplary operating environment including a travel management system in communication with a query database and a reservation history database.

FIG. 2 is a schematic diagram of an exemplary computer that may be used to provide the operating environment of FIG. 1.

FIG. 3 is a schematic diagram of a data warehousing system including a demand prediction module and a data collection module in communication with the predetermined history database and search queries of FIG. 1.

FIG. 4 is a graphical view of a pair of pick-up curves that may be generated by the demand prediction module of FIG. 3.

FIG. 5 is a graphical view of the pick-up curve from FIG. 4 and a query pick-up curve that may be generated using data extracted from the query database of FIG. 1.

FIG. 6 is a flow chart of a process for determining weight factors that may be used to incorporate search query data into a prediction process.

FIG. 7 is a graphical view of a historical query pick up curve and an expected query pick up curve that may be used to correct previous demand predictions.

FIG. 8 is a flow chart of a process for correcting demand predictions using the historical query pick up curve and the expected query pick up curve of FIG. 7.

Detailed Description

Embodiments of the present invention may be implemented by a data processing system that provides database functions that store, index, categorize, and organize search queries received by a travel management system. The travel management system may be configured to facilitate interconnection between one or more computers and the database system. The computer and database systems may include one or more provider systems, database management systems, user systems, and/or any other computer systems associated with providing travel products. In the context of air travel, the travel management system may allow a traveler to search for and subscribe to airline tickets across multiple providers and/or sales channels of travel products. The data warehouse system may be configured to collect and mine data related to search queries received by the travel management system and populate new database records and/or systems with data based on the mined data in a processed form that may be quickly and easily analyzed.

Referring now to FIG. 1, an operating environment 10 in accordance with an embodiment of the present invention may include a travel management system 12, a query database 14, a reservation history database 16, a provider system 18, and a user system 20. Each of travel management system 12, query database 14, reservation history database 16, provider system 18, and user system 20 may communicate over network 22. The network 22 may include one or more private or public data networks (e.g., the internet) that enable data to be exchanged between systems connected to the network 22.

The travel management system 12 may be configured to receive and process queries from the user system 20. The user system 20 may be a travel agency system, an airline reservation system, a travel website system, or any other system for searching, reserving (reserve), and purchasing travel products. The queries received by the travel management system 12 may include, for example, search queries, such as low fare search (LFC) queries, and the like. Each search query may include one or more search terms. The search term may include, for example, a start point, a destination, a desired amount of room, and a time period for which travel is desired. In response to receiving the search query, the travel management system 12 may query one or more reservation systems, a cache database, or any other suitable source of priced travel plans that match the search terms in the search query. The travel management system 12 may process all or a portion of the received priced travel itinerary and return it to the user system 20 as a search result.

The search query and/or data related to the search query, data defining or characterizing the search query may be stored in the query database 14. The data related to the search query may include an origin and destination defined by the search query, a time at which the search query was received by the travel management system 12 (or "time of receipt"), an amount of room requested for travel from the origin to the destination, a time at which travel is desired, or any other parameter defined by or related to the search query.

Before booking a flight, a user (e.g., a traveler or a travel agency working for the traveler) may search for a travel plan that meets the traveler's requirements. To this end, the user may enter the search term into a client application, such as a web browser or a predefined application running on the user system 20. The client application may then send a search query including the search term to a corresponding server application of the travel management system 12. The user may perform multiple searches for travel scenarios over a period of time prior to selecting and subscribing to one or more slots or "spaces". These searches may be performed during a single session or may be performed in separate sessions over a period of time. In either case, the user may eventually reserve a slot for the travel itinerary or decide to abandon the itinerary, at which point the user may stop searching for the travel itinerary.

In response to receiving a search query from a client application, a server application may determine which travel scenarios satisfy the search term. The server application may also search the query database 14 for query log records corresponding to origin-destination pairs defined by the search query. If no query log record is found for the origin-destination pair, the server application may request that the query database 14 create a record. Each query log record may correspond to a particular origin-destination pair and a particular departure interval (e.g., a particular day, week, or other period of time for which a demand is to be expected). The query log record may also correspond to a particular flight in addition to or instead of the departure interval. In addition to or instead of query log records, the query database 14 may store the search query itself or any other data related to the search query.

Each query log record may include one or more fields for storing data. These fields may include, for example, a start field containing data defining a start point, a destination field containing data defining a destination, a departure interval and/or flight field containing data defining a departure period, and a counter field containing data defining how many times the search term server application has received a search query if the search term matches the start point-destination pair, and the time at which each of the matching queries was received. When a search query is received by the server application, the server application may add data to the counter field in each matching query log record to indicate that a matching search query was received. The counter field may also include data indicating the number of slots requested by each search query. For example, the counter field may include a counter that increments the number of slots requested by a search query each time a search query matching a query log record is received.

The reservation history database 16 may store data related to reserved reservations. Once the user identifies one or more suitable travel plans, the user system 20 may send a request to the server application requesting that the slots in the one or more travel plans be booked. The request may be forwarded to one or more of the predetermined systems. If the request is accepted by the reservation system, reservation may be made (e.g., by creating a passenger name record in a passenger name record database) and the inventory of available slots in the corresponding reservation class of the travel scenario reduces the number of slots reserved.

In response to receiving a confirmation from one or more reservation systems that the requested slot has been reserved, the server application may request that reservation history database 16 create and/or modify a reservation record to indicate that the corresponding slot has been reserved, and the time at which the slot was reserved. This data may be stored in the reservation history database for a period of time (e.g., one year) after the flight corresponding to the reservation record has been taken.

Provider system 18 may include a Computer Reservation System (CRS) that enables travel management system 12 to reserve and pay for travel products, such as tickets, hotel rooms, or rental vehicles. For air travel providers, the CRS may manage reservations for gaps between nodes of the travel network. Each node of the travel network may include a station (e.g., airport) where the provider operates flights to and from. Provider system 18 may also interact with other provider systems, either directly or through travel management system 12, to enable an effective operator (validating carrier) to sell vacancies of tickets provided by a running operator (operating carrier). The operating operator may then charge the effective operator for the offered product.

Referring now to FIG. 2, the travel management system 12, query database 14, reservation history database 16, provider system 18, user system 20, and network 22 of the operating environment 10 may be implemented on one or more computer devices or systems, such as an exemplary computer 30. The computer 30 may include a processor 32, memory 34, mass storage memory device 36, input/output (I/O) interface 38, and Human Machine Interface (HMI) 40. The computer 30 may also be operatively coupled to one or more external resources 42 via the network 22 or the I/O interface 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other suitable computer resource that may be used by computer 30.

Processor 32 may include one or more devices selected from microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or any other device that manipulates (analog or digital) signals based on operational instructions stored in memory 34. Memory 34 may include a single memory device or multiple memory devices including, but not limited to, read Only Memory (ROM), random Access Memory (RAM), volatile memory, non-volatile memory, static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), flash memory, cache memory, or any other device capable of storing data. Mass storage memory device 36 may include a data storage device such as a hard disk drive, optical drive, tape drive, volatile or non-volatile solid state device, or any other device capable of storing data.

Processor 32 may operate under the control of an operating system 44 residing in memory 34. The operating system 44 may manage computer resources such that computer program code embodied as one or more computer software applications, such as application 46 resident in memory 34, may have instructions executed by the processor 32. Processor 32 may also execute applications 46 directly, in which case operating system 44 may be omitted. The one or more computer software applications may include an running instance of an application including a server that may accept requests from and provide responses to one or more corresponding client applications. One or more data structures 48 may also reside in the memory 34 and may be used by the processor 32, the operating system 44, and/or the applications 46 to store or manipulate data.

The I/O interface 38 may provide a machine interface that operably couples the processor 32 to other devices and systems, such as the network 22 or external resources 42. As such, applications 46 may cooperate with network 22 and/or external resources 42 through communications via I/O interface 38 to provide various features, functions, applications, processes, or modules that comprise embodiments of the present invention. The application 46 may also have program code that is executed by one or more external resources 42 or otherwise rely on functionality or signals provided by other systems or network components external to the computer 30. Indeed, in view of the virtually limitless hardware and software configurations possible, it should be appreciated that embodiments of the invention may include applications external to computer 30, distributed among multiple computers or other external resources 42, or provided by computing resources (hardware and software) provided as services on network 22, such as cloud computing services.

The HMI 40 may be operably coupled to the processor 32 of the computer 30 to enable a user to interact directly with the computer 30. HMI 40 may include a video or alphanumeric display, a touch screen, speakers, and any other suitable audio and video indicators capable of providing data to a user. HMI 40 may also include input devices and controls, such as an alphanumeric keyboard, pointing device, keypad, buttons, control knobs, microphones, etc., capable of accepting commands or inputs from a user and transmitting entered (enter) inputs to processor 32.

Database 50 may reside on mass storage memory device 36 and may be used to collect and organize data used by the various systems and modules described herein. Database 50 may include data and supporting data structures that store and organize the data. In particular, databases 50 may be arranged in any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, an object-oriented database, or a combination thereof.

A database management system (in the form of a computer software application executing as instructions on processor 32) may be used to access data stored in records of database 50 in response to queries, where the queries may be dynamically determined and executed by operating system 44, other applications 46, or one or more modules. Although embodiments of the invention may be described herein using relational, hierarchical, network, object-oriented, or other database terminology in particular instances, those of ordinary skill in the art will understand that embodiments of the invention may use any suitable database management model and are not limited to any particular type of database.

In the context of air travel, a "market" may refer to a single trip between a particular origin and a particular destination (or origin-destination pair). The demand for slots in the market may refer to the number of slots a customer would subscribe to in the market if the offer were unlimited. The slots in the market may extend across multiple flights and/or providers. The inventory of the provider may contain all flights with their available seats. The empty space may be distinguished from the seat based on the concept of oversubscription. Oversubscription refers to the fact that the provider has more room than the actual seat reservation on the flight in the event that some of the reservation's room is expected to be unused because the passenger fails to appear at the departure. Demand may depend on factors such as the price of the vacancies and the time the vacancies leave the starting point. For example, demand in a particular market may vary based on price, day of the week for a flight, and/or time of year.

A segment may refer to an operation of an aircraft between a point where a passenger first gets on the aircraft and another point where the passenger finally leaves the aircraft. A zone may include any number of stops at which passengers may leave and board the same aircraft. A leg (leg) may refer to the operation of an aircraft from one planned departure station to its next planned arrival station. Thus, a section may include one or more legs flown by a single aircraft.

A flight may refer to the operation of one or more sections with the same flight indicator, and may involve more than one aircraft. A travel scenario may refer to a combination of one or more flights that provide a one-way travel from a particular origin to a particular destination and leave the origin at a particular time. Thus, a travel plan may include specific travel instances between an origin and a destination. Travel plans that match the search terms of the search query may be returned as search results, and if a slot is available on the travel plans, the slot may be reserved by the searcher for travel from the origin to the destination.

Fig. 3 depicts a data warehouse system 60 that may include one or more of a query database 14, a reservation history database 16, a data warehousing application 62, an inventory database 64, and/or a fare database 66. The data warehouse application 62 may be hosted (host) by the travel management system 12 or other suitable system and may provide reporting and data analysis functions. To this end, the data warehousing application 62 may include a data collection module 68, a demand prediction module 70, a vacancy allocation module 72, and a pricing module 74. These modules may retrieve current and historical data from the query database 14 and the predetermined history database 16, use such data to create analysis reports and/or data, and store the reports and/or data in one or more inventory databases 64 and fare databases 66. Such analysis reports and/or data may include demand forecast, pick-up curves, vacancy allocation recommendations, and/or pricing recommendations.

The data collection module 68 may retrieve current and historical data from the query database 14 relating to the number of search queries received for travel in each market and a history record from the predetermined history data database 16 relating to the number of slots booked in each market. The demand prediction module 70 may use the data collected by the data collection module 68 to predict the demand for vacancies in each market. These predictions may be used by the slot allocation module 72 to issue reports and/or allocate slots in the inventory database 64 and by the pricing module 74 to issue reports and/or set fares in the fare database 66. In an embodiment of the invention, the fare database 66 may be managed by an ATPCO.

The slot allocation module 72 and the pricing module 74 may operate cooperatively to maximize operator revenue by establishing multiple fare classes within each market serviced by the operator, allocating inventory of the operator among the classes, and setting prices for inventory units (e.g., slots) in each class. The demand prediction module 70 may monitor demand for tickets within each fare class relative to the predicted demand and update the demand prediction based thereon. The available inventory in each market for each fare class for each flight and the pricing for each fare class in turn may be adjusted by the slot allocation module 72 and the pricing module 74 based on updated demand predictions. The purpose of the slot allocation module 72 and the pricing module 74 may be to allocate enough inventory for the discounted fare passengers such that each aircraft is fully loaded, but not so much inventory is allocated to the earlier booked discounted fare passengers that any later booked full fare passengers cannot reserve slots on the flight.

If demand is accurately predicted, the slot allocation module 72 and the pricing module 74 may set the price and allocate inventory in a manner that allows each flight to be full or nearly full without rejecting any full fare passengers by selling tickets to discounted fare passengers. Conventional systems may predict future demand based primarily on historical demand for vacancies in each market. This dependence on previous demands may lead to prediction errors. Prediction errors may result in sub-optimal allocation of available capacity between markets and between classes within each market.

For example, if the predicted demand is less than the actual demand, too many vacancies may be made available for discounted passengers. This may result in a void being sold earlier, so that after-booked full fare passengers cannot purchase tickets. On the other hand, if the predicted demand is greater than the actual demand, too little room may be provided to the discount passenger early enough during the booking. When the predicted demand fails to be fulfilled, this may result in the aircraft starting with a vacancy. Prediction errors may also result in suboptimal pricing of inventory. For at least these reasons, the prediction error may result in the provider receiving less revenue than would be possible if the demand was accurately predicted.

Prediction and optimization may provide two sets of information that may be used for revenue management. The forecast may predict how many slots will be reserved in the marketplace and when reservations will occur with respect to departure times. The optimization may determine how much room is available in each booking class in the market and when room is available for booking, i.e., when each booking class is opened and closed, based on the predicted demand.

Because the allocation of vacancies and pricing decisions are rooted in the forecast demand, accurate demand forecast has a direct impact on the operation of the data warehouse system 60. The operator may use the predicted demand to determine the amount of capacity to supply. Recent predictions may be used to make decisions such as allocation and pricing of capacity between predetermined classes for scheduled flights. Long-term predictions may be used to make decisions regarding bidding routes, which markets to enter, and the number and types of devices to purchase or rent.

Referring now to Table 1, an exemplary pick-up table for reservations for flights that depart in a particular market is depicted. For example, table 1 may be generated using data stored in the predetermined history database 16. The depicted pick-up table includes columns and rows defining cells, each cell including data associated with the rows and columns defining the cell. Each cell may be associated with a pointer to a memory location storing data in the cell. The data may be calculated from data stored in the predetermined history database 16 as needed, or may be calculated in advance and stored in a memory.

The data in each cell may define a number of slots reserved in the market at a specified time before the end of the reserved period (e.g., a reserved number of slots x days before departure), where the specified time corresponds to a respective column. The columns may be arranged in order of increasing pre-departure time amounts, with the leftmost column (e.g., column a) corresponding to the shortest amount of time until departure (e.g., one day) and the rightmost column (e.g., column I) corresponding to the longest amount of time until departure (e.g., 360 days). The number of slots in each cell may be for slots that start during a departure interval (e.g., all flights that depart daily) corresponding to the respective row of the cell. In embodiments of the present invention, the data in the pick-up table may also include slots that are scheduled to be launched. That is, the table may include data for flights that have not yet been taken.

The reservation period may define a length of time during which a slot may be reserved for a departure during a corresponding departure interval. A typical reservation period may cover a relatively long period of time, e.g., 6 to 12 months, while a typical departure interval may cover a relatively short period of time, e.g., one to seven days. The reservation period may be covered by the columns of table 1 such that the rightmost column (e.g., column I) represents the earliest time before departure at which the travel plan may be reserved (e.g., one year before the departure date). It should be understood that the predetermined time period, departure interval, number of rows and columns of table 1 are for illustrative purposes only and embodiments of the present invention are not limited to any particular duration or size of table.

Each column may correspond to a sample time before or at the departure date of the empty in the corresponding row. These sampling times may be equally spaced (e.g., in intervals of days or weeks), or staggered, with spacing varying as the specified time until departure decreases (e.g., such that the spacing between columns decreases as the departure date approaches).

As an example of the staggering time, column a may represent the total number of slots reserved until the departure of flights that were departure during the departure interval (e.g., all flights that were departure on "0" day, "1" day, etc.), column B may represent the total number of slots reserved 7 days before the departure, column C may represent the total number of slots reserved 14 days before the departure, column D may represent the total number of slots reserved 21 days before the departure, column E may represent the total number of slots reserved 28 days before the departure, column F may represent the total number of slots reserved 60 days before the departure, column G may represent the total number of slots reserved 90 days before the departure, column H may represent the total number of slots reserved 180 days before the departure, and column I may represent the total number of slots reserved 360 days before the departure.

The departure interval may correspond to the length of time between each row of table 1 and may define a sampling rate for analyzing the reservation. The departure interval may be different from the spacing of the sampling times or may coincide with the spacing of the sampling times. For example, if the distance between sampling times and the departure interval are one day for a travel scenario, the departure interval will coincide with the sampling time distance.

For the above exemplary values with a sampling time of one week and a departure interval of one day, the cells defined by row 0 and column a of table 1 will indicate that a total of 100 seats have been booked at departure for the flight that departed on day 0, which may be the nearest departure interval available for which all slots of the travel itinerary have been departed. The cells defined by row 0 and column B of table 1 will further indicate that 60 seats were reserved on the flight from day 0 one week prior to day 0 (i.e., days-7). This may indicate that 40 seats were reserved for flights starting on day 0 during the last week of the reservation period. Similarly, the cell defined by row-1 and column A of Table 1 will indicate that a total of 96 seats are reserved up to the departure time on the flight that departs from departure interval-1, which will be the day preceding departure interval 0 (i.e., day-1).

Quantitative predictions may use historical data to predict future demands. This type of prediction may be based on the assumption that historical trends will persist. Quantitative predictions may use time-based statistical methods (such as trend prediction and moving averages) to predict future demands based on historical data. Using the data in table 1 as an example, one type of quantitative analysis may determine the average number of reservations picked up between sample times (e.g., between A, B, C and D) for departure intervals that have taken off (e.g., departure intervals 0, -1, -2, -3, and-4). Reservation pick PU between sampling times x and y for a particular departure interval D _D Can be expressed as:

PU _D (x,y)＝N _D (y)-N _D (x) Equation 1

Average pick PU _AVG The following equation may be used to determine:

where n is the number of departure intervals for which an average value is determined. It should be appreciated that equations 1 and 2 are merely exemplary, and that other methods of determining demand may be used by embodiments of the present invention. For example, the average value may be weighted based on how recently the data was weighted, or simply determined by summing the subscriptions that start on days of the week that match the estimated departure interval of the subscriptions.

The above method is applied to the exemplary numbers in table 1 by adding the reserved pickup number to the existing reserved number in the cell of the departure interval (e.g., departure interval +4, +3, +2, +1) to be taken off to expect that the predetermined number to be received will produce the results as shown in table 2.

Referring now to fig. 4 and for illustration purposes only, an exemplary graph 80 includes a horizontal axis 82 corresponding to the number of days until departure and a vertical axis 84 corresponding to the number of reserved slots normalized to the total number of reserved slots at departure. It should be appreciated that the proportions of the horizontal axis 82 and the vertical axis 84 may be varied in order to more clearly describe embodiments of the present invention.

The graph 80 includes a pick-up curve 86 that may represent a low fare booking and a pick-up curve 88 that may represent a full fare booking. The demand prediction module 70 may generate pick-up curves 86 and 88 by analyzing a predetermined record of the departure flight. These reservation records may be selected from a pool of records stored in the reservation history database 16 to predict demand for a particular market or combination of markets. Each of the pick-up curves 86, 88 may be based on historical data collected from flights from the market or markets being analyzed. While, for clarity, this example depicts pick curves for two subscription classes, it should be understood that embodiments of the present invention may use curves for any number of subscription classes.

/>

As can be seen from the relative positions of the pick-up curve 86 and the pick-up curve 88, in this example, the reservation of discounted fare slots relative to the departure time of the flights tends to occur earlier than the reservation of full fare slots. To predict future demand in the marketplace, the demand prediction module 70 may generate a "model" pick-up curve based on a weighted average of pick-up curves for several reservation classes. For example, in a given market, the model pick-up curve may be provided by:

f _m (t)＝w ₁ ×f _F1 (t)+w ₂ ×f _F2 (t)

Wherein t represents the time until departure, f _m (t) represents a model pick-up curve, f _F1 (t) represents a pick-up curve for slots reserved in a predetermined class (e.g., full fare slots), f _F2 (t) a pick-up curve representing reserved slots (e.g., discounted fare slots) in another reservation class, w ₁ The representation applies to f _F1 Weights of (t) and w ₂ The representation applies to f _F2 The weight of (t). For example only, in a particular market having a full fare reservation class and a discounted fare reservation class, the weight applicable to the full fare reservation may be 0.30 and the weight applicable to the discounted fare may be 0.70.

Demand predictions based on historical reservations may be calculated for all flights scheduled to depart within a predetermined time frame, such as a year. The model pick-up curve may then be used to determine the remaining demand based on the time from departure. Such remaining demand may be provided to the slot allocation module 72 and the pricing module 74 to calculate an optimal slot allocation between the reservation classes and an optimal price for the slots in each reservation class.

Quantitative predictions may provide a useful tool for predicting future demands for vacancies in the market, but it may also have some drawbacks. For example, quantitative predictions may have limited capabilities for predicting demand in markets that are new to operators. Quantitative predictions may also fail to account for events that may affect demand, such as economic changes.

Table 3 depicts an exemplary pick table for search queries in a marketplace. Table 3 may be generated, for example, based on data stored in query database 14. The data in each cell of table 3 may define a number of slots for which a search query has been received prior to the time defined by the corresponding column for slots starting at the departure interval corresponding to that cell. A search query requesting more than one slot may increment data by an amount equal to the number of slots defined by the search query to reflect the number of slots requested. Thus, the data in each cell may correspond to the "strength" of the search query activity. Where the search query does not indicate the number of slots, the strength may be incremented by a default value (e.g., one slot).

As an example, assume that the departure interval and sampling time of table 3 are each equal to one day, the market represented by table 3 indicates new york as the origin and paris as the destination, and the departure interval "0" corresponds to day 2016, month 7, and day 4. Under this set of assumptions, a search query received at 30 of 2016 on a flight from New York to Paris beginning at 4 of 2016 on 7 may result in an incrementally higher number of search queries indicated by cells in row 0/column E than if no search query was received, e.g., 202 instead of 201 as shown (assuming the search query is for a single slot). As with tables 1 and 2, the search period, departure period, number of rows and columns of table 3 are for purposes of illustration, and embodiments of the present invention are not limited to any particular duration or size of table.

It has been determined that there is a positive correlation between the strength of the low fare search query and the number of subscriptions ultimately received. Because of this correlation between the strength of the search query and the number of subscriptions, statistics derived from the search query may be useful for predicting the needs. The statistical data may include, for example, a number of queries received for a particular origin and destination, the time each query was received, the difference between the arrival time and the requested departure date, or the "date from departure" for each query, or any other data describing the query and/or the context of the query.

Generating a pick-up profile using search query data may provide several advantages over using historical subscription data alone. One advantage may be that the amount of search queries typically significantly exceeds the number of seats reserved. This may allow robust statistics to be determined at a higher granularity than is possible with historical subscription data relative to both the analyzed time interval and market size. Another advantage may be that the number of current search queries may predict future needs in a more straightforward manner than historical subscription data. For example, because the amount of search queries is prospective, it can be useful to predict demand in markets that lack historical subscription data (e.g., markets that are new to the operator). The search query volume may also be responsive to events affecting demand, such as economic changes.

Referring now to FIG. 5, a graph 80 is depicted with an additional exemplary pick-up curve 90, which may represent search query data. In embodiments of the present invention, a pick-up profile based on search query data may be generated in each market for which demand is to be predicted. These pick-up curves may be analyzed to determine whether they improve predictions generated from historical reservation data for outgoing flights. If it is determined that the quality of predictions in a particular market is improved using the search query data, then the demand prediction module 70 may use the search query data to modify predictions in that market.

To achieve robust statistics (which typically require a large number of data points), predictions may be determined based on historical subscription data using data across a large number of issue dates. For example, pick-up curves based on historical subscription data, such as pick-up curves 86 and 88, may be based on departure occurring during one year. In contrast, since a relatively larger number of search queries for a trip are received in each market, search query data collected over a much shorter period of time may be used to obtain robust pick-up statistics, such as for a particular departure date.

For example, a pick-up profile (such as pick-up profile 90) based on data from query database 14 may be generated based on a subset of departure dates from which reservation data is fetched (draw) to generate reservation pick-up profiles (such as reservation pick-up profiles 86 and 88). These subsets may include specific days of the week (e.g., for search queries that start on tuesday), specific travel periods (e.g., the spring week), or even individual days (e.g., the day before the thanksgiving node). If the indication is that the prediction is to be improved by using the search query data, the model pickoff curve may be adjusted for flights not yet departure based on the query pickoff curve pattern that provides the best fit.

FIG. 6 illustrates a flow diagram of a process 100 that may be performed by the demand prediction module 70 to determine weight factors that may be used to incorporate search query data into the prediction process. In block 102, the process 100 may generate a reservation pickup curve for the market being analyzed. A marketplace may include flights from origin to destination, for example, according to a particular origin-destination pair. The average reservation pickup curve may be generated based on flights from the departure in the market during an analysis period (e.g., the previous year). The reservation pickup profile may be a normal pickup profile and may be generated using a reservation history to determine the number of reservations during an analysis period and when the reservations were made relative to the flight departure times in the marketplace.

In block 104, the process 100 may generate a query pick curve for the marketplace. The search query record may be used to generate a query pick-up curve to determine the number and/or strength of search queries received for flights departing in the marketplace. In embodiments of the present invention, the historical query pick-up profile may be based on statistics of search queries received for flights of the same departure used to generate the reservation pick-up profile. The query pick up curve may be generated using search query data from a complete analysis period (e.g., one year) or from a subset of analysis periods (e.g., one day, one week, or one month). In the case where a query pick-up curve is generated using a query for flights having departure dates on or during a subset of the analysis period, a pick-up curve may be generated for multiple subsets covering the entire analysis period. Process 100 may then proceed to block 106.

In block 106, the process 100 may determine a weight factor a. The weight factor a may have a value that produces a best fit between the composite pick-up curve and the target pick-up curve. The composite pick-up curve may be a weighted average of the reservation pick-up curve and the inquiry pick-up curve and may be provided by:

f _c (t)＝a×f _bpc (t)+(1-a)×f _qpc (t)

Wherein f _c (t) represents a composite pick-up curve, f _bpc (t) represents a reservation pickup curve, f _qpc (t) represents a query pick-up curve.

For the market being analyzed, the value of the weight factor α may be adjusted to provide a best fit between the composite pick-up curve and the target pick-up curve by minimizing the error function. For example, the value of the weight factor α may be adjusted to minimize a least squares error function, such as:

wherein f _T (t) represents a target pickup curve, t _start Is the starting point of the period of time in which the curves are compared, and t _end Is the end of the period in which the curves are compared. It should be appreciated that the above equations are for exemplary purposes only, and that other methods may be used to determine the weight factor α based on the composite pick-up curve and the target pick-up curve.

The target pick-up curve may be generated based on different types of data depending on how and/or when the curve is generated. For example, when a void on a flight is first available for purchase (e.g., the year immediately prior to departure), the amount of reservation and search data for the flight may be limited. In this case, the target pickup profile may be generated using reservation data of the departure flight similar to the analyzed flight.

As the departure date approaches, sufficient search data may become available to allow a target curve to be generated based at least in part on the search data for the flight or market being analyzed. If the target pick-up curve is significantly different from the composite pick-up curve, a new weighting factor may be determined by the demand prediction module 70. At some point, the number of reservations for the flights may also become sufficient to generate the target pick-up curve. As with the query reservation pickup curve, the demand prediction module 70 may recalculate the weight factor a if the reservation pickup curve for the flight in question appears to deviate significantly from the composite pickup curve.

In any case, once the compound curve f has been determined _c (a, t), the process 100 may proceed to block 108 and predict demand for future flights using a composite curve corresponding to a subset of analysis periods for which demand is being determined.

Process 100 may be performed for each departure date in each market. The historical back testing provided by the process 100 may allow for evaluation of the usefulness of search query logs in predicting future demand on a per market and per flight basis. The decision to use the search query data may be made based on whether the reverse test indicates that the search query data will improve demand prediction. This new data source may be particularly useful when the demand prediction module 70 is used to predict demand for a route (such as a new route) with limited historical reservation data.

Within a particular market, the number of bookings for flights to be made may be relatively limited. Thus, to provide a statistically robust reservation curve, reservation data for flights that depart may be aggregated over a relatively long period of time (e.g., departure date for each market or whole year of flights within the market). Because the number of search queries is typically much greater than the number of reservations for a particular market and/or flight, it has been determined that a much smaller subset of departure dates and/or flights may be used to generate a similarly robust query pick-up curve.

This feature of the query pick-up curve may allow the query pick-up curve to be generated and used to predict demand for a particular departure date. This may enable embodiments of the demand prediction module 70 to provide demand predictions that more accurately reflect customer behavior than revenue management systems that do not query the database 14 or generate pick-up curves using search query statistics. The demand prediction module 70 may also adjust the predicted demand during the prediction period. Adjustments may be made in response to determining that a prospective or "true" reservation or query pick-up curve deviates from one or more pick-up curves used to anticipate demand for a particular market, flight, or departure date.

Referring now to fig. 7, and for illustration purposes only, the exemplary graph 120 includes a horizontal axis 122 corresponding to the number of days until departure and a vertical axis 124 corresponding to the number of search queries/subscriptions received for the slots in the market. The number of search queries/subscriptions represented by the vertical axis 124 may be normalized to the total number of search queries/subscriptions received for the flight or market being analyzed up to the departure time.

Graph 120 includes a historical pickup profile 126 and an expected pickup profile 128. In an embodiment of the invention, the historical pickup curve 126 may be a historical query pickup curve used by the demand prediction module 70 to predict demand for a particular market and/or flight, and the expected pickup curve 128 may represent a partial pickup curve generated based on search queries received up to a current point in time for one or more flights in the market. In alternative embodiments of the invention, the historical pickup curve 126 may be a composite pickup curve used by the demand prediction module 70 to predict demand for a particular market and/or flight, and the expected pickup curve 128 may represent a partial pickup curve generated based on subscriptions received for one or more flights in the market to a current point in time.

In this example, the pickup curve 128 is expected to end at a point on the graph 120 corresponding to the point in time of 150 days prior to departure. For example, this point in time may reflect the most recent search query data available in query database 14, or the most recent subscription data available from one or more predetermined systems. As can be seen, the path of the expected pick-up curve 128 has begun to deviate from the historical pick-up curve 126. Such a deviation may indicate an error in the initial prediction of market demand, the occurrence of an event that has affected demand, or some other change in the market.

FIG. 8 illustrates a flowchart of a process 130 that may be performed by the demand prediction module 70 to identify and correct inaccurate predictions based on search query data for flights that have not yet been launched. In block 132, the process 130 may generate an expected pick-up curve for future departure dates in the market being analyzed. Because the expected query pick-up curve is prospective (i.e., the flight involved has not yet departed), the expected pick-up curve may be a partial pick-up curve, such as the expected pick-up curve 128 depicted in fig. 7.

In block 134, the process 130 may compare the expected pick-up profile to a historical pick-up profile (e.g., a historical query, composite, reservation, or target pick-up profile) used to generate the current demand forecast. Such a comparison may involve generating an error based on a deviation of the expected pick-up profile from the historical pick-up profile. For example, the error may be related to the area between the curves, the distance between the curves, or any other suitable parameter used to characterize the amount of deviation.

If the error does not exceed the predetermined threshold ("no" branch of decision block 136), then process 130 may end without changing the current demand forecast. If the error exceeds the predetermined threshold ("yes" branch of decision block 136), then process 130 may proceed to block 138. In block 138, the process 130 may select, generate, or determine a complete historical pick-up curve that matches the expected pick-up curve. For example, the process 130 may compare a plurality of previously generated historical pickup curves to an expected pickup curve and select the historical pickup curve that best fits the expected pickup curve. The process 130 may also use a partial curve matching algorithm to generate a complete historical pick-up curve based only on the expected pick-up curve.

In block 140, the process 130 may determine a new weight factor a by replacing the previously used historical pick-up curve with the complete historical pick-up curve. The process 130 may then proceed to block 142 to update the composite pick-up curve for the market being analyzed and generate a new demand forecast based on the updated composite pick-up curve. By providing a large number of data points related to the need for vacancies prior to the departure date, the search query log may enable robust statistics to be generated in the form of a query pick-up curve. These query pick-up curves enable more accurate predictions of future demand to be obtained, and may also allow correction of demand predictions due to unexpected changes in demand.

In general, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, object, sequence of instructions or module, or a subset thereof, may be referred to herein as "computer program code" or simply "program code". The program code typically includes computer readable instructions that reside at various times in various memories and storage devices in a computer, and when executed by one or more processors in the computer, cause the computer to perform the necessary operations to execute operations and/or elements embodying various aspects of embodiments of the invention. The computer readable program instructions for carrying out operations of embodiments of the present invention may be, for example, source code or object code written in assembly language or any combination of one or more programming languages.

Various program code described herein may be identified based upon the application for which it is implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature. Further, in view of the generally unlimited number of ways in which computer programs may be organized into routines, procedures, methods, modules, objects, and the like, and the various ways in which program functionality may be allocated among various software layers (e.g., operating systems, libraries), APIs, applications, applets, web-based services, etc.) residing in a typical computer, it should be appreciated that embodiments of the invention are not limited to the specific organization and allocation of program functionality described herein.

Program code embodied in any of the applications/modules described herein may be distributed, individually or collectively, as a program product in a variety of different forms. In particular, the program code may be distributed using a computer readable storage medium having computer readable program instructions thereon to cause a processor to perform aspects of embodiments of the present invention.

Computer-readable storage media, which are inherently non-transitory, may include volatile and non-volatile, as well as removable and non-removable tangible media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media may also include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technology, compact disc read-only memory (CD-ROM) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be read by a computer. The computer-readable storage medium should not be considered as a transitory signal itself (e.g., a radio wave or other propagating electromagnetic wave, an electromagnetic wave propagating through a transmission medium (such as a waveguide) or an electrical signal sent through a cable). The computer readable program instructions may be downloaded to a computer, another type of programmable data processing apparatus, or another device from a computer readable storage medium or an external computer or external storage device via a network.

Computer readable program instructions stored in a computer readable medium may be used to direct a computer, other types of programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function, act, and/or act specified in the flowchart, sequence diagram and/or block diagram block or blocks. The computer program instructions may be provided to one or more processors in a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the one or more processors, result in a series of computations being performed to implement the functions, acts, and/or operations specified in the flowchart, sequence diagram and/or block diagram block or blocks.

In some alternative embodiments, the functions, acts and/or operations specified in the flowchart, sequence diagram and/or block diagram block or blocks may be reordered, serially processed and/or concurrently processed consistent with embodiments of the present invention. Moreover, any of the flow diagrams, sequence charts and/or block diagrams may include more or less blocks than are shown in accordance with embodiments of the present invention.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the application. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, acts, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, acts, steps, operations, elements, components, and/or groups thereof. Furthermore, to the extent that the terms "includes," has, "" contains, "" consists of …, "or variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term" comprising.

While the present application has been illustrated by a description of various embodiments and while these embodiments have been described in considerable detail, it is not the intention of the inventors to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The application in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the inventors' general inventive concept.

Claims

1. A data warehouse system, comprising:

one or more processors; and

a memory coupled to the one or more processors, the memory storing first data comprising a first database of query log records and instructions that, when executed by the one or more processors, cause the system to:

receiving a plurality of search queries, each search query received at a time of receipt and defining a departure time and a origin-destination pair;

for each search query:

determining a time until departure from a time of receipt of the search query to a time of departure, and

second data indicating receipt of the search query and time to departure is stored in a query log record associated with the origin-destination pair,

wherein each query log record indicates, for a start-destination pair associated with the query log record, a number of slots and a time from departure associated with each slot;

receiving a request to provide statistics for a time period for a corresponding origin-destination pair;

in response to receiving the request, retrieving one or more query log records from a first database, each of the one or more query log records being associated with a respective origin-destination pair and including data related to a search query defining a respective departure time that falls within the time period;

Extracting second data from each of the retrieved query log records; generating a first pick-up curve based on the second data, the first pick-up curve depicting the strength of the search query for the respective origin-destination pair relative to the time from departure during the time period,

wherein the system tracks and provides data indicative of the receipt of a search query and the time from departure; and

the need for vacancies is predicted for the corresponding origin-destination pair using the first pick-up curve,

wherein the prediction uses historical search query data rather than individual historical subscription data to predict future needs.

2. The system of claim 1, wherein the instructions further cause the system to:

an index is defined that includes a plurality of fields, each field corresponding to a respective origin-destination pair, each field defining a location in the first database of each query log record associated with the respective origin-destination pair.

3. The system of claim 1 or 2, wherein the search query is a low fare search query.

4. The system of claim 1 or 2, wherein a departure time defined by each of the one or more query log records has elapsed upon receipt of the request.

5. The system of claim 1 or 2, wherein the time period covers a plurality of departure intervals, and the instructions cause the system to predict the need for room for the respective origin-destination pair using a first pick-up curve by:

querying a second database for third data defining a plurality of subscriptions to slots for respective origin-destination pairs that have been set out during the time period;

generating a second pick-up profile using the third data, the second pick-up profile depicting a predetermined number of times during the period of time relative to a time from departure; and

a third pick-up curve is generated as a weighted average of the first pick-up curve and the second pick-up curve,

wherein a third pick-up curve is used to predict the demand for vacancies for the corresponding origin-destination pair.

6. The system of claim 5, wherein the instructions further cause the system to, for at least one departure interval covered by the time period:

determining a fourth pick-up curve for the respective origin-destination pair;

determining a weight factor that provides a best fit between the third pickoff curve and the fourth pickoff curve; and

the need for vacancies is predicted for the corresponding origin-destination pair for the future departure interval using a third pick-up curve with weights providing the best fit,

Wherein the fourth pick-up profile is a target pick-up profile.

7. The system of claim 6, wherein the instructions further cause the system to, for each future departure interval:

determining a partial pick-up curve for the search query satisfied by the respective travel scenario for the respective origin-destination pair planning departure during the future departure interval;

determining a third pick-up curve having a best fit to the partial pick-up curve; and

using a third pick-up curve having a best fit to the partial pick-up curve, a demand for vacancies is predicted for the corresponding origin-destination pair for the future departure interval.

8. The system of claim 7, wherein each departure interval covers a day and the time period covers a year.

9. The system of claim 5, wherein the respective origin-destination pair is one of a plurality of origin-destination pairs comprising a travel network, and the instructions further cause the system to:

a separate first pick-up curve is generated for each of the plurality of origin-destination pairs for each departure interval.

10. A method of managing a data warehouse system, the method comprising:

Receiving, by the data warehouse system, a plurality of search queries, each search query received at a time of receipt and defining a departure time and a origin-destination pair;

for each search query:

wherein each query log record is stored in a first database and indicates, for a start-destination pair associated with the query log record, a number of slots and a time from departure associated with each slot;

extracting second data from each of the retrieved query log records;

Generating a first pick-up curve based on the second data, the first pick-up curve depicting the strength of the search query for the respective origin-destination pair relative to the time from departure during the time period,

wherein the method tracks and provides data indicative of the receipt of a search query and the time from departure; and

11. The method of claim 10, wherein the time period covers a plurality of departure intervals, and predicting a need for vacancies for a respective origin-destination pair using a first pick-up curve comprises:

12. The method of claim 11 further comprising, for at least one departure interval covered by the time period:

determining a fourth pick-up curve for the respective origin-destination pair;

wherein the fourth pick-up profile is a target pick-up profile.

13. A computer readable storage medium having stored thereon a computer program comprising program code for performing the method of any of claims 10 to 12 when the program is executed on a computer or computer system.