A PROCESSOR-EXECUTED METHOD; A SEARCH SERVER AND A COMPUTER-READABLE METHOD AND MEDIA FOR EXTENDING CONTEXTUAL SEARCH

Abstract

This specification describes a system, apparatus, and method for extending contextual search. A processor receives query parameters from a user and performs a primary search across various search engines to generate initial results. These results are aggregated into electronic credits that refine and expand the search criteria. The processor then performs secondary searches, generating alternative options, and compares the aggregated results to a predefined threshold. If the threshold is reached, the secondary results are displayed to the user. The system leverages advanced algorithms and artificial intelligence to dynamically adjust search parameters and thresholds to reduce the total number of searches over time.

Description

Title of the invention: METHOD PERFORMED BY A PROCESSOR; SEARCH SERVER AND METHOD AND COMPUTER-READABLE MEDIA FOR THE EXTENSION OF CONTEXTUAL RESEARCH

[0001] This specification generally relates to computer and network search, storage and retrieval, and more specifically to the extension of contextual search. Context

[0002] The vast majority of electronic searches are now conducted online, presenting numerous technical challenges. During peak periods, popular platforms often experience significant traffic, leading to potential server performance issues or even outages. This shift to online access also demands extensive data storage capacity, as the system must manage large volumes of information related to reservations, user profiles, and ticket details. Furthermore, real-time data processing is essential for up-to-date availability checks, but this instantaneous processing can place a significant burden on system resources, especially with numerous simultaneous requests. In addition, the complexity of user searches has increased, involving detailed and complex queries that, in turn, require substantial computing power and memory.In general, the increasing complexity of search requests can increase pressure on the system. These evolving requirements can lead to inefficiencies and increased latency, placing additional strain on the existing infrastructure. Summary

[0003] One aspect of the specification provides a computer-implemented method for extending contextual search, the method including: receiving, at the processor level, a first set of travel request parameters; performing, at the processor level, a primary search of at least one travel actor engine for a first electronic itinerary based on the first set; receiving, at the processor level, the primary results of the primary search; determining, at the processor level, a first aggregation of electronic credits from the primary results; generating, at the processor level, a second set of travel request parameters based on a contextual extension of the first set and the first aggregation; and performing, at the at the processor level, a secondary search of at least one travel actor engine for a second electronic itinerary based on the first set; the reception, at the processor level, of the secondary results of the secondary search from said at least one travel actor engine; the determination, at the processor level, of a second aggregation of electronic credits of the secondary results; the determination, at the processor level, of a difference between the first aggregation and the second aggregation; if the difference is greater than or equal to a predefined threshold, the control of an output device of a client device to generate the secondary results in response to the first set of travel request parameters; otherwise, the repetition of the generation of the second set of travel request parameters and the performance of the secondary search until the predefined threshold is met.

[0004] One aspect of the specification provides a method, wherein the first set of travel request parameters includes one or more optional parameters selected from the group consisting of: class preferences, preferred airlines, CO2 emission limits, time of day, number of stopovers, maximum stopover duration, specific airports, budget constraints, seat preferences, meal preferences, and loyalty program memberships.

[0005] One aspect of the specification provides a method, in which the contextual extension of the first set of travel request parameters includes expanded date ranges, alternative airports, alternative classes, alternative airlines, additional stopover locations, extended lengths of stay, various types of accommodation, and additional benefits selected from the group consisting of: lounge access, teleworking spaces, relaxation time allowances, car rentals, and travel insurance options.

[0006] One aspect of the specification provides a method in which the predefined threshold is based on a financial value, a loyalty point value, or a combination of both.

[0007] One aspect of the specification provides a method, in which the predefined threshold is based on the reduction of a total number of primary searches received by the search engines of travel actors.

[0008] One aspect of the specification provides a method, in which secondary search is performed if the price of the first electronic route exceeds a multiple of a minimum price threshold.

[0009] One aspect of the specification provides a method, in which secondary results include alternative travel itineraries that are generated on the basis of conditions such as changing travel dates, classes and the integration of additional services.

[0010] One aspect of the specification provides a method, in which the contextual extension is based on the reduction of a total number of primary searches received by travel actor engines.

[0011] One aspect of the specification provides a method, in which the first and second aggregation of electronic credits include calculations of total cost, possible rewards, and route-related disadvantages.

[0012] One aspect of the specification provides a method, in which the processor dynamically adjusts the second set of travel demand parameters based on business rules and artificial intelligence to influence secondary search with the aim of reducing over time the total number of primary searches received at the travel actor search engines.

[0013] One aspect of the specification provides a method, including integration into a rewards calculator to evaluate and aggregate electronic credits associated with different travel options.

[0014] One aspect of the specification provides a method, in which the processor controls the output device to display both the primary and secondary results for comparison by the user.

[0015] One aspect of the specification provides a method, in which the processor continues to refine the search parameters and threshold values ​​using machine learning algorithms to reduce the total number of searches performed on travel actor engines.

[0016] One aspect of the specification provides a method, in which the predefined threshold varies on the basis of the purpose of the journey.

[0017] One aspect of the specification provides a method, in which at least one of the contextual extension and threshold values ​​are continuously adjusted by machine learning algorithms to increase a number of reservations with a view to aligning with the number of search results generated.

[0018] Another aspect of the specification provides a search server.

[0019] Another aspect of the specification provides a computer-readable medium.

[0020] This specification also considers computer-readable methods, systems, devices and media in accordance with the foregoing. Brief description of the drawings

[0021] This specification includes the attached Figures, in which:

[0022] Fig. 1 presents a contextual search extension system.

[0023] [Fig.2] presents a schematic diagram of a non-limiting example of internal components of the search engine of [Fig.1].

[0024] [Fig.3] presents a schematic diagram of a non-limiting example of a stack of components associated with the search engine of [Fig.2].

[0025] Figure 4 presents a flowchart describing a method for extending the contextual search. Detailed description

[0026] Figure 1 presents a contextual search extension system, generally denoted as 100. System 100 comprises a plurality of journey actor engines 104-1, 104-2 ... 104-n (collectively, engines 104-1, 104-2 ... 104-n are referred to as engines 104, and generically as engine 104. This nomenclature is used elsewhere herein.) In System 100, the engines 104 connect to a network 108 such as the Internet. The network 108 interconnects the journey actor engines 104 to a plurality of client devices 116, at least one administrator terminal 118, and a search engine 120. As discussed further below, the search engine 120 performs a number of processing functions for System 100.

[0027] Travel actor engines 104 can be based on any existing or future electronic server or computing architectures that, among other things, manage electronic reservations for transportation, accommodation, meals, and / or any other travel-related reservation function. For example, travel actor engines for transportation 104 can manage reservations for airlines, trains, car rentals, and ride-sharing services.These 104 search engines can interface with various providers and systems, such as Global Distribution Systems (GDS) like Amadeus™, Sabre™, and Travelport™, which aggregate booking information from multiple airlines. Furthermore, they can utilize New Distribution Capability (NDC) standards for direct connections to airlines, enabling more personalized and dynamic offers. Aggregator sites like Expedia™ and Kayak™ can also be integrated to provide a comprehensive view of available travel options.

[0028] Accommodation provider engines can manage reservations for hotels, vacation rentals, and other accommodation options. These engines can connect to hotel chains (e.g., Marriott™, Hilton™), online travel agencies (e.g., Booking.com™, Expedia™), and home-sharing platforms (e.g., Airbnb™, VRBO™) to facilitate seamless booking experiences for travelers. By aggregating data from these sources, search engines can offer a wide selection of accommodations and guarantee real-time availability and pricing.

[0029] Meal booking engine actors can coordinate meal reservations and meal plans, integrating them with restaurant reservation systems (e.g., OpenTable™, Resy™) and booking services to provide travelers with suitable dining options. These engines ensure that travelers can easily reserve tables at their favorite restaurants or arrange meal services during their trips, thus enhancing the overall travel experience.

[0030] The search engine 120 can be any type of electronic server or computer architecture that facilitates search and booking interactions between customer devices 116 and travel actor engines 104.

[0031] The client devices 116 can be any type of human-machine interface for interacting with the search engine 120. For example, the client devices 116 can include traditional laptops, desktop computers, mobile phones, tablets, and any other device that can be used to receive and send content that complements the hardware input and output devices associated with a given client device 116. It is envisaged that the client devices 116 could include virtual or augmented reality equipment complementary to the virtual or augmented reality or "metaverse" environments that may be offered on the collaboration engines 104.The client devices 116 can be operated by different users 124 who are associated with a respective identifier 128 which uniquely identifies a given user 124 when accessing a given client device 116 in the system 100.

[0032] The administrator terminal 118 can also be any type of human-machine interface of the same types as the client devices 116. The administrator terminal 118 is operated by an administrator 126. In one present embodiment, there is a single administrator terminal 118 for all the journey actor engines 104 and all the client devices 116. In variants, when the system 100 is scaled up, a plurality of administrator terminals 118 can be provided, which correspond to one or more journey actor engines 104 and / or a plurality of administrator terminals 118 can be provided, which correspond to one or more client devices 116.

[0033] This specification considers scenarios in which users 124 may want to search for electronic travel itineraries via one or more travel actor engines 104 that store and / or calculate such electronic itineraries.

[0034] The administrator 126 operates the administrator terminal 118 and receives input representing configuration datasets defining parameters that are used in an extension of contextual search based on search requests from client devices 116 to the search engine 120. The administrator 126 might be, for example, a representative from the human resources department of a company that employs users 124 and establishes travel guidelines and / or policies. It should be understood, however, that these human factors are provided for a complete description and for the implementation context of the present teachings, but the technical teachings herein are directed toward the purpose, among other things, of reducing unnecessary searches on travel actor search engines 104 and increasing alignment between searches and actual bookings.

[0035] Consequently, the client devices 116 are based on any suitable client computer platform operated by the users 124 who may have an interest in the content provided by the engines 104. Each device 116 and its user 124 are thus typically associated with a user identifier 128, particularly if the booking functions are to be used.

[0036] A person skilled in the art recognizes that the form of an identifier 128 is not particularly limited, and in a simple exemplary embodiment, can simply be an alphanumeric sequence that is entirely unique with respect to identifiers in the system 100. Identifiers can also be more complex, such as combinations of account identification information (e.g., username, password, two-factor authentication token, etc.) that uniquely identify a given user 124. The identifiers themselves can also be indexes that refer to other identifiers, such as one or more accounts. The essential point is that they are uniquely identifiable in the system 100 in association with what they represent.Identifiers 128 may include profiles and other demographic information associated with their respective users 124 which can be used as part of an extension of contextual search.

[0037] Having described an overview of system 100, it is useful to comment on the hardware infrastructure of system 100. [Fig.2] presents a schematic diagram of a non-limiting example of internal components of search engine 120.

[0038] In this example, the search engine 120 includes at least one input device 204. The input from device 204 is received by a processor 208, which in turn controls an output device 212. The input device 204 can be a traditional keyboard and / or a mouse to provide physical input. Similarly, the output device 212 can be a screen. In variations, input devices Additional 204 and / or other or 212 output devices are envisaged or may be omitted together, if the context requires it.

[0039] The processor 208 can be implemented as a plurality of processors or as one or more multi-core processors. The processor 208 can be configured to execute different programming instructions in response to the input received via said one or more input devices 204 and to control one or more output devices 212 in order to generate the output on these devices.

[0040] In order to perform its programming functions, the process 208 is configured to communicate with one or more memory units, including non-volatile memory 216 and volatile memory 220. The non-volatile memory 216 can be based on any persistent memory technology, such as electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state drive (SSD), another type of hard drive, or combinations thereof. The non-volatile memory 216 can also be described as a non-transient, computer-readable medium. Similarly, more than one type of non-volatile memory 216 can be provided.

[0041] Volatile memory 220 is based on any random access memory (RAM) technology. For example, volatile memory 220 can be based on dual-speed synchronous dynamic random access memory (SDRAM) or dual-rate dynamic random access memory (DDR). Other types of volatile memory 220 are envisaged.

[0042] The processor 208 also connects to the network 108 via a network interface 232. The network interface 232 can also be used to connect to another computing device which has an input and output device, thus avoiding the need for the input device 204 and / or the output device 212 together.

[0043] Programming instructions in the form of applications 224 are typically stored continuously in non-volatile memory 216 and used by the processor 208, which reads from and writes to volatile memory 220 during the execution of the applications 224. Various processes discussed herein can be coded as one or more applications 224. One or more arrays or databases 228 are stored in non-volatile memory 216 for use by the applications 224.

[0044] The infrastructure of search engine 120, or a variant thereof, can be used to implement any of the computing nodes in system 100, including the journey actor engines 104. Furthermore, search engine 120 and the journey actor engines 104 can also be implemented as virtual machines and / or with mirror images for load balancing. The functions of search engine 120 can also be distributed among the various journey actor engines 104, thus avoiding the need for a search engine. Central search 120. A plurality of orchestration engines 120 can be provided with the same token. Overall, the 104 engines and / or the 120 engine and other nodes in the 100 system can be implemented using cloud computing platforms such as Microsoft Azure™ or Amazon Web Services (AWS)™.

[0045] Furthermore, a person skilled in the art will recognize that the key elements of the processor 208, the input device 204, the output device 212, the non-volatile memory 216, the volatile memory 220 and the network interface 232, as described in relation to the search engine server environment 120, have analogies with the various form factors of client machines such as those that can be used to implement the client devices 116 and the administrator terminal 118. Again, the client devices 116 can be based on computer workstations, laptops, tablets, mobile phone devices or the like.

[0046] Fig. 3 provides another schematic representation of the search engine 120, in particular a detailed view of a stack 300 used in the computing environment of the search engine 120. The stack 300 is structured to depict the different layers involved in the operation of the search engine 120, from the application layer 304 to the physical hardware layer 340 of the search engine 120.

[0047] At the highest level, the 304 application layer encompasses various 224 applications and 308 application frameworks. 224 applications represent end-user software such as web browsers, email clients, and office suites that perform specific tasks. 308 application frameworks include libraries and frameworks that facilitate application development, such as .NET, Spring, and Django.

[0048] Below the application layer is the middleware layer 312, which includes arrays 228 and other middleware components. Middleware acts as an intermediary, providing services and capabilities common to applications beyond those offered by the operating system. Examples include database management systems, web servers (e.g., Apache, Nginx), and application servers (e.g., Tomcat).

[0049] The operating system layer 316 is composed of the operating system 320 and the core 324. The operating system 320 is the software system that manages hardware resources and provides essential services to computer programs. The core 324 is the central part of the operating system, responsible for managing system resources and facilitating communication between the hardware and software components.

[0050] The hardware abstraction layer 328 includes the drivers 332 and the firmware 336. The drivers 332 are software components that enable the operating system 320 and other software to communicate with the hardware devices shown in [Fig. 2]. Examples include device drivers for the input device 204, the output device 212, and the network interface 232. The firmware 336 can be software programmed into hardware devices of the physical hardware layer 340 to provide low-level control and communication.

[0051] At the base of the stack, there is the hardware and physical layer of the search engine 120, encompassing physical hardware components such as the input device 204, the processor 208, the non-volatile memory 216, the volatile memory 220 and the network interface 232.

[0052] The stack 300 illustrates how the different layers interact in a computer environment of the search engine 120, enabling the execution of various applications 228 and services, such as the applications 224. Each layer relies on the layer below it to function correctly, and together they form a coherent system that powers the computing capabilities of devices such as those used in the search engine 120, the travel actor engines 104, the client devices 116.

[0053] The 300 stack in [Fig.3] can be applied to various computing environments including other hardware nodes in the system 100, including server infrastructures for engines 104, client devices 116 and the administrator terminal 118. Whether implemented in a traditional server environment or as virtual machines on cloud computing platforms such as Microsoft Azure or Amazon Web Services (AWS), the described layers of the 300 stack provide a framework for managing and running software applications, such as applications 224 and middleware layers 312 such as databases 228.

[0054] Figure 4 shows a diagram describing a process for extending contextual search, generally indicated at 400. Process 400 can be implemented on system 100. Skilled individuals may choose to implement process 400 on system 100 or variants thereof, or by omitting certain blocks, executing them in parallel, or in a different order than shown. Process 400 can thus also vary. However, for explanatory purposes, process 400 will be described in relation to its execution on system 100, with an emphasis on processing method 400, for example, application 224-2 stored in search engine 120 and its interactions with other nodes of system 100. Process 400 also typically assumes that process 300, or a variant thereof, has already been executed and that a unit data set is already available in cache memory. non-volatile memory 216 or in volatile memory 220 or a combination of both.

[0055] Block 404 includes the reception of an initial set of travel request parameters. In the system 100, the travel request parameters originate from one of the client devices 116, with a respective user 124 providing at least the travel dates, departure, and destination in the usual manner. Block 404 may also include the reception of optional parameters such as preferred CO2 emission limits, class, time of day, preferred airlines, number of stopovers, maximum duration of the stopover(s), specific airports, budget constraints, seat preferences, meal preferences, and frequent flyer program memberships. The initial set of parameters thus forms the basis of the initial travel search and is received from a user 124 via an interface on the client devices 116, which connect to the processor 208 of the search engine 120.

[0056] Block 408 includes performing a primary search of at least one travel actor engine 104 based on the first set of travel request parameters from block 404. This search in block 408 is executed by processor 208, which interfaces with the travel actor engines 120 via network 108. Again, search engine 120 can handle electronic reservations for transportation, accommodation, and meals. Typically, block 408 would focus on the transportation actor engines 104. The primary search aims to find an electronic itinerary that matches the parameters provided in block 404.

[0057] Block 412 includes the reception of primary results from the primary search. These results provide the possible routes that meet the initial request parameters. The primary results are collected by processor 208 in one or more respective travel actor(s) engines 104 and typically include minimum details such as flight options but also accommodation options, meal options, etc.

[0058] Block 416 comprises a first aggregation of electronic credits associated with the primary results. The definition of electronic credits is not particularly limited, and this block 416 may include the calculation of the total cost and any potential reward or benefit (e.g., loyalty points) linked to the itineraries found in the primary search. The aggregation aims to normalize factors such as currency, different travel actors (e.g., different airlines on the same route, various hotels, ground transportation costs), and / or loyalty points in different programs and / or travel actors, into a value based on a metric that represents the unified and normalized cost of the itinerary from the primary results. Loyalty points may be considered in terms of loyalty points used or any loyalty points earned through the route, the former being added to the total aggregation while the latter are subtracted from the total aggregation.

[0059] Block 420 comprises the generation, at the processor level, of a second set of travel request parameters based on a contextual extension of the first set and the first aggregation. This step uses the initial search data and the aggregated electronic credits to refine and extend the search criteria. As will be seen later, block 420 and subsequent blocks aim to identify alternative travel routes with a lower value than that of the first aggregation.

[0060] Block 424 comprises performing a secondary search on said at least one travel actor engine based on the second set of travel request parameters. Block 424 effectively repeats block 408, but this time using the second set of travel request parameters rather than the first set from block 404. Block 424 can be executed by the processor 208 of the search engine 120 by accessing one or more travel actor engines 104, using the extended parameters to find a second electronic route that could potentially be more advantageous than the first.

[0061] Block 428 comprises the reception of secondary results from the secondary search. Block 428 effectively repeats block 412, but in the context of secondary results from the secondary search of block 424. The secondary results from block 428 are collected by processor 208 and typically include a different itinerary with at least some different flight options. The secondary results may also include alternative accommodations and various meal reservations from the initial results.

[0062] Block 432 comprises the determination of a second aggregation of electronic credits associated with the secondary results. Block 432 effectively repeats block 416 but calculates the total cost and any rewards or benefits associated with the itineraries found in the secondary search. Again, the aggregation aims to normalize factors such as currency, different travel providers (e.g., different airlines on the same route, various hotels, ground transportation costs), and / or loyalty points in different programs and / or travel providers, into a value based on a metric that represents the unified and normalized cost of the itinerary from the primary results.Again, loyalty points can be considered in terms of loyalty points used or potential loyalty points earned through the route, the former being added to the total aggregation while the latter are subtracted from the total aggregation.

[0063] Block 436 includes determining the difference between the first and second aggregations. Processor 208 of search engine 120 calculates the variance between the two sets of electronic credits to assess whether the secondary results offer improvements over the primary results.

[0064] Block 440 involves determining whether the difference between the first and second aggregations reaches or exceeds a predefined threshold. If the difference is greater than or equal to the threshold, the process proceeds to block 444; otherwise, the process returns to block 420 where it repeats the generation of the second set of travel request parameters and the secondary search until the threshold is reached.

[0065] The threshold itself can be set at a value where the secondary results provide a desired overall improvement in the aggregation. The threshold can also vary during each cycle from block 440 to block 420, possibly establishing a level that will trigger a "yes" determination at block 440 and lead to block 444.

[0066] Block 444 includes the control of an output device from a client device to generate secondary results in response to the first set of travel request parameters. Block 444 may also include the generation of initial results for comparison. Block 444 may also include the presentation of all secondary results that may be generated during multiple cycles of block 440 by returning to block 420. In system 100, block 444 includes the search engine 120 returning the results to the client devices 116 and the control of the display on the client devices 116 to present the results. At this point, the given user 124 of the client devices 116 can select one of the options and continue to refine the chosen itinerary by completing the booking.

[0067] To illustrate the application of the method 400, consider the following example. A user 124 needs to travel from London to Miami for a meeting with a client, scheduled from March 14 to March 17. The user initiates a search on the system 100 by entering the travel request parameters into a client device 116. These parameters include the travel dates, the departure (London), and the destination (Miami). The user can also include optional parameters such as class preferences, preferred airlines, etc.

[0068] Block 404 includes the reception of this first set of travel request parameters. System 100 inputs these parameters via an interface on the client device 116, which communicates with the processor 208 of the search engine 120.

[0069] In block 408, processor 208 performs a primary search using travel request parameters. Search engine 120 interfaces with various travel actor engines 104 that manage electronic transport reservations, accommodation and meals. For this example, the primary search focuses on transportation, specifically flights from London to Miami.

[0070] Block 412 includes the reception of primary results from the primary search. In this example, the primary results include a Business Class flight priced at EUR 6000. These results are collected by processor 208 and provide the possible routes that correspond to the parameters of the user's initial request.

[0071] Block 416 includes a first aggregation of electronic credits associated with the primary results. In this example, the electronic credits include the total cost of the flight (EUR 6000). The aggregation process normalizes factors such as currency and the various travel stakeholders, resulting in a unified metric representing the cost of the itinerary.

[0072] Block 420 involves the generation, at the processor level, of a second set of travel request parameters based on a contextual extension of the first set and the first aggregation. System 100 analyzes the initial search data and the aggregated electronic credits to refine and extend the search criteria. In this case, the contextual extension includes searching for a less expensive alternative, such as flying one day earlier in economy class and including additional options such as accommodation for the extra night and optional services.

[0073] Block 424 includes performing a secondary search using the second set of travel request parameters. Processor 208 executes this secondary search by accessing the travel actor engine 104 with the expanded parameters. The secondary search aims to find an alternative route that is more cost-effective than the primary result.

[0074] In block 428, processor 208 receives secondary results from the secondary search. These secondary results may include an economy class flight at a price of EUR 1000, an additional night of accommodation costing EUR 200, and optional services such as lounge access (EUR 200), a room for teleworking (EUR 200), compensation for relaxation time (EUR 300), and a car rental (EUR 200).

[0075] Block 432 includes the determination of a second aggregation of electronic credits associated with the secondary outcomes. System 100 calculates the total cost of the secondary itinerary, which includes the flight (1000 EUR), the additional night (200 EUR), and optional services, if selected by the user. To maintain the simplicity of the example, let us assume that no optional services are selected, and therefore the second aggregation is 1200 EUR. The aggregation process normalizes these factors into a unified metric representing the cost of the secondary route.

[0076] Block 436 involves determining the difference between the first and second aggregations. Processor 208 calculates the variance between the total costs of the primary and secondary routes. According to our example, the difference is 6000 EUR - 1200 EUR = 4800 EUR

[0077] Block 440 involves determining whether the difference between the first and second aggregations reaches or exceeds a predefined threshold. In this example, let us assume that the threshold is set at EUR 1000. Therefore, since EUR 4800 > EUR 1000, a "yes" determination is reached in block 440 and process 400 proceeds to block 444.

[0078] (It can also be noted that even if all the optional services are included: access to the lounge (EUR 200), a room for teleworking (EUR 200), compensation for relaxation time (EUR 300), and a car rental (EUR 200), the total additional aggregation is EUR 900. Therefore, the second total aggregation becomes EUR 1200 + EUR 900 = EUR 2100; the difference becomes EUR 6000 - EUR 2100 = EUR 3900, which still exceeds the threshold of EUR 1000).

[0079] Block 444 includes the control of an output device from the client device to generate secondary results in response to the first set of travel request parameters. System 100 displays the secondary results on the client device 116, allowing the user to compare the primary and secondary routes. The options can be reviewed and appropriate selections made.

[0080] In one variant, the secondary results generated in block 444 can only be a single result. In this variant, block 440 can be provided but may result in a threshold that generates only a single result. Similarly, according to this variant, blocks 436 and 440 can be omitted, or made optional, if only a single secondary result is generated.

[0081] By implementing process 400, system 100 can automatically suggest alternatives. For example, instead of an initial flight in Business Class costing EUR 6000, the system can offer to fly one day earlier in Economy Class for EUR 1000, offering an additional night for EUR 200, and optionally including services such as lounge access, teleworking spaces, relaxation time, and car rentals.

[0082] In a variant of method 400, the administrator terminal 118 can be used to establish the permissible range of parameters (e.g., airline, class, travel dates, departure and arrival times, preferred airports, maximum duration of stopover(s), CO2 emission limits, budget constraints, meal preferences, seat preferences, programs of loyalty) which can be entered in block 404, as well as the range of parameters which can be part of a contextual extension (e.g., extended date ranges, alternative classes, alternative airlines, additional stopover locations, extended lengths of stay, various types of accommodation, additional services such as lounge access or teleworking spaces, relaxation time allowances, car rentals, travel insurance options) in block 416 and the establishment of a threshold set in block 440.

[0083] The parameters can also be configured to apply specific conditions and alternatives when generating secondary results. These parameter configurations can align with user preferences and company policies, thereby optimizing both profitability and user satisfaction. Configuration for making a bid: The parameters can establish various conditions under which secondary results are generated. For example:

[0084] If the class is the Business class, the search engine 120 can be configured to prioritize certain alternatives.

[0085] In another variant, a condition may be provided, according to which block 420 and subsequent blocks will only execute if the first aggregation at block 416 exceeds a certain multiple, e.g. three times a minimum price threshold (3*MinPrice) of the first aggregation.

[0086] In another embodiment, the purpose of the trip can influence the threshold in block 440. For example, if the purpose of the trip is NOT a visit to a client, perhaps indicating an internal meeting or a training session, then the threshold can be modified to reflect the relative importance of the trip. E.g., a trip with a low-value purpose may have a lower threshold in block 440 for locating secondary results, while a high-value trip may have a higher threshold in block 440 for locating secondary results.

[0087] The threshold at block 440 may be a financial value for the company, exceeding for example EUR 500, such as savings or improved efficiency, leading to a "yes" determination at block 440. Alternatively, the threshold may be a percentage (for example, 70% of the initial offer) or the result of a set of rules defined by the administrator 126.

[0088] The threshold at block 440 can focus on a loyalty account for user 124 associated with the respective identifier 128. E.g., if the user's rewards or loyalty points exceed a certain threshold (e.g., 100 points), then a "yes" determination can be reached at block 440.

[0089] Other factors that can be normalized at the aggregation level in block 416 or block 432 may be non-pecuniary, such as the duration of the journey, which could This may involve longer stopovers or longer travel times if it results in significant savings. Such non-monetary values ​​can be assigned a theoretical monetary value as part of the aggregation, such as a certain number of euros for each additional hour of flight and / or stopover time. It should therefore be emphasized that while monetary units are possible, the technical calculations derived from block 416, block 432, and the threshold in block 440 should not be monetary and can be measured as electronic credits.

[0090] Other factors that may be considered include providing additional nights of accommodation if extending the stay proves more economical or practical; offering one or more days off as compensation for choosing less convenient travel arrangements.

[0091] In light of the foregoing, it will now be evident that variants, combinations, and subsets of the preceding embodiments are envisaged. For example, the search engine 120 may include an orchestrator that manages and coordinates the reception and processing of travel request parameters, integrates multiple travel actor engines, and applies business rules and uses artificial intelligence to generate optimized travel itineraries.

[0092] The search engine 120 can leverage advanced algorithms and artificial intelligence within rule engines to apply specific business rules and preferences. This may involve biasing search results towards more cost-effective and user-preferred options, dynamically adjusting routes based on contextual factors, and ensuring compliance with company travel policies.

[0093] Furthermore, the 120 search engine can be integrated into a rewards calculator to evaluate and aggregate electronic credits, such as savings and loyalty points, associated with different travel options. By normalizing these factors into a unified metric, the system can efficiently compare primary and secondary results, determining the most advantageous routes based on predefined thresholds.

[0094] The 120 search engine can also provide analytics to offer visibility into the best travel deals and suggest improvements based on historical data and user preferences. This feature enhances the decision-making process for users by presenting comprehensive comparisons of travel options and highlighting potential savings.

[0095] Furthermore, the 120 search engine can function as a configurator of the best deals, applying specific conditions to create travel offers. This includes suggesting alternatives such as changing travel dates, classes, and integrating additional services such as access to lounges or remote workspaces. By offering these options, the system ensures that users can enjoy optimal travel experiences at reduced costs.

[0096] It should be understood that one or more of the applications may include the machine learning studio platform with the desired related algorithms and neural networks that are trained to improve the results generated at block 432, thereby reducing the overall number of searches performed on the travel actor engines 104. The machine learning applications 224 may be used by the processor 208 in learning mode to train the algorithms and neural networks of the machine learning applications 224 in accordance with the teachings herein.Machine learning applications can continuously adjust the contextual extension at block 420 and the threshold at block 440, by continuously monitoring the overall number of searches performed on the travel actor engine 104 in order to establish the contextual extensions at block 420 and the thresholds at block 440 that continue to reduce the number of searches while also controlling the corresponding alignment between searches at block 440 and bookings resulting from the results generated on customer devices 116 at block 444.

[0097] Algorithms and neural networks for machine learning applications 224 may include, but are not limited to: generalized linear regression; random forests; support vector machines; gradient reinforcement regression; decision trees; generalized additive models; neural networks; evolutionary programming; Bayesian inference; reinforcement learning, and the like. However, generalized linear regression, random forests, support vector machines, gradient reinforcement regression, decision trees, generalized additive models, and the like may be preferred to neural networks, evolutionary programming, and the like.

[0098] A person skilled in the art will now appreciate that the teachings contained herein can improve the technological efficiency and the use of computing and communication resources throughout the system 100 by reducing the number of searches performed on the travel actor engines 104. Indeed, according to prior knowledge of the art, operators of the travel actor engines 104 must dedicate significant resources to searches whose parameters are constantly adjusted and modified, but without this necessarily resulting in the refinement or completion of a travel itinerary suggested as a result of these searches. This leads to a significant processing load on the travel actor engines 104 and associated devices 116, not to mention the bandwidth consumption on the network 108. Therefore, the criteria for the extension to block 420 and the threshold at block 444 can be chosen to reduce the overall (wasted) number of searches performed on travel actor search engines 104.

[0099] People skilled in the art will now realize this and the other technical advantages of this specification.

[0100] It must be acknowledged that the features and aspects of the various examples provided above can be combined in other examples that also fall within the scope of the present invention. Furthermore, the figures are not to scale and may be exaggerated in size and shape for illustrative purposes.

Claims

1. Demands A computer-implemented process for extending contextual search, the process comprising: - the reception (404), at the level of a processor, of a first set of travel request parameters; - the realization (408), at the processor level, of a primary search for at least one travel actor engine for a first electronic itinerary based on the first set; - the reception (412), at the processor level, of the primary results for the primary search; - the determination (416), at the processor level, of a first aggregation of electronic credits of primary results; - the generation (420), at the processor level, of a second set of trip request parameters based on a contextual extension of the first set and the first aggregation; - the realization (424), at the processor level, of a secondary search of said at least one travel actor engine for a second electronic itinerary based on the first set; - the reception (428), at the processor level, of secondary results for secondary search from said at least one travel actor engine; - the determination (432), at the processor level, of a second aggregation of electronic credits of secondary results; - the determination (436), at the processor level, of a difference between the first aggregation and the second aggregation; - if the difference (440) is greater than or equal to a predefined threshold, the control (444) of an output device of a client device to generate the secondary results in response to the first set of travel request parameters; otherwise - the repetition of the generation of the second set of travel request parameters and the performance of the secondary search until the predefined threshold is reached; in which the processor controls the output device to display both the primary and secondary results for comparison with the user.

2. The method of claim 1, wherein the first set of travel request parameters includes one or more optional parameters selected from the group consisting of: class preferences, preferred airlines, CO2 emission limits, time of day, number of stopovers, duration of maximum 17 stopover(s), specific airports, budget constraints, seat preferences, meal preferences, and loyalty program memberships.

3. The method of claim 1 or claim 2, wherein the contextual extension of the first set of travel request parameters includes extended date ranges, alternative airports, alternative classes, alternative airlines, additional stopover locations, extended lengths of stay, various types of accommodation, and additional services selected from the group consisting of: lounge access, teleworking spaces, relaxation time allowances, car rentals, and travel insurance options.

4. The method of any of the preceding claims, wherein the predefined threshold is based on a financial value, a loyalty point value, or a combination of both.

5. The method of any of the preceding claims, wherein the predefined threshold is based on reducing a total number of primary searches received by travel actor search engines.

6. The method of any one of the preceding claims, wherein the secondary search is performed if the price of the first electronic route exceeds a multiple of a minimum price threshold.

7. The method of claim 1, wherein the secondary results include alternative travel itineraries that are generated on the basis of conditions such as changing travel dates, classes and the integration of additional services.

8. The method of any of the preceding claims, wherein the contextual extension is based on reducing a total number of primary searches received by travel actor search engines.

9. The method of any one of the preceding claims, wherein the first and second electronic credit aggregations include calculations of total cost, possible rewards, and route-related disadvantages.

10. The method of any of the preceding claims, wherein the processor dynamically adjusts the second set of travel demand parameters based on business rules and artificial intelligence to bias secondary search results with the aim of reducing over time the total number of primary searches received at the travel actor search engines.

11. The method of any one of the preceding claims, further comprising integration into a rewards calculator to evaluate and aggregate electronic credits associated with different travel options.

12. The method of claim 1, wherein the processor continues to refine search parameters and threshold values ​​using machine learning algorithms to reduce the total number of searches performed on travel actor engines.

13. The method of claim 1, wherein the predefined threshold varies on the basis of the purpose of the trip.

14. The method of claim 1, wherein at least one of the contextual extension and threshold values ​​are continuously adjusted by machine learning algorithms to increase a number of reservations for the purpose of aligning with the number of search results generated.

15. A search server to execute the method of any of the preceding claims.

16. A computer-readable medium for storing programming instructions which, when executed by a computer, enable that computer to execute the method of any one of claims 1 to 14.

Images