WO2008070768A2 - Système de planification de voyages qui partage le travail à travers les itinéraires et produit des réponses comportant de multiples canaux de vente/pnrs/billets par réponse - Google Patents

Système de planification de voyages qui partage le travail à travers les itinéraires et produit des réponses comportant de multiples canaux de vente/pnrs/billets par réponse Download PDF

Info

Publication number
WO2008070768A2
WO2008070768A2 PCT/US2007/086625 US2007086625W WO2008070768A2 WO 2008070768 A2 WO2008070768 A2 WO 2008070768A2 US 2007086625 W US2007086625 W US 2007086625W WO 2008070768 A2 WO2008070768 A2 WO 2008070768A2
Authority
WO
WIPO (PCT)
Prior art keywords
units
representation
priceable
split
pricing
Prior art date
Application number
PCT/US2007/086625
Other languages
English (en)
Other versions
WO2008070768A3 (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/635,400 external-priority patent/US20080140464A1/en
Priority claimed from US11/635,399 external-priority patent/US20080140463A1/en
Priority claimed from US11/635,805 external-priority patent/US20080140466A1/en
Priority claimed from US11/635,395 external-priority patent/US20080140462A1/en
Priority claimed from US11/635,401 external-priority patent/US20080140465A1/en
Application filed by Ita Software, Inc. filed Critical Ita Software, Inc.
Publication of WO2008070768A2 publication Critical patent/WO2008070768A2/fr
Publication of WO2008070768A3 publication Critical patent/WO2008070768A3/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
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem

Definitions

  • This invention relates to travel pricing, and more particularly, to pricing for air travel.
  • Travelers and travel agents pose air travel planning queries to computer travel planning systems (travel planning system), such as travel web sites, airline-specific web sites, or interfaces supplied by global distribution systems (GDSs) as used by travel agents.
  • travel planning system computer travel planning systems
  • GDSs global distribution systems
  • One type of query typically supported by travel planning systems is the so- called low-fare-search (LFS) query.
  • LFS low-fare-search
  • travel planning systems return a list of possible answers including flight and price information. The answers may also take other forms such as a pricing graph.
  • a traveler or travel agent selects for purchase one of the answers returned by the travel planning system.
  • the travel agent or a computer booking system, electronically interacts with a global distribution system (GDS) or an airline reservation system (ARS) to reserve seats on the appropriate flights and provide payment.
  • GDS global distribution system
  • ARS airline reservation system
  • PNR passenger name record
  • tickets Another unit of representation in the airline industry is a ticket. Typically, each passenger has a separate ticket, whereas multiple tickets may be referenced by one PNR. Tickets typically receive their own industry-wide identifier, called a ticket number.
  • the ticket and the PNR are fundamental units of representations of interaction in the airline industry. Generally, airlines, governmental authorities, GDS 's and travel agents use these units as the basis for accounting, billing, regulatory or contractual requirements, and electronic data interchange protocols. This imposes limitations on the forms that valid tickets and PNRs can have.
  • a method for producing a travel solution comprised of multiple travel units includes receiving a set of itineraries, determining plural split possibilities for pricing of the itineraries, producing fare components as combinations of individual units of representation and fares, according to whether a fare's rules pass a preliminary check on individual units of representation and determining plural individual units of representation, for each split possibilities.
  • Determining plural individual units includes computing plural individual units of representation multiple times using different journey split assumptions and storing the journey split assumptions required for the individual units of representation to be valid with the corresponding individual units of representation.
  • the individual units of representation are at least one from faring atoms, fare components and priceable units.
  • the method includes constructing priceable units from the fare components.
  • the method includes linking the priceable units into complete sets of pricing solutions by linking itineraries to corresponding pricing units from different slices to provide the pricing solution. Linking enforces consistency of journey split assumptions required for the individual units of representation to be valid.
  • Linking includes constructing a unique data structure for each slice of a journey, for every set of multi-slice priceable- unit-labels, constructing a second set of data structures, the second set comprising a set of "open” multi-slice priceable-unit-labels and a set of backward-links that correspond to a pair of a "first set” and a "second set.”
  • Linking includes assigning to each first set and each second set a set of labels so as to enforce split consistency, determining an intersection of the second set of data structures for the priceable unit labels, and determining if the intersection is non-empty; if non-empty and producing a first set labeled with labels based on the intersection, determining if the first set already exists, and if not, adding back the pointer and union L into second set.
  • the method produces a pricing-graph that enforces multiple-ticket consistency and represents multiple PNR' s.
  • the method produces a pricing-graph that enforces multiple-ticket consistency and represents multiple PNR' s and a single PNR.
  • Producing fare components includes decomposing the itineraries into individual units of representation of units of travel and testing retrieved fares by applying corresponding fare rules for the fare to the individual units of representation.
  • the method includes splitting the journey according to the lowest-priced solution. Splitting includes splitting by placing passengers on different passenger name records, or dividing the journey by slice, or dividing the journey by priceable unit.
  • a computer program product residing on a computer readable medium for producing a travel solution comprised of multiple travel units includes instructions to receive a set of itineraries, determine plural split possibilities for pricing of the itineraries, produce fare components as combinations of individual units of representation and fares, according to whether a fare's rules pass a preliminary check on individual units of representation and determine plural individual units of representation, for each split possibilities.
  • aspects of the invention provide a travel planning system that processes travel queries more efficiently by sharing computational efforts in pricing per-slice and whole journey pricings and that does not need to restrict answers (travel options) to those that can be sold as a single ticket or passenger name record (PNR), or through a single sales channel. Removal of such a restriction may return better answers for a passenger or passengers willing to travel on multiple tickets or PNRs. This can result in price savings. For instance, different fare codes can be used for different parts of a journey which can result in substantial savings on fares, e.g., as Y fares are typically much more expensive than Q fares. As a second example, dividing flights across tickets may enable a convenient or inexpensive airline combination that would otherwise be unavailable.
  • These techniques include various approaches for enhancing travel planning systems and itinerary pricing systems that share work across itineraries and whole trip journeys, to include in the search the possibility of booking a trip using more than one PNR or ticket or sales channel.
  • aspects of the invention permit multiple PNRs to cover an entire solution, either because different passengers are placed in different PNRs or different flights are placed in different PNRs, or both and/or techniques where multiple tickets are used to cover a single PNR (e.g., where a passenger's payment for multiple flights in a single PNR are recorded in multiple tickets rather than a single ticket.
  • FIG. 1 is a block diagram including a travel planning system.
  • FIG. 2 is a flow chart of a multiple ticket search in a travel planning system using sequential pricing of itineraries.
  • FIG. 3 is a flow chart that shows a process to artificially inflate availability information.
  • FIG. 4 A is a flow chart of a technique for using a sequential pricing travel planning system that re-prices a subset of solutions.
  • FIG. 4B is a flow chart depicting a technique for checking constraints.
  • FIGS. 5A-5B are flow charts of a technique for pricing by relaxing constraints, rules, or regulations on solutions.
  • FIGS. 6A-6B are flow charts of a technique for pricing by allowing multiple passengers to be booked using different booking codes.
  • FIGS. 7A-7D are flow charts of a faring process that shares computational efforts across per slice and whole journey pricings.
  • FIGS. 8 and 9 are flow charts of a technique to process a set of possible points of sale and to provide a choice of which points of sale to select.
  • an arrangement 10 includes one or more server type computer systems 12 that implements a travel planning system (travel planning system) 11 that searches for airline tickets in response to queries 13 using so-called large scale or low- fare-search algorithms.
  • the travel planning system 12 is typically a server type of computer system, or a cluster or farm of such server types of computers.
  • the computer includes memory, a processor, interfaces, networking support and storage, e.g., computer readable media storing various computer programs, data structures and so forth to implement features of the travel planning system.
  • the travel planning system 12 finds valid flight sequences between pairs of specified end-points in response to a query 13 received from a client system 14.
  • the client 14 communicates with the travel planning system (travel planning system) 12, via a network such as the Internet 15 through a web server 17.
  • the client 14 sends the query 13 to the web server 17 or directly to the travel planning system (travel planning system) 12.
  • the process of finding flight sequences for a portion of a trip is commonly called “scheduling.” Scheduling uses flight information contained in travel information databases 22. A particular flight sequence for a portion of a trip is an "itinerary.” Typically, the travel planning system attempts 10 to find prices for one or more combinations of itineraries from each portion of a trip.
  • Various types of travel planning systems 11 are known.
  • One type of travel planning system generates a plurality of possible itineraries (flight sequences) for the entire journey and then prices each itinerary separately.
  • Another type of travel planning system processes travel queries more efficiently by sharing computational efforts in pricing per-slice and whole journey pricings.
  • the process of finding prices for a specific combination of itineraries is known as "pricing" a set of flights, or “pricing a ticket” also referred to as a "faring process.”
  • the process of pricing the flights of a ticket involves retrieving fares from a fare database 22 and choosing fares for particular sub-sequences of flights such that all flights are paid for by exactly one fare. Pricing the flights can include grouping fares into priceable-units, and verifying that fare rules permit the particular choices of fares and priceable-units.
  • a fare is a price an airline offers for one-way travel between two airports that has associated restrictions on its usage called “rules.” If a fare's rules permit, a fare may cover more than one flight, and tickets may be priced using more than one fare.
  • rules rules
  • airlines publish fares in markets that often require many flights to get between a desired origin and destination.
  • the travel planning system 11 responds to LFS queries 13 that typically include origins and destinations, and travel times for each segment of a trip.
  • a complete solution 26 as described below can be reserved, booked, or sold as one (Passenger Name Record) PNR and/or ticket, or alternatively, as several PNRs and/or tickets.
  • An individual ticket or PNR is a subset of a complete solution that can be purchased independently, and includes all or a proper subset of passengers, all or a proper subset or flights, and all or a proper subset of fares.
  • a PNR passenger name record
  • a ticket is a record of payment and that contains information about the fares used to pay for flights as well as proof of payment.
  • each passenger on a PNR is issued a separate ticket that provides payment information for all the flights on the PNR.
  • Described below are techniques to permit multiple PNRs to cover an entire solution, either because different passengers are placed in different PNRs or different flights are placed in different PNRs, or both) and/or techniques where multiple tickets are used to cover a single PNR (e.g., where a passenger's payment for multiple flights in a single PNR are recorded in multiple tickets rather than a single ticket.
  • a technique to partition complete solutions is to sell multiple passengers individually. Putting each passenger on their own PNR overcomes the industry restriction that every person on a PNR must use the same booking code for a flight, preventing a cheaper mixed booking code solution in the situation where flight availability is for instance Y2, Ql . It may be computationally expedient in a travel planning system to avoid placing children or infants on their own PNR, as typically restrictions may prevent them from being priced without an accompanying adult. Another technique to partition complete solutions is to sell each priceable unit separately.
  • a priceable unit is an industry term that represents a fundamental unit at which many fare restrictions apply. For example, round trip fares often include minimum stay requirements and these can only be expressed when both an outbound and a return fare are combined.
  • a further technique to partition complete solutions is to sell the flights or fares of each airline separately. Many of the same benefits that are achieved by selling PUs separately are also achieved by selling the flights of each airline separately, since end- on-end and joint ticketing agreements often only prevent airline combinations from appearing on the same ticket.
  • LFS queries and solutions are conceptually divided into trip-segments, or slices, that represent the sub-portion between extended layovers. For example, "round trip" queries are divided into two slices, and the solutions are likewise divided into two slices.
  • PNRs and/or tickets There are a number of reasons why it may be impractical to place the flights of a single slice on multiple PNRs and/or tickets, including baggage transfer arrangements and airlines' reluctance to take responsibility for flight delays. For this reason, dividing a solution into PNRs and/or tickets by slices, or subsets of slices, may be desirable.
  • a ticket with three slices could be divided into 3 tickets, or any one of 3 combinations of a two-slice ticket with a one slice ticket.
  • a further advantage of such partitions is that there is a smaller search space than with PUs, and the possibilities are fixed given the flights. Not all of these possibilities are exclusive. For example, a complete solution could be split both by passenger and by priceable unit, airline, or slice.
  • Travel agents and travelers are capable of manually splitting a solution into multiple parts and booking them separately. However, travel agents and travelers would have to manually split a solution on their own initiative, rather than using an automated process to inform them of when it is beneficial and when it is not beneficial to split a solution. Because of these limitations, it is unusual for a travel agent and especially a traveler to split solutions.
  • travel planning systems and itinerary pricing systems can be constructed to accept queries that include a specification of whether or not to expand a search space to include the possibility of multiple PNRs and/or tickets and/or sales channels, and to return with the solutions a specification of the partition into PNRs and/or tickets (or other instructions for modifications to the ordinary booking and ticketing process) for the returned solutions.
  • the query would specify the kinds of partitions that are allowed. For example, the query would include a specification restricting the partitions to slice-based flight partitions or requiring that certain sets of passengers be placed in a common PNR.
  • Some travel planning systems perform LFS queries by first generating a multitude of possible complete itineraries (flight sequences) for all slices for the entire journey and then price each itinerary sequentially, e.g., pricing a first itinerary, then pricing a second, and so forth. While inefficient, this technique is a relatively straightforward technique to process LFS queries, given a pre-existing itinerary pricing system.
  • Compplete Itinerary refers to all the flights in a solution rather than the flights of a single slice (trip-segment) of the solution (I), whereas, the word “Itinerary” corresponds to the flight sequences in a single slice (trip segment) of a journey.
  • a multiple ticket or multiple-PNR search can be implemented as an outer search layer.
  • the travel planning system determines complete itineraries for the entire journey and prices each slice of the journey, as usual. This is typically accomplished in such systems, by enumerating sets of itineraries for each slice and taking a cross product of the sets of itineraries for each slice, pruning the result of the cross product to a manageable number of complete itineraries, and price each complete itinerary individually.
  • each sub-itinerary (for each slice) is priced as a single unit.
  • the multiple-unit options are constructed by combining per- trip-segment pricings. For example, the cheapest multiple-ticket solution is constructed from the cheapest tickets for each trip segment. Such a solution can be added to the set of solutions constructed by a conventional search method.
  • a technique 40 for pricing each itinerary (for each slice) as a single PNR and/or ticket (unit) in a travel planning system that generates a plurality of possible itineraries (flight sequences) for the entire journey or a complete itinerary and that prices each complete itinerary is shown.
  • the multiple-unit options are constructed by combining per-trip-segment units. For example, the cheapest multiple- ticket solution is constructed from the cheapest tickets for each trip segment.
  • the technique prices 42 each itinerary, and produces 44 a cross-product of each itinerary ticket to produce whole-journey, e.g., complete itinerary, multi-ticket solutions.
  • the technique prunes or deletes 46 the resulting possible combinations to a manageable number of whole-trip combinations, based upon some specified criteria.
  • Criteria can include the price or convenience of the combination.
  • the technique tests 47 the resulting solutions produced by the cross-product and if the resulting solutions are better than (e.g., more expensive) solutions produced from pricing the whole journey, as single PNRs and/or tickets for the whole journey, the technique 40 adds 48 the resulting solutions to set of normally produced solutions.
  • the flights in the complete itinerary can be partitioned by carrier and each flight set priced separately.
  • the total effort involved is unlikely to be greater than twice the cost of the whole-itinerary pricing.
  • each passenger in a multi-passenger query can be priced separately with seat availability artificially decreased for latter passengers to account for earlier use of seats for the earlier-priced passengers.
  • seat availability is such that a cheap booking code is available for only one passenger, and the travel planning system would ordinarily price all passengers using the same booking code, the alternative possibility that multiple PNRs are used is considered.
  • an initial pricing is performed for one passenger with full seat availability.
  • a technique 50 for pricing multi-passengers is shown.
  • the process receives whole journey itineraries 52 and for each (whole- journey) complete itinerary 54 and for each passenger i, 56, the process 50 sends 57 a query to a travel planning system for the passenger i, and provides 58 in the query an indication that the TPS should internally decrease whatever seat counts the TPS arrives at during its ordinary process of retrieving available seat counts for flights by a specified sum, computed by the querier as the sum of passengers from 1 .. i-1.
  • the technique 50 collects 59 the per-passenger answers to form a complete solution.
  • process 60 depicts an alternative implementation of splitting.
  • a travel planning system finds complete itineraries (flight sequences) for the entire journey and thereafter prices each complete itinerary separately.
  • Process 60 takes a subset of the solutions produced and re -prices the subset of solutions, as multiple PNRs and/or tickets.
  • process 60 partitions the solutions by trip segment or carrier or passenger, and thereafter re-prices each partition. If the total price or other properties of interest are improved by the combination of the multiple tickets, then that pricing method is returned in addition or in place of the whole-journey pricing.
  • One advantage of this process 60 is that the extra computational effort of exploring multiple PNRs and/or tickets is expended only on solutions that have been vetted by ordinary pricing mechanisms.
  • Process 60 for using a sequential pricing travel planning system that re-prices a subset of solutions returned, as multiple tickets includes sending 62 a user query for travel to a travel planning system.
  • the travel planning system returns 64 a solution set S.
  • the technique 60 constructs 68 a set P of partitions of flights and passengers of s (each partition p in P is a different way of dividing s into multiple pieces).
  • the process 60 returns 82 the set P.
  • One or more partitions may be selected and the technique need not use all of the partition methods or determine all of the partitions, as described above.
  • Another implementation performs LFS or itinerary pricing by relaxing constraints, rules, or regulations on solutions that would be circumvented if multiple PNRs and/or tickets were used to sell solutions.
  • process 90 performs itinerary pricing by relaxing constraints, rules and/or regulations. For example, end-on-end restrictions, carrier- combination restrictions and same booking-code restrictions are relaxed. One or more constraints, rules and/or regulations are relaxed, meaning that the logic to evaluate fares according to fare rules is altered so as to apply the specified "relaxed" constraints, rules and/or regulations 91.
  • the TPS ordinarily applies a rule check that enforced end-on- end fare restrictions, that rule check is turned off for this search.
  • the search can be unaltered.
  • the solutions can be checked in a post-processing pass to determine whether the solutions violate any constraints if sold as a single unit 92. That is, any rule checks that were skipped in the initial processing are applied to the entirety of the solution to check whether the complete solution could, in fact, be sold as a single unit.
  • a complete solution contains a constraint violation after the check 92
  • the pricing of the complete solution is performed again, 93, but this time on individual portions of the complete solution to validate the multiple-ticket possibility. The details of this process are described further below. If the complete solution does not contain any constraint violations, the complete solution is sold as a single unit 94, or re-priced as a single unit with the constraints enforced rather than relaxed 95, for additional assurance of its validity.
  • the advantage of this implementation is that the search over methods for splitting the journey is guided by the lowest-priced complete solution. If the complete solution does not contain constraint violations, there is no need to consider the possibility of selling as multiple units.
  • methods for splitting include placing two fares that are incompatible on different tickets 96, placing two carriers that are incompatible on different PNRs/tickets 97, or placing multiple passengers that use different booking codes on different PNRs 98.
  • Graph coloring is a computer science problem of assigning "colors" (e.g., numbers 1, 2, ...) to the vertices of a graph such that no two vertices connected by an edge have the same color (e.g., number).
  • Graph coloring can be envisioned as the problem of assigning colors to a wall map of the United States such that no two adjacent states are colored the same.
  • a graph coloring algorithm is applied 99 to the solutions to find a minimal number of selling units, the graph vertices representing solution pieces such as flights and fares. If constraints prevent two solution pieces from appearing on the same ticket or PNR, the solution pieces are connected by an edge.
  • a process 100 for pricing by relaxing constraints, rules, or regulations on solutions, if priced or sold as multiple PNRs or tickets is shown.
  • the process 100 prices flights and passengers by relaxing ordinary ticket/PNR constraints such as end-on-end fare combinability restrictions; and/or ticket carrier combination restrictions; and/or sales channel combination restrictions. These checks are applied to the resulting pricings to determine whether pairs of flights or fares are incompatible under the one-PNR/ticket assumption.
  • the process 100 receives 102 pricing "z," and constructs 104 a graph over flights by connecting two flights if they violate carrier ticket combination restrictions; connecting two flights if they are covered by two different fares that violate each other's end-on-end combinability restrictions; or, require different sales channels
  • the process 100 runs 106 a graph coloring algorithm to find a minimal coloring of the graph, and partitions 108 the flights by color.
  • the process 100 tests 110 to see if multiple colors are present. If not, the process 100 returns solutions. Otherwise, the process 100 for each color c, 112, collects 114 a set of flights of that color and prices 116 the collected set of flights as a single ticket.
  • the process 100 tests 118 to see if all pricings succeeded and, if so, collects 122 pricings to form a solution. If pricings did not succeed, the process 100 processes the next color.
  • the process 100 can be extended to allow multiple passengers to be booked using different booking codes.
  • FIGS. 6A-6B a process 130 for pricing by allowing multiple passengers to be booked using different booking codes is shown.
  • the process 130 uses similar processes, as mentioned above in FIGS. 5A-5B and is illustrated in FIG 6A using the same numbers as FIGS. 5A-5B for illustration.
  • the technique 130 prices flights and passengers, relaxing ordinary ticket/PNR constraints such as end-on-end fare combinability restrictions; and/or ticket carrier combination restrictions; and/or sales channel combination restrictions and also relaxes all-passengers-must-use-same- booking-code restrictions.
  • the process 130 receives 102 pricing "z" and constructs 104 a graph over flights by connecting two flights if they violate carrier ticket combination restrictions, connecting two flights if they are covered by two different fares that violate each other's end-on-end combinability restrictions or require different sales channels.
  • the process 130 runs 106 a graph coloring algorithm to find minimal coloring of the graph and partitions 108 the flights by color.
  • the process 130 builds 132 a graph among passengers by connecting two passengers if they use a different booking code for any flight. Then a minimal graph coloring 134 is performed over the passenger graph and partitions 136 passengers by color.
  • the technique 130 prices 138 flights for each passenger set (passengers of a color) separately and performs 140 a booking-code decrement on subsequent passenger sets to account for the other passengers on the same flights.
  • the technique tests 130 to see if all passenger pricings succeeded 142 and, if so, collects 144 pricings to form a solution.
  • the process 130 assigns each passenger a color and re-prices each color as a single unit. In order for the entire solution to be valid, each color would need to succeed.
  • Some types of travel planning systems process travel queries more efficiently by sharing computational efforts in pricing per-slice and whole journey pricings.
  • One such travel planning system is described in U.S. Patent No. 6,381,578, by Carl G. de Marcken entitled: "Factored Representation OfA Set Of Priceable Units” filed as application serial no. 09/109,876, on July 2, 1998, which patent is assigned to the assignee of the present application, ITA Software, Inc. (Cambridge, MA), as mentioned above and is incorporated herein by reference in its entirety.
  • the techniques disclosed in that patent price many itineraries simultaneously.
  • the travel planning system disclosed in that patent searches by constructing and evaluating individual travel units such as fare-components and priceable-units, builds a representation of all the possible ways they can be combined to cover a journey, and enumerates specific answers from the representation (called the pricing graph).
  • Described below is a process 150 to extend the architecture described in the above patent (6,381,578) to efficiently search for multiple ticket, PNR, or point-of-sale solutions simultaneously with the singleton, i.e. conventionally produced possibility.
  • the modified faring process 150 retrieves 151 itinerary sets for all slices in a journey.
  • the itinerary sets are provided from a scheduler process (such as the one referred to in the patent or other scheduler processes) for each slice of a journey where a slice corresponds to a direction of travel.
  • a scheduler process such as the one referred to in the patent or other scheduler processes
  • the faring process 18 decomposes 152 the complete itinerary into faring atoms.
  • faring atoms refer to a sequence of flight segments or equivalently legs that are spanned by a single fare.
  • the complete itinerary
  • a faring atom is represented by a data structure that preferably includes the following fields as shown in TABLE 2:
  • Split Assumptions the set of elements from Splits for which the faring-atom is valid, that it is a subset of Splits.
  • fare-components and priceable-unit-labels are also modified to include such a Split Assumptions fields.
  • the faring process 150 decomposes 152 individual units of representation, e.g., faring atoms for the split possibilities by computing the units multiple times, with each time using different journey split assumptions, providing multiple faring atoms.
  • the assumptions required for the unit of representation, e.g., faring atom to be valid are stored with the corresponding individual unit, e.g., the faring atom.
  • An example of the process 152 to compute these multiple faring atoms is discussed in FIG. 7C, below.
  • the faring process 18 After the faring process 18 decomposes 152 the itineraries into faring atoms, the faring process 18 retrieves 154 fares and rules 156 for each faring atom by accessing a fares/rules database, as is commonly known and disclosed in the patent. At this point a fare's routing is retrieved from a routing database and applied to the faring atom. If the routing test fails, the fare cannot be applied to the faring atom and a fare component is not built.
  • the faring process 18 applies the rules 158 to the faring atoms to produce fare components.
  • Fare-components are combinations of faring-atoms and fares.
  • Fare- components (TABLE 3) are produced if a fare's rules pass a preliminary check on a faring-atom.
  • the fare-components are used to store deferred rules (e.g., deferred record-2s and combinability record-2s) that are applied at a later stage of processing.
  • Fare components also store extra information produced during the rule-checking process, such as information about surcharges and penalties and discounts that are applied to the base fare price.
  • the faring process 18 constructs 160 priceable units. For certain types of rules such as those that require access to fares and/or flights from outside of the fare component, those rules are stored in the fare component for later or deferred evaluation. Construction 160 of priceable units takes valid fare components and constructs priceable units from the fare components. This process 160 involves grouping fare components from different slices and checking fare component combination restrictions. At this stage of processing, the rules deferred in step 158 are reapplied.
  • Priceable units are represented by priceable-unit-cores and priceable-unit-labels.
  • Priceable-unit-cores are collections of fares and other information associated with fares within a priceable-unit, such as discounts and penalties and surcharges.
  • Priceable-unit- cores (TABLE 4) are referenced by priceable-unit-labels.
  • Priceable-unit-labels group a set of priceable-unit-cores with sets of faring- atoms. Together, the priceable-unit-cores and priceable-unit-labels are used to represent sets of priceable-units (TABLE 5).
  • the itineraries and priceable units are grouped together into complete sets of pricing solutions. This occurs by a linking process 164 that links itineraries to corresponding pricing units from different slices to provide the pricing solution 166. At this juncture, any remaining cross priceable unit fare combinability checks are performed to eliminate invalid combinations.
  • the linking process 164 differs from that described in the patent to take into consideration, searching for multiple ticket, PNR, or point of sale solutions in a manner that is integrated with the faring process. Details on the linking process 164 are discussed in FIG. 7D.
  • each of these methods translates into sets of specific split possibilities.
  • possible splits include:
  • the method of dividing the journey by slice and by priceable unit are ordinarily incompatible.
  • the splitting process will split the journey either by slice or by priceable unit, but not both (at least for priceable units that span slices).
  • not all split possibilities need to be processed. For example, it may be more efficient only to consider a subset of the possibilities, such as all passengers separately or all passengers together, but not other possibilities (e.g., some passengers together and others separately).
  • the set of split possibilities may be filtered based on either known booking limitations or traveler preferences. For example, the possibility of breaking a solution within a slice may be conditioned on the length of layover to allow extra time for baggage transfer.
  • splitSlices the set of different multi-ticket ways to divide PUs across tickets
  • splitPsgrs the set of passenger split possibilities
  • the set “Wholeltin” is the singleton set of not splitting the journey by either slice or PU. Roughly, the total set of ways to split the flights of answers into tickets is:
  • each faring-atom and faring-market is duplicated 153a and labeled 153b with the elements of "SplitFlights.”
  • Each fare, during seat availability processing, is duplicated 153c and labeled 153d with the elements of "SplitPsgrs.”
  • Priceable units are constructed 153e from faring-markets that have the same label, and are assigned 153f that label.
  • the Fare combinations within a priceable unit are only constructed if 153g all of the fares have the same "SplitPsgrs" label.
  • the PU-labels are distinguished by both the "SplitPsgrs” and “SplitFlights” labels of the faring-atoms and fares within (every PU-label has a single label from Splits).
  • Rule checks 153h are performed on units of representation, and the rule checks are altered to take into account the split label. Examples of rule checks that may be altered include:
  • booking code checks applied to fares with labeled with elements from SplitPsgrs alter the set of available booking codes as appropriate: booking code decrementing is used to reduce counts by the sum of the number of higher priority passengers not in the set.
  • split labels may be equivalent, because the split labels reflect different behavior only on other parts of the journey.
  • the elements of "SplitSlices" for a faring-atom or faring-market in slice 1 there is no need to distinguish between the split case where all slices are on different tickets from that where slice 1 is on one ticket and slices 2 and 3 are on another.
  • Checks to determine whether two faring-markets can be combined into a priceable-unit are performed by checking whether the intersection of labels is non-empty, and the priceable unit (e.g., priceable unit label) is labeled with the intersection.
  • the linking process 164 (FIG. 7B) is modified from that of the linking process described in U.S. Patent No. 6,381,578, mentioned above, to construct the pricing graph from fare components and itineraries enforcing an integrity or consistency of the journey split assumptions that are required for the units to be valid.
  • the linking process 164 involves slice-label-sets and open-label-sets data structures.
  • Slice-label-sets data structures group itinerary divisions by the multi-slice priceable-unit-labels they can enter into.
  • a unique slice-label-set is constructed for every set of multi-slice priceable-unit-labels.
  • Each slice-label-set stores both the set of multi-slice priceable-unit-labels and a set of itinerary-label-holders, which contain single-slice priceable-unit-labels on a per- itinerary basis.
  • Each slice-label-set is a pair of an itinerary and a set of division-label- holders.
  • Each of these division-label-holders is a pair of a division and a set of sets of single-slice priceable-unit-labels (TABLE 6).
  • Slice-Label-Set fields Use multi-slice-PU-labels A set of multi-slice PU-labels.
  • itinerary-label-holders A set of itinerary-label-holders.
  • division-label-holders A set of division-label-holders.
  • Open-label-sets data structures (TABLE 7) are used to summarize the state of the linking process 164. Each is a set of "open” multi-slice priceable-unit-labels and a set of backward-links . Each of these backward-links is a pair of a "slice-label-set” and an "open-label-set.”
  • Open-Label-Set fields Use open-PU-labels A set of open multi-slice PU-labels. backward-links A set of backward-links.
  • Backward-Link fields Use slice-label-set A slice-label-set.
  • open-label-set An open-label-set.
  • each slice-label-set and each open-label-set is assigned 164a a set of labels.
  • the label-sets for those PU- labels are intersected 164b. If the intersection of the label sets for those PU-label is non-empty 164c, a slice-label-set is constructed 164d and labeled 164e with the intersection.
  • the linking process computes 164f the intersection L of Ll and L2. If the intersection is non-empty 164g, and produces an open-label-set that does not already exist, the process 164 adds 164h back the pointer and union L into pricing unit labels.
  • Enumeration of solutions can be unchanged, although it may be desirable to analyze the labels on solution components and annotate the solution with the split requirements (that is, how the solution must be partitioned for reservation and ticketing purposes).
  • the linking algorithm links itineraries to corresponding pricing units from different slices to provide pricing solutions.
  • the pricing solutions in that patent are represented in a compact manner, such as in a directed acyclic graph (DAG) structure, referred to therein as a pricing graph.
  • DAG directed acyclic graph
  • Selling a solution as multiple tickets, or reserving it as multiple PNRs, has consequences for both a travel agent and a traveler.
  • the primary advantage is usually either a cheaper total price, or working around restrictions that could have outright prevented a sale. Disadvantages include extra hassle for the agent, possibility of confusion for the airline and traveler during the trip, and so forth.
  • a value function is used to rate solutions and penalties can be added into the pricing-graph, by adding a special penalty object to the first-slice-label-sets based on its labels.
  • Traffic Restrictions Airlines frequently assign so-called "traffic restrictions" to flights. These restrictions prevent the use of certain flights unless in combination with another. A typical use is to prevent the use of a code share flights marketed by airline A and operated by airline B, unless a connection is made to another flight actually operated by A. Because of traffic restrictions, a sequence of flights that could be sold as a single ticket may not always be able to be partitioned for sale.
  • a traveler or travel-agent may wish to understand why a solution is reserved or purchased in multiple pieces.
  • the reasons can be computed in a variety of ways and displayed in a user interface.
  • the solution can be re-priced as a single entity forcing the same fares, priceable units, and booking codes, and failures recorded.
  • Explicit checks can be made of various likely causes, such as checking whether different passengers use different booking codes for the same flights, checking whether multiple airlines appear in the solution that do not have ticketing agreements, checking each fare's end-on-end combinability restriction against other fares, etc.
  • Air Traffic commonly condition prices on "point of sale,” a term that encompasses the identity of the selling travel agency and global distribution system (GDS), and sometimes also based on factors more closely tied to the passenger, such as the identity of the organization that employs the selling travel agency. For example, an airline may make a discount fare available for sale only by a particular travel agency when booking through a particular GDS, or only to employees of a particular company. They also condition seat availability on such information, i.e., the query from a travel planning system to an airline about seat availability for a flight typically includes travel agency and passenger information, and the airline may change its answer depending on these values (offering a Q booking code to a preferred agency or frequent flyer, but not to others).
  • GDS global distribution system
  • travel planning systems accept only a single travel agency and traveler identifier for a query.
  • some travelers and some agencies may have flexibility over how they identify themselves. For example, a traveler has a choice over what agency they buy a ticket through, and an agency may have choices over what GDS sales are made through.
  • a travel planning system accept in a query a set of possible points of sale and include in its search space the choice of which to select. If the entire solution is sold as one unit it may be required that the fares and booking codes be consistent with a single point of sale from the set; if the solution is sold as several units each may use a different POS.
  • a process 200 to process a set of possible points of sale during a search of pricing solutions and to provide a choice of which points of sale to select can be implemented independently of or with multiple-PNR/ticket processing discussed above.
  • the process 200 accepts 202 a query that is augmented to accept multiple points of sale.
  • the process 200 will query 204 airlines for flight availability for each different point of sale, and record 206 the information indexed by point of sale.
  • the process will iterate 208 over all points of sale and record the set of POSes that succeed, storing such information with the fare. This iteration can be performed during fare rule checks and booking code availability checks that depend on points of sale. In the context of the travel planning system described in the patent (6,381,578), this would be stored in the fare-components.
  • the process 200 combines 210 the point of sale sets as appropriate across units of pricing, in a manner analogous to the way split labels are propagated in the previously described algorithms; for example, in the context of the travel planning system described in the patent.
  • the process 210 (FIG. 8) to combine the points of sale sets combines the point of sale sets according to the stage of processing.
  • the process 210 determines 210a intersections of POS sets and determines 210b if there is an intersection in the POS sets for the PU's fare- components.
  • the process combines 210c fares only if there is an intersection in the POS sets, and annotates 21Od the resulting PU-labels with the intersection.
  • the process 210 determines 21Oe if there is an intersection of the POS sets and combines 21Of PU-labels only if there is an intersection of the POS sets, and annotates 21Og the resulting slice-label-sets with the intersection.
  • the process 210 determines 21Oh if there is an intersection of the POS sets and combines 21Oi the slice-label-set and preceding open-label-set (if any) if there is an intersection of the POS sets and forms 21Oj a union of this intersection into the open- label-set POS set.
  • each ticket is priceable using a single POS.
  • the changes are expressed using a form of the search algorithm where each PU-label, open-label-set and slice-label-set is assigned a single split label rather than a set.
  • fare- components and PU-labels are distinguished by both a point of sale (POS) set and split label.
  • POS point of sale
  • Each slice-label-set and open-label-set can have a table mapping a split-identifier to the POS set, where a split identifier is an object representing a component of a split partition.
  • split-identifier i if 1 is in SplitSlices, i is the set of slices that is the partition component of 1 that contains the PU; if 1 is Wholeltin, i is a canonical object, call it 'nil'; if 1 is in SplitPUs, i is the partition component of 1 that contains the PU, for the case where each PU is to be sold separately, i is simply the PU-label itself.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne des techniques permettant de générer une solution de voyage qui se compose de multiples unités de voyage. Les techniques incluent l'envoi d'une demande de planification de voyage ayant une spécification de partage à un système de planification de voyages. Le système de planification de voyages traite la demande de voyage afin de générer des solutions qui se basent sur les partages. Des possibilités de partages peuvent inclure les registres de noms de passagers (PNRs), les billets ou les canaux de vente pour les solutions retournée. Le traitement peut comporter l'assouplissement de contraintes, de règles, ou de règlements sur les solutions et le recalcule des prix des solutions, comme de multiples billets, en partageant les solutions par un partage. Des billets peuvent être générés pour les différentes parties des multiples unités de voyage à partir de la solution de voyage en utilisant différents procédés de vente ou points de canaux de vente.
PCT/US2007/086625 2006-12-07 2007-12-06 Système de planification de voyages qui partage le travail à travers les itinéraires et produit des réponses comportant de multiples canaux de vente/pnrs/billets par réponse WO2008070768A2 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US11/635,400 US20080140464A1 (en) 2006-12-07 2006-12-07 Travel planning system that produces answers involving mulitple sales channels/PNRs/tickets per answer
US11/635,399 US20080140463A1 (en) 2006-12-07 2006-12-07 Travel planning system that produces answers involving multiple sales channels/PNRS/tickets per answer
US11/635,805 US20080140466A1 (en) 2006-12-07 2006-12-07 Travel planning system that re-prices travel options to produce answers involving multiple sales channels/PNRs/tickets per answer
US11/635,395 US20080140462A1 (en) 2006-12-07 2006-12-07 Travel Planning system that relaxes constraints to produce answers involving multiple sales channels/PNRs/tickets per answer
US11/635,401 2006-12-07
US11/635,399 2006-12-07
US11/635,395 2006-12-07
US11/635,400 2006-12-07
US11/635,805 2006-12-07
US11/635,401 US20080140465A1 (en) 2006-12-07 2006-12-07 Travel planning system that shares work across itineraries and produces answers involving multiple sales channels/PNRs/tickets per answer

Publications (2)

Publication Number Publication Date
WO2008070768A2 true WO2008070768A2 (fr) 2008-06-12
WO2008070768A3 WO2008070768A3 (fr) 2008-12-11

Family

ID=39493066

Family Applications (5)

Application Number Title Priority Date Filing Date
PCT/US2007/086625 WO2008070768A2 (fr) 2006-12-07 2007-12-06 Système de planification de voyages qui partage le travail à travers les itinéraires et produit des réponses comportant de multiples canaux de vente/pnrs/billets par réponse
PCT/US2007/086631 WO2008070770A2 (fr) 2006-12-07 2007-12-06 Système de réservation de voyage dont chaque réponse implique de multiples canaux de vente/pnr/tickets
PCT/US2007/086618 WO2008073802A2 (fr) 2006-12-07 2007-12-06 Système de planification de voyage qui produit des réponses impliquant de multiples canaux de vente/pnr/tickets par réponse
PCT/US2007/086611 WO2008073799A2 (fr) 2006-12-07 2007-12-06 Système de planification de voyage qui retarifie les options de voyage pour produire des réponses impliquant de multiples canaux de vente/pnr/tickets par réponse
PCT/US2007/086632 WO2008070771A2 (fr) 2006-12-07 2007-12-06 Système de réservation de voyage dont chaque réponse implique de multiples canaux de vente/pnr/tickets par réponse

Family Applications After (4)

Application Number Title Priority Date Filing Date
PCT/US2007/086631 WO2008070770A2 (fr) 2006-12-07 2007-12-06 Système de réservation de voyage dont chaque réponse implique de multiples canaux de vente/pnr/tickets
PCT/US2007/086618 WO2008073802A2 (fr) 2006-12-07 2007-12-06 Système de planification de voyage qui produit des réponses impliquant de multiples canaux de vente/pnr/tickets par réponse
PCT/US2007/086611 WO2008073799A2 (fr) 2006-12-07 2007-12-06 Système de planification de voyage qui retarifie les options de voyage pour produire des réponses impliquant de multiples canaux de vente/pnr/tickets par réponse
PCT/US2007/086632 WO2008070771A2 (fr) 2006-12-07 2007-12-06 Système de réservation de voyage dont chaque réponse implique de multiples canaux de vente/pnr/tickets par réponse

Country Status (1)

Country Link
WO (5) WO2008070768A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11747153B1 (en) 2022-07-21 2023-09-05 Travelshift ehf. Apparatus and associated method for determining a travel itinerary

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016724A1 (en) * 2000-07-28 2002-02-07 Yue-Heng Yang System and method for booking international multiple-stop tickets
US6381578B1 (en) * 1998-07-02 2002-04-30 Ita Software, Inc. Factored representation of a set of priceable units
US20020077871A1 (en) * 2000-06-20 2002-06-20 Greg Udelhoven Traveler service system with a graphical user interface for accessing multiple travel suppliers
US20020184060A1 (en) * 2001-06-01 2002-12-05 Schmitz Benjamin W. System and method for receiving and loading fare and schedule data
US6609098B1 (en) * 1998-07-02 2003-08-19 Ita Software, Inc. Pricing graph representation for sets of pricing solutions for travel planning system
US20030177045A1 (en) * 2002-01-25 2003-09-18 Matt Fitzgerald System and method for processing trip requests
US20050033616A1 (en) * 2003-08-05 2005-02-10 Ezrez Software, Inc. Travel management system providing customized travel plan
US20050033614A1 (en) * 2003-08-05 2005-02-10 Sabre Inc. System and method for coordinating travel itineraries
US20050108068A1 (en) * 2003-11-14 2005-05-19 Marcken Carl D. Generating flight schedules using fare routings and rules

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7742934B2 (en) * 1999-03-25 2010-06-22 Travelocity.Com Lp Methods and apparatus for determining non-obvious savings in the purchase of goods and services
US20060085370A1 (en) * 2001-12-14 2006-04-20 Robert Groat System for identifying data relationships
US20040039615A1 (en) * 2002-08-26 2004-02-26 Maycotte Higinio O. Automated collection of flight reservation system data
US7346526B2 (en) * 2002-10-16 2008-03-18 Ita Software, Inc. System and method for entering flexible travel queries with layover description

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6381578B1 (en) * 1998-07-02 2002-04-30 Ita Software, Inc. Factored representation of a set of priceable units
US6609098B1 (en) * 1998-07-02 2003-08-19 Ita Software, Inc. Pricing graph representation for sets of pricing solutions for travel planning system
US20020077871A1 (en) * 2000-06-20 2002-06-20 Greg Udelhoven Traveler service system with a graphical user interface for accessing multiple travel suppliers
US20020016724A1 (en) * 2000-07-28 2002-02-07 Yue-Heng Yang System and method for booking international multiple-stop tickets
US20020184060A1 (en) * 2001-06-01 2002-12-05 Schmitz Benjamin W. System and method for receiving and loading fare and schedule data
US20030177045A1 (en) * 2002-01-25 2003-09-18 Matt Fitzgerald System and method for processing trip requests
US20050033616A1 (en) * 2003-08-05 2005-02-10 Ezrez Software, Inc. Travel management system providing customized travel plan
US20050033614A1 (en) * 2003-08-05 2005-02-10 Sabre Inc. System and method for coordinating travel itineraries
US20050108068A1 (en) * 2003-11-14 2005-05-19 Marcken Carl D. Generating flight schedules using fare routings and rules

Also Published As

Publication number Publication date
WO2008073802A2 (fr) 2008-06-19
WO2008070771A3 (fr) 2008-12-31
WO2008070770A3 (fr) 2008-12-18
WO2008070768A3 (fr) 2008-12-11
WO2008070771A2 (fr) 2008-06-12
WO2008073802A3 (fr) 2008-12-04
WO2008073799A2 (fr) 2008-06-19
WO2008073799A3 (fr) 2008-12-24
WO2008070770A2 (fr) 2008-06-12

Similar Documents

Publication Publication Date Title
US8265967B2 (en) Incremental searching in multi-passenger multi-route travel planning
Chatwin Multiperiod airline overbooking with a single fare class
US20050228702A1 (en) Devices, systems, and methods for providing remaining seat availability information in a booking class
US8306835B2 (en) User interface for inputting multi-passenger multi-route travel planning query
US20120197673A1 (en) Generating Flight Schedules Using Fare Routings and Rules
US8265966B2 (en) Multi-passenger multi-route travel planning through common locations
US7921022B2 (en) Multi-passenger multi-route travel planning
US8731980B2 (en) Low fare search for ticket changes
US20080041945A1 (en) Ticket reconstruction
US8589195B2 (en) Multi-passenger multi-route travel planning
US8185418B2 (en) Multi-passenger multi-route travel planning
US8688485B2 (en) Low fare search for ticket changes using married segment indicators
US20070168854A1 (en) User interface for presentation of solutions in multi-passenger multi-route travel planning
US20080140466A1 (en) Travel planning system that re-prices travel options to produce answers involving multiple sales channels/PNRs/tickets per answer
US20080140465A1 (en) Travel planning system that shares work across itineraries and produces answers involving multiple sales channels/PNRs/tickets per answer
US20080140464A1 (en) Travel planning system that produces answers involving mulitple sales channels/PNRs/tickets per answer
US20080140463A1 (en) Travel planning system that produces answers involving multiple sales channels/PNRS/tickets per answer
WO2008070768A2 (fr) Système de planification de voyages qui partage le travail à travers les itinéraires et produit des réponses comportant de multiples canaux de vente/pnrs/billets par réponse
EP2175404A1 (fr) Procédé et système pour la mise en place d'une offre de services optimale pour un service ou un produit donné
US20080140462A1 (en) Travel Planning system that relaxes constraints to produce answers involving multiple sales channels/PNRs/tickets per answer
US8185419B2 (en) Incremental searching with partial solutions for multi-passenger multi-route travel planning
US20080154630A1 (en) Method for Generating A Diverse Set of Travel Options
WO2008005844A2 (fr) Base de données pour stocker le champ technique d'informations de déplacement historique

Legal Events

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

Ref document number: 07865299

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07865299

Country of ref document: EP

Kind code of ref document: A2