Patent Application
20080041945
Referring to
The travel planning system 10 can be used with various forms of travel such as airline, bus and railroad and is particularly adapted for air travel. The travel planning system 10 may exist separately as a standalone system or may be implemented as an extension of an existing travel planning system capable of searching fares for future airline travel. An example of such an existing system is the travel planning system described in U.S. Pat. No. 6,295,521 filed by Carl G. deMarken et al on Jul. 2, 1998 and incorporated herein by reference, although other travel planning systems may be used in conjunction with the refund/reissue logic 19.
Details of refund/reissue logic 19 will now be described. A user (e.g., an individual consumer or a travel agent) at client 14 specifies one or more existing tickets to consider for reuse and parameters of a new trip in a query. The client 14 sends the query to the server 12 over network 22, which can be any local or wide area network or an arrangement such as the Internet. At the server 12, the search engine 18 and the refund/reissue logic 19 process the user's query to produce a complete set of pricing solutions for the new travel using aspects of the already issued ticket. In determining the pricing solutions, the refund/reissue logic 19 considers any rules associated with the existing ticket that specify conditions under which the existing ticket may be changed or exchanged. The rules are stored in the historical database 20. The historical database 20 is stored in the memory 42 of server 12. The historical database 20 may be built elsewhere from raw data files and distributed to the server 12 over the network 22. The client 14 receives the pricing solutions from the server 12 over the network 22 and presents the results to the user 16. The user 16 may sort the results by various criteria or extract a subset of results that fit the user's criteria. For example, the user may wish to view only the cheapest options, and of these, the user may wish to sort the results based on a time of day, carrier, length of travel, or other criteria. After the user selects one of the options presented by the client 14, the system books the new itinerary directly in a carrier's inventory system or in a computer reservation system (CRS) and reissues a ticket for the new travel.
The travel planning system 10 includes an historical database 20 that stores industry-standard information pertaining to travel (e.g., airline, bus, railroad, etc.). For example, the inventory database 20 can store the Airline Tariff Publishing Company database of published airline fares and their associated rules, routings and other provisions, the so-called ATPCO database. The system also includes an inventory database 26, which holds an inventory of current seat availability information for a particular carrier and so forth. The inventory and historical databases 26 and 20 may each actually be composed of several databases and may be stored locally within the server 12 or remotely on external servers connected to the network 22. In addition, the inventory database 26 and the historical database 20 may be managed together. The inventory database 26 includes inventory (i.e., seat availability) and uses a combination of live polling, caching, and availability prediction/computation.
Structure of an Airline Ticket
The system shown in
A PNR is an entry in one or more airlines' reservation databases that holds information such as the passengers' names, the flight segments of a trip, and which inventory (“booking code”) has been reserved on each segment of the trip. A PNR may also include information, such as ticket numbers, frequent flyer numbers, etc. and be assigned a unique identification number or alphanumeric string called a “record locator.”
A ticket document on the other hand, is a contractual document that entitles the holder to travel according to the PNR associated with the ticket. For example, a ticket document may show proof of a promise by the issuing agency to pay for the travel, or that the travel has already been paid for by the holder. A ticket document often contains a series of “coupons,” each of which is good for travel on a single flight segment and information pertaining to how the travel was priced. After purchase, a ticket document may have an entry in the airline's electronic ticket database that contains a pointer to an active PNR in the reservation database, via the PNR's record locator. Typically, a PNR contains little or no information about the price of the travel or the method of payment. Although a ticket document and a reservation are often linked together, it is possible to have a reservation without a ticket document. For example, the ticketing process that issues the ticketing document can happen almost simultaneously with booking the reservation, or it may happen after a period of time (e.g., a week) has passed. It is also possible to have a ticket without a reservation. For example, if a ticketed passenger decides not to travel on a ticket that he has purchased, he will typically cancel the reservation but retain the ticket.
Both the reservation and the ticket may have useful value. A ticket generally has direct, e.g., monetary value, since it may be converted into cash or exchanged for another ticket. A reservation's value however is less direct. A reservation's value is related to the inventory that the reservation controls, e.g., in a booking code that is no longer available. The airline industry typically operates in a manner that canceling inventory does not imply that the canceled inventory may be re-booked immediately or at all, either by the current holder or another traveler. A reservation may also have value purely by virtue of the time it was produced, since many of the cheapest fares have requirements that the flights be reserved a certain period of time in advance of departure.
Server
Referring to
Using the information associated with the original ticket supplied in the query, the reconstruction logic 52 performs a historical pricing query, or other similar processing, using the historical database 20 to reconstruct the pricing solution that was used to issue the original ticket. The pricing solution, as reconstructed, includes fare rules associated with fares used in the original pricing solution. The fare rules determine the conditions under which the fares were applied to the original ticket and are used to determine whether those fare rules and fares can be used to provide a reissued ticket, and if so, under what conditions.
The scheduler logic 54 retrieves sets of flights that satisfy the request for new travel specified by the user's query. The flights may be retrieved from the database 26 of published flights or from other sources. The reissue method logic 56 determines whether the flights returned by the scheduler process may also satisfy the fare rules specified by the reconstructed pricing solutions. The availability logic 59 analyzes the flights returned from the scheduler logic 54 to determine whether there are seats available on the flights for the chosen fares (in the context of the existing reservation) and discards those combinations for which no seats are determined to be available. The faring logic 58 determines a set of valid fares, taxes, and surcharges for the remaining flights, following industry standard rules regarding currency conversions. In addition to pricing solutions for reissued tickets, the server 12 can be configured to produce other travel-related information as a result of a user query. For example, the server 12 can produce routes or airline suggestions, optimal travel times and suggestions for alternative requests.
Client
Referring to
In some examples, the client computer 14 may be any type of web-enabled apparatus or system including but are not limited to a desktop computer, a laptop computer, a mainframe computer, a cellular telephone, a personal digital assistant (“PDA”), and a controller embedded in an otherwise non-computing device. The client computer 14 contains one or more processor(s) 40 (referred to simply as “processor 40”) and memory 42 for storing software 44. The processor 40 executes software 44, which includes a Web client application 47 and operating software 48. The Web client application 47 includes one or more routines used in implementing the TCP/IP protocol, which allows the client computer 14 to communicate over the network 22. The operating software 48 includes an operating system 50, such as Windows XP®, and a web browser 52, such as Internet Explorer®. The web browser 52 enables the user 16 to interact with a web page (i.e., an electronic document) that serves as an interface between the user and the search engine 18. The web page provides the user 16 with an interface to enter queries for ticket changes and displays pricing solutions returned by search engine 18 in response to the user's queries. The web page may also provide the user 16 with tools for customizing the display of the returned results (e.g., sorting the results, extracting results of interest, and eliminating results that are not of interest).
Although loosely described as a client-server model the system 10 can be implemented in other configurations/architectures.
Historical Database
Referring to
Fare records generally specify a fare for a given flight along with an effective date (i.e., the date on which the fare is in effect). Fare records may also specify changes or cancellations of a fare. When fare data changes, ATPCO sends either a fare record having a change tag that indicates that a new effective date of a particular fare or a fare record (referred to as a “cancel record”) that cancels the fare. For each fare record that is received from ATPCO (or from another source), the historical database 20 stores the fare record in the fare data file 54 along with the date on which the fare record was transmitted. Rather than applying changes or canceling fares, as directed by ATPCO, the historical database 20 stores all of the received fare records and transmission times as the fare records arrive at the historical database 20.
At the time of query of the database 20 for historical records, a fare record reconstruction process 60 retrieves relevant fare records that existed before and during the time the original ticket was issued and stores those retrieved fare records in a temporary database 59. The historical database 20 merges the retrieved fare records stored in the temporary database 59 to provide the fare record that was valid when the original ticket was issued.
Rule records include an effective date on which a rule for a given fare is in effect. Rule records also include a discontinue date on which the rule is no longer valid. The discontinue date of some rule records may not be specified, indicating, in effect, that the rule record is valid indefinitely. When rule data changes, ATPCO sends a cancel record to cancel a rule or an update record to change the rule. In some embodiments, ATPCO sends update records having the discontinue date set before the effective date (i.e., effective tomorrow, discontinue tomorrow). In other embodiments, when ATPCO sends a change, they send a new rule record with an effective date that is the same as the transmission date. When the historical database 20 receives a new rule record, a rule record reconstruction process 74 changes the discontinue date on the previous record to the day before the effective date of the new record. For each rule record that is received from ATPCO or from another source, the historical database 20 stores the rule record in the rule data file 57 along with the date on which the rule record was transmitted.
At the time of query, the database 20 retrieves the rule records that existed during the time the original ticket was issued. The historical database 20 restores the rule record to its original form so that it appears the way it had looked when the original ticket was issued. For example, if the rule record had an indefinite discontinue date at the time the original ticket was issued, the historical database 20 restores the discontinue date of the rule record to be infinity, even though it may have a finite discontinue date specified at the time of query.
Referring now to
Referring now to
Some data sources provide data to the historical database 20 that does not include explicit update or cancel records for canceling or changing previous data records. To handle data received from these types of sources, the historical database 20 or server 12 includes a program that looks at changes and computes incremental changes between records and stores these incremental changes. The program looks for any index that changed at all, determines the changes that were made, and stores the changes as additional records. For example, the program may insert a cancel record between two records where one would ordinarily be.
Under some frequently occurring circumstances, the exact time and date of ticket issuance and/or pricing is not known. To deal with such circumstances, the above algorithm is modified to take a time range instead of a single point in time. The result of the fare and rule retrieval processes are then sets of records, each labeled with a beginning and ending timestamp identifying the time period during which the record was valid.
Typically, tickets are only valid for one year from commencement of travel (which itself may be up to a year from the date of purchase) and this places a limit on how much historical data that needs to be maintained in the historical database 20. Even seemingly static databases, such as databases of city and airport codes, need to have historical versions to deal with the small number of changes that occur to them over the course of a year. Data is stored in the historical database 20 for a limited period of time (e.g., 25 months), after which it is purged to make room for new data.
To improve speed of data retrieval, the historical database 20 is implemented as a memory mapped file system that can be directly accessed from memory 42 by the processor 40. Although the historical database 20 could also be implemented as a relational database, in some implementations a memory mapped implementation is preferred. In some embodiments, the historical database 20 includes two separate indexes to the same fare and rule data: a first index referencing only to current data and a second index referencing both current and historical data. Having two such indexes can be used to speed up access to current data. The historical database 20 may also store information in a data file as the information arrives from ATPCO or other data sources and use the information to reconstruct the original ticket at the time of query.
Server Process
Referring now to
The query may specify other information related to the original ticket, for example, flight segments that have already been flown, information about taxes paid, etc. The refund/reissue logic 19 reconstructs (64) the ticket based on the received query in reconstruction logic 52 (
The refund/reissue logic 19 determines (66) possible itineraries, that is, sequences of flight segments, between the origin and destination for each portion of a new trip, which can satisfy the new travel requirements specified in the query. The scheduling uses the scheduler logic 54 (
The reissue method logic 56 (
The reissue method logic 56 provides reissue methods and sets of candidate reconstructed tickets and reissue itineraries that are applicable to each of the reissue methods to the faring logic 58. The faring logic 58 determines (70) valid fares corresponding to the replacement itineraries produced by the itinerary determination process 66 (also referred to as scheduler process 66) according to the reissue methods that are valid for the replacement itineraries. In determining (70) valid fares, the faring logic 58 calculates the final prices of the reissue solutions that may include taking deductions based on the existing ticket (fare or tax amounts paid) and adding penalty amounts specified by the reissue methods. The refund/reissue logic 19 on the server 12 sends the reissue pricing solutions to the client 14. After receiving a user's selection of one of the pricing solutions from the client 14, the server 12 initiates (72) a booking process to provide a booking and reservation for the user 16 based on the selected pricing solution. The booking process (72) is optional and may be performed by an external booking system.
Ticket Reconstruction Process
Referring to
The historical database 20 returns the fare records having information that matches the information supplied in the query. In some embodiments, the fare records in the historical 20 database contain information fields including: a carrier, a city pair, a fare basis code (an alphanumeric identifier), a tariff number, a rule number, a fare tag (one-way, round-trip, or one-way-only), the price for the particular fare record, and dates, such as the transmission date of the record and validity date or dates of the record. Typically, the user's ticket includes only a subset of the fields for each of the fares that it covers. For example, the fare information contained on the ticket may be limited to the following fields: the carrier, cities, fare basis code, price, and issue date. Because fare records may differ by any of the database information fields, there may be multiple entries in the database that match fields listed on the ticket; each is a potential match for the fare listed on the ticket.
In some instances, the data in the fields listed on the ticket may be incorrect or unreliable. Examples of such instances include the following: the fare rules may specify modifications to how the fare basis code is printed on the ticket; the price listed on the ticket is not the price in the fare record, but rather it is the sum of the fare record price with some applicable surcharges for the fare; the issue date of the ticket may not be the date when the ticket was priced; and the fares used on the ticket may originate from an unknown date if the ticket has been reissued previously.
The historical database 20 also includes fares that are constructed through various processes, including: processes that produce constructed fares (e.g., international fares which are pieced together from a “published base fare” and one or two “arbitraries or add-ons.”), and processes that produce a “fare by rule fares” (e.g., fares that are produced from other fares or for all markets in a geographic area). Thus, it is important that the correct fare records are retrieved from the historical database 20, since the methods available for changing a ticket depend on the rules attached to the fares on the ticket.
After a set of candidate fare records are returned by the historical database 20 in response to querying the historical database (82), the reconstruction logic 52 optionally evaluates (84) the rules of the candidate fare records in the context of information in the original ticket. In one implementation of the reconstruction logic 52, it is assumed that the system that priced the original ticket evaluated fare rules associated with the fare used to price the original ticket. The reconstruction logic 52 can dismiss, as candidate matches, any fare whose rules “FAIL” when the rules are applied to the flights of the original ticket, because the original pricing system would not have used those fares whose rules had failed. For example, the reconstruction logic 52 checks whether any special conditions specified in the candidate fare records such as day of week, seasonality, Saturday night stay, advance purchase, etc. are satisfied by the original ticket. Upon determining that one or more rules of a candidate fare record are violated, the reconstruction logic 52 eliminates the candidate fare record from consideration. In addition to rules which apply to the flights on the tickets, fares may also fail combinability constraints with each other.
The ticket reconstruction process 64 (
Alternatively, all combinations of fares and flights can be simultaneously considered, and a configurable penalty assessed for each rule violation; the pricing solution with the lowest penalty can then be chosen.
In some embodiments, the reconstruction logic 52 (
If at least one candidate solution exists, the process (64 of
If only one candidate solution exists, the reconstruction logic 52 returns (94) that solution to the scheduler process 66 (
Scheduler Process
Referring to
Availability Process
Referring to
Contained within some PNRs are a set of “married segment indicators.” Married segment indicators used by the airline industry are integers associated with flight segments that indicate which flight segments of the inventory held in the PNR are to be considered together as distinct units. If one segment with a particular married segment indicator is canceled, then all segments with that indicator must be canceled. This prevents changes to the PNR that allow the passenger to retain some of the married segments while canceling others. Generally, segments are married within a PNR to indicate that the inventory was granted to a passenger on the assumption that they would travel on (and pay for) all of the segments. For example, a passenger may have bought a ticket from Boston to LA connecting in Dallas. If the two segments are married, the passenger cannot keep the Boston to Dallas segment and cancel the Dallas to LA segment.
In determining availability of flights on the replacement tickets returned from the scheduler logic 54, the availability logic 59 marks (93) the replacement itineraries with potential marriage indicators (discussed below). For sequences of flights that overlap partially with the inventory currently held in a PNR, the availability logic 59 merges (95) availability counts from these sequences of flights with the inventory from the PNR, in accordance with the marriage indicators. For each response to an availability query for an overlapping sequence of flights, if the response contains a marriage indicator for the same subsequence as a married subsequence currently held in the PNR, the availability logic 59 produces (97) a record associated with the response that includes the counts for the subsequence of flights replaced with a placeholder record representing that married sequence from the PNR, with only currently held inventory available. The counts used in these placeholder records are given by the number of passengers in the existing PNR. The PNR holds inventory for the passenger; the reissue is accomplished by editing the PNR. The passenger is allowed to keep inventory they have from the original booking, or use new inventory available now. Pseudo code for the availability determination process 67 is:
Although the availability determination process 67 is shown after the scheduling process 66 in
Reissue Method Process
Referring to
A reissue method includes one or more of the following components:
(1) conditions on the original ticket (e.g., partially flown vs. completely unflown, ticket still valid for travel or not, exchange before or after departure, current time within the original “ticketing time limit”, passenger type at time of original ticket purchase, whether the ticket has previously been reissued or not, etc.);
(2) a source for fares used for re-pricing (e.g., keep all fares on original ticket, keep fares for unchanged flights, current fares for changed flights, historical fares from the time of ticket issue for all flights, and many other combinations);
(3) rule waivers for re-application of ticketed fares to new flights;
(4) mechanisms for validating advance purchase restrictions;
(5) conditions on the new ticket (e.g., must not change the first fare component, must not change fare breakpoints, specific restrictions on what fares may be used, the ticket must cost more than the previous ticket);
(6) change penalty amounts;
(7) changes in a form of payment or refund to be applied to the reissued ticket (e.g., cash refund, a refund in the form of credits that can be applied toward the purchase of a future ticket).
Given a reconstructed ticket, the reissue method logic 56 determines (100 of
Since the number of reissue methods may be large (e.g., for ATPCO category 31 (voluntary changes) and ATPCO category 33 (voluntary refunds) processing, the number of possible combinations can be exponential in the number of fares on the original ticket), it is desirable to eliminate non-applicable reissue methods as early as possible to avoid unnecessary computation. Reissue methods are often generalized such that they apply to large sets of possible tickets. At an early stage of the reissue method determination process 68, the reissue method logic 56 filters (102) the reissue methods down to only the set of reissue methods that applies to the actual reconstructed ticket or tickets being considered. The properties of a reconstructed ticket, such as whether it has been partially flown and whether the new transaction is within the “ticketing time limit” of the original ticket, and information present on the ticket are compared to the each of the reissue methods. The reissue method logic 56 eliminates any reissue methods whose requirements are violated by all of the candidate reconstructed tickets.
By filtering (104) the remaining reissue methods with respect to the constraints of the query for new travel, the reissue method logic 56 attempts to eliminate more of the reissue methods from consideration. For example, if the new travel specified in the query does not include any travel on the outbound travel date of the original ticket, any reissue method that requires keeping the flights of the first fare component can be discarded. In some embodiments, the reissue method logic 56 performs more aggressive filtering including pre-evaluating advance purchase restrictions using the advance purchase processing mechanism from the reissue method based on the query-specified desired departure time range. Performing more aggressive filtering may also include determining whether a reissue method enables the fare breakpoints of the original trip to remain unchanged given the requested new trip.
The reissue method logic 56 considers reissue methods for possible pricings of possible replacement itineraries by maintaining a status vector over the possible reissue methods in data structures representing partial pricing solutions of the replacement itineraries. A partial pricing solution includes a fare and itinerary that partially satisfy the new travel request. For example, a replacement ticket may be composed of multiple partial solutions each including a flight segment of the replacement itinerary and a fare associated with the flight segment. One technique to track applicable reissue methods is to use a status vector. A status vector of a partial pricing solution indicates the types of reissue methods that apply to the partial solution. In some embodiments, the position of a bit represents a reissue method and a “1” in the status vector at the position represents that at a particular stage of processing, the corresponding reissue method might still be possible for this partial pricing solution (in other words, the reissue method is not known to be inapplicable on all possible reissue pricing solutions which can be built from this partial pricing solution). Other approaches could be used.
In some embodiments, two “special” reissue methods are allocated and assigned to the first two bits in a status vector. These bits represent two possibilities. The first bit represents a reissue method that involves pricing a completely new ticket. Partial pricing solutions for flights in the future, using fares that are currently available, and which do not require waiving any fare rules may qualify for this special method. The second bit represents a reissue method that enables total reuse of the original ticket. This type of reissue method applies to the ticketed flights using the ticketed fares, regardless of whether rules fail or not. Under this reissue method, the passenger should be able to keep their ticket and inventory without change penalty regardless of any other constraints.
The reissue method logic 56 determines (106 of
The fare rules associated with the partial solutions determine the pricing of a replacement ticket composed of the partial solutions. When applying fare rules in a fare-component context (i.e., when the flights to paid for by the fare have been chosen, but the other flights in the new trip are not yet known), the system evaluates whether the flights being considered are all present, in sequence, and on the original ticket. If the flights being considered are all present in sequence on the original ticket and booked in the same inventory, the flights are considered unchanged flights; otherwise the flights are changed flights. Similarly, the fare itself can be checked to see if the fare occurs on the ticket, and whether it is a historical fare or a current fare.
The reissue method logic 56 evaluates (110 of
A determination is made (112) as to whether the rule check of step 110 returns a FAIL at each level of processing, as larger partial solutions are built up from smaller pieces. If a FAIL result is not returned, the partial solutions are passed through to the next higher level. At the highest level, if the rule still does not fail, the result is passed on to the next stage of processing.
When a normal rule check would return FAIL, the reissue method logic 56 determines (114) if any reissue method would allow the rule to be evaluated differently, and if so, what the result would be under the less restrictive evaluation. Some reissue methods allow the waiving of certain fare rules or modify the behavior of the rule evaluation process 110. For example, one or more reissue methods may enable rules that impose advance purchase requirements to be modified to allow partially flown trips to be re-priced. As long as the reissue methods change the rule evaluation behavior such that the new behavior is less restrictive than the normal behavior, a simple modification to the rule evaluation process is sufficient. Because rule applications only become less restrictive under the reissue methods, a PASS or DEFER result would also apply under the less restrictive rule as directed by the reissue method. This mechanism can be modified to handle the case where the rule evaluation becomes more restrictive under a particular reissue method, or where there are multiple levels of progressively loosened restrictions. All that is required is that the application of the rule evaluation proceeds from most restrictive to least restrictive.
If the reissue method logic 56 determines, for a given partial solution, that there are no re-issue methods that could modify the violated rule so that it does not still fail, the reissue method logic 56 eliminates (116) the partial solution from consideration. If however a reissue method that enables modification of a violated rule is determined (114), the status vector of the partial solution is updated (118) to include the reissue methods that would allow the modified rule check. This updated status vector is combined with the existing status vector of the partial solution (e.g., using a logical AND operation) to produce a final status vector indicative of all reissue methods that are valid for the partial solution. The process 68 checks (120) whether an entire ticket has been constructed and keeps looping over larger and larger partial solutions until the entire ticket is constructed. Once the entire ticket is constructed, the process 68 outputs (122) the constructed ticket to a subsequent process (e.g., faring process 70).
Referring to
The faring logic 58 examines (132 in
For each group of pricing solutions, the faring logic 58 determines (144) if the corresponding reissue methods allow the price of the previous ticket (i.e. previously paid fare or tax amounts) to be applied toward the value of the new ticket. Reissue methods that specify an “all-new-ticket” method will generally prohibit such discounts. The faring logic 58 also computes (146) any change penalty amount for each reissue method. The sum of the original ticket discount and the change penalty is referred to as the “total adjustment amount.”
The faring logic 58 produces complete pricing solutions from priceable units through a process 148 called “linking.” During the linking process 148, the faring logic 58 combines the priceable units within each group to form a set of pricing solutions for replacement tickets that satisfy the user's query. To account (150) for any adjustment amounts, the faring logic 58 subtracts out the value, if any, of the original ticket (fare or tax amounts) from the price of the replacement ticket and adds to the price of the replacement ticket any penalty amounts that have been calculated.
In some embodiments, such as when using the refund/reissue logic 19 in conjunction with a travel planning system, as described in U.S. Pat. No. 6,275,808, the pricing solutions are represented using a compact structure called a “pricing graph.” The pricing graph is divided into groups of pricing solutions based on the sets of reissue methods that are valid for generating the groups of pricing solutions. The faring logic 58 loops over all possible reissue methods for each group of complete pricing solutions (represented by the reissue-method status vector on the link-fringe) and tags the group of complete pricing solutions corresponding to a reissue method with the resulting adjustments so that the groups of solutions as represented in the graph have the correct total cost.
The pricing solutions are presented (152) to the user 16 at the client 14. In some embodiments, only the group of complete pricing solutions corresponding to the reissue method which results in the lowest total adjustment amount is presented to the user 16. After the server 12 receives a ticket selection from the user 16, the booking process 72 (
User Interface
Referring to
The user interfaces 164, 166, and 168 may also include controls that enable the user 16 sort the possible replacement ticket options displayed. In addition to enabling the user 16 to sort replacement ticket options by price, departure time, carrier, duration, class of service, warnings, and other standard travel parameters, the controls also enable the user 16 to sort replacement ticket options according to the number of differences between the replacement itineraries and the itinerary of the existing ticket. For example, the user 16 may prefer those replacement options for which the number of differences is the smallest.
The user interfaces 160, 162, 164, 166, and 168 may include controls that enable the user 16 to select and highlight various types of differences between the existing ticket and the replacement ticket options. For example, if the user 16 decides to take an earlier flight, the user 16 may want to highlight only those differences that correspond to originating flights. Similarly, the user 16 may want to un-highlight differences that are of no interest.
When specifying a search for options to replace an existing ticket, a user may specify their search differently from the initial search they performed when they bought their existing ticket. Depending on what information is stored and captured about the user's intent (i.e., the characteristic(s) of the existing ticket that the user 16 is explicitly attempting to change), the user interfaces 160, 162, 164, 166, and 168 can discriminate between explicitly requested differences between the existing ticket and candidate replacement options and consequential differences that were not explicitly requested.
For example, when highlighting differences between the original ticket and the possible replacement options, the user interfaces 160, 162, 164, 166, and 168 may highlight explicit differences and consequential difference in different colors or formats. In some embodiments, the user interfaces 160, 162, 164, 166, and 168 highlight differences between the travel options that were available when the search for the original ticket was performed and the travel options that are available at the time of the user's query for replacement ticket options. In some embodiments, the user interfaces 160, 162, 164, 166, and 168 include a separate “details page” for displaying the differences between the original ticket and a possible replacement options in an inline arrangement.
QPX Implementation
The travel planning system 10 and its operations may be implemented using the QPX travel planning system, as described in U.S. Pat. No. 6,275,808 and briefly discussed above. One technique to use the refund/reissue logic 19 with the travel planning system, as described in U.S. Pat. No. 6,275,808 involves certain modifications to the low fare search (LFS) algorithm described in that patent.
As described above, the reissue method can use a status vector to track applicable reissue methods. To adopt the LFS technique for use with the refund/reissue logic 19, the LFS technique is modified to track potential reissue methods using the status vector.
Thus, when a fare is first considered at the faring-market level rule evaluation, the reissue-method status vector is initialized, e.g., to all ones because the reissue methods are initially assumed to pass until they fail. The rule checkers (used at all levels of rule checks) are modified to relax rules, and when the rule checks relax the rules the rule checks return a marker status vector indicating the subset of reissue methods which allow the particular relaxation that was performed. For fare-components, priceable unit-labels, link-label-sets, and link-fringes, each data structure is provided with an additional field, “REISSUE-STATUS,” which is a status vector over the reissue methods, indicating the state (e.g. known to fail, unsatisfied constraint, etc.) for the set of partial pricing solutions, at that particular solution stage, which the fare-component, priceable unit-label, link-label-set, and link-fringe data structures represent.
When considering fares after the faring-market level rule checks, logic is added to evaluate each reissue method along with the set of marker status vectors returned by the rule checker to produce a reissue status vector. The resulting reissue status vector is passed directly along to the fare-component level rule check. When considering combinations of fares with flights, after the fare-component level rule checks, logic is added to evaluate each reissue method in the context of the fare component, in addition to the set of markers returned by the rule checker. The resulting reissue status vector is stored on the fare-component. When considering flights in the context of a priceable-unit, after priceable-unit level rule checks, logic is added to evaluate each reissue method in the context of the full set of flights of the priceable unit in addition to the set of markers returned by the faring market set level and priceable-unit level rule checkers.
The priceable unit level rule checker logic considers each reissue method that is listed as a possibility in all fare-components of the potential new priceable-unit, as well as being a possibility in any markers returned by rule checks. The resulting reissue status vector is stored on the priceable unit-label. When considering sets of priceable-unit-labels to combine into a link-label-set, logic is added to evaluate the reissue methods that are compatible with every priceable-unit-label. Cross-slice data structures are set up so that they keep track of the range of flights from the original ticket that are reused, and also the range of fare breakpoints from the original ticket that are reused, and different link-label-sets are produced for different values of these ranges. The resulting reissue status vector is stored on the link-label-set.
When performing final linking, the cross-slice summary information includes the first flight from the original ticket that was not reused, and the first faring-market of the solution that was not on the original ticket. Different link-fringes are produced for each different value of these fields. The final evaluation of many reissue-method conditions, such as “must reuse first coupon,” and “must keep same fare breakpoints” occurs at this stage using the cross-slice summary information. The final reissue status vector for the complete set of solutions represented by a link-fringe is stored in the link-fringe data structure.
Many aspects of QPX functionality described, for example, in U.S. Pat. No. 6,275,808 can be extended to applications that search for ticket changes. Examples of these include “sell-up” functionality in which a diverse set of possible pricing solutions are shown for the same ticket change, including refundable versus nonrefundable options, different cabin classes, and different fare restrictions. Other QPX functionality includes offering split-ticket and multiple point-of-sale options, the use of calendar queries for allowing comparison shopping over a large number of dates, the use of “anywhere” queries for allowing comparison shopping over a large number of possible new destinations, and changing frequent-flyer tickets.
The reissue method process 68 described above (see
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
Under 35 U.S.C. 119(e)(1), this application claims the benefit of provisional application serial number, 60/806,665, filed Jul. 6, 2006, entitled, “LOW FARE SEARCH FOR TICKET CHANGES.”
| Number | Date | Country | |
|---|---|---|---|
| 60806665 | Jul 2006 | US |
