СПОСОБ И СИСТЕМА ФОРМИРОВАНИЯ УВЕДОМЛЕНИЙ О ПОЯВЛЕНИИ ПРЕДЛОЖЕНИЙ БИЛЕТОВ Российский патент 2021 года по МПК G06Q10/02 G06F16/24 

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

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

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

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

[003] Из уровня техники известна заявка на патент JP2005018369A «Seat reservation system for train, seat reservation server, program, and seat reservation method for train» (заявитель: Nec Corp, дата публикации: 20.01.2005). Настоящее изобретение относится к системе бронирования мест в поезде, серверу бронирования мест, программе и способу бронирования мест в поезде. В частности, пользователь может указывать различные запросы на назначенное место, а система подыскивает для него самое комфортное место по запросу. В данном решении терминал 3 окна станции и терминал 4 туристического агентства запрашивают ввод условий и приоритета места, включая обозначение поезда, классификацию местоположения в транспортном средстве, классификацию положения транспортного средства и контактные данные пользователя для передачи их на сервер резервирования места и средство инструкции резервирования для отображения полученной информации о свободном месте. Сервер бронирования места использует полученные данные и условия и разрабатывает условия до тех пор, пока место не будет найдено. В данном решении существует средство для первоначальной установки условия распределения и отмены прогнозирования скорости резервирования, если оно превышает предварительно определенное значение.

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

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

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

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

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

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

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

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

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

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

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

[0014] В некоторых вариантах реализации технического решения хранилище данных сервера является персистентным и/или не персистентным.

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

[0016] В некоторых вариантах реализации технического решения в качестве не персистентного хранилища используется memcache, а персистентного хранилища MariaDB.

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

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

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

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

[0021] В некоторых вариантах реализации технического решения запрос в шлюз бронирования билетов на поиск предложений является HTTP-запросом (или HTTPS) в API шлюза.

[0022] В некоторых вариантах реализации технического решения ответ от шлюза бронирования билетов приходит в формате XML или JSON.

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

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

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

[0025] На Фиг. 2 показан вариант реализации формирования пользователем запроса на получение билета, направление его на сервер, а также сохранение в персистентном и неперсистентном хранилище данных.

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

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

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

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

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

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

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

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

[0033] Ниже будет подробно раскрыт способ 100 формирования уведомлений о появлении предложений билетов, показанный в виде блок-схемы на Фиг. 1 и приведенный ниже посредством последовательности вычислительных шагов.

[0034] Шаг 110: получают на сервере от по меньшей мере одного пользователя его данные и параметры требуемого для него по меньшей мере одного предложения билета.

[0035] Функционал данного технического решения позволяет пользователю 200 подписаться на получение уведомлений о появлении билетов в продаже, как показано на Фиг. 2. Для этого пользователь оставляет свои контактные данные (например, адрес электронной почты или номер телефона, или никнейм или ID в мессенджере и т.д., не ограничиваясь) и подписывается на нужный ему транспорт (например, ЖД или авиа) или целое направление, а также выбирает конкретную дату или диапазон дат, класс обслуживания, кол-во необходимых мест и другие необходимые требования к местам для осуществления поездки. Пользователь оставляет свои данные на веб-сайте или в мобильном приложении пользователя, а также выбирает параметры уведомления (на какой поезд, дату и т.д. хочет получить билет). После того, как он нажимает на кнопку «подписаться» (данный вариант реализации является примерным, что очевидно), на сервер 220 уходят параметры сформированного им запроса 210 на уведомления о появляющихся предложений билетов (например, в примерном варианте реализации это может быть AJAX - запрос из веб-браузера). В некоторых вариантах реализации это может быть любое устройство связи, выполненное с возможностью передавать данные на сервер 220. Например, это может быть мобильное приложение, установленное на телефон пользователя. Также это могут быть терминалы для поездки на автобусе, которые установлены на вокзалах. Сервер 220 принимает запросы 210 с параметрами уведомления на своей стороне. На базе этих параметров запроса 210 создается запись в персистентном хранилище 230 (например, в базе данных), представляющая из себя строку таблицы БД (например, в БД MySQL) а также запись в не персистентном хранилище 240 (например в базе данных, находящейся в оперативной памяти, без записи на диск), т.к. выборка из него будет быстрее, чем из хранилища персистентного 230, после чего обработка закончена. Неперсистентное хранилище 240 располагается в оперативной памяти вычислительного устройства, поэтому, если сервер 220 выключить и включить, все данные потеряются. Однако доступ к данным в оперативной памяти быстрее, чем в случае с обычной персистентной базой данных, например, MySQL. Два хранилища данных используют в конкретном варианте реализации, чтобы если неперсистентное хранилище 240 обнулится (т.е. данные потеряются), была возможность загрузить данные из персистентного хранилища 330. В качестве неперсистентного хранилища 240 в конкретном варианте реализации используется memcache, а персистентного хранилища 230 - MariaDB. После появления мест, которые отслеживаются по приведенному ниже алгоритму, пользователь 200 уведомляется о возможности купить билеты через оставленные ранее контактные данные по любому каналу передачи данных, как показано на Фиг. 2.

[0036] Пользователю посредством графического интерфейса пользователя предоставляется возможность оформить заявку на уведомление о появлении предложений билета на выбранный им ранее транспорт в продаже. Для этого пользователь посредством графического интерфейса выбирает параметры заявки из выпадающего списка или вводит самостоятельно. Параметрами заявки могут быть, не ограничиваясь, интересующий вид транспорта, дата отправления или диапазон дат направления, пункт отправления, пункт прибытия, количество билетов или количество пассажиров, класс обслуживания (может быть представлен как "эконом/эконом+/бизнес" или для ЖД транспорта по России как "сидячий/плацкарт/общий/купе, люкс/спальный вагон"), номер рейса опционально, контактные данные для уведомления: смс/e-mail или другие виды.

[0037] После этого пользователь посредством интерфейса подтверждает свое согласие с предоставленными параметрами заявки и эти параметры посредством канала связи сети Интернет отправляются на сервер по протоколу передачи данных HTTP или HTTPS. Не ограничиваясь протоколом HTTP могут использоваться и другие протоколы из стека протоколов TCP/IP.

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

[0039] После получения параметров заявки на сервере 220 в хранилище данных создается структура 310, поля которой соответствуют параметрам заявки, как показано на Фиг. 3. После чего в эту структуру 310 (объект класса в программировании) автоматически заносятся параметры заявки 210. Также в этой структуре 310 существует дополнительное поля, которые никак не соотносятся с параметрами уведомления, полученными от пользователя, а заполняются на стороне сервера 220. Эти дополнительные поля структуры 310 могут включать статус заявки (создана, проверена, выполнена, отменена), следующая дата проверки, приоритет. В некоторых вариантах реализации приоритет может зависеть от стратегии поиска предложений билетов. Например, поезда скоро отправятся или это начало продаж, поэтому лучше их обрабатывать первыми.

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

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

[0042] В первом примере реализации получают набор из количества часов до отправления (этот набор может отличаться для разных направлений, систем бронирования билетов, вида транспорта, но в конкретном примере реализации для ЖД транспорта этот набор такой: "за 24 часа до отправления", "за 6 часов", "за 4", "за 2", "за 0 часов"). Используя этот набор, составляют набор дат со временем, путем вычитания из даты и времени отправления поезда количество часов из набора с добавленными, например, пятью минутами (это время на оформление билета на сайте). Фактически это должно быть среднее время, за которое пользователь успевает оформить билет на сайте или в мобильном приложении. Данное время выбирается эмпирическим путем. Этот набор дат далее фильтруется посредством удаления всех дат, которые уже наступили. Фильтрация может быть реализована следующим образом. Например в данный момент время 19:00, а поезд отправляется завтра в 18:00. Если взять время «за 24 часа до отправления», то получится дата «сегодня в 18:00». Но она уже наступила, потому что сейчас 19:00. Поэтому эту дату удаляют из выборки и рассматривают предложения дальше. Например, берут за «6 часов» и т.д. В итоге останутся только те даты, которые еще не наступили. Из оставшихся дат выбирается ближайшая к текущей дате и времени. Например остался набор дат такой: «сегодня в 21:00», «сегодня в 23:00». А сейчас 19:00. Ближайшей значит датой является «сегодня в 21:00».

[0043] Во втором варианте реализации используют сценарий, аналогичный первому, но использует не дату отправления, а дату прибытия поезда. Например, поезд должен прибыть на станцию 21.03.2020 в 15:00. Выбирают следующий набор дат: «за 24 часа», «за 6», и т.д. Затем вычитают и получают даты: «20.03.2020 в 15:00», «21.03.2020 в 9:00», «21.03.2020 в 11:00» и т.д. Далее оставляют только актуальные, предположим, что все. Так как сегодня, например, 18.03, то берут ближайшую дату, т.е. «20.03.2020 в 15:00».

[0044] В еще одном варианте реализации формируют набор дат (дата + время) путем вычитания из даты и времени отправления следующих отрезков: "40 дней" "35 дней" "25 дней" "20 дней" "15 дней" "10 дней" "7 дней" "5 дней" "3 дня". Далее из полученного набора дат со временем, остаются только те, которые еще не наступили и потом из них берется ближайшая дату со временем

[0045] В еще одном варианте реализации возвращают набор дат со временем, исходя из даты и времени открытия продаж на конкретное направление. Таким образом, берется дата и время открытия продаж на конкретное направление. Далее путем добавления к этой дате со временем 5, 10, 15, 25, 45, 105 и 145 минут мы получим набор из 7 дат со временем, из них оставляем только те, что еще не наступили и из них берем ближайшую дату со временем.

[0046] Поле "приоритет" задает приоритет для заявки, т.е. насколько эта заявка приоритетнее, чем другая. По умолчанию ставим "нормальный" приоритет.

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

[0048] Далее подробно раскрывается процесс проверки заявки системой в шлюзе бронирования.

[0049] Шаг 130: выгружают из хранилища данных все сформированные ранее структуры данных с заранее заданной периодичностью.

[0050] На сервере 220 работает процесс-демон 500 (т.е. компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем), как показано на Фиг. 5, который, например, каждую минуту или несколько секунд, не ограничиваясь, выгружает из неперсистетного хранилища 240 (потому что оно гораздо быстрее чем персистентное) все сохраненные ранее структуры 310, у которых содержимое поля "следующая дата проверки" меньше текущей даты и времени, т.е. наступило время проверки. В некоторых вариантах процесс-демон 500 может быть отключен в неработающие часы шлюза бронирования 530, если это заранее известно. Например известно, что шлюзы 530 не работают с 3 до 4 ночи и там нет смысла их опрашивать. Эти структуры формируются в группы (510, 520 и т.д.), как показано на Фиг. 5. Чтобы структуры были в одной группе, у них должны совпадать поля с пунктом отправления и прибытия (частичное совпадение), а также должны пересекаться даты отправления, класс обслуживания и количество пассажиров. В других вариантах реализации возможны варианты группировок, которые позволят снизить кол-во запросов к шлюзам 530 и обработать похожие заявки разом.

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

[0052] После этого по каждой группе сервером 220 делается запрос в шлюз бронирования 530 билетов. Для этого на базе значения поля "пункт отправления", значения поля "пункт прибытия", "дата отправления", кол-во пассажиров, класс обслуживания и опционально номер рейса формируется запрос в API шлюза 530, который представляет собой HTTP запрос (или HTTPS) в API шлюза бронирования 530 билетов.

[0053] Шлюз бронирования 530 билетов представляет из себя стороннюю систему, которая предоставляет посредством API информацию о текущих предложениях билетов на направление и дату. Сделанная ранее группировка структур 310 позволяет уменьшить количество запросов к шлюзу 530 и сделать один запрос на каждую группу, вместо отдельного запроса на каждую структуру. Например, один пользователь заказал уведомления на направление «Москва-Санкт-Петербург» на завтра - класс обслуживания любой, 1 пассажир, а второй пользователь также «Москва-Санкт-Петербург» на завтра, но на конкретный поезд 056А - класс обслуживания любой. В группе соответственно будут обе эти заявки, так как у них пересекаются даты и направление, а также класс обслуживания.

[0054] Шаг 150: получают ответ от по меньшей мере одного шлюза бронирования билетов.

[0055] Если в ответе от шлюза 530 содержатся предложения билетов, которые удовлетворяют значениям полей по меньшей мере одной структуры данных 310, направляют уведомление о появлении предложения билета пользователю по его контактным данным из этой структуры данных.

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

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

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

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

- память 403,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- получают ответ от по меньшей мере одного шлюза бронирования билетов, причем

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

2. Способ по п. 1, характеризующийся тем, что данные пользователя включают адрес электронной почты, и/или номер телефона, и/или имя, и/или никнейм.

3. Способ по п. 1, характеризующийся тем, что параметры предложения билета включают дату отправления или диапазон дат, и/или класс обслуживания, и/или количество необходимых мест.

4. Способ по п. 1, характеризующийся тем, что получают данные пользователя и параметры требуемого для него предложения билета из веб-сайта или мобильного устройства связи.

5. Способ по п. 1, характеризующийся тем, что хранилище данных сервера является персистентным и/или неперсистентным.

6. Способ по п. 5, характеризующийся тем, что неперсистентное хранилище располагается в оперативной памяти вычислительного устройства.

7. Способ по п. 5, характеризующийся тем, что в качестве неперсистентного хранилища используется memcache, а персистентного хранилища MariaDB.

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

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

10. Способ по п. 1, характеризующийся тем, что сформированные в хранилище данных сервера структуры данных объединяют в группы.

11. Способ по п. 10, характеризующийся тем, что объединяют структуры данных в группы, если совпадают поля с пунктом отправления и прибытия, и/или даты отправления, и/или класс обслуживания и количество пассажиров.

12. Способ по п. 1, характеризующийся тем, что запрос в шлюз бронирования билетов на поиск предложений является HTTP-запросом и/или HTTPS-запросом в API шлюза.

13. Способ по п. 1, характеризующийся тем, что ответ от шлюза бронирования билетов приходит в формате XML или JSON.