Patent Grant
11941552
The present disclosure relates to data processing and, more particularly, to facilitating travel planning.
Travel consumers enjoy of a plurality of options. The travel market is replete with numerous sources providing travel-related information and advice on everything from destinations to hotels, related points of interest, and pricing data for a vast array of goods and services. While consumers can derive much utility from this choice environment enabled by online travel agencies (OTAs) and travel websites, a choice task of the travel consumer is often encumbered by information abundance and by legacy technology platforms that almost invariably complicate the consumer choice problem.
For the average consumer, these choice-related challenges can take many forms, which include a large number of viable itinerary options to sort through, evaluate, and ultimately choose from; disparate and non-homogenous information sources, all of which possess varying degrees of quality, usefulness, and reliability; and the need to consider complex value trade-offs among key choice attributes and objectives (e.g., price vs. suitability of a selected flight for the consumer), together with the existence of often conflicting objectives (e.g., a desire for luxury, constrained by willingness-to-pay).
To overcome the choice-related challenges, average consumers typically utilize a vast array of short-cuts and heuristics, all of which enable the consumer to sift through and evaluate numerous choice options, in ways that lead, ultimately, to choices that satisfy the consumer. This piecemeal, serial manner in which consumers typically construct, evaluate, and ultimately purchase travel itineraries (e.g., first, airfare options are reviewed and selections are made; this selection is followed, in turn, by the identification and evaluation of hotel options, and so on) can lead to undesirable allocative inefficiencies that stem from a kind of evaluative and decisional myopia that ultimately compromises the ability of the consumer to construe itinerary value holistically. In other words, delivering travel booking capabilities to the consumer needs to be redesigned to maximize the expected utility of individual consumers seeking to make travel-related purchases. Moreover, consumers need to be able to identify option combinations that create maximal overall utility or value, across the entire spectrum of available options, subject to any constraints deemed relevant to the itinerary construction, evaluation, and selection task.
Various embodiments of a travel booking platform with multiattribute portfolio evaluation as a system and methods of use thereof are provided according to the teachings herein.
According to one aspect of the invention, there is disclosed a system for facilitating travel reservations, the system comprising: a database in communication with a processor, the database having stored thereon: a travel lexicon having attribute names and related values for flights, hotels, origins, and destinations; and a travel taxonomy comprising look-up tables having logical relations and predicates; a scheduler in communication with the processor and operable to: instantiate the plurality of travel attributes in terms of the travel lexicon that are relevant to a travel-related query, thereby generating a plurality of instantiated travel attributes; index the plurality of instantiated travel attributes, thereby generating an attribute index comprising a plurality of indexed travel attributes defined in terms of the travel lexicon; search for feasible travel itineraries based on the plurality of indexed travel attributes, the feasible travel itineraries determined based on at least two weighted attributes and user preferences; and transmit the feasible travel itineraries including an optimal travel itinerary and feasibility scores to a user device to present, to the user via the user device; a parser in communication with the processor and operable to: parse the travel-related query to derive a vector function comprising at least two attribute values related to the plurality of indexed travel attributes, and to derive at least one constraint related to the travel-related query; and ascertain a relevant attribute set for the travel-related query, the relevant attribute set comprising the at least two attribute values for the travel-related query selected from the plurality of travel attributes based on a context of the travel-related query in the travel taxonomy; the processor in communication with the database, the scheduler, and the parser, the processor operable to: receive the travel-related query from the user via the user device, the travel-related query comprising free text data obtained via at least one of a natural language oral exchange or a natural language typed text; receive the user preferences for the user from at least one of the database, the user device, or a server, the user preferences including relative importances assigned to each of the plurality of travel attributes; rank the at least two attribute values related to the relevant attribute set based on encoded preference information derived from the user preferences, thereby generating a ranking that represents a relative importance of each attribute value related to the relevant attribute set; assign weights to each of the at least two attribute values based on the ranking to create the at least two weighted attributes for the relevant attribute set; associate a value to each of the feasible travel itineraries based on the at least two weighted attributes and a value score corresponding to a performance of the feasible travel itinerary under each of the at least two travel attributes, thereby generating rank-order preference data for preference information that is associated with the travel-related query; score the feasible travel itineraries based at least in part on the at least two weighted attributes for each of the feasible travel itineraries and associated rank-order preference data to create the feasibility scores; and select, from the feasible travel itineraries, based on the at least one constraint, the optimal travel itinerary to be provided to the user.
In at least one embodiment, the user preferences are determined based on one or more of the following: the travel-related query, preexisting selections of the user and preexisting selections of one or more further users.
In at least one embodiment, the system comprises a man-machine interface to receive the preexisting selections from the user.
In at least one embodiment, the travel related query is for a plurality of users.
In at least one embodiment, the processor is configured to adjust the scoring of the feasible travel itineraries based on forecasted weather conditions at a time of travel.
In at least one embodiment, the presenting of the at least one travel itinerary is performed within a predetermined time after the receiving of the travel related query.
In at least one embodiment, the processor is configured to visualize the at least one travel itinerary and corresponding scores.
In at least one embodiment, the travel-related query is provided via at least one of the following: a natural language, a typed text, and a selection of preexisting options.
In at least one embodiment, the selecting of the optimal travel itinerary from the feasible travel itineraries is based on the scoring of the feasible travel itineraries.
In at least one embodiment, the at least one constraint includes one or more of the following: a budgetary constraint, a logical constraint, a conditional constraint, and a timing constraint.
In at least one embodiment, the processor is configured to identify at least one of the feasible travel itineraries for which a budget allocation is unutilized, the budget allocation being associated with the at least one constraint.
In at least one embodiment, the processor is configured to present at least the optimal travel itinerary and the at least one of the feasible travel itineraries for which the budget allocation is unutilized to the user.
In at least one embodiment, the database has stored thereon the user preferences for the user related to the plurality of travel attributes.
In at least one embodiment, the parser is operable to parse the travel-related query to determine the user preferences based on an understanding of an intent of the user related to the travel-related query.
In at least one embodiment, the processor is operable to associate cost data with at least one of the at least two weighted attributes and the processor is operable to score the feasible travel itineraries based at least in part on the cost data associated with at least one of the at least two weighted attributes.
According to another aspect of the invention, there is disclosed a method for facilitating travel reservations by a computer processor in communication with a database having stored thereon (a) a travel lexicon having attribute names and related attribute values for flights, hotels, origins, and destinations, and (b) a travel taxonomy comprising look-up tables having logical relations and predicates, the method comprising: receiving a travel-related query from the user via a user device, the travel-related query comprising free text data obtained via at least one of a natural language oral exchange or a natural language typed text; instantiating the plurality of travel attributes in terms of the travel lexicon that are relevant to the travel-related query, thereby generating a plurality of instantiated travel attributes; indexing the plurality of instantiated travel attributes, thereby generating an attribute index comprising a plurality of indexed travel attributes defined in terms of the travel lexicon; parsing the travel-related query to derive at least one constraint related to the travel-related query and to derive a vector function comprising at least two attribute values related to the plurality of indexed travel attributes comprised in the attribute index; ascertaining a relevant attribute set for the travel-related query, the relevant attribute set comprising at least two attribute values for the travel-related query selected from the plurality of travel attributes based on a context of the travel-related query in a travel taxonomy; receiving user preferences for the user from at least one of the database, the user device, or a server, the user preferences including relative importances assigned to each of the plurality of travel attributes; ranking the at least two attribute values related to the relevant attribute set based on encoded preference information derived from the user preferences, thereby generating a ranking that represents a relative importance of each attribute in the relevant attribute set; assigning weights to each of the at least two attribute values based on the ranking to create at least two weighted attributes for the relevant attribute set; searching for feasible travel itineraries based on the plurality of indexed travel attributes, the feasible travel itineraries determined based on the at least two weighted attributes and the user preferences; associating a value to each of the feasible travel itineraries based on the at least two weighted attributes and a value score corresponding to a performance of the feasible travel itinerary under each of the at least two travel attributes, thereby generating rank-order preference data for preference information that is associated with the travel-related query; scoring the feasible travel itineraries based at least in part on the at least two weighted attributes for each of the feasible travel itineraries and associated rank-order preference data to create the feasibility scores; selecting from the feasible travel itineraries, based on the at least one constraint, an optimal travel itinerary to be provided to the user; and transmitting the feasible travel itineraries including the optimal travel itinerary and the feasibility scores to the user device to present, to the user via the user device.
In at least one embodiment, the user preferences are determined based on one or more of the following: the travel-related query, preexisting selections of the user and preexisting selections of one or more further users.
In at least one embodiment, the travel related query is for a plurality of users.
In at least one embodiment, the method comprises adjusting the scoring of the feasible travel itineraries based on forecasted weather conditions at a time of travel.
In at least one embodiment, the presenting of the at least one travel itinerary is performed within a predetermined time after the receiving of the travel related query.
In at least one embodiment, the method comprises visualizing the at least one travel itinerary and corresponding scores.
In at least one embodiment, the at least one attribute having at least one of the derived attribute values is a necessarily satisfied condition.
In at least one embodiment, the method comprises providing a man-machine interface to receive the preexisting selections from the user.
In at least one embodiment, the at least one constraint includes one or more of the following: a budgetary constraint, a logical constraint, a conditional constraint, and a timing constraint.
In at least one embodiment, the selecting of the optimal travel itinerary from the feasible travel itineraries is based on the scoring of the feasible travel itineraries.
In at least one embodiment, the method comprises identifying at least one of the feasible travel itineraries for which a budget allocation is unutilized, the budget allocation being associated with the at least one constraint.
In at least one embodiment, the method comprises presenting at least the optimal travel itinerary and the at least one of the feasible travel itineraries for which the budget allocation is unutilized to the user.
In at least one embodiment, the travel-related query is provided via at least one of the following: a natural language, a typed text, and a selection of preexisting options.
In at least one embodiment, the database has stored thereon the user preferences for the user related to the plurality of travel attributes.
In at least one embodiment, parsing the travel-related query comprises determining the user preferences based on an understanding of an intent of the user related to the travel-related query.
In at least one embodiment, the method comprises associating cost data with at least one of the at least two weighted attributes and scoring the feasible travel itineraries is based at least in part on the cost data associated with at least one of the at least two weighted attributes
Other features and advantages of the present application will become apparent from the following detailed description taken together with the accompanying drawings. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the application, are given by way of illustration only, since various changes and modifications within the spirit and scope of the application will become apparent to those skilled in the art from this detailed description.
Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with exemplary embodiments. These exemplary embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the present subject matter. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and electrical changes can be made without departing from the scope of what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.
The system may act as a decision framework that provides a structural basis for travel itinerary planning and is capable of supporting the evaluative challenges entailed in identifying the itinerary option combinations that maximize or enhance overall itinerary value for the consumer. Moreover, the system provides an analytic decision frame that brings a holistic orientation to how problems of allocative efficiency are approached within the context of the itinerary choice task.
The disclosure relates to a system for facilitating optimization-based travel itinerary planning to aid consumer efforts directed at constructing value- or utility-maximizing travel itineraries, given some understanding of goals, objectives, and preferences of a consumer, together with an understanding of any constraints, such as budgetary, logical, timing, or other constraints. More specifically, the system brings a portfolio-analytic frame to an itinerary choice task of the travel consumer. The purpose of the system is to identify Pareto efficient itinerary options that maximize overall itinerary value for the consumer and are consistent with specified constraints. By making the travel planning process more efficient, the likelihood of consumer ex post purchase satisfaction may increase because of enhanced decision quality provided to the consumer.
In the present disclosure, upon receiving a travel related query from the consumer, the platform may analyze the travel related query to determine multiple attributes and constraints relating to itinerary options of the consumer. The attributes may include itinerary elements, such as airlines, hotel options, dates, and so forth. The constraints may include budgetary constraints, timing constraints, logical constraints, and so forth. The attributes may have differing levels of importance for the consumer. Therefore, the platform may prioritize and rank the attributes based on consumer preferences. Based on the ranking, each of the attributes may be assigned a weight depending on an importance of this attribute for the consumer. Furthermore, the platform may associate each of the weighted attributes with cost data related to each of the weighted attributes. The platform may perform a search based on the attributes and the consumer preferences to assemble feasible travel itineraries. The platform may perform multiparameter scoring of feasible travel itineraries. Specifically, the feasible travel itineraries may be simultaneously scored based on the weighted attributes and the cost data associated with the weighted attributes. The travel itineraries having the highest scores may be presented to the consumer in response to the travel-related query. Further, at least one optimal travel itinerary may be selected from the feasible travel itineraries based on the constraints associated with the travel-related query. The selected optimal travel itinerary may be presented to the user.
A plurality of feasible travel itineraries is also referred to herein as an itinerary portfolio group. The itinerary portfolio group may be structured hierarchically in terms of one or more itinerary categories or groups, i.e., attributes related to the travel-related query. The itinerary portfolio group can describe typical itinerary elements of the itinerary, such as flights, hotel options, and the like, as well as other attributes, such as ground transportation options, tours, and so forth. Each itinerary portfolio group may contain a constructed choice set of determinate size, and each choice set may consist of options that pertain to the itinerary portfolio group to which the choice set belongs.
While determining multiple attributes relevant to the travel related query, the platform may create a linkage between (i) natural language instantiation of itinerary-relevant attributes via parsing the travel related query; and (ii) consumer-specified preference information concerning relevant travel goods and services (e.g., airlines and hotels), which, for example, can be ascertained from a consumer account associated with the platform.
Firstly, the platform is both intention- and preference-driven. The platform is developed at the very foundations of travel planning actions and travel-related consumption. The platform can therefore be capable of “understanding” travel-related requests in terms of the determinate goals and objectives of consumers, as well as include the ability to properly handle the logistics of travel. To the extent that it is possible for the platform to either “know” or infer the travel-related preferences of the consumer, the preferences may factor into how travel requests are ultimately serviced within the platform.
Secondly, a man-machine interface of the platform can enable specifying travel-related goals and objectives. For this purpose, the platform may use parsing of natural language of the travel related queries. Accordingly, the platform can enable the consumer to articulate/specify strategic intent via natural language queries, with the built-in intelligence to understand a robust travel lexicon.
Thirdly, the platform can be capable of supporting the complex logistics and scheduling of multi-passenger/multi-leg/multi-city itineraries. Existing OTA technologies are incapable of efficiently handling complex itinerary requests, involving multiple, perhaps geographically-distributed, travelers. In contrast, the platform may incorporate complex scheduling capabilities, enabling groups of travelers (e.g., business colleagues or families) to effectively plan and book travel.
Fourthly, the platform can possess true end-to-end integration, including fulfillment. A characteristic feature of many travel applications and web sites is the ability to move from search/research to booking/purchase within the application. The platform may have en suite capabilities that never require the consumer to exit the travel application environment prior to making a purchase decision, thereby providing the consumer with an immersive “all-in-one” experience from making a travel related query to purchasing tickets for travel.
Furthermore, interactivity and control can be built into the platform, and the consumer may be able to personalize aspects of the interactivity. The consumer can be able to define aspects of how the consumer interacts with and consumes travel content. The platform may therefore be capable of receiving requests of the consumer (in fact, capable of “listening” to the consumer), with the goal of finding satisfying solutions to articulated/stated goals and objectives, consistent with underlying preferences and consumer willingness-to-pay. Moreover, the platform may enable the consumer to amend/revise plans during searching for a requisite purchase decision.
Moreover, the platform may possess both stage and state awareness. More specifically, the platform may be operable to determine where the consumer is in the path-to-purchase. With this awareness, the platform may come to determining of information requirements and needs of the consumer.
Additionally, the platform may possess a purpose-built choice architecture that may provide the consumer with decision aiding capabilities. The goal is to provide the consumer with the most efficient route to a requisite or satisfying purchase decision.
Furthermore, the platform may incorporate journey management capabilities to enable the consumer to change elements of a travel itinerary. It is often the case that changes must be made to one or more aspects of a purchased travel itinerary-driven, for example, by endogenous reasons (e.g., the change of travel plans of the consumer) or by exogenous factors (e.g., extreme weather).
Additionally, the platform may be consumer-centric in both the design of the platform and how the platform acts in the marketplace, thereby maximizing the efficiency of the travel-buying experience. The goal of the platform is to deliver maximal personal utility to the travel consumer; the platform is therefore “utility-centric,” as opposed to profit-centric.
Many of the core design elements and principles of the platform outlined above relate directly to how feasible travel requests can be identified and presented for consideration to the consumer. In this regard, the platform may tend to explore the manner in which choice is manifested within the platform. The more travel itinerary options that are presented to the consumer, the greater the chance that the consumer finds a travel itinerary that aligns with preferences of the consumer. Therefore, there is a tension between abundance of choice and choice burden for the consumer. At the same time, the presence of a plurality of options places a greater cognitive burden on the consumer, and this can lead to compromised decision quality and possibly sub-optimal outcomes. The cognitive burden may lie upon the consumer or a representative of the consumer, e.g., a travel agent creating a travel itinerary for a consumer. The platform may provide the balance between “richness of options” and “choice overload,” along with considering conflicting objectives and values (e.g., a desire for luxury constrained by willingness-to-pay).
The platform addresses, among others, the technical problem that user queries may be about anything, and not constrained within the travel domain. A related problem is on the search side: the many possible attributes of this open domain search need to be compressed to facilitate an efficient retrieval of relevant content within the target travel domain.
Thus, the platform has a choice architecture that pertains to how the choice task is structured, and how choice options are described or presented to the consumer. The choice architecture can be characterized by the following categories:
Logical/Rational Basis. The knowledge, information, and preferences that factor into the travel itinerary selection process can be structured and evaluated in a transparent and rationally consistent manner. The logical basis may formally include multiple attributes in order to allow for proper trade-off analysis.
Speed and Efficiency. The choice architecture can provide results and itinerary solutions within time-frames that are compatible with the OTA decision context (i.e., on the order of a few seconds). Information and analysis can be presented to the consumer in an efficient manner, minimizing search costs and conveying essential information in ways that enable rapid identification of minimal choice sets, from which final purchase decisions can be made.
Awareness of Cognitive Biases and Heuristics. Consumers are known to invoke a number of heuristics and biases in evaluating travel options. For example, consumers can often perform an initial screening of options on the basis of some subset of total product attributes (e.g., cost), and then make alternative-based comparisons on the basis of the remaining attributes after the initial screening. Within the travel space, it is also not uncommon to see consumers use attribute information (e.g., seat choice) to predict their en route or ex post satisfaction. The choice task for the average travel consumer can be, in fact, replete with cognitive biases. As consumers are often inclined to accept and use information in the form in which they receive it, the choice architecture of the platform may present information to the consumer in ways that minimize the adverse effects of cognitive biases that can adversely impact decision quality and consumer satisfaction.
Visualization Capabilities. It is important for consumers to be able to visualize the results of their travel queries in ways that ultimately maximize decisional efficiency. At a minimum, the visualization schemes may, when presenting two or more travel itinerary options, convey rank information as well as information concerning the cause of the rank. The platform is able to convey information about “performance” (namely, suitability of the travel itinerary based on customer preferences) vs. price by conveying maximal information to the consumer in an efficient and easy-to-understand manner. The interactive refinement and/or modification of travel search attributes is also a part of the decision aiding capabilities of the platform.
The travel related query 120 may be transmitted to the system 200 for facilitating travel reservations via a network 110. The network 110 may include the Internet or any other network capable of communicating data between devices. Suitable networks may include or interface with any one or more of, for instance, a local intranet, a Personal Area Network (PAN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a virtual private network, a storage area network, a frame relay connection, an Advanced Intelligent Network connection, a synchronous optical network connection, a digital T1, T3, E1 or E3 line, Digital Data Service connection, Digital Subscriber Line connection, an Ethernet connection, an Integrated Services Digital Network line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an Asynchronous Transfer Mode connection, or an Fiber Distributed Data Interface or Copper Distributed Data Interface connection. Furthermore, communications may also include links to any of a variety of wireless networks, including Wireless Application Protocol, General Packet Radio Service, Global System for Mobile Communication, Code Division Multiple Access or Time Division Multiple Access, cellular phone networks, Global Positioning System (GPS), cellular digital packet data, Research in Motion, Limited duplex paging network, Bluetooth radio, or an IEEE 802.11-based radio frequency network. The network 110 can further include or interface with any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a Universal Serial Bus (USB) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking. The network 110 may be a network of data processing nodes that are interconnected for the purpose of data communication. The network 110 may include any suitable number and type of devices (e.g., routers and switches) for forwarding commands, content, and/or web object requests from each client to the online community application and responses back to the clients.
The user device 140, in some example embodiments, may include a Graphical User Interface (GUI) for displaying the user interface associated with the system 200. In a typical GUI, instead of offering only text menus or requiring typed commands, the system 200 may present graphical icons, visual indicators, or special graphical elements called widgets that may be utilized to allow the user 130 to interact with the system 200. The user device 140 may be configured to utilize icons used in conjunction with text, labels, or text navigation to fully represent the information and actions available to the user 130.
The user device 140 may include a mobile telephone, a personal computer (PC), a laptop, a smart phone, a tablet PC, and so forth. The system 200 may be a server-based distributed application; thus it may include a central component residing on a server and one or more client applications residing on one or more user devices and communicating with the central component via the network 110. The user 130 may communicate with the system 200 via a client application available through the user device 140.
Travel itineraries available from the optional database 150 may be analyzed with reference to preferences of the user 130 and travel itineraries 160 suiting the preferences of the user 130 may be determined. Travel itineraries 160 may be presented to the user 130 by displaying travel itineraries 160 via the user interface on a screen of the user device 140.
The processor 210 may receive a travel related query. The travel related query may be provided by a user. Moreover, the travel related query may be provided using a natural language, a typed text, a selection of preexisting options, and so forth. Examples of typed text include an email, a Short Message Service (SMS) message, a Rich Communication Services (RCS) message, and a chat message. In a further embodiment, the travel-related query may be associated with a group of users. The processor 210 may ascertain an attribute set relevant to the travel related query. The attributes may include parameters of the itinerary, such as a flight, a hotel, an origin city, a destination city, a departure date, an arrival date, time, prices, travel class, and other attributes, such as ground transportation options, tours, and the like. Each attribute may have an option. For example, the options for the ‘hotel’ attribute may include ‘hotel 1’ in a destination city, ‘hotel 2’ in the destination city, and any other hotels that may satisfy the travel-related query.
The parser 220, being in communication with the processor 210, may be operable to parse the travel related query to derive attribute values related to the attribute set and at least one constraint related to the travel-related query. In some embodiments, a constraint may include a budgetary constraint, a logical constraint, a conditional constraint, a timing constraint, and the like. The parser 220 may be further operable to initiate the at least one attribute of the attribute set with the derived attribute values.
In an example embodiment, the at least one attribute with one possible value is a necessarily satisfied condition. In other words, the user may need to provide at least one attribute of the travel-related query.
Thereafter, the processor 210 may rank at least one attribute based on user preferences. The user preferences may be determined based on the travel related query. Additionally, the user preferences may be determined based on preexisting selections (for example, selections made by the user in a user profile associated with the system 200). The preexisting selections may be received from the user using a man-machine interface. Based on the ranking, the processor 210 may assign weights to the at least one attribute to create at least one weighted attribute. Thus, at least one weighted attribute may be created. The processor may also associate cost data with the at least one weighted attribute. Specifically, each specific weighted attribute may be associated with cost data related to this specific weighted attribute.
The scheduler 230 may be operable to search for the feasible travel itineraries based on the least one attribute and the user preferences. The scheduler 230 may score the feasible travel itineraries based on the at least one weighted attribute and the cost data associated with the at least one weighted attribute for each of the feasible travel itineraries.
Upon scoring the feasible travel itineraries, the processor 210 may present at least one travel itinerary selected from the feasible travel itineraries based on the scoring. The processor may also select an optimal travel itinerary based on the at least one constraint. Specifically, the optimal travel itinerary may be selected from the feasible travel itineraries based on the scoring of the feasible travel itineraries. Additionally, the at least one travel itinerary and corresponding scores may be visualized to the user. The optimal travel itinerary may be presented to the user via a user device.
In an example embodiment, the processor 210 may further be configured to rank the feasible travel itineraries based on the scoring and select one or more further optimal travel itineraries to be provided the user. The one or more further optimal travel itineraries may be selected from the feasible travel itineraries based on the ranking. In other words, one or more top feasible travel itineraries in a ranked list of feasible travel itineraries may be presented to the user.
In an example embodiment, the system may be configured to identify at least one of the feasible travel itineraries for which a budget allocation is unutilized. The budget allocation may be associated with the at least one constraint. Specifically, the budget allocation may include a cost of the itinerary indicated by the user in the travel-related query. In other words, the at least one of the feasible travel itineraries the cost of which is lower than the cost of the itinerary indicated by the user may be identified. The system 200 may further be configured to present the at least one of the feasible travel itineraries for which the budget allocation is unutilized to the user.
The optional database 240 may be configured to store at least data related to the travel related query, the user preferences, and so forth.
Thus, the system 200 may be operable to customize, for each individual traveler, how travel itinerary options are identified and presented for purchase consideration. Furthermore, the choices, namely the travel itineraries, may be presented to the user in ways that minimize search cost and maximize path-to-purchase efficiency.
The method 300 may continue with ascertaining an attribute set relevant to the travel related query and at least one constraint related to the travel-related query at operation 304. At operation 306, the method may include parsing the travel related query to derive attribute values related to the attribute set. In some embodiments, a constraint may include a budgetary constraint, a logical constraint, a conditional constraint, a timing constraint, and the like. In an example embodiment, a plurality of attributes, i.e., an attribute set relevant to the travel-related query, may be derived. The attributes may include parameters of the itinerary, such as a flight, a hotel, an origin city, a destination city, a departure date, an arrival date, time, prices, travel class, and other attributes, such as ground transportation options, tours, and the like. Each attribute may have an option. For example, the options for the ‘hotel’ attribute may include ‘hotel 1’ in a destination city, ‘hotel 2’ in the destination city, and any other hotels that may satisfy the travel-related query.
In an example embodiment, the at least one attribute with one possible value is a necessarily satisfied condition. In other words, the user may need to provide at least one attribute of the travel-related query.
Upon the parsing, at least one attribute of the attribute set may be initiated with the derived attribute values at operation 306. In an example embodiment, the at least one attribute with one possible value is a necessarily satisfied condition.
At operation 308, the at least one attribute may be ranked based on user preferences. In an example embodiment, the user preferences may be determined based on the travel related query. In another example embodiment, the user preferences may be determined based on preexisting selections.
The method 300 may optionally comprise providing a man-machine interface to receive the preexisting selections from a user. More specifically, the method 300 may include a front-end instantiation of user preferences, where the user preferences are obtained by parsing the semantic intent underlying the travel related query. The method 300 may further include a back-end specification of the user preferences by reading user-specified rank-order preference information (i.e., the preexisting selections) from a database (for example, the preference information related to airlines, hotels, etc.).
The method 300 may continue with operation 310, at which weights may be assigned to the at least one attribute based on the ranking. Thus, at least one weighted attribute may be created.
At operation 312, the method 300 may include searching for feasible travel itineraries based on the least one attribute and the user preferences. Upon the search, the feasible travel itineraries may be scored at operation 314. The scoring may be based on the at least one weighted attribute and the cost data associated with the at least one weighted attribute for each of the feasible travel itineraries. In example embodiments, the method 300 may optionally include adjusting the scoring based on forecasted weather conditions at a time of travel.
Upon scoring, the method 300 may continue with operation 316, at which at least one travel itinerary selected from the feasible travel itineraries based on the scoring may be presented. An optimal travel itinerary may be selected from the feasible travel itineraries based on the at least one constraint at operation 316. Specifically, the optimal travel itinerary may be selected from the feasible travel itineraries based on the scoring of the feasible travel itineraries. In example embodiments, the presenting of the at least one travel itinerary may be performed within a predetermined time after the receiving of the travel related query. The method 300 may further optionally include visualizing the at least one travel itinerary and corresponding scores.
In an example embodiment, the method 300 may further include ranking the feasible travel itineraries based on the scoring and selecting one or more further optimal travel itineraries to be provided the user. The one or more further optimal travel itineraries may be selected from the feasible travel itineraries based on the ranking. In other words, one or more top feasible travel itineraries in a ranked list of feasible travel itineraries may be presented to the user.
In an example embodiment, the method 300 may include identifying at least one of the feasible travel itineraries for which a budget allocation is unutilized. The budget allocation may be associated with the at least one constraint. The constraint regarding budget allocation may be specified, for example, in a corporate travel policy associated with the user 130. Specifically, the budget allocation may include a cost of the itinerary indicated by the user in the travel-related query. In other words, the at least one of the feasible travel itineraries the cost of which is lower than the cost of the itinerary indicated by the user may be identified. The method 300 may further include presenting the at least one of the feasible travel itineraries for which the budget allocation is unutilized to the user.
The method 300 may be directed to determining how the utility, or value, the consumer derives from a given travel itinerary is characterized and evaluated. This utility may be derived from the defining elements of each travel itinerary (e.g., flight characteristics, such as class of service, etc.). Thus, the method 300 may be used for prioritizing and ranking itinerary options.
The operations of the method 300 and elements of the system 200 are further described in detail below.
In an example embodiment, a typical consumer may construct an itinerary portfolio, also referred herein to as a travel itinerary portfolio, by constructing sets of choices using the system 200. Specifically, the itinerary portfolio may include a set of attributes of the travel itinerary. The process of constructing the itinerary portfolio using the system 200 may consist of the steps of (i) specification of the individual choice sets that correspond to the desired and/or relevant attributes of the itinerary; (ii) multiattribute valuation and costing of individual choice set options; and (iii) specification of relevant constraints. Completing this set of steps may provide a numerically specified itinerary portfolio, which may be amenable to numerical evaluation and analysis. In possession of the enumerated itinerary portfolio, the system 200 may identify itinerary portfolio allocations, i.e., a specific combination of choices across all of the attributes contained in a given portfolio with one option selected from each choice set, that maximize a value of the itinerary portfolio value for a specified constraint of the customer, such as a budget. The value of the itinerary portfolio may include a multiattribute score related to the travel itinerary and determined by scoring feasible travel itineraries based on the weighted attributes of the travel itinerary and the cost data associated with each of the weighted attributes.
In an example embodiment, a typical company may construct a corporate travel policy in a manner similar to how a typical consumer would construct an itinerary portfolio, by constructing sets of choices using the system 200.
Specification of Relevant Attribute Sets
The system for facilitating travel reservations may support a travel lexicon to accommodate and fulfill a wide range of possible travel related query. Therefore, within the system, the travel related queries can be expressed via natural language (typed or spoken). The system may be operable to support basic travel queries, Q, which take the form of
Q={qs,qd,qt}, where
qs≡starting point (airport, city, etc.); qd≡final destination; qt≡duration of trip.
Each travel query, Q can be contextualized or made more specific via attributes that are instantiated via the travel related query in natural language. Accordingly, the system may be operable to identify and specify attribute sets that are relevant to the travel related query (which, in fact, relates to goals and objectives expressed by the user in the travel related query). It is possible to reason about whether the goals and objectives are met in terms of attribute values. In the context of a travel itinerary, attribute values may include the desire for an aisle seat, a non-stop flight, and the like. Therefore, the system can be used to find a means by which it is possible to reason whether the travel itinerary is capable of providing specified attribute values.
Therefore, the processor of the system is operable to define relevant attribute sets (RAS) that are linked/tied to context-defining attribute values specified in the given travel query, Q. The attribute sets may pertain, specifically, to flights (F), hotels (H), and origin (O) and destination (D), and may be defined as follows:
RAS(Q,F)={f∈F|isRelevant_Flights(f,Q)=true};
RAS(Q,H)={h∈H|isRelevant_Hotels(h,Q)=true};
RAS(Q,O)={o∈O|isRelevant_O&D(o,Q)=true}.
In the characterization above, isRelevant_Flights is a logical predicate that asserts that attribute f is relevant for travel related attribute values specifiable in the travel related query, Q. Similar interpretations hold for the predicates isRelevant_Hotels and isRelevant_O&D.
Thus, the relevant attribute sets may be specified for flights, hotels, and origin and destination (O&D), respectively. For example, the RAS for Flights, RAS(Q, F), covers five attributes that may be supported within the travel lexicon of the parser of the system. These attributes, and their possible values, are shown in table 1 below.
The RAS for hotels, RAS(Q, H), are shown in table 2 below and may include five attributes that are typically encountered in hotel searches.
Finally, the RAS for O&D, RAS(Q,O), is shown in table 3 below and may enable the consumer to specify a country, city, city code, or airport code in a given travel request.
Parser-Enabled Instantiation of Attributes
As mentioned above, the capabilities of the system can be utilized to contextualize and add specificity to travel related requests, thereby enabling the consumer to explicitly specify sought after or desired attribute values. The RASs defined above make it possible to operationalize the “front-end” and “back-end” integration discussed above. In this regard, it may be explored what this front-end portion means for any set of the attributes contained in each RAS to be activated or instantiated within the context of a given travel related query, Q.
Generally speaking, the fulfillment of a travel related query may require the instantiation of one or more attributes. These instantiated attributes enable adding context or specificity to the travel related query. For this purpose, the Cartesian product, Z, of three relevant attribute sets may be defined:
Z=F×H×O,
which, given the specifications for F, H, and O, above, gives rise to the following ordered n-tuple:
z=(f1,f2,f3,f4,f5,h1,h2,h3,h4,h5,o1,o2,o3,o4). (1)
If vector notation is used and if F=[f1, f2, f3, f4, f5], H=[h1, h2, h3, h4, h5], and O=[o1, o2, o3, o4], then Equation (1) can be expressed succinctly as follows:
Z=[F,H,O]. (2)
In the context of a given travel related query, Q, Equations (1) and (2) can be used for representing those attributes that are instantiated within the travel related query. Some of the travel attributes may be instantiated on a continuing basis, in that the attributes may represent characteristic features of any feasible travel itinerary (e.g., every travel itinerary containing flights can be characterized by one or more air carriers, and so forth).
For the purpose of this disclosure, it can be assumed that instantiability is binary-valued. The space of all possible instantiations of the attributes is of order 2n=214, and is defined as the cross product of the binary-valued state space associated with each individual attribute.
This scheme describes which travel attributes matter to the consumer. In general, the more attributes that are ascertained, the more specific the travel related query is. Therefore, the travel related query may be assumed to be closed with respect to a given RAS and a given query, Q, if all the attributes contained within the set of attributes are instantiated. Conversely, the travel related query may be assumed to be open if only a partial (possibly empty) subset of travel attributes is ascertained.
Further, let Z(Q) denote a query-driven set of ascertained attributes, and ‘*’ denote those attributes that are non-ascertained. Therefore, a query-driven set of the ascertained attributes may be represented as follows:
Z(Q)=(f1,f2,*,*,f5;h1,*,*,h4,*;*,*,*,o4). (3)
In Equation (3), query Q ascertains three of our travel related attributes: f1, f2, and f5 (i.e., the natural language request specifies user preferences pertaining to ‘Carrier,’ ‘Number of Stops,’ ‘Class of Service,’ and ‘Desired Departure Time’). The query Q also ascertains hotel-related attributes pertaining to ‘Hotel Chains’ and ‘Bed Type,’ together with the origin and destination attribute pertaining to ‘Airport Codes.’ Therefore, for the travel related attributes, Equation (3) is open with respect to attributes 3 and 4; for the hotel attributes, Z(Q) is open with respect to attributes 2 and 3; and for the origin and destination attributes, the travel related query is open with respect to attributes 1, 2, and 3.
Identification and Specification of Individual Choice Sets
In a travel-specific example, a consumer, who is a business traveler, plans to travel by himself on a two-day/one-night trip that has one destination. The following six itinerary portfolio groups, i.e., attributes of the travel-related query, are deemed as most relevant to the travel planning process of the consumer:
The system 200 may specify the choice sets that correspond to each of these itinerary portfolio groups.
Let A denote the set of ground transportation options that the consumer wishes to consider for getting from the consumer from home to the origin airport:
A={a1,a2,a3,a4},
where
Let B denote the set of outbound flight options that the consumer wishes to consider:
B={b1,b2,b3,b4,b5},
where
Let C denote the set of options that the consumer wishes to consider as ground transportation alternatives at her destination city:
C={c1,c2,C3},
where
Let D denote the set of hotel accommodation options that the consumer wishes to consider at her destination city:
D={d1,d2,d3,d4},
where
Let E denote the set of return flight options that the consumer wishes to consider:
E={e1,e2,e3,e4,e5},
where
Finally, let F denote the set of ground transportation options that the consumer wishes to consider for her return home from the airport:
F={f1,f2,f3,f4},
where
The system further utilizes the RASs specified above to associate a determinate value with each travel itinerary as a function of the ascertained attributes that are associated with a given travel related query. In this way, each feasible itinerary may be characterized in terms of a single, aggregate (dimensionless) value, which may be used to prioritize and rank itinerary attributes.
The key elements for performing prioritizing and ranking may include: a finite number of travel itineraries, ; a finite number of attributes, I; a weight, wi, for each attribute i∈I; a value score for each attribute and itinerary, νi(a), for itinerary a∈
and attribute i∈I; and total value, V, of itinerary a∈
defined as the weighted sum
Σiwiνi(a).
Alternatively, using the vector notation introduced earlier, the total value of an itinerary choice set is succinctly expressed as
V(F,H,O)=Σwν(·),
where w denotes vector tradeoff weights for F, H, O. For ease of analysis and exposition, it is convenient to also assume that
∀i∈I,wi≥0 and Σiwi=1;
∀α∈ and i∈I,νi(a)∈[0,1], and for each i∈
, there are a′,a″∈
νi(a′)=1 and νi(a″)=0;
The next step is to integrate front-end attribute ascertaining and back-end-specified consumer preferences. This may require some mathematical preliminaries described below.
Mathematical Preliminaries
As discussed earlier, it is necessary to take into consideration the relationship between a “front-end” of the system (where parser-enabled attribute instantiations occur) and a “back-end” of the system (where consumers provide profile information that contains preference information). For this purpose, permutations on lexicographically ordered finite sets can be used, where each permutation contains information pertaining to the rank-order preferences of the consumer (for example, for airlines, hotels, and the like).
The back-end-specified rank-order preference information can be utilized to impute numerical values which serve as the primary means by which numeric specifications for the value functions may be determined: vi(a).
The concept of a permutation can enable explicitly referencing/indexing rank-order preference data obtained via “user profiles” on the back-end of the system. For this purpose, let S denote a finite set consisting of n elements:
S={x1,x2, . . . ,xn}.
For ease of exposition and analysis, the restriction can be imposed that the elements of S are lexicographically ordered such that
x1≤x2≤ . . . ≤xn.
The kind of permutation, n, is a bijection, i.e., a one-to-one and onto function from S onto itself:
π:S→S.
Example 1. Let S={x1, x2, x3, x4, x5}, with the following illustrative graph of π: π(x1)=x2, π(x2)=x3, π(x3)=x1, π(x4)=x5, and π(x5)=x4. This permutation can be expressed in matrix form as
If the lexical order described above is treated as fixed, the permutation can be expressed in its simpler Cartesian form:
π=[x2,x3,x1,x5,x4]. (5)
Example 2. As a travel-specific example, there are the following 5 airlines, listed in alphabetical order in table 4:
The consumer may provide the following rank-order preference information for this set of airlines:
Virgin America>Southwest>United>American>Jet Blue.
This preference ordering can be representable by:
π=[5,3,4,1,2] (6)
This example can be generalized to an arbitrary n:
π=[i1,i2, . . . ,in], (7)
where π∈Sn and π(x1)=xi
Imputation of Marginal Value Functions via Rank-Ordered Preferences
Equation (7) can be utilized to encode preference information concerning air carriers, hotels, and the like. As described below, each permutation vector is used to impute numerical weights of relative importance or value for these vector elements. For the purposes of this disclosure, two numerical approaches can be utilized, namely rank sum and rank reciprocal.
Rank Sum (RS). N attributes or lexicographically ordered elements are ranked, and each attribute is weighted according to the formula,
where ri is the rank position of the attribute or element.
Rank Reciprocal (RR). Weights are derived from the normalized reciprocals of a rank of the attribute or element:
Example 3. Applying Equations (7), (8), and (9) to the airline of Example 2 yields the numerical values shown in table 5 below.
Indexing the Multiattribute Value Model
Within the context of a given travel related query, only the attributes that are instantiated are taken into consideration. Therefore, the instantiated attributes need to be indexed. To this end, a travel related query, Q, gives rise to a vector Z(Q) of instantiated attributes. For example, the travel related query, Q, generates the following attribute instantiations:
(f1,f2,*,*,f5;h1,*,*,h4,*;*,*,*,o4),
in which case
Z(Q)=(f1,f2,f5;h1,h4,o4). (10)
From Equation (10), three index sets can be extracted, which enable indexing multiattribute aggregation model:
IF={1,2,5}
IR={1,4}
IO={4}.
In more general terms, the index sets illustrated above can be defined as follows:
IF={i|i∈F and fi∈Z(Q)=true}; (11)
IH={j|j∈H and hj∈Z(Q)=true}; (12)
IO={k|k∈O and ok∈Z(Q)=true}. (13)
Having properly indexed the instantiated attributes that the travel related query, Q, gives rise to, the multiattribute aggregation model described earlier can be specified in the specialized form that its application here requires:
The linear additive nature of Equation (14) enables using the portions of the aggregation model that are required by the travel related query, Q. For example, the travel related query that only requests a flight itinerary will utilize only the first of the three summations shown in Equation (14).
The numerical specification of Equation (14) is essentially a two-step process and includes a specification of the relevant single attribute value functions νfi(·), νhj(·), and νok(·), and a specification of the (scaling) weights wi, wj, and wk. Each of these elements can be considered in turn.
Specification of Single-Attribute Value Functions—Flights
In specifying the single-attribute value functions, νfi(·) associated with flights, there is reason to presume the existence of a set, , offeasible itinerary solutions (FISs), comprised of elements a1, a2, . . . , am. In the case of a travel related query, each travel itinerary ai ∈
is evaluated on attributes F1, . . . , Fm and a marginal value function, νj(fij), on the performance fij of the travel itinerary ai under attribute Fj. Each of these five travel related attributes is considered below.
Carrier (F1). This attribute captures the preferences of the consumer related to an airline carrier. In the context of travel related queries, this attribute exists on a continuous basis, in the sense that every itinerary that involves air travel is characterized by a determinate carrier value.
In formally characterizing this attribute, it is distinguished between two types of travel related requests: those where the consumer expresses an explicit, named preference for one or more airlines (e.g., “Please show me all of the United flights from IAD to SFO for Friday”; “Can I see what Virgin or American flights I can take next Monday to London?”, etc.) and those where no such preference is expressed. From a consumer choice perspective, the request for a specific carrier (or set of carriers) acts as a filter: if the scheduler is able to return one or more feasible solutions that satisfy the travel related query, then those travel itinerary options are presented to the consumer for consideration, and the multiattribute value model is invoked only if other travel related attributes in RAS(Q, F) have been instantiated.
In all other instances involving travel related queries, each feasible itinerary solution ai∈ must be evaluated on attribute F1. To this end, the marginal value function ν1(fi1) needs to be characterized and evaluated on the performance fi1 of itinerary ai∈
under this attribute. Equation (14) serves as the basis for a numeric scheme that enables the single-attributed scoring of each feasible itinerary solution yielded by the Scheduler, as measured by the Carrier attribute.
Since the number of carriers is finite, it can be assumed that F1 is characterized by a finite domain DF1. Numeric characterization of the marginal value function can proceed along several possible lines. It is possible to envision systematic attempts at the elicitation of consumer preferences regarding air carriers. Alternatively, it is also possible to envision schemes whereby these carrier preferences are learned over time in a systematic manner. The approach adopted herein exploits the existence of stated preference information provided on the back-end of the system. This information takes the form of rank-order preference data concerning air carriers, and this data is used, in conjunction with the RS and RR equations described earlier, to arrive at a numeric characterization for ν1(fi1).
Furthermore, the existence of a set, C, consisting of a lexically-ordered set of air carriers is presumed:
C={C1,C2, . . . ,Cn}.
Given this set, the existence of a permutation vector, nc, is presumed, and the vector encodes rank-order preference information for the air carriers contained in C:
IIc=[πc1, . . . ,πcn].
Equation (8) can now be re-written as follows:
which provides a rank-order-derived importance weight, wc
Further, each travel itinerary ={a1, . . . , a2} is scored on attribute F1. It is assumed that each travel related itinerary ai∈
is characterized by a determinate carrier value xijh=xij1=ci{circumflex over (∈)}C, where i indexes travel itineraries (i.e., i=1, . . . , m), j indexes carriers (i.e., j=1, . . . , n), and k indexes the instantiated (ascertained) attributes. Given this domain characterization, the marginal value function can be characterized as follows:
where
is the rank-order-derived weight, obtained via Equation (15), associated with carrier πcj, j=1, . . . , n.
Number of Stops (F2). When instantiated, this attribute captures the consumer preferences for the number of leg segments contained within a given Origin and Destination city pair. Generally speaking, most travelers prefer less stops to more, but often this convenience comes at a cost (i.e., it increases the cost associated with an itinerary). For the purposes of this disclosure, this attribute is modeled as a constructed attribute, defined in terms of three attribute levels shown in table 6:
The baseline parameterization for the single-attribute value function, ν2(·), is given as follows:
ν2(0)=1
ν2(1)=0.7
ν2(2)=0.
Class of Service (F3). This attribute captures the consumer preferences for the specific classes of service offered by most airlines. When this variable is instantiated, the user is expressing a preference for a particular class of service. In looking, then, to measure the contribution to overall value that the instantiation of this attribute has on the overall value of a given itinerary, it is necessary to capture the conditional nature of this marginal value proposition. For this purpose, an “Ask/Get” matrix can be used, which, for the purposes of this disclosure, is defined as shown in table 7:
In Table 7, the column entries contained in quotes (“Economy,” “Econ.-Refundable,” “Bus.-Restricted,” “Bus.-Unrestricted”) denote the actual consumer-provided travel related query, whereas the row entries denote the class of service associated with a given itinerary, ai∈. If, for example, the consumer asks for a “Business-Restricted” ticket, but the feasible itinerary choice is an Economy-Refundable ticket, then that itinerary is assigned a weight of 0.4.
Equipment (F4). This attribute becomes instantiated when the consumer expresses an explicit equipment-related preference. The consumer may, for example, request a wide-body plane (e.g., an A380, A340, etc.). Within the parser, such travel related query can be invoked at various levels of aggregation, e.g., body type, model type, and so forth. For ease of analysis, ν4(·) is characterized an indicator variable, where a travel related query, Q, containing a specific equipment-related request gives rise to one or more travel itinerary options that either succeed or fail to satisfy the equipment request. Accordingly, the weight function is formally specified as follows:
where DesiredEquipment is a logical predicate that returns a truth-value obtained via look-up tables (may be stored in the database) that define the relevant set of equivalence classes. For the purposes of this disclosure, for the wide/narrow body distinctions, the basic taxonomy supported within the parser is shown in table 8 below.
For example, if the consumer requests, within a given query, a wide-body plane, and a travel itinerary contains any of the jets listed in the first column of table 8 above, then the weight function is assigned a value of 1; otherwise it is assigned a zero.
Desired Departure/Arrival Time (F5). Time factors into the travel plans and desires of most consumers. For example, typical requests may include the following: “I need to be in Los Angeles first thing Monday morning for a meeting”; “For my trip to New York, I'd like to arrive in New York in time to have dinner with Jonathan,” and the like. The system has the ability to include attributes that allow capturing and representing these kinds of time-related preferences. Accordingly, two attributes that capture/represent preferences pertaining to desired departure and arrival times, respectively, can be used.
In the first of these two instances, preferences pertaining to a desired departure time (DDT) of consumer need to be captured. When instantiated, the DDT can be expressed precisely as a time of day (12- or 24-hour format), or as a time-period (e.g., “morning,” “afternoon,” “evening,” or other possible sub-categories within these general categorizations). In practical terms, the marginal value function, ν5(xj), focuses on the relative duration of period between the departure time associated with the outbound flight (OF) associated with itinerary ai∈, and the stated DDT.
The preference levels associated with xi can be specified in any number of ways. For the purposes of this disclosure, the following four attribute levels are specified in table 9:
is within 1 hour of the DDT;
, 1-hr < |DDT − OFi| < 2-hrs;
, |DDT − OFi| > 2-hrs.
This value function can be parameterized as follows:
ν5(0)=0
ν5(1)=0.9
ν5(2)=0.7
ν5(3)=0.4.
Furthermore, travel related queries that specify a desired arrival time (DAT) may be considered. In defining this attribute, as before, a constructed scale that measures the duration of period between the DAT of the consumer and the arrival time of a destination leg/flight (DF) of the travel itinerary is shown in table 10:
is within 1 hour of the DAT;
, 1-hr <| DAT − DFi| < 2-hrs;
, |DAT − DFi| > 2-hrs.
This value function can be parameterized as follows:
ν5(0)=0
ν5(1)=0.9
ν5(3)=0.4.
Specification of Single-Attribute Value Functions—Hotels
The other attributes may include Hotel Chain, Star Rating, Smoking Preference, Bed Type, and the like.
For the Hotel Chain attribute (h1), the indicator variable may be stated as follows:
For the Star Rating attribute (h2), the indicator variable may be stated as follows:
{0,1,2,3,4,5,6,7}.
For the Smoking Preference attribute (h3), the indicator variable may be stated as follows:
For the Bed Type attribute (h4), the Ask/Get Matrix may be used as discussed above.
The Hotel Name attribute (h5) may be instantiated when the consumer mentions a hotel by name. If the hotel is available, the attribute has utility; if the hotel is unavailable, then the attribute has little or no utility.
Other Single-Attribute Value Functions relating to Origin and Destination may include country (o1), city (o2), city code (o3), airport code (o4), and so forth.
Numerical Case Study. Case: Flights-Only Itineraries
In an example embodiment, a travel related query, Q, is passed through the analytic framework of the system specified above. The travel related query may read as follows: “Roy and Jonathan want to travel non-stop from Toronto to Seattle on March 21st; we want business class seats, if possible; if possible, it would be nice to get there early enough in the evening to have dinner at Daniel's Broiler in Bellevue; as always, we prefer a wide-body plane.”
The travel related query instantiates the following flight attributes: F1 (since a flight itinerary is desired), F2 (since a non-stop flight is desired), F3 (since business class seats are desired), F4 (since a wide-body plane is preferred), and F5 (since a desired arrival time—“Supper”=“Evening”—is specified). Therefore, this travel related query is closed under F, and, via Equation (7), gives rise to the following index set:
IF={1,2,3,4,5}.
At least one of the travelers (for example, Roy) may preliminarily create, on the back-end of the system, a user profile that contains personal rank-order preferences of the traveler for air carriers. Therefore, airline preferences of this traveler may be captured. Furthermore, the traveler may also preliminarily provide the rank-order preference information regarding the travel related attributes. Given this set of rankings, it may be determined that, when evaluating travel itinerary selection, the traveler assigns highest importance to obtaining a desired cabin class, followed by trip duration. Using these rank-order preferences, Equation (15) can be used to impute the RS weights shown below in table 11:
The scheduler may factor the preferences of the traveler into the search performed by the scheduler.
The scheduler may return a result to the traveler. The result of the search is shown on
Look-up tables stored in a database may be used to determine that the wide-body plane request is not satisfied in either of the travel itinerary 602 and the travel itinerary 604, and that the instantiated DAT is satisfied in the travel itinerary 602, but not in the travel itinerary 604.
Multiattribute Valuation and Costing of Options
The system 200 may assign determinate multiattribute scores to the individual choice set options described above along with providing determinate cost estimates for each option.
Choice Set A. Among the four options that the consumer considers within this particular choice set, the subway options is by far the cheapest, but provides the consumer the least utility, owing mainly to its lack of convenience, the need to allow for additional time to get to the subway station, and the fact that the consumer need to physically carry the luggage to the subway station. The Uber option is preferred over the taxi option, due mainly to cost and convenience considerations. Finally, the Uber-Black option is the priciest option, but it provides the consumer the greatest level of utility, due mainly to the tangible benefits that the consumer derives from the luggage handling and the overall level of service. These preferences and judgements are represented numerically in the vector shown below, together with the relevant cost data associated with the options considered in this choice set:
A: [(0.3;$4:50);(0.6;$30);(0.45;$37);(0.9;$47)];
where each ordered pair contains the aggregate multiattribute score and the determinate cost value, respectively, for each ai∈A, for i=1, . . . , 4. A similar notation is used for the choice set values described below.
Choice Set B. The measurable value function used for this decision category follows a fairly linear progression in its treatment of performance vs. price:
B: [(0.2;$299);(0.45;$450);(0.6;$535);(0.7;$600);(0.95;$800)].
Choice Set C. In valuing the options contained in this choice set, the consumer appraises the tradeoffs between benefit versus cost. Looking at the three options contained in this choice set, the consumer may note that the taxi is almost always readily available in the city the consumer is traveling to, but is, on average, slightly more expensive than using Uber. This latter option, though, may typically entail a wait time of some (unknown) duration, and may sometimes even require the consumer to meet the driver at a convenient intersection. The rental car option has some attraction, but also comes with hassles for the consumer, for example, picking up and dropping-off the rental vehicle near the airport, as well as the additional cost and hassle of finding public parking, etc.:
C: [(0.3;$300);(0.6;$280);(0.75;$373)].
Choice Set D. The measurable value function used here is, for the most part, linear in its treatment of performance versus price. For option da, however, the value function captures the fact that the price savings inherent to this option come with a specific risk, namely, the consumer lacks first-hand familiarity with this particular hotel property, and therefore values that option slightly less than its “known” counterpart:
D: [(0.3;$350);(0.6;$475);(0.56;$425);(0.9;$550)].
Choice Set E. The measurable value function of choice set E is similar to the one used for choice set B, but, nevertheless, admits the possibility that differences may exist for the preferences of the consumer concerning outbound versus return flight itineraries. Accordingly, for this example, the higher performing options are scored higher than they were for choice set B, owing to the fact that the consumer envisions being tired after meetings of the consumer, and is likely to value the higher level of service more than in the case of the outbound flight:
E: [(0.1;$299);(0.45;$450);(0.7;$535);(0.8;$600);(0.95;$800)].
Choice Set F. Similar to the situation described above for choice set E, the consumer envisions that a state of mind of the consumer may be such that lower performing options are less desirable to the consumer in the latter portion of the trip than they were for the outbound portion. Similarly, the taxi option is also valued less than before, in anticipation of possibly long lines and/or wait times for a taxi in the late evening of the anticipated arrival of the consumer back home:
F: [(0.2;$4:50);(0.65;$30);(0.3;$37);(0.9;$47)].
Specification of Constraints—Budgetary and Otherwise
In the travel-specific example above, budget may be the constraint with which the consumer is most concerned. The total budgeted amount for the purchase of an entire travel itinerary is denoted by C. C can be constructed as the sum total of r individually specified budget constraints, where r is the total number of decision groups under consideration by the consumer. Another type of constraint is how each individual portfolio group is treated within the overall context of an itinerary portfolio evaluation. In the travel-specific example above, it can be assumed that the consumer selects one (and only one) option from the constructed choice set associated with each portfolio group. In other embodiments, this assumption can be relaxed to make such choices optional (for example, the system 200 may dictate that an option from a given portfolio group is included in a feasible portfolio allocation if its inclusion maximizes the objective function of the consumer and the option satisfies all of the relevant and/or specified constraints). In another embodiment, the constraints imposed can be made explicitly conditional, so that a given option (or a set of options) may be only selected if certain logical conditions are met. For example, the consumer may consider the purchase of a spa package, which is only available for purchase if the consumer stays at a particular hotel. Such conditions can take many forms, e.g., either- or constraints, K-out-of-N constraints, and so forth.
Itinerary Portfolio Evaluation—Optimization Approach
Having fully specified and enumerated the itinerary portfolio, the system 200 can numerically evaluate the portfolio to explore the prescriptive implications of the itinerary portfolio evaluation. The system 200 can structure the numerically evaluated portfolio in a visual representation, such as in
Using the itinerary decision space of
The system 200 may analyze the specified set of values yielding the following optimal portfolio allocation:
(a4;b1;c3;d4;e3;f4).
This particular portfolio allocation yields an itinerary portfolio value of 4.35, for a total cost to the consumer of $1,853—just shy of the $1,900 budget constraint specified by the consumer.
In another example embodiment, the consumer may wonder how changes in the available budget may affect the itinerary prescriptions for the trip of the consumer. The system 200 may iteratively analyze itineraries across a range of possible budget constraints and identify an optimal itinerary at each constraint. For example, the consumer may wish to consider a finite set of possible budget constraints, ranging from $1,300 to $2,800, in increments of $100. The optimal itinerary portfolio allocations derived by the system 200 from the iterative process are shown in Table 12:
Table 12 provides a basis for bringing value-for-money considerations into decision making calculus concerning the selection of itinerary elements. For each specified budget constraint, the feasible itinerary portfolio allocation is Pareto efficient, in the sense that (i) for each itinerary portfolio, there does not exist a better performing portfolio for less cost; and (ii) for each $100 incremental addition to the budget constraint, the prescribed itinerary portfolio allocation represents the best possible use of additional capital.
Both Table 12 and
The system 200 may utilize integer programming (IP) to optimize travel itineraries. iPs represent a broad class of constrained optimization problems where some or all of the variables are integers, and where the objective function and constraints are typically linear. In some embodiments, knapsack problem (KP) models or multiple choice knapsack problem (MCKP) models, which are specific classes of IPs, are utilized within the system.
An MCKP model used within the system 200 is formally stated as follows:
where the itinerary portfolio is assumed to consist of K categories or groups. Associated with each category t, where t∈K={1, 2, . . . , K}, is a choice set that consists of nt options. In this model, exactly one option is selected from each choice set. In some embodiments, exactly one option is required to be selected from each choice set. The cost and the multiattribute score associated with each option j, j∈S={1, 2, . . . , ni}, in category t, are assessed as ctj and btj, respectively. The total budget to be allocated across all K categories is capped by a fixed, determinate allocation, d. Finally, the decision variables in the model are defined as xtj=1, if option j (j∈St), in choice set t (t∈K), is selected, or as xtj=0, otherwise.
Equation (16) computes the overall value of a given itinerary portfolio allocation (a value to be maximized); Equation (17) represents a constraint commonly referred to as the resource constraint or budget constraint. The constraints that are given by Equation (18) are commonly referred to as the multiple choice constraints. Finally, consistent with the previous usage and overall formulation, sets St, t∈K, shall be referred to as the choice sets that collectively comprise a given itinerary portfolio.
The example computer system 1000 includes a processor or multiple processors 1002, a hard disk drive 1004, a main memory 1006, and a static memory 1008, which communicate with each other via a bus 1010. The computer system 1000 may also include a network interface device 1012. The hard disk drive 1004 may include a computer-readable medium 1020, which stores one or more sets of instructions 1022 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1022 can also reside, completely or at least partially, within the main memory 1006 and/or within the processors 1002 during execution thereof by the computer system 1000. The main memory 1006 and the processors 1002 also constitute machine-readable media.
While the computer-readable medium 1020 is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such a set of instructions. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media. Such media can also include, without limitation, hard disks, floppy disks, NAND or NOR flash memory, digital video disks, Random Access Memory (RAM), Read-Only Memory (ROM), and the like.
The exemplary embodiments described herein can be implemented in an operating environment comprising computer-executable instructions (e.g., software) installed on a computer, in hardware, or in a combination of software and hardware. The computer-executable instructions can be written in a computer programming language or can be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interfaces to a variety of operating systems.
In some embodiments, the computer system 1000 may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computer system 1000 may itself include a cloud-based computing environment, where the functionalities of the computer system 1000 are executed in a distributed fashion. Thus, the computer system 1000, when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below.
In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners, or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.
The cloud may be formed, for example, by a network of web servers that comprise a plurality of computing devices, such as a client device, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource consumers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.
It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire, and fiber optics, among others, including the wires that comprise one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk, any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a Programmable Read-Only Memory, an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory, a FlashEPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or a WAN, or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The corresponding structures, materials, acts, and equivalents of all means or steps plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.
Aspects of the present technology are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
Thus, computer-implemented methods and systems for facilitating travel reservations are described. Although embodiments have been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes can be made to these exemplary embodiments without departing from the broader spirit and scope of the present application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
The present utility patent application is related to and a continuation-in-part of U.S. patent application Ser. No. 14/750,841 filed Jun. 25, 2015, and U.S. patent application Ser. No. 16/142,834 filed Sep. 26, 2018, which claims the priority benefit under 35 U.S.C. 119(e) of U.S. Provisional Application No. 62/574,533, filed on Oct. 19, 2017, and titled “ITINERARY PORTFOLIO EVALUATION TOOL.” The disclosure of these related non-provisional and provisional applications is incorporated herein by reference for all purposes to the extent that such subject matter is not inconsistent herewith or limiting hereof.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5021953 | Webber | Jun 1991 | A |
| 5557524 | Maki | Sep 1996 | A |
| 5797127 | Walker et al. | Aug 1998 | A |
| 5832452 | Schneider et al. | Nov 1998 | A |
| 5948040 | DeLorme et al. | Sep 1999 | A |
| 6059724 | Campell et al. | May 2000 | A |
| 6275808 | DeMarcken | Aug 2001 | B1 |
| 6307572 | DeMarcken et al. | Oct 2001 | B1 |
| 6477520 | Malaviya et al. | Nov 2002 | B1 |
| 6553310 | Lopke | Apr 2003 | B1 |
| 6795710 | Creemer | Sep 2004 | B1 |
| 7092892 | Sobalvarro et al. | Aug 2006 | B1 |
| 7181438 | Szabo | Feb 2007 | B1 |
| 7219073 | Taylor et al. | May 2007 | B1 |
| 7286998 | Sauser et al. | Oct 2007 | B2 |
| 7302398 | Ban et al. | Nov 2007 | B2 |
| 7680777 | Poston et al. | Mar 2010 | B2 |
| 7860808 | Peters | Dec 2010 | B2 |
| 7912734 | Kil | Mar 2011 | B2 |
| 7979457 | Garman | Jul 2011 | B1 |
| 7983956 | Goel | Jul 2011 | B1 |
| 8005685 | Bird | Aug 2011 | B1 |
| 8035511 | Weaver et al. | Oct 2011 | B2 |
| 8165920 | Goel | Apr 2012 | B2 |
| 8224665 | Morris | Jul 2012 | B2 |
| 8332247 | Bailey et al. | Dec 2012 | B1 |
| 8510133 | Peak et al. | Aug 2013 | B2 |
| 8600784 | Ivey et al. | Dec 2013 | B1 |
| 8600830 | Hoffberg | Dec 2013 | B2 |
| 8631007 | Blandford et al. | Jan 2014 | B1 |
| 8762160 | Lulla | Jun 2014 | B2 |
| 8775426 | Mukerjee et al. | Jul 2014 | B2 |
| 9031853 | Bartfeld et al. | May 2015 | B2 |
| 9043151 | Cai et al. | May 2015 | B2 |
| 9286629 | Miller et al. | Mar 2016 | B2 |
| 9449151 | Etchegoyen | Sep 2016 | B2 |
| 9659099 | Miller et al. | May 2017 | B2 |
| 9946839 | Wilson et al. | Apr 2018 | B1 |
| 10041803 | Miller et al. | Aug 2018 | B2 |
| 10078855 | Miller et al. | Sep 2018 | B2 |
| 10210270 | Miller et al. | Feb 2019 | B2 |
| 10275810 | Miller et al. | Apr 2019 | B2 |
| 10282797 | Valverde, Jr. et al. | May 2019 | B2 |
| 10311068 | Tanne et al. | Jun 2019 | B2 |
| 10740412 | Bhat et al. | Aug 2020 | B2 |
| 20010044788 | Demir et al. | Nov 2001 | A1 |
| 20020069133 | Currie et al. | Jun 2002 | A1 |
| 20020082877 | Schiff et al. | Jun 2002 | A1 |
| 20020147619 | Floss et al. | Oct 2002 | A1 |
| 20020173978 | Boies et al. | Nov 2002 | A1 |
| 20020178034 | Gardner et al. | Nov 2002 | A1 |
| 20030018499 | Miller et al. | Jan 2003 | A1 |
| 20030023463 | Dombroski et al. | Jan 2003 | A1 |
| 20030050846 | Rodon | Mar 2003 | A1 |
| 20030055690 | Garback | Mar 2003 | A1 |
| 20030055772 | Goldstein | Mar 2003 | A1 |
| 20030135458 | Tadano et al. | Jul 2003 | A1 |
| 20030177044 | Sokel et al. | Sep 2003 | A1 |
| 20030217052 | Rubenczyk et al. | Nov 2003 | A1 |
| 20040002876 | Sommers et al. | Jan 2004 | A1 |
| 20040044516 | Kennewick et al. | Mar 2004 | A1 |
| 20040078213 | Brice et al. | Apr 2004 | A1 |
| 20040111255 | Huerta et al. | Jun 2004 | A1 |
| 20040220854 | Postrel | Nov 2004 | A1 |
| 20040249680 | Liew et al. | Dec 2004 | A1 |
| 20050033614 | Lettovsky et al. | Feb 2005 | A1 |
| 20050038644 | Napper et al. | Feb 2005 | A1 |
| 20050043940 | Elder | Feb 2005 | A1 |
| 20050108068 | Marcken et al. | May 2005 | A1 |
| 20050144162 | Liang | Jun 2005 | A1 |
| 20050220278 | Zirngibl et al. | Oct 2005 | A1 |
| 20050267651 | Arango et al. | Dec 2005 | A1 |
| 20050288973 | Taylor et al. | Dec 2005 | A1 |
| 20060106655 | Lettovsky et al. | May 2006 | A1 |
| 20060178931 | Horn | Aug 2006 | A1 |
| 20060241983 | Viale et al. | Oct 2006 | A1 |
| 20060247954 | Hunt | Nov 2006 | A1 |
| 20060265508 | Angel et al. | Nov 2006 | A1 |
| 20060271277 | Hu et al. | Nov 2006 | A1 |
| 20060285662 | Yin et al. | Dec 2006 | A1 |
| 20060293930 | Rodgers et al. | Dec 2006 | A1 |
| 20070073562 | Brice et al. | Mar 2007 | A1 |
| 20070073563 | Dourthe et al. | Mar 2007 | A1 |
| 20070100962 | Barth et al. | May 2007 | A1 |
| 20070106497 | Ramsey et al. | May 2007 | A1 |
| 20070106536 | Moore | May 2007 | A1 |
| 20070143154 | Ashby et al. | Jun 2007 | A1 |
| 20070156469 | Bird et al. | Jul 2007 | A1 |
| 20070168245 | de Marcken et al. | Jul 2007 | A1 |
| 20070168854 | de Marcken et al. | Jul 2007 | A1 |
| 20070174350 | Pell et al. | Jul 2007 | A1 |
| 20070185744 | Robertson | Aug 2007 | A1 |
| 20070192186 | Greene et al. | Aug 2007 | A1 |
| 20070198442 | Horn | Aug 2007 | A1 |
| 20070203735 | Ashton | Aug 2007 | A1 |
| 20070208503 | Harnsberger | Sep 2007 | A1 |
| 20070260495 | Mace et al. | Nov 2007 | A1 |
| 20070276595 | Lewinson et al. | Nov 2007 | A1 |
| 20070294149 | Lu et al. | Dec 2007 | A1 |
| 20080021748 | Bay et al. | Jan 2008 | A1 |
| 20080046274 | Geelen et al. | Feb 2008 | A1 |
| 20080052217 | Etkin | Feb 2008 | A1 |
| 20080059454 | Andrieu | Mar 2008 | A1 |
| 20080091525 | Kretz | Apr 2008 | A1 |
| 20080091557 | Cella et al. | Apr 2008 | A1 |
| 20080103949 | Lobana et al. | May 2008 | A1 |
| 20080109232 | Musgrove et al. | May 2008 | A1 |
| 20080114623 | Berthaud et al. | May 2008 | A1 |
| 20080120306 | Panabaker et al. | May 2008 | A1 |
| 20080201178 | Vizitei | Aug 2008 | A1 |
| 20080262995 | Zweig et al. | Oct 2008 | A1 |
| 20080319803 | Heyraud et al. | Dec 2008 | A1 |
| 20090005650 | Angell et al. | Jan 2009 | A1 |
| 20090006143 | Orttung et al. | Jan 2009 | A1 |
| 20090048876 | Bonissone et al. | Feb 2009 | A1 |
| 20090063359 | Connors | Mar 2009 | A1 |
| 20090070322 | Salvetti et al. | Mar 2009 | A1 |
| 20090112639 | Robinson | Apr 2009 | A1 |
| 20090157312 | Black et al. | Jun 2009 | A1 |
| 20090157664 | Wen | Jun 2009 | A1 |
| 20090177651 | Takamatsu et al. | Jul 2009 | A1 |
| 20090193352 | Bunn | Jul 2009 | A1 |
| 20090210262 | Rines et al. | Aug 2009 | A1 |
| 20090216633 | Whitsett et al. | Aug 2009 | A1 |
| 20090234681 | Champernowne | Sep 2009 | A1 |
| 20090240517 | Pelter | Sep 2009 | A1 |
| 20090313055 | Martin et al. | Dec 2009 | A1 |
| 20090319305 | Weissert et al. | Dec 2009 | A1 |
| 20090327148 | Kamar et al. | Dec 2009 | A1 |
| 20100010841 | Cooper et al. | Jan 2010 | A1 |
| 20100010978 | Carapella et al. | Jan 2010 | A1 |
| 20100030594 | Swart | Feb 2010 | A1 |
| 20100082241 | Trivedi | Apr 2010 | A1 |
| 20100153292 | Zheng et al. | Jun 2010 | A1 |
| 20100217680 | Fusz et al. | Aug 2010 | A1 |
| 20100217723 | Sauerwein, Jr. et al. | Aug 2010 | A1 |
| 20100317420 | Hoffberg | Dec 2010 | A1 |
| 20100318386 | Vaughan et al. | Dec 2010 | A1 |
| 20100324927 | Tinsley | Dec 2010 | A1 |
| 20110046989 | Crean et al. | Feb 2011 | A1 |
| 20110093361 | Morales | Apr 2011 | A1 |
| 20110125578 | Alspector et al. | May 2011 | A1 |
| 20110137766 | Rasmussen et al. | Jun 2011 | A1 |
| 20110153373 | Dantzig et al. | Jun 2011 | A1 |
| 20110167003 | Nice et al. | Jul 2011 | A1 |
| 20110231182 | Weider et al. | Sep 2011 | A1 |
| 20110246246 | Johnson | Oct 2011 | A1 |
| 20110295692 | Zivkovic et al. | Dec 2011 | A1 |
| 20110307241 | Waibel et al. | Dec 2011 | A1 |
| 20110307280 | Mandelbaum | Dec 2011 | A1 |
| 20110312870 | Beatty | Dec 2011 | A1 |
| 20120036158 | Cahill et al. | Feb 2012 | A1 |
| 20120054001 | Zivkovic et al. | Mar 2012 | A1 |
| 20120054054 | Kameyama | Mar 2012 | A1 |
| 20120059679 | de Marcken et al. | Mar 2012 | A1 |
| 20120089407 | Goldstein | Apr 2012 | A1 |
| 20120209517 | Li et al. | Aug 2012 | A1 |
| 20120233207 | Mohajer | Sep 2012 | A1 |
| 20120239440 | Miller et al. | Sep 2012 | A1 |
| 20120239443 | Miller et al. | Sep 2012 | A1 |
| 20120239455 | Crean et al. | Sep 2012 | A1 |
| 20120239584 | Yariv et al. | Sep 2012 | A1 |
| 20120239669 | Miller et al. | Sep 2012 | A1 |
| 20120259667 | Pelissier et al. | Oct 2012 | A1 |
| 20120265598 | Krone | Oct 2012 | A1 |
| 20120265696 | Tuchman et al. | Oct 2012 | A1 |
| 20120330982 | Arnaud et al. | Dec 2012 | A1 |
| 20130166329 | Arnoux-Prost et al. | Jan 2013 | A1 |
| 20130041696 | Richard | Feb 2013 | A1 |
| 20130041902 | Swann et al. | Feb 2013 | A1 |
| 20130054375 | Sy et al. | Feb 2013 | A1 |
| 20130073323 | Zacharia et al. | Mar 2013 | A1 |
| 20130073325 | Ross | Mar 2013 | A1 |
| 20130090959 | Kvamme et al. | Apr 2013 | A1 |
| 20130096965 | Pappas et al. | Apr 2013 | A1 |
| 20130132129 | Fox et al. | May 2013 | A1 |
| 20130144889 | Gupta et al. | Jun 2013 | A1 |
| 20130151291 | Salway | Jun 2013 | A1 |
| 20130158821 | Ricci | Jun 2013 | A1 |
| 20130159023 | Srinivas et al. | Jun 2013 | A1 |
| 20130198036 | Pappas et al. | Aug 2013 | A1 |
| 20130261957 | Mahapatro et al. | Oct 2013 | A1 |
| 20130268532 | Doshi | Oct 2013 | A1 |
| 20130304349 | Davidson | Nov 2013 | A1 |
| 20130339105 | Russell et al. | Dec 2013 | A1 |
| 20140012659 | Yan | Jan 2014 | A1 |
| 20140019176 | Mandelbaum | Jan 2014 | A1 |
| 20140025540 | Hendrickson | Jan 2014 | A1 |
| 20140067483 | Jeong et al. | Mar 2014 | A1 |
| 20140074746 | Wang | Mar 2014 | A1 |
| 20140081793 | Hoffberg | Mar 2014 | A1 |
| 20140089020 | Murphy | Mar 2014 | A1 |
| 20140089036 | Chidlovskii | Mar 2014 | A1 |
| 20140089101 | Meller | Mar 2014 | A1 |
| 20140114705 | Bashvitz et al. | Apr 2014 | A1 |
| 20140156411 | Murgai | Jun 2014 | A1 |
| 20140229102 | Bapna et al. | Aug 2014 | A1 |
| 20140257949 | Gishen | Sep 2014 | A1 |
| 20140279196 | Wilson et al. | Sep 2014 | A1 |
| 20140304014 | Lee et al. | Oct 2014 | A1 |
| 20140330605 | Connolly et al. | Nov 2014 | A1 |
| 20140330606 | Paget et al. | Nov 2014 | A1 |
| 20140330621 | Nichols et al. | Nov 2014 | A1 |
| 20140337063 | Nelson et al. | Nov 2014 | A1 |
| 20150012309 | Buchheim et al. | Jan 2015 | A1 |
| 20150012467 | Greystoke et al. | Jan 2015 | A1 |
| 20150046201 | Miller et al. | Feb 2015 | A1 |
| 20150066594 | Li et al. | Mar 2015 | A1 |
| 20150066830 | Wilson et al. | Mar 2015 | A1 |
| 20150149432 | Hart et al. | May 2015 | A1 |
| 20150168169 | Caceres et al. | Jun 2015 | A1 |
| 20150193583 | McNair et al. | Jul 2015 | A1 |
| 20150227633 | Shapira | Aug 2015 | A1 |
| 20150235478 | Blandin et al. | Aug 2015 | A1 |
| 20150242927 | Will | Aug 2015 | A1 |
| 20150278970 | Valverde, Jr. et al. | Oct 2015 | A1 |
| 20150339405 | Vora et al. | Nov 2015 | A1 |
| 20150356262 | Liebovitz et al. | Dec 2015 | A1 |
| 20160048928 | Davis et al. | Feb 2016 | A1 |
| 20160055162 | Woolf | Feb 2016 | A1 |
| 20160125559 | Shekou | May 2016 | A1 |
| 20160132791 | Jin et al. | May 2016 | A1 |
| 20160162871 | Lee | Jun 2016 | A1 |
| 20160196271 | Miller et al. | Jul 2016 | A1 |
| 20160202073 | Claycomb et al. | Jul 2016 | A1 |
| 20160203422 | Demarchi et al. | Jul 2016 | A1 |
| 20160232626 | Geraci et al. | Aug 2016 | A1 |
| 20160258767 | Nevrekar et al. | Sep 2016 | A1 |
| 20160275194 | Borza et al. | Sep 2016 | A1 |
| 20160364815 | Miller et al. | Dec 2016 | A1 |
| 20160370197 | Miller et al. | Dec 2016 | A1 |
| 20160371799 | Miller et al. | Dec 2016 | A1 |
| 20170132740 | Waysbort et al. | May 2017 | A1 |
| 20170154353 | Ralston | Jun 2017 | A1 |
| 20170293722 | Valverde, Jr. et al. | Oct 2017 | A1 |
| 20170316103 | Miller et al. | Nov 2017 | A1 |
| 20180336642 | Miller | Nov 2018 | A1 |
| 20180347995 | Valverde, Jr. et al. | Dec 2018 | A1 |
| 20190012712 | Miller et al. | Jan 2019 | A1 |
| 20190179863 | Miller et al. | Jun 2019 | A1 |
| 20190243839 | Tanne et al. | Aug 2019 | A1 |
| 20190251643 | Valverde, Jr. et al. | Aug 2019 | A1 |
| 20200027039 | Miller et al. | Jan 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2830228 | Aug 2017 | CA |
| 2830224 | Dec 2017 | CA |
| 2009033167 | Mar 2009 | WO |
| 2012125742 | Sep 2012 | WO |
| 2012125753 | Sep 2012 | WO |
| 2012125761 | Sep 2012 | WO |
| 2015021180 | Feb 2015 | WO |
| 2015153776 | Oct 2015 | WO |
| 2016201134 | Dec 2016 | WO |
| 2016205076 | Dec 2016 | WO |
| 2016205280 | Dec 2016 | WO |
| 2017180483 | Oct 2017 | WO |
| Entry |
|---|
| PR Newswire, “GetGoing Launches Multi-Supplier Hotel Merchandising Platform: BCD Travel Signs Multi-Year Agreement to Streamline Hotel Booking for Travel Management Companies,” New York, PR Newswire Association LLC, Sep. 23, 2014. |
| Notices of Allowance and References Cited in U.S. Appl. No. 14/750,841, dated Mar. 23, 2021 (12 pages). |
| PR Newswire, “GetGoing Launches Multi-Supplier Hotel Merchandising Platform: BCD Travel Signs Multi-Year Agreement to Streamline Hotel Booking for Travel Management Companies”, New York, PR Newswire Association LLC, Sep. 23, 2014 (2-3 pages). |
| Notices of Allowance and Cited References dated Oct. 29, 2021 in U.S. Appl. No. 16/854,753 (10 pages). |
| Notices of Allowance and References Cited dated Jul. 9, 2021 in U.S. Appl. No. 16/275,133 (12 pages). |
| International Search Report and Written Opinion dated Jun. 15, 2012 in International Patent Application No. PCT/US2012/029121 (8 pages). |
| International Search Report and Written Opinion dated Jun. 7, 2012 in International Patent Application No. PCT/US2012/029098 (6 pages). |
| International Search Report and Written Opinion dated Mar. 14, 2013 in International Patent Application No. PCT/US2012/029112 (6 pages). |
| International Search Report and Written Opinion dated Nov. 24, 2014 in International Patent Application No. PCT/US2014/049979 (8 pages). |
| United Hub, “FareLock: An Opportunity to Lock in Your Ticket Price for up to Seven Days”, Jul. 28, 2012 <https://web.archive.org/web/20120728071904/https://www.united.com/CMS/en-US/products/travelproducts/Pages/FareLock.aspx>, Aug. 17, 2012 <https://hub.united.com/en-us/news/products-services/pages/farelock-lets-you-lock-in-your-ticket-price.aspx> (3 pages). |
| MacKenzie, “Two Services Help You Lock in a Good Deal on Airfare”, Hack My Trip, Apr. 2014 <http://hackmytrip.com/2014/04/two-services-help-lock-good-deal-airfare> (9 pages). |
| Boardman, “Options Away”, Vimeo, May 24, 2013 <http://vimeo.com/66936261> (2 pages). |
| International Search Report and Written Opinion dated Jul. 2, 2015 in International Patent Application No. PCT/US2015/023901 (8 pages). |
| Examiner's Report dated Feb. 26, 2016 in CA Patent Application No. 2,830,228 (3 pages). |
| Examiner's Report dated May 18, 2016 in CA Patent Application No. 2,830,224 (6 pages). |
| Examiner's Report dated May 19, 2016 in CA Patent Application No. 2,830,229 (4 pages). |
| International Search Report and Written Opinion dated Jul. 11, 2016 in International Patent Application No. PCT/US2016/037555 (12 pages). |
| International Search Report and Written Opinion dated Sep. 1, 2016 in International Patent Application No. PCT/US2016/036760 (8 pages). |
| International Search Report and Written Opinion dated Sep. 9, 2016 in International Patent Application No. PCT/US2016/037503 (6 pages). |
| International Search Report and Written Opinion dated Sep. 27, 2016 in International Patent Application No. PCT/US2016/036749 (8 pages). |
| Notice of Allowance dated Jan. 12, 2017 in CA Patent Application No. 2,830,228 (1 page). |
| Notice of Allowance dated May 4, 2017 in CA Patent Application No. 2,830,224 (1 page). |
| Examiner's Report dated Apr. 28, 2017 in CA Patent Application No. 2,830,229 (4 pages). |
| International Search Report and Written Opinion dated Jul. 7, 2017 in International Patent Application No. PCT/US2017/026708 (8 pages). |
| Mayerowitz, “Latest Airline Fee: $9 to Lock in Airfare”, ABC News [online], Dec. 13, 2010 <http://web.archive.org/web/20110122133909/http://abcnews.go.com/Travel/airline-fees-forget-checked-bags-pay-lock-airfare/story?id=12385126> (p. 1) and Dec. 18, 2010 <http://web.archive.org/web/20101218074131/http://abcnews.go.com:80/Travel/airline-fees-forget-checked-bags-pay-lock-airfare/story?id=12385126&page=2> (p. 2), total 8 pages. |
| Examiner's Report dated Mar. 16, 2018 in CA Patent Application No. 2,830,229 (5 pages). |
| Goddeau, et al., “Galaxy: A Human-Language Interface to On-Line Travel Information”, 3rd International Conference on Spoken Language Processing (ICSLP94), Yokohama, Japan, Sep. 18-22, 1994, pp. 707-710. |
| Subramoni, “Topology-Aware MPI Communication and Scheduling for High Performance Computing Systems”, Ohio State University, 2013, 151 pages. |
| Tablan et al., “A Natural Language Query Interface to Structured Information”, The Semantic Web: Research and Applications, ESWC 2008: Lecture Notes in Computer Science, vol. 5021, pp. 361-375. |
| United Airlines, “FareLock”, webpage, Jul. 28, 2012 <https://www.united.com/CMS/en-US/products/travel/products/Pages/FareLock.aspx> (4 pages). |
| Federal Trade Commission, “Using Layaway Plans”, webpage, Dec. 19, 2012 <http:/web.archive.org/web/20121219044435/https://www.consumer.ftc.gov/articles/0128-using-layaway-plans> (2 pages). |
| Examiner's Report dated Feb. 27, 2019 in CA Patent Application No. 2,944,652 (5 pages). |
| Examiner's Report dated Mar. 1, 2019 in CA Patent Application No. 2,830,229 (3 pages). |
| Examiner's Report dated Jun. 3, 2019 in CA Patent Application No. 3,021, 147 (5 pages). |
| Examiner's Report dated Jul. 26, 2019 in CA Patent Application No. 2,989,325 (6 pages). |
| Examiner's Report dated Dec. 30, 2019 in CA Patent Application No. 2,944,652 (5 pages). |
| Non-final Office Action and Notice of References Cited dated Jun. 5, 2018 in U.S. Appl. No. 15/595,795 (14 pages). |
| Non-final Office Action and Notice of References Cited dated Mar. 11, 2015 in U.S. Appl. No. 13/420,433 (9 pages). |
| Non-final Office Action and Notice of References Cited dated Feb. 26, 2016 in U.S. Appl. No. 13/420,433 (11 pages). |
| Non-final Office Action and Notice of References Cited dated Dec. 16, 2013 in U.S. Appl. No. 13/419,989 (16 pages). |
| Non-final Office Action and Notice of References Cited dated Dec. 5, 2014 in U.S. Appl. No. 13/419,989 (14 pages). |
| Notices of Allowance and References Cited dated Dec. 18, 2015 in U.S. Appl. No. 13/419,989 (15 pages). |
| Non-final Office Action and Notice of References Cited dated Oct. 21, 2014 in U.S. Appl. No. 13/420,179 (10 pages). |
| Non-final Office Action and Notice of References Cited dated Aug. 12, 2015 in U.S. Appl. No. 14/750,841 (15 pages). |
| Non-final Office Action and Notice of References Cited dated Aug. 14, 2015 in U.S. Appl. No. 14/676,302 (19 pages). |
| Final Office Action and Notice of References Cited dated Apr. 6, 2016 in U.S. Appl. No. 14/676,302 (26 pages). |
| Final Office Action and Notice of References Cited dated Jul. 11, 2016 in U.S. Appl. No. 13/420,433 (12 pages). |
| Non-final Office Action and Notice of References Cited dated Sep. 20, 2016 in U.S. Appl. No. 14/453,420 (29 pages). |
| Non-final Office Action and Notice of References Cited dated Nov. 30, 2016 in U.S. Appl. No. 14/676,302 (20 pages). |
| Non-final Office Action and Notice of References Cited dated Dec. 29, 2016 in U.S. Appl. No. 14/750,841 (16 pages). |
| Non-final Office Action and Notice of References Cited dated Jul. 13, 2016 in U.S. Appl. No. 15/069,791 12 pages). |
| Non-final Office Action and Notice of References Cited dated Jun. 22, 2016 in U.S. Appl. No. 13/420,179 (13 pages). |
| Notices of Allowance and References Cited dated Dec. 27, 2018 in U.S. Appl. No. 13/420,179 (13 pages). |
| Non-final Office Action and Notice of References Cited dated Apr. 24, 2018 in U.S. Appl. No. 14/676,302 (26 pages). |
| Advisory Action dated May 21, 2015 in U.S. Appl. No. 13/420,179 (3 pages). |
| Non-final Office Action and Notice of References Cited dated Feb. 7, 2019 in U.S. Appl. No. 14/750,841 (18 pages). |
| Non-final Office Action and Notice of References Cited dated Mar. 13, 2020 in U.S. Appl. No. 14/750,841 (25 pages). |
| Non-final Office Action and Notice of References Cited dated Aug. 24, 2018 in U.S. Appl. No. 15/178,064 (30 pages). |
| Final Office Action and Notice of References Cited dated Feb. 19, 2019 in U.S. Appl. No. 15/178,064 (33 pages). |
| Non-final Office Action and Notice of References Cited dated Oct. 7, 2019 in U.S. Appl. No. 15/178,064 (44 pages). |
| Non-final Office Action and Notice of References Cited dated Sep. 26, 2017 in U.S. Appl. No. 15/178,453 (12 pages). |
| Non-final Office Action and Notice of References Cited dated Sep. 16, 2019 in U.S. Appl. No. 16/055,767 (7 pages). |
| Final Office Action and Notice of References Cited dated Apr. 18, 2017 in U.S. Appl. No. 14/453,420 (27 pages). |
| Non-final Office Action dated Mar. 9, 2018 in U.S. Appl. No. 14/453,420 (38 pages). |
| Final Office Action and Notice of References Cited dated Aug. 27, 2018 in U.S. Appl. No. 14/453,420 (45 pages). |
| Non-final Office Action and Notice of References Cited dated Jan. 7, 2019 in U.S. Appl. No. 14/453,420 (47 pages). |
| Final Office Action and Notice of References Cited dated Mar. 29, 2019 in U.S. Appl. No. 14/453,420 (44 pages). |
| Non-final Office Action and Notice of References Cited dated Jul. 12, 2018 in U.S. Appl. No. 15/183,620 (14 pages). |
| Non-Final Office Action and Notice of References Cited dated Nov. 29, 2018 in U.S. Appl. No. 15/183,620 (17 pages). |
| Non-final Office Action and Notice of References Cited dated May 22, 2019 in U.S. Appl. No. 15/183,620 (16 pages). |
| Non-final Office Action and Notice of References Cited dated Apr. 17, 2019 in U.S. Appl. No. 15/482,619 (42 pages). |
| Non-final Office Action and Notice of References Cited dated Apr. 14, 2020 in U.S. Appl. No. 15/979,275 (14 pages). |
| Non-final Office Action and Notice of References Cited dated May 28, 2020 in U.S. Appl. No. 16/142,834 (33 pages). |
| Final Office Action and Notice of References Cited dated Oct. 23, 2020 in U.S. Appl. No. 14/750,841 (21 pages). |
| Niknafs, et al., A Case-Based Reasoning Approach in E-tourism: Tour Itinerary Planning, Proceedings of the 14th International Workshop on Database and Expert Systems Applications (DEXA'03), 2003 (Year: 2003) (5 pages). |
| Final Office Action and Notice of References Cited dated Dec. 5, 2022 in U.S. Appl. No. 16/396,487 (10 pages). |
| Notices of Allowance and Cited References dated Feb. 23, 2023 in U.S. Appl. No. 17/502,625 (8 pages). |
| Notice of Allowance and References cited dated May 5, 2023 in U.S. Appl. No. 16/396,487 (13 pages). |
| Supplemental Notice of Allowance dated May 15, 2023 in U.S. Appl. No. 16/396,487 (8 pages). |
| Rudnicky, et al., “An Agenda-Based Dialog Management Architecture for Spoken Language Systems,” IEEE Automatic Speech Recognition and Understanding Workshop, vol. 13, No. 4, 1999. |
| Number | Date | Country | |
|---|---|---|---|
| 20210081854 A1 | Mar 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62574533 | Oct 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16142834 | Sep 2018 | US |
| Child | 17106022 | US | |
| Parent | 14750841 | Jun 2015 | US |
| Child | 16142834 | US |
