Computer-implemented methods of responding to a user travel search query

Abstract

There is disclosed a computer-implemented method of responding to a user travel search query, which may be a general travel search query, including the steps of: (i) a back end for front end (BFF) sen

Description

[0001] COMPUTER-IMPLEMENTED METHODS OF RESPONDING TO A USER TRAVEL SEARCH QUERY

[0002] BACKGROUND OF THE INVENTION

[0003] 1. Field of the Invention

[0004] The field of the invention relates to computer-implemented methods of responding to a user travel search query, which may be a general travel search query, and to related systems and servers.

[0005] 2. Technical Background

[0006] Internet travel search services are in ever-greater demand, which means that internet travel search services are consuming ever more energy. Individual travel searches tend to take some time, which means that users’ searching activities can be constrained by the time the users have available to search. When including a new travel search service aspect in an existing travel search service, e.g. pandemic travel restrictions, travel deals, it can be cumbersome to integrate a new travel search service aspect into an existing travel search service, e.g. because of incompatible data structures.

[0007] Accordingly, there is a need for a way to reduce the energy consumed by internet travel services, while maintaining the level of the search services provided, or while improving the level of the search services provided. There is also a need for a way to integrate a new travel search service aspect into an existing travel search service more easily.

[0008] 3. Discussion of Related Art

[0009] US11030635B2 discloses a computer server receives a request for a price for goods or services, such as airfares, together with parameters defining those goods or services, for example: activity type, such as airfare, hotel booking, train fare; date range; destination; origin; desired weather conditions; star ratings; keywords; any other user defined preference. One or more processors programmed with software then infer, estimate or predict estimated prices from an incomplete historical price dataset by analysing patterns in that dataset and provide the price estimates to an end-user computing device, such as a personal computer, smartphone or tablet.

[0010] US11294912B2 discloses a computer-implemented method of providing a set of alternative search results, the method including the steps of

[0011] (i) receiving a search request;

[0012] (ii) searching a database to provide a first set of a plurality of search results, each search result including a plurality of attributes;

[0013] (iii) identifying a best search result as the initially highlighted result;

[0014] (iv) providing the highlighted search result for display;

[0015] (v) receiving a selection of an attribute in the highlighted search result;

[0016] (vi) providing the set of alternative search results, in which the selected attribute is varied with respect to the highlighted search result, and

[0017] (vii) providing the set of alternative search results for display.

[0018] SUMMARY OF THE INVENTION

[0019] According to a first aspect of the invention, there is provided a computer- implemented method of responding to a user travel search query, which may be a general travel search query, the method including the steps of

[0020] (i) a back end for front end (BFF) receiving the user travel search query;

[0021] (ii) the BFF processing the user travel search query to define a BFF travel search query, the BFF travel search query including (a) an origin, (b) an inventory list type, (c) a specified geo-type target resolution for one or more destinations, (d) a query boundary including a geo-type defining the one or more destinations, (e) a date scope, and (f) filtering criteria;

[0022] (iii) the BFF sending the BFF travel search query to a Unified Search Service (USS), the USS starting a search at an initial geo-type level in a geographical hierarchy;

[0023] (iv) the USS selecting backends according to the geo-type level in the geographical hierarchy, and according to the date scope;

[0024] (v) the USS calling the selected backends in relation to the BFF travel search query, and receiving any search results sets from the selected backends, and any updates to the BFF travel search query;

[0025] (vi) including in a USS response set the received search result sets;

[0026] (vii) updating the BFF travel search query using any received updates to the BFF travel search query;

[0027] (viii) repeating steps (iv) to (vii), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;

[0028] (ix) the USS applying a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;

[0029] (x) the USS returning the reduced USS response set to the BFF;

[0030] (xi) the BFF processing the reduced USS response set to produce a processed reduced USS response set, and responding to the user travel search query using the processed reduced USS response set.

[0031] An advantage is that the method uses less energy than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request. An advantage is that a user obtains search results more quickly than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request, because making many search requests takes longer than making a single general travel search request. An advantage is that it is easy to include a new backend, because the general query grammar supports including a new backend easily. An advantage is the method provides an improvement in computer technology.

[0032] The method may be one in which a query grammar for BFF travel search queries is: "With Origin (ORIGIN), show results of type (INVENT OR Y_LI ST) at (TARGET RESOLUTION) resolution for destination(s) (QUERY BOUNDARY) filtered by (FILTER LIST) for dates (DATE SCOPE)". Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0033] The method may be one in which the data type geo-type identifies a depth in the (e.g. Skyscanner) Geographical Hierarchy e g. ANYWHERE, COUNTRY, CITY, PLACE. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0034] The method may be one wherein the filtering criteria include a data type FILTER LIST which is a List of Trip Modifier constraints to be applied by USS backends; this contains a filter type enumeration, optionally plus parameters. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0035] The method may be one wherein the filtering criteria include a filter list of a data type TRIP MODIFIER which defines query filters: enumerated constraints used to restrict results returned from USS. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0036] The method may be one wherein the constraints are evaluated by one or more of the USS backends orchestrated by the USS service itself, e.g. Travel Restrictions may be set as LOW or MODERATE.

[0037] The method may be one in which the date scope identifies a date scope of ANYTIME, or MONTH(s), or DATE(s).

[0038] The method may be one in which the date scope includes flexible departure dates. The method may be one in which the date scope includes flexible duration of the trip. The method may be one in which the origin identifies an origin location for the traveller, with a Travel Entity ID and a geo-type, eg. CITY(«EntityId»).

[0039] The method may be one in which the inventory list type is a List of Search Inventory type enumerations, e.g. Search backend identifiers. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0040] The method may be one in which the geo-type target resolution defines the query's target scope: the geographical resolution required for results, e.g. COUNTRY, or CITY, or AIRPORT. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0041] The method may be one in which the query boundary defines a query starting scope, defining a boundary for the recommendations and suggestions query space, e.g. I am looking at ANYWHERE destinations, or I am looking at this list of six CITIES. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0042] The method may be one in which the date scope is defined by a DATE RESOLUTION identifier (e.g. ANYTIME, SEASON, MONTH etc) and optionally parameters.

[0043] The method may be one in which the date scope identifies a resolution and parameters. The method may be one in which the USS suggests, ranks and retrieves search inventory for travellers.

[0044] The method may be one in which the Unified Search Service (USS) is configured to perform ‘Normal’ searches, and in which the USS is configured to perform ‘Advanced’ searches.

[0045] The method may be one in which the BFF request specifies a 'Geo Scope', which is a 'root node(s)' in the geographical hierarchy. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0046] The method may be one in which the USS coordinates a process to traverse the geographical hierarchy from the root node using suggestion and filtering logic selected by the client. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0047] The method may be one in which the USS uses data provided by other services in the search domain to coordinate the process to traverse the geographical hierarchy from the root node using suggestion and filtering logic selected by the client. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0048] The method may be one in which a search starts at root node(s) in the hierarchy and ends when nodes at a specified depth in the hierarchy have been identified and returned to the client. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0049] The method may be one in which the BFF is in communication with the USS via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf).

[0050] The method may be one in which the USS is in communication with search backends (e.g. for flights, for hotels, for vehicle hire) via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf).

[0051] The method may be one in which for each interface there is provided a corresponding inventory schema.

[0052] The method may be one in which a common inventory schema is used for the interfaces.

[0053] The method may be one in which the common inventory schema uses protobuf.

[0054] The method may be one in which a user does not need to integrate with multiple backends individually. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0055] The method may be one in which a user needs to specify their query only once. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0056] The method may be one in which USS search backends implement server-side filtering.

[0057] The method may be one in which filter constraints are expressed in the USS backend interface and are implemented by all participating ‘Advanced’ search backends.

[0058] The method may be one in which a (e.g. BFF) component outside of USS identifies entity IDs e.g. visible in a map (based on zoom level), in order to populate the USS request.

[0059] The method may be one in which in the event that a dependency is not available, the search fails fast and uses fallback data sources to approximate an ‘Advanced’ search result.

[0060] The method may be one in which the USS uses a static, in-memory alternative list of suggested locations if it is unable to retrieve personalized recommended locations within a predetermined time frame.

[0061] The method may be one in which the method includes a refinement process including: Generating suggested locations; Filtering and / or ranking suggestions; Dispatching queries to 'Advanced' search backends for data related to these locations, and Aggregating and returning results.

[0062] The method may be one in which the USS uses a destination suggestion backend to generate possible destinations based on a requested Geo Scope and filters.

[0063] The method may be one in which the suggestions are returned from the backend as a list of Entity IDs that meet the query criteria.

[0064] The method may be one in which the USS dispatches this list of entity IDs to other backends along with backend filtering criteria; and the results returned from these backends contain a new list of Entity IDs that match only the specified backend filter criteria. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0065] The method may be one in which the USS queries any remaining backends to retrieve outstanding results for the filtered entity IDs.

[0066] The method may be one in which during a refinement process, the USS forms a dynamic pipeline, which defines in which order the backends are called.

[0067] The method may be one in which backends called first are used to refine, suggest and / or filter the provided query into a more specific one, e.g. transform the initial geo scope of anywhere to a list of countries safe to travel to.

[0068] The method may be one in which the performance of the pipeline is defined by a priority of the components in the pipeline.

[0069] The method may be one in which the USS determines the order to query the backends using the provided filters in the explore query.

[0070] The method may be one in which when a query contains a recommendation request, the USS asks a "destination suggester" backend to get recommendations.

[0071] The method may be one in which the USS imposes a limit on the number of entities included in the BFF request.

[0072] The method may be one in which the USS imposes a limit of the number of entities included in a request to a backend service.

[0073] The method may be one in which in order to satisfy a client-facing request, the USS makes more than one request to a USS backend in order to stay within the limit.

[0074] The method may be one in which the USS truncates the list of suggested destinations after applying prioritization and ranking.

[0075] The method may be one in which the BFF handles mapping USS SearchResult schema elements (backend-specific) to front-end needs.

[0076] The method may be one in which the BFF translates between map coordinates and travel entity IDs.

[0077] The method may be one in which the BFF includes enrichment logic to return text copy, or images, or videos or other content about destinations.

[0078] The method may be one in which the USS includes ranking of the results set of returned inventory.

[0079] The method may be one in which the USS includes combining the results of multiple backends into a single response. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0080] The method may be one in which the search backends provide a schema for the inventory type.

[0081] The method may be one in which a search backend applies a query model, such as server-side filtering.

[0082] The method may be one in which the USS server implementation itself is stateless and includes no caching of results.

[0083] The method may be one in which the USS Backends implement their own caching strategies.

[0084] The method may be one in which the BFF provides to the user a map interface, and the BFF receives a selection of where the user wants to go to, as the destination(s).

[0085] The method may be one in which the map interface shows travel restrictions & destination safety information.

[0086] The method may be one in which backends queried include Travel Restrictions, Destination Safety.

[0087] The method may be one in which backends queried include Travel Restrictions, Advanced Flights, Destination Safety, Deals.

[0088] The method may be one in which a map is shown to the user with personalized recommended destinations.

[0089] The method may be one in which Backends queried include Travel Restrictions, Advanced Flights, Destination Safety, Deals, Destination Recommender(s).

[0090] The method may be one in which a map is shown to the user with hotel indicative pricing or with trips pricing.

[0091] The method may be one in which the USS processes as input Shorthand names for geographical groupings, such as "the Alps", "the Riviera".

[0092] The method may be one in which search backends return refined intent which contains the requested geo entities as provided in the destination set of the original intent, or the next level in geo scope hierarchy.

[0093] The method may be one in which search backends return an origin which is either the requested origin or an updated origin used by the backend to answer the request.

[0094] The method may be one in which if the request does not define travel dates (i.e. date resolution is ANYTIME), backends can use this field to recommend the travel dates or simply provide the default value they used when searching the results.

[0095] The method may be one in which available geo informs USS, which geo entities the backend was able to return.

[0096] The method may be one in which the USS backends include Advanced Flights, e.g. in which queries include one or more of: ANYWHERE request returning data for all countries from origin city with date range; or COUNTRY list request returning data for selected countries from origin city with date range; or CITY list request returning data for selected cities from origin city with date range.

[0097] The method may be one in which the USS backends include Destination Recommender, e.g. in which queries include one or more of: City -level - Generates personalized recommendations of cities similar to an entered destination entity ID (city) - Parameters UTID, Origin Entity ID, Origin Country Code (Market), Destination Entity ID; Country-level - Generates personalized recommendations for countries similar to entered destination entity ID (country) - Parameters UTID, Origin Country Code (Market), Destination Entity ID (Country).

[0098] The method may be one in which in backend querying: BFF constructs and sends Search Intent to USS (501); Travel Restrictions sends an unfiltered response containing: List of country entity IDs; Travel restrictions data per country ID, as USS backend result (502); USS Extracts list of matching destinations from Travel Restrictions response (503); optionally Ranks / truncates matching destinations list to keep within query constraints; Dispatches a new Search Intent containing list of destinations to remaining search backend (Destination Safety); USS constructs a client response message containing Result payloads from Travel Restrictions and Destination Safety (504); and a List of matching destinations as entity IDs; USS returns result to BFF (505). Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0099] The method may be one in which the USS includes location entities with Geo coordinates in results.

[0100] The method may be one in which the USS includes appending geo information to requested and returned entity IDs.

[0101] The method may be one in which the USS is written in Java and deployed in Cells. The method may be one including the step of storing the processed reduced USS response set, or storing the reduced USS response set.

[0102] Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0103] According to a second aspect of the invention, there is provided a system including a BFF server, a USS server and backend servers, the system configured to perform a method of any aspect according to a first aspect of the invention.

[0104] According to a third aspect of the invention, there is provided a computer- implemented method of responding to a user travel search query, which may be a general travel search query, including the steps of:

[0105] (i) a BFF sends a BFF travel search query to a Unified Search Service (USS), the USS starting a search at an initial geo-type level in a geographical hierarchy;

[0106] (ii) the USS selecting backends according to the geo-type level in the geographical hierarchy, and according to the date scope;

[0107] (iii) the USS calling the selected backends in relation to the BFF travel search query, and receiving any search results sets from the selected backends, and any updates to the BFF travel search query;

[0108] (iv) including in a USS response set the received search result sets;

[0109] (v) updating the BFF travel search query using any received updates to the BFF travel search query; (vi) repeating steps (ii) to (v), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;

[0110] (vii) the USS applying a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;

[0111] (viii) the USS returning the reduced USS response set to the BFF. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0112] The method may be one including a method of any aspect of the first aspect of the invention.

[0113] According to a fourth aspect of the invention, there is provided a system including a BFF server, a USS server and backend servers, the system configured to perform a method of any aspect of the third aspect of the invention.

[0114] According to a fifth aspect of the invention, there is provided a computer- implemented method of responding to a user travel search query, which may be a general travel search query, including a USS lowering a depth of a searched geo-type level in a geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches a specified geo-type target resolution. Advantages are that the method is low energy, fast and it is easy to include a new backend.

[0115] The method may be one including a method of any aspect of the first aspect of the invention.

[0116] According to a sixth aspect of the invention, there is provided a system including a USS server and backend servers, the system configured to perform a method of any aspect of the fifth aspect of the invention.

[0117] According to a seventh aspect of the invention, there is provided a system including a BFF server and a USS server, the USS server in communication with backend servers, the system configured to respond to a user travel search query, which may be a general travel search query, in which:

[0118] (i) the back end for front end (BFF) server is configured to receive the user travel search query;

[0119] (ii) the BFF server is configured to process the user travel search query to define a BFF travel search query, the BFF travel search query including (a) an origin, (b) an inventory list type, (c) a specified geo-type target resolution for one or more destinations, (d) a query boundary including a geo-type defining the one or more destinations, (e) a date scope, and (f) filtering criteria;

[0120] (iii) the BFF server is configured to send the BFF travel search query to a Unified Search Service (USS) server, the USS server configured to start a search at an initial geo-type level in a geographical hierarchy;

[0121] (iv) the USS server is configured to select backends according to the geo-type level in the geographical hierarchy, and according to the date scope;

[0122] (v) the USS server is configured to call the selected backends in relation to the BFF travel search query, and to receive any search results sets from the selected backends, and any updates to the BFF travel search query;

[0123] (vi) the USS server is configured to include in a USS response set the received search result sets;

[0124] (vii) the USS server is configured to update the BFF travel search query using any received updates to the BFF travel search query;

[0125] (viii) the USS server is configured to repeat (iv) to (vii), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;

[0126] (ix) the USS server is configured to apply a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;

[0127] (x) the USS server is configured to return the reduced USS response set to the BFF server;

[0128] (xi) the BFF server is configured to process the reduced USS response set to produce a processed reduced USS response set, and to respond to the user travel search query using the processed reduced USS response set.

[0129] An advantage is that the system uses less energy than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request. An advantage is that a user obtains search results more quickly than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request, because making many search requests takes longer than making a single general travel search request. An advantage is that it is easy to include a new backend, because the general query grammar supports including a new backend easily. An advantage is the system provides an improvement in computer technology.

[0130] The system may be configured to perform a method of any aspect of the first aspect of the invention.

[0131] According to an eighth aspect of the invention, there is provided a BFF server of any aspect of the seventh aspect of the invention.

[0132] According to a ninth aspect of the invention, there is provided a USS server of any aspect of the seventh aspect of the invention.

[0133] According to a tenth aspect of the invention, there is provided a system including a BFF server and a USS server, the USS server in communication with backend servers, the system configured to respond to a user travel search query, which may be a general travel search query, in which:

[0134] (i) the BFF server is configured to send a BFF travel search query to the Unified Search Service (USS) server, the USS server configured to start a search at an initial geo-type level in a geographical hierarchy;

[0135] (ii) the USS server configured to select backends according to the geo-type level in the geographical hierarchy, and according to the date scope;

[0136] (iii) the USS server configured to call the selected backends in relation to the BFF travel search query, and to receive any search results sets from the selected backends, and any updates to the BFF travel search query;

[0137] (iv) the USS server is configured to include in a USS response set the received search result sets;

[0138] (v) the USS server is configured to update the BFF travel search query using any received updates to the BFF travel search query;

[0139] (vi) the USS server is configured to repeat (ii) to (v), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution; (vii) the USS server is configured to apply a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;

[0140] (viii) the USS server is configured to return the reduced USS response set to the BFF server.

[0141] An advantage is that the system uses less energy than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request. An advantage is that a user obtains search results more quickly than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request, because making many search requests takes longer than making a single general travel search request. An advantage is that it is easy to include a new backend, because the general query grammar supports including a new backend easily. An advantage is the system provides an improvement in computer technology.

[0142] The system may be configured to perform a method of any aspect of the first aspect of the invention.

[0143] According to an eleventh aspect of the invention, there is provided a BFF server of any aspect of the tenth aspect of the invention.

[0144] According to a twelfth aspect of the invention, there is provided a USS server of any aspect of the tenth aspect of the invention.

[0145] According to a thirteenth aspect of the invention, there is provided a Unified Search Service (USS) server, the USS server in communication with backend servers, the USS server configured to call selected backend servers in relation to a travel search query received from a BFF server, in relation to responding to a user travel search query, which may be a general travel search query, in which the USS server is configured to lower a depth of a searched geo-type level in a geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches a specified geo-type target resolution. An advantage is that the USS server uses less energy than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request. An advantage is that a user obtains search results more quickly than when a user makes many specific search requests, which occurs when the user is trying to obtain more general travel search results than can be obtained from a specific search request, because making many search requests takes longer than making a single general travel search request. An advantage is that it is easy to include a new backend, because the general query grammar supports including a new backend easily. An advantage is the USS server provides an improvement in computer technology.

[0146] The USS server may be configured to perform a method of any aspect of the first aspect of the invention.

[0147] Aspects of the invention may be combined.

[0148] BRIEF DESCRIPTION OF THE FIGURES

[0149] Aspects of the invention will now be described, by way of example(s), with reference to the following Figures, in which:

[0150] Figure 1 shows an example in which a Unified Search Service (USS) can perform ‘Normal’ searches, and in which the USS may also perform ‘Advanced’ searches.

[0151] Figure 2 shows an example in which a search starts at root node(s) in the hierarchy and ends when nodes at a specified depth in the tree have been identified and returned to the client.

[0152] Figure 3 shows an example in which a search at the top left accesses more content, and more inventory is created as the process progresses from the top left to the bottom right. Specificity increases from left to right and from top to bottom. PSS is passenger service system. PDP is policy decision point.

[0153] Figure 4 shows an example of a USS Intent Refinement Algorithm.

[0154] Figure 5 shows an example of backend querying.

[0155] Figure 6 shows an example of backend querying.

[0156] DETAILED DESCRIPTION

[0157] A travel -related search service (e.g. Skyscanner’s) may contain a wealth of information published from many services, each using a bespoke application programming interface (API) and query model. Due to this diversity, it may be time consuming and complex to access and combine search inventory data for different use cases. As a result, there may be too much use case-specific computer program code along with associated maintenance overhead.

[0158] A Unified Search Service may address this problem. A Unified Search Service (USS) may act as a gateway to a (e.g. Skyscanner's) search domain and may provide a single API with a domain-agnostic query grammar offering Combined Results for highly- specific ‘Normal’ queries (e.g. with a known origin, destination and travel dates), and for more general ‘Advanced’ queries.

[0159] In an initiative, we introduce the ability to respond to a different class of search queries, ‘Advanced’ queries, with more scope for receiving an original query which is something matching the traveller's intent. USS and participating search backends may be configured in order to support this different class of ‘Advanced’ search queries.

[0160] We may provide a 'unified API' approach while also standardising query models for inventory backends so that onboarding additional data sources and filter criteria takes less effort and can deliver value to travellers more quickly.

[0161] A goal for this Unified Search Service (USS) is to present users with destination options that meet their criteria and budget. An additional goal is to build a common framework to support future search ‘Advanced’ search use cases without extensive rework.

[0162] Example Design aspects

[0163] • A production-scale solution suitable for an initial use case of displaying flight prices and travel restrictions e,g, on a map, e.g. filtered by safety. • Defined APIs for client and backend USS ‘Advanced’ search components.

[0164] • Defined standard query model and non-functional requirements for USS ‘Advanced’ search components.

[0165] • Build suitable abstractions within USS to enable future iteration on ‘Advanced’ search queries without significant changes for other components.

[0166] • Fully generic USS ‘Advanced’ search support (e.g. allowing arbitrary filtering and data sources).

[0167] Overview and Theory of Operation

[0168] A Unified Search Service (USS) Architecture

[0169] In an example, the USS supports Combined Results via Normal-style search queries. The traveller query is captured as specific parameters in a single 'intent' request sent to USS. The query is dispatched to multiple search inventory providers ("backends") with results aggregated together by USS. See Figure 1, for example. A search backend may wrap an inventory schema to a USS search backend response. The USS may collect results from all search backends and wrap them in a USS schema.

[0170] In an example, a front end is in communication with a back end for front end (BFF) via a web interface. The BFF is in communication with a USS layer via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf). The USS layer is in communication with search backends (e.g. for flights, for hotels, for vehicle hire) via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf). For each interface there is provided a corresponding inventory schema. See Figure 1, for example.

[0171] There are a number of benefits with this approach:

[0172] • Clients of the search domain do not need to integrate with multiple backends individually

[0173] • Clients need specify their query only once

[0174] • New search backends / inventory can be exposed to clients relatively quickly since the USS backend interaction is well-defined and shared by all backends

[0175] • Concentrating all queries through USS affords a single place to apply processing for cross-cutting concerns (e.g. in future) (e.g. relevance ranking or event logging)

[0176] In an example, a common schema has been defined for the client-facing request / response API along with a separate API implemented by USS backends. The common schema may use Protocol Buffers (Protobuf), which is a cross-platform data format used to serialize structured data. Search backends should be compatible with being USS backends. gRPC calls may be possible between the back end for front end (BFF) server and the USS layer, where gRPC (gRPC Remote Procedure Calls) is a crossplatform high performance remote procedure call (RPC) framework. gRPC calls may be possible between the USS layer and the search backends.

[0177] Example backends in USS: Flights; Hotels; Car Hire; Deals (a Deals Engine).

[0178] Design Principles

[0179] The following section lists the principles incorporated into the design:

[0180] 'Normal' query types and 'Advanced' (sometimes referred to as “Explore”) query types require different performance characteristics from USS components:

[0181]

[0182] USS ‘Advanced’ search queries will typically generate more results at the requested geo hierarchy depth than are required by the client (e.g. more cities than could be displayed on a map). As such, USS search backends may implement some level of server-side filtering. Filter constraints may be expressed in the USS backend interface and should be implemented by all participating ‘Advanced’ search backends.

[0183] For example, a Travel Restrictions API may support queries relating to [ANYWHERE, COUNTRY];

[0184] An Advanced Flights API may support queries relating to [ANYWHERE, COUNTRY, CITY];

[0185] A Travel Restrictions API query may return results for a list of N COUNTRIES (expressed as a list of travel entity IDs).

[0186] This ensures all clients can make requests and interpret results using the same geographical grammar. This implies a component outside of USS should be responsible for identifying entity IDs e.g. visible in a map (based on zoom level), in order to populate the USS request.

[0187] For example, a list of (e.g. Skyscanner) Travel Entity IDs is provided for the countries (e.g. visible in a map viewport) as the query start nodes. Although ‘Advanced’ search queries may commonly require 'refinement', suggestions and filtering to determine results to be returned, this may not always be the case.

[0188] USS may also able to provide results from ‘Normal’ search backends where the client already knows precisely which locations they wish to retrieve. For example, a search using, schematically, "given this list of cities, retrieve INDICATIVE PRICES and TRAVEL RESTRICTIONS data with no filters": the USS query model may support this type of query.

[0189] By the nature of 'Advanced' searches, the traveller does not know precisely what results they can expect to see. Although it is intended to return optimised and relevant results if possible, the design should also strive to avoid hard dependencies that could result in the search query failing.

[0190] In the event that a dependency is not available, the search should fail fast and use fallback data sources to approximate an ‘Advanced’ search result. The client may be able to gracefully handle a degraded ‘Advanced’ search response where results from a requested backend is not available.

[0191] For example, USS should delegate to a reliable / static / in-memory alternative list of suggested locations if it is unable to retrieve personalized recommended locations within a reasonable time frame.

[0192] Stable abstractions and interfaces between USS and external components are provided. Provided we have sufficiently isolated components using these abstractions, a fully generic refinement algorithm capable of supporting future ‘Advanced’ search and ‘Normal’ search use cases can follow iteratively.

[0193] USS Combined ‘Advanced’ and ‘Normal’ searches Concept

[0194] The Combined ‘Advanced’ and ‘Normal’ searches experience is implicitly linked with the concept of a Geographical Hierarchy.

[0195] Any given search starts at root node(s) in the hierarchy and ends when nodes at a specified depth in the tree have been identified and returned to the client. An example is shown in Figure 2.

[0196] USS may coordinate a process to traverse the geo hierarchy from the root node using suggestion and filtering logic selected by the client. USS may use data provided by other services in the search domain to achieve this (e.g. some combination of Price, Safety, Relevance, Theme etc).

[0197] In other words, USS delivers value for ‘Advanced’ and ‘Normal’ searches by suggesting, ranking and retrieving search inventory for travellers.

[0198] When received from a client, many 'Advanced'-style search queries lack specificity and need to be refined into more concrete queries before they can be sent to the backends holding search inventory.

[0199] To generalise, we can think of an example of the refinement process as using USS backends and user intent to:

[0200] 1) Generate suggested locations

[0201] 2) Filter and / or rank suggestions

[0202] 3) Dispatch queries to 'Advanced' search backends for data related to these locations

[0203] 4) Aggregate and return results.

[0204] A travel -related search may progress from a homepage, in which a continent is selected, then a country or region is selected, then a search in a country for a given month is requested and performed, which yields specific dates and times for possible city destinations. Following selection of a specific city, a ‘Normal’ search is performed, which leads to a selection of a specific trip, and hence to a booking panel. An example is shown in Figure 3. In Figure 3, the searches at the top left access more content, and more inventory is created as the process progresses from the top left to the bottom right.

[0205] Query Model

[0206] An example query grammar for USS 'Advanced' search queries is:

[0207] "With Origin (ORIGIN), show results of type (INVENT OR Y_LI ST) at (TARGET RESOLUTION) resolution for destination(s) (QUERY BOUNDARY) filtered by (FILTER LIST) for dates (DATE SCOPE)" In an example, there is a data type GEO TYPE which identifies a 'depth' in the (e.g. Skyscanner) Geo Hierarchy e g. ANYWHERE, COUNTRY, CITY, PLACE.

[0208] In an example, there is a data type GEO SCOPE, which includes a GEO TYPE plus an optional list of (e.g. Skyscanner) Travel Entity IDs which identify node(s) in the (e.g. Skyscanner) Geo Hierarchy e.g. CITY«1234».

[0209] In an example, there is a data type FILTER LIST which is a List of Trip Modifier constraints to be applied by USS backends. This contains a filter type enumeration plus optional parameters.

[0210] In an example, there is a data type DATE SCOPE which identifies a date scope (e.g, ANYTIME, MONTH(s), DATE(s)).

[0211] In an example, there is a query parameter ORIGIN of the data type SINGLE GEO SCOPE which identifies the origin location for the traveller, with a Travel Entity ID and a GEO TYPE. In an example, CITY(«EntityId») is supported.

[0212] In an example, there is a query parameter INVENTORY LIST of the data type SEARCH INVENTORY TYPE, in which there is a List of Search Inventory type enumerations, e.g. Search backend identifiers.

[0213] In an example, there is a query parameter TARGET RESOLUTION of the data type GEO TYPE which defines the query's target scope: the geographical resolution required for results, e.g. COUNTRY, or CITY, or AIRPORT.

[0214] In an example, there is a query parameter QUERY BOUNDARY of the data type GEO SCOPE which defines a query starting scope: this defines the boundary for the recommendations and suggestions query space, e.g. I am looking at ANYWHERE destinations, or I am looking at this list of 6 CITIES.

[0215] In an example, there is a query parameter FILTER LIST of the data type TRIP MODIFIER which defines query filters: enumerated constraints used to restrict results returned from USS. These constraints are evaluated by one or more of the USS backends orchestrated by the USS service itself, e.g. Travel Restrictions may be set as LOW or MODERATE.

[0216] In an example, there is a query parameter DATE SCOPE of the data type DATE SCOPE which may be defined by a DATE RESOLUTION identifier (e.g. ANYTIME, SEASON, MONTH etc) and optional parameters.

[0217] An example ‘Advanced’ search query, which is a very general one, is:

[0218] "With origin (CITY«LONDON»), show results of type (TRAVEL RESTRICTIONS, FLIGHT S INDIC ATI VE PRICING, DEALS) at (COUNTRY«*») resolution for destination(s) (ANYWHERE«*») filtered by (TRAVEL RESTRICTIONS == LOW) for dates (ANYTIME«*»)"

[0219] USS Intent Refinement Algorithm

[0220] The USS “Advanced’ search query processor may operate as follows:

[0221] 1. A client request specifies a 'Geo Scope' ('root node(s)' in the geo hierarchy) as well as a desired 'Geo Resolution' for results. Additionally, a client request includes a 'Date Range' identifying a resolution and parameters (e.g. ANYTIME, MONTH, DAYS), e.g. "I am considering [COUNTRY(1,2,3,4)] and would like [CITY] resolution for results filtered by 'MODERATE' Travel Safety" for 'MONTH (2,3)'; or

[0222] "I am considering [ANYWHERE] and would like [CITY] resolution for results filtered by 'Beach'" for 'ANYTIME'.

[0223] 2. USS uses a destination suggestion backend to generate possible destinations based on the requested Geo Scope and filters. These suggestions are returned from the backend as a list of Entity IDs that could meet the query criteria.

[0224] 3. USS dispatches this list of entity IDs to other backends along with filtering criteria. Results returned from these backends contain a new list of Entity IDs that match only the specified filter criteria.

[0225] 4. USS applies a reduction algorithm on returned entity IDs from all backend results to determine a single list of entity IDs matching all requested ranking criteria. 5. USS queries any remaining backends to retrieve outstanding results for the filtered entity IDs.

[0226] Figure 4 shows an example of a USS Intent Refinement Algorithm.

[0227] Backend prioritisation

[0228] During a refinement process, a USS may form a dynamic pipeline, which defines in which order the backends are called. Typically, the backends called first are used to refine, suggest and / or filter the provided query into a more specific one, e.g. transform the initial geo scope of anywhere to a list of countries safe to travel to.

[0229] In the rest of the pipeline, backends provide results to a more specific query and have an option to further refine the query for the remaining steps in the pipeline. This also means the performance of the pipeline is defined by the priority of the components in it. It is a responsibility of the USS to determine the best order based on the provided filters in the explore query.

[0230] When a query contains a recommendation request, such as "cheapest destinations" or "beach holiday", the USS may ask a "destination suggester" backend to get recommendations in the first step. This could be followed by the TravelRestrictions backend that filters destinations with "low" restrictions in the second step and then the rest of the backends in parallel in the last iteration. However, if the recommendation filter was not provided, the first step would be skipped and the initial set of country suggestions would be provided by the TravelRestrictions backend, before continuing the rest of the backends as in the first scenario.

[0231] A dedicated "destination suggester" component providing travel recommendations based on the "destination themes" may be provided. The TravelRestrictions backend may fulfill the role of "suggester," in an example.

[0232] Query Limits

[0233] It is clear that the refinement process is likely to generate many more suggested destinations than will efficiently fit in a single query to a USS backend (or which can be shown to clients).

[0234] This imposes a number of requirements: a) USS may impose a limit on the number of entities included in a client API request. For example, it would not be reasonable for a BFF to send a single USS request asking for indicative flights results for 500 cities. The actual limit is determined during implementation but the client may send more than one request if more results are needed. b) USS may similarly impose a limit of the number of entities included in a request to a backend service. The actual limit is determined during implementation, but it is typically in the low 10's of entities per request. In order to satisfy a client-facing request, USS may make more than one request to a USS backend in order to stay within this limit. c) An example of the ‘Advanced’ search refinement algorithm may adopt a strategy of truncating the list of suggested destinations after applying prioritization and ranking, in order to keep the number of results manageable for downstream USS components.

[0235] USS Component Responsibilities

[0236] The BFF may handle communication with USS, including constructing search intent, and error handling, retries, etc. The BFF may handle mapping USS SearchResult schema elements (backend-specific) to front-end needs. The BFF may translate between map coordinates and travel entity IDs. The BFF may assume responsibility for: Deriving a list of visible country / cities as entity IDs e.g. given a map viewport and zoom level; Deriving geo coordinates for entity IDs returned in USS results. The USS may instead assume this responsibility in an alternative example.

[0237] In an example, the USS may not return text copy / images / videos or other content about destinations, as these may be supplied by dedicated backends. As such, BFFs may need to take on some enrichment logic if there is a product need to return text copy / images / videos or other content about destinations.

[0238] The USS may include validation and enrichment of the search intent. The USS may include intent refinement: orchestrating other search backends regarding deadlines propagation to the downstream services, and / or error handling, and / or resilience on backend failures. The USS may include ranking of the results sets of returned inventory. The USS may include combining the results of multiple backends into a single response.

[0239] The search backends may provide a schema for the inventory type. The search backends may apply a query model, such as server-side filtering. The search backends may conform to service-level objectives (SLOs).

[0240] USS Component Non-Functional Requirements and SLOs

[0241] Performance and Availability for an ‘Advance’ search experience is important. In an example, we aim to deliver USS Explore SLOs as follows : < 600ms response time; 99.9% aggregate availability.

[0242] Since USS relies on orchestrating other data sources to deliver results, in an example it is important that other ‘Advanced’ search components conform to strict SLOs : e.g. < 200ms response time; 99.9% aggregate availability; USS API calls fully instrumented with OpenTelemetry tracing.

[0243] For the USS Response Time, an assumption may be that USS requires sequential calls to at most two backends for query refinement, followed by one request to remaining backends for data retrieval, hence three times the backend response time.

[0244] In order to mitigate the availability impact of multiple dependencies, the USS implementation attempts to: Limit the complexity of filtering / suggestion / retrieval logic to a maximum number of sequential steps (where an algorithm 'step' is one or more concurrent calls to an external service to gather suggestions or filtered results); Enforce deadlines for dependencies and apply sensible fallback policies if deadlines are exceeded; Return a degraded result if not all inventory is available (e.g. omit some result types, and then return what has been successfully retrieved).

[0245] In an example, the USS server implementation itself is stateless and includes no caching of results. In an example, the USS Explore Backends are responsible for implementing their own caching strategies, if used. In an example, session stickiness is not supported.

[0246] Example Interface: a “Where Can I Go?” map, with prices

[0247] We describe example supported queries. All queries start with a CITY origin.

[0248] An example query requests to show a map with travel restrictions & destination safety information. Example Backends involved include Travel Restrictions, Destination Safety. The destination may be ANYWHERE. There is no filter.

[0249] An example query requests to show a map with travel restrictions, flights prices & deals for COUNTRIES (a list) with X travel restrictions and a DATE RANGE. Example Backends involved include Travel Restrictions, Advanced Flights, Destination Safety, Deals. The destination may be COUNTRY [«entity_id_list»], A filter may be Travel Restrictions == Low, or Moderate, or High.

[0250] An example query requests to show a map with travel restrictions, flights prices & deals for CITIES (a list) with X travel restrictions and a DATE RANGE. Example Backends involved include Travel Restrictions, Advanced Flights, Destination Safety, Deals. The destination may be CITY [«entity_id_list»], A filter may be Travel Restrictions == Low, or Moderate, or High.

[0251] An example query requests to show a map with personalized recommended destinations. Example Backends involved include Travel Restrictions, Advanced Flights, Destination Safety, Deals, Destination Recommender(s).

[0252] An example query requests to show a map with hotel indicative pricing. An example query requests to show a map with trips pricing.

[0253] Possible Examples

[0254] The USS can process any type of query that can be resolved, by USS or one of its data sources, into a list of travel entity IDs. Examples: using as input Map Viewport (a Latitude and Longitude box). Using as input Shorthand names for geographical groupings, such as "the Alps", "the Riviera".

[0255] The USS can process a request for enriched entity data for suggested results, such as geographic coordinates for rendering in a map component.

[0256] The USS can enable ranking of results with models in a generic way, e.g using a Relevance Service backend.

[0257] USS Client API

[0258] The same API is provided for ‘Normal’ searches and for ‘Advanced’ searches. In the ‘Advanced’ search requests, clients may send a new Explorelntent with less specific geographic destination and travel dates compared to a ‘Normal’ search. In an example, clients are expected to send geo type for all entities. USS may proceed even if not all results are available: in an example, a response may include travel restrictions data but omit indicative flights pricing even if both were requested. In an example, clients may indicate if a particular type of inventory is mandatory.

[0259] An example normal search client request is: service UnifiedSearchService { rpc CreateSearch (CreateSearchRequest) returns (CreateSearchResponse) {

[0260] / / Initiate a search

[0261] } rpc PollSearch (PollSearchRequest) returns (PollSearchResponse) {

[0262] / / Poll for updates on an existing search }

[0263] } message CreateSearchRequest {

[0264] RequestContext request context = 1 ;

[0265] Searchintent intent = 2;

[0266] } message PollSearchRequest {

[0267] RequestContext request context = 1 ;

[0268] / / Session token. Callers must set this to be the latest ' session token'

[0269] / / that has been received in a ' SearchResponse' for this particular session. string session_token = 2;

[0270] } message CreateSearchResponse {

[0271] Searchintent search intent = 1; / / Search intent including any enrichment of the original user-supplied parameters

[0272] SearchResponse search response = 2;

[0273] } message PollSearchResponse {

[0274] SearchResponse search response = 1;

[0275] } message Searchintent {

[0276] TravellerContext traveller context = 1; repeated TripElement trip element = 2;

[0277] } message TripElement { parameter 1; / / Specific location (entity ID) parameter2; parameters; / / Specific date parameter4; parameters; / / Used to pass modifiers from the client to be interpreted by intent processors (e.g. cabin_class == "business" ) } For an example ‘Advanced’ search request use-case, clients are expected to send an ‘Advanced’ ("explore") intent to USS. Backwards compatibility with a ‘normal’ search use-case may be preserved by using “oneof ’. In an example, the USS does not support combination of a ‘Normal’ search intent and an ‘Advanced’ search intent in a single client request. An example ‘Advanced’ search client request is: message

[0278] CreateSearchRequest {

[0279] RequestContext request context = 1 ; oneof search intent {

[0280] Searchintent intent = 2;

[0281] Explorelntent explore intent = 3;

[0282] }

[0283] }

[0284] In the "’Advanced’ search (explore) intent", clients can define:

[0285] • destination - non-specific travel destinations as broad as "anywhere" or more specific ones, as a combination of geo type and entity IDs, which could be for example a list of countries or cities to be included in ’Advanced’ (explore) search.

[0286] • travel date - flexible departure dates and duration of the trip

[0287] • desired geo resolution - used to determine the desired level of geo specificity of the results, e.g. a client can use the field to tell USS it only wants COUNTRY level to be returned, so USS won't attempt to look for backends dealing with cities or airports.

[0288] • modifiers - define the filters to be applied during the search, for example a travel restriction filter: e g. TRIP MODIFIER TRAVEL RESTRICTIONS = 6; TRIP MODIFIER CONSTRAINT EQUALS TO = LOW. An example ‘Advanced’ search client request is:

[0289] / / Explore intent can be used instead of Searchintent when requesting / / results for flexible destinations and / or travel dates message Explorelntent { TravellerContext traveller context = 1;

[0290] / / Starting point of the trip

[0291] Geo origin = 2;

[0292] / / Desired travel destinations, this can be as wide as anywhere,

[0293] / / or more restricted by the type of entity and entity IDs

[0294] Multi Geo destination = 3;

[0295] / / Desired type of geo entities to be returned by USS

[0296] GeoType desired geo resolution = 4;

[0297] / / Travel dates, inc. flexible departure dates

[0298] TravelDate travel date = 5;

[0299] / / Filters to be applied on the search request repeated TripModifier modifier = 6;

[0300] }

[0301] Geo and MultiGeo may be used to represent one or more geo locations specified by their entity IDs and corresponding geo type. The following geo types may be supported: ANYWHERE; COUNTRY; CITY; AIRPORT.

[0302] Date resolution may be used to define the specificity of the provided travel date. For example:

[0303] • ANYTIME - travel date doesn't matter

[0304] • MONTH - flexibility of the travel dates within a specific month, may be used in combination with flexible_dates.month_of_year.

[0305] • RANGE - departure dates for the travel need to be within a specific range defined by flexible dates, departure date.

[0306] • SPECIFIC - departure dates are fixed, i.e. from and to dates are given and provided in specific dates.

[0307] An example ‘Advanced’ search client request is: message Geo { / / Canonical geo 'type' describing the type of the provided

[0308] / / entity, e.g. country, city, airport

[0309] GeoType type = 1;

[0310] / / Entity ID of the place, or empty when type is GEO TYPE ANYWHERE string entity id = 2;

[0311] }

[0312] / / MutiGeo type is used to represent multiple geo entities of the same type message MultiGeo {

[0313] GeoType type = 1;

[0314] / / Entity IDs of places, or empty when type is GEO TYPE ANYWHERE repeated string entity_id = 2;

[0315] } message TravelDate {

[0316] DateResolution resolution = 1; oneof travel date {

[0317] FlexibleDates flexible_dates = 2;

[0318] DateRange specific_dates = 3;

[0319] }

[0320] }

[0321] / / Canonical geo 'type' describing the type of the provided

[0322] / / entities, e.g. country, city, airport enum GeoType {

[0323] GEO TYPE UNSPECIFIED = 0;

[0324] GEO TYPE ANYWHERE = 1;

[0325] GEO TYPE COUNTRY = 2;

[0326] GEO TYPE CITY = 3;

[0327] GEO TYPE AIRPORT = 4;

[0328] } enum DateResolution {

[0329] DATE RESOLUTION UNSPECIFIED = 0;

[0330] DATE RESOLUTION ANYTIME = 1;

[0331] DATE RESOLUTION RANGE = 2;

[0332] DATE RESOLUTION MONTH = 3;

[0333] DATE RESOLUTION SPECIFIC = 4;

[0334] } message TravelDate {

[0335] DateResolution resolution = 1; oneof travel date {

[0336] FlexibleDates flexible_dates = 2;

[0337] DateRange specific_dates = 3;

[0338] }

[0339] }

[0340] / / Flexible dates can be used when traveller does

[0341] / / not know the exact travel dates message FlexibleDates { oneof departure {

[0342] / / Specifies the earliest from and latest to dates as a range

[0343] DateRange departure date = 1 ;

[0344] / / Month of a year.

[0345] Must be from 1 to 12,

[0346] / / or 0 to specify the depart range is being used int32 month_of_year = 2;

[0347] }

[0348] / / Desired duration of the trip in days, or 0 if not relevant int32 duration in days = 3;

[0349] } message DateRange { LocalDate from = 1 ;

[0350] LocalDate to = 2;

[0351] }

[0352] USS ‘Advanced’ search (Explore) Backend API

[0353] ‘Advanced’ search (Explore) backends may use a different Backend remote procedure call (RPC) API compared to ‘Normal’ search backends; this allows a clear separation for implementation and observability purposes.

[0354] Responses from both RPC APIs allows a backend to return:

[0355] • a set of results served by the given backend

[0356] • a more refined version of the original intent, which can be used to traverse to the next level in the geo hierarchy (if supported by the given backend).

[0357] Search backends might support polling, but in an example it is not supported by the USS clients for ‘Normal’ search and ‘Advanced’ search.

[0358] USS backends may implement both RPC services but may return an empty result if they do not wish to provide ‘Normal’ search or ‘Advanced’ search results.

[0359] ‘Normal’ search and ‘Advanced’ search use cases may use the "new" explore intent that is less specific than the Searchintent, which is used for searching the exact travel destinations and dates.

[0360] There may be cases where a search backend is used to provide both ‘Normal’ search and ‘Advanced’ search results (e.g. Travel Restrictions). In this case, the backend should implement both RPC services. Example remote procedure calls (RPCs) for ‘Normal’ search requests are:

[0361] / / Existing RPC for Day View queries service SearchB ackend Service { rpc CreateBackendSearch

[0362] (CreateB ackend S earchRequest) returns

[0363] (CreateBackendSearchResponse) {

[0364] / / Create search in backend } rpc PollBackendSearch

[0365] (PollBackendSearchRequest) returns

[0366] (PollBackendSearchResponse) {

[0367] / / Poll for updates on an existing search in this backend

[0368] }

[0369] } message CreateBackendSearchRequest {

[0370] RequestContext request context = 1 ;

[0371] Searchintent search intent = 2;

[0372] }

[0373] / / New RPC for Explore queries service Explore S earchB ackend S ervi ce { rpc

[0374] CreateExpl oreB ackend Search

[0375] (CreateExpl oreB ackend S earchRequest) returns

[0376] (CreateExploreBackendSearchResponse)

[0377] {

[0378] / / Create Explore search in backend

[0379] }

[0380] } message

[0381] CreateExploreBackendSearchRequest {

[0382] RequestContext request context = 1 ;

[0383] Explorelntent explore intent = 2; }

[0384] Along with the search results (if any), search backends return the refined intent.

[0385] Refined intent contains the requested geo entities as provided in the destination set of the original intent, or the next level in geo scope hierarchy.

[0386] • origin is either the requested origin from the explore intent or an updated origin used by the backend to answer the request, e.g. origin can be London (City) in the request, but the search backend translates it to London Heathrow (Airport).

[0387] • available geo informs USS, which geo entities the backend was able to return; this can be used in multiple ways: when backend wants to recommend / filter the list of geo entities from the request, e.g. country entities 1,2, 3, 4, 5 where provided in the request, but only 1,3,5 satisfy the filter of being safe to travel to, so the available geo in the response intent may only include those; when backend is able to traverse to the lower level of geo hierarchy, e.g. request asks for geo scope ANYWHERE, and backend is able to return a list of recommended COUNTRY level entities;

[0388] • travel date represents a concrete or flexible range of dates when to travel: if the request does not define travel dates (i.e. date resolution is ANYTIME), backends can use this field to recommend the travel dates or simply provide the default value they used when searching the results; if the request defines more specific travel date (e.g. a specific month or a range of departure dates), the backends are expected to return the same value. Example backend search responses are: message BackendSearchResponse {

[0389] / / Gives information for the status of the request and if it requires more polling to be fully fetched.

[0390] SessionState session state = 1; oneof results wrapper {

[0391] SearchResultSet result set = 2; googl e . protobuf . Any opaque result = 3;

[0392] }

[0393] / / If action == REPLACED, prior results in the session are no longer valid

[0394] / / If action != REPLACED, prior results still stand

[0395] ResultAction action = 4;

[0396] / / Updated intent that is being responded by the backend

[0397] RefinedExplorelntent intent = 5; } message RefinedExplorelntent {

[0398] / / Explore backends can alter the origin to more specific

[0399] Geo origin = 1 ;

[0400] / / Retumed / Suggested Geo results

[0401] MultiGeo available_geo = 2; / / Returned / Suggested Geo results

[0402] / / Suggested travel dates

[0403] TravelDate travel date = 3;

[0404] }

[0405] Example USS Backends

[0406] An example USS backend is Travel Restrictions. Example query models for ‘Normal’ search are: Origin entity ID is mandatory (Country or City); Single destination entity ID is optional - if not set, data for all countries is returned; Results keyed by Country as a travel entity ID; NOT date aware. Example queries for ‘Advanced’ search are: ANYWHERE request returning data for all countries from origin city; COUNTRY list request returning data for selected countries; Filtered ANYWHERE list request returning data for all countries where restrictions == (LOW or MODERATE or HIGH); Filtered COUNTRY list request returning data for selected countries where restrictions == (LOW or MODERATE or HIGH).

[0407] An example USS backend is Destination Safety. Example query models for ‘Normal’ search are: No query parameters - all data returned on each request; Results keyed by Country as a travel entity ID; NOT date aware; HTTP only. Example queries for ‘Advanced’ search are: ANYWHERE request returning data for all countries; COUNTRY list request returning data for selected countries.

[0408] An example USS backend is Advanced Flights. Example query models for ‘Normal’ search are: Lookup into pre-prepared datasets supporting a variety of data access patterns include day / month / anytime. Example queries for ‘Advanced’ search are: ANYWHERE request returning data for all countries from origin city with date range; COUNTRY list request returning data for selected countries from origin city with date range; CITY list request returning data for selected cities from origin city with date range. Here, DateRange may be expressed as one of ANYTIME, YYMMDD range or Month(s).

[0409] An example USS backend is Deals. Example query models for ‘Normal’ search are: Origin entity ID as CITY or AIRPORT; List of destination entity IDs is optional (AIRPORT / CITY / COUNTRY); FromDate(Y / M / D) ToDate(Y / M / D); Optional limit on number of returned results. Example queries for ‘Advanced’ search are: ANYWHERE request returning N deals for all destinations from origin city with date range; COUNTRY list returning N deals for selected countries and date range. Here, DateRange may be expressed as one of ANYTIME, YYMMDD range or Month(s).

[0410] An example USS backend is Destination Recommender. Example query models for ‘Normal’ search are: City-level - Generates personalized recommendations of cities similar to an entered destination entity ID (city) - Parameters UTID, Origin Entity ID, Origin Country Code (Market), Destination Entity ID; Country-level - Generates personalized recommendations for countries similar to entered destination entity ID (country) - Parameters UTID, Origin Country Code (Market), Destination Entity ID (Country).

[0411] Worked Examples are: request context { inventory { inventory type : SEARCH INVENTORY TYPE DESTINATION S AFET Y

[0412] } inventory { inventory type : SEARCH INVENTORY TYPE TRAVEL RESTRICTIONS

[0413] }

[0414] } explore intent { origin { type: GEO TYPE CITY entity id: "27544008"

[0415] } destination { type: GEO TYPE ANYWHERE

[0416] } desired geo resolution: GEO TYPE COUNTRY }

[0417] In an example of backend querying, in step 501, BFF constructs and sends Search Intent to USS. Intent contains LONDON 'ANYWHERE' as the query geo scope. In step 502, Travel Restrictions sends an unfiltered response containing: List of country entity IDs; Travel restrictions data per country ID, as USS backend result. In step 503, USS Extracts list of matching destinations from Travel Restrictions response; optionally Ranks / truncates matching destinations list to keep within query constraints; Dispatches a new Search Intent containing list of destinations to remaining search backend (Destination Safety). In step 504, USS constructs a client response message containing Result payloads from Travel Restrictions and Destination Safety; and a List of matching destinations as entity IDs. In step 505, USS returns result to BFF. An example is shown in Figure 5. An example search request is: request context { inventory { inventory type : SEARCH INVENTORY TYPE TRAVEL RESTRICTIONS

[0418] } inventory { inventory type : SEARCH INVENTORY TYPE DEALS

[0419] } inventory { inventory type: SEARCH INVENTORY TYPE FLIGHTS INDICATIVE

[0420] } } explore intent { origin { type: GEO TYPE CITY entity _id: "27544008" } destination { type: GEO TYPE COUNTRY entity _id: " 1" entity _id: "2" entity _id: "3" entity _id: "4" } desired geo resolution: GEO TYPE COUNTRY travel date { resolution: DATE RESOLUTION MONTH flexible dates { month_of_year: 5 } } modifier { modifier type: TRIP MODIFIER TYPE TRAVEL RESTRICTIONS LOW } }

[0421] In an example of backend querying, in step 601, BFF constructs and sends Search Intent to USS. Intent contains LONDON 'COUNTRY[1,2,3,4]' as the query geo scope. In step 602, based on geo scope and filter parameters in the Search Intent, USS determines that Travel Restrictions should be used to generate suggested destinations by applying filter parameters. The Search Intent is dispatched to the Travel Restrictions USS Backend. Travel Restrictions returns a USS Backend Response containing: List of destinations (country entity IDs) matching filter parameters; Travel Restrictions data for each matching country. In step 603, USS Extracts list of matching destinations from Travel Restrictions response; optionally Ranks / truncates matching destinations list to keep within query constraints; Dispatches a new Search Intent containing list of destinations to remaining search backends (Advanced Flights Search, Destination Safety and Deals). In step 604, USS constructs a client response message containing Result payloads from Travel Restrictions, Advanced Flights Search, Destination Safety and Deals; and a List of matching destinations as entity IDs. In step 605, USS returns result to BFF. An example is shown in Figure 6. An example search request is: request context { inventory { inventory type : SEARCH INVENTORY TYPE TRAVEL RESTRICTIONS

[0422] } inventory { inventory type : SEARCH INVENTORY TYPE DEALS

[0423] } inventory { inventory type: SEARCH INVENTORY TYPE FLIGHTS INDICATIVE

[0424] } } explore intent { origin { type: GEO TYPE CITY entity _id: "27544008"

[0425] } destination { type: GEO TYPE CITY entity _id: " 111" entity _id: "222" entity _id: "333" entity _id: "444" } desired geo resolution: GEO TYPE CITY travel date { resolution: DATE RESOLUTION RANGE flexible dates { departure date { from { year: 2021 month: 4 day: 10 } to { year: 2021 month: 5 day: 10 } } } } modifier { modifier type: TRIP MODIFIER TYPE TRAVEL RESTRICTIONS LOW } }

[0426] In an example of backend querying, in step 701, BFF constructs and sends Search Intent to USS. Intent contains LONDON 'CITYfl 11,222,333,444]' as the query geo scope. Intent contains CITY as the target geo scope to be returned as results. In step 702, based on geo scope and filter parameters in the Search Intent, USS determines that Travel Restrictions should be used to suggest country destinations by applying the provided trip modifier (i.e.

[0427] TRIP MODIFIER TYPE TRAVEL RESTRICTIONS LOW). Here, Travel Restrictions requires COUNTRY level input. In step 703, USS calls "common geo API" to get the list of countries: "common geo API" responds with: the list of countries associated with the cities provided in the original request. In step 704, the updated Search Intent (with the entities of COUNTRY level) is dispatched to the Travel Restrictions USS Backend. Travel Restrictions returns a USS Backend Response containing: List of destinations (country entity IDs) matching the provided filter; Travel Restrictions data for each matching country. In step 705, USS Extracts list of matching CITY destinations from Travel Restrictions response; Optionally Ranks / truncates matching destinations list to keep within query constraints; Dispatches a new Search Intent containing list of destinations to remaining search backends: Advanced Flights - returns city level indicative flights prices for the destination countries as results; Destination Safety - returns destination restrictions for the set of destination countries; Deals - returns deals to the set of destination countries. In step 706, USS constructs a client response message containing: Result payloads from Travel Restrictions, Advanced Flights, Destination Safety and DEALS; List of matching destinations as entity IDs. In step 707, USS returns result to BFF.

[0428] Common Geo API

[0429] Geo entity data is an important element of the ‘Normal’ search and ‘Advanced’ search solution.

[0430] The following geo related use cases have been identified for USS ‘Advanced’ components:

[0431] Advanced Flights requires translation of geo entity IDs to route node IDs used internally to create the required cache keys;

[0432] In an example, BFF / USS client layer needs to map the viewport coordinates to a list of visible entity IDs;

[0433] In an example, BFF / USS client needs to map from entity IDs into places on the map using geo coordinates, which are readily available in geo entity data;

[0434] Given any entity ID with a country, retrieve country ID; Retrieve airport child nodes for a given entity ID.

[0435] These queries are supported by the Travel API, which can be accessed directly or through a convenient Travel API java client.

[0436] In an example, the USS does not integrate with geo service itself. Instead, the USS client and backends perform the desired mapping suitable for their purpose. In an example, geo enrichment is provided as an optional feature of the USS API, e.g. adding geo data to entity IDs returned from an ‘Advanced’ search query. Other Features

[0437] Some scenarios require ‘Advanced’ search results with different geo resolution.

[0438] (e.g. Show map prices for cities in USA but country-level prices for adjacent Carribbean countries). How may the USS query model support this? This is handled by making multiple requests to USS with different geo scoped queries. This results in extra calls to USS but is still reasonably efficient.

[0439] The USS may enrich location entities with Geo coordinates in results. This saves the client / BFF from extra work. USS may include an enrichment function to append geo information to requested and returned entity IDs.

[0440] Use USS to expose indicative prices and other information for non-traveller queries (e.g. Provide a Search engine optimization (SEO) page with indicative pricing or point of interest (POI) data for a destination or airline route). If the query includes the correct starting and target geo scopes, the refinement algorithm should carry this out. For example, Query Scope = CITY(12335); Target Scope = CITY; InventoryTypes = Advanced Flights, TRAVEL RESTRICTIONS.

[0441] Language and Frameworks

[0442] In an example, the USS Service is written in Java and deployed in Cells. In an example, the client-facing API contract supports both Protobuf-over-HTTP and gRPC (gRPC is preferred); USS backend integrations support both Protobuf-over-HTTP and gRPC (HTTP is supported, gRPC is implemented in this design and is the preferred integration approach for backends deployed in Cells).

[0443] Note

[0444] It is to be understood that the above-referenced arrangements are only illustrative of the application for the principles of the present invention. Numerous modifications and alternative arrangements can be devised without departing from the spirit and scope of the present invention. While the present invention has been shown in the drawings and fully described above with particularity and detail in connection with what is presently deemed to be the most practical and preferred example(s) of the invention, it will be apparent to those of ordinary skill in the art that numerous modifications can be made without departing from the principles and concepts of the invention as set forth herein.

Claims

CLAIMS1. A computer-implemented method of responding to a user travel search query, which may be a general travel search query, the method including the steps of:(i) a back end for front end (BFF) receiving the user travel search query;(ii) the BFF processing the user travel search query to define a BFF travel search query, the BFF travel search query including (a) an origin, (b) an inventory list type, (c) a specified geo-type target resolution for one or more destinations, (d) a query boundary including a geo-type defining the one or more destinations, (e) a date scope, and (f) filtering criteria;(iii) the BFF sending the BFF travel search query to a Unified Search Service (USS), the USS starting a search at an initial geo-type level in a geographical hierarchy;(iv) the USS selecting backends according to the geo-type level in the geographical hierarchy, and according to the date scope;(v) the USS calling the selected backends in relation to the BFF travel search query, and receiving any search results sets from the selected backends, and any updates to the BFF travel search query;(vi) including in a USS response set the received search result sets;(vii) updating the BFF travel search query using any received updates to the BFF travel search query;(viii) repeating steps (iv) to (vii), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;(ix) the USS applying a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;(x) the USS returning the reduced USS response set to the BFF;(xi) the BFF processing the reduced USS response set to produce a processed reduced USS response set, and responding to the user travel search query using the processed reduced USS response set.

2. The method of Claim 1, in which a query grammar for BFF travel search queries is: "With Origin (ORIGIN), show results of type (INVENTORY LIST) at (TARGET RESOLUTION) resolution for destination(s) (QUERY BOUNDARY)filtered by (FILTER LIST) for dates (DATE SCOPE)".

3. The method of Claims 1 or 2, in which the data type geo-type identifies a depth in the (e.g. Skyscanner) Geographical Hierarchy e.g. ANYWHERE, COUNTRY, CITY, PLACE.

4. The method of any previous Claim, wherein the filtering criteria include a data type FILTER LIST which is a List of Trip Modifier constraints to be applied by USS backends; this contains a filter type enumeration, optionally plus parameters.

5. The method of any previous Claim, wherein the filtering criteria include a filter list of a data type TRIP MODIFIER which defines query filters: enumerated constraints used to restrict results returned from USS.

6. The method of Claim 5, wherein the constraints are evaluated by one or more of the USS backends orchestrated by the USS service itself, e.g. Travel Restrictions may be set as LOW or MODERATE.

7. The method of any previous Claim, in which the date scope identifies a date scope of ANYTIME, or MONTH(s), or DATE(s).

8. The method of any previous Claim, in which the date scope includes flexible departure dates.

9. The method of any previous Claim, in which the date scope includes flexible duration of the trip.

10. The method of any previous Claim, in which the origin identifies an origin location for the traveller, with a Travel Entity ID and a geo-type, eg. CITY(«EntityId»).

11. The method of any previous Claim, in which the inventory list type is a List of Search Inventory type enumerations, e.g. Search backend identifiers.

12. The method of any previous Claim, in which the geo-type target resolution defines the query's target scope: the geographical resolution required for results, e.g. COUNTRY, or CITY, or AIRPORT.

13. The method of any previous Claim, in which the query boundary defines a query starting scope, defining a boundary for the recommendations and suggestions query space, e.g. I am looking at ANYWHERE destinations, or I am looking at this list of six CITIES.

14. The method of any previous Claim, in which the date scope is defined by a DATE RESOLUTION identifier (e.g. ANYTIME, SEASON, MONTH etc) andoptionally parameters.

15. The method of any previous Claim, in which the date scope identifies a resolution and parameters.

16. The method of any previous Claim, in which the USS suggests, ranks and retrieves search inventory for travellers.

17. The method of any previous Claim, in which the Unified Search Service (USS) is configured to perform ‘Normal’ searches, and in which the USS is configured to perform ‘Advanced’ searches.

18. The method of any previous Claim, in which the BFF request specifies a 'Geo Scope', which is a 'root node(s)' in the geographical hierarchy.

19. The method of any previous Claim, in which the USS coordinates a process to traverse the geographical hierarchy from the root node using suggestion and filtering logic selected by the client.

20. The method of Claim 19, in which the USS uses data provided by other services in the search domain to coordinate the process to traverse the geographical hierarchy from the root node using suggestion and filtering logic selected by the client.

21. The method of any previous Claim, in which a search starts at root node(s) in the hierarchy and ends when nodes at a specified depth in the hierarchy have been identified and returned to the client.

22. The method of any previous Claim, in which the BFF is in communication with the USS via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf).

23. The method of any previous Claim, in which the USS is in communication with search backends (e.g. for flights, for hotels, for vehicle hire) via an interface, e.g. an interface using gRPC / HTTP (e.g. protobuf).

24. The method of Claims 22 or 23, in which for each interface there is provided a corresponding inventory schema.

25. The method of Claims 22 or 23, in which a common inventory schema is used for the interfaces.

26. The method of Claim 25, in which the common inventory schema uses protobuf.

27. The method of any previous Claim, in which a user does not need to integrate with multiple backends individually.

28. The method of any previous Claim, in which a user needs to specify theirquery only once.

29. The method of any previous Claim, in which USS search backends implement server-side filtering.

30. The method of any previous Claim, in which filter constraints are expressed in the USS backend interface and are implemented by all participating ‘Advanced’ search backends.

31. The method of any previous Claim, in which a (e.g. BFF) component outside of USS identifies entity IDs e.g. visible in a map (based on zoom level), in order to populate the USS request.

32. The method of any previous Claim, in which in the event that a dependency is not available, the search fails fast and uses fallback data sources to approximate an ‘Advanced’ search result.

33. The method of any previous Claim, in which the USS uses a static, in-memory alternative list of suggested locations if it is unable to retrieve personalized recommended locations within a predetermined time frame.

34. The method of any previous Claim, in which the method includes a refinement process including: Generating suggested locations; Filtering and / or ranking suggestions; Dispatching queries to 'Advanced' search backends for data related to these locations, and Aggregating and returning results.

35. The method of any previous Claim, in which the USS uses a destination suggestion backend to generate possible destinations based on a requested Geo Scope and filters.

36. The method of Claim 35, in which the suggestions are returned from the backend as a list of Entity IDs that meet the query criteria.

37. The method of any previous Claim, in which the USS dispatches this list of entity IDs to other backends along with backend filtering criteria; and the results returned from these backends contain a new list of Entity IDs that match only the specified backend filter criteria.

38. The method of any previous Claim, in which the USS queries any remaining backends to retrieve outstanding results for the filtered entity IDs.

39. The method of any previous Claim, in which during a refinement process, the USS forms a dynamic pipeline, which defines in which order the backends are called.

40. The method of Claim 39, in which backends called first are used to refine,suggest and / or filter the provided query into a more specific one, e.g. transform the initial geo scope of anywhere to a list of countries safe to travel to.

41. The method of Claims 39 or 40, in which the performance of the pipeline is defined by a priority of the components in the pipeline.

42. The method of any previous Claim, in which the USS determines the order to query the backends using the provided filters in the explore query.

43. The method of any previous Claim, in which when a query contains a recommendation request, the USS asks a "destination suggester" backend to get recommendations.

44. The method of any previous Claim, in which the USS imposes a limit on the number of entities included in the BFF request.

45. The method of any previous Claim, in which the USS imposes a limit of the number of entities included in a request to a backend service.

46. The method of Claim 45, in which in order to satisfy a client-facing request, the USS makes more than one request to a USS backend in order to stay within the limit.

47. The method of any previous Claim, in which the USS truncates the list of suggested destinations after applying prioritization and ranking.

48. The method of any previous Claim, in which the BFF handles mapping USS SearchResult schema elements (backend-specific) to front-end needs.

49. The method of any previous Claim, in which the BFF translates between map coordinates and travel entity IDs.

50. The method of any previous Claim, in which the BFF includes enrichment logic to return text copy, or images, or videos or other content about destinations.

51. The method of any previous Claim, in which the USS includes ranking of the results set of returned inventory.

52. The method of any previous Claim, in which the USS includes combining the results of multiple backends into a single response.

53. The method of any previous Claim, in which the search backends provide a schema for the inventory type.

54. The method of any previous Claim, in which a search backend applies a query model, such as server-side filtering.

55. The method of any previous Claim, in which the USS server implementationitself is stateless and includes no caching of results.

56. The method of any previous Claim, in which the USS Backends implement their own caching strategies.

57. The method of any previous Claim, in which the BFF provides to the user a map interface, and the BFF receives a selection of where the user wants to go to, as the destination(s).

58. The method of Claim 57, in which the map interface shows travel restrictions & destination safety information.

59. The method of Claim 58, in which backends queried include TravelRestrictions, Destination Safety.

60. The method of Claim 58, in which backends queried include TravelRestrictions, Advanced Flights, Destination Safety, Deals.

61. The method of any previous Claim, in which a map is shown to the user with personalized recommended destinations.

62. The method of Claim 61, in which Backends queried include Travel Restrictions, Advanced Flights, Destination Safety, Deals, Destination Recommender(s).

63. The method of any previous Claim, in which a map is shown to the user with hotel indicative pricing or with trips pricing.

64. The method of any previous Claim, in which the USS processes as input Shorthand names for geographical groupings, such as "the Alps", "the Riviera".

65. The method of any previous Claim, in which search backends return refined intent which contains the requested geo entities as provided in the destination set of the original intent, or the next level in geo scope hierarchy.

66. The method of any previous Claim, in which search backends return an origin which is either the requested origin or an updated origin used by the backend to answer the request.

67. The method of any previous Claim, in which if the request does not define travel dates (i.e. date resolution is ANYTIME), backends can use this field to recommend the travel dates or simply provide the default value they used when searching the results.

68. The method of any previous Claim, in which available geo informs USS, which geo entities the backend was able to return.

69. The method of any previous Claim, in which the USS backends include Advanced Flights, e.g. in which queries include one or more of: ANYWHERE request returning data for all countries from origin city with date range; or COUNTRY list request returning data for selected countries from origin city with date range; or CITY list request returning data for selected cities from origin city with date range.

70. The method of any previous Claim, in which the USS backends include Destination Recommender, e.g. in which queries include one or more of: City-level - Generates personalized recommendations of cities similar to an entered destination entity ID (city) - Parameters UTID, Origin Entity ID, Origin Country Code (Market), Destination Entity ID; Country-level - Generates personalized recommendations for countries similar to entered destination entity ID (country) - Parameters UTID, Origin Country Code (Market), Destination Entity ID (Country).

71. The method of any previous Claim, in which in backend querying: BFF constructs and sends Search Intent to USS (501); Travel Restrictions sends an unfiltered response containing: List of country entity IDs; Travel restrictions data per country ID, as USS backend result (502); USS Extracts list of matching destinations from Travel Restrictions response (503); optionally Ranks / truncates matching destinations list to keep within query constraints; Dispatches a new Search Intent containing list of destinations to remaining search backend (Destination Safety); USS constructs a client response message containing Result payloads from Travel Restrictions and Destination Safety (504); and a List of matching destinations as entity IDs; USS returns result to BFF (505).

72. The method of any previous Claim, in which the USS includes location entities with Geo coordinates in results.

73. The method of any previous Claim, in which the USS includes appending geo information to requested and returned entity IDs.

74. The method of any previous Claim, in which the USS is written in Java and deployed in Cells.

75. The method of any previous Claim, including the step of storing the processed reduced USS response set, or storing the reduced USS response set.

76. A system including a BFF server, a USS server and backend servers, thesystem configured to perform a method of any previous Claim.

77. A computer-implemented method of responding to a user travel search query, which may be a general travel search query, including the steps of:(i) a BFF sends a BFF travel search query to a Unified Search Service (USS), the USS starting a search at an initial geo-type level in a geographical hierarchy;(ii) the USS selecting backends according to the geo-type level in the geographical hierarchy, and according to the date scope;(iii) the USS calling the selected backends in relation to the BFF travel search query, and receiving any search results sets from the selected backends, and any updates to the BFF travel search query;(iv) including in a USS response set the received search result sets;(v) updating the BFF travel search query using any received updates to the BFF travel search query;(vi) repeating steps (ii) to (v), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;(vii) the USS applying a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;(viii) the USS returning the reduced USS response set to the BFF.

78. The method of Claim 77, the method including a method of any of Claims 1 to 75.

79. A system including a BFF server, a USS server and backend servers, the system configured to perform a method of any of Claims 77 or 78.

80. A computer-implemented method of responding to a user travel search query, which may be a general travel search query, including a USS lowering a depth of a searched geo-type level in a geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches a specified geo-type target resolution.

81. The method of Claim 80, the method including a method of any of Claims 1 to75.

82. A system including a USS server and backend servers, the system configured to perform a method of any of Claims 80 or 81.

83. A system including a BFF server and a USS server, the USS server in communication with backend servers, the system configured to respond to a user travel search query, which may be a general travel search query, in which:(i) the back end for front end (BFF) server is configured to receive the user travel search query;(ii) the BFF server is configured to process the user travel search query to define a BFF travel search query, the BFF travel search query including (a) an origin, (b) an inventory list type, (c) a specified geo-type target resolution for one or more destinations, (d) a query boundary including a geo-type defining the one or more destinations, (e) a date scope, and (f) filtering criteria;(iii) the BFF server is configured to send the BFF travel search query to a Unified Search Service (USS) server, the USS server configured to start a search at an initial geo-type level in a geographical hierarchy;(iv) the USS server is configured to select backends according to the geo-type level in the geographical hierarchy, and according to the date scope;(v) the USS server is configured to call the selected backends in relation to the BFF travel search query, and to receive any search results sets from the selected backends, and any updates to the BFF travel search query;(vi) the USS server is configured to include in a USS response set the received search result sets;(vii) the USS server is configured to update the BFF travel search query using any received updates to the BFF travel search query;(viii) the USS server is configured to repeat (iv) to (vii), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;(ix) the USS server is configured to apply a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;(x) the USS server is configured to return the reduced USS response set to the BFFserver;(xi) the BFF server is configured to process the reduced USS response set to produce a processed reduced USS response set, and to respond to the user travel search query using the processed reduced USS response set.

84. The system of Claim 83, the system configured to perform a method of any of Claims 1 to 75.

85. A BFF server of Claim 83 or 84.

86. A USS server of Claim 83 or 84.

87. A system including a BFF server and a USS server, the USS server in communication with backend servers, the system configured to respond to a user travel search query, which may be a general travel search query, in which:(i) the BFF server is configured to send a BFF travel search query to the Unified Search Service (USS) server, the USS server configured to start a search at an initial geo-type level in a geographical hierarchy;(ii) the USS server configured to select backends according to the geo-type level in the geographical hierarchy, and according to the date scope;(iii) the USS server configured to call the selected backends in relation to the BFF travel search query, and to receive any search results sets from the selected backends, and any updates to the BFF travel search query;(iv) the USS server is configured to include in a USS response set the received search result sets;(v) the USS server is configured to update the BFF travel search query using any received updates to the BFF travel search query;(vi) the USS server is configured to repeat (ii) to (v), including lowering a depth of a searched geo-type level in the geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches the specified geo-type target resolution;(vii) the USS server is configured to apply a reduction algorithm on the USS response set, using the filtering criteria, to produce a reduced USS response set;(viii) the USS server is configured to return the reduced USS response set to the BFFserver.

88. The system of Claim 87, the system configured to perform a method of any of Claims 1 to 75.

89. A BFF server of Claim 87 or 88.

90. A USS server of Claim 87 or 88.

91. A Unified Search Service (USS) server, the USS server in communication with backend servers, the USS server configured to call selected backend servers in relation to a travel search query received from a BFF server, in relation to responding to a user travel search query, which may be a general travel search query, in which the USS server is configured to lower a depth of a searched geo-type level in a geographical hierarchy, until no backends remain to be queried, or until the geo-type level reaches a specified geo-type target resolution.

92. The USS server of Claim 91, configured to perform a method of any of Claims 1 to 75.

Images