RU2738590C1 - Method and system for searching for ticket offers - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: invention relates to the computer equipment. Method for searching ticket offers includes the following steps: receiving at least one request from a user to search for ticket offers; converting at least one request from a user obtained at a previous step into a set of requests for booking system gateways; distributing a set of requests for gateways, obtained at previous step, by modules of interaction with gateway by means of dispatcher; determining, by means of at least one interaction module with gateway, whether this gateway will execute request and how many requests to given gateway are required; performing at least one search request in the reservation system gateway for those requests, which are determined as available at previous step; obtaining ticket offers data from at least one reservation system; generating, based on the received proposals, at least one response to the user for a request which was received from the user.

EFFECT: technical result consists in improvement of speed of user obtaining ticket search offers.

18 cl, 7 dwg

Description

FIELD OF TECHNOLOGY

[001] The present invention relates generally to the field of computing, and in particular to methods and systems for searching for ticket offers.

LEVEL OF TECHNOLOGY

[002] Currently, prior art ticket search solutions have a number of serious drawbacks that prevent users from quickly retrieving search suggestions. The gateways of booking systems respond to requests at different times, which increases the client's waiting time for search results.

[003] In most cases (except for completely regional destinations), no gateway of booking systems contains the entire possible range of offers. In addition, the information returned by gateways is often incomplete or inconvenient for a layman to understand.

[004] International application WO2018135834 (A1) "Plane ticket search system and method using modified plane ticket" is known from the prior art (Applicant: FLTGRAPH CO LTD [KR], Publication date: 2018-07-26). This solution discloses a system and method for searching for flights using a modified plane ticket. A flight search system according to an embodiment of the present invention comprises: a control module for providing information about an existing plane ticket in a user terminal; and a modification module for receiving a modification request for a predetermined selection component among the components of an existing airplane ticket provided to the user terminal, the components including a departure place, a stopping place, a destination, and information about staying at a stopping place indicated on the airplane ticket where the control module performs processing such that the user terminal can search for the target plane ticket using the modified component and the legacy component that are included in the modified plane ticket components reflecting the change request, the changed component being the component reflecting the request for a change to a selection component among the components of an existing airplane ticket, and the legacy component is a component among the components of an existing airplane ticket for which there is no change request.

SUMMARY OF THE INVENTION

[005] A technical problem or a technical problem solved in the present invention is the implementation of a method and system for fast search of ticket offers.

[006] The technical result achieved by solving the aforementioned technical problem is to increase the speed at which the user receives search ticket offers.

[007] An additional technical result is the provision of more accurate proposals to the user, an increase in the number of mechanisms for assisting the user in choosing an offer.

[008] The specified technical result is achieved by implementing a method for searching for ticket offers, which is performed by at least one processor, in which at least one request is received from a user to search for ticket offers; transforming at least one request from the user received in the previous step into a set of requests for gateways of reservation systems; distribute the set of requests for gateways received in the previous step among the modules for interacting with the gateway through the dispatcher; determining by means of at least one module for interaction with the gateway whether the given gateway will fulfill the request and how many requests are required to the given gateway; performing at least one search query in the gateway of the ticket booking system for those queries determined to be available in the previous step; receive ticket offer data from at least one ticket booking system; on the basis of the received proposals, at least one response to the user request that was received from him is formed.

[009] In some embodiments, upon receiving a request from a user to search for ticket offers, convert it to gRPC or REST and JSON format.

[0010] In some embodiments, upon receiving a request from a user that includes a round trip, it is split into two search queries by a query transform module within one or more partner results schemas.

[0011] In some embodiments of the invention, the price is formed separately for each direction.

[0012] In some embodiments of the invention, received requests from the user to search for ticket offers are combined into groups.

[0013] In some embodiments, the received request from the user to search for ticket offers is transformed by a search strategy across the hubs.

[0014] In some embodiments, ticket offer data is obtained from a reservation system gateway and / or cache.

[0015] In some embodiments of the invention, ticket offer data is retrieved from the cache after its relevance to a particular offer has been verified.

[0016] In some embodiments, a fuzzy search is performed by a query transform module.

[0017] In some embodiments, the lookup request to the gateway interaction module is a SOAP or RPC or XML network request.

[0018] In some embodiments, the search query to the gateway interaction module has a different format depending on the gateway.

[0019] In some embodiments, the search query to the gateway interaction module contains a set of directions and dates for which users are searching for a ticket, a passenger configuration, and a service class.

[0020] In some embodiments of the invention, the search request to the gateway interaction module contains information about the user of the gateway for authentication and authorization, as well as the gateway's recommendations on which offers to choose.

[0021] In some embodiments, upon receipt of requests, the dispatcher

• forms an output queue that contains a unique name;

• sends a command to the data bus to create a given output queue with such a unique name;

• informs the modules of interaction with the gateway that it is necessary to send data from the reservation systems to this queue.

[0022] In some embodiments, the data bus is a RabbitMQ or Nats software broker.

[0023] In some embodiments of the invention, a database with predefined rules is used to determine whether the gateway will execute a request and how many requests to it are required.

[0024] In some embodiments, all method steps use streaming data processing.

BRIEF DESCRIPTION OF DRAWINGS

[0025] The features and advantages of the present invention will become apparent from the following detailed description and the accompanying drawings, in which:

[0026] FIG. 1 shows an example of the implementation of the architecture of a multilayer system for smart search for ticket offers.

[0027] FIG. 2 shows an example implementation of the architecture of layer 140, which sends search queries to search gateways and enriches the results with information that does not depend on a particular user (eng. AviaGateSearch).

[0028] FIG. 3 shows an example of the implementation of synchronization in layer 130 of transforming user queries into a set of queries to layer 140 to search for the best results by assortment (Avia-Smart-Search).

[0029] FIG. 4 shows an example of the computing architecture of a system through components for intelligently searching for ticket offers.

[0030] FIG. 5 shows an example of the implementation of data movement in layer 130 of transforming user queries into a set of queries to layer 140 for searching for the best results by assortment (Avia-Smart-Search).

[0031] FIG. 6 shows an example of the implementation of synchronization in the layer 120 of the formation of search results for a specific user (English Avia-User-Search).

[0032] FIG. 7 shows an example of the implementation of the movement of data in the layer 120 of the formation of search results for a specific user (English Avia-User-Search).

DETAILED DESCRIPTION OF THE INVENTION

[0033] Below will be discussed in detail the terms and their definitions used in the description of the invention.

[0034] In this invention, a system means a computer system, a computer (electronic computer), a CNC (numerical control), a PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given, well-defined sequence of operations. (actions, instructions), centralized and distributed databases, smart contracts.

[0035] By a command processor is meant an electronic unit or an integrated circuit (microprocessor) executing machine instructions (programs), a smart contract, an Ethereum virtual machine (EVM), or the like. A command processor reads and executes machine instructions (programs) from one or more storage devices. Data storage devices can be, but are not limited to, hard disks (HDD), flash memory, ROM (read only memory), solid-state drives (SSD), optical drives.

[0036] A program is a sequence of instructions for execution by a computer control device or command processing device.

[0037] Watchdog timer (English watchdog timer letters, "watchdog") - a hardware-implemented scheme to control system hangup. It is a timer that is periodically reset by a monitored system. If the reset does not occur within a certain time interval, a forced system reboot occurs. In some cases, the watchdog timer can send a signal to the system to reboot ("soft" reboot), while in others it can be rebooted in hardware (by shorting the RST signal wire or similar).

[0038] A software emulation of this solution is also possible, when the functions of the timer, as well as reset (reboot) of the system, are performed by an external system in relation to the controlled one. In this case, the implementation of system timers and control signals external to the executable algorithm is used.

[0039] A search engine is a computer system designed to search for information.

[0040] Dispatcher is a system module responsible for managing processes.

[0041] The present invention implements the search functionality, which is disclosed in more detail below. As an example of use, for clarity of understanding when reading, air ticket offers are used, however, it is obvious to any person skilled in the art that offers of railway tickets, bus tickets and so on can be used. or in aggregate, depending on the booking system.

[0042] The system architecture includes the following components (layers) as shown in FIG. one:

• Avia-Search-Gateway - Layer 110 converting data stream to packet data and data formats.

• Avia-User-Search - layer 120 of the formation of search results for a specific user;

• Avia-Smart-Search - layer 130 converting user queries into a set of queries to layer 140 to find the best results by assortment;

• Avia-Gate-Search - Layer 140 that sends search queries to search gateways and enriches the results with user-independent information.

[0043] The concept of layers is one of the common models used by computational designers to divide complex systems into simpler parts. Computer system architectures, for example, distinguish between layers of programming language code, operating system functions, device drivers, CPU instruction sets, and internal chip logic.

[0044] Layer n + 1 uses layer n, therefore, the abstraction of the concepts of layer n + 1 is at least not lower than that of layer n, and if the system architecture is efficient, then the level of abstraction of the layer should be higher. Accordingly, layer n hides (encapsulates) the logic of working with concepts defined on this layer, thus allowing layer n + 1 to implement work with more complex concepts, to organize more complex logic using the expressive means of the underlying layer. You can choose an alternative implementation of the base layers: the components of the upper layer are able to work without any changes in the underlying layers, provided that the interfaces are preserved. Dependency between layers, i.e. in fact, the interfaces provided by the lower layers by the upper can be minimized. This minimization of interfaces allows for increased system flexibility.

[0045] Layers can successfully encapsulate much, but not all: modification of one layer is sometimes associated with the need to make cascading changes in other layers. Excessive layers often reduce system performance. When moving from layer to layer, data is usually transformed from one view to another. Despite this, encapsulating the underlying functions can often be very beneficial.

[0046] Each of the layers contains one or more modules. Modules are combined into layers according to what data they work with.

[0047] No upper layer changes data from the lower layers, i. E. on the user query conversion layer 130, no changes are made to the search suggestions (see paragraph 0086 below). In this technical solution, a search is carried out in gateways, each of which provides access to one or more booking systems for search proposals in accordance with a user-specified request. The gateway can use XML-protocol (XML-gateway, but not limited to, which allows to form reference queries, receive responses, and also use all content, for example, Sirena-Travel ARS for booking and selling air travel.

[0048] In some implementations, the mode of providing search results to the frontend - batch or streaming, and the restrictions imposed by them are approved. Batch mode implies a one-time return of data from the search engine to the front-end, but only at the moment when the most recent offer is processed. The streaming mode allows you to give each offer immediately after processing it, without waiting for the rest, but imposes additional requirements on the data transfer protocol, plus in the streaming mode it is impossible to use information about the entire issue when processing each specific offer.

[0049] The request (for layers 120 and 130, as will be discussed later) is a set of destinations for which the user wants to purchase tickets, as well as the configuration of passengers and service classes for each of these destinations. The user can thus form a request in the graphical user interface of a web resource or through a description. For example, the request may be the following: two directions "Moscow - St. Petersburg" for December 10, with 1 adult and 1 child in economy class, and "St. Petersburg - Moscow" for December 15, with 1 adult and 1 child in economy class. The search engine does not restrict requests to the same configuration of passengers and service classes. The configuration of passengers and service classes in the request is specified for each direction separately, including if the user interface allows you to set them once for all directions. Technically, the search engine implemented in the system receives a user request in the form of a request over the network, which is then converted, for example, into a request in an internal format, for example, a gRPC request) and transmitted between the components of the search engine (sometimes - the “engine”) or the kernel by others words. In other implementations, a bunch of REST + JSON technologies can be used instead of gRPC, but not limited to.

[0050] Then, the request received from the user is converted by the request transform unit (in layer 130, as shown in FIG. 1). A user request consisting of more than one direction with the same configurations of passengers and service classes is converted into at least two groups of search requests. In the first group, a separate search query is created for each direction. In the second group, all directions are combined into an atomic search query. For example, a roundtrip search Moscow - St. Petersburg - Moscow on 01/01/2020 and 01/07/2020 per adult passenger in Economy class for both directions will be converted into two groups of search queries: the first group will have two separate request (eng. oneway) Moscow - St. Petersburg and St. Petersburg - Moscow, for each of which the configuration of passengers and class of service will be indicated; in the second group there will be one atomic search Moscow - St. Petersburg - Moscow with a single configuration of passengers and service classes for all directions at once. In some implementations, more complex custom queries can be transformed into more query groups. The Search Offers received within one group of search queries (see p. 0086) are then combined into Combined Offers (see p. 0084), including between different Affiliate Schemes.

[0051] The Affiliate Scheme is a channel for booking and selling an offer. For example, the same offer can be received from different booking systems (for example, Aeroflot's offers can be received from the Sabre, Galileo, Sirena, etc. booking systems). This offer may have slightly different rates and taxes in different booking systems, in addition, the agency fees that the web service of this invention receives differ. In a particular implementation, the price is calculated for each such option separately, and these prices may differ, and in this case, the user is offered the cheapest (although there are exceptions). In other implementations, the final price is the same for different sales channels. In addition, even offers from the same booking system can be issued through different legal entities, which also affects the profitability and price.

[0052] In some implementations, the user's query may be translated by a search strategy across the hubs. It should be noted that offers with a transfer also combine the booking systems themselves. In this technical solution, it is possible to combine offers from different booking systems, and also by explicitly dividing the route into components based on your own knowledge, send additional requests to the booking systems in order to get more options. For example, a user searches for "Cheboksary - Miami". Not a single booking system will find such a flight, because only local flights fly from Cheboksary, which are not in booking systems that have flights Moscow - Miami. However, in this technical solution it is known that you can separately search for "Cheboksary - Moscow" and separately "Moscow - Miami", and then combine offers from different booking systems.

[0053] In some implementations, an imprecise search is performed in a particular implementation by a query transform module, for example, to and from country searches, subject searches, floating date searches, and the like. The user makes a request "Moscow - Warm sea in January", and in this technical solution it is determined that in January the sea is warm in Southeast Asia and the Caribbean, and accordingly makes inquiries to the GDS "Moscow - Phuket", "Moscow - Havana" etc. A fuzzy search is a search for information in which information is matched against a given search pattern or a value close to this pattern.

[0054] In addition, tariffs are determined by the module for determining tariff rules (SegmentConditions) of layer 140, which enriches the search results obtained from the gateways, and informs the user about the tariff options available on each offer. In a specific implementation, a database is used that is filled by the content department or automatically through parsing of external systems, based on the texts of tariff rules, descriptions of tariffs on the websites of airlines, as well as directly by requests to the airline. The database may contain a structure from the most general rule (for example, "one piece of baggage is available on all Aeroflot flights") and exceptions from it (for example, "there are no baggage pieces for Aeroflot's Light group fares") and exceptions from exceptions, etc. ... Other implementations use the information received in the response from the reservation system gateway.

[0055] In some embodiments, the implementation determines and informs the user about the features of individual offers (offer price, charter flight, ordering separate tickets, technical landings, etc.).

[0056] In some embodiments, whether it is a charter flight or not is defined on layer 140. For example, only charters come from gateway Sig23, and charters come only from it.

[0057] The determination of the possibility of ordering with separate tickets can occur on different layers of the system. In some implementations, gateways are already sending ticketing offers — this is level 140. In another implementation, this is determined by the combiner from layer 130 when the offers are combined into a coherent whole.

[0058] The definition of technical fits occurs in the module for determining intermediate fits (SegmentLegs, not shown in Fig.) Of layer 140.

[0059] In a particular implementation, the offer price is the sum of the tariff and taxes (received from the GDS), as well as a service charge. A separate Pricing module is used to set the service charge. It can be a machine learning model (but not limited to). The model is built on the basis of historical data on sales and search results, which generates many configurations of service charges, from which the optimal configuration is then selected. Profitability is defined as the sum of the service fee and agency fees that are paid by airlines and GDS for the sale of a ticket, minus the cost of the payment gateway and minus the affiliate fee that is charged by partners for selling a ticket through this partner. Depending on the sales scheme, these parameters can be either set directly in the program code in advance (for example, the percentage of a payment gateway), or calculated based on the database. In some embodiments, the profitability includes the expected costs of user support (contact center, communication channels), etc., but is not limited to.

[0060] In the present invention, the time from receiving a request to generating a response by the backend in 95% of cases does not exceed the response time of the slowest of the enabled gateways plus 3 seconds (overhead). Back-end (English back-end) - software and hardware part of the invention. The total time for the formation of the first sentence, which can be displayed to the user in 95% of cases, does not exceed one and a half seconds (in this case, it is full, not additional, but here it is practically the same, since the gateway responses are cached).

[0061] With an increase in the assortment coming from any of the gateways of the reservation systems, or adding a new gateway, or increasing and complicating the combined offers, the overhead time remains within 3 seconds, or returns to these limits by horizontal scaling of computing power, which allows to achieve the technical result of this invention, to increase the speed of obtaining search proposals by the user. The overhead time is the total time the user received the offer minus the time spent on contacting and waiting for a response from the reservation system gateway. The meaning of this requirement is that in most cases, when the volume of data passing through the search engine increases, it would be possible to keep the overhead time within, for example , 3 seconds not by modifying algorithms, rewriting the system's program code, but by allocating more resources (RAM, CPU time) and / or creating more copies of the search engine components.

[0062] In some implementations, a cache search is performed instead of a gateway search. In advance, if they receive any offer from the gateway, they save it to the cache, for example, for half an hour (the time is set separately for each gateway). Accordingly, if within half an hour one of the users makes a similar request, then in this solution they do not contact the gateway, but download the saved offer from the cache. Clarification that the cache is up-to-date will be made for a specific offer that the user chooses to purchase.

[0063] Additionally, the system architecture has taken into account the possibility of providing API to other products, including third-party ones, taking into account the customization of the provided functionality.

[0064] By enriched results in this invention is meant data related directly to the proposal. In addition to the basic information reported by the reservation system gateway, these are:

i. tariff options,

ii. information about intermediate landings (in aviation terminology, transfers differ when the flight number changes, and intermediate landings when it does not change, although from the user's point of view they look the same - in most cases he needs to get off the plane. In this solution, intermediate landings are displayed as refueling, and sometimes it really is an aircraft refueling);

iii. elements of the yield per sale of the offer.

iv. other options

[0065] On the other hand, user-specific information is:

- a personalized recommendation of a proposal;

- a way to sort and group offers.

[0066] Previously, a request comes from the layer 130 of transforming user requests (for example, a request from the user "Moscow-SPb-Moscow" for specific dates) and gets to the dispatcher 210, as shown in FIG. 2, which knows that there are many gateways 230 and sends out a search query to them. The request comes from a custom frontend, which is a network request with dates, destinations, passenger configurations, and service classes. AviaGateway, without changing its essence, converts it into a request in an internal format (for example, gRPC), the layer 120 for generating search results for a specific user passes further into the layer 130 for converting user requests. On the other hand, the user request conversion layer 130 transforms one user request into a plurality of requests from the layer 140, which sends search requests to search gateways, each of which will then be transmitted to each gateway.

[0067] The search gateway search engine layer 140 performs specific searches in the interaction modules with specific gateways 230 (Galileo interaction module, Saber interaction module, etc.) that are located on this layer, as shown in FIG. 2. Generally, a search request is a network request (an HTTP-based request such as SOAP or RPC or XML request). The search query format is different for each gateway 230. For example, IATA is developing the NDC protocol recommended for interfacing with 230 reservation system gateways. In one implementation, the NDC protocol is used to communicate with individual airline reservation gateways 230. The request always contains a set of directions and dates for which the user wants to find a ticket, passenger configuration and service class. At least some gateways 230 require a single passenger configuration and service class for all flights, while the search query of the present invention does not contain this restriction (however, the query to the search gateway search query layer 140 may contain this restriction), and if the client wants a different configuration of passengers for different flights, then by internal transformations his request is split into several requests to gateways 230.

[0068] In addition, the request to the gateway 230 contains information about the user of the gateway 230 (data for authentication and authorization of the user of the gateway), as well as recommendations of the gateway 230 on which offers to choose. For example, you can make a request to gateway 230 to search not for any flights on the Moscow - St. Petersburg route, but only direct flights, or only Aeroflot. In some cases, this allows you to get a larger assortment with several requests. The rules for specifying such parameters are contained in the database.

[0069] For example, if information does not come from the gateways 230 which client the luggage is available for, this information is determined in the SegmentConditions module 260 based on the database mentioned above. In more detail, then each proposal has a number of properties: airports of departure and arrival, date and time of departure and arrival, the airline operating the flight (whose plane), the airline that sets the fare (not money, namely the conditions of carriage, coded by the airline or identifier - tariff code), etc. The database contains basic rules (basically the basic rule depends on the airline that assigns the fare and the fare code) and exceptions to these rules.

[0070] The manager 210 of the search query direction layer 140 copies the received queries to the representatives of the gateway 230 (GateRepresent in FIG. 2) as shown in FIG. 2. Each gateway communication module has its own gateway 230 representative. For example, a Saber communication module has a Saber representative. The representative of the gateway 230 is a module that knows about the peculiarities of a particular gateway 240 and accordingly decides whether it makes sense to send a request there. For example, if a user wants to find tickets to some small airport that does not have an IATA code, but only has a GSGA code, then it is useless to send a request to Saber - he does not know how to work with the GSGA codes. In some implementations, dispatcher 210 is responsible for creating an output queue. The dispatcher 210 generates a unique output queue name based on algorithms provided by the development environment. Then he sends a command to create a queue with this name to the data bus 150 (for example, RabbitMQ), and then informs the representatives of gateway 230 that the results need to be written to this queue (more precisely, the queue name is passed through requests to the pipeline processing data 710, which will already write to the queue), and also informs the user request conversion layer 130 to the reader from the queue 330 shown in FIG. 3 that you need to read from this queue.

[0071] The manager 210 of the search routing layer 140 may create a queue in some implementations on the data bus 150 (eg, RabbitMQ) (RabbitMQ is an AMQP-based message broker, a replicable message-centric middleware) , into which the response will fall, and gives its name to the layer 130 of the transformation of user requests. Also, the dispatcher 210 may use, for example, but not limited to the Nats message broker. The proxy module of the gateway 230 decides whether the gateway 240 will execute the request and how many requests (search patterns) are needed, reports up to the dispatcher 210 how many searches have been started. The dispatcher 210, in turn, sums these numbers, thus obtaining the total number of expected responses and communicating them through the search response module 250 upward to the reader from the queue 330 of the user query conversion layer 130. Above is an example with GSGA codes, where module 230 decides to send a request to gateway 240 or not. These are either technical features of the operation of the gateway 240, or in the technical solution it is decided that it makes no sense to send certain requests to a specific gateway 240 (the assortment is scarce, offers are more expensive, etc.) and these rules are described in the internal database. The module of interaction with the gateway forms a request to the API of the corresponding gateway 240 and sends it, after which a response is received and converted into the GateOffer format, and in some cases checks for the presence of a response in the cache.

[0072] Throughout the architecture of the invention, all modules are streaming data. Each offer is processed as soon as all the data necessary for this processing has appeared. As shown above using the example from the description of the search strategy through the hubs: to get an offer on the Cheboksary - Miami route, you need at least one offer for each of the Cheboksary - Moscow and Moscow - Miami routes. In this case, the processing of data dependent on each other is guaranteed by the same process. The assurance is achieved by the fact that after the transformation of the user query into a set of query groups for the search query to search gateways layer 140, there is a dispatcher 210 that assigns a task for a combination of sentences from a specific group to a specific instance of combiner module 310, as shown in FIG. 3. Dependent data are proposals for each of the parts of the flight, necessary for the preparation of a combined proposal.

[0073] Also, the reader from the queue 330 determines the state of processing and decides to stop processing by polling the states (each service that is waiting for some data does not know about the state of the underlying processes, but can decide to end the wait using the methods described below ), a predetermined number of messages (for example, from 0 to 15, not limited), a predetermined time for receiving messages, terminating messages. Each module operates in one particular way, specifically the reader from queue 330 knows the expected number of messages. A termination message is a message that does not contain data, but information that there will be no more data, for example, the line "finish". There may be a problem that the termination message will not arrive at the receiving module last, despite the fact that it was sent last. This is solved by specifying the number of data messages in the termination message, for example, the message finish: 45 means that 45 data messages need to be processed.

[0074] When streaming data as shown in FIG. 3, the scoring module 740 (shown in Figs. 6 and 7), from the user's point of view, offers of the layer 120 of generating search results for a particular user scores the offers and makes decisions about the expediency of further processing in various implementations:

• at the level of creating proposals;

• at the level of processing proposals.

[0075] The goal of scoring is to select from a set of offers that are identical from the user's point of view for display.

[0076] The manager 340 of the user query conversion layer 130 optimizes the number of queries to the search query direction layer 140 to the search gateways, and then creates a multiplexer 320 (Multiplexer) of the results, starts the mechanism for transporting queries and data between the layers, namely, transfers the request to the transport module queries and data 350 between the search query routing layer 140 and the user query conversion layer 130, creates an input queue on the data bus 150 (eg, RabbitMQ). This mechanism is needed in order to be able to physically separate data bus 150 installations (for example, RabbitMQ) according to layers. Multiplexer 320 is a data transport method with the goal of obtaining copies of the same data set by multiple recipients.

[0077] The query and data transport module 350 transmits a request to the search query layer 140 to search gates, obtains the name of the output queue (is a unique string. Described above is how the manager 210 of the search gateway layer 140 creates and transmits it), listens to it and transfers the responses to the multiplexer 320, and also acts as a watchdog timer. The watchdog timer fixes a predetermined time for receiving messages (for example, 15 seconds). When the time expires, the wait ends.

[0078] Multiplexer 320 duplicates each sentence to each combiner 310 specified when multiplexer 320 was created.

[0079] The merging module 310 accumulates the results for all individual searches included in the group, while also performing the function of a watchdog timer. A group is a collection of search queries against the search gateway search query layer 140 into which the user query has been transformed. As soon as there is at least one offer in each individual search from the group, this module 310 generates a SmartOffer and a SmartVariant. Also, this component maintains statistics of the generated SmartOffers and decides to transfer each of them to the AviaUserSearch level, sends SmartOffers to the data bus 150, as shown in FIG. 5. This decision is made in order not to transmit too much information, and this, in turn, so as not to complicate the user's choice and remove unnecessary load on computing and transport capacities. For example, there is a round trip search. There are 100 sentences, back 100. If you combine and give the user everything with everything, you get 10,000, which increases the computational load.

[0080] Combined Offer (or SmartOffer) - a combined set of search suggestions from different responses received for queries to the layer 140 of sending search queries to search gateways, and the corresponding set of combined options. For example, if we were looking for RT (RoundTrip - search back and forth), then it could be an atomic answer, or a union of two OWs. (English Oneway - one way search).

[0081] Combined Option (or SmartVariant) is a combination of different search options (OfferVariant) from different search offers (SearchOffer) within one combined offer.

[0082] A search proposal (or SearchOffer) is a specific combination of flights for a search query (for example, a combination of flights SU025 and SU026 on the corresponding dates obtained by atomic search Moscow - St. Petersburg - Moscow on 01.01.2020 in St. Petersburg and 07.01.2020 back) and a set of tariff options for which this combination can be issued. Each such variant is called a search variant (or Search Variant). The search option consists of specifying the fare code for each flight in the search offer, information on available fare options (baggage, exchange and refund options, but not limited to them), as well as available design options (from which booking system the option was received and which legal entity can be issued) and corresponding to the design options tariffs and taxes

[0083] Previously, the layer 120 generating search results for a specific user transmits the user's request unchanged to the layer 130 for transforming user requests without transformations, but at the same time creates the necessary transport infrastructure for processing the results. Then it receives data (offers in the SmartOffer format) from the layer 130 of transforming user requests and performs processing depending on a particular user (pricing and a / b companies, marketing campaigns, etc.).

[0084] The manager 210 of the layer 120 generation of search results for a specific user starts the processing pipeline 710 to listen to a specific queue, passes the request to the layer 130 of the transformation of user requests, gets the names of the queues to which the response will arrive, and tells them SmartSearchAdapter'y to listen queues and transferred messages to the data bus 150 (RabbitMQ) layer 120 of the formation of search results for a specific user.

[0085] Next, the SmartSearchAdapter module receives the name of the output queue, listens to it, transfers it to the data bus 150, and this module serves as a watchdog timer.

[0086] The processing pipeline 710 transmits the proposal results from the user request conversion layer 130 to the price calculator 720 as shown in FIG. 6, which calculates the final offer price, then calculates the scoring using the scoring module 740 of the same offers from the point of view of the user and performs filtering, depending on the specific user. Scoring in this technical solution is understood as a mechanism that allows you to manage the display of offers that are identical from the user's point of view in streaming mode by assigning a rating to the offers. The absolute value of the rating in this case does not matter, only their comparison ratios play a role. For example, if an offer for 2000 rubles with a rating of 1 went to issue, and then a similar offer for 1990 rubles was received and processed, then it can be rated 2 so that the frontend has a simple criterion to hide the offer for 2000 and instead show an offer for 1990 rubles. Filtering is understood as preventing the issuance of offers that are inaccessible to a specific user. For example, there is a promotion of one of the airlines, where a prerequisite is that the user entered the site under his username, and the offers for the promotion were not shown to those who were not logged in. In some implementations, filtering of low-conversion offers on large SERPs can be implemented in order to simplify the process of selecting a suitable offer by a user. In some implementations, offers (eg, marketing promotions) are validated by validator 730.

[0087] Scoring module 740 evaluates "like" sentences when SearchOffer and SearchVariant match. Those. offers are considered the same if they have the same set of segments (for example, a specific flight) and fare options. Segments are compared by flight parameters, marketing carrier and flight number. Operating Carrier - the airline that owns the aircraft in operation. Marketing carrier - an airline that sets the conditions of carriage for a specific passenger and assigns a flight number. For example, if a user is flying an Aeroflot plane, Aeroflot is the operating carrier. The conditions of carriage were assigned to him by Aeroflot, and given the flight number SU292. For flight SU292 Aeroflot is a marketing carrier. But on the next seat is a man who was assigned the conditions of carriage by Vietnam Airlines and the flight number for him is VN555. On flight VN555, the marketing carrier is Vietnam Airlines, although Aeroflot is still operating.

[0088] As it passes through the processing pipeline 710, grouping by hash is performed, where collections of sentences having the same hash are considered.

[0089] Below is a specific example of implementation of the present invention.

[0090] The user wants to search for tickets for the Moscow - St. Petersburg - Moscow flight for one adult on 01.01.2020 and 07.01.2020 in Economy class. He enters these parameters in the search form, which transfers them to the layer 110 for converting the data stream into a data packet and data formats in a format where for each direction (Moscow - St. Petersburg and St. Petersburg - Moscow) the configuration of passengers and the selected class of service (one adult in the class Economy)

[0091] The layer 110 for converting the data stream into a data packet and data formats initiates data exchange with the manager module 210 of the layer 120 generating search results for a specific user using an internal protocol (eg gRPC) in the mode of receiving a stream from a server. That is, the client (layer 110 for converting the data stream into a data packet and data formats) sends a single request to the server (dispatcher 210), and waits for successively arriving offers in response. In this case, the request is not transformed.

[0092] The Manager 210 module of the layer 120 generating search results for a specific user creates one queue in RabbitMQ, which will receive offers ready for display. It then creates one queue that will be used to transport the data received from the user query conversion layer 130 to the processing pipeline 710 of the user-specific search engine layer 120. The dispatcher 210 then sends the user request unchanged to the transformer module of the user request transformation layer 130 and receives from it the name of the queue to which the user request transformation layer 130 will transmit its work. Then the dispatcher sends the received queue name to the module for interaction with the layer 130 of the transformation of user requests, which waits for the receipt of combined offers in this queue and serves as a watchdog timer (see Fig. 6)

[0093] The module for converting requests from the received request forms two groups of requests. The first contains two separate search queries (Moscow - St. Petersburg and St. Petersburg - Moscow), the second contains a combined atomic query (Moscow - St. Petersburg - Moscow). These groups are passed to the manager 340 of the user request transformation layer 130, which creates three mux 320 according to the number of unique searches in the created groups, starts two blocks of offer combining 310 according to the number of groups, maps unique searches, multiplexers 320 and combiners 310 by creating queues in RabbitMQ ... The dispatcher 340 then submits each unique search as a query to the search engine query layer 140 interaction module to the search gateways. Further processing of each of the unique searches occurs in parallel (see Fig. 3)

[0094] The module for interacting with the layer 140 for directing search queries to search gateways transfers the received requests to the layer 140 of directing search queries to the search gateways, receives from it the name of the queue from which search suggestions can be obtained and the expected number of messages, and starts the message waiting process ... In this case, this module serves as a watchdog timer, (see Fig. 3)

[0095] The manager 210 of the layer 140 sending searches to search gates creates an output queue in RabbitMQ, then communicates the request parameters to a predetermined set of gateway representatives 230. Each of them determines how many searches will be launched by the corresponding module of interaction with the gateway, reports this number to the dispatcher 210 and sends the search query to the appropriate module for interacting with the gateway 240. The dispatcher 210, having received and summarized the responses from all representatives 230, reports the name of the output queue and the total expected number of messages to the module for interacting with the layer 140 of sending search queries to the search gates of the layer 130 of transforming user requests. (see Fig. 2)

[0096] Each of the modules for interaction with the gateway, which received a search request, independently and in parallel converts it to the gateway format, executes it, receives a response, converts it into the format of the SearchOffer search proposal and transfers the received search proposals through RabbitMQ to the module for enriching search proposals with data, ( see Fig. 2)

[0097] The module for enriching search suggestions 270 with data by referring to the appropriate databases adds information about the available baggage, the possibility of exchange or refund, stopovers, elements of profitability, etc. to the proposals. A message consisting of the thus enriched offers obtained as a result of one search request to one gateway 240 of the reservation system is transmitted via RabbitMQ to the layer 130 of the transformation of user requests. Bids received from different gateways 240 for different search queries are processed by the enrichment module independently and in parallel (see Fig. 2)

[0098] The module for interacting with the layer 140 for sending search queries to the search gateways receives messages containing search suggestions and, through RabbitMQ, transmits them to the corresponding multiplexer 320. The multiplexer 320 copies the message for each of the respective merging modules 310 (see Fig. 5)

[0099] The merging module 310, having received at least one search suggestion for each of the search queries included in the group (for example, in the case of search for proposals "back and forth" by separate queries - at least one search suggestion for each of the two searches " one way "), starts combining them into combined offers (SmartOffer) and combined options (SmartVariant). Each received combined offer via RabbitMQ is independently and in parallel sent to the layer 120 of the formation of search results for a specific user (see Fig. 5)

[00100] The module for interacting with the layer 130 of converting user requests of the layer 120 of generating search results for a specific user receives the combined offers and through RabbitMQ transfers them to the pipeline for processing proposals 710 of the layer 120 of generating search results for a specific user (see Fig. 7)

[00101] Bid processing pipeline 710 filters bids that are not available to a particular user, determines the bid price for each bid, and calculates a score for each bid. As a result, an offer is generated ready to be shown to the user, which is transmitted to the layer 110 for converting the data stream into a data packet and data formats (see Fig. 7)

[00102] In some implementations, the data stream to packet conversion layer 110 and data formats convert the data stream to a packet, after which the data is presented to the front-end for display to the user.

[00103] Referring to FIG. 4, the present invention may be embodied in a smart flight search computer system 400 that includes one or more of the following components:

• a processing component 401 comprising at least one processor 402,

• memory 403,

• component 405 multimedia,

• component 406 audio,

• interface 407 input / output (I / O),

• sensor component 408,

• component 409 data transmission.

[00104] The processing component 401 generally controls all of the operations of the system 400, such as processing data about the user or his flight search request, and also controls the display, phone call, data transfer, camera operation, and recording operation of the mobile communication device. The processing component 401 may include one or more processors 402 that implement instructions to complete all or part of the steps from the above methods. In addition, the processing component 401 may include one or more modules for convenient communication between other processing modules 401 and other modules. For example, the processing component 401 may include a media module for convenient, lightweight interaction between the media component 405 and the processing component 401.

[00105] Memory 403 is configured to store various types of data to support the operation of system 400, such as a user profile database. Examples of such data include instructions from any application or method, contact information, address book data, messages, images, videos, etc., all of which operate on the system 400. The memory 403 can be implemented as any type of volatile storage device, nonvolatile memory, or a combination thereof, such as static random access memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (EPROM), Read Only Memory device (ROM), magnetic memory, flash memory, magnetic disk or optical disk and others, but not limited to.

[00106] The multimedia component 405 includes a screen that provides an output interface between a system 400 that may be installed on a user's mobile communications device and a user. In some implementations, the screen may be a liquid crystal display (LCD) or a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen for receiving input from a user. The touchpad includes one or more touch sensors in terms of gestures, touching, and sliding across the touchpad. The touch sensor can not only sense the subject's touch boundary or swipe gesture, but also detect the length of time and pressure associated with touch and slide behavior. In some embodiments, the multimedia component 405 includes one front camera and / or one rear camera. When the system 400 is in an operating mode, such as shooting mode or video mode, the front camera and / or the rear camera can receive media data from the outside. Each front camera and rear camera can be one fixed lens optical system, or can have focal length or optical zoom.

[00107] The audio component 406 is configured to output and / or input an audio signal. For example, the audio component 406 includes a single microphone (MIC) that is configured to receive an external audio signal when the system 400 is in a mode of operation such as a call mode, a recording mode, and a speech recognition mode. The resulting audio signal can be further stored in memory 403 or routed to data transfer component 409. In some embodiments, the audio component 406 also includes one speaker configured to output an audio signal.

[00108] An input / output (I / O) interface 407 provides an interface between the processing component 401 and any peripheral interface module. The above peripheral interface module can be keyboard, steering wheel, button, etc. These buttons may include, but are not limited to, a start button, a volume button, a start button, and a lock button.

[00109] The sensor component 408 contains one or more sensors and is configured to provide various aspects of assessing the state of the system 400. For example, the sensor component 408 can detect on / off states of the system 400, the relative position of components, such as a display and a keypad, of a single component. system 400, presence or absence of contact between a subject and system 400, and orientation or acceleration / deceleration and temperature change of system 400. Sensor component 408 includes a proximity sensor configured to detect the presence of an object in the vicinity when there is no physical contact. Touch component 408 includes an optical sensor (eg, CMOS or CCD image sensor) configured for use in rendering an application. In some embodiments, sensor component 408 comprises an acceleration sensor, gyroscope sensor, magnetic sensor, pressure sensor, or temperature sensor.

[00110] Communication component 409 is configured to facilitate wired or wireless communication between system 400 and other devices. System 400 can access a wireless network based on a communication standard such as WiFi, 2G, 3G, 5G, or a combination thereof. In one exemplary embodiment, the communication component 409 receives a broadcast signal or broadcast associated information from an external broadcast control system via a broadcast channel. In one embodiment, communication component 409 comprises a Near Field Communication (NFC) module to facilitate near field communication. For example, the NFC module may be based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[00111] In an exemplary embodiment, system 400 may be implemented by one or more Application-Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPs), Programmable Logic Devices (PLDs), a logic chip programmed into operating conditions (FPGA), controller, microcontroller, microprocessor, or other electronic components, and can be configured to implement the method 500 for performing smart search for tickets.

[00112] In an exemplary embodiment, the non-volatile computer-readable medium comprises memory 403 that includes instructions where instructions are executed by processor 401 of system 400 to implement the above-described smart flight search methods. For example, a nonvolatile computer-readable medium can be ROM, random access memory (RAM), compact disc, magnetic tape, floppy disks, optical storage devices, and the like.

[00113] Computing system 400 may include a display interface that transmits graphics, text, and other data from a communications infrastructure (or from a framebuffer, not shown) for display on a multimedia component 405. Computing system 400 further includes input devices or peripherals. Peripheral devices may include one or more devices for interacting with a user's mobile communications device, such as a keyboard, microphone, wearable device, camera, one or more audio speakers, and other sensors. Peripheral devices can be external or internal to the user's mobile communications device. A touchscreen can display, typically graphics and text, and also provides a user interface (such as, but not limited to, a graphical user interface (GUI)) through which a subject can interact with a user's mobile communication device, such as access and interact with applications running on the device.

[00114] Elements of the claimed invention are in a functional relationship, and their joint use leads to the creation of a new and unique invention. Thus, all blocks are functionally linked.

[00115] All blocks used in the system can be implemented with electronic components used to create digital integrated circuits, which is obvious to a person skilled in the art. Not limited to, microcircuits can be used, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGA), the logic of which is set through programming. For programming, programmers and debugging environments are used that allow you to set the desired structure of a digital device in the form of a circuit diagram or a program in special hardware description languages: Verilog, VHDL, AHDL, etc. An alternative to FPGAs can be programmable logic controllers (PLCs), basic matrix crystals ( BMK) requiring a factory production process for programming; ASICs are specialized custom large integrated circuits (LSIs), which are significantly more expensive for small-scale and single-piece production.

[00116] Typically, the FPGA itself consists of the following components:

• configurable logic blocks that implement the required logic function;

• programmable electronic links between configurable logic blocks;

• programmable input / output blocks providing connection of the external output of the microcircuit with the internal logic.

[00117] Blocks can also be implemented with read-only memory devices.

[00118] Thus, the implementation of all the blocks used is achieved by standard means based on the classical principles of implementing the foundations of computing.

[00119] As will be understood by one skilled in the art, aspects of the present invention may be embodied as a system, method, or computer program product. Accordingly, various aspects of the present invention may be implemented solely as hardware, as software (including application software, and so on), or as an embodiment combining software and hardware aspects, which may generally be referred to as a “module”. "System" or "architecture". In addition, aspects of the present invention may take the form of a computer program product implemented on one or more computer-readable media having computer-readable program code that is implemented thereon.

[00120] Any combination of one or more computer readable media can also be used. The computer-readable storage medium can be, without limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or any suitable combination thereof. More specifically, examples (non-exhaustive list) of a computer-readable storage medium include: electrical connection using one or more wires, a portable computer diskette; hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), fiber optic connection, compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any combination of the above. As used herein, a computer-readable storage medium can be any flexible storage medium that can contain or store a program for use by the system itself, device, apparatus, or in connection therewith.

[00121] Program code embedded in a computer-readable medium can be transmitted using any medium, including, without limitation, wireless, wired, fiber optic, infrared, and any other suitable network or combination of the above.

[00122] Computer program code for performing operations for the steps of the present invention can be written in any programming language or combinations of programming languages, including an object-oriented programming language such as Python, R, Java, Smalltalk, C ++, and so on, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can be executed on the user's computer in whole, in part, or as a separate software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN), a wide area network (WAN), or a connection to an external computer (for example, via the Internet using Internet providers).

[00123] Aspects of the present invention have been described in detail with reference to block diagrams, circuit diagrams, and / or diagrams of methods, devices (systems), and computer program products in accordance with embodiments of the present invention. It will be appreciated that each block from the block diagram and / or diagrams, as well as combinations of blocks from the block diagram and / or diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other data processing device to create a procedure, such that instructions executed by a computer processor or other programmable data processing device create means to implement the functions / actions specified in block or blocks of flowchart and / or diagram.

[00124] These computer program instructions may also be stored on a computer-readable medium that can control a computer other than a programmable data processing device or other devices that function in a particular way, such that the instructions stored on the computer-readable medium create a device including instructions that perform the functions / actions specified in the block diagram and / or diagram.

Claims (39)

1. A method for searching for ticket offers, performed by at least one processor and comprising the following steps: • receive at least one request from the user to search for ticket offers; • transform at least one request from the user, received in the previous step, into a set of requests for gateways of reservation systems; • distribute the set of requests for gateways received at the previous step among the modules for interacting with the gateway via the dispatcher; • determine, by means of at least one module of interaction with the gateway, whether this gateway will fulfill the request and how many requests are required to this gateway; • perform at least one search query in the gateway of the reservation system for those queries that were determined to be available in the previous step; • receive ticket offer data from at least one booking system; • form on the basis of the received proposals at least one response to the user request, which was received from him. 2. A method according to claim 1, characterized in that upon receiving a request from a user to search for ticket offers, it is converted into gRPC or REST and JSON format. 3. The method according to claim. 1, characterized in that when receiving a request from a user, which contains a direction there and back, it is divided into two search queries by means of a query transformation module within one partner results scheme. 4. The method according to claim 3, characterized in that the price is formed separately for each direction. 5. The method according to claim 1, characterized in that the received requests from the user for the search for ticket offers are combined into groups. 6. The method according to claim 1, characterized in that the received request from the user to search for ticket offers is transformed by a search strategy through the hubs. 7. The method according to claim 1, characterized in that ticket offer data is received from the gateway of the booking system and / or the cache. 8. The method according to claim 7, characterized in that the ticket offer data is obtained from the cache after its relevance for a specific offer has been clarified. 9. The method according to claim 1, characterized in that an inexact search is performed by means of a query conversion module. 10. A method according to claim 1, characterized in that the search request to the gateway interaction module is a SOAP or RPC or XML network request. 11. The method according to claim 1, characterized in that the search request to the module for interacting with the gateway has a different format depending on the gateway. 12. The method according to claim 1, characterized in that the search request to the gateway interaction module contains a set of directions and dates for which the user is looking for a ticket offer, passenger configuration and service class. 13. The method according to claim 1, characterized in that the search request to the module for interacting with the gateway contains information about the user of the gateway for authentication and authorization, as well as the gateway's recommendations on which offers to choose. 14. The method according to claim 1, characterized in that upon receipt of requests, the dispatcher • forms an output queue that contains a unique name; • sends a command to the data bus to create a given output queue with such a unique name; • informs the modules of interaction with the gateway that it is necessary to send data from the reservation systems to this queue. 15. The method according to claim 14, characterized in that the data bus is a RabbitMQ or Nats software broker. 16. The method according to claim. 14, characterized in that when determining whether the gateway will fulfill the request and how many requests to it are required, a database with predetermined rules is used. 17. The method according to claim 1, characterized in that streaming data processing is used at all steps of the method. 18. A system for smart search for ticket offers, containing: • at least one processor capable of ο receiving at least one request from a user to search for ticket offers; ο transforming at least one request from a user received in the previous step into a set of requests for gateways of reservation systems; ο receiving ticket offers from at least one booking system; ο forming, on the basis of the received proposals, at least one response to the user request that was received from him; • at least one dispatcher, configured to distribute a set of requests for gateways received by the processor among modules for interaction with the gateway; • at least one module for interacting with the gateway, configured to determine whether the given gateway will fulfill the request and how many requests to this gateway are required; • at least one booking system capable of ο executing at least one search query in the gateway of the reservation system for those queries that have been determined by the gateway interaction module as available; ο referrals to at least one ticket processor; ο forming, on the basis of the received proposals, at least one response to the user request that was received from him.

Images