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

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

 

ОБЛАСТЬ ТЕХНИКИ

[001] Настоящее изобретение, в общем, относится к области вычислительной техники, а в частности к способам и системам для осуществления поиска предложений билетов.

УРОВЕНЬ ТЕХНИКИ

[002] В настоящее время существующие в уровне техники решения поиска предложений билетов обладают рядом серьезных недостатков, не позволяющих быстро получать пользователям поисковые предложения. Шлюзы систем бронирования в разное время отвечают на запросы, что увеличивает время ожидания клиентом поисковой выдачи.

[003] В большинстве случаев (кроме совсем региональных направлений) ни один шлюз систем бронирования не содержит весь возможный ассортимент предложений. Кроме того, информация, возвращаемая шлюзами, зачастую неполна или неудобна для понимания неспециалистом.

[004] Из уровня техники известна международная заявка WO2018135834 (А1) «Plane ticket search system and method using modified plane ticket» (Заявитель: FLTGRAPH CO LTD [KR], Дата публикации: 2018-07-26). В данном решении раскрыты система и способ поиска рейсов с использованием модифицированного билета на самолет. Система поиска рейсов в соответствии с вариантом осуществления настоящего изобретения содержит: модуль управления для предоставления информации о существующем билете на самолет в пользовательском терминала; и модуль модификации для приема запроса на модификацию для заранее определенного компонента выбора среди компонентов существующего билета на самолет, предоставленных пользовательскому терминалу, причем компоненты включают в себя место отправления, место остановки, место назначения и информацию о пребывании в месте остановки, указанном в билете на самолет, причем модуль управления выполняет обработку таким образом, что пользовательский терминал может искать целевой билет на самолет, используя модифицированный компонент и унаследованный компонент, которые включены в компоненты модифицированного билета на самолет, отражающие запрос на изменение, при этом измененный компонент является компонентом, отражающим запрос на изменение в отношении компонента выбора среди компонентов существующего билета на самолет, а унаследованный компонент является компонентом среди компонентов существующего билета на самолет, для которого нет запроса на изменение.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[005] Технической проблемой или технической задачей, решаемой в данном изобретении, является осуществление способа и системы быстрого поиска предложений билетов.

[006] Техническим результатом, достигаемым при решении вышеуказанной технической проблемы, является повышение скорости получения пользователем поисковых предложений билетов.

[007] Дополнительным техническим результатом является предоставление пользователю более точных предложений, повышение количества выбора механизмов помощи пользователю в выборе предложения.

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

[009] В некоторых вариантах реализации изобретения при получении запроса от пользователя на поиск предложений билетов преобразовывают его в формат gRPC или REST и JSON.

[0010] В некоторых вариантах реализации изобретения при получении запроса от пользователя, который содержит направление туда и обратно, разделяют его на два поисковых запроса посредством модуля преобразования запроса в рамках одной или нескольких партнерской схемы результатов.

[0011] В некоторых вариантах реализации изобретения для каждого направления цену формируют отдельно.

[0012] В некоторых вариантах реализации изобретения полученные запросы от пользователя на поиск предложений билетов объединяют в группы.

[0013] В некоторых вариантах реализации изобретения полученный запрос от пользователя на поиск предложений билетов преобразовывают посредством стратегии поиска через хабы.

[0014] В некоторых вариантах реализации изобретения получают данные предложений по билетам из шлюза системы бронирования и/или кэша.

[0015] В некоторых вариантах реализации изобретения данные предложений билетов получают из кэша после уточнения его актуальности по конкретному предложению.

[0016] В некоторых вариантах реализации изобретения осуществляют неточный поиск посредством модуля преобразования запроса.

[0017] В некоторых вариантах реализации изобретения поисковый запрос в модуль взаимодействия со шлюзом является сетевым запросом SOAP или RPC, или XML.

[0018] В некоторых вариантах реализации изобретения поисковый запрос в модуль взаимодействия со шлюзом имеет разный формат в зависимости от шлюза.

[0019] В некоторых вариантах реализации изобретения поисковый запрос в модуль взаимодействия со шлюзом содержит набор направлений и дат, на которые пользователи ищет билет, конфигурация пассажиров и сервисный класс.

[0020] В некоторых вариантах реализации изобретения поисковый запрос в модуль взаимодействия со шлюзом содержит информацию о пользователе шлюза для аутентификации и авторизации, а также рекомендации шлюза по тому, какие предложения выбрать.

[0021] В некоторых вариантах реализации изобретения при получении запросов диспетчер

• формирует выходную очередь, которая содержит уникальное имя;

• посылает в шину данных команду на создание данной выходной очереди с таким уникальным именем;

• сообщает модулям взаимодействия со шлюзом, что направлять данные необходимо из систем бронирования в данную очередь.

[0022] В некоторых вариантах реализации изобретения шина данных представляет из себя программный брокер RabbitMQ или Nats.

[0023] В некоторых вариантах реализации изобретения при определении того, будет ли шлюз выполнять запрос и сколько необходимо запросов к нему используют базу данных с заранее заданными правилами.

[0024] В некоторых вариантах реализации изобретения на всех шагах способа используют поточную обработку данных.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0025] Признаки и преимущества настоящего изобретения станут очевидными из приведенного ниже подробного описания и прилагаемых чертежей, на которых:

[0026] На Фиг. 1 показан пример реализации архитектуры многослойной системы для осуществления умного поиска предложений билетов.

[0027] На Фиг. 2 показан пример реализации архитектуры слоя 140, который отправляет поисковые запросы в поисковые шлюзы и обогащает результаты информацией, не зависящей от конкретного пользователя (англ. AviaGateSearch).

[0028] На Фиг. 3 показан пример реализации синхронизации в слое 130 преобразования запросов пользователя в набор запросов к слою 140 для поиска лучших результатов по ассортименту (англ. Avia-Smart-Search).

[0029] На Фиг. 4 показан пример вычислительной архитектуры системы через компоненты для осуществления умного поиска предложений билетов.

[0030] На Фиг. 5 показан пример реализации движения данных в слое 130 преобразования запросов пользователя в набор запросов к слою 140 для поиска лучших результатов по ассортименту (англ. Avia-Smart-Search).

[0031] На Фиг. 6 показан пример реализации синхронизации в слое 120 формирования поисковой выдачи для конкретного пользователя (англ. Avia-User-Search).

[0032] На Фиг. 7 показан пример реализации движения данных в слое 120 формирования поисковой выдачи для конкретного пользователя (англ. Avia-User-Search).

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0033] Ниже будут подробно рассмотрены термины и их определения, используемые в описании изобретения.

[0034] В данном изобретении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций), централизованные и распределенные базы данных, смарт-контракты.

[0035] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы), смарт-контракт, виртуальная машина Ethereum (EVM) или подобное. Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0036] Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

[0037] Контрольный таймер (англ. watchdog timer букв, «сторожевой пес») - аппаратно реализованная схема контроля над зависанием системы. Представляет собой таймер, который периодически сбрасывается контролируемой системой. Если сброса не произошло в течение некоторого интервала времени, происходит принудительная перезагрузка системы. В некоторых случаях сторожевой таймер может посылать системе сигнал на перезагрузку («мягкая» перезагрузка), в других же - перезагрузка происходит аппаратно (замыканием сигнального провода RST или подобного ему).

[0038] Также возможна софтверная эмуляция данного решения, когда функции таймера, а также сброса (перезагрузки) системы выполняет внешняя система по отношению к контролируемой. В данном случае используется реализация системных таймеров и сигналов управления, внешние по отношению к исполняемому алгоритму.

[0039] Поисковая система(англ. Search engine) - это компьютерная система, предназначенная для поиска информации.

[0040] Диспетчер - модуль системы, отвечающий за управление процессами.

[0041] В данном изобретении реализован поисковый функционал, который более подробно ниже раскрыт.В качества примера использования для ясности понимания при прочтении используются предложения авиабилетов, однако любому специалисту в уровне техники очевидно, что могут быть использованы предложения ЖД билетов, автобусных билетов и так далее или в совокупности, в зависимости от системы бронирования.

[0042] Архитектура системы включает следующие компоненты (слои), как показано на Фиг. 1:

• Avia-Search-Gateway - слой 110 преобразования потока данных в пакет данных и форматов данных.

• Avia-User-Search - слой 120 формирования поисковой выдачи для конкретного пользователя;

• Avia-Smart-Search - слой 130 преобразования запросов пользователя в набор запросов к слою 140 для поиска лучших результатов по ассортименту;

• Avia-Gate-Search - слой 140, который отправляет поисковые запросы в поисковые шлюзы и обогащает результаты информацией, не зависящей от конкретного пользователя.

[0043] Концепция слоев - одна из общеупотребительных моделей, используемых разработчиками в вычислительной области техники для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем.

[0044] Слой n+1 использует слой n, следовательно, абстракция понятий слоя n+1 по меньшей мере не ниже, чем у слоя n, а если архитектура системы эффективна, то уровень абстракции слоя должен быть выше. Соответственно, слой n скрывает (инкапсулирует) логику работы с понятиями, определенными на этом слое, позволяя, таким образом, слою n+1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные средства нижележащего слоя. Можно выбирать альтернативную реализацию базовых слоев: компоненты верхнего слоя способны работать без каких-либо изменений в нижележащих слоях при условии сохранения интерфейсов. Зависимость между слоями, т.е. фактически интерфейсы, предоставляемые нижними слоями верхним, можно свести к минимуму. Такая минимизация интерфейсов позволяет увеличивать гибкость системы.

[0045] Слои способны удачно инкапсулировать многое, но не все: модификация одного слоя подчас связана с необходимостью внесения каскадных изменений в остальные слои. Наличие избыточных слоев нередко снижает производительность системы. При переходе от слоя к слою данные обычно подвергаются преобразованиям из одного представления в другое. Несмотря на это, инкапсуляция нижележащих функций зачастую позволяет достичь весьма существенного преимущества.

[0046] Каждый из слоев содержит один или более модулей. Модули, объединяются в слои по тому, с какими данными они работают.

[0047] Ни один верхний слой не меняет данные из нижних слоев, т.е. на слое 130 преобразования запросов пользователя не происходит изменений в поисковых предложениях (см. далее параграф 0086). В данном техническом решении осуществляют поиск в шлюзах, каждый из которых предоставляет доступ к одной или нескольким системам бронирования поисковых предложений в соответствии с заданным пользователем запросом. Шлюз может использовать XML-протокол (XML-шлюз, но не ограничиваясь, который позволяет формировать справочные запросы, получать ответы, а также использовать весь контент, например, АРС "Сирена-Трэвел" для бронирования и продажи авиаперевозок.

[0048] В некоторых вариантах реализации утвержден режим предоставления поисковых результатов на фронтенд - пакетный или поточный, и накладываемые ими ограничения. Пакетный режим подразумевает одномоментную отдачу данных от поисковой системы на фронтенд, но только в тот момент, когда будет обработано самое последнее предложение. Поточный режим позволяет отдавать каждое предложение сразу после обработки именно его, не дожидаясь остальных, но накладывает дополнительные требования на протокол передачи данных, плюс при поточном режиме невозможно использовать информацию о всей выдаче при обработке каждого конкретного предложения.

[0049] Запросом (для слоев 120 и 130 как будет раскрыто далее) является набор направлений, на которые пользователь хочет приобрести билеты, а также конфигурация пассажиров и классов обслуживания на каждое из этих направлений. Пользователь может таким образом формировать запрос в графическом интерфейсе пользователя веб-ресурса или посредством описания. Например, запросом может являться следующее: два направления «Москва - Спб» на 10 декабря, причем 1 взрослый и 1 ребенок в эконом классе, и «Спб - Москва» на 15 декабря, причем 1 взрослый и 1 ребенок в эконом классе. Поисковая система не ограничивает запросы одинаковой конфигурацией пассажиров и классов обслуживания. Конфигурация пассажиров и классов обслуживания в запросе указывается для каждого направления отдельно, в том числе в случае, если пользовательский интерфейс позволяет задать их один раз на все направления. Технически поисковый механизм, реализованный в системе, получает пользовательский запрос в виде запроса по сети, который затем преобразуется, например, в запрос во внутреннем формате, например, gRPC запрос) и передается между компонентами поискового механизма (иногда - «движка») или ядра другими словами. В других вариантах реализации вместо gRPC может использоваться связка технологий REST+JSON, но не ограничиваясь.

[0050] Затем полученный от пользователя запрос преобразуется посредством модуля преобразования запроса (в слое 130, как показано на Фиг. 1). Пользовательский запрос, состоящий из более чем одного направления с одинаковыми конфигурациями пассажиров и классов обслуживания, преобразуется в как минимум две группы поисковых запросов. В первой группе на каждое направление создается отдельный поисковый запрос. Во второй группе все направления комбинируются в атомарный поисковый запрос. Например, поиск "туда-обратно" (англ. roundtrip) Москва - Спб - Москва на 01.01.2020 и 07.01.2020 на одного взрослого пассажира в классе Эконом на оба направления будет преобразован в две группы поисковых запросов: в первой группе будут два отдельных запроса (англ. oneway) Москва - Спб и Спб - Москва, для каждого из которых будет указана конфигурация пассажиров и класс обслуживания; во второй группе будет один атомарный поиск Москва - Спб - Москва с единой конфигурацией пассажиров и классов обслуживания на все направления сразу. В некоторых реализациях более сложные пользовательские запросы могут быть трансформированы в большее число групп запросов. Полученные в рамках одной группы поисковых запросов Поисковые Предложения (см. п. 0086) затем комбинируются в Объединенные Предложения (см. п. 0084), в том числе и между различными Партнерскими Схемами.

[0051] Партнерская Схема представляет собой канал бронирования и продажи предложения. Например, одно и то же предложение может быть получено из разных систем бронирования (например, предложения Аэрофлота могут быть получены из систем бронирования Сейбр, Галилео, Сирена и т.п.). У этого предложения могут немного отличаться тарифы и таксы в разных системах бронирования, кроме того, отличаются агентские вознаграждения, которые получает веб-сервис данного изобретения. В конкретном варианте реализации рассчитывают цену для каждого такого варианта отдельно, и эти цены могут отличаться, причем в таком случае предлагают пользователю самое дешевое (хотя есть исключения). В других вариантах реализации конечная цена является одной и той же для разных каналов продажи. Кроме того, даже предложения из одной и той же системы бронирования могут оформлять через разные юридические лица, что тоже влияет на доходность и цену.

[0052] В некоторых вариантах реализации запрос пользователя может преобразовываться посредством стратегии поиска через хабы. Необходимо отметить, что предложения с пересадкой комбинируют и сами системы бронирования. В данном же техническом решении можно комбинировать предложения от разных систем бронирования, а также путем явного разбиения маршрута на составляющие на основе собственных знаний посылать дополнительные запросы в системы бронирования, чтобы получить больше вариантов. Например, пользователь ищет «Чебоксары - Майами». Ни одна система бронирования такого перелета не найдет, потому что из Чебоксар летают только локальные рейсы, которых нет в системах бронирования, в которых есть рейсы Москва - Майами. Однако в данном техническом решении известно, что можно отдельно поискать «Чебоксары - Москва» и отдельно «Москва - Майами», а затем скомбинировать предложения из разных систем бронирования.

[0053] В некоторых вариантах реализации осуществляют неточный поиск в конкретном варианте реализации посредством модуля преобразования запроса, например, поиск в страну и из страны, тематический поиск, поиск на плавающие даты и т.п. Пользователь делает запрос «Москва - Теплое море в январе», а в данном техническом решении определяют, что в январе море теплое в Юго-Восточной Азии и на Карибах, и соответственно сделает запросы в ГДС «Москва - Пхукет», «Москва - Гавана» и т.д. Нечеткий поиск - это поиск информации, при котором выполняется сопоставление информации заданному образцу поиска или близкому к этому образцу значению.

[0054] Дополнительно определяют тарифы посредством модуля определения тарифных правил (SegmentConditions) слоя 140, который обогащает результаты поиска, полученные из шлюзов, и информируют пользователя о доступных на каждом предложении тарифных опциях. В конкретном варианте реализации используют базу данных, наполняемую контент-отделом или автоматически посредством парсинга внешних систем,на основе текстов тарифных правил, описания тарифов на сайтах авиакомпаний, а также напрямую запросами в авиакомпании. В базе данных может содержаться структура из наиболее общего правила (например, "на всех рейсах Аэрофлота доступно одно место багажа") и исключений из него (например, "для тарифов Аэрофлота группы Лайт мест багажа нет") и исключений из исключений и т.д. В других вариантах реализации используют информацию, полученную в ответе от шлюза системы бронирования.

[0055] В некоторых вариантах реализации определяют и информируют пользователя об особенностях отдельных предложений (цена предложения, чартерный рейс, заказ раздельными билетами, технические посадки и т.п.).

[0056] В некоторых вариантах реализации, чартерный рейс это или нет определяется на слое 140. Например, из шлюза Sig23 приходят только чартеры, и чартеры приходят только из него.

[0057] Определение возможности заказа раздельными билетами может происходить на разных слоях системы. В некоторых вариантах реализации шлюзы уже направляют предложения с оформлением билетов - это уровень 140. В другом варианте реализации это определяется объединителем со слоя 130 при комбинации предложений в единое целое.

[0058] Определение технических посадок происходит в модуле определения промежуточных посадок (SegmentLegs, не показан на Фиг. ) слоя 140.

[0059] В конкретном варианте реализации цена предложения представляет собой сумму тарифа и такс (получаемые от ГДС), а также сервисного сбора. Для задания сервисного сбора используется отдельный модуль Pricing. Он может представлять собой модель, полученная методами машинного обучения(но не ограничиваясь). Модель строится на основе исторических данных о продажах и результатах поиска, которая генерирует множество конфигураций сервисных сборов, из которых потом выбирают оптимальную конфигурацию. Доходность определяется как сумма сервисного сбора и агентских вознаграждений, которые оплачивают авиакомпании и ГДС за продажу билета, минус расходы на платежный шлюз и минус партнерский сбор, который взимается партнерами за продажу билета через этого партнера. В зависимости от схемы продажи эти параметры могут быть как заданы непосредственно в программном коде заранее (например, процент платежного шлюза), так и рассчитываться на основе базы данных. В некоторых вариантах реализации в доходность закладывают ожидаемые расходы на поддержку пользователя (контакт-центр, каналы связи) и т.п., не ограничиваясь.

[0060] В данном изобретении время от получения запроса до формирования ответа бэкендом в 95% случаев не превышает времени ответа самого медленного из включенных шлюзов плюс 3 секунды (надбавочное время). Бэкенд (англ. back-end) - программно-аппаратная часть изобретения. Полное время на формирование первого предложения, которое можно отобразить пользователю в 95% случаев не превышает полутора секунд (в данном случае именно полное, а не добавочное, но здесь это практически одно и то же, поскольку ответы шлюзов кэшируются).

[0061] При увеличении ассортимента, приходящего из какого-либо из шлюзов систем бронирования, либо добавлении нового шлюза, либо увеличении и усложнении комбинированных предложений, надбавочное время остается в пределах 3 секунд, либо возвращается в эти пределы путем горизонтального масштабирования вычислительных мощностей, что позволяет достичь технического результата данного изобретения, повышения скорости получения пользователем поисковых предложений. Надбавочное время представляет собой полное время получения предложения пользователем минус время на обращение и ожидание ответа от шлюза системы бронирования.. Смысл этого требования в том, чтобы в большинстве случаев при увеличении объема проходящих через поисковую систему данных, можно было сохранять надбавочное время в пределах, например, 3 секунд не путем модифицирования алгоритмов, переписывания программного кода системы, а путем выделения большего объема ресурсов (ОЗУ, процессорное время) и/или создания большего количества копий компонентов поисковой системы.

[0062] В некоторых вариантах реализации осуществляют поиск по кэшу вместо поиска по шлюзу. Заранее если получают какое-либо предложение из шлюза, то сохраняют его в кэш, например, на полчаса (время настраивается отдельно для каждого шлюза). Соответственно, если в течение получаса кто-то из пользователей сделает аналогичный запрос, то в данном решении не обращаются в шлюз, а загружают из кэша сохраненное предложение. Уточнение того, что кэш актуален, будет произведено уже для конкретного предложения, которое пользователь выберет для покупки.

[0063] Дополнительно учтена в архитектуре системы возможность предоставления API другим продуктам, в том числе и сторонним, с учетом кастомизации предоставляемого функционала.

[0064] Под обогащенными результатами в данном изобретении подразумеваются данные, относящиеся непосредственно к предложению. Помимо базовой информации, которую сообщает шлюз системы бронирования, это:

i. тарифные опции,

ii. информация о промежуточных посадках (в авиационной терминологии отличаются пересадки, когда меняется номер рейса, и промежуточные посадки, когда он не меняется, хотя с точки зрения пользователя они выглядят одинаково - в большинстве случаев ему нужно выйти из самолета. В данном решении промежуточные посадки отображаются как дозаправки, причем иногда это действительно дозаправки самолета);

iii. элементы доходности за продажу предложения.

iv. иные опции

[0065] С другой стороны, информация зависящая от пользователя, это:

- персонифицированная рекомендация того или иного предложения;

- способ сортировки и группировки предложений.

[0066] Предварительно приходит запрос из слоя 130 преобразования запросов пользователя (например, запрос от пользователя «Москва-Спб-Москва» на конкретные даты) и попадает в диспетчер 210, как показано на Фиг. 2, который знает, что существует много шлюзов 230 и рассылает по ним поисковый запрос. Запрос приходит от пользовательского фронтенда, который представляет собой запрос по сети с датами, направлениями, конфигурациями пассажиров и сервисными классами. AviaGateway без изменения сути преобразует его в запрос во внутреннем формате (например gRPC), слой 120 формирования поисковой выдачи для конкретного пользователя прокидывает дальше в слой 130 преобразования запросов пользователя. А вот слой 130 преобразования запросов пользователя один пользовательский запрос преобразует в множество запросов слоя 140, который отправляет поисковые запросы в поисковые шлюзы, каждый из которых потом будет передан каждому шлюзу.

[0067] Слой 140 направления поисковых запросов в поисковые шлюзы выполняет конкретные поисковые запросы в модули взаимодействия с конкретными шлюзами 230 (модуль взаимодействия с системой Galileo, модуль взаимодействия с системой Sabre и т.д.), которые расположены на этом слое, как показано на Фиг. 2. В общем случае поисковый запрос это сетевой запрос (запрос на основе HTTP, например, SOAP или RPC или XML запрос). Формат поискового запроса у каждого шлюза 230 свой. Например, IATA развивает протокол NDC, рекомендуемый для взаимодействия с шлюзами 230 систем бронирования. В одном из вариантов реализации протокол NDC используется для взаимодействия со шлюзами 230 бронирования отдельных авиакомпаний. В запросе всегда есть набор направлений и дат, на которые пользователь хочет найти билет, конфигурация пассажиров и сервисный класс. По крайней мере, некоторые шлюзы 230 требуют единую конфигурацию пассажиров и сервисный класс на все перелеты, тогда как поисковый запрос данного изобретения этого ограничения не содержит (однако, запрос к слою 140 направления поисковых запросов в поисковые шлюзы может содержать это ограничение), и если клиент хочет разную конфигурацию пассажиров на разные перелеты, то внутренними преобразованиями его запрос разбивается на несколько запросов к шлюзам 230.

[0068] Кроме того, запрос к шлюзу 230 содержит информацию о пользователе шлюза 230 (данные для аутентификации и авторизации пользователя шлюза), а также рекомендации шлюза 230 по тому, какие предложения выбирать. Например, можно сделать запрос к шлюзу 230 поискать не любые перелеты по маршруту «Москва - Спб», но только без пересадок, или только Аэрофлота. В ряде случаев это позволяет несколькими запросами получить больший ассортимент. Правила указания таких параметров содержатся в базе данных.

[0069] Например, если из шлюзов 230 не приходит информация какой клиенту доступен багаж по предложению, данная информация определяется в модуле 260 определения тарифных правил (англ. SegmentConditions), основанный на базе данных, которая выше упоминалась. Если более развернуто, то у каждого предложения есть ряд свойств: аэропорты вылета и прилета, дата и время вылета и прилета, авиакомпания, выполняющая рейс (чей самолет), авиакомпания, назначающая тариф (не деньги, а именно условия перевозки, закодированные авиакомпанией каким-либо идентификатором - кодом тарифа) и т.д. База данных содержит базовые правила (в основном базовое правило зависит от авиакомпании, назначающей тариф, и кода тарифа), и исключения из этих правил.

[0070] Диспетчер 210 слоя 140 направления поисковых запросов в поисковые шлюзы копирует полученные запросы по представителям шлюза 230 (англ. GateRepresent на Фиг. 2) как показано на Фиг. 2. На каждый модуль взаимодействия со шлюзом есть свой представитель шлюза 230. Например, на модуль взаимодействия с Sabre есть представитель Sabre. Представителем шлюза 230 является модуль, который знает об особенностях конкретного шлюза 240 и соответственно решает, имеет ли смысл туда посылать запрос. Например, если пользователь хочет найти билеты в какой-нибудь маленький аэропорт, у которого нет IATA-кода, а есть только ГСГА-код, то бесполезно посылать запрос в Sabre - он не умеет работать с ГСГА-кодами. В некоторых вариантах реализации диспетчер 210 занимается созданием выходной очереди. Диспетчер 210 генерирует уникальное имя выходной очереди на основе алгоритмов, предоставляемых средой разработки. Затем он посылает в шину данных 150 (англ. Data Bus) (например, RabbitMQ) команду на создание очереди с таким именем), а затем сообщает представителям шлюза 230, что писать результаты нужно в эту очередь (точнее имя очереди через запросы прокидывается до конвейера обработки данных 710, который уже будет писать в очередь), а также сообщает на слой 130 преобразования запросов пользователя модулю чтения из очереди 330, показанному на Фиг. 3, что читать нужно из этой очереди.

[0071] Диспетчер 210 слоя 140 направления поисковых запросов в поисковые шлюзы может создавать очередь в некоторых вариантах реализации в шине данных 150 (например, RabbitMQ) (RabbitMQ - программный брокер сообщений на основе стандарта AMQP- тиражируемое связующее программное обеспечение, ориентированное на обработку сообщений), в которую будет попадать ответ, и сообщает ее имя слою 130 преобразования запросов пользователя. Также диспетчер 210 может использовать, например, брокер сообщений Nats, не ограничиваясь. Модуль представителя шлюза 230 решает, будет ли шлюз 240 выполнять запрос и сколько всего необходимо запросов (поисковые схемы), сообщает наверх диспетчеру 210 сколько поисков запущено. Диспетчер 210 в свою очередь суммирует эти числа, получает таким образом общее число ожидаемых ответов и сообщает их через модуль направления поисковых ответов 250 наверх модулю чтения из очереди 330 слоя 130 преобразования запросов пользователя. Выше приведен пример с ГСГА-кодами, где модуль 230 решает посылать в шлюз 240 запрос или нет. Это либо технические особенности работы шлюза 240, либо в техническом решении решается, что те или иные запросы посылать в конкретный шлюз 240 не имеет смысла (ассортимент скудный, предложения дороже и т.д.) и описываются эти правила во внутренней базе данных. Модуль взаимодействия со шлюзом формируют запрос к API соответствующего шлюза 240 и отправляют его, после чего получают ответ и преобразуют его в формат GateOffer, причем в некоторых вариантах проверяет наличие ответа в кэше.

[0072] Во всей архитектуре изобретения во всех модулях осуществляется поточная обработка данных. Каждое предложение обрабатывается как только появились все данные, необходимые для этой обработки. Как показано выше на примере из описания стратегии поиска через хабы: чтобы получить предложение по маршруту «Чебоксары - Майами», необходимо хотя бы по одному предложению по каждому из маршрутов «Чебоксары - Москва» и «Москва - Майами». В данном случае гарантируется обработка зависимых друг от друга данных одним и тем же процессом. Гарантия достигается за счет того, что после трансформации пользовательского запроса в набор групп запросов к слою 140 направления поисковых запросов в поисковые шлюзы существует диспетчер 210, который назначает задание на комбинацию предложений из конкретной группы конкретному экземпляру модуля объединителя 310, как показано на Фиг. 3. Зависимыми данными являются предложения по каждой из частей перелета, необходимые для составления скомбинированного предложения.

[0073] Также модуль чтения из очереди 330 определяет состояние обработки и принимает решения о прекращении обработки посредством опроса состояний (каждый сервис, который ожидает каких-то данных не знает о состоянии нижележащих процессов, но может принять решение о завершении ожидания с помощью описанных далее методов), заранее оговоренного количества сообщений (например, от 0 до 15, не ограничиваясь), заранее оговоренного времени приема сообщений, терминирующих сообщений. Каждый модуль работает с одним конкретным способом, конкретно модуль чтения из очереди 330 знает ожидаемое количество сообщений. Терминирующее сообщение представляет собой сообщение, которое содержит не данные, а информацию о том, что больше данных не будет, например, строку «finish». Может возникнуть проблема, что терминирующее сообщение придет в принимающий модуль не последним, несмотря на то, что было отправлено последним. Это решается указанием в терминирующем сообщении количества сообщений с данными, например, сообщение finish:45 означает, что нужно обработать 45 сообщений с данными.

[0074] При поточной обработке данных, как показано на Фиг. 3, модуль скоринга 740 (показан на Фиг. 6 и 7) одинаковых с точки зрения пользователя предложений слоя 120 формирования поисковой выдачи для конкретного пользователя осуществляет скоринг предложений и принимает решения о целесообразности дальнейшей обработки в различных вариантах реализации:

• на уровне создания предложений;

• на уровне обработки предложений.

[0075] Целью скоринга является выбор из набора одинаковых с точки зрения пользователя предложений для показа.

[0076] Диспетчер 340 слоя 130 преобразования запросов пользователя оптимизирует количество запросов к слою 140 направления поисковых запросов в поисковые шлюзы, после чего создает мультиплексер 320 (англ. Multiplexer) результатов, запускает механизм транспортировки запросов и данных между слоями, а именно передает запрос модулю транспортировки запросов и данных 350 между слоем 140 направления поисковых запросов в поисковые шлюзы и слоем 130 преобразования запросов пользователя, создает входную очередь в шине данных 150 (например, RabbitMQ). Данный механизм нужен для того, чтобы была возможность физически разделить инсталляции шины данных 150 (например, RabbitMQ) в соответствии со слоями. Мультиплексер 320 представляет собой способ организации транспорта данных, ставящий своей целью получение копий одного и того же набора данных несколькими получателями.

[0077] Модуль транспортировки запросов и данных 350 передает запрос на слой 140 направления поисковых запросов в поисковые шлюзы, получает имя выходной очереди (представляет собой уникальную строку. Выше описано как диспетчер 210 слоя 140 направления поисковых запросов в поисковые шлюзы создает ее и передает), слушает ее и перекладывает ответы в мультиплексер 320, а также выполняет роль контрольного таймера (англ. watchdog). Контрольный таймер фиксирует заранее оговоренное время приема сообщений (например, 15 секунд). По истечении времени ожидание завершается.

[0078] Мультиплексер 320 дублирует каждое предложение в каждый модуль объединения 310, указанный при создании мультиплексера 320.

[0079] Модуль объединения 310 аккумулирует результаты по всем отдельным поискам, входящим в группу, при этом еще и исполняет функцию контрольного таймера. Группа представляет собой набор поисковых запросов к слою 140 направления поисковых запросов в поисковые шлюзы, в который был преобразован пользовательский запрос. Как только в каждом отдельном поиске из группы есть хотя бы одно предложение, данный модуль 310 формирует SmartOffer и SmartVariant. Также данный компонент ведет статистику сформированных SmartOffer'ов и принимает решение о передачи каждого из них на уровень AviaUserSearch, отправляет SmartOffer'ы в шину данных 150, как показано на Фиг. 5. Данное решение принимается для того, чтобы не передавать слишком много информации, а это в свою очередь, чтобы не усложнять выбор пользователя и убрать лишнюю нагрузку на вычислительные и транспортные мощности. Например, существует поиск «туда-обратно». Туда 100 предложений, обратно 100. Если комбинировать и отдавать пользователю все со всем, получится 10000, что повышает сильно вычислительную нагрузку.

[0080] Объединенное Предложение (или SmartOffer) - объединенный набор поисковых предложений из разных ответов, полученных на запросы к слою 140 направления поисковых запросов в поисковые шлюзы, и соответствующий набор объединенных вариантов. Например, если мы искали RT (англ. RoundTrip - поиск туда-обратно), то это может быть атомарный ответ, либо же объединение двух OW. (англ. Oneway - поиск в одну сторону).

[0081] Объединенный Вариант (или SmartVariant) - комбинация различных поисковых вариантов (OfferVariant) из разных поисковых предложений (SearchOffer) в рамках одного объединенного предложения.

[0082] Поисковое предложение (или SearchOffer) представляет из себя конкретную комбинацию рейсов по поисковому запросу (например полученная по атомарному поиску Москва - СПб - Москва на 01.01.2020 в СПб и 07.01.2020 обратно комбинация рейсов SU025 и SU026 в соответствующие даты) и набор вариантов тарифов, по которым может быть оформлена эта комбинация. Каждый такой вариант называется поисковым вариантом (или Search Variant). Поисковый вариант состоит из указания кода тарифа для каждого рейса в поисковом предложении, информацию о доступных тарифных опциях (багаж, возможность обмена и возврата, но не ограничиваясь ими), а также доступные варианты оформления (из какой системы бронирования получен вариант и каким юридическим лицом может быть оформлен) и соответствующие вариантам оформления тарифы и таксы

[0083] Предварительно слой 120 формирования поисковой выдачи для конкретного пользователя передает запрос пользователя в неизменном виде на слой 130 преобразования запросов пользователя без преобразований, но при этом создает необходимую транспортную инфраструктуру для обработки результатов. Затем принимает данные (предложения в формате SmartOffer) со слоя 130 преобразования запросов пользователя и производит обработки, зависящие от конкретного пользователя (ценообразование и а/б компании, маркетинговые акции и т.п.).

[0084] Диспетчер 210 слоя 120 формирования поисковой выдачи для конкретного пользователя запускает конвейер обработки данных 710 на прослушивание конкретной очереди, передает запрос слою 130 преобразования запросов пользователя, получает имена очередей, в которые поступит ответ, и сообщает их SmartSearchAdapter'y, чтобы тот слушал очереди и перекладывал сообщения в шину данных 150 (RabbitMQ) слоя 120 формирования поисковой выдачи для конкретного пользователя.

[0085] Далее модуль SmartSearchAdapter получает имя выходной очереди, слушает ее, перекладывает в шину данных 150, причем данный модуль служит контрольным таймером (англ. watchdog).

[0086] Конвейер обработки данных 710 передает результаты предложения со слоя 130 преобразования запросов пользователя в модуль вычисления цены 720, как показано на Фиг. 6, который рассчитывает конечную цену предложения, затем рассчитывает скоринг с помощью модуля скоринга 740 одинаковых с точки зрения пользователя предложений и проводит фильтрации, зависящие от конкретного пользователя. Под скорингом в данном техническом решении понимается механизм, позволяющий управлять показом одинаковых с точки зрения пользователя предложений в поточном режиме путем присваивания предложениям некоторого рейтинга. Абсолютное значение рейтинга в данном случае не имеет значения, играют роль лишь их отношения сравнения. Например, если на выдачу ушло предложение за 2000 рублей с рейтингом 1, а затем было получено и обработано аналогичное предложение за 1990 рублей, то ему можно поставить рейтинг 2, чтобы у фронтенда был простой критерий для того, чтобы скрыть предложение за 2000 и вместо него показать предложение за 1990 рублей. Под фильтрацией понимается недопущение на выдачу предложений, недоступных конкретному пользователю. Например, существует акция одной из авиакомпаний, где обязательным условием является то, что пользователь вошел на сайт под своим логином, а незалогиненным предложения по акции не показывались. В некоторых вариантах реализации может быть реализована фильтрация низкоконверсионных предложений на больших выдачах с целью упрощения процесса выбора пользователем подходящего ему предложения. В некоторых вариантах реализации осуществляют валидацию предложений (например, маркетинговые акции) посредством валидатора 730.

[0087] Модуль скоринга 740 оценивает "одинаковые" предложения, когда совпадает SearchOffer и SearchVariant. Т.е. одинаковыми считаются предложения, у которых одинаковый набор сегментов (например, конкретный рейс) и тарифных опций. Сегменты сравниваются по параметрам перелета, маркетинговому перевозчику и номеру рейса. Оперирующий перевозчик - авиакомпания, которой принадлежит самолет, выполняющий рейс. Маркетинговый перевозчик - авиакомпания, устанавливающая условия перевозки для конкретного пассажира и назначающая номер рейса. Например, если пользователь летит самолетом Аэрофлота, Аэрофлот - оперирующий перевозчик. Условия перевозки ему назначил Аэрофлот, и поставил номер рейса SU292. Для рейса SU292 Аэрофлот - маркетинговый перевозчик. Но на соседнем кресле летит человек, которому условия перевозки назначили Вьетнамские Авиалинии и номер рейса для него VN555. По рейсу VN555 маркетинговый перевозчик - Вьетнамские Авиалинии, хотя оперирующий по прежнему Аэрофлот.

[0088] При проходе через конвейер обработки данных 710, осуществляется группировка по хэшу, где рассматриваются совокупности предложений, имеющих одинаковый хэш.

[0089] Ниже приведен конкретный пример реализации данного изобретения.

[0090] Пользователь хочет поискать билеты на рейс Москва - Спб - Москва на одного взрослого человека на 01.01.2020 и 07.01.2020 в классе Эконом. Он вводит эти параметры в форме поиска, которая передает их слою 110 преобразования потока данных в пакет данных и форматов данных в формате, где для каждого направления (Москва - СПб и СПб - Москва) продублирована конфигурация пассажиров и выбранный класс обслуживания (один взрослый в классе Эконом)

[0091] Слой 110 преобразования потока данных в пакет данных и форматов данных инициирует обмен данными с модулем диспетчер 210 слоя 120 формирования поисковой выдачи для конкретного пользователя по внутреннему протоколу (например gRPC) в режиме получения потока от сервера. То есть клиент (слой 110 преобразования потока данных в пакет данных и форматов данных) посылает серверу (диспетчеру 210) один запрос, а в ответ ожидает последовательно приходящие предложения. Запрос при этом не трансформируется.

[0092] Модуль Диспетчер 210 слоя 120 формирования поисковой выдачи для конкретного пользователя создает одну очередь в RabbitMQ, в которую будут поступать готовые к показу предложения. Затем он создает одну очередь, которая будет использоваться для транспортировки данных, полученных со слоя 130 преобразования запросов пользователя, в конвейер обработки 710 слоя 120 формирования поисковой выдачи для конкретного пользователя. Затем диспетчер 210 отсылает пользовательский запрос в неизменном виде модулю преобразователя слоя 130 преобразования запросов пользователя и получает от него имя очереди, в которую слой 130 преобразования запросов пользователя будет передавать результаты своей работы. После чего диспетчер отправляет полученное имя очереди модулю взаимодействия со слоем 130 преобразования запросов пользователя, который ожидает поступления объединенных предложений в эту очередь и служит контрольным таймером (см. Фиг. 6)

[0093] Модуль преобразования запросов из полученного запроса формирует две группы запросов. Первая содержит два отдельных поисковых запроса (Москва - Спб и Спб - Москва), вторая содержит объединенный атомарный запрос (Москва - Спб - Москва). Эти группы передаются диспетчеру 340 слоя 130 преобразования запросов пользователя, который создает три мультиплексера 320 по числу уникальных поисков в созданных группах, запускает два модуля объединения предложений 310 по числу групп, устанавливает соответствие уникальных поисков, мультиплексеров 320 и модулей объединения 310 путем создания очередей в RabbitMQ. Затем диспетчер 340 передает каждый уникальный поиск в виде запроса модулю взаимодействия со слоем 140 направления поисковых запросов в поисковые шлюзы. Дальнейшая обработка каждого из уникальных поисков происходит параллельно (см. Фиг. 3)

[0094] Модуль взаимодействия со слоем 140 направления поисковых запросов в поисковые шлюзы передает полученные запросы на слой 140 направления поисковых запросов в поисковые шлюзы, получает от него имя очереди, из который можно будет получить поисковые предложения, и ожидаемое количество сообщений и запускает процесс ожидания сообщений. При этом данный модуль служит контрольным таймером, (см. Фиг. 3)

[0095] Диспетчер 210 слоя 140 направления поисковых запросов в поисковые шлюзы создает выходную очередь в RabbitMQ, затем сообщает параметры запроса заранее известному набору представителей шлюзов 230. Каждый из них определяет, сколько поисковых запросов будет запущено соответствующим модулем взаимодействия со шлюзом, сообщает это число диспетчеру 210 и передает поисковый запрос соответствующему модулю взаимодействия со шлюзом 240. Диспетчер 210, получив и просуммировав ответы от всех представителей 230, сообщает имя выходной очереди и общее ожидаемое количество сообщений модулю взаимодействия со слоем 140 направления поисковых запросов в поисковые шлюзы слоя 130 преобразования запросов пользователя, (см. Фиг. 2)

[0096] Каждый из модулей взаимодействия со шлюзом, получивший поисковый запрос, независимо и параллельно преобразует его в формат шлюза, выполняет его, получает ответ, преобразует его в формат поискового предложения SearchOffer и передает полученные поисковые предложения посредством RabbitMQ модулю обогащения поисковых предложений данными, (см. Фиг. 2)

[0097] Модуль обогащения поисковых предложений 270 данными посредством обращения к соответствующим базам данных добавляет в предложения информацию о доступном к провозу багаже, возможности обмена или возврата, промежуточных посадках, элементах доходности и т.д. Сообщение, состоящее из обогащенных таким образом предложений, полученных в результате одного поискового запроса к одному шлюзу 240 системы бронирования, посредством RabbitMQ передается на слой 130 преобразования запросов пользователя. Предложения, полученные из разных шлюзов 240 по разным поисковым запросам, модулем обогащения обрабатываются независимо и параллельно (см. Фиг. 2)

[0098] Модуль взаимодействия со слоем 140 направления поисковых запросов в поисковые шлюзы получает сообщения, содержащие поисковые предложения и посредством RabbitMQ передает их соответствующему мультиплексеру 320. Мультиплексер 320 копирует сообщение для каждого из соответствующих модулей объединения 310 (см. Фиг. 5)

[0099] Модуль объединения 310, получив хотя бы по одному поисковому предложению по каждому из поисковых запросов, входящих в группу (например, в случае поиска предложений "туда-обратно" раздельными запросами - хотя бы по одному поисковому предложению для каждого из двух поисков "в одну сторону"), начинает их комбинацию в объединенные предложения (SmartOffer) и объединенные варианты (SmartVariant). Каждое полученное объединенное предложение посредством RabbitMQ независимо и параллельно отправляется на слой 120 формирования поисковой выдачи для конкретного пользователя (см. Фиг. 5)

[00100] Модуль взаимодействия со слоем 130 преобразования запросов пользователя слоя 120 формирования поисковой выдачи для конкретного пользователя получает объединенные предложения и посредством RabbitMQ передает их конвейеру обработки предложений 710 слоя 120 формирования поисковой выдачи для конкретного пользователя (см. Фиг. 7)

[00101] Конвейер обработки предложений 710 фильтрует предложения, недоступные для конкретного пользователя, определяет цену предложения для каждого предложения и вычисляет для каждого предложения скоринг. В результате формируется предложение, готовое к показу пользователю, которое передается на слой 110 преобразования потока данных в пакет данных и форматов данных (см. Фиг. 7)

[00102] В некоторых вариантах реализации на слое 110 преобразования потока данных в пакет данных и форматов данных производится преобразование потока данных в пакет, после чего данные предоставляют фронтенду для показа пользователю.

[00103] Ссылаясь на Фиг. 4, данное изобретение может быть реализовано в виде вычислительной системы 400 осуществления умного поиска авиабилетов, которая содержит один или более из следующих компонентов:

• компонент 401 обработки, содержащий по меньшей мере один процессор 402,

• память 403,

• компонент 405 мультимедиа,

• компонент 406 аудио,

• интерфейс 407 ввода / вывода (I / О),

• сенсорный компонент 408,

• компонент 409 передачи данных.

[00104] Компонент 401 обработки в основном управляет всеми операциями системы 400, например, осуществляет обработку данных о пользователе или его запросе на поиск авиабилетов, а также управляет дисплеем, телефонным звонком, передачей данных, работой камеры и операцией записи мобильного устройства связи. Компонент 401 обработки может включать в себя один или более процессоров 402, реализующих инструкции для завершения всех или части шагов из указанных выше способов. Кроме того, компонент 401 обработки может включать в себя один или более модулей для удобного процесса взаимодействия между другими модулями 401 обработки и другими модулями. Например, компонент 401 обработки может включать в себя мультимедийный модуль для удобного облегченного взаимодействия между компонентом 405 мультимедиа и компонентом 401 обработки.

[00105] Память 403 выполнена с возможностью хранения различных типов данных для поддержки работы системы 400, например, базу данных с профилями пользователей. Примеры таких данных включают в себя инструкции из любого приложения или способа, контактные данные, данные адресной книги, сообщения, изображения, видео, и т.д., и все они работают на системе 400. Память 403 может быть реализована в виде любого типа энергозависимого запоминающего устройства, энергонезависимого запоминающего устройства или их комбинации, например, статического оперативного запоминающего устройства (СОЗУ), Электрически-Стираемого Программируемого постоянного запоминающего устройства (ЭСППЗУ), Стираемого Программируемого постоянного запоминающего устройства (СППЗУ), Программируемого постоянного запоминающего устройства (ППЗУ), постоянного запоминающего устройства (ПЗУ), магнитной памяти, флэш-памяти, магнитного диска или оптического диска и другого, не ограничиваясь.

[00106] Компонент 405 мультимедиа включает в себя экран, обеспечивающий выходной интерфейс между системой 400, которая может быть установлена на мобильном устройстве связи пользователя и пользователем. В некоторых вариантах реализации, экран может быть жидкокристаллическим дисплеем (ЖКД) или сенсорной панелью (СП). Если экран включает в себя сенсорную панель, экран может быть реализован в виде сенсорного экрана для приема входного сигнала от пользователя. Сенсорная панель включает один или более сенсорных датчиков в смысле жестов, прикосновения и скольжения по сенсорной панели. Сенсорный датчик может не только чувствовать границу прикосновения субъекта или жест перелистывания, но и определять длительность времени и давления, связанных с режимом работы на прикосновение и скольжение. В некоторых вариантах осуществления компонент 405 мультимедиа включает одну фронтальную камеру и/или одну заднюю камеру. Когда система 400 находится в режиме работы, например, режиме съемки или режиме видео, фронтальная камера и/или задняя камера могут получать данные мультимедиа извне. Каждая фронтальная камера и задняя камера может быть одной фиксированной оптической системой объектива или может иметь фокусное расстояние или оптический зум.

[00107] Компонент 406 аудио выполнен с возможностью выходного и/или входного аудио сигнала. Например, компонент 406 аудио включает один микрофон (MIC), который выполнен с возможностью получать внешний аудио сигнал, когда система 400 находится в режиме работы, например, режиме вызова, режима записи и режима распознавания речи. Полученный аудио сигнал может быть далее сохранен в памяти 403 или направлен по компоненту 409 передачи данных. В некоторых вариантах осуществления компонент 406 аудио также включает в себя один динамик выполненный с возможностью вывода аудио сигнала.

[00108] Интерфейс 407 ввода / вывода (I / О) обеспечивает интерфейс между компонентом 401 обработки и любым периферийным интерфейсным модулем. Вышеуказанным периферийным интерфейсным модулем может быть клавиатура, руль, кнопка, и т.д. Эти кнопки могут включать, но не ограничиваясь, кнопку запуска, кнопку регулировки громкости, начальную кнопку и кнопку блокировки.

[00109] Сенсорный компонент 408 содержит один или более сенсоров и выполнен с возможностью обеспечения различных аспектов оценки состояния системы 400. Например, сенсорный компонент 408 может обнаружить состояния вкл/выкл системы 400, относительное расположение компонентов, например, дисплея и кнопочной панели, одного компонента системы 400, наличие или отсутствие контакта между субъектом и системой 400, а также ориентацию или ускорение/замедление и изменение температуры системы 400. Сенсорный компонент 408 содержит бесконтактный датчик, выполненный с возможностью обнаружения присутствия объекта, находящегося поблизости, когда нет физического контакта. Сенсорный компонент 408 содержит оптический датчик (например, КМОП или ПЗС-датчик изображения) выполненный с возможностью использования в визуализации приложения. В некоторых вариантах сенсорный компонент 408 содержит датчик ускорения, датчик гироскопа, магнитный датчик, датчик давления или датчик температуры.

[00110] Компонент 409 передачи данных выполнен с возможностью облегчения проводной или беспроводной связи между системой 400 и другими устройствами. Система 400 может получить доступ к беспроводной сети на основе стандарта связи, таких как WiFi, 2G, 3G, 5G, или их комбинации. В одном примерном варианте компонент 409 передачи данных получает широковещательный сигнал или трансляцию, связанную с ними информацию из внешней широковещательной системы управления через широковещательный канал. В одном варианте осуществления компонент 409 передачи данных содержит модуль коммуникации ближнего поля (NFC), чтобы облегчить ближнюю связь. Например, модуль NFC может быть основан на технологии радиочастотной идентификации (RFID), технологии ассоциации передачи данных в инфракрасном диапазоне (IrDA), сверхширокополосных (UWB) технологии, Bluetooth (ВТ) технологии и других технологиях.

[00111] В примерном варианте осуществления система 400 может быть реализована посредством одной или более Специализированных Интегральных Схем (СИС), Цифрового Сигнального Процессора (ЦСП), Устройств Цифровой Обработки Сигнала (УЦОС), Программируемым Логическим Устройством (ПЛУ), логической микросхемой, программируемой в условиях эксплуатации (ППВМ), контроллера, микроконтроллера, микропроцессора или других электронных компонентов, и может быть сконфигурирован для реализации способа 500 осуществления умного поиска авиабилетов.

[00112] В примерном варианте осуществления энергонезависимый машиночитаемый носитель содержит память 403, которая включает инструкции, где инструкции выполняются процессором 401 системы 400 для реализации описанных выше способов осуществления умного поиска авиабилетов. Например, энергонезависимым машиночитаемым носителем может быть ПЗУ, оперативное запоминающее устройство (ОЗУ), компакт-диск, магнитная лента, дискеты, оптические устройства хранения данных и тому подобное.

[00113] Вычислительная система 400 может включать в себя интерфейс дисплея, который передает графику, текст и другие данные из коммуникационной инфраструктуры (или из буфера кадра, не показан) для отображения на компоненте 405 мультимедиа. Вычислительная система 400 дополнительно включает в себя устройства ввода или периферийные устройства. Периферийные устройства могут включать в себя одно или несколько устройств для взаимодействия с мобильным устройством связи пользователя, такие как клавиатура, микрофон, носимое устройство, камера, один или более звуковых динамиков и другие датчики. Периферийные устройства могут быть внешними или внутренними по отношению к мобильному устройству связи пользователя. Сенсорный экран может отображать, как правило, графику и текст, а также предоставляет пользовательский интерфейс (например, но не ограничиваясь ими, графический пользовательский интерфейс (GUI)), через который субъект может взаимодействовать с мобильным устройством связи пользователя, например, получать доступ и взаимодействовать с приложениями, запущенными на устройстве.

[00114] Элементы заявляемого изобретения находятся в функциональной взаимосвязи, а их совместное использование приводит к созданию нового и уникального изобретения. Таким образом, все блоки функционально связаны.

[00115] Все блоки, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем, что очевидно для специалиста в данном уровне техники. Не ограничиваюсь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задается посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др. Альтернативой ПЛИС могут быть программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC - специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже.

[00116] Обычно, сама микросхема ПЛИС состоит из следующих компонент:

• конфигурируемых логических блоков, реализующих требуемую логическую функцию;

• программируемых электронных связей между конфигурируемыми логическими блоками;

• программируемых блоков ввода/вывода, обеспечивающих связь внешнего вывода микросхемы с внутренней логикой.

[00117] Также блоки могут быть реализованы с помощью постоянных запоминающих устройств.

[00118] Таким образом, реализация всех используемых блоков достигается стандартными средствами, базирующимися на классических принципах реализации основ вычислительной техники.

[00119] Как будет понятно специалисту в данной области техники, аспекты настоящего изобретения могут быть выполнены в виде системы, способа или компьютерного программного продукта. Соответственно, различные аспекты настоящего изобретения могут быть реализованы исключительно как аппаратное обеспечение, как программное обеспечение (включая прикладное программное обеспечение и так далее) или как вариант осуществления, сочетающий в себе программные и аппаратные аспекты, которые в общем случае могут упоминаться как «модуль», «система» или «архитектура». Кроме того, аспекты настоящего изобретения могут принимать форму компьютерного программного продукта, реализованного на одном или нескольких машиночитаемых носителях, имеющих машиночитаемый программный код, который на них реализован.

[00120] Также может быть использована любая комбинация одного или нескольких машиночитаемых носителей. Машиночитаемый носитель хранилища может представлять собой, без ограничений, электронную, магнитную, оптическую, электромагнитную, инфракрасную или полупроводниковую систему, аппарат, устройство или любую подходящую их комбинацию. Конкретнее, примеры (неисчерпывающий список) машиночитаемого носителя хранилища включают в себя: электрическое соединение с помощью одного или нескольких проводов, портативную компьютерную дискету; жесткий диск, оперативную память (ОЗУ), постоянную память (ПЗУ), стираемую программируемую постоянную память (EPROM или Flash-память), оптоволоконное соединение, постоянную память на компакт-диске (CD-ROM), оптическое устройство хранения, магнитное устройство хранения или любую комбинацию вышеперечисленного. В контексте настоящего описания, машиночитаемый носитель хранилища может представлять собой любой гибкий носитель данных, который может содержать или хранить программу для использования самой системой, устройством, аппаратом или в соединении с ними.

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

[00122] Компьютерный программный код для выполнения операций для шагов настоящего изобретения может быть написан на любом языке программирования или комбинаций языков программирования, включая объектно-ориентированный язык программирования, например Python, R, Java, Smalltalk, С++ и так далее, и обычные процедурные языки программирования, например язык программирования «С» или аналогичные языки программирования. Программный код может выполняться на компьютере пользователя полностью, частично, или же как отдельный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере, или же полностью на удаленном компьютере. В последнем случае, удаленный компьютер может быть соединен с компьютером пользователя через сеть любого типа, включая локальную сеть (LAN), глобальную сеть (WAN) или соединение с внешним компьютером (например, через Интернет с помощью Интернет-провайдеров).

[00123] Аспекты настоящего изобретения были описаны подробно со ссылкой на блок-схемы, принципиальные схемы и/или диаграммы способов, устройств (систем) и компьютерных программных продуктов в соответствии с вариантами осуществления настоящего изобретения. Следует иметь в виду, что каждый блок из блок-схемы и/или диаграмм, а также комбинации блоков из блок-схемы и/или диаграмм, могут быть реализованы компьютерными программными инструкциями. Эти компьютерные программные инструкции могут быть предоставлены процессору компьютера общего назначения, компьютера специального назначения или другому устройству обработки данных для создания процедуры, таким образом, чтобы инструкции, выполняемые процессором компьютера или другим программируемым устройством обработки данных, создавали средства для реализации функций/действий, указанных в блоке или блоках блок-схемы и/или диаграммы.

[00124] Эти компьютерные программные инструкции также могут храниться на машиночитаемом носителе, который может управлять компьютером, отличным от программируемого устройства обработки данных или отличным от устройств, которые функционируют конкретным образом, таким образом, что инструкции, хранящиеся на машиночитаемом носителе, создают устройство, включающее инструкции, которые осуществляют функции/действия, указанные в блоке блок-схемы и/или диаграммы.

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. Система для осуществления умного поиска предложений билетов, содержащая:

• по меньшей мере один процессор, выполненный с возможностью

ο получения по меньшей мере одного запроса от пользователя на поиск предложений билетов;

ο преобразования по меньшей мере одного запроса от пользователя, полученного на предыдущем шаге, в набор запросов для шлюзов систем бронирования;

ο получения предложений по билетам от по меньшей мере одной системы бронирования;

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

• по меньшей мере один диспетчер, выполненный с возможностью распределения набора запросов для шлюзов, полученных процессором, по модулям взаимодействия со шлюзом;

• по меньшей мере один модуль взаимодействия со шлюзом, выполненный с возможностью определения, будет ли данный шлюз выполнять запрос и сколько необходимо запросов к данному шлюзу;

• по меньшей мере одну систему бронирования, выполненную с возможностью

ο выполнения по меньшей мере одного поискового запроса в шлюзе системы бронирования для тех запросов, которые были определены модулем взаимодействия со шлюзом как доступные;

ο направления на по меньшей мере один процессор предложений по билетам;

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