Patent Application
20080222566
This invention relates to travel scheduling and pricing, and more particularly to processing queries for air travel planning systems.
In travel planning such as for air travel scheduling and pricing, low-fare-search queries are posed by users from travel agent systems, airline reservation agent systems, travel web sites, and airline-specific web sites. Low-fare-search (LFS) queries typically include origin and destination information, time constraints and additional information including passenger profile and travel preferences. Travel planning computer systems respond to these LFS queries and typically return a list of possible tickets, each having flight and price information. Some systems return answers in a compact form such as through a pricing graph.
Most travel planning systems require each input LFS query to specify a narrow range of possible travel dates, e.g., one-day range, such as “depart anytime on August 2”, or perhaps a slightly longer range, such as “return on either August 9 or 10.” Most systems do not permit queries with more flexibility in their travel dates such as a query, “depart anytime in August.”
Some travel websites such as Travelocity® and Expedia®, provide a type of flexible-date query in the form of a “fare calendar.” The fare calendar technique requires a user to select one fare (for example, the United Airlines BOS-LAX fare with basis code QE14NR). The site will display a calendar indicating the available travel dates for flights using that particular fare.
There are several difficulties with handling “flexible travel date” queries. One difficulty is that the lack of precise date constraints imposes extensive computational requirements on the search engine answering the query. An airfare search can involve many flight combinations and correspondingly availability questions, fares, and rules to process. Another difficulty resides in a user interface. The user interface should allow users to easily pose queries that match their schedule's flexibility. In addition, the user interface should present query results in an informative and understandable manner. Another problem is that fare calendar technique, which requires the user to select a fare, is basically a trial-and-error approach makes the use of flexible date queries very time consuming and cumbersome for the user.
According to an aspect of the invention, an interface for travel planning includes a field that allows a user to enter a layover description that includes the duration of the layover at a destination.
According to an additional aspect of the invention, a method of processing flexible-date queries includes sending a flexible date query including a description of a traveler's desired layover at a destination, receiving a set of solutions that satisfy the flexible date query from executing the query using a search engine, and storing the set of solutions in a database. The method also includes retrieving a subset of the set of solutions to render to a user.
According to an additional aspect of the invention, an interface for travel planing includes a depiction of a calendar that represents in cells of the calendar search results for which a solution is found by using information pertaining to a complete, validated solution in each calendar cell for which a solution was generated.
According to an additional aspect of the invention, a computer program product residing on a computer readable medium for processing flexible-date queries includes instructions to cause a processor to send a flexible date query including a description of a traveler's desired layover at a destination, receive a set of solutions that satisfy the flexible date query and store the set of solutions in a database. The computer program product also includes instructions to retrieve a subset of the set of solutions to render to a user.
Unlike prior approaches to handle flexible date queries the present techniques avoid a long trial-and-error process of investigating fares and looking for a fare that provides availability on preferred dates. This present technique provides the possibility of using fare combinations (e.g., BOS-CHI plus CHI-LAX) or multiple airlines, either of which might result in a cheaper price than any available single fare.
The techniques provide a query form that allows users to specify a flexible range of outbound and return dates for their travel plans, using a specification of their preferred layover length. The technique stores results in a database for later retrieval and display. Results are conveyed to a user by use of a “results calendar” which displays an overview of the solutions on a calendar. On days for which results have been requested, information such as that day's cheapest available ticket price will be shown in the corresponding grid cell of the calendar. The information displayed in each grid cell of the calendar corresponds to properties of complete travel solutions, for which all rules and optionally availability have been checked, and for which a ticket can be issued. No trial-and-error on the part of the user is required.
Users can interact with the results calendar in a number of ways. For example, the user can use filters to select or deselect travel on certain airlines, travel involving one or more stops, etc., resulting in an update of the prices displayed in the calendar cells. The result calendar provides the ability to click on the price associated with a given day, and quickly see an overview of flight choices on that day, as well as a sampling of full, validated ticket options. Also the results calendar provides the ability to extend the query dates beyond those originally specified by clicking directly on the calendar. Special parameter settings can be used to control the performance of the underlying fare search engine.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
Referring to
The travel application 16 interprets queries 18 that arrive from the client 14, sends the queries 18 to a travel planning computer 20 and, organizes the results from the travel computer 20 into a formatted output such as HTML, and sends the results back to the client 14. The travel application 16 composes query information into an appropriately formatted query, e.g., a low-fare-search query 18, which is sent to a travel planning system 20. The travel planning system 20 includes a search engine or search process 21 that searches for flight and fare combinations that satisfy the flexible date query. The search performed by the search engine 21 in the travel planning systems 20 can use any of several know techniques, possible modified to include a query splitting process described below in
Referring to
The travel application 16 controls the input specification for the query. One approach would be to request four dates to be input by the user: earliest possible departure date, latest possible departure date, earliest possible return date, and latest possible return date. However, this approach would result in a number of trip combinations proportional to the product of the outbound date range and the return date range. In many circumstances where there are large values in those ranges the computation needed could overburden the search engine. For example, a user who proposed departing “anytime in July” and returning “anytime in August”, assuming 100 flight combinations per day serving the user's requested airports, would translate into a search request of 31*100*31*100 or nearly ten million flight combinations.
In practice a travelers' trips are constrained in duration, even if they are flexible in departure date. Practical queries of this type resemble the following:
“visit Daytona Beach for about a week sometime this winter”
“visit Burlington for a short weekend in October”
“go to Chicago for a day trip some day next week”
“get a one-way ticket to San Francisco anytime this month”
In each of these examples, while the range of possible travel dates is quite wide, the duration or length of time spent at the destination is specified with some precision. Accordingly, the graphical user interface 40 pane 41e for providing flexible-date queries includes a field 42 where users specify the approximate duration of the trip. Users may optionally enter an outbound date range. The GUI 40 can also include a field for entering an earliest departure date (not shown) and a field for entering a Latest departure date 43. The fields for entering an earliest departure date and latest departure date are optional fields. If an outbound range is not entered a default outbound date range can be used. One such default is “departing anytime between tomorrow and one month from today.”
The user specifies the desired duration in one of a number of manners that can be accessed via a scroll bar on the field 44. The forms of layover length include “a day trip”, “weekend trip”, “month-long trip”, and so forth. This specification is selected from a menu or entered in a text field. The GUI 40 also includes a origin field 46 and a destination field 48, each of which allows inclusion of additional airports with a user specified number of miles from the origin or destination. The GUI can also have fields 49 for specifying profile information, e.g., number of adults, seniors, youths, children, infants (in seat or lap). A “Go” button launches the query and sends it to the travel application 16 for transmission to the travel planning system 20.
The duration specification may include additional constraints beyond the length of the stay. For example, a layover specification of “one weekend” could be interpreted to mean a layover of duration 1 or 2 nights, departing only on a Friday or Saturday. A layover specification of “one-day business trip” could be interpreted to mean a same-day return, departing only on a non-holiday weekday. Each additional constraint reduces the computational burden on the search engine, increasing the number of answers that can be generated within a given search time. Furthermore, the additional constraints make it easier for the user to find a useful ticket option among the results presented. The GUI can also include user specific choices for layover length, e.g., under advanced options such as “one-way ticket only”, “one-day business trip”, “two-day business trip”, “one weekend”, “one long weekend”, “weekend to weekend”, “about one week”, “about two weeks”, “about three weeks”, “about one month”, and so forth (not shown).
With the layover length specified, the computational burden on the search engine is significantly reduced. For example, if a user proposed departing “anytime in July” and returning after a layover of “about one month”, assuming a range of 29-31 days for the layover and again assuming 100 flight combinations per day, the number of flight combinations in the search request would be 31*100*3*100—less than a million, for a tenfold savings over the approach mentioned above.
Referring now to
The travel application 16 queries the database 63 to retrieve 68 the “best” solution given a current set of user-specified filters, for each departure date. By default, the notion of “best” is defined simply as the cheapest among all solutions computed and which are not filtered out by user specified criteria. Other definitions for “best” can be defined, often based on the initial query parameters specified by the user. For example, if the user specified that only first class service solutions were desired, then “best” might be defined as the cheapest first-class solutions, rather than the cheapest solutions in any class of service.
The travel application 16 has a calendar generator 65 that generates 70 a results calendar, highlighting properties of the best solution(s) corresponding to each departure date, and sends 72 the results calendar to the user. The user may select or modify filters (for example, to filter out solutions involving particular airlines or solutions involving prop planes). The process 60 returns to retrieve (again 68) another set of best solutions, by retrieving from its database only the subset of solutions matching the new filter criteria. The user may augment the query (again 62), either by requesting additional solutions for a date that has already been considered, or by asking the system to extend the permissible date range to new dates. In either case the system writes (again 66) newly discovered solutions to the solution set stored in the database 63. The search engine 21 informs (again 64) the web server 17 that solutions have been written.
The solutions are stored in the database 63 for the duration of a user's session with the website. However, an extension could provide for the database 63 to be maintained across multiple users' sessions. This extension would involve inserting an additional action at the beginning process, e.g., the travel application checks database to see whether solutions to the user's query have already been stored; if so, then retrieve best solutions without having the search engine perform another search.
Because airline fares and seat availability change frequently, solutions are either pruned from the database 63 within a few hours of their having been generated, or refreshed by a follow-up query to the search engine 1, so as to avoid presenting solutions on the “results calendar” display that cannot be booked. The system could also regularly pose queries to the search engine (e.g., during times of excess search-engine capacity) for the purpose of “stocking” the database with up-to-date solution sets in commonly traveled markets.
The Results Calendar
Potentially, hundreds or thousands of travel solutions, spanning many different departure dates, are stored in the database 63. The system 10 (
The price of the best solution departing on that day, where “best” refers to the cheapest ticket meeting the user's cabin-class preference and other filters;
The primary airline(s) used by the best solutions departing on that day (represented by the airline's name, icon, or two-letter code);
The number of stops in the best solution departing on that day; and
An indication of the cabin class, origin and departure airports and times, and equipment type (for example, an icon of a propeller to denote a prop plane) associated with the best solution departing on that day.
Referring to
As illustrated in
With the airline tab 87a selected, the summary information in the table 87 is arranged in rows and columns with here enumerating the airlines that offer solutions for the date selected arranged in columns of the table as links, and each of the rows of the table 87 arranging specified travel options such as nonstop flights or one-stop flights, and so forth as links. Interior cells within the table 87 are links that correspond to prices for the solutions that match the user's airline and number of stops criteria. The table 87 displays a set of air travel options according to specified criteria, e.g., the airlines used in one or more of the travel options (displayed horizontally at the top of the table), and the number of stops or connections in the set of travel options (displayed vertically on the left of the table). Here, the travel options represented by a given table cell are those solutions which use the airline in the same column as that cell, and that have the same number of stops as the “number of stops” header in the same row as that cell. A third criteria, price (i.e. price of an airline ticket), is displayed in each cell of the table; this price is the minimum price for any of the travel solutions that are represented by a given cell.
Selecting a cell (by clicking on a URL in this case) displays, in a lower pane 89, a listing of the travel solutions for that particular cell. Each travel solution contains a ‘details’ URL link in the row of information devoted to that travel solution. Clicking on that link takes the user to a detailed description of that travel solution (not shown).
A general procedure to construct the summarizing tabs 87a and 87b is given below:
1) Obtain list of query-specific travel solutions from database.
2) For each criteria in travel solutions:
3) Given the bins computed in (2), compute which travel solutions go into intersecting bin pairs to determine what travel solutions go in what cells of the summary table.
4) Generate and display summary table given information from procedure (3).
When the flight time tab 87b is selected, the table 87 is arranged to show departure times between the origin and the destination over ranges of times for the potential days of travel in the outbound portion of the trip in rows of the table, as well as departure time for the return portion of the trip in columns of the table 87 over time ranges in the potential return days. Thus, selecting one of the outer peripheral cells of the table will bring up all flight options on a designated day in the designated time area; whereas selecting an interior one of the cells will produce the intersection of solutions for a time segment on the selected outbound date and the time segment of the selected return date. Each solutions table 87 cell displays the cost of the cheapest solutions for each pair of intersecting time segments, allowing a user to decide the most appropriate time to travel giving consideration such as cost and convenience.
Several approaches can be used to produce data for inclusion in the calendar results web pages.
Referring now to
The search engine parameters can be set so as to increase the diversity of solutions generated by the search engine. This helps ensure that each cell of the overview table is represented by at least one solution on each departure date. However, recognizing that many additional solutions are missing from the initially generated set, the interface provides a prominent link labeled, e.g., “Search for additional options like these.” This link is similar to the follow-up query as discussed in
Referring to
However, if the full set of solutions has not been completed the web server sends 114 a request for a single day query to the search engine. The search engine produces a diverse list of travel options according to a set of travel criteria such as carrier, departure or arrival times, time of day, origin, destination, airports and so forth. A diversity process can iterate through a set of travel criteria and select the best travel option for each criterion. When the search engine has determined a complete set of solutions, the search engine informs 116 the web server 21. The results are written 118 to the database 63 for use by the calendar generator 65 as just mentioned above.
It frequently occurs that the cheapest trip satisfying the user's query on some or all dates within the user's date range has some properties undesirable to the user. For example, the cheapest solution on some or all dates might be available only on “Undesirable Airlines”, or might involve an inconvenient number of connections en route to the destination. If the prices displayed on the calendar correspond only to these undesirable solutions, the calendar is less valuable to the user.
Referring to
The following is a partial list of criteria that may be applied as filters on the calendar's solution set:
The filters can be implemented as an advanced options link on the results page that can bring up another page (not shown) to allow users to input their preferences for these items.
When calendar filters are selected, the same filters are simultaneously applied to the single-day result page currently being displayed. In that way, the price highlighted on any given date of the calendar always corresponds to the cheapest price on that day's corresponding single-day result page.
Referring back to
For example, on dates for which the calendar shows no associated solutions, links are provided that cause a follow-up query to be posed to the search engine, filling the gap on that date. A second type of extending link would be that on the column headings of each calendar, corresponding to the weekdays of that month, a link is provided that causes all weekdays in that month to be added to the dates under consideration. When that link is followed, any dates not already filled in are resubmitted to the search engine, filling any gaps on that weekday. A third type would be on the row headings of each calendar, corresponding to a given departure week, a link provides for an automatic follow-up query to the search engine to fill in the empty cells corresponding to days during that week. In addition, links can be provided to enable the user to add an additional month's calendar, immediately prior to or subsequent to the displayed calendar(s). When a new month is added, all dates on that month are shown as blank initially, with links provided as in (1)-(3) above to fill in the blank dates. Alternatively, the system may submit a follow-up query to fill part or all of the newly displayed month with solutions.
The departure date information of the query is modified when the query is resubmitted. All other query fields, such as the passenger information, airport preferences, and layover specification, are preserved. As before, the newly generated solutions are added to the solutions database for subsequent interactions.
Search Engine Parameters for Flexible-Date Queries
Although using a layover specification helps to constrain the amount of searching that the search engine performs, flexible-date queries still involve searching many more flight options than a standard, single-day query. As such, the flexible date queries are likely to require more computation time. Several techniques can be used to limit the search, while not compromising the ability of the system to generate useful, fully validated solutions.
One such technique would be to limit the search according to flight-itinerary diversity. In normal, single-day operation, a search engine may consider as many as 1000 of the most convenient flight combinations between the user's origin and destination. To handle flexible-date queries quickly, this number is reduced to a few dozen per day, representing only the most convenient options on a sampling of carriers.
Another solution would be to limit the search according to seat availability. When there are multiple flight-combinations on a given day on a given airline, the one with the cheapest price is usually the one with the most seat availability. The system checks the seat availability on all flight-combination options and prunes out those with lower seat availability. The result is that the search space shrinks, while the best answer for each airline on each date is most likely preserved. A third possibility is to limit the search by fare. Airlines typically publish dozens, and sometimes as many as hundreds, of different fares for each city-pair that they serve. Significant reduction in computations can be attained by eliminating some of these fares from consideration—for example, all first-class and business-class fares.
Another way would be to limit the search by construction. On an itinerary such as United:BOS-CHI-LAX, it is usually possible to fare the itinerary either as a BOS-LAX “through fare”, or as the sum of a “BOS-CHI” fare and a “CHI-LAX” fare. Eliminating the latter faring, and requiring only through fares to be used in the search would result in significant reductions in computations.
An additional technique would be to limit the search by priceable unit type. Airline fare construction principles require all tickets to be broken down into sub-units called priceable units, of which there are four types: one-way, round-trip, open-jaw, and circle-trip. Open-jaw and circle-trip units sometimes result in the cheapest solution even on a simple round-trip journey, but usually one-way and round-trip priceable-units suffice. The faring process can be sped up by eliminating open-jaw and circle-trip priceable units from consideration.
Another technique to reduce latency of low fare searching uses query splitting. Query splitting involves dividing the query among several different processors in a “farm” of low-fare search engines, as discussed in
Referring to
The answers for each sub-query may be collected and organized by the answer collator 25 using a number of different techniques. If the form of the sub-query results is a simple list of travel options, the collation process used by the answer collator 25 may simply involve concatenating the answers from each sub-query. However more complex collations schemes are possible, such as selecting a subset of answers from each sub-query (such as the cheapest travel options from amongst all of the answers and so forth). Alternatively, if the query division process 12 produces sub-queries that overlap, the collation process 25 could remove duplicate answers. In the case where the travel planning computers produce answers in other forms, such as a pricing graph representation, other methods of collation may be used. For example, multiple pricing graphs can be merged into one by joining them with an OR node. It may also be that no collation process is used, so that answers for the different sub-queries are returned to the travel application as soon as they are available, rather than waiting for all sub-queries to complete.
When queries are split using this technique, the user-interface can display the results on the calendar progressively, as the sub-queries finish and results are returned using dynamically generated animated-GIF images and image maps.
Algorithms for performing such query splitting are described in co-pending patent application Ser. No. ______ Filed Entitled ______ “Split Travel Queries” by assigned to the assignee of the present invention.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10272521 | Oct 2002 | US |
| Child | 12044028 | US |
