WO2021125997A1 - Способ и система для осуществления поиска предложений билетов - Google Patents

Способ и система для осуществления поиска предложений билетов Download PDF

Info

Publication number
WO2021125997A1
WO2021125997A1 PCT/RU2019/000977 RU2019000977W WO2021125997A1 WO 2021125997 A1 WO2021125997 A1 WO 2021125997A1 RU 2019000977 W RU2019000977 W RU 2019000977W WO 2021125997 A1 WO2021125997 A1 WO 2021125997A1
Authority
WO
WIPO (PCT)
Prior art keywords
gateway
search
request
user
ticket
Prior art date
Application number
PCT/RU2019/000977
Other languages
English (en)
French (fr)
Inventor
Иван Андреевич САДОВОЙ
Игорь Анатольевич СУХАНОВ
Иван Сергеевич РУДЕВ
Original Assignee
Общество С Ограниченной Ответственностью "Глобус Медиа"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество С Ограниченной Ответственностью "Глобус Медиа" filed Critical Общество С Ограниченной Ответственностью "Глобус Медиа"
Publication of WO2021125997A1 publication Critical patent/WO2021125997A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G06Q10/025—Coordination of plural reservations, e.g. plural trip segments, transportation combined with accommodation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]

Definitions

  • the present technical solution generally relates to the field of computing, and in particular to methods and systems for searching for ticket offers.
  • Reservation system gateways respond to requests at different times, which increases the client's waiting time for search results.
  • gateway of booking systems contains the entire possible range of offers.
  • information returned by gateways is often incomplete or inconvenient for a layman to understand.
  • a flight search system 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 plane ticket provided to the user terminal, the components including a departure point, a stopping point, a destination and stay information at a stopping point indicated on the plane 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 components a modified plane ticket reflecting a change request, where the changed component is a component reflecting a change request with respect to a selection component among the components of an existing plane ticket, and a legacy component is a component among the components of an existing plane ticket for which there is no change request ...
  • a technical problem or a technical problem solved in this technical solution is the implementation of a method and system for fast search for ticket offers.
  • the technical result achieved by solving the above technical problem is to increase the speed of receiving the search ticket offers by the user.
  • An additional technical result is the provision of more accurate offers to the user, an increase in the number of mechanisms for assisting the user in choosing an offer.
  • 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 that were determined to be available in the previous step; receive ticket offer data from at least one ticket booking system; are formed on the basis of the received proposals for at least one response to the user request that was received from him.
  • the price is formed separately.
  • the received requests from the user for the search for ticket offers are combined into groups.
  • the received request from the user to search for ticket offers is transformed by a search strategy through the hubs.
  • the ticket offer data is obtained from the reservation system gateway and / or cache.
  • the ticket offer data is obtained from the cache after its relevance to a specific offer has been clarified.
  • an inexact search is performed using a query transform module.
  • the search request to the gateway interaction module is a SOAP or RPC or XML network request.
  • the search query in the module for interacting with the gateway has a different format depending on the gateway.
  • the search query in the gateway interaction module contains a set of directions and dates for which users are looking for a ticket, passenger configuration and service class.
  • 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.
  • the dispatcher upon receipt of requests, the dispatcher
  • the data bus is a RabbitMQ or Nats software broker.
  • a database with predefined rules is used to determine whether the gateway will execute a request and how many requests to it are required.
  • data streaming is used at all steps of the method.
  • FIG. 1 shows an example of the implementation of the architecture of a multilayer system for smart search of ticket offers.
  • FIG. 2 shows an example of the implementation of the architecture of the AviaGateSearch layer.
  • FIG. 3 shows an example of synchronization implementation in the Avia-Smart-Search layer.
  • FIG. 4 shows an example of the computing architecture of a system through components for intelligently searching for ticket offers.
  • FIG. 5 shows an example of data movement implementation in the Avia-Smart-Search layer.
  • FIG. 6 shows an example of synchronization implementation in the Avia-User-Search layer.
  • FIG. 7 shows an example of the implementation of data movement in the Avia-User-Search layer.
  • the system means a computer system, a computer (electronic computer), CNC (numerical control), 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.
  • a computer electronic computer
  • CNC numerical control
  • 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.
  • An instruction processing device means an electronic unit or an integrated circuit (microprocessor) that executes 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.
  • the role of 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.
  • a program is a sequence of instructions intended for execution by a computer control device or a command processing device.
  • the watchdog timer (aHm.watchdog timer of the letters "watchdog") is a hardware-implemented scheme for controlling the system freezing. 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 reboot of the system occurs. In some cases, the watchdog timer can send a signal to the system to reboot ("soft" reboot), in others - the reboot occurs in hardware (by closing the signal wire RST or similar).
  • a search engine is a computer system designed to search for information.
  • Dispatcher is a system module responsible for managing processes.
  • the system architecture includes the following components (layers) as shown in FIG. one :
  • Avia-Smart-Search a layer for converting user queries into a set of queries to the Avia-Gate-Search layer to search for the best results by assortment;
  • Avia-Gate-Search - a layer that sends search queries to search gateways and enriches the results with information that does not depend on a particular user.
  • 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, the n layer hides (encapsulates) the logic of working with the concepts defined on this layer, thus allowing the n + 1 layer to implement work with more complex concepts, to organize more complex logic using the expressive means of the underlying layer.
  • 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.
  • Layers can successfully encapsulate a lot, 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 often provides a very significant advantage.
  • Each of the layers contains one or more modules. Modules are combined into layers according to what data they work with.
  • 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 an XML protocol (but not limited to an XML gateway, which allows you to form reference queries, receive responses, and also use all content, for example, Sirena-Travel ARS for booking and selling air travel.
  • the mode of providing search results to the frontend is approved - batch or streaming, and the restrictions imposed by them.
  • Batch mode means instant return of data from the search engine to the frontend, but only at the moment when the most recent offer is processed.
  • the streaming mode allows you to send 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.
  • a request (for layers AviaUserSearch and AviaSmartSearch, as will be described below) is a set of directions for which the user wants to purchase tickets, as well as the configuration of passengers and service classes for each of these directions.
  • the user can thus form a request in the graphical user interface of the web resource or by means of a description.
  • the request may be the following: two directions "Moscow - St. Russia” for December 10, with 1 adult and 1 child in economy class, and "St.town - Moscow” for December 15, with 1 adult and 1 child in economy class.
  • the search engine does not restrict queries to the same configuration of passengers and service classes.
  • the configuration of passengers and service classes in the request is indicated for each direction separately, including if the user interface allows you to set them once for all directions.
  • 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.
  • a bunch of REST + JSON technologies can be used instead of gRPC, but not limited to.
  • the request received from the user is transformed by the request transformation module (in the AviaSmartSearch layer).
  • 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.
  • a separate search query is created for each direction.
  • all directions are combined into an atomic search query.
  • search "roundtrip" English roundtrip
  • affiliate Scheme is a channel for booking and selling an offer.
  • the same offer can be received from different booking systems (for example, Aeroflot's offers can be received from Saber, Galileo, Sirena, etc.).
  • This offer may have slightly different rates and taxes in different booking systems, in addition, the agency fees that the web service of this technical solution receives differ.
  • 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).
  • the final price is the same for different sales channels.
  • offers from the same booking system can be issued through different legal entities, which also affects the profitability and price.
  • the user's query may be transformed by a search strategy across the hubs.
  • offers with a transfer also combine the booking systems themselves.
  • you can separately search for "Cheboksary - Moscow” and separately “Moscow - Miami” and then combine offers from different booking systems.
  • a fuzzy 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 this technical solution determines that in January the sea is warm in Southeast Asia and the Caribbean, and accordingly makes inquiries to the GDS "Moscow - silk", “Moscow - Gavana " 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.
  • tariffs are determined by means of the module for determining tariff rules (SegmentConditions) of the AviaGateSearch layer, which enriches the search results obtained from the gateways, and informs the user about the tariff options available on each offer.
  • a database is used, which 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 the structure of 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 fares of the Light group”) and exceptions from exceptions, etc. ...
  • Other implementations use the information received in the response from the reservation system gateway.
  • the user is determined and informed about the features of individual offers (offer price, charter flight, ordering with separate tickets, technical landings, etc.).
  • whether it is a charter flight or not is defined on the AviaGateSearch layer. For example, only charters come from the Sig23 gateway, and charters come only from it. The determination of the possibility of ordering with separate tickets can take place on different layers of the system. In some implementations, gateways are already sending ticketing offers - this is the AviaGateSearch layer. In another implementation, this is determined by a combiner from the AviaSmartSearch layer when combining sentences into a single whole.
  • 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 costs of the payment gateway and minus the partner fee, which is charged by partners for selling a ticket through this partner.
  • these parameters can be either set directly in the program code in advance (for example, the percentage of a payment gateway), or calculated on the basis of a database.
  • the profitability includes the expected costs of user support (contact center, communication channels), etc., but is not limited to.
  • 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).
  • Backend (English back-end) - software and hardware part of a technical solution.
  • 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 gateway responses are cached).
  • the overhead time remains within 3 seconds, or returns to these limits by horizontal scaling of computing power, which makes it possible to achieve the technical result of the present invention, increasing the speed of obtaining search suggestions by the user.
  • the overhead is the total time the user received the offer minus the time it takes to contact and wait for a response from the reservation system gateway. ...
  • a cache search is performed instead of a gateway search.
  • they receive any offer from the gateway they save it to the cache, for example, for half an hour (the time is configured 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.
  • 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.
  • enriched results are understood to mean data that are directly related to the proposal.
  • 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.
  • intermediate landings are displayed as refueling, and sometimes these are actually aircraft refueling); sh. elements of return on sale of an offer iv. other options
  • information that depends on the user is: a personalized recommendation of a particular proposal; a way to sort and group sentences.
  • a preliminary request comes from the Avia-Smart-Search module (for example, a request from a user "Moscow-Spb-Moscow" for specific dates) and gets to the dispatcher, who knows that there are many gateways and sends a search request to them.
  • the request comes from a custom frontend, which is a web request with dates, destinations, passenger configurations, and service classes.
  • AviaGateway without changing the essence converts it into a request in an internal format (for example, gRPC), AviaUserSearch passes it further into AviaSmartSearch. But AviaSmartSearch converts one user request into many requests of the AviaGateSearch layer, each of which will then be sent to each gateway.
  • the Avia-Gate-Search layer performs specific searches in the modules for interacting with specific gateways (module for interacting with the Galileo system, module for interacting with the Saber system, etc.) that are located on this layer.
  • 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.
  • IATA is developing the NDC protocol recommended for interfacing with reservation system gateways.
  • the NDC protocol is used to communicate with individual airline reservation gateways.
  • 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 require a single passenger configuration and service class for all flights, while the search request for this technical solution does not contain this limitation (however, the request to the AviaGateSearch layer may contain this limitation), and if the client wants a different configuration passengers on different flights, then by internal transformations its request is split into several requests to the gateways.
  • the request to the gateway contains information about the gateway user (data for authentication and authorization of the gateway user), as well as the gateway's recommendations on which offers to choose. For example, you can make a request to the gateway to search not for any flights on the route "Moscow - St. Russia", 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.
  • each offer 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 by an identifier - a fare code), etc.
  • the database contains basic rules (basically, the basic rule depends on the airline that sets the fare and the fare code) and exceptions to these rules.
  • the AviaGateSearch layer manager copies the received requests to the gateway representatives (GateRepresent in Fig. 2) as shown in Fig. 2. 2.
  • Each module for interaction with the gateway has its own gateway representative.
  • a gateway representative is a module that knows about the features of a particular gateway 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 a GHA code, then it is useless to send a request to Saber - he does not know how to work with GHA codes. creating an output queue.
  • the dispatcher generates a unique name for the output queue based on algorithms provided by the development environment.
  • the AviaGateSearch layer manager can create a queue in some implementations on the data bus (for example, RabbitMQ) (RabbitMQ - a software message broker based on the AMQP standard - replicated middleware focused on message processing), into which the response will fall, and reports its name layer Avia-Smart-Search.
  • the dispatcher can use, for example, the Nats message broker, but is not limited to.
  • the gateway representative module decides whether the gateway will execute the request and how many requests are needed (search schemes), informs the dispatcher upstairs how many searches have been started. The dispatcher, in turn, sums up these numbers, thus getting the total number of expected responses and communicating them through the GateSearch module to the top of the GateSearchAdapter module of the AviaSmartSearch layer.
  • GSGA codes where the module decides to send a request to the gateway or not. These are either technical features of the gateway operation, or in the technical solution it is decided that it makes no sense to send certain requests to a specific gateway (the assortment is scarce, offers are more expensive, etc.) and these rules are described in the internal database.
  • the module for interacting with the gateway generates a request to the API of the corresponding gateway and sends it, after which it receives a response and converts it into the GateOffer format, and in some cases checks for the presence of a response in the cache.
  • this module determines the state of processing and makes decisions about stopping 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), in advance a specified number of messages (for example, from 0 to 15, not limited), a predetermined time for receiving messages, terminating messages.
  • Each module works in one specific way, specifically the GateSearchAdapter knows the expected number of messages.
  • a terminating 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.
  • the module for scoring the offers of the AviaUserSearch layer which are identical from the user's point of view, scores the offers and makes decisions on the expediency of further processing in various implementation options:
  • the goal of scoring is to choose from a set of offers that are identical from the user's point of view.
  • the AviaSmartSearch layer manager optimizes the number of requests to the AviaGateSearch layer, after which it creates a multiplexer of the results, starts the mechanism for transporting requests and data between layers, namely, transfers the request to the module for transporting requests and data between AviaGateSearch and AviaSmartSearch layers, creates an input queue in data bus (e.g. RabbitMQ).
  • data bus e.g. RabbitMQ
  • This mechanism is needed in order to be able to physically separate data bus installations (for example, RabbitMQ) according to layers.
  • a multiplexer is a way of organizing data transport, with the goal of obtaining copies of the same data set by multiple recipients.
  • the module for sending requests and receiving responses sends a request to the AviaGateSearch layer, receives the name of the output queue (it is a unique string.
  • the watchdog timer fixes a predetermined time for receiving messages (for example, 15 seconds). When the time expires, the wait ends.
  • the multiplexer duplicates each sentence into each combiner specified when the multiplexer was created.
  • the merging module accumulates the results for all individual searches included in the group, while also performing the function of a watchdog timer.
  • a group is a set of search queries for the AviaGateSearch layer into which a custom query has been converted.
  • this module generates SmartOffer and SmartVariant.
  • this component keeps statistics of generated SmartOffer'oB and decides to transfer each of them to the AviaUserSearch level, sends SmartOffer'bi to the data bus. 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.
  • Combined Offer (or SmartOffer) - a combined set of Search Suggestions from different responses received to requests to the AviaGateSearch layer, and a 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).
  • Combined Variant is a combination of different Search Options (OfferVariant) from different Search Offers (SearchOffer) within one combined offer.
  • a search offer 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. Moscow - Moscow on 01.01.2020 in St. Russia and 07.01.2020 back) and a set of options tariffs at which this combination can be issued.
  • Each such variation is called a search variation (or SearchVariant).
  • the search option consists of specifying the fare code for each flight in the Search offer, information on available fare options (baggage, the possibility of exchange and refund, but not limited to them), as well as available design options (from which booking system the option was received and which legal entity can to be issued) and the rates and taxes corresponding to the design options
  • the Avia-User-Search layer transfers the user's request unchanged to the Avia-Smart-Search layer without transformations, but at the same time creates the necessary transport infrastructure for processing the results. Then it receives data (offers in SmartOffer format) from the Avia-Smart-Search layer and performs processing depending on a specific user (pricing and a / b companies, marketing campaigns, etc.).
  • the AviaUserSearch layer manager starts the data processing pipeline to listen to a specific queue, passes the request to the AviaSmartSearch layer, gets the names of the queues to which the response will arrive, and tells them to SmartSearchAdapter'y so that it listens to the queues and transfers messages to the data bus (RabbitMQ) of the AviaUserSearch layer.
  • the SmartSearchAdapter module receives the name of the output queue, listens to it, transfers it to the data bus, and this module serves as a watchdog timer.
  • the data processing pipeline transfers the results of the offer from the AviaSmartSearch layer to the price calculation module, which calculates the final price of the offer, then calculates the scoring of offers that are the same from the user's point of view and performs filtering depending on the specific user. Scoring in this technical solution means 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 certain rating to the offers. The absolute value of the rating in this case does not matter, only their comparison ratios play a role.
  • 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.
  • Filtration 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 using his username, and the offers for the promotion were not shown to those who were not logged in.
  • filtering of low-conversion offers on large SERPs can be implemented in order to simplify the process of selecting an appropriate offer by the user.
  • offers are validated (eg, marketing promotions).
  • the scoring module evaluates "the same" offers when SearchOffer and SearchVariant match. That is, offers are considered the same if they have the same set of segments (for example, a specific flight) and fare options.
  • the segments are compared by flight parameters, marketing carrier and flight number.
  • carrier the airline that owns the aircraft operating the flight.
  • Marketing carrier - the airline that sets the conditions of carriage for a specific passenger and assigns the flight number. For example, if the user flies by Aeroflot, Aeroflot is the operating carrier.
  • the Avia-Search-Gateway layer initiates data exchange with the manager of the Avia-User-Search layer using an internal protocol (for example, gRPC) in the mode of receiving a stream from the server. That is, the client (Avia-Search-Gateway layer) sends one request to the server (Dispatcher), and in response expects consecutive incoming offers. In this case, the request is not transformed.
  • an internal protocol for example, gRPC
  • the Avia-User-Search Layer Manager module creates one queue in RabbitMQ, which will receive ready-to-serve offers. It then creates one queue that will be used to transport the data received from the Avia-Smart-Search layer to the processing pipeline of the Avia-User-Search layer.
  • the dispatcher then sends the user request unchanged to the Avia-Smart-Search layer transformer module and receives from it is the name of the queue to which the Avia-Smart-Search layer will transfer the results of its work. Then the dispatcher sends the received queue name to the module for interaction with the AviaSmartSearch level, which waits for the combined offers to arrive in this queue and serves as a watchdog timer (see Fig. 6)
  • the request transformation module forms two groups of requests from the received request.
  • the first contains two separate search queries (Moscow - St. Russia and St. Russia - Moscow), the second contains a combined atomic query (Moscow - St. Russia - Moscow).
  • These groups are transferred to the Ayia-Smart-Search layer manager, which creates three multiplexers according to the number of unique searches in the created groups, launches two modules for combining sentences by number of groups, matches unique lookups, multiplexers, and pooling modules by creating queues in RabbitMQ.
  • the dispatcher then passes each unique search as a request to the AviaGateSearch layer interaction module. Further processing of each of the unique searches occurs in parallel (see Fig. 3)
  • the module for interaction with the AviaGateSearch layer transfers the received requests to the AviaGateSearch layer, receives from it the name of the queue from which the Search Suggestions can be received, and the expected number of messages, and starts the message waiting process.
  • this module serves as a watchdog timer (see Fig. 3)
  • the AviaGateSearch layer manager creates an output queue in RabbitMQ, then communicates the request parameters to a predefined set of Gateway Representatives. 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 and passes the search request to the module of the corresponding module of interaction with the gateway.
  • the dispatcher having received and summed up the responses from all Representatives, reports the name of the output queue and the total expected number of messages to the module for interacting with the AviaGateSearch layer of the AviaSmartSearch layer. (see Fig. 2)
  • Each of the modules for interacting with the gateway that received a search query independently and in parallel converts it to the gateway format, executes it, receives a response, converts it into the SearchOffer format, and transfers the received Search Suggestions via RabbitMQ to the search suggestions enrichment module (see Fig. 2)
  • the module for enriching search suggestions with data by accessing the relevant databases adds information about the baggage available for carriage, the possibility of exchange or return, intermediate landings, elements of profitability, etc. to the offers.
  • Offers received from different gateways for different search queries are processed by the enrichment module independently and in parallel (see Fig. 2)
  • the module for interaction with the AviaGateSearch layer receives messages containing Search Suggestions and, through RabbitMQ, transfers them to the appropriate Multiplexer.
  • the multiplexer copies the message for each of the corresponding Aggregation Modules (see Fig. 5)
  • Aggregation Module 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 suggestions "round trip” by separate queries - at least one Search Suggestion for each of the two searches "in one direction” ) starts combining them into Combined Offers (SmartOffer) and Combined Variants (SmartVariant).
  • Combined Offers SmartOffer
  • Combined Variants SmartVariant
  • Each received Unified Offer via RabbitMQ is independently and in parallel sent to the AviaUserSearch layer (see Fig. 5)
  • the module for interaction with the AviaSmartSearch layer of the AviaUserSearch layer receives the Combined offers and, through RabbitMQ, passes them to the Offer Processing Pipeline of the AviaUserSearch layer (see Fig. 7)
  • the offer pipeline filters offers that are not available to a specific user, determines the offer price for each offer, and calculates a score for each offer. As a result, a proposal is formed, ready to be shown to the user, which is transmitted to the AviaSearchGateway layer (see Fig. 7)
  • the data stream is converted into a packet on the AviaSearchGateway layer, after which the data is presented to the frontend for display to the user.
  • this solution may be implemented as a smart flight search computing system 400, which includes one or more of the following components:
  • processing component 401 containing at least one processor
  • the processing component 401 generally controls all the operations of the system 400, such as processing data about the user or their flight search request, and also controls the display, phone call, data transfer, camera operation, and recording operation of the mobile communications device.
  • the processing component 401 may include one or more processors 402 that implement instructions to complete all or part of the steps of the above methods.
  • the processing component 401 may include one or more modules for convenient communication between other processing modules 401 and other modules.
  • the processing component 401 may include a media module for convenient, lightweight interaction between the media component 405 and the processing component 401.
  • 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 system 400.
  • 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.
  • SRAM static random access memory
  • EEPROM Electrically Erasable Programmable Read Only Memory
  • EPROM Erasable Programmable Read Only Memory
  • EPROM Programmable Read Only Memory
  • ROM Read Only Memory device
  • magnetic memory flash memory
  • flash memory magnetic disk or optical disk and others, but not limited to.
  • 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.
  • 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 touch panel includes one or more touch sensors in terms of gestures, touching and sliding on 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.
  • the media 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.
  • the audio component 406 is configured to output and / or input an audio signal.
  • 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.
  • the audio component 406 also includes a single speaker configured to output an audio signal.
  • the input / output (I / O) interface 407 provides an interface between the processing component 401 and any peripheral interface module.
  • the above peripheral interface module may be a 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.
  • Sensor component 408 includes one or more sensors and is configured to provide various aspects of assessing the state of system 400. For example, sensor component 408 may detect on / off states of system 400, relative positioning of components, such as display and keypad, of one component of system 400, the presence or absence of contact between the subject and the system 400, as well as the orientation or acceleration / deceleration and temperature change of the system 400.
  • the sensor component 408 comprises a non-contact sensor made with the ability 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.
  • sensor component 408 includes an acceleration sensor, gyroscope sensor, magnetic sensor, pressure sensor, or temperature sensor.
  • 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.
  • communication component 409 receives a broadcast signal or broadcast associated information from an external broadcast control system via a broadcast channel.
  • communication component 409 comprises a Near Field Communication (NFC) module to facilitate near field communication.
  • NFC Near Field Communication
  • 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.
  • RFID radio frequency identification
  • IrDA infrared data association
  • UWB ultra-wideband
  • Bluetooth Bluetooth
  • system 400 may be implemented by one or more Specialized
  • ASIC Integrated Circuits
  • DSP Digital Signal Processor
  • DSP Digital Signal Processing Devices
  • a logic device PLD
  • field programmable logic chip FPGA
  • controller microcontroller
  • microprocessor or other electronic components, and may be configured to implement smart flight search method 500.
  • nonvolatile 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.
  • nonvolatile computer readable media can be ROM, random access memory (RAM), CD, magnetic tape, floppy disks, optical storage devices, and the like.
  • 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.
  • GUI graphical user interface
  • 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, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGA), the logic of which is set through programming, can be used.
  • FPGA programmable logic integrated circuits
  • 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.
  • FPGAs programmable logic controllers
  • BMK basic matrix crystals
  • ASICs specialized custom large integrated circuits (LSI), which are significantly more expensive for small-scale and single-piece production.
  • the FPGA itself consists of the following components:
  • Blocks can also be implemented using read-only memory devices.
  • aspects of the present technical solution may be implemented as a system, method, or computer program product. Accordingly, various aspects of the present technical solution 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 technical solution 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.
  • 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 computer-readable storage media include: one or more wire connection; 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.
  • 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.
  • 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 a combination of the above.
  • Computer program code to perform operations for the steps of this technical solution 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. for example, 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.
  • 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 service providers).
  • LAN local area network
  • WAN wide area network
  • Internet service providers for example, via the Internet using Internet service providers.
  • These computer program instructions can also be stored on a computer-readable medium that can control a computer other than a programmable data processing device or devices that function in a particular way, such that the instructions stored on the computer-readable medium create a device that includes instructions that carry out the functions / actions indicated in the block of the block diagram and / or diagram.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Настоящее техническое решение, в общем, относится к области вычислительной техники, а в частности к способам и системам для осуществления умного поиска предложений билетов. Техническим результатом, достигаемым при решении вышеуказанной технической проблемы, является повышение скорости получения пользователем поисковых предложений билетов. Способ для осуществления поиска предложений билетов, выполняемый посредством по меньшей мере одним процессором, в котором получают по меньшей мере один запрос от пользователя на поиск предложений билетов; осуществляют преобразование по меньшей мере одного запроса от пользователя, полученного на предыдущем шаге, в набор запросов для шлюзов систем бронирования; распределяют набор запросов для шлюзов, полученных на предыдущем шаге, по модулям взаимодействия со шлюзом посредством диспетчера; определяют посредством по меньшей мере одного модуля взаимодействия со шлюзом будет ли данный шлюз выполнять запрос и сколько необходимо запросов к данному шлюзу; выполняют по меньшей мере один поисковый запрос в шлюзе системы бронирования предложений билетов для тех запросов, которые определили как доступные на предыдущем шаге; получают данные предложений по билетам по меньшей мере от одной системы бронирования предложений билетов; формируют на основании полученных предложений по меньшей мере один ответ пользователю на запрос, который был от него получен.

Description

СПОСОБ И СИСТЕМА ДЛЯ ОСУЩЕСТВЛЕНИЯ ПОИСКА ПРЕДЛОЖЕНИЙ БИЛЕТОВ
ОБЛАСТЬ ТЕХНИКИ Настоящее техническое решение, в общем, относится к области вычислительной техники, а в частности к способам и системам для осуществления поиска предложений билетов.
УРОВЕНЬ ТЕХНИКИ
В настоящее время существующие в уровне техники решения поиска предложений билетов обладают рядом серьезных недостатков, не позволяющих быстро получать пользователям поисковые предложения. Шлюзы систем бронирования в разное время отвечают на запросы, что увеличивает время ожидания клиентом поисковой выдачи.
В большинстве случаев (кроме совсем региональных направлений) ни один шлюз систем бронирования не содержит весь возможный ассортимент предложений. Кроме того, информация, возвращаемая шлюзами, зачастую неполна или неудобна для понимания неспециалистом.
Из уровня техники известна международная заявка WO2018135834 (А1) «Plane ticket search system and method using modified plane ticket» (Заявитель: FLTGRAPH CO LTD [KR], Дата публикации: 2018-07-26). В данном решении раскрыты система и способ поиска рейсов с использованием модифицированного билета на самолет. Система поиска рейсов в соответствии с вариантом осуществления настоящего изобретения содержит: модуль управления для предоставления информации о существующем билете на самолет в пользовательском терминала; и модуль модификации для приема запроса на модификацию для заранее определенного компонента выбора среди компонентов существующего билета на самолет, предоставленных пользовательскому терминалу, причем компоненты включают в себя место отправления, место остановки, место назначения и информацию о пребывании в месте остановки, указанном в билете на самолет, причем модуль управления выполняет обработку таким образом, что пользовательский терминал может искать целевой билет на самолет, используя модифицированный компонент и унаследованный компонент, которые включены в компоненты модифицированного билета на самолет, отражающие запрос на изменение, при этом измененный компонент является компонентом, отражающим запрос на изменение в отношении компонента выбора среди компонентов существующего билета на самолет, а унаследованный компонент является компонентом среди компонентов существующего билета на самолет, для которого нет запроса на изменение.
СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ
Технической проблемой или технической задачей, решаемой в данном техническом решении, является осуществление способа и системы быстрого поиска предложений билетов.
Техническим результатом, достигаемым при решении вышеуказанной технической проблемы, является повышение скорости получения пользователем поисковых предложений билетов. Дополнительным техническим результатом является предоставление пользователю более точных предложений, повышение количества выбора механизмов помощи пользователю в выборе предложения.
Указанный технический результат достигается благодаря осуществлению способа для осуществления поиска предложений билетов, который выполняет посредством по меньшей мере одним процессором, в котором получают по меньшей мере один запрос от пользователя на поиск предложений билетов; осуществляют преобразование по меньшей мере одного запроса от пользователя, полученного на предыдущем шаге, в набор запросов для шлюзов систем бронирования; распределяют набор запросов для шлюзов, полученных на предыдущем шаге, по модулям взаимодействия со шлюзом посредством диспетчера; определяют посредством по меньшей мере одного модуля взаимодействия со шлюзом будет ли данный шлюз выполнять запрос и сколько необходимо запросов к данному шлюзу; выполняют по меньшей мере один поисковый запрос в шлюзе системы бронирования билетов для тех запросов, которые определили как доступные на предыдущем шаге; получают данные предложений по билетам по меньшей мере от одной системы бронирования билетов; формируют на основании полученных предложений по меньшей мере один ответ пользователю на запрос, который был от него получен.
В некоторых вариантах реализации технического решения при получении запроса от пользователя на поиск предложений билетов преобразовывают его в формат gRPC или REST и JSON.
В некоторых вариантах реализации технического решения при получении запроса от пользователя, который содержит направление туда и обратно, разделяют его на два поисковых запроса посредством модуля преобразования запроса в рамках одной или нескольких партнерской схемы результатов.
В некоторых вариантах реализации технического решения для каждого направления цену формируют отдельно.
В некоторых вариантах реализации технического решения полученные запросы от пользователя на поиск предложений билетов объединяют в группы.
В некоторых вариантах реализации технического решения полученный запрос от пользователя на поиск предложений билетов преобразовывают посредством стратегии поиска через хабы.
В некоторых вариантах реализации технического решения получают данные предложений по билетам из шлюза системы бронирования и/или кэша.
В некоторых вариантах реализации технического решения данные предложений билетов получают из кэша после уточнения его актуальности по конкретному предложению.
В некоторых вариантах реализации технического решения осуществляют неточный поиск посредством модуля преобразования запроса.
В некоторых вариантах реализации технического решения поисковый запрос в модуль взаимодействия со шлюзом является сетевым запросом SOAP или RPC, или XML.
В некоторых вариантах реализации технического решения поисковый запрос в модуль взаимодействия со шлюзом имеет разный формат в зависимости от шлюза.
В некоторых вариантах реализации технического решения поисковый запрос в модуль взаимодействия со шлюзом содержит набор направлений и дат, на которые пользователи ищет билет, конфигурация пассажиров и сервисный класс. В некоторых вариантах реализации технического решения поисковый запрос в модуль взаимодействия со шлюзом содержит информацию о пользователе шлюза для аутентификации и авторизации, а также рекомендации шлюза по тому, какие предложения выбрать.
В некоторых вариантах реализации технического решения при получении запросов диспетчер
• формирует выходную очередь, которая содержит уникальное имя;
• посылает в шину данных команду на создание данной выходной очереди с таким уникальным именем;
• сообщает модулям взаимодействия со шлюзом, что направлять данные необходимо из систем бронирования в данную очередь.
В некоторых вариантах реализации технического решения шина данных представляет из себя программный брокер RabbitMQ или Nats.
В некоторых вариантах реализации технического решения при определении того, будет ли шлюз выполнять запрос и сколько необходимо запросов к нему используют базу данных с заранее заданными правилами.
В некоторых вариантах реализации технического решения на всех шагах способа используют поточную обработку данных.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Признаки и преимущества настоящего технического решения станут очевидными из приведенного ниже подробного описания и прилагаемых чертежей, на которых:
На Фиг. 1 показан пример реализации архитектуры многослойной системы для осуществления умного поиска предложений билетов.
На Фиг. 2 показан пример реализации архитектуры слоя AviaGateSearch.
На Фиг. 3 показан пример реализации синхронизации в слое Avia-Smart- Search.
На Фиг. 4 показан пример вычислительной архитектуры системы через компоненты для осуществления умного поиска предложений билетов.
На Фиг. 5 показан пример реализации движения данных в слое Avia- Smart-Search. На Фиг. 6 показан пример реализации синхронизации в слое Avia-User- Search.
На Фиг. 7 показан пример реализации движения данных в слое Avia-User- Search.
ПОДРОБНОЕ ОПИСАНИЕ ТЕХНИЧЕСКОГО РЕШЕНИЯ
Ниже будут подробно рассмотрены термины и их определения, используемые в описании технического решения.
В данном изобретении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций), централизованные и распределенные базы данных, смарт-контракты.
Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы), смарт-контракт, виртуальная машина Ethereum (EVM) или подобное. Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.
Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.
Контрольный таймер (aHm.watchdog timer букв «сторожевой пёс») — аппаратно реализованная схема контроля над зависанием системы. Представляет собой таймер, который периодически сбрасывается контролируемой системой. Если сброса не произошло в течение некоторого интервала времени, происходит принудительная перезагрузка системы. В некоторых случаях сторожевой таймер может посылать системе сигнал на перезагрузку («мягкая» перезагрузка), в других же — перезагрузка происходит аппаратно (замыканием сигнального провода RST или подобного ему).
Также возможна софтверная эмуляция данного решения, когда функции таймера, а также сброса (перезагрузки) системы выполняет внешняя система по отношению к контролируемой. В данном случае используется реализация системных таймеров и сигналов управления, внешние по отношению к исполняемому алгоритму.
Поисковая система (англ. Search engine) — это компьютерная система, предназначенная для поиска информации.
Диспетчер — модуль системы, отвечающий за управление процессами.
В данном техническом решении реализован поисковый функционал, который более подробно ниже раскрыт. В качества примера использования для ясности понимания при прочтении используются предложения авиабилетов, однако любому специалисту в уровне техники очевидно, что могут быть использованы предложения ЖД билетов, автобусных билетов и так далее или в совокупности, в зависимости от системы бронирования.
Архитектура системы включает следующие компоненты (слои), как показано на Фиг. 1 :
• Avia-Search-Gateway - слой преобразования потока данных в пакет данных и форматов данных.
• Avia-User-Search - слой формирования поисковой выдачи для конкретного пользователя;
• Avia-Smart-Search - слой преобразования запросов пользователя в набор запросов к слою Avia-Gate-Search для поиска лучших результатов по ассортименту;
• Avia-Gate-Search - слой, который отправляет поисковые запросы в поисковые шлюзы и обогащает результаты информацией, не зависящей от конкретного пользователя.
Концепция слоев - одна из общеупотребительных моделей, используемых разработчиками в вычислительной области техники для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. Слой n + 1 использует слой п, следовательно, абстракция понятий слоя п + 1 по меньшей мере не ниже, чем у слоя п,а если архитектура системы эффективна, то уровень абстракции слоя должен быть выше. Соответственно, слой п скрывает (инкапсулирует) логику работы с понятиями, определенными на этом слое, позволяя, таким образом, слою п + 1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные средства нижележащего слоя. Можно выбирать альтернативную реализацию базовых слоев: компоненты верхнего слоя способны работать без каких-либо изменений в нижележащих слоях при условии сохранения интерфейсов. Зависимость между слоями, т.е. фактически интерфейсы, предоставляемые нижними слоями верхним, можно свести к минимуму. Такая минимизация интерфейсов позволяет увеличивать гибкость системы.
Слои способны удачно инкапсулировать многое, но не все: модификация одного слоя подчас связана с необходимостью внесения каскадных изменений в остальные слои. Наличие избыточных слоев нередко снижает производительность системы. При переходе от слоя к слою данные обычно подвергаются преобразованиям из одного представления в другое. Несмотря на это, инкапсуляция нижележащих функций зачастую позволяет достичь весьма существенного преимущества.
Каждый из слоев содержит один или более модулей. Модули, объединяются в слои по тому, с какими данными они работают.
Ни один верхний слой не меняет данные из нижних слоёв, т.е. на слое Avia-Smart-Search не происходит изменений в поисковых предложениях (см. далее параграф 0086). В данном техническом решении осуществляют поиск в шлюзах, каждый из которых предоставляет доступ к одной или нескольким системам бронирования поисковых предложений в соответствии с заданным пользователем запросом. Шлюз может использовать XML-протокол (XML- шлюз, но не ограничиваясь, который позволяет формировать справочные запросы, получать ответы, а также использовать весь контент, например, АРС "Сирена-Трэвел" для бронирования и продажи авиаперевозок.
В некоторых вариантах реализации утвержден режим предоставления поисковых результатов на фронтенд - пакетный или поточный, и накладываемые ими ограничения. Пакетный режим подразумевает одномоментную отдачу данных от поисковой системы на фронтенд, но только в тот момент, когда будет обработано самое последнее предложение. Поточный режим позволяет отдавать каждое предложение сразу после обработки именно его, не дожидаясь остальных, но накладывает дополнительные требования на протокол передачи данных, плюс при поточном режиме невозможно использовать информацию о всей выдаче при обработке каждого конкретного предложения.
Запросом (для слоев AviaUserSearch и AviaSmartSearch как будет раскрыто далее) является набор направлений, на которые пользователь хочет приобрести билеты, а также конфигурация пассажиров и классов обслуживания на каждое из этих направлений. Пользователь может таким образом формировать запрос в графическом интерфейсе пользователя веб-ресурса или посредством описания. Например, запросом может являться следующее: два направления «Москва — Спб» на 10 декабря, причем 1 взрослый и 1 ребенок в эконом классе, и «Спб — Москва» на 15 декабря, причем 1 взрослый и 1 ребенок в эконом классе. Поисковая система не ограничивает запросы одинаковой конфигурацией пассажиров и классов обслуживания. Конфигурация пассажиров и классов обслуживания в запросе указывается для каждого направления отдельно, в том числе в случае, если пользовательский интерфейс позволяет задать их один раз на все направления. Технически поисковый механизм, реализованный в системе, получает пользовательский запрос в виде запроса по сети, который затем преобразуется, например, в запрос во внутреннем формате, например, gRPC запрос) и передается между компонентами поискового механизма (иногда - «движка») или ядра другими словами. В других вариантах реализации вместо gRPC может использоваться связка технологий REST+JSON, но не ограничиваясь.
Затем полученный от пользователя запрос преобразуется посредством модуля преобразования запроса (в слое AviaSmartSearch). Пользовательский запрос, состоящий из более чем одного направления с одинаковыми конфигурациями пассажиров и классов обслуживания, преобразуется в как минимум две группы поисковых запросов. В первой группе на каждое направление создается отдельный поисковый запрос. Во второй группе все направления комбинируются в атомарный поисковый запрос. Например, поиск “туда-обратно” (англ roundtrip) Москва - Спб - Москва на 01.01.2020 и 07.01.2020 на одного взрослого пассажира в классе Эконом на оба направления будет преобразован в две группы поисковых запросов: в первой группе будут два отдельных запроса (англ oneway) Москва - Спб и Спб - Москва, для каждого из которых будет указана конфигурация пассажиров и класс обслуживания; во второй группе будет один атомарный поиск Москва - Спб - Москва с единой конфигурацией пассажиров и классов обслуживания на все направления сразу. В некоторых реализациях более сложные пользовательские запросы могут быть трансформированы в большее число групп запросов. Полученные в рамках одной группы поисковых запросов Поисковые Предложения (см. п.0086) затем комбинируются в Объединенные Предложения (см. п.0084), в том числе и между различными Партнерскими Схемами.
Партнерская Схема представляет собой канал бронирования и продажи предложения. Например, одно и то же предложение может быть получено из разных систем бронирования (например, предложения Аэрофлота могут быть получены из систем бронирования Сейбр, Галилео, Сирена и т.п.). У этого предложения могут немного отличаться тарифы и таксы в разных системах бронирования, кроме того, отличаются агентские вознаграждения, которые получает веб-сервис данного технического решения. В конкретном варианте реализации рассчитывают цену для каждого такого варианта отдельно, и эти цены могут отличаться, причем в таком случае предлагают пользователю самое дешевое (хотя есть исключения). В других вариантах реализации конечная цена является одной и той же для разных каналов продажи. Кроме того, даже предложения из одной и той же системы бронирования могут оформлять через разные юридические лица, что тоже влияет на доходность и цену.
В некоторых вариантах реализации запрос пользователя может преобразовываться посредством стратегии поиска через хабы. Необходимо отметить, что предложения с пересадкой комбинируют и сами системы бронирования. В данном же техническом решении можно комбинировать предложения от разных систем бронирования, а также путем явного разбиения маршрута на составляющие на основе собственных знаний посылать дополнительные запросы в системы бронирования, чтобы получить больше вариантов. Например, пользователь ищет «Чебоксары — Майами». Ни одна система бронирования такого перелета не найдет, потому что из Чебоксар летают только локальные рейсы, которых нет в системах бронирования, в которых есть рейсы Москва - Майами. Однако в данном техническом решении известно, что можно отдельно поискать «Чебоксары — Москва» и отдельно «Москва - Майами», а затем скомбинировать предложения из разных систем бронирования.
В некоторых вариантах реализации осуществляют неточный поиск в конкретном варианте реализации посредством модуля преобразования запроса, например, поиск в страну и из страны, тематический поиск, поиск на плавающие даты и т.п. Пользователь делает запрос «Москва — Тёплое море в январе», а в данном техническом решении определяют, что в январе море тёплое в Юго-Восточной Азии и на Карибах, и соответственно сделает запросы в ГДС «Москва — Пхукет», «Москва — Г авана» и т.д. Нечеткий поиск - это поиск информации, при котором выполняется сопоставление информации заданному образцу поиска или близкому к этому образцу значению.
Дополнительно определяют тарифы посредством модуля определения тарифных правил (SegmentConditions) слоя AviaGateSearch, который обогащает результаты поиска, полученные из шлюзов, и информируют пользователя о доступных на каждом предложении тарифных опциях. В конкретном варианте реализации используют базу данных, наполняемую контент-отделом или автоматически посредством парсинга внешних систем, на основе текстов тарифных правил, описания тарифов на сайтах авиакомпаний, а также напрямую запросами в авиакомпании. В базе данных может содержаться структура из наиболее общего правила (например, “на всех рейсах Аэрофлота доступно одно место багажа”) и исключений из него (например, “для тарифов Аэрофлота группы Лайт мест багажа нет”) и исключений из исключений и т.д. В других вариантах реализации используют информацию, полученную в ответе от шлюза системы бронирования.
В некоторых вариантах реализации определяют и информируют пользователя об особенностях отдельных предложений (цена предложения, чартерный рейс, заказ раздельными билетами, технические посадки и т.п.).
В некоторых вариантах реализации, чартерный рейс это или нет определяется на слое AviaGateSearch. Например, из шлюза Sig23 приходят только чартеры, и чартеры приходят только из него. Определение возможности заказа раздельными билетами может происходить на разных слоях системы. В некоторых вариантах реализации шлюзы уже направляют предложения с оформлением билетов — это уровень AviaGateSearch. В другом варианте реализации это определяется объединителем со слоя AviaSmartSearch при комбинации предложений в единое целое.
Определение технических посадок происходит в модуле определения промежуточных посадок (SegmentLegs) слоя AviaGateSearch.
В конкретном варианте реализации цена предложения представляет собой сумму тарифа и такс (получаемые от ГДС), а также сервисного сбора. Для задания сервисного сбора используется отдельный модуль Pricing. Он может представлять собой модель, полученная методами машинного обучения (но не ограничиваясь). Модель строится на основе исторических данных о продажах и результатах поиска, которая генерирует множество конфигураций сервисных сборов, из которых потом выбирают оптимальную конфигурацию. Доходность определяется как сумма сервисного сбора и агентских вознаграждений, которые оплачивают авиакомпании и ГДС за продажу билета, минус расходы на платежный шлюз и минус партнерский сбор, который взимается партнерами за продажу билета через этого партнера. В зависимости от схемы продажи эти параметры могут быть как заданы непосредственно в программном коде заранее (например, процент платежного шлюза), так и рассчитываться на основе базы данных. В некоторых вариантах реализации в доходность закладывают ожидаемые расходы на поддержку пользователя (контакт-центр, каналы связи) и т.п., не ограничиваясь.
В данном техническом решении время от получения запроса до формирования ответа бэкендом в 95% случаев не превышает времени ответа самого медленного из включенных шлюзов плюс 3 секунды (надбавочное время). Бэкенд (англ back-end) — программно-аппаратная часть технического решения. Полное время на формирование первого предложения, которое можно отобразить пользователю в 95% случаев не превышает полутора секунд (в данном случае именно полное, а не добавочное, но здесь это практически одно и то же, поскольку ответы шлюзов кэшируются).
При увеличении ассортимента, приходящего из какого-либо из шлюзов систем бронирования, либо добавлении нового шлюза, либо увеличении и усложнении комбинированных предложений, надбавочное время остается в пределах 3 секунд, либо возвращается в эти пределы путем горизонтального масштабирования вычислительных мощностей, что позволяет достичь технического результата данного изобретения, повышения скорости получения пользователем поисковых предложений. Надбавочное время представляет собой полное время получения предложения пользователем минус время на обращение и ожидание ответа от шлюза системы бронирования. . Смысл этого требования в том, чтобы в большинстве случаев при увеличении объема проходящих через поисковую систему данных, можно было сохранять надбавочное время в пределах, например, 3 секунд не путем модифицирования алгоритмов, переписывания программного кода системы, а путем выделения большего объема ресурсов (ОЗУ, процессорное время) и/или создания большего количества копий компонентов поисковой системы.
В некоторых вариантах реализации осуществляют поиск по кэшу вместо поиска по шлюзу. Заранее если получают какое-либо предложение из шлюза, то сохраняют его в кэш, например, на полчаса (время настраивается отдельно для каждого шлюза). Соответственно, если в течение получаса кто-то из пользователей сделает аналогичный запрос, то в данном решении не обращаются в шлюз, а загружают из кэша сохраненное предложение. Уточнение того, что кэш актуален, будет произведено уже для конкретного предложения, которое пользователь выберет для покупки.
Дополнительно учтена в архитектуре системы возможность предоставления API другим продуктам, в том числе и сторонним, с учетом кастомизации предоставляемого функционала.
Под обогащенными результатами в данном техническом решении подразумеваются данные, относящиеся непосредственно к предложению. Помимо базовой информации, которую сообщает шлюз системы бронирования, это: i. тарифные опции, ii. информация о промежуточных посадках (в авиационной терминологии отличаются пересадки, когда меняется номер рейса, и промежуточные посадки, когда он не меняется, хотя с точки зрения пользователя они выглядят одинаково — в большинстве случаев ему нужно выйти из самолёта. В данном решении промежуточные посадки отображаются как дозаправки, причем иногда это действительно дозаправки самолёта); ш. элементы доходности за продажу предложения iv. иные опции
С другой стороны, информация, зависящая от пользователя, это: персонифицированная рекомендация того или иного предложения; способ сортировки и группировки предложений.
Предварительно приходит запрос из модуля Avia-Smart-Search (например, запрос от пользователя «Москва-Спб-Москва» на конкретные даты) и попадает в диспетчер, который знает, что существует много шлюзов и рассылает по ним поисковый запрос. Запрос приходит от пользовательского фронтенда, который представляет собой запрос по сети с датами, направлениями, конфигурациями пассажиров и сервисными классами. AviaGateway без изменения сути преобразует его в запрос во внутреннем формате (например, gRPC), AviaUserSearch прокидывает дальше в AviaSmartSearch. А вот AviaSmartSearch один пользовательский запрос преобразует в множество запросов слоя AviaGateSearch, каждый из которых потом будет передан каждому шлюзу.
Слой Avia-Gate-Search выполняет конкретные поисковые запросы в модули взаимодействия с конкретными шлюзами (модуль взаимодействия с системой Galileo, модуль взаимодействия с системой Sabre и т. д.), которые расположены на этом слое. В общем случае поисковый запрос — это сетевой запрос (запрос на основе HTTP, например, SOAP или RPC или XML запрос). Формат поискового запроса у каждого шлюза свой. Например, IATA развивает протокол NDC, рекомендуемый для взаимодействия с шлюзами систем бронирования. В одном из вариантов реализации протокол NDC используется для взаимодействия со шлюзами бронирования отдельных авиакомпаний. В запросе всегда есть набор направлений и дат, на которые пользователь хочет найти билет, конфигурация пассажиров и сервисный класс. По крайней мере, некоторые шлюзы требуют единую конфигурацию пассажиров и сервисный класс на все перелеты, тогда как поисковый запрос данного технического решения этого ограничения не содержит (однако, запрос к слою AviaGateSearch может содержать это ограничение), и если клиент хочет разную конфигурацию пассажиров на разные перелеты, то внутренними преобразованиями его запрос разбивается на несколько запросов к шлюзам.
Кроме того, запрос к шлюзу содержит информацию о пользователе шлюза (данные для аутентификации и авторизации пользователя шлюза), а также рекомендации шлюза по тому, какие предложения выбирать. Например, можно сделать запрос к шлюзу поискать не любые перелеты по маршруту «Москва — Спб», но только без пересадок, или только Аэрофлота. В ряде случаев это позволяет несколькими запросами получить больший ассортимент. Правила указания таких параметров содержатся в базе данных.
Например, если из шлюзов не приходит информация какой клиенту доступен багаж по предложению, данная информация определяется в модуле определения тарифных правил (SegmentConditions), основанный на базе данных, которая выше упоминалась. Если более развернуто, то у каждого предложения есть ряд свойств: аэропорты вылета и прилета, дата и время вылета и прилета, авиакомпания, выполняющая рейс (чей самолёт), авиакомпания, назначающая тариф (не деньги, а именно условия перевозки, закодированные авиакомпанией каким-либо идентификатором — кодом тарифа) и т. д. База данных содержит базовые правила (в основном базовое правило зависит от авиакомпании, назначающей тариф, и кода тарифа), и исключения из этих правил.
Диспетчер слоя AviaGateSearch копирует полученные запросы по представителям шлюза (англ. GateRepresent на Фиг. 2) как показано на Фиг. 2. На каждый модуль взаимодействия со шлюзом есть свой представитель шлюза. Например, на модуль взаимодействия с Sabre есть представитель Sabre. Представителем шлюза является модуль, который знает об особенностях конкретного шлюза и соответственно решает, имеет ли смысл туда посылать запрос. Например, если пользователь хочет найти билеты в какой-нибудь маленький аэропорт, у которого нет IATA-кода, а есть только ГСГА-код, то бесполезно посылать запрос в Sabre — он не умеет работать с ГСГА-кодами.В некоторых вариантах реализации диспетчер занимается созданием выходной очереди. Диспетчер генерирует уникальное имя выходной очереди на основе алгоритмов, предоставляемых средой разработки. Затем он посылает в шину данных (англ. Data Bus) (например, RabbitMQ) команду на создание очереди с таким именем), а затем сообщает представителям шлюза, что писать результаты нужно в эту очередь (точнее имя очереди через запросы прокидывается до конвейера обработки данных, который уже будет писать в очередь), а также сообщает на слой AviaSmartSearch модулю GateSearchAdapter, что читать нужно из этой очереди.
Диспетчер слоя AviaGateSearch может создавать очередь в некоторых вариантах реализации в шине данных (например, RabbitMQ) (RabbitMQ — программный брокер сообщений на основе стандарта AMQP — тиражируемое связующее программное обеспечение, ориентированное на обработку сообщений), в которую будет попадать ответ, и сообщает её имя слою Avia- Smart-Search. Также диспетчер может использовать, например, брокер сообщений Nats, не ограничиваясь. Модуль представителя шлюза решает, будет ли шлюз выполнять запрос и сколько всего необходимо запросов (поисковые схемы), сообщает наверх диспетчеру сколько поисков запущено. Диспетчер в свою очередь суммирует эти числа, получает таким образом общее число ожидаемых ответов и сообщает их через модуль GateSearch наверх модулю GateSearchAdapter слоя AviaSmartSearch. Выше приведен пример с ГСГА-кодами, где модуль решает посылать в шлюз запрос или нет. Это либо технические особенности работы шлюза, либо в техническом решении решается, что те или иные запросы посылать в конкретный шлюз не имеет смысла (ассортимент скудный, предложения дороже и т. д.) и описываются эти правила во внутренней базе данных. Модуль взаимодействия со шлюзом формируют запрос к API соответствующего шлюза и отправляют его, после чего получают ответ и преобразуют его в формат GateOffer, причем в некоторых вариантах проверяет наличие ответа в кэше.
Во всей архитектуре технического решения во всех модулях осуществляется поточная обработка данных. Каждое предложение обрабатывается, как только появились все данные, необходимые для этой обработки. Как показано выше на примере из описания стратегии поиска через хабы: чтобы получить предложение по маршруту «Чебоксары — Майами», необходимо хотя бы по одному предложению по каждому из маршрутов «Чебоксары — Москва» и «Москва — Майами». В данном случае гарантируется обработка зависимых друг от друга данных одним и тем же процессом. Гарантия достигается за счёт того, что после трансформации пользовательского запроса в набор групп запросов к слою AviaGateSearch существует диспетчер, который назначает задание на комбинацию предложений из конкретной группы конкретному экземпляру модуля объединителя. Зависимыми данными являются предложения по каждой из частей перелета, необходимые для составления скомбинированного предложения.
Также данный модуль (GateSearchAdapter) определяет состояние обработки и принимает решения о прекращении обработки посредством опроса состояний (каждый сервис, который ожидает каких-то данных не знает о состоянии нижележащих процессов, но может принять решение о завершении ожидания с помощью описанных далее методов), заранее оговоренного количества сообщений (например, от 0 до 15, не ограничиваясь), заранее оговоренного времени приема сообщений, терминирующих сообщений. Каждый модуль работает с одним конкретным способом, конкретно GateSearchAdapter знает ожидаемое количество сообщений. Терминирующее сообщение представляет собой сообщение, которое содержит не данные, а информацию о том, что больше данных не будет, например, строку «finish». Может возникнуть проблема, что терминирующее сообщение придет в принимающий модуль не последним, несмотря на то, что было отправлено последним. Это решается указанием в терминирующем сообщении количества сообщений с данными, например, сообщение finish:45 означает, что нужно обработать 45 сообщений с данными.
При поточной обработке данных, как показано на Фиг. 3, модуль скоринга одинаковых с точки зрения пользователя предложений слоя AviaUserSearch осуществляет скоринг предложений и принимает решения о целесообразности дальнейшей обработки в различных вариантах реализации:
• на уровне создания предложений;
• на уровне обработки предложений.
Целью скоринга является выбор из набора одинаковых с точки зрения пользователя предложений для показа.
Диспетчер слоя AviaSmartSearch оптимизирует количество запросов к слою AviaGateSearch, после чего создает мультиплексер (англ. Multiplexer) результатов, запускает механизм транспортировки запросов и данных между слоями, а именно передает запрос модулю транспортировки запросов и данных между слоями AviaGateSearch и AviaSmartSearch, создаёт входную очередь в шине данных (например, RabbitMQ). Данный механизм нужен для того, чтобы была возможность физически разделить инсталляции шины данных (например, RabbitMQ) в соответствии со слоями. Мультиплексер представляет собой способ организации транспорта данных, ставящий своей целью получение копий одного и того же набора данных несколькими получателями.
Модуль направления запросов и получения ответов передает запрос на слой AviaGateSearch, получает имя выходной очереди (представляет собой уникальную строку. Выше описано как диспетчер слоя AviaGateSearch создает ее и передает), слушает её и перекладывает ответы в мультиплексер, а также выполняет роль контрольного таймера (англ watchdog). Контрольный таймер фиксирует заранее оговоренное время приема сообщений (например, 15 секунд). По истечении времени ожидание завершается.
Мультиплексер дублирует каждое предложение в каждый модуль объединения, указанный при создании мультиплексера.
Модуль объединения аккумулирует результаты по всем отдельным поискам, входящим в группу, при этом еще и исполняет функцию контрольного таймера. Группа представляет собой набор поисковых запросов к слою AviaGateSearch, в который был преобразован пользовательский запрос. Как только в каждом отдельном поиске из группы есть хотя бы одно предложение, данный модуль формирует SmartOffer и SmartVariant. Также данный компонент ведет статистику сформированных SmartOffer’oB и принимает решение о передачи каждого из них на уровень AviaUserSearch, отправляет SmartOffer’bi в шину данных. Данное решение принимается для того, чтобы не передавать слишком много информации, а это в свою очередь, чтобы не усложнять выбор пользователя и убрать лишнюю нагрузку на вычислительные и транспортные мощности. Например, существует поиск «туда-обратно». Туда 100 предложений, обратно 100. Если комбинировать и отдавать пользователю всё со всем, получится 10000, что повышает сильно вычислительную нагрузку.
Объединенное Предложение (или SmartOffer) - объединенный набор Поисковых Предложений из разных ответов, полученных на запросы к слою AviaGateSearch, и соответствующий набор Объединенных Вариантов. Например, если мы искали RT (англ. RoundTrip - поиск туда-обратно), то это может быть атомарный ответ, либо же объединение двух OW. (англ. Oneway - поиск в одну сторону). Объединенный Вариант (или SmartVariant) - комбинация различных Поисковых Вариантов (OfferVariant) из разных поисковых предложений (SearchOffer) в рамках одного объединенного предложения.
Поисковое предложение (или SearchOffer) представляет из себя конкретную комбинацию рейсов по поисковому запросу (например, полученная по атомарному поиску Москва - СПб - Москва на 01.01.2020 в СПб и 07.01.2020 обратно комбинация рейсов SU025 и SU026 в соответствующие даты) и набор вариантов тарифов, по которым может быть оформлена эта комбинация. Каждый такой вариант называется поисковым вариантом (или SearchVariant). Поисковый вариант состоит из указания кода тарифа для каждого рейса в Поисковом предложении, информацию о доступных тарифных опциях (багаж, возможность обмена и возврата, но не ограничиваясь ими), а также доступные варианты оформления (из какой системы бронирования получен вариант и каким юридическим лицом может быть оформлен) и соответствующие вариантам оформления тарифы и таксы
Предварительно слой Avia-User-Search передает запрос пользователя в неизменном виде на слой Avia-Smart-Search без преобразований, но при этом создает необходимую транспортную инфраструктуру для обработки результатов. Затем принимает данные (предложения в формате SmartOffer) со слоя Avia-Smart-Search и производит обработки, зависящие от конкретного пользователя (ценообразование и а/б компании, маркетинговые акции и т.п.).
Диспетчер слоя AviaUserSearch запускает конвейер обработки данных на прослушивание конкретной очереди, передает запрос слою AviaSmartSearch, получает имена очередей, в которые поступит ответ, и сообщает их SmartSearchAdapter’y, чтобы тот слушал очереди и перекладывал сообщения в шину данных (RabbitMQ) слоя AviaUserSearch.
Далее модуль SmartSearchAdapter получает имя выходной очереди, слушает её, перекладывает в шину данных, причем данный модуль служит контрольным таймером (англ watchdog).
Конвейер обработки данных передает результаты предложения со слоя AviaSmartSearch в модуль вычисления цены, который рассчитывает конечную цену предложения, затем рассчитывает скоринг одинаковых с точки зрения пользователя предложений и проводит фильтрации, зависящие от конкретного пользователя. Под скорингом в данном техническом решении понимается механизм, позволяющий управлять показом одинаковых с точки зрения пользователя предложений в поточном режиме путем присваивания предложениям некоторого рейтинга. Абсолютное значение рейтинга в данном случае не имеет значения, играют роль лишь их отношения сравнения. Например, если на выдачу ушло предложение за 2000 рублей с рейтингом 1, а затем было получено и обработано аналогичное предложение за 1990 рублей, то ему можно поставить рейтинг 2, чтобы у фронтенда был простой критерий для того, чтобы скрыть предложение за 2000 и вместо него показать предложение за 1990 рублей. Под фильтрацией понимается недопущение на выдачу предложений, недоступных конкретному пользователю. Например, существует акция одной из авиакомпаний, где обязательным условием является то, что пользователь вошел на сайт под своим логином, а незалогиненным предложения по акции не показывались. В некоторых вариантах реализации может быть реализована фильтрация низкоконверсионных предложений на больших выдачах с целью упрощения процесса выбора пользователем подходящего ему предложения. В некоторых вариантах реализации осуществляют валидацию предложений (например, маркетинговые акции).
Модуль скоринга оценивает "одинаковые” предложения, когда совпадает SearchOffer и SearchVariant. Т.е. одинаковыми считаются предложения, у которых одинаковый набор сегментов (например, конкретный рейс) и тарифных опций. Сегменты сравниваются по параметрам перелета, маркетинговому перевозчику и номеру рейса. Оперирующий перевозчик — авиакомпания, которой принадлежит самолёт, выполняющий рейс. Маркетинговый перевозчик — авиакомпания, устанавливающая условия перевозки для конкретного пассажира и назначающая номер рейса. Например, если пользователь летит самолетом Аэрофлота, Аэрофлот — оперирующий перевозчик. Условия перевозки ему назначил Аэрофлот, и поставил номер рейса SU292. Для рейса SU292 Аэрофлот — маркетинговый перевозчик. Но на соседнем кресле летит человек, которому условия перевозки назначили Вьетнамские Авиалинии и номер рейса для него VN555. По рейсу VN555 маркетинговый перевозчик — Вьетнамские Авиалинии, хотя оперирующий по-прежнему Аэрофлот. При проходе через конвейер обработки данных, осуществляется группировка по хэшу, где рассматриваются совокупности предложений, имеющих одинаковый хэш.
Ниже приведен конкретный пример реализации данного технического решения.
Пользователь хочет поискать билеты на рейс Москва - Спб - Москва на одного взрослого человека на 01.01.2020 и 07.01.2020 в классе Эконом. Он вводит эти параметры в форме поиска, которая передает их слою Avia-Search- Gateway в формате, где для каждого направления (Москва - СПб и СПб - Москва) продублирована конфигурация пассажиров и выбранный класс обслуживания (один взрослый в классе Эконом)
Слой Avia-Search-Gateway инициирует обмен данными с модулем диспетчер слоя Avia-User-Search по внутреннему протоколу (например, gRPC) в режиме получения потока от сервера. То есть клиент (слой Avia-Search- Gateway) посылает серверу (Диспетчеру) один запрос, а в ответ ожидает последовательно приходящие предложения. Запрос при этом не трансформируется.
Модуль Диспетчер слоя Avia-User-Search создает одну очередь в RabbitMQ, в которую будут поступать готовые к показу предложения. Затем он создает одну очередь, которая будет использоваться для транспортировки данных, полученных со слоя Avia-Smart-Search, в конвейер обработки слоя Avia-User-Search Затем Диспетчер отсылает пользовательский запрос в неизменном виде модулю преобразователя слоя Avia-Smart-Search и получает от него имя очереди, в которую слой Avia-Smart-Search будет передавать результаты своей работы. После чего диспетчер отправляет полученное имя очереди иодулю взаимодействия с уровнем AviaSmartSearch, который ожидает поступления объединенных предложений в эту очередь и служит контрольным таймером (см. Фиг.6)
Модуль преобразования запросов из полученного запроса формирует две группы запросов. Первая содержит два отдельных поисковых запроса (Москва - Спб и Спб - Москва), вторая содержит объединенный атомарный запрос (Москва - Спб - Москва). Эти группы передаются диспетчеру слоя Ayia- Smart-Search, который создает три мультиплексера по числу уникальных поисков в созданных группах, запускает два модуля объединения предложений по числу групп, устанавливает соответствие уникальных поисков, мультиплексеров и модулей объединения путем создания очередей в RabbitMQ. Затем диспетчер передает каждый уникальный поиск в виде запроса модулю взаимодействия со слоем AviaGateSearch. Дальнейшая обработка каждого из уникальных поисков происходит параллельно (см. Фиг.З)
Модуль взаимодействия со слоем AviaGateSearch передает полученные запросы на слой AviaGateSearch, получает от него имя очереди, из который можно будет получить Поисковые Предложения, и ожидаемое количество сообщений и запускает процесс ожидания сообщений. При этом данный модуль выполняет служит контрольным таймером (см. Фиг.З)
Диспетчер слоя AviaGateSearch создает выходную очередь в RabbitMQ, затем сообщает параметры запроса заранее известному набору Представителей шлюзов. Каждый из них определяет, сколько поисковых запросов будет запущено соответствующим модулем взаимодействия со шлюзом, сообщает это число Диспетчеру и передает поисковый запрос модулю соответствующему модулю взаимодействия со шлюзом. Диспетчер, получив и просуммировав ответы от всех Представителей, сообщает имя выходной очереди и общее ожидаемое количество сообщений модулю взаимодействия со слоем AviaGateSearch слоя AviaSmartSearch. (см. Фиг.2)
Каждый из модулей взаимодействия со шлюзом, получивший поисковый запрос, независимо и параллельно преобразует его в формат шлюза, выполняет его, получает ответ, преобразует его в формат Поискового Предложения SearchOffer и передает полученные Поисковые Предложения посредством RabbitMQ модулю обогащения поисковых предложений данными (см. Фиг.2)
Модуль обогащения поисковых предложений данными посредством обращения к соответствующим базам данных добавляет в предложения информацию о доступном к провозу багаже, возможности обмена или возврата, промежуточных посадках, элементах доходности и т.д. Сообщение, состоящее из обогащенных таким образом предложений, полученных в результате одного поискового запроса к одному шлюзу системы бронирования, посредством RabbitMQ передается на слой AviaSmartSearch. Предложения, полученные из разных шлюзов по разным поисковым запросам, модулем обогащения обрабатываются независимо и параллельно (см. Фиг.2) Модуль взаимодействия со слоем AviaGateSearch получает сообщения, содержащие Поисковые Предложения и посредством RabbitMQ передает их соответствующему Мультиплексеру. Мультиплексер копирует сообщение для каждого из сооветствующих Модулей Объединения (см. Фиг.5)
Модуль Объединения, получив хотя бы по одному Поисковому Предложению по каждому из поисковых запросов, входящих в группу (например, в случае поиска предложений “туда-обратно” раздельными запросами - хотя бы по одному Поисковому Предложению для каждого из двух поисков “в одну сторону”), начинает их комбинацию в Объединенные Предложения (SmartOffer) и Объединенные Варианты (SmartVariant). Каждое полученное Объединенное предложение посредством RabbitMQ независимо и параллельно отправляется на слой AviaUserSearch (см. Фиг.5)
Модуль взаимодействия со слоем AviaSmartSearch слоя AviaUserSearch получает Объединенные предложения и посредством RabbitMQ передает их Конвейеру обработки предложений слоя AviaUserSearch (см. Фиг.7)
Конвейер обработки предложений фильтрует предложения, недоступные для конкретного пользователя, определяет цену предложения для каждого предложения и вычисляет для каждого предложения скоринг. В результате формируется предложение, готовое к показу пользователю, которое передается на слой AviaSearchGateway (см. Фиг.7)
В некоторых вариантах реализации на слое AviaSearchGateway производится преобразование потока данных в пакет, после чего данные предоставляют фронтенду для показа пользователю
Ссылаясь на Фиг. 4, данное техническое решение может быть реализовано в виде вычислительной системы 400 осуществления умного поиска авиабилетов, которая содержит один или более из следующих компонентов:
• компонент 401 обработки, содержащий по меньшей мере один процессор
402,
• память 403,
• компонент 405 мультимедиа,
• компонент 406 аудио,
• интерфейс 407 ввода / вывода (I / О),
• сенсорный компонент 408, • компонент 409 передачи данных.
Компонент 401 обработки в основном управляет всеми операциями системы 400, например, осуществляет обработку данных о пользователе или его запросе на поиск авиабилетов, а также управляет дисплеем, телефонным звонком, передачей данных, работой камеры и операцией записи мобильного устройства связи. Компонент 401 обработки может включать в себя один или более процессоров 402, реализующих инструкции для завершения всех или части шагов из указанных выше способов. Кроме того, компонент 401 обработки может включать в себя один или более модулей для удобного процесса взаимодействия между другими модулями 401 обработки и другими модулями. Например, компонент 401 обработки может включать в себя мультимедийный модуль для удобного облегченного взаимодействия между компонентом 405 мультимедиа и компонентом 401 обработки.
Память 403 выполнена с возможностью хранения различных типов данных для поддержки работы системы 400, например, базу данных с профилями пользователей. Примеры таких данных включают в себя инструкции из любого приложения или способа, контактные данные, данные адресной книги, сообщения, изображения, видео, и т. д., и все они работают на системе 400. Память 403 может быть реализована в виде любого типа энергозависимого запоминающего устройства, энергонезависимого запоминающего устройства или их комбинации, например, статического оперативного запоминающего устройства (СОЗУ), Электрически-Стираемого Программируемого постоянного запоминающего устройства (ЭСППЗУ), Стираемого Программируемого постоянного запоминающего устройства (СППЗУ), Программируемого постоянного запоминающего устройства (ППЗУ), постоянного запоминающего устройства (ПЗУ), магнитной памяти, флэш- памяти, магнитного диска или оптического диска и другого, не ограничиваясь.
Компонент 405 мультимедиа включает в себя экран, обеспечивающий выходной интерфейс между системой 400, которая может быть установлена на мобильном устройстве связи пользователя и пользователем. В некоторых вариантах реализации, экран может быть жидкокристаллическим дисплеем (ЖКД) или сенсорной панелью (СП). Если экран включает в себя сенсорную панель, экран может быть реализован в виде сенсорного экрана для приема входного сигнала от пользователя. Сенсорная панель включает один или более сенсорных датчиков в смысле жестов, прикосновения и скольжения по сенсорной панели. Сенсорный датчик может не только чувствовать границу прикосновения субъекта или жест перелистывания, но и определять длительность времени и давления, связанных с режимом работы на прикосновение и скольжение. В некоторых вариантах осуществления компонент 405 мультимедиа включает одну фронтальную камеру и/или одну заднюю камеру. Когда система 400 находится в режиме работы, например, режиме съемки или режиме видео, фронтальная камера и/или задняя камера могут получать данные мультимедиа извне. Каждая фронтальная камера и задняя камера может быть одной фиксированной оптической системой объектива или может иметь фокусное расстояние или оптический зум.
Компонент 406 аудио выполнен с возможностью выходного и/или входного аудио сигнала. Например, компонент 406 аудио включает один микрофон (MIC), который выполнен с возможностью получать внешний аудио сигнал, когда система 400 находится в режиме работы, например, режиме вызова, режима записи и режима распознавания речи. Полученный аудио сигнал может быть далее сохранен в памяти 403 или направлен по компоненту 409 передачи данных. В некоторых вариантах осуществления компонент 406 аудио также включает в себя один динамик выполненный с возможностью вывода аудио сигнала.
Интерфейс 407 ввода / вывода (I / О) обеспечивает интерфейс между компонентом 401 обработки и любым периферийным интерфейсным модулем. Вышеуказанным периферийным интерфейсным модулем может быть клавиатура, руль, кнопка, и т. д. Эти кнопки могут включать, но не ограничиваясь, кнопку запуска, кнопку регулировки громкости, начальную кнопку и кнопку блокировки.
Сенсорный компонент 408 содержит один или более сенсоров и выполнен с возможностью обеспечения различных аспектов оценки состояния системы 400. Например, сенсорный компонент 408 может обнаружить состояния вкл/выкл системы 400, относительное расположение компонентов, например, дисплея и кнопочной панели, одного компонента системы 400, наличие или отсутствие контакта между субъектом и системой 400, а также ориентацию или ускорение/замедление и изменение температуры системы 400. Сенсорный компонент 408 содержит бесконтактный датчик, выполненный с возможностью обнаружения присутствия объекта, находящегося поблизости, когда нет физического контакта. Сенсорный компонент 408 содержит оптический датчик (например, КМОП или ПЗС-датчик изображения) выполненный с возможностью использования в визуализации приложения. В некоторых вариантах сенсорный компонент 408 содержит датчик ускорения, датчик гироскопа, магнитный датчик, датчик давления или датчик температуры.
Компонент 409 передачи данных выполнен с возможностью облегчения проводной или беспроводной связи между системой 400 и другими устройствами. Система 400 может получить доступ к беспроводной сети на основе стандарта связи, таких как WiFi, 2G, 3G, 5G, или их комбинации. В одном примерном варианте компонент 409 передачи данных получает широковещательный сигнал или трансляцию, связанную с ними информацию из внешней широковещательной системы управления через широковещательный канал. В одном варианте осуществления компонент 409 передачи данных содержит модуль коммуникации ближнего поля (NFC), чтобы облегчить ближнюю связь. Например, модуль NFC может быть основан на технологии радиочастотной идентификации (RFID), технологии ассоциации передачи данных в инфракрасном диапазоне (IrDA), сверхширокополосных (UWB) технологии, Bluetooth (ВТ) технологии и других технологиях.
В примерном варианте осуществления система 400 может быть реализована посредством одной или более Специализированных
Интегральных Схем (СИС), Цифрового Сигнального Процессора (ЦСП), Устройств Цифровой Обработки Сигнала (УЦОС), Программируемым
Логическим Устройством (ПЛУ), логической микросхемой, программируемой в условиях эксплуатации (ППВМ), контроллера, микроконтроллера, микропроцессора или других электронных компонентов, и может быть сконфигурирован для реализации способа 500 осуществления умного поиска авиабилетов.
В примерном варианте осуществления энергонезависимый машиночитаемый носитель содержит память 403, которая включает инструкции, где инструкции выполняются процессором 401 системы 400 для реализации описанных выше способов осуществления умного поиска авиабилетов. Например, энергонезависимым машиночитаемым носителем может быть ПЗУ, оперативное запоминающее устройство (ОЗУ), компакт-диск, магнитная лента, дискеты, оптические устройства хранения данных и тому подобное.
Вычислительная система 400 может включать в себя интерфейс дисплея, который передает графику, текст и другие данные из коммуникационной инфраструктуры (или из буфера кадра, не показан) для отображения на компоненте 405 мультимедиа. Вычислительная система 400 дополнительно включает в себя устройства ввода или периферийные устройства. Периферийные устройства могут включать в себя одно или несколько устройств для взаимодействия с мобильным устройством связи пользователя, такие как клавиатура, микрофон, носимое устройство, камера, один или более звуковых динамиков и другие датчики. Периферийные устройства могут быть внешними или внутренними по отношению к мобильному устройству связи пользователя. Сенсорный экран может отображать, как правило, графику и текст, а также предоставляет пользовательский интерфейс (например, но не ограничиваясь ими, графический пользовательский интерфейс (GUI)), через который субъект может взаимодействовать с мобильным устройством связи пользователя, например, получать доступ и взаимодействовать с приложениями, запущенными на устройстве.
Элементы заявляемого технического решения находятся в функциональной взаимосвязи, а их совместное использование приводит к созданию нового и уникального технического решения. Таким образом, все блоки функционально связаны.
Все блоки, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем, что очевидно для специалиста в данном уровне техники. Не ограничиваюсь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задаётся посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др. Альтернативой ПЛИС могут быть программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже.
Обычно, сама микросхема ПЛИС состоит из следующих компонент:
• конфигурируемых логических блоков, реализующих требуемую логическую функцию;
• программируемых электронных связей между конфигурируемыми логическими блоками;
• программируемых блоков ввода/вывода, обеспечивающих связь внешнего вывода микросхемы с внутренней логикой.
Также блоки могут быть реализованы с помощью постоянных запоминающих устройств.
Таким образом, реализация всех используемых блоков достигается стандартными средствами, базирующимися на классических принципах реализации основ вычислительной техники.
Как будет понятно специалисту в данной области техники, аспекты настоящего технического решения могут быть выполнены в виде системы, способа или компьютерного программного продукта. Соответственно, различные аспекты настоящего технического решения могут быть реализованы исключительно как аппаратное обеспечение, как программное обеспечение (включая прикладное программное обеспечение и так далее) или как вариант осуществления, сочетающий в себе программные и аппаратные аспекты, которые в общем случае могут упоминаться как «модуль», «система» или «архитектура». Кроме того, аспекты настоящего технического решения могут принимать форму компьютерного программного продукта, реализованного на одном или нескольких машиночитаемых носителях, имеющих машиночитаемый программный код, который на них реализован.
Также может быть использована любая комбинация одного или нескольких машиночитаемых носителей. Машиночитаемый носитель хранилища может представлять собой, без ограничений, электронную, магнитную, оптическую, электромагнитную, инфракрасную или полупроводниковую систему, аппарат, устройство или любую подходящую их комбинацию. Конкретнее, примеры (неисчерпывающий список) машиночитаемого носителя хранилища включают в себя: электрическое соединение с помощью одного или нескольких проводов, портативную компьютерную дискету; жесткий диск, оперативную память (ОЗУ), постоянную память (ПЗУ), стираемую программируемую постоянную память (EPROM или Flash-память), оптоволоконное соединение, постоянную память на компакт- диске (CD-ROM), оптическое устройство хранения, магнитное устройство хранения или любую комбинацию вышеперечисленного. В контексте настоящего описания, машиночитаемый носитель хранилища может представлять собой любой гибкий носитель данных, который может содержать или хранить программу для использования самой системой, устройством, аппаратом или в соединении с ними.
Программный код, встроенный в машиночитаемый носитель, может быть передан с помощью любого носителя, включая, без ограничений, беспроводную, проводную, оптоволоконную, инфракрасную и любую другую подходящую сеть или комбинацию вышеперечисленного.
Компьютерный программный код для выполнения операций для шагов настоящего технического решения может быть написан на любом языке программирования или комбинаций языков программирования, включая объектно-ориентированный язык программирования, например, Python, R, Java, Smalltalk, C++ и так далее, и обычные процедурные языки программирования, например, язык программирования «С» или аналогичные языки программирования. Программный код может выполняться на компьютере пользователя полностью, частично, или же как отдельный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере, или же полностью на удаленном компьютере. В последнем случае, удаленный компьютер может быть соединен с компьютером пользователя через сеть любого типа, включая локальную сеть (LAN), глобальную сеть (WAN) или соединение с внешним компьютером (например, через Интернет с помощью Интернет-провайдеров).
Аспекты настоящего технического решения были описаны подробно со ссылкой на блок-схемы, принципиальные схемы и/или диаграммы способов, устройств (систем) и компьютерных программных продуктов в соответствии с вариантами осуществления настоящего технического решения. Следует иметь в виду, что каждый блок из блок-схемы и/или диаграмм, а также комбинации блоков из блок-схемы и/или диаграмм, могут быть реализованы компьютерными программными инструкциями. Эти компьютерные программные инструкции могут быть предоставлены процессору компьютера общего назначения, компьютера специального назначения или другому устройству обработки данных для создания процедуры, таким образом, чтобы инструкции, выполняемые процессором компьютера или другим программируемым устройством обработки данных, создавали средства для реализации функций/действий, указанных в блоке или блоках блок-схемы и/или диаграммы.
Эти компьютерные программные инструкции также могут храниться на машиночитаемом носителе, который может управлять компьютером, отличным от программируемого устройства обработки данных или отличным от устройств, которые функционируют конкретным образом, таким образом, что инструкции, хранящиеся на машиночитаемом носителе, создают устройство, включающее инструкции, которые осуществляют функции/действия, указанные в блоке блок-схемы и/или диаграммы.

Claims

ФОРМУЛА
1. Способ для осуществления поиска предложений билетов, выполняемый посредством по меньшей мере одним процессором и включающий следующие шаги:
• получают по меньшей мере один запрос от пользователя на поиск предложений билетов;
• осуществляют преобразование по меньшей мере одного запроса от пользователя, полученного на предыдущем шаге, в набор запросов для шлюзов систем бронирования;
• распределяют набор запросов для шлюзов, полученных на предыдущем шаге, по модулям взаимодействия со шлюзом посредством диспетчера;
• определяют посредством по меньшей мере одного модуля взаимодействия со шлюзом будет ли данный шлюз выполнять запрос и сколько необходимо запросов к данному шлюзу;
• выполняют по меньшей мере один поисковый запрос в шлюзе системы бронирования для тех запросов, которые определили как доступные на предыдущем шаге;
• получают данные предложений по билетам по меньшей мере от одной системы бронирования;
• формируют на основании полученных предложений по меньшей мере один ответ пользователю на запрос, который был от него получен.
2. Способ по п. 1, характеризующийся тем, что при получении запроса от пользователя на поиск предложений билетов преобразовывают его в формат gRPC или REST и JSON.
3. Способ по п. 1, характеризующийся тем, что при получении запроса от пользователя, который содержит направление туда и обратно, разделяют его на два поисковых запроса посредством модуля преобразования запроса в рамках одной партнерской схемы результатов.
4. Способ по п. 3, характеризующийся тем, что для каждого направления цену формируют отдельно.
5. Способ по п. 1, характеризующийся тем, что полученные запросы от пользователя на поиск предложений билетов объединяют в группы.
6. Способ по п. 1, характеризующийся тем, что полученный запрос от пользователя на поиск предложений билетов преобразовывают посредством стратегии поиска через хабы.
7. Способ по п. 1, характеризующийся тем, что получают данные предложений по билетам из шлюза системы бронирования и/или кэша.
8. Способ по п. 7, характеризующийся тем, что данные предложений билетов получают из кэша после уточнения его актуальности по конкретному предложению.
9. Способ по п. 1, характеризующийся тем, что осуществляют неточный поиск посредством модуля преобразования запроса.
10. Способ по п. 1, характеризующийся тем, что поисковый запрос в модуль взаимодействия со шлюзом является сетевым запросом SOAP или RPC, или XML.
11. Способ по п. 1, характеризующийся тем, что поисковый запрос в модуль взаимодействия со шлюзом имеет разный формат в зависимости от шлюза.
12. Способ по п. 1, характеризующийся тем, что поисковый запрос в модуль взаимодействия со шлюзом содержит набор направлений и дат, на которые пользователи ищет предложение билета, конфигурация пассажиров и сервисный класс.
13. Способ по п. 1, характеризующийся тем, что поисковый запрос в модуль взаимодействия со шлюзом содержит информацию о пользователе шлюза для аутентификации и авторизации, а также рекомендации шлюза по тому, какие предложения выбрать.
14. Способ по п. 1, характеризующийся тем, что при получении запросов диспетчер
• формирует выходную очередь, которая содержит уникальное имя;
• посылает в шину данных команду на создание данной выходной очереди с таким уникальным именем;
• сообщает модулям взаимодействия со шлюзом, что направлять данные необходимо из систем бронирования в данную очередь.
15. Способ по п. 14, характеризующийся тем, что шина данных представляет из себя программный брокер RabbitMQ или Nats.
16.Способ по п. 14, характеризующийся тем, что при определении того, будет ли шлюз выполнять запрос и сколько необходимо запросов к нему используют базу данных с заранее заданными правилами.
17. Способ по п. 1, характеризующийся тем, что на всех шагах способа используют поточную обработку данных.
18. Система для осуществления умного поиска предложений билетов, содержащая:
• по меньшей мере один процессор, выполненный с возможностью о получения по меньшей мере одного запроса от пользователя на поиск предложений билетов; о преобразования по меньшей мере одного запроса от пользователя, полученного на предыдущем шаге, в набор запросов для шлюзов систем бронирования; о получения предложений по билетам от по меньшей мере одной системы бронирования; о формирования на основании полученных предложений по меньшей мере одного ответа пользователю на запрос, который был от него получен.
• по меньшей мере один диспетчер, выполненный с возможностью распределения набора запросов для шлюзов, полученных процессором, по модулям взаимодействия со шлюзом;
• по меньшей мере один модуль взаимодействия со шлюзом, выполненный с возможностью определения будет ли данный шлюз выполнять запрос и сколько необходимо запросов к данному шлюзу;
• по меньшей мере одна система бронирования, выполненная с возможностью о выполнения по меньшей мере одного поискового запроса в шлюзе системы бронирования для тех запросов, которые были определены модулем взаимодействия со шлюзом как доступные; о направления на по меньшей мере один процессор предложений по билетам.
• формируют на основании полученных предложений по меньшей мере один ответ пользователю на запрос, который был от него получен.
PCT/RU2019/000977 2019-12-19 2019-12-19 Способ и система для осуществления поиска предложений билетов WO2021125997A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2019142437A RU2738590C1 (ru) 2019-12-19 2019-12-19 Способ и система для осуществления поиска предложений билетов
RU2019142437 2019-12-19

Publications (1)

Publication Number Publication Date
WO2021125997A1 true WO2021125997A1 (ru) 2021-06-24

Family

ID=73834979

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2019/000977 WO2021125997A1 (ru) 2019-12-19 2019-12-19 Способ и система для осуществления поиска предложений билетов

Country Status (2)

Country Link
RU (1) RU2738590C1 (ru)
WO (1) WO2021125997A1 (ru)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016724A1 (en) * 2000-07-28 2002-02-07 Yue-Heng Yang System and method for booking international multiple-stop tickets
US20120066200A1 (en) * 2000-02-22 2012-03-15 Harvey Lunenfeld Metasearch Engine for Ordering Items Returned In Travel Related Search Results Using Multiple Queries on Multiple Unique Hosts
EP3002714A1 (en) * 2014-09-30 2016-04-06 Amadeus S.A.S. Ticketing system with integrated personalized data
US20160253387A1 (en) * 2015-02-25 2016-09-01 FactorChain Inc. Automatic recursive search on derived information
US20190102423A1 (en) * 2017-09-29 2019-04-04 Oracle International Corporation System and method for providing an interface for a blockchain cloud service

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU117671U1 (ru) * 2011-08-11 2012-06-27 Закрытое акционерное общество "Электронный вокзал" Система продажи виртуальных билетов и проверки их действительности

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120066200A1 (en) * 2000-02-22 2012-03-15 Harvey Lunenfeld Metasearch Engine for Ordering Items Returned In Travel Related Search Results Using Multiple Queries on Multiple Unique Hosts
US20020016724A1 (en) * 2000-07-28 2002-02-07 Yue-Heng Yang System and method for booking international multiple-stop tickets
EP3002714A1 (en) * 2014-09-30 2016-04-06 Amadeus S.A.S. Ticketing system with integrated personalized data
US20160253387A1 (en) * 2015-02-25 2016-09-01 FactorChain Inc. Automatic recursive search on derived information
US20190102423A1 (en) * 2017-09-29 2019-04-04 Oracle International Corporation System and method for providing an interface for a blockchain cloud service

Also Published As

Publication number Publication date
RU2738590C1 (ru) 2020-12-14

Similar Documents

Publication Publication Date Title
KR102173108B1 (ko) 컨텍스트적 상호작용 메커니즘을 갖춘 컴퓨팅 시스템 및 그 작동 방법
US20170011444A1 (en) Intelligent Purchasing Systems and Methods
US20170293610A1 (en) Voice assistant
US20230394381A1 (en) Method and server for providing fare availabilities, such as airfare availabilities
US12106365B2 (en) Web browser and operating system portal and search portal with price time priority queues
AU2014363194C1 (en) Method and server for providing fare availabilities, such as air fare availabilities
US20150356446A1 (en) Systems and methods for a learning decision system with a graphical search interface
CN114930369A (zh) 具有不同费率类别的旅行服务
US12020575B2 (en) Autonomous vehicle fleet management system based on application status
EP4399599A1 (en) Systems and methods for data ingestion and generation of task recommendations in task facilitation services
US11625444B2 (en) Curated result finder
US20230022198A1 (en) Systems and methods for user interfaces including task delegation controls
CN110852810A (zh) 优惠信息管理方法与装置
US11551160B2 (en) Composite asset option pool
RU2738590C1 (ru) Способ и система для осуществления поиска предложений билетов
WO2023069154A1 (en) Searching trips based on accumulated subscription days
CN112866482B (zh) 一种对象行为习惯预测的方法和终端
US11860958B2 (en) Method and device of providing integrated search service
KR102230303B1 (ko) 콘텐츠 예약을 제공하는 애플리케이션을 운영하는 서버 및 그 동작 방법
US20210241185A1 (en) Composite Asset Creation
US20240045912A1 (en) Systems and methods for generating itinerary-related recommendations and/or predictions for a user
CN110766493B (zh) 业务对象提供方法、服务器、电子设备、存储介质
WO2022103289A1 (ru) Способ и система автоматизированного формирования предложений для заказа билетов
KR20140116385A (ko) 상품 또는 서비스를 검색 및/또는 구매하기 위한 개선된 방법 및 시스템
WO2021236314A1 (en) Subscription based travel service with delay

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19956244

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 02/11/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 19956244

Country of ref document: EP

Kind code of ref document: A1