WO2008086150A2 - Fourniture d'informations de voyage à l'aide d'une base de données cache à couches - Google Patents

Fourniture d'informations de voyage à l'aide d'une base de données cache à couches Download PDF

Info

Publication number
WO2008086150A2
WO2008086150A2 PCT/US2008/050188 US2008050188W WO2008086150A2 WO 2008086150 A2 WO2008086150 A2 WO 2008086150A2 US 2008050188 W US2008050188 W US 2008050188W WO 2008086150 A2 WO2008086150 A2 WO 2008086150A2
Authority
WO
WIPO (PCT)
Prior art keywords
travel
pricing
query
user
database
Prior art date
Application number
PCT/US2008/050188
Other languages
English (en)
Other versions
WO2008086150A3 (fr
Inventor
Carl G. De Marcken
Original Assignee
Ita Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/650,358 external-priority patent/US20080167909A1/en
Priority claimed from US11/650,327 external-priority patent/US20080167907A1/en
Priority claimed from US11/650,296 external-priority patent/US20080167912A1/en
Priority claimed from US11/650,360 external-priority patent/US20080167910A1/en
Priority claimed from US11/650,301 external-priority patent/US20080167906A1/en
Priority claimed from US11/650,312 external-priority patent/US7711587B2/en
Priority claimed from US11/650,342 external-priority patent/US20080168093A1/en
Priority claimed from US11/650,351 external-priority patent/US20080167908A1/en
Priority claimed from US11/650,324 external-priority patent/US20080167886A1/en
Priority claimed from US11/650,325 external-priority patent/US20080167887A1/en
Application filed by Ita Software, Inc. filed Critical Ita Software, Inc.
Publication of WO2008086150A2 publication Critical patent/WO2008086150A2/fr
Publication of WO2008086150A3 publication Critical patent/WO2008086150A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Definitions

  • This disclosure relates to travel scheduling and pricing, and more particularly to processing low-fare search queries for air travel planning computer systems.
  • TPSes Conventional travel planning systems
  • fundamental travel units include "flights” (sequences of regularly scheduled takeoffs and landings assigned a common identifier) and "fares” (prices published by airlines for travel between two points).
  • the term “itinerary” refers to a sequence of flights on particular dates and the term “pricing solution” refers to a combination of fares and itineraries.
  • travel 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 may include additional information such as passenger profile and travel preferences. TPSes respond to these LFS queries and typically return a list of possible travel options of a flight combination with price information.
  • LFS Low- fare-search
  • TPSes expend considerable computational resources responding to LFS queries. It is not uncommon for a TPS to spend more than 30 seconds responding to an LFS query, even for a relatively straightforward round-trip query leaving and returning from specific airports on specific dates. This delay is undesirable for the user of the system, as it reduces interactivity.
  • the computational cost of responding to LFS queries is burdensome to the TPS and as a consequence it is economically impractical for the TPS to respond to queries without remuneration, reducing the range of uses for which the TPS can be used. For these reasons, it is desirable to reduce the marginal cost of answering an LFS query.
  • the invention provides systems and methods, including computer program products, for travel planning.
  • the invention features a system for storing cached results for travel planning.
  • the system includes a database storing cached results provided from querying a travel planning system with travel queries specifying travel parameters of trips, the cached results including schedule and fare information; and a processor configured to store data from the cached results in records in the database, the records including fields corresponding to predefined categories of the schedule and fare information; define a super-category of at least two of the predefined categories, the super-category including at least a portion of schedule and fare information from the at least two of the predefined categories; and index the records by the super- category.
  • the invention features a system for travel planning.
  • the system includes a database configured to store query answers received from a travel planning system, the query answers including schedule and fare information satisfying parameters of previous travel queries; and a processor configured to receive a travel query specifying travel parameters of a trip of interest for a user and construct a first pricing solution according to the travel parameters of the trip of interest, from a combination of the query answers.
  • the invention features a method and a computer program product for configuring a database.
  • the method includes storing cached results provided from querying a travel planning system with travel queries specifying travel parameters of trips, the cached results including schedule and fare information; storing data from the cached results in records in the database, the records including fields corresponding to predefined categories of the schedule and fare information; defining a super-category of at least two of the predefined categories, the super- category including at least a portion of schedule and fare information from the at least two of the predefined categories; and indexing the records by the super-category.
  • the invention features a method and a computer program product for travel planning.
  • the method includes storing query answers received from a travel planning system, the query answers including schedule and fare information satisfying parameters of previous travel queries; receiving a travel query specifying travel parameters of a trip of interest for a user; and constructing a first pricing solution according to the travel parameters of the trip of interest, from a combination of the query answers.
  • Embodiments may include one or more of the following.
  • One of the predetermined categories may be a departure date specifying a day and a month of a scheduled departure, and the new category may be a departure date specifying only a month of a scheduled departure.
  • One of the predetermined categories may be an origin airport and the new category may be a city in which the origin airport is located.
  • One of the predetermined categories may be an origin airport and the new category may be a country in which the origin airport is located.
  • the fields corresponding to a first category may be deleted from the records.
  • Pricing solutions may be computed for the records; a cheapest pricing solution may be determined from the computed pricing solutions; an identifier of the new category and the cheapest pricing solution may be stored in a data structure; and the database may be configured to retrieve the cheapest pricing solution in response to receiving a travel query specifying a parameter that matches the new category and that is broader than a first category.
  • the cheapest pricing solution satisfying the travel parameters may be updated.
  • Timestamps may be assigned to the records, the timestamps indicating a time at which the data from the cached results is stored.
  • a plot of pricing information as a function of time may be constructed using the timestamps.
  • Query answers may be associated with one-way trips and the first pricing solution may be associated with a trip that includes the one-way trips.
  • the query answers may correspond to cheapest fares.
  • Taxes associated with the first pricing solution may be computed along with a final price of a ticket associated with the first pricing solution.
  • a second pricing solution may be constructed using the first pricing solution. Constructing the first pricing solution may include combining the one-way trips to produce a round trip or combining the one-way trips to produce an open jaw trip.
  • FIG. 1 is a block diagram of a travel planning system including a cache database.
  • FIG. 2 is a flowchart of a process for populating the cache database.
  • FIG. 3 is a flowchart of an alternative process for populating the cache database.
  • FIG. 4 is a flowchart of a process for updating the cache database.
  • FIGS. 5A-5B are flowcharts of processes for updating the cache database.
  • FIG. 6 is a flowchart of a process for determining availability of cached results.
  • FIG. 7 is a flowchart of a process for loading data in to the cache database.
  • FIG. 8 is a diagram depicting data loading.
  • FIG. 9 is a flowchart of a process for constructing answers to queries using a combination of cached results stored in the cache database.
  • FIG. 10 is a block diagram of an exemplary cache database.
  • FIGS. 1 IA-I IB is a flowchart of a process for configuring data stored in the cache database.
  • FIG. 12 is a flowchart of a process for extracting information from the cache database.
  • FIGS. 13A-C are flowcharts of processes for supplying travel information to a user.
  • FIG. 14 is flowchart of a process for answering a flexible query.
  • FIG. 15 is a flowchart of a process for presenting travel information to a user based on travel parameters anticipated to be of interest to the user.
  • FIG. 16 is a flowchart of a process for anticipating a travel parameter based on location identification found in a cookie.
  • FIG. 17 is a flowchart of a process for anticipating a travel parameter based on identification information of origin of an electronic communication sent by the user.
  • FIG. 18 is a flowchart of a process for anticipating travel parameters for a user based on popular travel parameters.
  • FIG. 19 is a flowchart of a process for anticipating travel parameters from information related to prior searches performed by the user.
  • FIG. 20 is a flowchart of a process for anticipating travel parameters based on properties of the cached results stored in the cache database.
  • FIG. 21 is a diagram of a display for presenting travel information to a user.
  • FIG. 22 is a flowchart of a process for anticipating travel parameters based on preferences specified by a user.
  • FIG. 23 is a diagram of a display for presenting travel information to a user.
  • FIG. 24 is a flowchart of a process for presenting summaries of travel information to a user based on known origin and destinations of interest for the user.
  • FIG. 25 is a flowchart of a process for receiving user preferences via entry forms.
  • FIG. 26 is a diagram of a display for presenting travel information to a user.
  • FIG. 27 is a flowchart of a process for replicating a travel planning application with parameters .
  • FIG. 28 is a diagram of an interface for presenting travel information to an attendee from a conference home page.
  • FIG. 29 is a diagram of an interface for presenting travel information to a user from a web page affiliated with lodging or other services having time-varying availability or price.
  • FIG. 30 is a flowchart of a process for presenting travel information to a user based on detecting a change in one or more cached travel options.
  • FIG. 31 is a flowchart of a process for presenting travel information to an enterprise based on a change in price of a flight operated by a competitor of the enterprise.
  • FIG. 32 is a flowchart of a process for presenting travel information in streaming form.
  • FIG. 33 is a flowchart of a process for notifying a user of changes to travel information.
  • FIG. 34 is block diagram of the subscription database
  • FIGS. 35 A-B are flowcharts of a process for reporting changes to the best available price of a travel option.
  • FIG. 36 is a flowchart of a process for detecting errors and unusual behavior in a travel planning system.
  • FIGS. 37A-B are flowcharts of a process for advertising a service or product to a user. DETAILED DESCRIPTION
  • TPSes take time to compute answers to LFS queries, limiting the dissemination of such information to modalities where delays are acceptable (this, for example, prevents the inclusion of results on the home pages of web portals, as it would not be acceptable for the display of other information on such pages to be delayed).
  • Described below are structural and operation features of a travel planning system that includes a cache database to permit relatively low cost and low latency dissemination of travel information, including examples of business applications supported by the system.
  • a cached-based travel planning system 10 includes a caching system 11 coupled to a client 16 via a network 20 (e.g., a LAN, WAN, the Internet.
  • a network 20 e.g., a LAN, WAN, the Internet
  • the caching system 11 includes a user preferences database 30, a subscription database 31, a web server 26, a cache database 28, and a pricing-graph database 48.
  • the web server 26 includes a poller program 36 and an availability merger 46.
  • the cache database 28 interacts with a conventional travel planning system 12 through the poller program 36 running on the web server 26.
  • the poller program 36 preemptively poses LFS queries 22 (also referred to as TPS queries 22) to a travel planning system (TPS) 12.
  • the LFS queries 22 are not solicited by users but rather are formulated and maintained by the poller 36.
  • the LFS queries 22 include travel parameters such as origins, destinations, travel dates and other preference or conditions of travel (e.g., non-stop, first class, carrier, etc.).
  • the TPS 12 includes a search engine 14 that searches fare and flight information in travel databases 38 and constructs answers 24, which include pricing solutions (also referred to as travel options), from the flight and fare information. Those answers 24 that satisfy the LFS queries 22 are stored in the cache 28 as cached results 42.
  • the travel databases 38 contain schedule information provided by carriers, typically in the so-called Standard Schedules Information Manual (SSIM) format, fares published by carriers and resellers, and fare rules that govern how and whether fares can be used with flights.
  • SSIM Standard Schedules Information Manual
  • fares published by carriers and resellers and fare rules that govern how and whether fares can be used with flights.
  • the fare and fare rule information are typically provided through an intermediary, The Airline Tariff Publishing Company (ATPCO).
  • ATPCO Airline Tariff Publishing Company
  • the databases 38 may also contain "availability" information that is used to predict whether space is available on flights, or availability information may be obtained through communication links to external sources such as revenue management systems of airlines.
  • the TPS 12 is a conventional computer reservation system (CRSs), Sabre®, Galileo®, Amadeus®, and WorldSpan®.
  • Some availability information, e.g., flight availability may be more accessible than other availability information, e.g., seat availability, which can change more rapidly. For example, seat availability typically changes more quickly than flight availability.
  • the TPS can be systems such as Orbitz, Expedia, Travelocity and other systems that typically operate over the Internet.
  • the travel options retrieved from the travel databases 38 are referred to as "answers” 24 and include information such as flights, (flight number, airline, etc.) and fares that can be used with the flights.
  • the web server 26 receives the answers 24 from the TPS 12, processes the answers, and stores the answers in the cache database 28.
  • the processed answers 24 stored in the cache database are referred to as "cached results" 42.
  • the cached results 42 stored in the cache database 28 may include all or a portion of the answers 24 returned from the TPS 12.
  • a cached result 42 can include a set of answers 24 or correspond to a single answer 24.
  • the cached results 42 in the cache database 28 are obtained in response to TPS queries 22, which are either performed preemptively, e.g., by the poller 36 or in response to user supplied travel planning queries 18.
  • the cached results 42 may include pricing solutions and/or information associated with pricing solutions (e.g., the lowest price for a particular fare).
  • the availability merger 46 checks seat availability of an initial answer 24 returned from the TPS 12 before storing it as a cached result 42 in the cache database 28.
  • a user Independently of the poller program 36, at a web browser 32 of a client computer 16, a user specifies travel parameters of trip of interest in a travel query 18.
  • Examples of one or more travel parameters of the travel query 18 include origins, destination, travel dates and other preferences or conditions of travel requested by the user, e.g., nonstop, first class, etc.
  • the client 16 sends the query 18 to the web server 26, via the network 20.
  • the web server 26 searches the cache database 28 for cached query results 42 that satisfy the travel parameters of the query 18.
  • the cached results 42 that satisfy the user's query 18 may be referred to as "qualifying cached results 42.”
  • the qualifying cached results 42 are returned to the client 16, at which they are presented to the user through the web browser 32.
  • a qualifying cached result 42 is substituted for an actual answer 24 that would be received directly from the TPS 12 had the TPS 12 actually processed the query 18 immediately after the query 18 had been posed.
  • the travel planning system 10 reduces marginal costs and latency involved with directly querying the conventional TPS 12.
  • the cache database 28 may be used for a variety of applications including responding to specific questions posed by users at a travel agent or airline web site, performing historical price analysis, triggering notifications to users of trips of interest, alerting airlines of prices below expected market thresholds, and so forth.
  • the system 10 shown in FIG. 1 could be implemented in the context of a variety of business applications in which revenue is derived from various parties.
  • the answers 24 retrieved from the TPS 12 may be represented as a pricing graph (i.e., a compact representation including nodes corresponding to flights and fares that can produce travel itineraries of the answers 24 and stored in the pricing graph database 48.
  • a pricing graph i.e., a compact representation including nodes corresponding to flights and fares that can produce travel itineraries of the answers 24 and stored in the pricing graph database 48.
  • the preferences database 30 stores travel parameters and preferences, editable by users, that include travel preferences such as preferred origin airports, destination airports or locations or location types (e.g., "ski resorts"), or favorite trips with or without dates.
  • the subscription database 31 stores account information of users who subscribe to various services supported by the caching system 11. A. Poller Program
  • the poller 36 maintains a list of TPS queries 22 over markets and dates of interest and regularly populates the cache database 28 with answers 24 supplied by TPS 12 in accordance with the TPS queries 22.
  • the poller 36 continually cycles, sending (in sequence or concurrently or some mix) the set of TPS queries 22 to the TPS 12.
  • a search engine 14 at the TPS 12 that may include multiple search engines at multiple computers responds to individual TPS queries 22 and returns answers 24 satisfying the queries.
  • the answers 24 include pricing solutions (for example, the single cheapest solution for each market and date combination) or summary information of pricing solutions (for example, the price of the single cheapest solution for each market and date combination).
  • the answers 24 include a pricing graph from which pricing solutions are enumerated.
  • the poller 36 processes the answers 24 returned by the TPS and stores the answers 24 in the cache database 28 as cached results 42.
  • the poller 36 poses certain TPS queries 22 at a higher frequency than other TPS queries 22.
  • the poller 36 poses queries 22 that include markets of high popularity or dates near to the present at higher frequencies than other queries 22.
  • the poller 36 varies the polling frequency to reduce staleness of entries of high importance or of data that is expected to change at a more frequent rate.
  • the poller 36 may also vary the polling frequency based on knowledge of data changes. For example, the poller 36 may give priority to international queries immediately after receipt of international fare updates and give priority to domestic queries after receipt of domestic fare updates.
  • the poller 36 and availability merger 46 implement a process 60 that checks seat availability of an initial answer 24 returned from the TPS 12 before storing an answer in the cache database 28.
  • the poller 36 preemptively queries (62) the travel planning system 12 with a TPS query 22 specifying parameters of trips.
  • the poller 36 receives (64) one or more answers 24 to the TPS query 22 from the TPS 12, the answers 24 being in the form of pricing solutions.
  • the TPS 12 calculates the pricing solutions that satisfy the TPS query 12 and determines whether those pricing solutions include available seats. Only those pricing solutions for which seats are available are returned to the poller 36 as answers 24.
  • the poller 36 stores (65) the answers 24 as results 42 in the cache database 28, the results 42 being in the form of pricing solutions or as summaries of pricing solutions. Thus, at the time of caching, the results 42 include available seats.
  • the process 60 re-checks (66) seat availability of the cached results 42. In some embodiments, the process 60 re- checks (66) seat availability by querying the TPS 12 to determine seat availability of the cached results 42. In other embodiments, the process 60 re-checks (66) seat availability, without the use of TPS 12, by predicting whether at least one seat is available on each of the flights in the itinerary information of the answer.
  • the process 60 may re-check the seat availability of a result 42 at regular time intervals and/or at a time immediately before the result 42 is returned to a user.
  • the poller 36 determines (68) that there are one or more available seats on flights associated with a cached result 42, the poller 36 maintains (70) the result 42 in the cache database 28. If, on the other hand, the availability merger 46 determines (68) that at least one of the flights associated with the result 42 has no seats available, the poller 36 deletes (72) the result 42 from the cache database 28 or flags (73) the result 42 as unavailable to prevent the caching system 11 from returning the result 42 to a user. In some embodiments, process 60 does not re-check seat availability (steps 66, 68, 70 and (72 or 73)) of the cached results 42.
  • the process 60 ensures that unavailable answers 24 are not initially stored in the cache database 28 as cached results 42.
  • the process 60 has the disadvantage that process 60 cannot make the unavailable answers 24 available if subsequent availability checks indicate that the unavailable answers are now available because it initially did not store those answers in the cache database 28.
  • the process 60 provides an advantage that the initial filtering of pricing-solutions is guided by seat availability, so fewer pricing-solutions need to be stored in the cache database 28 because it is more likely that the pricing solutions that are stored are more likely to be available.
  • the availability merger 46 can avoid checking availability during an initial query of the TPS 12 and return a set of answers 24 that are regularly checked for availability in a separate availability merging process. As the number of returned answers 24 increases, the amount of memory needed to store the answers 24 and the demand on computational resources to perform seat availability checks on the answers concomitantly increases. To conserve memory and computational resources, the poller 36 represents the answers 24 retrieved from the TPS 12 as a pricing graph (i.e., a compact representation including nodes corresponding to flights and fares that can produce travel itineraries of the answers 24).
  • the poller 36 (see FIG.l) and availability merger 46 implement a process 80 that checks seat availability of itineraries encoded in a pricing graph returned from the TPS 12.
  • the poller 36 regularly sends (82) queries 22 to the TPS that disable seat availability checks and request answers 24 in the form of a pricing-graph.
  • the TPS 12 generates a pricing-graph that encodes all possible pricing- solutions for a set of itinerary combinations, including many for which no seats are available.
  • the generation of a full-availability pricing-graph can be computationally more efficient than one filtered by seat availability, because while there are more pricing-solutions represented in the pricing-graph, the pricing-solution set may factor better, resulting in a smaller pricing-graph.
  • a compact representation such as the pricing-graph may represent the set of 100 combinations using a "factored" structure of size 20, rather than 100.
  • seat availability as determined by airline revenue management systems may eliminate an irregular subset of the 100 combinations in a manner that does not permit simple factorization of the resulting set.
  • a TPS constructs a representation of all available answers that representation may be substantially larger than the set of all answers, regardless of seat availability.
  • the poller 36 stores (84) the pricing graph, which may include multiple pricing graphs, in a pricing-graph database 48 indexed by appropriate key information such as airports or dates (i.e., whatever information is particular to the query that generated the pricing-graph).
  • the pricing-graph database 48 may be a separate database or may be a portion of the cache database 28.
  • the querying and storing processes (82, 84) are collectively referred to as the graph generation process 98.
  • the poller 36 translates booking-code restrictions of each fare within the pricing graph into a form that can be efficiently evaluated against itinerary, seat availability, such as by pre-recording the set of booking-codes for which if the booking-code were available on each flight of the fare-component, the fare's booking-code restrictions would pass.
  • the availability merger 46 regularly cycles over pricing graphs stored in the pricing-graph database 48, retrieving each of the pricing-graphs from the database 42. For a retrieved pricing graph, the availability merger retrieves (86) seat availability information for the travel itineraries represented in the pricing graph. This may be done using a number of techniques including posing itinerary or flight availability questions to an availability server within the TPS 12 or to an availability predicting system for those flights or itineraries in the pricing graph. These and other techniques for determining availability of an itinerary are further described below.
  • seat availability information is retrieved (86) for all itineraries that appear in the pricing-graph. For each itinerary, the availability merger 46 determines (88) if at least one seat is available.
  • the pricing graph is a compact representation of a larger set of itinerary and fare combinations. In many instances, several itineraries may combine in all possible ways with several fares. In such circumstances, the pricing-graph optimally compresses the set of combinations into a (AND (OR itinl itin2 %) (OR farel fare2 %) structure.
  • Seat availability checks may rule out essentially arbitrary combinations of fares with itineraries. Thus, if without considering seat availability a set of valid combinations is
  • the pricing-graph representation stores pricing solutions that may or may not have an available seat.
  • the process extracts an explicit list of pricing solutions and filters those pricing solutions by seat availability.
  • One way to do this is to alter the "enumeration" algorithm described in U.S. Patent 6,275,808 by Carl G. de Marcken and assigned to the assignee of the present invention and incorporated herein by reference.
  • the enumeration algorithm includes an explicit filtering process that checks fare and itinerary combinations against a table of seat availability retrieved by querying an availability server.
  • that approach may be somewhat inefficient, as the algorithm may generate many answers that turn out to be unavailable. There are optimizations to alleviate this problem.
  • the availability merger 46 disables (90) nodes in the pricing graph corresponding to a subset of the travel itineraries for which no seats are available, and disables (92) nodes in the pricing graph corresponding to a subset of the fares for which no travel itineraries are available.
  • the fare's booking code restrictions are evaluated against the seat availability information for that itinerary, to produce a table of fare and itinerary combinations that are permitted by seat availability. If a fare or itinerary fails to appear in any entry in this table, it can be disabled using the mechanisms described in US Patent 6,275,808 and assigned to the assignee of the present application and incorporated herein by reference.
  • the retrieving, determining, and disabling processes (86, 88, 90, and 92) are collectively referred to as the availability merging process 100.
  • the poller 36 After nodes of the pricing graph have been disabled (90, 92) based on seat availability constraints, the poller 36 enumerates (94) pricing-solutions from the pricing-graph. During enumeration (94), the poller 36 compares fares and itineraries of the pricing solutions to the seat availability tables determined in step 86 and filters those pricing solutions having fare/itinerary combinations for which no seats are available.
  • the poller 36 extracts pricing- solutions from the pricing-graph and that filters itinerary and fare combinations found in partial solutions against the itinerary and fare validity table.
  • the filtering can include an explicit filtering test.
  • the table is checked; if the fare and itinerary combinations is not in the table, the partial pricing-solution is discarded. Examples of enumeration algorithms for use by poller 36 are described in US Pat. 6,275,808 by Carl G. de Marcken and assigned to the assignee of the present invention and incorporated herein by reference.
  • the process 80 stores (96) the remaining pricing-solutions as results 42 in the cache database 28.
  • the seat availability check (88), the disabling procedures (90, 92) and the enumeration process (94) can be integrated.
  • the table of fare and itinerary combinations that are permitted by seat availability is checked. If the fare and itinerary combinations are not in the table, the partial pricing-solution is discarded.
  • Other more efficient methods for taking seat availability constraints into account when extracting pricing-solutions or summary information from the pricing-graph may be possible.
  • the volume of data generated by the TPS 12 in response to the queries 22 is typically quite large and storage of the data in the cache database 28 requires significant memory resources. For example, if for an ordinary single market and date pair query, the TPS 12 returns 100 answers 24 (potential tickets), then for the 10,000 market/5000 date-pair example, the TPS 12 returns 5,000,000,000 answers. Storing on the order of a billion answers 24 in the cache database 28 may or may not be practical. It is possible to represent a complete pricing solution in, e.g., 100 to 1000 bytes or less if suitable compression schemes are used, resulting in database sizes on the order of terabytes.
  • the travel planning system 100 may be able to efficiently generate a pricing graph representation of the set of answers 24 from the TPS 12, the cost of enumerating individual pricing-solutions from the pricing-graph grows linearly with the number of answers to be enumerated.
  • summary information that summarizes the answers 24 to TPS queries 22, rather than the actual answers 24 themselves, is stored in the cache database 28 as cached results 42.
  • the summary information may include the lowest available price (or corresponding pricing solution) for each combination of origin, destination, and travel dates.
  • Summary information can characterize a group of pricing solutions belonging to one or more super categories. For example, summary information may include a range of prices for pricing solutions that include any US city as an origin and any European city as a destination.
  • a result 42 in the form of summary information describes a group of pricing solutions in broad terms and generally includes less information than a result 42 in the form of a complete pricing solution for a trip.
  • the summary information can be selected on the basis of the applications to be supported. For example, to support the display of itineraries and fares in the form of a pricing matrix that groups the itineraries by airline and cheapest price, it may be necessary for the TPS to return the cheapest price per airline and per airline/number-of- stops combination.
  • An example of a pricing matrix is disclosed in U.S. Patent 6,801,226 assigned to the assignee of the present invention and incorporated herein by reference.
  • the correctness of a cached result for a particular query depends on whether the flights, fares, and seats that affect the results have changed.
  • the results 42 are initially available when the poller 36 stores them in the cache database 28, over time, one or more of a fare, flight, and seat associated with the results 42 may become unavailable, or indeed changes to the underlying flight and fare data may make one or more of the results invalid.
  • the availability merger 46 checks the availability of the results 42 and updates the results 42 accordingly.
  • the idea is that the TPS 12 is queried for a pricing-graph (computed with or without seat availability checks, preferably without) and then at regular intervals a separate process extracts results and filters them for seat availability.
  • the availability merger 46 rechecks (87) seat availability of flights associated with a cached result and determines (89) whether one or more of a flight, fare, and fare rule associated with the cached result are still available. As particular itineraries and fares become unavailable, the availability merger 46 deletes (91) the result from the cache database 28. Alternatively, the availability merger 46 disables (93) the nodes corresponding to the unavailable itineraries or fares in the pricing graph (stored in pricing-graph database 48) from which the results 42 were derived.
  • the availability merger 46 enables (95) the corresponding nodes in the pricing graph that were previously disabled.
  • the availability merger 46 may perform the availability rechecking and the enabling / disabling of nodes in accordance with the availability merging process 100 described above in connection with FIG. 3.
  • the poller 36 enumerates (97) pricing solutions from the updated pricing graph and stores (99) these solutions as results 42 in the cache database 28.
  • the poller 36 regenerates (101) the pricing graph from scratch via the graph generation process 98.
  • the process 85 generally regenerates (110) the pricing graph less frequently than it performs the previous processes described above.
  • the graph generation process 98 and the availability merging process 100 may each be executed multiple times at various time intervals and in various orders relative to each other.
  • the availability merging process 100 is a lower-latency (and lower computation) operation than the graph generation process 98.
  • the availability merger 46 updates the cache database 28 many times for each pricing-graph answer 24 returned by the TPS 12. It may be advantageous for the availability merger 46 to use the same computational resources as the poller 36 uses to perform the graph generation process 98.
  • Update process 110 to regenerate a pricing graph in response to an external event, such as the receipt of a fare or flight or rule update is shown.
  • Update process 110 has the availability merger 46 regularly execute the availability merging process 100 on a pricing graph generated in process 80 (FIG. 3) until the poller 36 detects (112) the occurrence of a fare or flight or rule update. The detection of such an update triggers the poller 36 to re-generate the pricing-graph via the graph generation process 98.
  • pricing-graphs are computed once per flight/ fare/ rule update and then regularly merged with current seat availability.
  • another update process 120 rechecks seat availability of pricing solutions derived from the pricing graph at the time a user query comes in - the pricing-graph is retrieved from the cache database and the enumeration & seat availability checks are done "on demand", with only the calculation of the pricing- graph done in advance.
  • the seat availability of a pricing graph is checked only in response to receiving a query 18 (see FIG. 1) from a user.
  • the availability merger 46 performs the availability merging process 100 on a pricing graph generated in process 80 (FIG. 3) only when a query 18 is received (122) from a user for either complete pricing-solutions or summary information.
  • the update process 110 FIG.
  • the update process 120 is likely to have a higher latency, and thus may be less suitable for such uses as presenting summary information on web home pages.
  • it is well suited to extracting a list of pricing-solutions for a specific query 18 posed on an airline or travel agent web site or a CRS terminal, especially if the query 18 contains out-of-the-ordinary constraints or parameters, such as a desire for a particular route or travel time or carrier or fare product or cabin class that can be enforced by disabling particular graph nodes or enumerating answers in an order determined by a biased value function.
  • a "value function” is the name for a "utility” or “preference” or “ranking” function used to assign a numerical value to a pricing-solution, that when used in algorithms that extract pricing-solutions from the pricing-graph, determine which solutions come out in which order, as described in U.S. Patent 6,275,808 mentioned above.
  • the pricing-graph containing a large space of answers, can support such queries, and while significantly greater latency and computational load is incurred answering such queries by extracting information from a pricing-graph than using methods where fully-checked answers have been pre-computed, the latency and load may still be significantly lower than if the pricing-graph had not been pre-computed.
  • the availability merger 46 poses a high rate of seat availability queries compared to the rate at which travel queries are posed for schedules and prices since flight and fare data change at a lower rate than seat availability.
  • the seat availability queries are made to seat availability predictors or in some circumstances to airline revenue management systems. These seat availability queries are used to determine whether a seat will be made available for a flight or a set of flights, generally coupled with a fare usable with the flight or sets of flights.
  • a TPS such as TPS 12
  • TPS 12 can determine a set of flights useable with a fare, generally a ticket cannot be booked unless an airline's revenue management system or seat availability system makes a seat available.
  • each fare has associated rules that restrict what flights the fare can be used with. However those rules are not the only consideration.
  • the airline revenue management/seat availability system indicates that inventory will be made available for the combination.
  • fare rules do not change nearly as rapidly as responses from an airline's revenue management/seat availability system.
  • fare rule evaluations are more computationally intensive than seat availability checks, so in some circumstances it is desirable to have a TPS to construct fare/flight combinations ignoring seat availability and determine seat availability in a subsequent process.
  • cache database 28 may be updated at sufficiently high frequency such that the likelihood of stale results being accessed is low.
  • Other techniques that enable the cache database 28 to be updated at sufficiently high frequency such that the likelihood of stale results being accessed is low include using a large farm of computers to answer LFS queries and posing broad queries to a TPS that shares work across dates and airports to maximize computational efficiency.
  • cached results 42 In addition to frequently updating cached results 42 to reflect changes in the
  • Such a technique is particularly effective if the cache database 28 is populated at a high enough frequency so that errors are rare. It is especially appropriate when the cache database 28 contains pricing-solutions indexed by one or more sets of indexing features (i.e., cheapest price, origin, destination, etc.), referred to as "keys," and can be enhanced by raising the number of pricing-solutions stored for a given key (e.g., airports and dates) from one to several, so that if one fails, the price from the others is likely to remain valid.
  • keys e.g., airports and dates
  • the direct tests can be performed either "online” (when results are extracted from the cache database 28) or "offline” (regularly, or on data changes). If performed offline, if a pricing-solution stored in the cache database 28 is determined to be unavailable it can either be removed from the database 28 or simply marked as invalid (with the possibility that it becomes valid again in the future if in the future direct tests succeed again, as would be particularly likely in the case of seat availability changes).
  • direct tests are testing seat availability
  • a notification may be in the form of AVS (avionics system) or NAVS (navigation system) seat availability messages sent from the TPS 12.
  • the notification may be sent from a system that predicts seat availability, such as those described in US Patent 6,275,808, or from a system that received updates to bid-prices or market-prices used to compute seat availability in "married" or revenue management schemes. There are different varieties of revenue management systems that can be used.
  • RM airline revenue management
  • Some of those revenue management (RM) systems rely on various databases that assign properties to flights and fares (such as the approximate profit revenue represented by a fare -the "market price - and the approximate lost-opportunity cost of selling a seat on a flight - the "bid price”).
  • Airlines for which duplicated revenue management (RM) systems are used would send to the process changes to these databases as the changes are made.
  • RM revenue management
  • determine seat availability, receipt of change information can be used to trigger re-checks of seat availability for cached solutions.
  • Other availability prediction techniques could be used.
  • an exemplary batch process 140 for determining availability is depicted using an exemplary timeline.
  • An agreement between providers e.g., airlines, not shown in FIG. 6) and a party (not shown) providing the cached-based travel planning system 10 (see FIG. 1) guarantees the data sent by the providers (e.g., flights, fares, and possibly but not necessarily seat availability).
  • the airline agrees that the fares in existence at time X may be used at some time after X even though the airline has updated the fares in the intervening period. Another way, the airline agrees that updates need not be processed immediately and institutionalizes the delay between transmission and usage.
  • the fares in existence may be used to book tickets based on the batch during the period [X+I, X+2I].
  • the data in the TPS 12 is updated (142) and answers 24 to pre-emptive TPS queries 22 based on the updated data are received at the web server 26.
  • the poller 36 populates (144) the cache database 28 with results 42 based on data at time X, and associates (146) the timestamp X with every entry in the cache database 28 that has been computed in the interval X to X+I.
  • entries from the result database are retrieved only if they are marked with timestamp X (during the period from X to X+I, retrievals are done using timestamp X-I).
  • the provider agrees that although some results are always stale by a duration between X+I and X+2I, if I is sufficiently small (e.g., below a predefined threshold) the provider will accept stale answers (i.e., the provider will book a ticket corresponding to a stale answer).
  • the booking system of a provider receives (148) a request to book a ticket in time period X+I to X+2I, it determines (150) whether the one or more of a seat, fare, or rule is stale. Upon determining (150) that a proposed ticket is not stale, the TPS books the ticket (156). Upon determining (150) that a proposed ticket is stale, however, the TPS determines (152) whether the request is associated with the timestamp X. If the request is associated the timestamp X, the TPS allows (156) the ticket to be booked although it includes stale information. Otherwise, if the request is not associated with the timestamp X, the TPS denies (154) the request to book the ticket.
  • a first TPS delays the use of new data until such time as a second TPS is processing the new data, so as to maintain consistency between the two systems. This is especially common when a first TPS (used by an agency) is used for search and a second TPS (used by a provider) is used for verification prior to reservation and ticketing: the first TPS delays answering queries based on new data until the new data is loaded and available for use by the second TPS. This ensures that the second TPS will not prematurely reject any pricing-solutions that use the new data.
  • the travel planning system 10 can use the difference in load delays to its advantage.
  • FIG. 7 an exemplary process 160 for loading data into the cache database 28 and that accounts for load delays incurred by conventional TPSes is shown.
  • One or more TPSes are used to calculate answers for caching, each TPS running on a particular set of data (fare and flight database, e.g.).
  • Providers update data and transmit to different TPSes.
  • the caching system 11 After the caching system 11 retrieves (162) answers 24 from the TPSes the system 11 immediately stores (164) the answers as new results 42 in the cache database 28 and marks (166) the answers with a data-specific timestamp reflecting the version of data used by a TPS to generate the answer.
  • a separate "verification” or “booking" TPS may update its data in response to provider transmissions at a different rate than cacheTPSes (e.g. TPS 12) used by the caching system 11 to populate the cache database 28 with results 42.
  • cacheTPSes e.g. TPS 12
  • a cache TPS loaded with old data d2 is updated with new data dl, and the verification TPS has not been updated and still has old data d2 in effect.
  • the caching system 11 annotates (166) pricing solutions received from the cache TPS with timestamp dl and stores these pricing solutions in the cache database 28.
  • the caching system 11 poses queries (168) to TPSes loaded with both the (new) dl and (old) d2 timestamps.
  • the caching system 11 provides (170) only those solutions marked with the old timestamp d2 to the verification TPS, which has not yet been updated, to ensure that the solutions returned by the cache system 11 are compatible with the verification TPS.
  • the caching system 11 is primed for when the verification TPS switches to the new dl data. After the verification TPS has been updated with the new dl data, the answers marked with the dl timestamps are compatible with verification TPS.
  • the caching system 11 At an appropriate time determined (172) by the caching system 11 (e.g., at a time when the carrier's TPS 12 has loaded the new dl data), the caching system 11 provides results having the new dl timestamp (174) to the verification TPS. .
  • a diagram depicting data loading includes a timeline 178 of interaction between pollers 36 and corresponding travel planning systems.
  • numbers in the row represented by the symbol "Rcpt” correspond to events in which new data is received by the caching system 11.
  • the value of the number represents the timestamp index associated with the data.
  • the number "1" located in the Rcpt row at time tO represents the receipt of new data marked with a timestamp index equal to "1.”
  • Numbers in the row represented by the symbol "Efft" correspond to events in which the received new data of an indicated timestamp is effective (i.e., results based on the new data can be supplied to a user) by the caching system 11.
  • the time at which the data is effective corresponds to the time at which a verification TPS maintained by a provider or carrier has finished loading and processing the new data.
  • Numbers in the row represented by the symbol "Quer” correspond to the timestamp index used for selecting results 42 from the cache database 28.
  • Numbers in the row represented by the symbol “A” correspond to events in which a first poller A and a first TPS A supply results 42 to preemptive queries 22 and the timestamp index associated with the results 42.
  • numbers in the row represented by the symbol "B” correspond to events in which a second poller B and a second TPS B supply results 42 to preemptive queries 22 and the timestamp index associated with the results 42.
  • the TPS B during a time prior to the switch (e.g., at time tl) to the next data set, preemptively calculates results (e.g., two results represented by "11") for that timestamp, so that there is no delay in switching.
  • results e.g., two results represented by "11"
  • TPSes A and B could be replaced by a TPS that is capable of loading and processing multiple data sets simultaneously.
  • a TPS may be capable of working on multiple sets of data in one query, annotating answers with what data sets they are compatible with. As typically few fares change in an update, the TPS can determine whether a particular fare was valid before the update and/or after the update. The TPS considers all fares valid either before or after an update, but annotates solutions with timestamp information that is required for the solution to be valid. That may be more efficient than posing two separate queries to two TPSes with different data sets loaded, as those TPSes would duplicate work for fares that were not affected by the update.
  • the loading process shown in FIG. 8 minimizes staleness due to flights, fares and fare result, although not for seat availability.
  • an update process to subsequently re-check seat availability at a more rapid rate (that is, numerous times between flight and fare and fare rule updates), such as the update process 110 in FIG. 5 A.
  • the result database may be pre -populated with results calculated for the next day and stored with the next day key; so that close to the end of a day the result database contains results both for the current day and for the next day, with database queries containing a reservation date so as to ensure the results with the proper date are retrieved.
  • providers may be willing to commit to accept any remaining errors, effectively eliminating them by agreement. That is, providers may be willing to commit that any prices returned by the caching system will be accepted by the provider, even if they were computed from now-stale data.
  • the cache database 28 contains complete pricing-solutions described at a level of detail that includes an itemization of the fares involved in solutions, then after the receipt of fare updates, solutions that include fares for which amounts have changed can be found in the cache database 28. The prices for those solutions are re-computed and any summary information are updated accordingly. There is a risk, however, that summaries may not be the best pricing solutions, because the pricing-solutions in the result-database after the amount changes.
  • the availability merger 46 updates the elements of the representations (e.g., pricing-graph nodes) corresponding to the fares.
  • the poller 36 then updates the cache database 28 with pricing solutions that are re- extracted from the representations.
  • LFS queries 18 are substantially more common than others, such as round-trip queries in which the user requests travel back and forth between two specific airports or cities. If answers to such queries are pre-computed, expanding the query to include multiple airport pairs (that is, the user allows that they might take a round-trip between any one of several airport pairs) does not alter the caching architecture described here, because the answer for the broader query can be constructed by simply merging database entries for narrower queries (returning a choice between multiple entries, or for a price summary, minimizing over multiple entries).
  • Queries for which answers have not been pre-computed may require that searches be done live.
  • This deficiency can be partially alleviated by pre-populating a broader range of queries, such as open-jaw queries and one-way queries, or using query-widening techniques described in the patent application entitled QUERY CACHING FOR TRAVEL PLANNING SYSTEMS, Ser. No. 10/456,997, filed on June 6, 2003 by Carl de Marcken et al, to expand the set of airports for each slice origin and destination to include nearby neighbors and to store the results in a pricing- graph format.
  • the space of queries may exceed the space that can be pre-computed using an economically practical computing facility.
  • the poller 36 constructs answers to queries (i.e., user queries 18 and pre-emptive queries 22) directly from the results 42 for previous queries 22.
  • queries i.e., user queries 18 and pre-emptive queries 22
  • some airlines restrict their fare structure to one-way fares.
  • the space of solutions for round-trip, circle-trip, and open-jaw queries can be expressed as the cross-product of answers to a sequence of one-way queries, with some caveats.
  • the web server 26 receives (167) a query (e.g., a user query 12 or a TPS query 22) that includes two or more slices (i.e., a user-requested trip portion, such as the "outbound" of a round-trip query).
  • a query e.g., a user query 12 or a TPS query 22
  • two or more slices i.e., a user-requested trip portion, such as the "outbound" of a round-trip query.
  • Open jaw trips include flight itineraries where the departure city is different on the outbound portion than the destination city of the return portion. Or alternatively, the destination city that a passenger arrives in is different than the one that is departed from on the return portion of a flight itinerary.
  • An example would be a traveler starting at Boston's Logan Airport flying into San Francisco International, and then returning to Washington Dulles airport instead of Boston.
  • the poller 36 selects (169) the cached results 42 that can satisfy portions of the specified trip. For example, for a Boston-Los Angeles-Providence open jaw, the poller 36 selects cached results 42 for a Boston-Los Angeles one-way trip and cached results for a Los Angeles-Providence one-way trip. From the selected cached results 42, the poller 36 constructs (171) a pricing solution for the desired trip. For example, the poller 36 computes the cheapest price for a Boston- Los Angeles-Providence open jaw from the sum of the cheapest price for a Boston-Los Angeles one-way and the cheapest price for a Los Angeles-Providence one-way. Thus, if the caching system 11 (see FIG.
  • the poller 36 can construct answers to more complicated queries from answers 24 to pre-emptive one-way queries 22. In some cases this process is not guaranteed to produce the best answer (for example, if the best answer involves a stopover fare that crosses slices), or may produce slightly incorrect answers (for example, if taxes do not factor across slices) that may need to be corrected.
  • the taxes applied to the component cached results 42 may be different than those that apply to the pricing solution constructed from the component cached results 42.
  • the poller 36 computes (173) the appropriate taxes applicable to the pricing solution.
  • taxes typically do not substantially alter the price-order of results it may be sufficient for summarization purposes to re-compute taxes for the single pricing-solution on which the summary is based. For example, if the goal is to present the single cheapest price for a round-trip query on particular dates, the cheapest outbound solution and cheapest return solution are selected, and taxes are re-computed on the combined solution to compute the final price.
  • the results 42 in the cache database 28 may be organized and categorized in a variety of different ways to best suit a variety of travel applications that use the results 42. If multiple travel applications with different requirements are supported, it may be beneficial to store results in multiple table structures within the cache database 28, with each of the multiple table structures optimized for particular uses. For example, to support some applications, the cache database 28 may store a set of complete pricing- solutions for answers 24 received from the TPS 12 or a representative selection of the complete set of pricing pricing-solutions (such as the cheapest, or the most convenient, or a diverse selection). In some embodiments, the table structures are stored in separate cache databases that collectively form the cache database 28.
  • a conceptual structure of the cache database 28 includes multiple data structures 201 : a TABLE-SUMMARY data structure 204, a TABLE- DETAIL-SUMMARY data structure 206, a TABLE-SOLUTION-MAPPING data structure 208, a TABLE-SOLUTION data structure 210, a TABLE-ITINERARY data structure 212, a TABLE-ITINERARY-FLIGHT data structure 214, a TABLE-FLIGHT data structure 216, and a TABLE-BOOKING-CODES data structure 218.
  • the data structures 201 organize information associated with the cached results 42 in a form that requires little transformation prior to use or display (e.g., to a user at client 16) and reduce the number of database entries needed to be accessed when responding to a users' queries 18.
  • the data structures 201 are in the form of tables and are sometimes referred to as "tables 201".
  • the data structures 201 could be represented as tree structures, array structures, and other types of data structures. Each of the data structures 201 are described in further detail below. Referring to FIGS. 1 IA-I IB, a process 180 for configuring data stored in the cache database 28 (see FIG.
  • the poller 36 sends (181) the TPS 12 flexible travel queries 22 that include travel parameters (e.g., oneway, round-trip, and open jaw) for every airport pair of origin and destination airports, with very broad date ranges on outbound and return.
  • travel parameters e.g., oneway, round-trip, and open jaw
  • Such a flexible travel query includes a specification that solutions with a particular feature (e.g., the cheapest pricing solution (if any)) are returned for every combination of outbound date and return date.
  • a flexible travel query 22 may include a multi-feature specification of the answers to return.
  • Examples of features included in a query 22 may include Other queries 22 include the cheapest pricing solution whose flights are provided by only one airline is returned for every date combination and for every airline that provides service; the cheapest pricing solution for every date combination in business class or better and in first class or better is returned; and a cheapest pricing solution for nonstop flights on each carrier is returned for every date combination. Other combinations of features may be requested in a single query.
  • the poller 36 may request a large diversity of answers for each date, to support applications in which many solutions are available for each date.
  • Further examples of flexible travel queries are as disclosed in U.S. Patent Application Serial No. 09/431,365, entitled “Method for Generating A Diverse Set of Travel Options" by Carl de Marcken and U.S. Patent Application Serial No. 09/431 ,699, entitled “Method for Generating A Diverse Set of Travel Options" by Carl de Marcken, both of which are assigned to the assignee of the present invention.
  • the poller 36 For each query 22 sent to the TPS 12 by the poller 36, the poller 36 receives a set of answers 24. The poller processes these answers 24 to populate the cache database 28 with results 42.
  • the results 42 can be in the form of pricing solutions or in the form of summary information.
  • the results 42 are initially stored (182) in records including fields corresponding to predefined categories of the schedule and fare information. The information is expressed in these records database 28 at a fine grain, for example indexed by travel dates and airports. For example, a record that includes the following fields: origin apt, destination apt, out date, return date, and cheapest price, can be indexed by the first four fields.
  • the web server 26 can process a query 18 for the cheapest price for a trip from Boston to Europe in January by retrieving from the record all entries whose (1) origin airport is located in Boston, (2) outbound and return dates occur in January, and (3) destination airport is one of the hundreds of airports in Europe.
  • the web server 26 can include a program that sorts the pricing solutions and determines, e.g., the cheapest travel option by minimizing the price over all of the retrieved entries.
  • the poller 36 translates the results 42 into representations suitable for storage in one or more of the tables 201 of the cache database 28.
  • the pricing solutions are summarized (184) according to categories that include aggregated travel parameters that are typically broader than the travel parameters of the results 42. Examples of aggregated travel parameters include more general trip-segment endpoint locations (such as countries or location classes such as "tropical islands” or “ski resorts") and departure / return times (dates or months or seasons).
  • a first exemplary set includes: origin- airport, destination-airport, outbound-date, and return-date.
  • a second exemplary set includes origin-airport, destination-airport, and outbound-month.
  • a third exemplary set includes: origin-airport, destination-airport, outbound-month, and length of stay.
  • a fourth exemplary set includes: origin-airport, destination-country, outbound-date, and length of stay.
  • Table 1 shows an exemplary TABLE- SUMMARY data structure 204 in which the best price over all pricing-solutions with a given set of features is stored in an entry keyed by the set of features.
  • a super-category of travel parameters i.e., an aggregate travel parameter
  • the fields within the TABLE- SUMMARY data structure 204 are indexed (188) by the super-category.
  • the super- category includes at least a portion of schedule and fare information from the at least two of the predefined categories.
  • the fields where the type is enclosed in ⁇ > are "key" fields by which the entries may be indexed. Multiple prices are stored, such as the best price for each of various passenger combinations. Some pricing solutions may be involved in the calculation of the prices of multiple summary entries. To indicate that a search was conducted but no options were found for the particular set of search criteria, summaries for features sets for the search criteria with no matching pricing solutions may be represented by storing "nil" or no entry in price fields.
  • More detailed sets of features are calculated (190) by extending the coarse feature sets with more features, such as the carrier (for solutions that are supported by a single carrier), the cabin class, and the maximum number of stops.
  • Other index information can include other travel parameters such as a number of passengers or a passenger type.
  • the referenced information of primary importance is existence (whether a trip is possible), price, and trip duration or number of stops or other measures of convenience.
  • Entries are provided in a TABLE-DETAIL- SUMMARY data structure 206 indexed by the summary-id and the more detailed features. Table 2 shows an exemplary TABLE-SUMMARY data structure 206.
  • the TABLE-DETAIL-SUMMARY data structure 206 of Table 2 is similar to the TABLE- SUMMARY data structure data structure 204 shown in Table 1 but includes more detail by adding several more index fields to permit summaries itemized by or restricted to a carrier, a class and a maximum number of stops.
  • Table 2 TABLE-DETAIL-SUMMARY
  • An "atomic” summary is a summary where key elements such as origin, destination and date ranges are populated with indivisible units like individual airports and dates.
  • a “non-atomic” summary is a summary where the fields are populated by aggregated units like countries or months.
  • Atomic summaries can be updated based on a single response from a TPS whereas non-atomic summaries may be summaries of multiple TPS queries (e.g., a non-atomic summary of Boston-Europe may include data from TPS queries Boston-London, Boston-Paris, etc.).
  • a non-atomic summary is based on data that comes from multiple queries posed to the TPS, for example a summary over markets where each market is posed to the TPS in a separate query
  • relevant non-atomic summaries may either be updated after each atomic summary update, or at some regular interval.
  • the cache database 28 relates (192) the summary information to the pricing solutions over which they are aggregated using a TABLE-SOLUTION-MAPPING data structure 208.
  • Table 3 shows an exemplary TABLE-SOLUTION-MAPPING data structure 208.
  • the TABLE-SOLUTION-MAPPING data structure 208 shows relationships between information summaries and pricing-solutions. Each solution is identified with a unique identifier present in the "solution-id" field. For a solution identified in the "solution-id” field, the field "best-solution?" is marked “true” if that pricing solution is the cheapest price for the summary.
  • the TABLE-SOLUTION-MAPPING data structure 208 enables efficient retrieval of either a representative solution, or all the solutions that meet summary criteria, such as all the solutions between two airports on particular dates.
  • the cache database 28 represents the pricing solutions (194 in FIG. 1 IB) in a TABLE-SOLUTION data structure 210.
  • Table 4 shows an exemplary TABLE- SOLUTION data structure 210 that represents pricing-solution; indexed by "solution- id" and “data-timestamp.”
  • the TABLE-SOLUTION data structure 210 includes price and identifiers of outbound and return itineraries associated with a pricing solution; and passenger assumptions and fare product and cabin-class summary.
  • the fields labeled "out-itin-id” and "ret-itin-id” reference shared itineraries. By sharing itineraries and indexing itineraries on both itinerary-id and origin and destination and departure date, memory resources are conserved.
  • the TABLE- S OLUTION data structure 210 enables the poller 36 to efficiently extract itinerary options independently of pricing-solutions as well as extract pricing-solutions for particular itineraries or itinerary combinations.
  • the cache database 28 represents (196 in FIG. 1 IB) an itinerary for a trip in a TABLE-ITINERARY data structure 212.
  • Table 5 shows an exemplary TABLE- ITINERARY data structure 212 in which itineraries that are shared across pricing solutions and each identified by a unique key in the "itinerary-id" field, are indexed by either an itinerary-id or combination of origin, destination, and departure-date.
  • Table 5 TABLE-ITINERARY
  • the cache database 28 represents (198) relationships between itineraries and flights using a TABLE-ITINERARY-FLIGHT data structure 214.
  • Table 6 shows an exemplary TABLE-ITINERARY-FLIGHT data structure 214 in which multiple flights per itinerary may be represented.
  • the cache database 28 represents (200) flights in a TABLE-FLIGHT data structure 216.
  • Table 7 shows an exemplary TAB LE -FLIGHT data structure 216 of flight instances shared across pricing solutions.
  • the cache database 28 stores (202) the booking codes of flights belonging to a pricing solution in a TABLE-BOOKTNG-CODES data structure 218.
  • Table 8 shows an exemplary TABLE-BOOKING-CODES data structure 218.
  • the poller 36 extracts information from one or more of the data structures to support various travel applications. For example, in order to extract the "best price" for an adult one-way or round- trip query between particular airports on particular dates, a best price procedure is used with the TABLE-SUMMARY data structure 204 shown in Table 1. Such a best price procedure is shown by the following pseudo code:
  • a process 220 for extracting data from the cache database 28 in response to queries for aggregated travel parameters is shown.
  • the caching system 11 receives (222) a query 18 from a user requesting pricing information for itineraries that are grouped over location or time, such as "from Boston to France” or “from Boston to a ski resort” or “departing January,” the poller 36 determines (224) whether a feature by which the itineraries were grouped, matches up with one of the pre-computed groupings in the TABLE-SUMMARY data structure 204, such as by a "country” or by a "month.” If a match exists, the results are returned (226) directly from the TABLE- SUMMARY data structure 204 in the same manner, as described above, for an original (i.e., non-grouped) feature.
  • An exemplary technique is shown by the following pseudo code:
  • the poller 36 summarizes (230) the multiple returned results 42 before sending (234) the results 42 to the client 16. For example, the poller 36 may sort all matching entries using price, and return those results 42 with the cheapest price. In some embodiments, the requesting application may summarize the returned results.
  • the poller 36 may also itemize (232) prices or other features by summary key before sending (234) the results to the user. For example, the poller 36 may present prices for each day in a calendar of dates, or for each of many destinations. In some embodiments, the poller itemizes summaries by posing multiple database queries with different selection criteria (for example, different outbound dates in turn), or by eliminating selection criteria. An example in which summaries are itemized by an airport is shown by the following pseudo code:
  • TYPE-OF (destin-location) 'airport' or
  • the poller 36 may also itemize prices or other features by detail summary key. It is frequently desirable to itemize summaries by carrier, number of stops, cabin class, and other features at a finer level of detail than merely dates and airports. For example, the poller 36 presents itemized summaries in a price matrix (e.g., a carrier-by-number- of-stops price matrix for a given pair of airports and dates). Alternatively, applications may be configured to support user-specified filters on such features. If a request for more detailed information regarding a summary is received
  • the poller 36 uses the TABLE-SOLUTION-MAPPING data structure 208 to access to one or more pricing-solutions with features matching the summary and returns (238) those pricing solutions to the user. If such a request is not made by the user, then process 220 goes directly to the end.
  • the structure of the cache database 28 can be modified to use different indexing systems, to summarize different features than those described above, to exclude summaries, to exclude pricing-solutions, to represent pricing-solutions at different levels of detail, and to represent trip types other than one- way trips and round-trips.
  • processed forms include a summary, as discussed above, highlights of particular information (such as booking codes and so forth) of such data, information that requires less translation prior to presentation, such as binary display representations, as hypertext markup language (html) or portable document files (pdf) or graphical bitmaps corresponding to printed tables, charts and so forth.
  • html hypertext markup language
  • pdf portable document files
  • Timestamps It is advantageous, in some embodiments, to associate entries in the cache database 28 with an indicator of when the entry was calculated or an indicator of the effective time of the flight, fare and seat-availability data associated with the entry. Furthermore, it may be advantageous to retain in the database not only the entries associated with the most recent query to the TPS 12 but also one or more previous (“historical”) entries.
  • the poller 36 maintains an index of how many times each of the queries 22 has been sent. That is, if the poller 36 cycles through markets and sends the TPS 12 one query per market every cycle, the index would be the cycle number.
  • the poller 36 stores the index in the cache database 28 with every summary and pricing-solution resulting from the query 22. For example, the poller 36 stores the index value in the field named "data-timestamp" in the exemplary TABLE - SUMMARY, TABLE -SOLUTION, and TABLE -ITINERARY database structures 204, 210, and 212 (see FIG. 10) of Table 1, Table 4, and Table 5.
  • a data-time stamp can be used by the poller 36 to detect changes in the results 42 stored in cache database 28 (e.g., to detect the lowering of the best price available in a market on particular dates).
  • the poller 36 compares results 42 with a timestamp index to corresponding results 42 marked with an earlier timestamp. If the price or other properties of interest have changed, applications can be notified of such changes.
  • the poller 36 can track the behavior of summaries over time using timestamps of older entries existing in either the cache database 28 or a secondary database to which they were copied.
  • entries may be assigned first and last timestamps such that when a new entry having the same price and other information as an earlier entry is received, instead of saving the new entry (as a duplicate entry), the last timestamp of the earlier entry may be updated to reflect the time that the new entry had been received.
  • Timestamps can be used to detect missing entries. For example, if at some period all potential pricing solutions for a market cease to be available and the TPS 12 returns no answers 24, one method for recording such information is to produce summary entries with a price, of "nil" or no entry for price to indicate that the summary is not available or to delete existing entries with the relevant key features. A second method is to make no edits to the cache database 28 and retrieve only those entries having the most recent timestamp. As will be described later in further detail, the poller 36 may pre-populate the cache database 28 with results 42 that are known in advance to be appropriate for some later query time. When pre -populating the cache database 28, the poller uses timestamps to mark the time when the results 42 are produced and the time when the results 42 are valid.
  • results 42 reflecting anticipated "future” behavior
  • those results 42 would be distinguished from the results 42 that are appropriate at present. Distinguishing of the results can be accomplished by labeling of annotating summary or pricing-solution entries with the time or time ranges for which they are valid, and including the current time in the selection criteria used to select the results 42.
  • the travel planning system 10 enables users' queries 18 to be answered very rapidly and with very low marginal cost, at the expense of substantial pre-computation.
  • the combination of low latency and low marginal cost opens up a wide variety of business models for distributing and using travel information that have not been previously contemplated or commercially feasible.
  • the travel planning system 10 responds to queries using results 42 with less delay and in some cases without the need for informing the user that there will be a delay. This is because the latency associated with accessing pre-computed results 42 from the cache database 28 is much lower than the latency associated with querying conventional TPSes. Even if the cache database 28 contains a pricing-graph or other representation from which pricing-solutions must be extracted using availability merging and/or enumeration, the latency may be sufficiently low (e.g., less than 1 second) that to the user the interaction will be fluid.
  • the travel planning system 10 is capable of reducing the latencies to less than 1 second, while providing higher level services that are more data intensive. In comparison, the latencies of conventional TPSes are higher for less than comparable level of services (fewer options available, older data used, etc.).
  • FIGS. 13A-13C depict exemplary processes 250, 260, and 270, respectively, by which the travel planning system 10 supplies travel information in the form of cached results 42 to a user at the client system 16 (client 16).
  • process 250 receives a query 18 from a user (252) via web server 26.
  • the user may visit a web page using the browser 32, enter query parameters into a console displayed by the browser 32, and click a "submit" button within the console.
  • the web server 26 sends (254) a request to cache database 28 for results 42 that satisfy (and in some cases partially satisfy) the parameters of the query 12.
  • the selected results 42 are returned (256) to the user in the form of pricing solutions or summary information and displayed to the user via the browser 32.
  • process 260 in which direct tests are performed to determine whether selected results 42 are available before returning them to the user, is shown.
  • the availability merger 46 filters (262) the results 42 returned by the cache database 28 using one or more direct tests of seat availability, flights, and fares. Only those results that pass the direct tests are returned (256) to the user.
  • process 270 in which results 42 to a query 18 are extracted from a pricing graph, is shown.
  • the web server 26 sends (272) a request including the query parameters to the pricing-graph database 48 (which, in some embodiments, is the same as the cache database 28).
  • the web server 26 filters (274) the pricing-graph according to the parameters included in the request. For examples, during the filtering step (274) nodes corresponding to unavailable flights and fares may be disabled. Pricing solutions are enumerated (276) from the pricing graph of solutions and returned (256) to the user.
  • Examples of such implementations include systems that answer such queries using fare databases or using cached solutions from single-day, single-airport queries that were posed to other interfaces in the recent past without pre-emptive cache filling and without efforts to ensure correctness such as direct tests or even guarantee that queries are identical (e.g., that numbers and types of passengers are the same).
  • Results that have not been checked for availability in terms of their seat availability or fare availability often include highly misleading prices, or only support popular sets of dates or airports (for which ordinary queries have been recently received); and are therefore of very limited usefulness and popularity.
  • the travel planning system 10 Because the cache database 28 of the travel planning system 10 of FIG. 1 contains comprehensive and correct information, the travel planning system 10 produces reliable and accurate answers to flexible queries. Furthermore, unlike many conventional systems, the travel planning system 10 returns, to the user, answers to flexible queries that are immediately available for purchase by the user.
  • process 280 for answering a flexible date query using the travel planning system 10 (FIG. 1) is shown.
  • process 280 receives (282) a flexible travel query 12 specifying a range of one or more parameter of a desired trip for a user.
  • the query 12 may specify one or more of a range of departure dates, a range of return dates, and a range of airports.
  • the process 280 searches (284) the cache database 28 for results 42 (i.e., summary information or pricing solutions) that satisfy travel parameters of the query 12.
  • the results 42 include answers from previous queries (either preemptive queries 22, user queries 12, or a combination thereof).
  • the process 280 determines (286) that a result 42 satisfies the query 12, the process 280 selects (287) the result 42.
  • the selected results 42 are tested (288) for staleness using one or more of the techniques described above (e.g., availability merging process 100 described in FIG. 3) for determining whether a seat for given fare and set of flight(s) is available.
  • Those results 42 that are determined to be stale are discarded (290), while the remaining results 42 are presented (292) to the user. All of the results 42 returned to the user represent pricing solutions that are available for purchase at the time of presentation.
  • the process 280 suggests (294) alternate travel parameters in place of one or more of the travel parameters of the original query 12.
  • the process 280 may suggest alternative airports (e.g., nearby airports or airports with similar properties), alternative destinations (e.g., popular European destinations or other popular Caribbean islands), and/or alternative travel dates.
  • the process 280 forms (296) a new query that includes the alternate travel parameters and the remaining travel parameters of the original query.
  • the process 280 selects (296) the results 42 that satisfy the new query, checks for staleness (288), discards any stale results 42 (290), and returns (292) the remaining results 42 to the user.
  • the caching system 11 anticipates one or more travel parameters of a user's query 12, and searches the cache database 28 for cached results 42 that satisfy the anticipated travel parameters and presents any qualifying results 42 to the user prior to receiving any travel queries 12 from the user.
  • Anticipating travel parameters of interest to a user minimizes the data entry tasks the user must perform and presents travel results 42 immediately after the user accesses the web site. In general, presenting results 42 that anticipate users' travel interests is economically and/or computationally impractical using conventional TPS technology.
  • the caching system 10 makes it practical to anticipate queries and present travel information to users that have not explicitly requested such travel information.
  • a process 300 for presenting travel information to a user based on travel parameters anticipated to be of interest to the user is shown.
  • the web server 26 or at a third party web server one or more parameters of a travel query of likely interest to a user are predicted (302) by evaluating information associated with the user.
  • the travel parameters are predicted using historical information associated with previous queries submitted by the user. In other embodiments, the travel parameters are predicted by selecting default parameters that reflect general popularity. In further embodiments, the travel parameters are selected according to a geographic location of the user determined from location identification information such as an IP address.
  • Examples of predicted travel parameters include an origin location (e.g., an outbound city and/or outbound airport), a destination location (e.g., a destination city and/or destination airport), a departure date, and a return date.
  • the set of parameters that must be anticipated depends in part on the methods used to present results. For example, if the cheapest price, a price matrix, such as that disclosed in U.S. Patent 6,801,226 assigned to the assignee of the present invention, or pricing-solutions for a traditional basic round-trip query on specific dates are to be presented, the anticipated travel parameters may include an origin and destination location and outbound and return dates.
  • the presentation itemizes returned results 42 by a particular travel parameter of the query 12 for example displaying the cheapest price per outbound date in a calendar presentation
  • that travel parameter e.g., outbound date
  • the origin or destination may not be anticipated.
  • Some presentations may group the returned results according to one or more particular travel parameters of the query 12 that are not anticipated. For example, a presentation may display the cheapest price(s) for any outbound and return date in the next month.
  • a travel query that includes the anticipated travel parameters is posed (304) to the caching system 11.
  • the poller 36 accesses (306) the cache database 28 to provide a set of results 42 that satisfy the travel query.
  • the poller 36 returns (308) the results 42 to the client 16 at which the results 42 are presented to the user using one or more methods, including those discussed above.
  • the results 42 are pricing solutions that are available for purchase at the time they are presented (308) to the user.
  • the application returning the results 42 to the user optionally allows the user to edit the anticipated query if the returned results 42 are undesirable.
  • the caching system 10 searches (312) the results 42 stored in the cache database 28 for those results 42 that satisfy the travel parameter of the user's query 12 and returns (314) those results 42 to the user. If a new query 12 is not received (310) the caching system 11 assumes that the user is satisfied with the results 42 generated in response to the anticipated query parameters.
  • the travel parameters are selected based on information associated with a particular user while other techniques select travel parameters based on information associated with a collective group of users.
  • a user's identity or location is used to anticipate travel parameters for populating a travel query.
  • Different distribution technologies allow for different methods of user or user location identification. For example, web browsers permit storage of user identifiers in cookies, with subsequent access by web servers.
  • a process 320 by which a travel application anticipates a travel parameter based on location identification information found in a user identifier, e.g., a cookie is shown.
  • the process 320 detects (322) that a user at the client 16 has accessed a web site that runs the travel application.
  • the browser 32 on the client system 16 locates a cookie that is associated with the web site and stored in the client 16.
  • the cookie is a small piece of data that was previously sent from the web site to the client 16 when the user first accessed the web site.
  • the cookie includes information identifying the user and may additionally include travel preferences or travel parameters that had been previously indicated by the user.
  • the process 320 receives (324) the cookie from the user and reads (326) location identification information stored in the cookie. Using the location identification, the process 320 anticipates (328) an origin travel parameter including an airport located nearest to the user as determined from the location identification. If the process 320 receives (330) a response from the user, it records (332) new information pertaining to the response in the cookie.
  • the response may be a request to book a trip that includes the anticipated travel parameter.
  • the response may also be a travel query submitted by the user having a different origin parameter than the one anticipated (328) by the process 320.
  • the new information may be used by the travel application to anticipate travel parameters during future visits to the web site by the user.
  • a process 350 anticipates a travel parameter based on identification information of origin of an electronic communication sent by the user.
  • the process 350 receives (352) a request from a user at the client 16 to access the travel application. From the request, the process 350 determines (354) the source address of the client 16. For example, communication protocols based on TCP/IP and worldwide-web that the client 16 uses to request the travel application provides identification of the client 16 in the form of an IP address. The source address could also be based on caller ID information (e.g., a telephone number).
  • the process 350 uses the source address to determine (356) a geographic location of the user. For example, the travel application may invoke databases that map an IP address range to one or more of a country, region and city to determine a geographic location that corresponds to the IP address.
  • the process 350 assesses (358) other information associated with the user. For example, in addition to the geographic location of the user, the travel application may determine the company or organizational affiliation of the user, or the user's country of citizenship. The process 350 anticipates (360) travel parameters for a trip of interest to the user based on the location identification information and any other information associated with the user. For example, the travel application estimates origin airports that are located within or nearest to the geographic location corresponding to geographic location of the user as determined from the source address.
  • a travel application running on the agent's computer uses caller ID information to identify the user and/or to make a probable guess as to the user's location or affiliation.
  • the caller ID information is used by the travel application to populate the travel agent's display with prices and other information about trips the user commonly makes. If the user cannot be uniquely identified, the travel application uses the location identification information found in the caller ID information to display information about trips to popular vacation destinations from origin airports located nearest to the user as determined from the location identification information.
  • Other technologies may permit other mechanisms for identifying user identity, affiliation or location, including global positioning systems (GPS) data or cell on mobile telephones and pre-stored computer location or identifier information on applications running on computers.
  • GPS global positioning systems
  • the caching system 11 selects travel parameters that reflect general popularity, such as travel dates in the near future (e.g., 7 or 14 or 21 days from the present), travel dates corresponding to national or religious holidays, or popular origins and destinations (vacation spots).
  • travel dates in the near future e.g., 7 or 14 or 21 days from the present
  • travel dates corresponding to national or religious holidays e.g., 7 or 14 or 21 days from the present
  • popular origins and destinations vacation spots.
  • a process 370 performed by a travel application anticipates travel parameters for a user based on popular travel parameters.
  • the process 370 determines (372) popular travel parameters for different parameter types (e.g., origin, destination, travel dates, airports, etc.).
  • the popular travel parameters may include those travel parameters that are listed most frequently in the user preferences database 30 (FIG.
  • the process 370 stores (374) the popular travel parameters in a database and selects (376) one or more of the popular travel parameters to include in a travel query.
  • the caching system 11 may select one or more of the travel parameters at random or according to a predefined selection scheme. For example, a selection scheme may instruct the caching system 11 to select a fixed set of travel parameters.
  • travel parameters for a particular user are anticipated based on the travel parameters stored in the preferences database 30.
  • a user preferences database 30 stores identification information associated with users and prior queries posed by those users, including travel parameters used in those queries. For example, travel parameters for origin, destination, and dates of travel may be anticipated from the origin, destination, and dates of the most recent query posed by the user.
  • a travel application performs a process 380 for anticipating travel parameters from information related to prior searches performed by the user. This information may be stored in a historical database (not shown).
  • the process 380 identifies (382) the user. For example, the travel application may require the user to enter authentication information, such as a login name and/or password. From the authentication information, the process 380 uniquely identifies (382) the user.
  • the process 380 locates (384) a record that stores the user's preferences in the preferences database 30 (FIG. 1).
  • the process 380 selects (386) one or more of the travel parameters used in one or more previous queries stored in the record.
  • the process 380 may select the travel parameters for, e.g., the most recent query stored in the user's records. Alternatively, the process 380 may select travel parameters that the user requested most frequently in previous queries submitted by the user. The process 380 may also select most popular travel parameters to include in the travel query. For example, in a travel query, the process 380 may include (1) anticipated travel parameters for origin and destination selected from a list of, e.g., the most popular origins and destinations determined from queries of other users and (2) anticipated travel parameters for travel dates selected from the travel dates of the most recent query stored for the user in the preferences database 30. The process 380 submits (387) the travel query to the caching system 11 and returns (388) a set of cached results 42 that satisfy the travel query.
  • the process 380 presents (389) to the user a list of travel parameters that serve as likely alternatives to the default selection included in the travel query.
  • the browser 32 may present the travel parameters as a pull-down menu of travel parameters that the user can select to include in a new query. The user may then select one or more of the alternatives in place or in addition to the default selection.
  • d. Result Properties For example, the browser 32 may present the travel parameters as a pull-down menu of travel parameters that the user can select to include in a new query. The user may then select one or more of the alternatives in place or in addition to the default selection.
  • travel parameters are anticipated based on properties of the cached results 42.
  • destination and/or travel date parameters for a query may include destinations and/or times for which the best available price is particularly low relative to other possibilities or historical prices for the same parameters.
  • Other travel parameters that are included in the query may be anticipated from identification information associated with the user.
  • a process 390 performed by a travel application anticipates travel parameters based on properties of the cached results 42 stored in the cache database 28.
  • the process 390 anticipates (392) an origin travel parameter for a user from location identification information associated with the user. For example, the process 390 may use the process 320 described in FIG. 16 to anticipate an origin travel parameter.
  • the process 390 searches (394) the cache database 28 for results 42 that include the anticipated origin travel parameter and that are particularly cheap (e.g., marked down at least 25% from an average price).
  • the process 390 displays (396) those results 42 to a user (e.g., a traveler or a travel agent serving the traveler).
  • the results displayed to the user may be accompanied by information on historical prices.
  • the process 390 anticipates a travel parameter other than an origin travel parameter for the user in step 392.
  • the process 390 may anticipate a destination travel parameter from previous queries submitted by the user or from a list of most popular destinations stored in the user preferences database 30.
  • the process 390 may anticipate multiple travel parameters in addition to the origin travel parameter. The multiple travel parameters may be anticipated based on other factors such as user's historical advance purchase.
  • Destinations may be defaults (e.g., vacation destinations, or vacation destinations popular and practical for given origin), those of interest to user (e.g., as entered by user in preference database), relate to results (e.g., those destinations for which particularly cheap solutions are available), or be calculated based on other known properties of an individual such as types of trips searched for or purchased in past and their price level.
  • the travel application may receive the origin travel parameter from the user or access an origin travel parameter that is preferred by the user from a record stored for the user in the preferences database 30.
  • Travel application for implementing the process 390 can be included in web home pages, including those constructed by web portals such as AOL®, Yahoo®, Google® and MSN®, or airline or travel agent pages, or desktop notification applications, or regular e-mail or RSS feeds, or as embedded parts of user-created web pages such as event, attraction or lodging web pages, or as advertisements embedded in other web pages, or as interactive advertisements embedded in other web pages. e. Specification by user
  • the travel planning system 10 may populate a query with travel parameters based on travel preferences specified by users in the user preferences database 30.
  • a process 410 performed by a travel application anticipates travel parameters based on preferences specified by a user.
  • the user's preferences are stored in a record associated with the user in the user preferences database 30.
  • the process 410 identifies (412) the user.
  • the process 410 may require the user to enter authentication information, such as a login name and/or password. From the authentication information, the process 410 uniquely identifies (412) the user.
  • the process 410 locates (414) a record that stores the user's preferences in the preferences database 30.
  • the process 410 selects (416) one or more of the travel parameters from the user's record to include in a travel query.
  • the process 410 is aware of one or more specific trips a user is interested in, including locations, dates, and price, and proactively informs when such a trip becomes available.
  • the process 410 may send the user an email or instant message that includes pricing and schedule information for one or more trips.
  • Travel applications for performing process 410 may be included in web home pages, including those constructed by web portals such as AOL®, Yahoo®, Google® and MSN®, or airline or travel agent pages, or desktop notification applications, or regular e-mail or RSS feeds.
  • the display may include controls for accessing details.
  • the entries may be web links that redirect to an interface that presents details of one or more pricing-solutions matching the displayed summary, which may likewise be extracted from the cache database 28 or which may be recomputed by the TPS 12 using current data by posing a pricing query with appropriate parameters (e.g., the origins and destinations and dates of the summary).
  • a process 420 performed by a travel application is aware of origin and destinations of interest to user, and presents (422) summaries for a range of dates, for example, as a calendar over outbound departure dates presenting the lowest price for that date.
  • the process 420 includes a display having controls for altering the query parameters (e.g., origins, destinations, and length of stay).
  • the process 420 requests (426) new summary information associated with the edited query parameters from the cache database 28 and displays (428) the new summary information to the user.
  • optional controls such as web links can be used to cause more detailed information to be presented.
  • a process 430 performed by a travel application that uses entry forms similar to the entry forms used by conventional travel applications found on such websites as "Orbitz.com” and "Expedia.com” in which trip segment origins and destinations and travel dates are entered by the user.
  • the process 430 anticipates (432) travel parameters of interest to a user from user preferences database 30 or from other sources and fills (434) in the entry form with travel parameters (e.g., airports, cities and dates).
  • the application queries (436) the cache database 28 with the travel parameters and receives (438), from the database 24, results 42 that satisfy the anticipated query parameters prior to any data entry by the user.
  • the process 430 displays (440) the results 42 to the user.
  • the process 430 may display the results 42 to the user in a variety of presentations, including a summary matrix, such as that disclosed in U.S. Patent 6,801,226 assigned to the assignee of the present invention, and a listing of pricing solutions.
  • a summary matrix such as that disclosed in U.S. Patent 6,801,226 assigned to the assignee of the present invention
  • a listing of pricing solutions Referring to FIG. 26, an example of a display 442 that presents prices for trips from Boston to Los Angeles on various carriers is shown.
  • the results 42 displayed to the user may include alternative origin and destination airports, dates or combinations that may be available as "shortcuts" to explicit entry.
  • entries surrounded by [] are pre-populated, but editable, query parameters; entries surrounded by ⁇ > are buttons for altering query parameters; and entries surrounded by () are alternative airports (e.g., in display 442, BOS and PVD are presented as alternative origins and LAX, PAR, and MIA are presented as alternative destinations).
  • Clicking on an alternative parameter causes the entry form to be filled with the alternative parameter and the application to display travel options associated with the alternative parameter. For example if the user clicks on PVD, the application presents prices for trips from PVD to LAX that originate on Jan 22 and return on Jan 27.
  • anticipatory display may include summary information, such as in the form of a matrix, but not listing of pricing solutions (since the cache in this example only includes prices).
  • the application may be included in airline and travel agent web sites, CRS (computer reservation system)/GDS (global distribution system) interfaces for travel agents, or embedded in web sites for events, attractions or lodging.
  • a travel planning application populates queries with travel parameters (or equivalently, some form of identification of the application instances that can be used to retrieve parameters from a database) that are hard- wired to the instance of the application that is accessed by a user.
  • travel parameters or equivalently, some form of identification of the application instances that can be used to retrieve parameters from a database
  • Examples of an application instance include URLs (i.e., text-based addresses that identify specific resources on the Internet, such as web pages) or short computer programs intended to be embedded in web pages or desktop environments, that contain identifiers or query parameters.
  • a web travel planning application process 450 in which the travel planning application is replicated with parameters provided by an organizer of an event is shown.
  • a web travel planning service offers a web interface in which Internet users may produce custom instances of travel planning applications particularized for certain query parameters.
  • the web travel planning application process 450 receives (452) a default destination and travel dates for an event such as a widely attended convention from a user (e.g., a person or party affiliated with the event).
  • the web travel planning application process 450 receives (454) a URL from the web travel planning service that points to a caching system 11 of a travel planning system 10 and that also includes the destination and travel dates as URL parameters.
  • the user instructs the web travel planning application process 450 to embed (456) the URL in a link on a web page affiliated with the event (e.g., a convention home page).
  • the caching system 11 When attendees access the web page and click on the embedded link, the caching system 11 generates a web page of cached results 42 that satisfy the destination and travel dates included in the URL. The caching system 11 sends these results 42 to the web travel planning application process 450.
  • the web travel planning application process 450 After receiving (458) the results 42, the web travel planning application process 450 presents (460) information particular to the origin airport of the attendee by using the attendee's IP address or identification information found in a cookie.
  • the web travel planning application may generate a set of computer instructions to be embedded in the event home page to cause the price information to be automatically displayed to an attendee accessing the event home page without the attendee clicking on a link.
  • These instructions may take the form, for example, of Java or JavaScript instructions that contain query parameters or identification information (for example, a unique identifier for the custom application instance, in this case unique to the convention).
  • the computer instructions cause the attendee's web browser to send a request for prices and other trip information of relevance (e.g., advertisements).
  • the request includes the query parameters.
  • the request is processed by the cache system 11 returning cached results 42 satisfying the query parameters.
  • the cached results 42 are subsequently displayed on the home page.
  • the home page also displays controls for sorting and filtering the results and controls for changing the query parameters.
  • Anticipatory presentation of cached results 42 based on identification information associated with the attendee is used either in a context where the attendee has the capability of altering the display by specifying a different query, or one in which the display is static.
  • an example of an interface 462 presented to an attendee from a conference home page is shown.
  • the dates and destination are particular and are preset to match the dates and destination of the conference.
  • the origin is anticipated from location identification information of a user visiting the conference home page using mechanisms described above.
  • the origin may also be edited by the user.
  • the conference home page may provide controls for sorting and filtering travel options presented to the user.
  • the appearance of the interface application may also be customized by the party hosting the conference home page, for example including title or utilizing look-and-feel parameters provided by the party in a web cascading style sheet (CSS).
  • the interface application may be implemented using a source code utilizing HTML, XML, XHTML, MSHTML, JavaScript, or any other appropriate programming language.
  • the interface 462 shown in FIG. 28 and other similar interfaces are suitable, for example, for event, organization or attraction web pages, or as advertisements embedded in other web pages, or as interactive advertisements embedded in other web pages, and especially as created using a travel planning service that generates such particularized instances using a public interface.
  • FIG. 29 an example of an interface 470 affiliated with lodging or other services having time-varying availability or price is shown.
  • the interface 470 presents travel information from the cached database 28 combined with other computed or cached source of price or availability information for the lodging service.
  • the interface 470 presents a combined travel/lodging options for each date or date combination.
  • the combined travel/lodging options include the best travel price with the price of lodging over the duration of stay.
  • the interface 470 and other similar interfaces are also suitable for event, organization or attraction web pages, or as advertisements embedded in other web pages, or as interactive advertisements embedded in other web pages. Such interfaces may be produced by a travel planning service from a publicly available interface.
  • the integration of the price or availability information for the lodging service may be done by the travel application using a table or database provided by the lodging service provider to the travel application.
  • a table or database provided by the lodging service provider to the travel application.
  • a price and availability table may be provided to the computer program in a data region of the web page.
  • the lodging service provider may send a table or a database of price and availability information to a middleware application used to integrate cached results 42 stored in the cache database 28 with service price and availability information and generate a combined result table for display.
  • various other implementations may be used.
  • Parameters may be based on promotions or advertisements, for example choosing destinations and/or times relating to products that a supplier or agent desires to promote.
  • advertisements or promotions may be presented in addition to the cached travel results 42.
  • Such advertisements or promotions may be for travel options (e.g., by highlighting one or more solutions or placing in a prominent position) or for other goods or services (e.g., advertisements for hotels associated with a flight option display).
  • the caching system 11 detects changes by comparing new results 42 to corresponding results 42 having timestamps that immediately precede the timestamps of the new results 42.
  • Users may purchase subscriptions to services that notify the users of changes to results 42 in the cache database 28. Various types of subscriptions and notification services are described below in further detail.
  • a traveler or travel agent may desire to be notified immediately whenever the price for travel in a particular market (e.g. city pair) for particular dates falls below a certain price, so that they may purchase a ticket before the price changes or seat availability is exhausted.
  • a particular market e.g. city pair
  • Such a use is particularly appropriate for agents or airlines using business models in which the traveler pays the agent or airline a fixed price for any pricing-solution satisfying certain basic location and time requirements, and the agent or airline has substantial freedom in choosing the pricing-solution to satisfy the requirement and the purchase time and may particularly benefit from finding a low priced pricing-solution satisfying the requirements.
  • a process 500 presents travel information to a user based on detecting a change in one or more of the travel options 42 stored in the cache database 28.
  • the process 500 retrieves (502) a first cached result 42 from the cache database 28 in response to submitting a travel query to a travel planning system at a first time. At a later time, the process 500 receives (504) a second cached result 42 obtained in response to submitting the travel query to the TPS 12. For example, the timestamp of the first cached result 42 may immediately precede the timestamp of the second cached result 42.
  • the process 500 compares (506) the first, retrieved cached result 42 to the second, retrieved cached result and determines (508) whether the results 42 are different. If a change is detected (508), the process 500 determines (510) whether a parameter of the second cached result 42 matches criteria previously specified by the user.
  • the process 500 may determine that the price of the second cached result matches is below a threshold specified by the user. If a match is determined (510), the process 500 reports (512) the change to a user in a report that includes travel parameters of the second cached result 42.
  • the report may also include travel parameters of the first cached result 42 and the difference (e.g., in price) between the first and second results 42.
  • the party that owns and operates the caching system 11 receives (514) a payment from the user.
  • a single payment is received from the user in return for continuously notifying the user of changes to cached travel options over a predetermined period of time (i.e., a subscription to the notification service is purchased by the user).
  • payment is received from the user in response to the user purchasing one of the travel options, with the payment related to the price of the second result.
  • payment is received from the user in response to the user purchasing one of the travel options, with the payment related to the price of the second result plus a portion of the difference in price between the first and second travel options.
  • a process 520 presents travel information to an enterprise that reflects the change in price of a flight operated by a competitor of that enterprise.
  • the process 520 retrieves (522) cached travel options 42 for travel planning from the cache database 28 and analyzes (524) the cached travel options 42 to detect (526) a change in price of a flight operated by the competitor. For example the process 520 may detect if the price of the flight, for a given set of travel related parameters, has increased or decreased by a predetermined amount.
  • the process 520 may determine that the price of the flight has changed by a predetermined amount relative to a price of a corresponding flight offered by the enterprise. If a change is detected (526) the process 520 reports (528) the change to the enterprise. For example, the process 520 reports (528) the change by sending a report to the enterprise that displays the flight and its current price. The report may also include the previous price of the flight, and the difference between the previous price and the current price. Additionally, the report may include the difference between the current price of the flight offered by the competitor and a similar flight offered by the enterprise. In exchange for providing the report, the party that owns and operates the process 520 receives (530) a payment from the user. In some embodiments, payment from the enterprise is received in return for continuously notifying the enterprise of changes to prices of flights maintained by other enterprises over a predetermined period of time (i.e., in the form of a subscription).
  • Streaming prices As a third example, travel providers may wish to display travel information stored in the cache database 28 in a streaming form, (e.g., akin to a stock ticker). The travel information may be displayed in streaming form, for example, on a kiosk or monitor in an airport or the window of a computer desktop application.
  • a streaming form e.g., akin to a stock ticker.
  • the travel information may be displayed in streaming form, for example, on a kiosk or monitor in an airport or the window of a computer desktop application.
  • a process 540 presents travel information to a user in streaming form based on the results 42 stored in the cache database 28.
  • the process 540 retrieves (542) cached travel options 42 from a cache database 28 corresponding to a trip of interest to a user. From the retrieved travel options 42, the process 540 extracts (544) travel information to be displayed to a user. For example, the information includes the price of the travel options.
  • the process 540 renders (546) the information on a display.
  • the information is rendered as a moving ticker across the display.
  • the process constructs the ticker by including certain information, e.g., the origin and destination and a price.
  • the process 540 determines (548) if there is a change in a price of the flight and updates (550) the information associated with the flight and displays (552) the updated information.
  • the process 540 regularly polls the cache database 28 for prices of the flight; and presents the prices on the display.
  • the updating (550) is performed only after the change is detected. Updating information rendered on the display only after a change is detected, rather than regularly polling the cache database 28, is more computationally efficiently and requires fewer communication resources.
  • the travel information may be displayed in real-time or near real-time. 4. Subscription
  • Users may purchase a subscription that grants unlimited access to one or more of the foregoing notification services over a period of time (e.g., a month, or a year) rather than paying a separate fee for each time they use one of the services.
  • the terms of a subscription may be customized for different users and generally include: one or more notification services to be provided, criteria to be applied to the notification service(s), a specified period of time over which access to the service(s) are granted or a number of times the service(s) may be used, and a purchase price.
  • a process 570 notifies a user of changes to travel information who has subscribed to one or more notification services.
  • the terms of the subscription including the notification services to be provided and the criteria to be applied in each notification service are stored (572) in a subscription database 31 (FIG. 1).
  • Match criteria include for example, changes to prices for round-trip queries with particular market and date combinations, or on certain carriers, or only when the price for any solution that matches a particular set of complicated traveler-defined criteria drops below some specified threshold.
  • Match criteria can be expressed in terms of the keys used in the entries of the summary tables stored in the cache database 28. Examples of summary tables are shown above in Tables 1-8.
  • the match criteria specify a change that is to be detected in one or more entries, such as a reduction in the best price.
  • the process 570 determines (574) whether the results 42 stored in the cache database 28 have undergone any changes.
  • the process 570 applies (576) the match criteria specified in the subscription to the results 42 stored in the cache database 28.
  • the key features of that summary entry such as origin, destination, outbound and return date
  • the process 570 directly matches (578) answers 24 returned by the TPS 12 against the match criteria. Travel information corresponding to the summary table entries that fit the match criteria are returned (580) to the user.
  • the travel information may be in the form of a pricing solution or summary information.
  • subscriptions are organized into data structures appropriate for fast match checking. For example when processing pricing- solutions for a particular market and date pair, a set of subscriptions that match the market and dates are determined. Subsequently, the pricing-solutions are tested against the remainder of the match requirements specified by the set of subscriptions.
  • a conceptual structure of the subscription database 31 includes multiple data structures 590: a TABLE SUBSCRIBER data structure 592, a TABLE SUBSCRIBER SUBSCRIPTIONS data structure 594, a TABLE SUBSCRIPTION data structure 596, a TABLE SUBSCRIPTION MATCH data structure 598, and a TABLE SUBSCRIPTION STATE data structure 600.
  • the data structures 590 are in the form of tables and are sometimes referred to as "tables 590".
  • the data structures 590 could be represented as tree structures, array structures, and other types of data structures. Each of the data structures 590 are described in further detail below in connection with Tables 9- 13.
  • the T ABLE SUB SCRIBER data structure 592 shown in Table 9 holds information about a subscriber including information for transmitting data to subscriber.
  • Table 9 TABLE SUBSCRIBER
  • the TABLE SUBSCRIBER SUBSCRIPTIONS data structure 594 shown in Table 10 provides a mapping between a subscriber and one or more subscriptions purchased by the subscriber.
  • the T ABLE SUB SCRIPTION data structure 596 shown in Table 11 holds basic subscription information, including information about the level of aggregation of information (e.g., should changes be itemized by carrier, date, or market, or alternatively, aggregated across various travel parameters).
  • the level of aggregation of information e.g., should changes be itemized by carrier, date, or market, or alternatively, aggregated across various travel parameters.
  • TABLE SUBSCRIPTION data structure 596 also includes the travel information to be sent to a subscriber (e.g., current best-price for a single adult, or a detailed pricing- solution including flight and fare information).
  • travel information e.g., current best-price for a single adult, or a detailed pricing- solution including flight and fare information.
  • the TABLE SUBSCRIPTION MATCH data structure 598 holds "match criteria" information that characterize the parameters of pricing-solutions that are of interest to the subscriber. These parameters may include one or more of an origin, destination, dates, price, and so forth. These parameters may also include features formed by aggregated travel parameters (e.g., month, country, etc.). Table 12: TABLE SUBSCRIPTION MATCH
  • the TABLE SUBSCRIPTION STATE data structure 600 holds information about the travel information that was sent most recently to a subscriber.
  • a process 610 is shown for reporting changes to the best available price of a travel option to a subscriber using the data structures 592, 594, 596, 598, and 600.
  • the process 610 determines (612) whether the poller 36 has updated the price of a cached result 42 having the travel parameters of the TABLE SUBSCRIPTION MATCH data structure 598 (Table 12). In some embodiments, the process 610 determines whether the
  • TABLE SUBSCRIPTION MATCH data structure 598 includes a feature formed from aggregated parameters.
  • the process 610 searches (614) the subscription database 31 for records in the
  • TABLE SUBSCRIPTION MATCH data structure 598 (Table 12) that match the travel parameters.
  • the process 610 locates (616) the records in the TABLE SUBSCRIPTION data structure 596 (Table 11) having a subscription-id that matches the subscription-id of the matching TABLE SUBSCRIPTION MATCH records.
  • the process 610 applies (618) the match criteria listed in the TABLE SUBSCRIPTION data structure 596 to the appropriate travel parameters of the cached results 42 (which may include fields of a summary table) and determines (620) the cached results having travel parameters that meet the match criteria.
  • the process 610 determines (622) which of the "itemize-by- ⁇ travel parameter ⁇ ?” fields of the TABLE SUBSCRIPTION data structure 596 are true and clears (624) those that are false.
  • the process 610 uses the "itemize-by" travel parameter to retrieve (626) any existing records in the TABLE SUBSCRIPTION STATE data structure 600 (Table 13) indicating previous transmission for carrier/date/markets.
  • the process 610 applies (628) the match criteria within the max-price and price-resolution fields of the TABLE SUBSCRIPTION data structure 596 (table 11) to the cached result 42 and determines (630) whether the price change meets the match criteria. If not, the fields of the TABLE SUBSCRIPTION STATE data structure 600 are not updated (632) and thus remain unchanged. If so, the caching system 11 updates (634) the fields of the
  • the process 610 contacts the subscriber using the contact information stored in the TABLE SUB S CRIBER data structure 594 (Table 9). In those embodiments in which billing is based on a number of transmissions, the caching system increments the price of the "amount due" field of the TABLE SUB S CRIB ER data structure 594 after every transmission.
  • the process 610 can be applied to other query parameters such as cabin-class or maximum-stop restrictions.
  • travel applications may need to receive a block transmission of the state of a subscription, for example in the case where a travel application is re-started and loses its state.
  • block transmissions divide data into multiple blocks and treat each block as a record. Each record has a count field, data, and an end-of-record marker. The data is sent one block at a time. If the transmission fails, it can be resumed starting at the last record sent.
  • the block transmission of the state of a subscription can be supported by re- sending the TABLE SUBSCRIPTION STATE records for the subscription, or alternatively by clearing all TABLE SUBSCRIPTION STATE records for the subscription and re -processing all summarization tables in the result database to regenerate TABLE SUBSCRIPTION STATE records and notification messages for the subscription.
  • a method for degrading quality of service is to impose a selective delay between the detection of a change and the transmission of the associated notification message. This can be implemented by simply storing a "quality of service" indicator in the TABLE SUBSCRIBER data structure 592 (Table 9) or TABLE SUBSCRIPTION data structure 596 shown in Table 11 and referencing this indicator prior to transmitting (636) messages to the subscriber.
  • the subscription database 31 includes separate data structures (e.g., tables) that relate a subscriber or a subscription to properties of pricing-solutions or summary tables that include the travel provider as a parameter.
  • the caching system 11 filters travel information associated with those pricing-solutions or summary tables from the change messages transmitted to the subscriber and/or alters the quality of service of change messages that include travel information associated with those pricing-solutions or summary tables.
  • Travel providers and TPSes are often concerned with the possibility that data entry errors, computer programming errors, or other mistakes may result in unexpected and unwanted prices from being offered or other aberrant behavior such as failure to generate pricing-solutions for reasonable queries or unusually long query response times. If such behavior occurs, it is desirable to detect it as quickly as possible, preferably before users have a chance to detect or act on the behavior.
  • a method for detecting problems is to regularly probe the TPS 12 by posing queries and checking for unusual behavior, using thresholds, heuristics, or tables of historical behavior or expected behavior to evaluate the responses. If problems are detected, providers or the TPS 12 are notified.
  • the TPS 12 may be temporarily disabled or particular queries or database entries within the TPS 12 may be disabled.
  • the queries 22 sent by the caching system 11 to the TPS 12 to generate answers 24 can also be used to detect unusual behavior of the TPS 12.
  • the use of the queries 22 is particularly advantageous because the queries 22 are comprehensive and may be posed before users have access to the answers.
  • a process 650 detects errors and unusual behavior in a travel planning system (e.g., TPS 12).
  • the process 650 poses (652) queries 22 to the TPS 12.
  • the travel queries are posed (652) at different times and include a variety of different combinations of travel parameters.
  • the process 650 receives (654) answers 24 to the queries 22 from the TPS 12 and stores (656) the answers 24 in the cache database 28 as cached travel options 42. Tables of historical price and performance behavior may be populated from such queries.
  • the process 650 analyzes (658) the cached travel options 42 for anomalies.
  • a heuristic for notification of aberrant behavior may be that the price a specific airline offers in a market should not ever be below the minimum of $100 and/or the average minimum price over the preceding month of travel in the market with the same length of advance purchase and destination layover.
  • the process 650 maintains historical price information by market and date of the results 42 stored in the cache database 28.
  • the process 650 analyzes the cached travel options 42 until process 650 determines (660) that an anomaly exists. If the process 650 detects (660) an anomaly in a cached travel options, it notifies (662) an administrator of the TPS 12 that a problem may exist.
  • the service provider or operator of the TPS being monitored may subscribe to a service for detecting unusual behavior using process 650 on a regular basis over a predetermined time (e.g., every day for a month).
  • the historical price records of particular travel plans made at different times may be taken together and combined using an algorithm to plot or otherwise describe a trend over multiple time periods.
  • the points on the curve may be fitted using standard statistical means to extrapolate to future time periods.
  • trends can be computed for business factors such as revenue (price less expenses) over time and if there is a significant pattern, then extrapolations can be made so corrective actions can be taken earlier than otherwise possible.
  • the historical price records may also be used to provide a clear and complete record of a carrier's price offerings over a given period of time (e.g., a year or several years). Such a record can provide useful information during legal inquiries or proceedings. For example, charges of price fixing can be very damaging to a company even though untrue especially in a tightly regulated industry such as the airline travel business. If a company had access to historical pricing information it could help provide a strong defense against such false charges.
  • Advertisement Travel agents and travel providers desire to often promote their products using various forms of advertisement. Advertisement copies are often determined well in advance of viewing, such as generally the case with print, television, and radio advertisements. Dynamically priced products such as air travel prices or availability of the products presented in such static advertisements may be stale or inapplicable by the time those advertisements reach an audience.
  • the Internet, electronic billboards, mobile telephones, networked video game consoles, subscriber- specific dynamic television advertisements and other technologies offer the possibility of more rapid electronic dissemination of information and better targeted advertisements that do not present stale (and thus misleading) data.
  • Traditional TPSes often do not support such dynamic advertising, especially for air travel, because of the latency and cost involved in calculating pricing-solutions.
  • Some airlines and travel agents periodically pose queries for a small set of markets and particular dates, and use resulting prices of computed pricing solutions to populate lists of promotions (e.g., listing on a carrier's web site special promotional fares available the next weekend).
  • promotions are often not well- targeted at the web user, in large part because the airline or agent cannot afford the expense of posing the variety of queries necessary to target a diverse set of travelers.
  • some carriers and travel agents tailor the listing based on the traveler's known origin airport, but not preferred travel dates.
  • the pricing-solutions on the listing typically include only special promotional fares to limit the computational expense of calculating the promoted prices.
  • the pricing solutions are not continually kept up to date with changing seat availability. Rather, the pricing solutions are refreshed once per day or once per fare load.
  • a provider may promote products or services through polled advertisements that are generated instantly based on cached results and user information. For example, just prior to showing a television advertisement in Seattle, a television network or cable system sends a request to an airline for current advertisements appropriate for users in Seattle and the airline responds with appropriate travel options 42 retrieved from the cache database 28.
  • An airline/agent may actively "push out” advertisements for their products or services to a target audience. For example, an advertisement in the form of computer instructions may be sent to the client 16 over the Internet. The instructions cause the client 16 to send user info to the airline/agent. The airline/agent tailors the advertisement according to the user info and transmits the advertisement back to the client 16, which subsequently displays the advertisement to the user.
  • the provider may use the information provided by the client 16 to lookup additional information associated with the user stored in one or more databases (e.g., the user preferences database 30 of FIG. 1).
  • additional user information include: a history of searches and ticket purchases, frequent flyer information, and demographic and financial info.
  • Advertisement Database A carrier or agent may use the results 42 stored in the cache database 28 to populate an advertisement database for advertisement and promotions (e.g., generating lists of pricing solutions for different kinds of people, such as those in different locations).
  • the advertisement database may periodically receive updated results 42 retrieved from the cache database 28. Alternatively, the advertisement database may receive updated results 42 only on demand.
  • a process 680 by which a travel provider advertises a service or product to a user at the client 16 is described.
  • the airline/agent may pay for computer instructions (e.g., Java script) embedded in a web page operated by or affiliated with the provider) to be embedded in other web pages, either arranging for direct inclusion or paying an ad network such as Google to include the computer instructions.
  • an ad network allows ad bids to be keyed off markets, dates.
  • the travel provider uses a subscription table to keep such ads updated with up-to-the-minute price and availability information as well as bid prices (e.g., based on measures of profit, competitive situation, emptiness of flights).
  • process 680 When the user accesses the web page, process 680, e.g., an advertisement server owned and/or operated by the travel provider requests (682) information associated with the user. Such information may be information stored in a cookie or the IP address of the client 16. The process 680 determines (684) whether a cookie is stored in the client 16. If the process 680 determines (684) that no cookie is stored in the client 16, the process 680 produces (685) a new user ID and returns (687) the user ID to the client 16 for inclusion in a cookie. The process 680 determines (691) the location of the user from the user's IP address or by using other techniques.
  • the advertisement server determines (686) the identity of the user and the location of the user.
  • the process 680 selects (688) an origin airport located nearest to the location of the user.
  • the process 680 retrieves (690) additional information associated with the user from the user preferences database 30.
  • the process 680 selects (692) promotional locations and dates from a promotional database storing pricing solutions received from the cache database 28.
  • the process 680 returns (694) to the client 16 an advertisement including prices for specific markets and dates.
  • the message includes fields in which the user may enter alternative travel parameters (e.g., alternative origins, destinations, and travel dates).
  • the message may also add in other dates or location specific prices such as hotel costs. Additionally, the message may enable the user to manipulate personal defaults stored in the user preference database 30 such as entering or changing favorite trips, dates, express preferences, and other travel preferences.
  • the process 680 determines (696) whether the user has selected any alternative travel parameters. If one or more alternative travel parameters are received (696) from the user, the process 680 returns (698) results 42 that satisfy the alternative travel parameters.
  • the process 680 stores (700) the alternative travel parameters in the cookie with an annotation that they had been provided by the user. When presenting subsequent advertisements to the user, the process 680 may base the advertisements on the alternative travel parameters. H. Revenue management
  • users or providers or others may pay or rank or vote to ensure that queries specific to their business, services, or products are used to preemptively fill the cache database 28 (e.g., to ensure some minor airport is included in some of the results 42).
  • the selection of travel parameters to include in TPS queries 22 are be based on tables of popular markets and dates as determined by statistics based on prior queries, prior ticket sales, airport size, and so forth.
  • the TPS queries 22 are based in part on subscription services or info stored in the user preference database 30, such as what markets users want to display on home page. III. Examples
  • the following example illustrates the reduction in computational costs provided by the travel planning system 10 for answering users' travel queries.
  • a web site for a single airline of medium-large size having a network spanning over 100 cities and serving approximately 10,000 markets. If it is desired to pre-compute answers for all the carrier's markets over all outbound and return dates within 100 days of the present, then there are approximately 5000 date pairs, and 50,000,000 possible "basic queries" of a city pair and outbound and return date pair.
  • a conventional TPS such as TPS 12 requires 5 CPU-seconds to answer each basic query, then populating the entire database once requires approximately 250,000,000 CPU-seconds. To maintain a 250 second (4 minute) bound on result staleness (age), approximately 1,000,000 CPUs would be required. Though maintaining this many CPUs may be currently possible at the present time, in most cases, it would not be economically practical.
  • TPSes such as those described in U.S. Patent 6,275,808 by Carl G. de Marcken and assigned to the assignee of the present invention and incorporated herein by reference can save work by evaluating many days of travel window as part of one query, because much of the computational cost of fare and rule retrieval and rule evaluation is shared across the itineraries and travel dates under consideration.
  • Such a TPS can in many cases answer a single query between two airports with 100-day outbound and return time windows in 100 seconds or less. With such performance, the number of queries to populate the database is reduced to one per market (10,000) and the total computational effort to 1,000,000 CPU-seconds. To maintain a 250 second staleness threshold requires only 4000 CPUs. Similar savings can be had by processing multiple origins and destinations as part of one query, because many flights and markets and fare-component and priceable-units are shared between solutions for the multiple airports.
  • the components of the travel planning system 10 can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
  • the components of the travel planning system 10 can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine- readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • Method steps associated with the travel planning system 10 can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating an output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
  • special purpose logic circuitry e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a random access memory or both.
  • the essential elements of a computer are a processor for executing instructions and one r more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non- volatile memory, including by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto-optical disks e.g., CD-ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

Abstract

La présente invention concerne des systèmes et des techniques de configuration de base de données. Des résultats issus d'un cache et fournis par un système de planification de voyages interrogé sont mis en mémoire avec des requêtes de voyages spécifiant les paramètres de voyages. Des données correspondant aux résultats issus d'un cache sont mémorisées dans des enregistrements dans la base de données, qui comportent des champs correspondant à des catégories prédéfinies d'informations horaires et tarifaires. Une super-catégorie d'au moins deux des catégories prédéfinies est définie de manière telle que ladite super-catégorie comprend au moins une partie des informations horaires et tarifaires des deux catégories prédéfinies au moins. Les enregistrements sont indexés par la super-catégorie.
PCT/US2008/050188 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide d'une base de données cache à couches WO2008086150A2 (fr)

Applications Claiming Priority (20)

Application Number Priority Date Filing Date Title
US11/650,327 2007-01-05
US11/650,296 2007-01-05
US11/650,324 2007-01-05
US11/650,327 US20080167907A1 (en) 2007-01-05 2007-01-05 Cache poller for providing travel planning information
US11/650,296 US20080167912A1 (en) 2007-01-05 2007-01-05 Providing travel information using cached summaries of travel options
US11/650,360 US20080167910A1 (en) 2007-01-05 2007-01-05 Providing travel information using a notification service
US11/650,358 US20080167909A1 (en) 2007-01-05 2007-01-05 Updating a database of travel information
US11/650,301 US20080167906A1 (en) 2007-01-05 2007-01-05 Support for flexible travel planning
US11/650,312 2007-01-05
US11/650,360 2007-01-05
US11/650,301 2007-01-05
US11/650,351 2007-01-05
US11/650,312 US7711587B2 (en) 2007-01-05 2007-01-05 Providing travel information using cached query answers
US11/650,342 US20080168093A1 (en) 2007-01-05 2007-01-05 Providing travel information using a layered cache
US11/650,351 US20080167908A1 (en) 2007-01-05 2007-01-05 Notification service for presenting travel information
US11/650,358 2007-01-05
US11/650,325 2007-01-05
US11/650,342 2007-01-05
US11/650,324 US20080167886A1 (en) 2007-01-05 2007-01-05 Detecting errors in a travel planning system
US11/650,325 US20080167887A1 (en) 2007-01-05 2007-01-05 Anticipatory presentation of travel information

Publications (2)

Publication Number Publication Date
WO2008086150A2 true WO2008086150A2 (fr) 2008-07-17
WO2008086150A3 WO2008086150A3 (fr) 2009-01-22

Family

ID=39609318

Family Applications (9)

Application Number Title Priority Date Filing Date
PCT/US2008/050199 WO2008086157A2 (fr) 2007-01-05 2008-01-04 Service de notification pour la présentation d'informations de voyage
PCT/US2008/050203 WO2008086159A2 (fr) 2007-01-05 2008-01-04 Présentation par anticipation d'informations de voyage
PCT/US2008/050184 WO2008086146A2 (fr) 2007-01-05 2008-01-04 Mise à jour d'une base de données contenant des informations de voyage
PCT/US2008/050186 WO2008086148A2 (fr) 2007-01-05 2008-01-04 Interrogateur de base de données cache pour la fourniture d'informations de planification de voyages
PCT/US2008/050190 WO2008086151A2 (fr) 2007-01-05 2008-01-04 Détection d'erreurs dans un système de planification de voyages
PCT/US2008/050191 WO2008086152A2 (fr) 2007-01-05 2008-01-04 Support pour planification de voyage souple
PCT/US2008/050188 WO2008086150A2 (fr) 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide d'une base de données cache à couches
PCT/US2008/050193 WO2008086154A2 (fr) 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide d'un service de notification
PCT/US2008/050196 WO2008086155A2 (fr) 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide de réponses issues d'un cache à des requêtes

Family Applications Before (6)

Application Number Title Priority Date Filing Date
PCT/US2008/050199 WO2008086157A2 (fr) 2007-01-05 2008-01-04 Service de notification pour la présentation d'informations de voyage
PCT/US2008/050203 WO2008086159A2 (fr) 2007-01-05 2008-01-04 Présentation par anticipation d'informations de voyage
PCT/US2008/050184 WO2008086146A2 (fr) 2007-01-05 2008-01-04 Mise à jour d'une base de données contenant des informations de voyage
PCT/US2008/050186 WO2008086148A2 (fr) 2007-01-05 2008-01-04 Interrogateur de base de données cache pour la fourniture d'informations de planification de voyages
PCT/US2008/050190 WO2008086151A2 (fr) 2007-01-05 2008-01-04 Détection d'erreurs dans un système de planification de voyages
PCT/US2008/050191 WO2008086152A2 (fr) 2007-01-05 2008-01-04 Support pour planification de voyage souple

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/US2008/050193 WO2008086154A2 (fr) 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide d'un service de notification
PCT/US2008/050196 WO2008086155A2 (fr) 2007-01-05 2008-01-04 Fourniture d'informations de voyage à l'aide de réponses issues d'un cache à des requêtes

Country Status (2)

Country Link
EP (2) EP2118842A2 (fr)
WO (9) WO2008086157A2 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2500848A1 (fr) 2011-03-15 2012-09-19 Amadeus S.A.S. Procédé et système pour la gestion centralisée de contexte de réservation dans un système de réservation de serveurs multiples
EP2500856A1 (fr) 2011-03-15 2012-09-19 Amadeus S.A.S. Procédé et système pour fournir une session impliquant une pluralité d'applications logicielles
EP2541473A1 (fr) 2011-06-27 2013-01-02 Amadeus S.A.S. Procédé et système pour système de réservation d'avant courses avec une efficacité de recherche améliorée
US9235620B2 (en) 2012-08-14 2016-01-12 Amadeus S.A.S. Updating cached database query results
CN104169950B (zh) 2012-04-26 2017-12-01 艾玛迪斯简易股份公司 利用面向批处理的计算的数据库系统
US9689227B2 (en) 2012-06-08 2017-06-27 Halliburton Energy Services, Inc. Methods of adjusting the rate of galvanic corrosion of a wellbore isolation device
US9689231B2 (en) 2012-06-08 2017-06-27 Halliburton Energy Services, Inc. Isolation devices having an anode matrix and a fiber cathode
US10977312B2 (en) 2012-09-21 2021-04-13 Google Llc Apparatus and method for inferring an origin
US9420056B2 (en) 2013-06-26 2016-08-16 International Business Machines Corporation Analytics caching based on users connected
EP3229193A1 (fr) * 2016-04-07 2017-10-11 The Boeing Company Procédé et système informatique permettant de partager des informations entre des passagers et des acteurs de la gestion de la circulation aérienne
US11455312B1 (en) 2019-11-20 2022-09-27 Sabre Glbl Inc. Data query system with improved response time

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065688A1 (en) * 2000-08-29 2002-05-30 David Charlton Electronic reservation system
US6609098B1 (en) * 1998-07-02 2003-08-19 Ita Software, Inc. Pricing graph representation for sets of pricing solutions for travel planning system
US20040220910A1 (en) * 2003-05-02 2004-11-04 Liang-Jie Zang System and method of dynamic service composition for business process outsourcing
US20050108069A1 (en) * 2003-11-18 2005-05-19 Tomer Shiran System and a method for prefetching travel information

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7050986B1 (en) * 1995-09-06 2006-05-23 The Sabre Group, Inc. System for corporate traveler planning and travel management
US20010051876A1 (en) * 2000-04-03 2001-12-13 Seigel Ronald E. System and method for personalizing, customizing and distributing geographically distinctive products and travel information over the internet
JP4403639B2 (ja) * 2000-06-29 2010-01-27 ソニー株式会社 販売方法、及び販売システム
US20020174205A1 (en) * 2001-05-18 2002-11-21 Susan Nakashima Method and apparatus to deliver personalized travel data
US20040153348A1 (en) * 2001-09-19 2004-08-05 Garback Brent J. Internet-based computer travel planning system
US20060059024A1 (en) * 2002-11-07 2006-03-16 Flytecomm, Inc. Advanced travel management system
US20040249799A1 (en) * 2003-06-06 2004-12-09 Demarcken Carl G. Query caching for travel planning systems
US20040249682A1 (en) * 2003-06-06 2004-12-09 Demarcken Carl G. Filling a query cache for travel planning
US20040249683A1 (en) * 2003-06-06 2004-12-09 Demarcken Carl G. Query widening for query caches for travel planning systems
US7840587B2 (en) * 2003-06-06 2010-11-23 Ita Software, Inc. Query caching for travel planning systems
US7363242B2 (en) * 2003-07-21 2008-04-22 Emirates Internet based airline ticket purchasing and vacation planning system and method
GB0322877D0 (en) * 2003-09-30 2003-10-29 British Telecomm Search system and method
US20050228702A1 (en) * 2004-03-30 2005-10-13 Travelocity.Com Lp Devices, systems, and methods for providing remaining seat availability information in a booking class
US20060277079A1 (en) * 2005-04-22 2006-12-07 Gilligan Geffrey D Groupware travel itinerary creation
US20060265361A1 (en) * 2005-05-23 2006-11-23 Chu William W Intelligent search agent

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6609098B1 (en) * 1998-07-02 2003-08-19 Ita Software, Inc. Pricing graph representation for sets of pricing solutions for travel planning system
US20020065688A1 (en) * 2000-08-29 2002-05-30 David Charlton Electronic reservation system
US20040220910A1 (en) * 2003-05-02 2004-11-04 Liang-Jie Zang System and method of dynamic service composition for business process outsourcing
US20050108069A1 (en) * 2003-11-18 2005-05-19 Tomer Shiran System and a method for prefetching travel information

Also Published As

Publication number Publication date
WO2008086152A2 (fr) 2008-07-17
WO2008086154A2 (fr) 2008-07-17
WO2008086152A3 (fr) 2009-01-15
WO2008086157A2 (fr) 2008-07-17
WO2008086155A2 (fr) 2008-07-17
WO2008086146A2 (fr) 2008-07-17
WO2008086151A2 (fr) 2008-07-17
WO2008086159A3 (fr) 2009-01-08
WO2008086159A2 (fr) 2008-07-17
WO2008086148A2 (fr) 2008-07-17
WO2008086151A3 (fr) 2009-12-30
WO2008086155A3 (fr) 2009-12-30
WO2008086148A3 (fr) 2009-12-30
EP2118843A4 (fr) 2013-01-23
WO2008086154A3 (fr) 2008-12-31
EP2118843A2 (fr) 2009-11-18
WO2008086146A3 (fr) 2008-12-24
WO2008086157A3 (fr) 2009-12-30
WO2008086150A3 (fr) 2009-01-22
EP2118842A2 (fr) 2009-11-18

Similar Documents

Publication Publication Date Title
US7711587B2 (en) Providing travel information using cached query answers
US20080167887A1 (en) Anticipatory presentation of travel information
US20080168093A1 (en) Providing travel information using a layered cache
US20090271226A1 (en) Cache poller for providing travel planning information
US20080167886A1 (en) Detecting errors in a travel planning system
US20080167909A1 (en) Updating a database of travel information
US20080167906A1 (en) Support for flexible travel planning
WO2008086150A2 (fr) Fourniture d'informations de voyage à l'aide d'une base de données cache à couches
US20080167908A1 (en) Notification service for presenting travel information
US8762184B2 (en) System and method for presenting pricing information for online travel products and services
US20140258045A1 (en) Collecting and displaying price information
TWI466057B (zh) Feed apparatus, information providing method, information providing program product, and recording medium
US20040249682A1 (en) Filling a query cache for travel planning
US20080262878A1 (en) Systems, methods, and computer program products for generating and updating a cache of price and availability information for travel packages and components
US20040249799A1 (en) Query caching for travel planning systems
US20040249683A1 (en) Query widening for query caches for travel planning systems
US20080120130A1 (en) Systems, methods, and computer program products for storing and retrieving product availability information from a storage cache
US20080167912A1 (en) Providing travel information using cached summaries of travel options
US11580584B2 (en) Managing item queries
US20080167910A1 (en) Providing travel information using a notification service
AU2009204911B2 (en) Online travel reservation system and method delivering restriction-aware travel opportunities
WO2008086153A2 (fr) Fourniture d'informations de voyage à l'aide de récapitulations d'options de voyage issues d'un cache

Legal Events

Date Code Title Description
NENP Non-entry into the national phase in:

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08713505

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 08713505

Country of ref document: EP

Kind code of ref document: A2