TARGETED SEARCH APPARATUS AND METHOD

Abstract

This specification describes a targeted search system, apparatus, and method. The method involves receiving search attributes related to an identifying object, extracting canonical search parameters, and applying specific constraints. A generic search is performed, and the results are filtered based on specific constraints to produce a refined result set. The use of machine learning improves the accuracy and relevance of the search results. The system also allows for dynamic adjustment based on real-time data and integrates with external APIs for up-to-date information, thus ensuring efficient and accurate request processing. Figure for abbreviation: [Fig. 4]

Description

Title of the invention: APPARATUS AND METHOD FOR TARGETED SEARCHING

[0001] This specification generally relates to computer and network searching, storage and retrieval, and more specifically targeted searches. Context

[0002] The vast majority of electronic searches are currently conducted online, thus presenting several significant technical challenges. High traffic during peak periods can lead popular platforms to experience server performance issues or even outages. This transition to online platforms implies extensive data storage and retrieval capabilities, as systems must manage large amounts of information. Furthermore, the need to process data in real time to provide up-to-date availability checks places a considerable burden on system resources, particularly when processing numerous simultaneous requests.

[0003] Furthermore, the complexity of search queries has increased, requiring substantial computing power and memory to process detailed and complex requests. As search queries become more complex, they contribute to increased pressure on the system. These evolving demands can lead to inefficiencies and increased latency, thereby placing additional strain on the existing infrastructure. Summary

[0004] One aspect of the specification provides a computer-implemented method for orchestrating a search including: receiving a set of search attribute inputs corresponding to an identifier object; extracting search parameters including at least one origin, one destination, one departure date, and generic preferences from the search attributes; extracting specific constraints from the search attributes; performing a generic search of electronic travel itineraries based on search parameters; receiving the results of the generic search; distilling a set of filtered outputs from the results of the constraint-based generic search by discarding any electronic travel itinerary that does not meet a constraint and including any electronic travel itinerary that meets the constraints;and, the control of an output device to generate the filtered results.

[0005] One aspect of the specification provides a method which also includes, before the execution of the generic search, the deduction of additional search parameters based on specific constraints to reduce the number of results of the generic search.

[0006] One aspect of the specification provides a method in which the additional search parameters are implemented differently during the execution of the generic search on different travel actor engines based on unique characteristics of each travel actor engine.

[0007] One aspect of the specification provides a method, in which the specific constraints include individual-specific requirements such as disabilities, religious considerations, age-related needs, and travel restrictions.

[0008] One aspect of the specification provides a method, in which generic preferences include general user preferences such as seat selection, preferred travel times, class and preferred airlines.

[0009] One aspect of the specification provides a method further comprising the dynamic adjustment of at least one of the specific constraints based on real-time data, including flight availability, weather conditions and travel advice.

[0010] One aspect of the specification provides a method in which the specific constraints preferably include at least one of the travel times, and a country in which stopovers are prohibited.

[0011] One aspect of the specification provides a method in which the execution of a generic search for electronic travel itineraries includes querying multiple travel actor engines and aggregating the results.

[0012] One aspect of the specification provides a method in which the filtering of results based on specific constraints is performed using a machine learning algorithm to improve accuracy and relevance.

[0013] One aspect of the specification provides a method, further comprising the ranking of filtered results based on priorities including at least one travel time and a number of stops.

[0014] One aspect of the specification provides a method, in which the identifier object includes a unique user identifier, user profile information, and historical travel data.

[0015] One aspect of the specification provides a method which also includes the provision of recommendations for alternative travel options if no electronic travel itinerary meets all the specific constraints.

[0016] One aspect of the specification provides a method in which the control of an output device includes the generation of a user interface on a device client that includes filtered results and accepts modification of at least one of the search parameters, generic preferences and specific constraints.

[0017] One aspect of the specification provides a method, further including the storage of the filtered results in a database to train an AI model in order to refine at least one among a future execution of the generic research project or the filtering of the results.

[0018] One aspect of the specification provides a method, including integration with external APIs to dynamically update the execution of the generic search based on real-time information such as flight delays, cancellations and gate changes.

[0019] One aspect of the specification provides a method which also includes receiving a weighting for each of the specific constraints and sorting the filtered results by rank based on the weighting.

[0020] One aspect of the specification provides a method which also includes the suppression of electronic routes from the filtered results which are below a predefined rank.

[0021] One aspect of the specification provides a method, in which the filtering includes the application of a multi-step filtering process which first eliminates routes based on strict constraints and then ranks the remaining routes based on soft constraints and user preferences.

[0022] One aspect of the specification provides a method, including, prior to the execution of the generic search, the validation of at least one of the search parameters and the specific constraints with respect to the travel policies of the companies stored in an administrative database.

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

[0024] This specification includes the attached figures, in which:

[0025] Fig. 1 presents a targeted search system.

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

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

[0028] Figure 4 presents a flowchart describing a targeted search process. Detailed description

[0029] Figure 1 presents a targeted search system generally designated as 100. The system 100 comprises a plurality of travel actor engines 104-1, 104-2 ... 104-N. (collectively, the 104-1, 104-2 ... 104-n engines are referred to as engine 104 and generically engine 104. This nomenclature is used elsewhere in this document.) In system 100, engine 104 connects to a network 108 such as the Internet. The network 108 interconnects the travel actor engines 104 to a plurality of client devices 116, at least one administrator terminal 118, and an orchestration engine 120. Each client device 116 corresponds to a different user 124, with an identifier object 128 associating each user 124 with their respective device 116. Similarly, the management terminal 118 corresponds to a system administrator 126. An identifier object 132 associates the administrator 126, or the head of the organization that manages the users 124, with the management terminal 118.For context, administrator 126 may belong to an organization that employs users 124 and establishes corporate travel policies on behalf of user 124.

[0030] In addition, the orchestration engine 120 is connected, via network 108, to a search engine 136, a booking engine 140, a compliance engine 144, and a calibration engine 148. As will be seen later, the compliance engine 144 can refine search results by applying compliance rules after filtering and scoring, thus ensuring that the results meet both the user's specific constraints and the company's policies. Furthermore, the calibration engine 148 can use machine learning to recalibrate group properties and improve rule compliance over time. This feedback loop continuously optimizes the rules based on actual user selections and compliance data.

[0031] Travel actor engines 104 can be based on any existing or future electronic server or computer architecture that, among other things, manages electronic reservations for transportation, accommodation, meals, and / or any travel-related booking function. For example, transportation-type travel actor engines 104 can manage reservations for airlines, trains, car rentals, and ride-sharing services. These 104 engines can communicate 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 use New Capacity Distribution (NDC) standards for direct connections to airlines, thus enabling more personalized and dynamic offers.Aggregator sites such as Expedia(TM) and Kayak(TM) can also be integrated to provide an overview of available travel options.

[0032] Travel industry-specific booking engines for accommodations (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, the engines can offer a wide range of accommodation choices and ensure real-time availability and pricing.

[0033] Travel actor engines for meal reservations, such as those described in article 104, can coordinate meal reservations and meal plans by 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, thereby enhancing the overall travel experience.

[0034] The orchestration engine 120 can be any type of electronic server or computer architecture that facilitates the coordination of the other nodes of the system 100, particularly in the context of search and booking interactions between the client device 116 and the travel actor engines 104, which can be subject to policies administered via the administrator terminal 118 which requires alignment with the personalized preferences and constraints of each user 124.

[0035] The client devices 116 can be any type of human-machine interface for interacting with the orchestration 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 may include augmented and virtual reality equipment complementary to the virtual reality or augmented reality or "metaverse" environments that may be offered on collaboration engines 104.The client devices 116 can be operated by different users 124 who are associated with a respective identifier object 128 which uniquely identifies a given user 124 when accessing a given client device 116 in the system 100.

[0036] 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 this embodiment, there is one administrator terminal 118 for all the travel actor engines 104. and all customer devices 116. In variants, if the system 100 is enlarged, a plurality of administrator terminals 118 can be provided, which correspond to one or more travel actor engines 104 and / or a plurality of administrator terminals 118 can be provided, which correspond to one or more customer devices 116.

[0037] This specification considers scenarios in which users 124 may want to search for travel itineraries and via one or more travel actor engines 104 that store and / or calculate such electronic itineraries, especially if there are specific constraints and / or preferences for different users 124. At the same time, the specification also considers the alignment of these constraints and / or preferences with the booking policies established via the administrator terminal 118.

[0038] Thus, the administrator 126 operates the administrator terminal 118, which receives inputs representing configuration data sets defining parameters that determine travel booking search requests from the client devices 116 directed to the travel actor engines 104. The administrator 126 could 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, among other things, toward reducing unnecessary searches on the travel actor engines 104 and increasing the alignment between searches and actual bookings.

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

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

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

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

[0043] As we will explain in more detail below, in general terms, the orchestration engine 120 is configured to coordinate and execute search and booking requests from the travel actor engines 104 originating from a given user 124 by dynamically applying user-specific constraints and preferences. This involves prioritizing these constraints, thereby reducing the computational load on the travel actor engines 104. The orchestration engine 120 processes input from the client devices 116, so that the resulting search requests align with both the user-specific constraints and the broader policies determined by the administrator terminal 118.

[0044] 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 input received via one or more input devices 204 and to control one or more output devices 212 to generate output on those devices.

[0045] In order to perform its programming functions, the processor 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 may be based on persistent memory technology, such as electrically erasable programmable read-only memory (EEPROM), flash memory, a solid-state drive (SSD), another type of hard drive, or combinations thereof. The non-volatile memory 216 can be described as non-transient, computer-readable memory. Furthermore, more than one type of non-volatile memory 216 may be provided.

[0046] 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) with a double transfer rate (DDR). Other types of volatile memory 220 are envisaged.

[0047] The processor 208 also connects to the network 108 via a user 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.

[0048] 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.

[0049] The infrastructure of the orchestration engine 120, or a variant thereof, can be used to implement any of the computing nodes in the system 100, including the travel actor engines 104, the search engine 136, the booking engine 140, the compliance engine 144, and the calibration engine 148. In variants, the search engine 136, the booking engine 140, the compliance engine 144, and the calibration engine 148 can be integrated directly into the orchestration engine 120. However, in most embodiments, the travel actor engines 104 would generally remain independent of the orchestration engine 120, unless the orchestration engine 120 had been associated with a single travel actor engine 104.

[0050] Similarly, a plurality of orchestration engines 120 can be provided. Overall, the engine 104 and / or the engine 120 and other nodes in the system 100 can be implemented using cloud computing platforms such as Microsoft Azure™ or Amazon Web Services (AWS)™.

[0051] In addition, one or more engine nodes in the system 100 (i.e. the orchestration engine 120, the travel actor engines 104, the search engine 136, the booking engine 140, the compliance engine 144 and the calibration engine 148) can also be implemented as virtual machines and / or with mirror images to balance the load.

[0052] A person skilled in the art will recognize that the essential 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 server environment of the orchestration engine 120, have analogies with the different form factors of client machines such as those that can be used to implement client devices 116 and administrator terminal 118. Again, client devices 116 can be based on computer workstations, laptops, electronic tablets, mobile phone devices or similar.

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

[0054] 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.

[0055] 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).

[0056] 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.

[0057] 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.

[0058] At the base of the stack, there is the hardware and physical layer of the orchestration 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.

[0059] The stack 300 illustrates how the different layers interact in a computing environment of the orchestration 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 orchestration engine 120, the journey actor engines 104, the client devices 116 and other system nodes 100.

[0060] 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.

[0061] As we will see in more detail below, System 100 envisages the integration of a rules engine. Such a rules engine is not specifically presented in System 100 since it is typically integrated into the orchestration engine 120, but can also be deployed in other nodes, such as the search engine 136, the booking engine 140, the compliance engine 144, or the calibration engine 148. The rules engine aggregates the properties of individual and collective characters to dynamically generate search parameters and constraints.

[0062] Figure 4 shows a diagram describing a targeted search process 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 the purpose of explanation, process 400 will be described in relation to its execution on system 100 with an emphasis on the processing method 400, for example, application 224-2 stored in orchestration engine 120 and its interactions with other nodes of system 100. Process 400 also typically assumes that process 300, a variant thereof, has already been executed and that a unit data set in cache memory is already available, in volatile memory 216 or in volatile memory 220 or a combination of both.

[0063] Block 404 includes the reception of search attributes concerning an identifier object. The identifier object (e.g., identifier object 128-1) identifies a user only (e.g., User 124-1) and includes: A) generic search attributes such as origin, destination, departure date, search preferences (e.g., seat preferences, preferred travel times) and B) specific constraints (e.g., disabilities, religious requirements).

[0064] A) Examples of generic search attributes may include (by way of non-limiting examples):

[0065] Origin: the place of departure of the journey.

[0066] The destination: the place where the journey ends.

[0067] Departure date: The date on which the journey will begin.

[0068] Return date: The date on which the return trip will take place (if applicable).

[0069] Number of travellers: The total number of individuals who are travelling.

[0070] The travel class: the service category (e.g., economy, business, first class).

[0071] The type of journey: one way, round trip, multi-destination.

[0072] Examples of search preferences that can extend generic search attributes may include, but are not limited to:

[0073] • Seat preferences:

[0074] Aisle window seat

[0075] Extra space for people

[0076] Specific seat number or area of ​​the aircraft (e.g., front, middle, rear)

[0077] • Preferred airlines:

[0078] Specific airlines with which the user prefers to fly

[0079] Exclusion of certain airlines

[0080] • Preferred travel times:

[0081] Preferred departure time slot (e.g., morning, afternoon, evening)

[0082] Preferred arrival time slot

[0083] • Non-stop flights versus connecting flights:

[0084] Preference for non-stop flights

[0085] Acceptance of connecting flights and preferred stopover duration

[0086] • The loyalty program:

[0087] Membership in loyalty programs

[0088] Reference for accumulating miles or points

[0089] • Baggage requirements

[0090] Number of checked bags

[0091] Preferences for certain baggage-related policies

[0092] Search attributes, including generic search preferences, are canonical, meaning that they are standard search parameters, well known to travel actor engines 104. However, specific constraints may not be canonical, and therefore may be unknown to the structured data stored in travel actor engines 104.

[0093] To go further, “canonical” implies that generic search attributes and search preferences are standardized and universally recognized within the context of travel actor search engines 104. On the other hand, “non-canonical” specific constraints indicate that specific constraints are individualized or may not be part of the standard structured data in travel actor search engines 104

[0094] B) Specific (non-canonical) constraints may include, by way of non-limiting examples:

[0095] The handicaps:

[0096] Wheelchair accessibility

[0097] Special assistance at airports and during flights

[0098] Accommodation accessibility requirements

[0099] Religious requirements:

[0100] Dietary restrictions (e.g., kosher, halal)

[0101] Avoid travel on certain religious days

[0102] Places of prayer

[0103] Travel restrictions:

[0104] Countries to avoid due to political or security problems

[0105] Passport or visa requirements

[0106] Health considerations:

[0107] Health condition requiring special travel arrangements (e.g., no long flights, need for medical equipment)

[0108] Vaccination requirement or health advice

[0109] Family considerations:

[0110] Travel with babies or children

[0111] Need for family-friendly accommodation and activities

[0112] Ecological preferences:

[0113] Preference for eco-friendly airlines or accommodations

[0114] Minimizing the carbon footprint

[0115] Fear of flying:

[0116] Preference for direct flights

[0117] Avoid certain types of aircraft or airports

[0118] The means by which the dataset is collected at block 404 are not particularly limited, but typically, at least the canonical parameters (search attributes and search parameters) are entered via a client device 116 corresponding to the identifier object 128 and the user 124. (Consistent with our example, the client device 116-1 is used by the user 124-1 and authenticated via the identifier object 128-1). At the same time, one or more specific non-canonical parameters may also be entered directly, where they may be intrinsically associated with the identifier object 128-1, or they may be associated with the identifier object 132, under the control of the administrator 126 who may himself maintain an individual record corresponding to the identifier object 128-1.

[0119] Block 408 includes the extraction of search parameters from search attributes. These search parameters include at least origin, destination, departure date, and generic preferences. As discussed above, these parameters are canonical and represent the basic requirements for travel searches; they are currently available on online travel agencies (OTAs) and airline systems as hosted on travel actor engines. The extraction process involves analyzing the entire set of search attribute entries in block 404 to isolate these fundamental elements.

[0120] Block 412 includes the extraction of specific constraints from search attributes. As noted, specific constraints may include disabilities, religious considerations, countries to avoid, fear of flying, or an ecological preference. This block isolates these specific constraints from search attributes to process them separately from generic canonical preferences during a search process on travel actor engines 104.

[0121] Block 416 includes the execution of a generic search for electronic travel itineraries based on the canonical extracted search parameters. The orchestration engine 120, via the search engine 136, queries the travel actor engines 104 to perform this search, exploiting the origin, destination, departure date, and generic preferences extracted in block 408. Block 416 can generate a large set of travel itineraries that meet the basic search criteria.

[0122] Block 420 involves receiving the results of the generic search. The results include various travel itineraries from travel actor search engines 104, via search engine 136, which correspond to the search parameters specified in the previous step. These results are collected and prepared for further filtering based on the specific constraints extracted in block 412.

[0123] Block 424 comprises the distillation of a set of filtered outputs based on specific constraints. Block 424 involves the orchestration engine 120, in conjunction with the conformance engine 144 and the calibration engine 148, discarding any electronic travel route that does not meet one or more of the specific constraints and including only those routes that fulfill all the constraints. The process reduces the set of travel routes to those most appropriate for the individual user's needs, as specified by their constraints.

[0124] Block 428 includes control of an output device for generating the filtered results. For example, block 428 may include the orchestration engine 120 returning the filtered results to the client device 116-1 for display and interaction, allowing the user 124-1 to access the booking engine 140 and complete an electronic booking for a selected route on the appropriate travel actor engines 104. The travel routes filtered on the client device 116-1 provide a carefully selected set of options that respect both generic preferences and specific constraints.

[0125] Controlling an output device at block 428 can also consist of taking the filtered results (and / or any reservation via the reservation engine 140), and using the results for machine learning in the calibration engine 148 in order to further improve operations at block 424 during subsequent executions of process 400.

[0126] To give a concrete example of the execution of process 400, consider a user 124-1 who enters the following search attributes at block 404 via client device 116-1.

[0127] - Origin: New York (NYC)

[0128] - Destinations: London (LHR)

[0129] - Departure date: July 22, 2024

[0130] - Return date: July 30, 2024

[0131] - Travel class: Business

[0132] - Seat preferences: aisle seat

[0133] - Preferred airline: Delta, British Airways

[0134] - Preferred travel times: morning departures

[0135] - Disabilities: requires wheelchair accessibility

[0136] - Religious requirements: kosher meals

[0137] - Travel restrictions: avoid stopovers in countries without meal options kosher

[0138] - Health considerations: need to wear medical equipment

[0139] Note that these attributes can be entered entirely manually by user 124-1, and / or some of the attributes can be inferred based on identifier object 128-1 and / or identifier object 132, which has specific data about user 124-1. For example, origin, destination, departure date, return date, seat preferences, and preferred travel times can be expressly entered by user 124-1, while travel class, preferred airlines, disabilities, religious requirements, and health considerations can be implicitly stored in identifier object 128-1 and / or identifier object 132. All of the above can be generically considered as search "constraints," even though "travel class: Business" can be considered a "plus" for user 124-1.Therefore, here again, "constraints" are used in the sense of a technical search and not in a limiting or restrictive sense. They refer to any parameter, requirement, or preference associated with electronic research, including both limitations and improvements, and can be expressed via Boolean logic or other computational techniques.

[0140] From these attributes, the following canonical search parameters can be extracted at block 408:

[0141] - Origin: New York (NYC)

[0142] - Destinations: London (LHR)

[0143] - Departure date: July 22, 2024

[0144] - Return date: July 30, 2024

[0145] - Travel class: Business

[0146] - Seat preferences: aisle seat

[0147] - Preferred airline: Delta, British Airways

[0148] - Preferred travel times: morning departures

[0149] From these attributes in block 404, the following specific non-canonical constraints can be extracted in block 416:

[0150] - Disabilities: requires wheelchair accessibility

[0151] - Religious requirements: kosher meals

[0152] - Travel restrictions: avoid stopovers in countries without meal options kosher

[0153] - Health considerations: need to wear medical equipment

[0154] Continuing with the example, block 416 includes the execution of a generic search for electronic travel itineraries based on the canonical extracted search parameters. The orchestration engine 120, via the search engine 136, queries the travel actor engines 104 to execute this search, exploiting the origin, destination, departure date, and preferences. Generics extracted in block 408. Block 416 can generate a large set of travel itineraries that meet basic search criteria.

[0155] Continuing with the example, block 420 includes the reception of the generic search results. This result includes various travel itineraries from travel actor engines 104, via the search engine 136, which correspond to the search parameters specified in block 416. These results are collected and prepared for further filtering based on the specific constraints extracted in block 412.

[0156] Continuing with the example, the orchestration engine 120 can receive results such as:

[0157] 1. Flight with Delta departing NYC at 8:00 AM, arriving LHR at 8:00 PM, with a stopover at Amsterdam (AMS).

[0158] 2. Flight with British Airways departing NYC at 10:00, arriving LHR at 22:00, direct flight.

[0159] Block 424 comprises the distillation of a set of filtered result outputs based on specific constraints. Block 424 involves the orchestration engine 120, in conjunction with the conformance engine 144 and the calibration engine 148, discarding any electronic travel itinerary that does not meet one or more of the specific constraints and including only those itineraries that fulfill all the constraints. Thus, at this stage, the non-canonical search parameters in the form of extracted specific constraints are applied. Block 424 reduces the set of travel itineraries to the most suitable ones for user 124-1, as specified by the constraints.

[0160] By applying specific constraints, the orchestration engine 120 filters the flight with Delta due to the stopover in Amsterdam. The orchestration engine 120 can also filter this flight if it does not offer kosher meals. The filtered result according to this example may therefore include:

[0161] - Flight with British Airways departing NYC at 10:00, arriving LHR at 22:00, direct flight.

[0162] Block 428 includes the control of an output device to generate the results filtered. For example, block 428 might include the orchestration engine 120, which returns the filtered results to the client device 116-1 for display and interaction, allowing the user 124-1 to access the booking engine 140 and complete an electronic booking for a chosen route on the appropriate travel actor engines 104. The travel routes filtered on the client device 116-1 provide a carefully selected set of options that respect both generic preferences and specific constraints.

[0163] In the example, the filtered result displayed for user 124-1 would be the following:

[0164] - Flight with British Airways departing NYC at 10:00, arriving LHR at 22:00, direct flight.

[0165] Thus, by generating only one option instead of two, computing resources for the search are managed more efficiently.

[0166] Note that other examples of attributes in block 404 can also be processed in block 412 and block 424 to give a carefully and efficiently selected result for customer device 116-1.

[0167] Controlling an output device at block 428 can also consist of taking the filtered results (and / or any reservation via the reservation engine 140), and using the results for machine learning in the calibration engine 148 in order to further improve operations at block 424 during subsequent executions of process 400.

[0168] In light of the foregoing, it will now be apparent that variants, combinations, and subsets of the preceding embodiments are envisaged. For example, before block 416 or after block 412, an added step may include the generation of additional canonical search parameters based on specific non-canonical constraints before performing the generic search. This may be performed by a rules engine in the orchestration engine 120 or in the search engine 136, the conformance engine 144, or the calibration engine 148.For example, if a specific constraint indicates that user 124-1 has a disability requiring wheelchair accessibility, the rules engine can infer additional canonical search parameters available on the orchestration engine 120, such as selecting airlines known to provide excellent assistance to disabled passengers and choosing airports with appropriate facilities. By incorporating these inferred parameters into the initial search, the system can reduce the number of non-compliant results and improve the efficiency of subsequent filtering steps.

[0169] Additional examples of canonical search parameters inferred based on specific non-canonical constraints include:

[0170] Health considerations:

[0171] Constraint: The user requires frequent use of medication or medical equipment.

[0172] Parameters deduced: The selection of flights with available medical assistance, airports with medical facilities, and airlines that allow the transport of medical equipment without additional charges.

[0173] Religious requirements:

[0174] Constraint: The user has dietary restrictions (e.g., kosher, halal); the user cannot travel on certain days of the same week (e.g., Friday, Saturday).

[0175] Deduced parameters: Choose flights offering suitable meal options, and hotels with certified meal services.

[0176] Travel restrictions:

[0177] Constraint: The user cannot travel to certain countries due to political or security issues.

[0178] Inferred parameters: Automatically exclude routes that include stopovers in countries subject to restrictions and favor routes passing through safer or approved countries.

[0179] Age-related needs:

[0180] Constraint: Senior traveler who requires assistance.

[0181] Inferred parameters: Select flights or services with accommodations adapted to the needs of seniors, including priority boarding and additional in-flight assistance.

[0182] Family considerations:

[0183] Constraint: Travelling with young children.

[0184] Inferred parameters: Choosing flights with family-friendly seats, in-flight entertainment for children, and hotels with babysitting services or family suites.

[0185] Ecological preferences:

[0186] Constraint: The user prefers environmentally friendly travel options.

[0187] Inferred parameters: Select airlines with low carbon emissions, opt for direct flights to reduce carbon footprint, and choose eco-certified accommodations.

[0188] Fear of flying:

[0189] Constraint: The user is afraid of flying and prefers the shortest flights possible.

[0190] Inferred parameters: Prioritize direct flights with the shortest duration, select airlines with the best safety ratings and choose airports with effective security procedures in order to reduce stress.

[0191] Accessibility requirements:

[0192] Constraint: The user requires sign language interpretation services.

[0193] Inferred parameters: Select airlines and airports that offer sign language interpretation, and choose hotels with staff trained in sign language.

[0194] Special dietary needs:

[0195] Constraint: The user follows a strict gluten-free diet.

[0196] Inferred parameters: Choose airlines and hotels that offer certified gluten-free meal options, and select routes with shorter travel times to minimize the complexity of meal planning.

[0197] In another embodiment, search parameters can be deployed differently across various travel actor engines 104 based on their unique characteristics. For example, some travel actor engines 104 might offer direct integrations with accessibility service providers, while others might specialize in green travel options. The orchestration engine 120 can dynamically adjust the search parameters for each engine 104 to optimize results and ensure that user-specific constraints are efficiently addressed.

[0198] In another embodiment, at least one of the specific constraints can be adjusted based on real-time data. This could include adjusting travel schedules based on current flight availability, modifying route options due to weather conditions, or updating travel advisories. By way of specific, but not limiting, example, if a particular country is specifically identified as a no-stopover destination, and real-time data indicates that a flight may include that country on one day but not another, then the constraint can be adjusted.

[0199] As noted, specific constraints may include preferences for certain travel times and restrictions in countries where stopovers are prohibited. Specific constraints may include traveling only during daylight hours and avoiding stopovers in specific countries due to security concerns. These constraints are extracted and applied during the filtering and search process to tailor travel options to the user's needs.

[0200] Another variant involves querying multiple travel actor engines 120 and aggregating the results. This variant combines the capabilities of various engines 120 to provide a comprehensive set of travel options. By querying different engines, the system can gather a wide range of routes, increasing the likelihood of finding matches that suit preferences and constraints.

[0201] As stated above, it is envisaged that non-canonical specific constraints can be processed to create canonical specific constraints. In another embodiment, a machine learning feedback loop in the calibration engine 148 examines historical reservations following the earlier execution of process 400, where specific constraints were filtered at block 424. Following the execution of the machine learning loop for the historical executions of process 400, during the future execution of process 400, Filtering at block 424 is avoided as a rules engine (e.g., in the orchestration engine 120 or the compliance engine 144 or the calibration engine 148) and is updated to convert future similar non-canonical specific constraints into canonical search parameters that can be searched at block 416. The machine learning model is thus trained on historical travel data and on the return to improve the ability to match travel options with specific user constraints and preferences.

[0202] As discussed above, it should be understood that one or more of the applications may include a machine learning studio platform with any related algorithm based on machine learning (ML) and / or neural networks, and the like. Machine learning applications may use various algorithms, including but not limited to: generalized linear regression, random forest, support vector machine, gradient reinforcement regression, decision tree, generalized additive models, neural networks, deep learning, evolutionary programming, Bayesian inference, and reinforcement learning algorithms.Algorithms such as generalized linear regression, random forest, support vector machine, gradient reinforcement regression, decision tree, and generalized additive models may be preferred over neural network, deep learning, and evolutionary programming algorithms.

[0203] Another variant involves ranking the filtered results based on user-defined priorities such as travel time, number of stops, and cost. This ranking can identify the best travel options according to the user's specific priorities. Rankings can be based on weights provided in block 404, indicating priorities for various non-canonical constraints. A weight can be provided for each specific constraint and used to rank the filtered results based on the weighting in block 424. Rankings can also be part of the machine learning feedback loop, as discussed elsewhere.Another variant involves applying a multi-stage filtering process that first eliminates routes based on strict constraints and then ranks the remaining routes based on soft constraints and user preferences.

[0204] Another variant involves removing electronic itineraries from the filtered results that fall below a predefined rank. This step helps to streamline the final set of results, reducing the likelihood of a search being run again and conserving the computing resources available in the travel actor engines 104.

[0205] To develop a possible ranking process, each constraint can be assigned an importance score from 0 to 1. These scores can determine the importance of each constraint, with higher scores indicating mandatory constraints and lower scores indicating optional constraints. This importance score allows the dynamic and flexible ranking system to prioritize the user's most important needs.

[0206] During the filtering process, the orchestration engine 120 can evaluate each travel route against the constraints of block 404 and / or block 412:

[0207] Routes that do not meet the mandatory constraints (those with high importance scores) can be discarded. The remaining routes can then be ranked based on how well they meet the optional constraints, with greater weight given to constraints with higher importance scores.

[0208] For example, consider a user with the following constraints and importance scores:

[0209] Wheelchair accessibility: 1.0 (mandatory)

[0210] Kosher meal: 0.9 (mandatory)

[0211] Avoid stopovers in countries without kosher meal options: 0.7 (important but optional)

[0212] Need to transport medical equipment: 0.8 (important but optional)

[0213] Business Class: 0.5 (preferred but optional)

[0214] Block 424 can thus include orchestration engine 120, which filters out routes that do not provide wheelchair accessibility or kosher meals. Orchestration engine 120 can then rank the remaining routes based on how well they meet the optional requirements, giving higher priority to those that allow the transport of medical equipment and avoid stopovers in countries without kosher meal options. Finally, orchestration engine 120 can consider the relative preference for Business Class due to its lower importance score.

[0215] By integrating importance scores, system 100 prioritizes the most important constraints, resulting from a set of travel options that best meets users' needs and thus reducing the computational load on system 100 by removing / filtering some results and returning only a subset of results to users 124.

[0216] Another variant includes providing recommendations for alternative travel routes if no route is produced in the results filtered at block 424. For example, alternative routes may be based on travel dates neighboring, such as x days before or after the suggested departure date and y days before or after the suggested return date.

[0217] Another variant includes generating a user interface on a client device 116 that displays filtered results and accepts modifications to search parameters, generic preferences, and specific constraints. This interactive interface allows users to refine their search criteria in real time and rerun process 400 with each modification.

[0218] It is envisaged that the orchestration engine 120 can be integrated into external application programming interfaces (APIs) to update generic search based on real-time information such as flight delays, cancellations and gate changes.

[0219] Another variant includes validating at least one of the search parameters and specific constraints against corporate travel policies in an administrative database, so that they can be associated with identifier object 132 and relevant identifier object 128-1. This validation can be performed by the compliance engine 144 to check with the organization's travel guidelines, further filtering out search results that are superfluous.

[0220] A person skilled in the art will now understand that the lessons learned herein can improve technological efficiency and the use of communication and computing resources in system 100 by reducing the number of searches performed on travel actor search engines 104. Indeed, according to prior business knowledge, operators of travel actor search 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 travel actor search engines 104 and associated devices 116, not to mention the bandwidth consumption on the network 108.

[0221] Other technical efficiencies include resource allocation, which can be achieved through the inference of additional canonical search parameters in non-canonical specific constraints. Consequently, many irrelevant search results are eliminated early in the process. This reduces the computational load on the travel actor engines 104 and conserves bandwidth on the network 108, enabling more efficient use of available resources and improved system scalability.

[0222] Another technical advantage arises from minimizing multiple search requests, which includes the overall reduction in the volume of data processed at each This step reduces the overall time required to generate and present search results. This latency reduction ensures faster response times and a more efficient search process.

[0223] Another technical advantage stems from scalability and load balancing potential. System 100 can be configured to dynamically adjust search parameters and filter results based on specific constraints, thus enabling more efficient load balancing across multiple travel actor engines. This improves the ability to handle large volumes of search requests without degrading System 100's performance, while also making it more scalable and robust under varying loads.

[0224] 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

Demands

1. A computer-implemented method for orchestrating a search comprising: • receiving (404) a set of search attribute entries for an identifier object; • extracting (408) search parameters including at least one origin, one destination, one departure date, and generic preferences from the search attributes; • extracting (412) specific constraints from the search attributes; • performing (416) a generic search for electronic travel itineraries based on the search parameters; • integrating with external APIs to dynamically update the execution of the generic search based on information such as flight delays, cancellations, and gate changes; • receiving (420) the results of the generic search;• the distillation (424) of a set of filtered result outputs from the constraint-based genetic search results by discarding any electronic travel route that does not meet a constraint and including any electronic travel route that meets the constraints; and • the control (428) of an output device to generate the filtered results.

2. The method of claim 1 further comprises, before the execution of the generic search, the deduction of additional search parameters based on specific constraints to reduce the number of results of the generic search.

3. The method of claim 2 wherein the additional search parameters are implemented differently during the execution of the generic search on different travel actor engines based on the unique characteristics of each travel actor engine.

4. The method according to any one of the preceding claims, wherein the specific constraints include individual-specific requirements, such as disabilities, religious considerations, age-related needs, and travel restrictions.

5. The method according to any one of the preceding claims, wherein generic preferences include general user preferences such as seat selection, preferred travel times, class and preferred airlines.

6. The method according to any one of the preceding claims further includes the dynamic adjustment of at least one of the specific constraints based on real-time data, including flight availability, weather conditions and travel advice.

7. The method of claim 6, wherein the specific constraints preferably include at least one travel schedule and a country in which stopovers are prohibited.

8. The method according to any one of the preceding claims wherein the execution of a generic search for electronic travel itineraries includes querying multiple travel actor search engines and aggregating the results.

9. The method according to any one of the preceding claims, wherein the filtering of results based on specific constraints is performed using a machine learning algorithm that converts the specific constraints into search parameters to perform the search.

10. The method according to any one of the preceding claims further includes ranking the filtered results based on priorities including at least one of the travel time and the number of stops.

11. The method according to any one of the preceding claims, wherein the identifying object includes a unique user identifier (ID), user profile information, and historical travel data.

12. The method according to any one of the preceding claims further includes providing recommendations for alternative travel options if no electronic travel itinerary meets all the specific constraints.

13. The method according to any one of the preceding claims, wherein the control of an output device includes the generation of a user interface on a client device that includes the filtered results and accepts modification of at least one of the search parameters, generic preferences and specific constraints.

14. The method according to any one of the preceding claims further comprises storing the filtered results in a database to train an AI model in order to refine at least one among a future execution of the generic search project or the filtering of the results.

15. The method according to any one of the preceding claims further comprises receiving a weighting for each of the specific constraints and ranking the filtered results by rank, based on the weighting.

16. The method of claim 15 further includes the suppression of electronic routes in the filtered results which are below a predefined rank.

17. The method according to any one of the preceding claims, wherein the filtering includes the application of a multi-stage filtering process that first eliminates routes based on strict constraints and then ranks the remaining routes based on soft constraints and user preferences.

18. The method according to any one of the preceding claims further comprises, before the execution of the generic search, the validation of at least one of the search parameters and specific constraints with respect to corporate travel policies stored in an administrative database.

19. A server configured to execute the method of any of the preceding claims.

20. 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-18.