СИСТЕМЫ И СПОСОБЫ ВЗАИМОДЕЙСТВИЙ МЕЖДУ ВЛАДЕЛЬЦАМИ БИЛЕТОВ И ФУНКЦИЯМИ САМООБСЛУЖИВАНИЯ Российский патент 2022 года по МПК H04W4/21 

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

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

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

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

Помимо вышеупомянутых проблем, растет понимание потребностей пассажиров-инвалидов. Во многих странах на законодательном уровне гарантируется надлежащая помощь пассажирам с инвалидностью и ограниченной подвижностью в аэропортах. Примером является директива EU 1107/2006, где указано, что стойки регистрации пассажиров и регистрации и сдачи багажа являются зонами, где аэропорт отвечает за оказание помощи пассажирам с инвалидностью и ограниченной подвижностью. Существующее или будущее законодательство требует обеспечить доступ к любому решению сдачи багажа на основе автоматизации или самообслуживания и может требовать, например, определенной максимальной высоты тактильного доступа для инвалидов-колясочников и особых дополнительных устройств управления для слабовидящих пассажиров.

Изобретение ставит целью решение и смягчение этих проблем.

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

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

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

Варианты осуществления изобретения могут иметь преимущество упрощения взаимодействия между владельцами билетов и функциями самообслуживания. В одном предпочтительном варианте осуществления функцией самообслуживания является система приема багажа, например, для использования в аэропорту. Варианты осуществления изобретения могут иметь преимущество упрощения взаимодействий со стойкой сдачи багажа, и обеспечения возможности авиакомпании или другим поставщикам услуг снижать объем взаимодействия с человеком, необходимого при сдаче багажа и в других процессах самообслуживания и, таким образом, снижать стоимость и издержки.

В одном варианте осуществления изобретения билет связан с рейсом пассажира и включает в себя идентификацию пассажира и рейса. Информация билета может содержать посадочный талон. В одном варианте осуществления присутствие мобильного устройства в положении можно обнаружить с использованием устройства геолокации, например, маяка Bluetooth.

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

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

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

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

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

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

фиг. 1 - схема варианта осуществления изобретения;

фиг. 2 - блок-схема операций, демонстрирующая этапы согласно варианту осуществления изобретения;

фиг. 3 - схема системы, в которой воплощено изобретение;

фиг. 4 - логическая архитектура системы;

фиг. 5 - логическая архитектура облачной службы;

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

фиг. 7 - схема контроллера багажной стойки;

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

фиг. 9 - блок-схема операций процесса для мобильного приложения; и

фиг. 10 - блок-схема операций процесса для системы в целом.

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

В вариантах осуществления, представленных в чертежах, относящихся конкретно к решению для аэропорта, технология определения положения, например, маяки Bluetooth, распределенные по аэропорту, используется для того, чтобы мобильное устройство пассажира, например, смартфон, планшет, портативный компьютер или другое устройство могло определить присутствие данного маяка. Любая другая технология геолокации в помещении или вне помещения может использоваться для того, чтобы устройство могло определить свое относительное положение. Однако очевидно, что, будучи предпочтительной, маяки Bluetooth или другая технология определения положения не существенна для изобретения. Пассажир загружает на свое мобильное устройство приложение сдачи багажа. Это приложение может быть уникальным приложением сдачи багажа или модулем сдачи багажа приложения авиакомпании или аэропорта. Мобильное устройство 10 обнаруживает присутствие устройств определения положения, например, когда оно входит в аэропорт и проходит вблизи первого маяка 12. Когда пассажир проходит по аэропорту к зоне сдачи багажа, второй маяк 14 обнаруживается устройством 10, которое инициирует приложение сдачи багажа на устройстве. Обнаружение мобильным устройством пассажира первого маяка на входе в аэропорт не обязательно, но предпочтительно, поскольку обнаружение маяков устройством позволяет взаимодействовать с другими службами, обеспеченными в аэропорту.

Использование обнаружения маяка для отслеживания перемещения пассажира по аэропорту или аналогичному сооружению описано в WO2013117723.

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

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

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

Таким образом, в одном варианте осуществления, система использует смартфон или другое мобильное устройство пассажира и, в необязательном порядке, любую технологию геолокации в помещении или вне помещения, например, маяки Bluetooth или другие типы датчиков и картографические приложения, для автоматизации процесса сдачи багажа или любого другого пассажирского процесса, который требует взаимодействия с системой в аэропорту или других связанных местах. Вблизи зоны сдачи багажа, киоска или установки обработки пассажиров, пропускного пункта или электронного турникета, мобильное приложение на смартфоне или другом мобильном устройстве пассажира активируется, и пассажир и его детали брони идентифицируются. Устройство пассажира "сопрягается" со стойкой сдачи багажа, и все дополнительные инструкции по управлению сдачей багажа выполняются электронным/беспроводным образом через смартфон или мобильное устройство. Система содержит мобильное приложение, например, на смартфоне, блок обработки (контроллер), подключенный к стойке сдачи багажа, и облачную службу API, через которую осуществляется взаимодействие между мобильным приложением и стойкой сдачи багажа, как более подробно описано ниже.

Хотя описанный ниже вариант осуществления использует Bluetooth как инициирующий механизм сопряжения мобильного устройства с багажной системой, возможны другие способы. Например другой тип автоматического сопряжения, например, можно использовать другие маяки ближней бесконтактной связи (NFC), WIFI или BLE или ручной способ, например, QR или другой штрихкод, который сканируется владельцем мобильного устройства для запуска приложения или команды голосовой активации, например, Amazon Alexa^TM. В случае использования штрихкода пассажир может сканировать 2-D штрихкод на наклейке на стойке регистрации или фотографировать код известным образом. Для решения вопросов безопасности штрихкод можно создавать с использованием электронных чернил и регулярно изменять. Для наглядности связь между мобильным устройством и системой обработки багажа осуществляется через службу API, как описано ниже с использованием WIFI или другого протокола связи.

Процесс в отношении сдачи багажа показан более подробно на фиг. 2 с точки зрения пассажира. Процесс в целом обозначен 100. На этапе 102 пассажир регистрируется онлайн через свой смартфон или другое мобильное устройство. Как упомянуто выше, это можно делать через особое приложение или через модуль регистрации на веб-сайте авиакомпании. Как часть процесса регистрации создается мобильный посадочный талон, который включает в себя различную информацию о пассажире, в том числе ID пассажира и багажную норму. Посадочный талон хранится в подходящем месте хранения на мобильном устройстве. Примером подходящего места хранения в приложении кошелька Apple на устройствах, работающих под Apple IOS, или Google PassWallet на устройствах, работающих под Android. Возможны и другие хранение варианты.

Каждая авиакомпания может по выбору предлагать двухэтапный процесс самостоятельной сдачи багажа или одноэтапный процесс. На фиг. 2 приведен пример двухэтапного процесса, в котором, на этапе 106, пассажир печатает багажную квитанцию и прикрепляет ее к своему багажу. Он может печатать ее у себя дома или на работе или в киоске в аэропорту. Киоск может предназначаться для печати багажных квитанций или обеспечения другой функции, например, онлайн-регистрация. В одноэтапном процессе этап 106 исключен, и пассажир переходит прямо к сдаче багажа.

На входе в аэропорт мобильное устройство пассажира обнаруживает маяк расположенный вблизи входа в аэропорт (12, фиг. 1). Мобильное устройство снова обнаруживает второй маяк, когда пассажир оказывается вблизи этого второго маяка 14 на входе в зону сдачи багажа аэропорта. Это обнаружение демонстрирует намерение в приложении для мобильного устройства пользователя. Вызов API производится для получения деталей сдачи багажа, представленной маяком, и запрос сеанса к облачной службе осуществляется с использованием id сдачи багажа из вызова API и id мобильного устройства. Это более подробно описано ниже.

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

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

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

Открыв приложение сдачи багажа, пассажир подходит к указанной стойке сдачи багажа на этапе 110. Приложение может предписывать пассажиру представиться конкретному одному или группе терминалов самостоятельной сдачи багажа. На этой стадии приложение или модуль сдачи багажа извлекает данные посадочного талона, хранящиеся на устройстве. Они могут включать в себя информацию багажной нормы или информацию, которая может извлекаться с использованием идентификации пассажира из системы управления вылетом (DCS) авиакомпании. Проверка пригодности может осуществляться, например, для определения, не слишком ли рано или поздно пассажиру сдавать свой багаж, или доступен ли вариант сдачи багажа мобильного устройства для его конкретного рейса.

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

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

Исходя из того, что вес заключен в разрешенных пределах, или что за перевес заплачено, на этапе 114 печатается багажная квитанция. В случае вышеупомянутого двухэтапного процесса этот этап не требуется, поскольку багажная квитанция уже существует. Затем приложение отображает информацию о пассажире, касающуюся того, как присоединять багажную квитанцию к багажу.

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

На этапе 116 осуществляется этап проверки пассажира. Поскольку приложение имеет доступ к авиакомпании DCS, оно может извлекать PNR (запись имени пассажира) и сравнивать данные на квитанции с этой записью. Приложение может предписывать пассажиру сфотографироваться или использовать одну или более других форм проверки, предлагаемых мобильным устройством, например, биометрической идентификации или распознавания отпечатка пальца. Собранные таким образом данные могут храниться для ссылки в дальнейшем. Проверка пассажира может осуществляться до печати багажных квитанций.

На этапе 118, если личность пассажира удостоверена, багаж принимается системой управления вылетом (DCS), и упаковочный ярлык отображается пассажиру на смартфоне. Этот ярлык хранится в приложении и/или на мобильном устройстве. Затем багаж передается системе обработки багажа, причем этот этап осуществляется автоматически или с помощью сотрудника авиакомпании.

Передав багаж, приложение может сообщать пассажиру дополнительную информацию, касающуюся его рейса, например, но без ограничения, время посадки и номер выхода на посадку. В этот момент приложение может автоматически закрываться или может возвращать пассажира в навигационное приложение наподобие раскрытого в WO2013/117723, которое направляет пассажир к выходу на посадку с использованием маяков малого радиуса действия, распределенных по аэропорту.

На фиг. 3 показаны важные аппаратные компоненты, используемые в вышеописанном процессе. На мобильное устройство пассажира, обозначенное 200, загружается приложение, которое состоит из логики для регистрации багажа пассажира. Как упомянуто выше, приложение может представлять собой, например, модуль приложения авиакомпании или автономное приложение. Устройство 200 осуществляет связь с системой 210 управления вылетом (DCS) авиакомпания и облачной службой 220, где содержится набор API и связанная логика. Система регистрации багажа включает в себя стойку 230 регистрации багажа и контроллер 235, который может быть либо аппаратным контроллером, связанным со стойкой 230 регистрации багажа (BCIU), которая содержит программное обеспечение и/или программно-аппаратное обеспечение для осуществления связи с BCIU 230, либо модуль CUTE/CUSS, который выполняет те же функции. CUTE (Common Use Terminal Equipment) и CUSS (Common Use Self Service). CUTE и CUSS являются общеизвестными стандартами, которые позволяют использовать оборудование многочисленным авиакомпаниям или обслуживающим компаниям. Контроллер также осуществляет связь с облачной службой 220. Хотя это не обязательно, предусмотрен маяк 240 для автоматической идентификации зоны сдачи багажа, который осуществляет связь с мобильным устройством через Bluetooth ^TM или по другому протоколу связи. В случае использования маяков мобильное устройство 200 также осуществляет связь с реестром 250 маяков для извлечения идентификатора сдачи багажа. Даже в случае использования маяков, реестр 250 маяков может не быть обязательным, поскольку служба поддерживается облачной службой 220.

На фиг. 4 показана логическая архитектура системы. В общем случае, облачная служба (220 на фиг. 3) действует как посредник между мобильным устройством 200 и контроллером багажной стойки. Служба открывает мобильному устройству единственную концевую точку соединения, облегчает любые сложности, связанные с сетью, позволяет использовать для многих устройств протоколы "over the air", диспетчеризует доступность услуги приема багажа и создает абстракцию для любого обмена сообщениями, зависящего от контроллера. Соединение 400 WebSocket устанавливается между мобильным устройством 200 и облачной службой и между облачной службой и контроллером багажной стойки. Последнее соединение будет устанавливаться контроллером багажной стойки и поддерживаться на протяжении срока эксплуатации контроллера. Контроллер призван гарантировать, что соединение установлено. В случае обрыва соединения, контроллер должен переустановить соединение. Облачная служба будут считать стойку сдачи багажа недоступной, если соединение WebSocket не активно. Хотя описан websocket, могут использоваться другие асинхронные или бисинхронные методы.

Аналогично, мобильное устройство 200 отвечает за установление соединения с облачной службой 220 и за поддержание соединения на протяжение сеанса. Как и в случае контроллера, обнаружение службы от каждого мобильного устройства упрощает процесс.

Сквозной сеанс отображается путем связывания id мобильного устройства и контроллера багажной стойки.

Логическая архитектура облачной службы 220 показана на фиг. 5. Облачная служба образована набором микрослужб, базирующихся на распределенной реактивной платформе. Каждая концевая точка службы регистрирует адрес, по которому события, на основании оператора (op), будут маршрутизироваться через шину событий. Служба WebSocket является службой внешнего сопряжения, которая непосредственно осуществляет связь с контроллерами и мобильными устройствами.

На фиг. 6 изображена диаграмма 600 классов, где показана модель служб, отражающая доступные интерфейсы и грубее гранулированная по природе, чем платформенная модель служб. Она включает в себя следующие службы:

BagDropSvc 602

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

BagDropMngmtSvc 604

эта служба распоряжается диспетчеризацией контроллеров. При первом запуске контроллера, отправляется запрос регистрации. Служба взаимодействует с ConfigurationSvc 606 для удостоверения запроса и сохранения новой конфигурации для контроллера. Она также распоряжается статусом доступности контроллера.

TimerSvc 608

Сеанс имеет заранее определенный период бездействия. TimerSvc регулирует его и взаимодействует с sessionSvc для управления состоянием сеанса в целом.

ConfigurationSvc 606

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

SessionSvc 610

Эта служба управляет сеансом между мобильным устройством и контроллером. Она взаимодействует с AuthSvc для аутентификации пользователей на start_session и для удостоверения жетонов, и с timerSvc для объявления сеанса недействительным после периода бездействия.

AuthSvc 612

Этот служебный интерфейс действует как лицевая сторона одной или более реализаций аутентификации и авторизации. Начальная реализация будет обеспечивать схему аутентификации по локальному id пользователя/паролю, и JWT (веб-жетоны JSON) для авторизации.

На фиг. 7 показана логическая архитектура контроллера 235 багажной стойки, изображенного на фиг. 3. Рабочая станция 702, которой может быть любое подходящее вычислительное устройство, реализует аппаратную службу 704 и службу 706 контроллера сдачи багажа. Рабочая станция, в предпочтительном варианте осуществления, выполнена как терминал общего пользования, например, работающий под операционной системой Windows^TM, как рассмотрено выше. Служба контроллера сдачи багажа действует как уровень связи между облачной службой и аппаратной службой через WebSocket 708 и аппаратный уровень связи 710. Она также управляет состоянием машины и регистрируется в облачной службе. Аппаратная служба 704 подключается к серверу 710 IO и другому периферийному оборудованию. Альтернативно аппаратная служба может подключаться к модулю самообслуживания общего пользования.

Сервер 710 IO включает в себя программируемый логический контроллер PLC 712 для управления одной или более багажными лентами 714 и другим оборудованием 716. Он подключен либо к системе обработки багажа аэропорта, либо непосредственно к оборудованию.

На фиг. 8 показана архитектура приложения 800 для мобильного устройства (приложения). Приложение имеет два основных компонента, пакет средств разработки программного обеспечения SDK 802 и написанные пользователем обработчики 804 событий. Архитектура мобильного устройства призвана максимально переносить применимую обработку в SDK 802. Это облегчает разработчику приложений, который является конкретной авиакомпанией или внешним поставщиком, реализацию службы. Применимая обработка включает в себя последовательность операций, а также связь через сокет между мобильным устройством и облачной службой.

С этой целью разработчик приложений реализует набор задокументированных слушателей или обработчиков 804 событий. Эти слушатели, или наблюдатели, регистрируются для приема обратных вызовов от SDK, и в это время обработчик выполняет логику, заранее заданную для достижения определенного результата. Обработчику 804 также может требоваться вызывать SDK 802 с результатом, или просто сообщать SDK 802 о своем завершении. На фиг. 8 показаны взаимодействия высокого уровня между уровнем UX 806 (ощущений пользователя), логикой 808 приложения и SDK 802.

В нижеприведенной таблице 1 перечислены обработчики событий, реализуемые разработчиком приложений.

Оператор Описание no_session Вызывается в случае неудачи start_session, например, когда стойка сдачи багажа недоступна session_ready Сеанс готов, приложение просит пользователя поместить багаж на весы. Он также инициирует вызов правил авиакомпании, если они уже не заложены в приложении. scale_result Показания весов доставляются обработчику. К ним прилагаются правила аэропорта. В случае нарушения правил авиакомпании или аэропорта, обработчик предлагает пассажиру варианты. bagtag_printed Обработчику сообщается, что багаж можно забирать. Приложение может связаться с пассажиром прежде чем вызвать induct_bag. Если багажная квитанция уже отпечатана (в этом случае print_bagtag не вызывается), приложение сразу вызывает sdk induct_bag) bag_inducted Обработчик очищается и заканчивает сеанс. end_session Альтернатива к bag_inducted

Таблица 1

В таблице 2 перечислены методы, обращающиеся к sdk, которые реализованы приложением.

Метод Описание start_session Запрос инициирования сеанса связи со стойкой сдачи багажа. Наиболее вероятно вызывается в результате внешнего инициирования (например, маяка, NFC) от ближайшей стойки сдачи багажа. print_bagtag Приложению нужно вызвать свою DCS для регистрации багажа. В этот вызов включается успешный результат (изображение, PECTAB и т.д.). induct_bag Запрос на ввод багажа в систему BHS. print_receipt Запрос печати талона к багажной квитанции. end_session Запрос на окончание этого сеанса.

Таблица 2

На фиг. 9 показана блок-схема операций процесса, демонстрирующая сквозное взаимодействие между SDK 802, компонентами мобильного приложения авиакомпании и UX 806. В примере, приведенном на фиг. 9, багажная квитанция еще не отпечатана. Если бы багажная квитанция уже была отпечатана, для поддержки этого был бы выбран другой путь.

На фиг. 10 показаны сквозные взаимодействия между основными деятелями системы, приложением для мобильного устройства, облачной службой и стойкой самостоятельной сдачи багажа. Показана также DCS (система управления вылетом), взаимодействующая с приложением. Аналогично примеру на фиг. 9, багажная квитанция еще не отпечатана. Если бы багажная квитанция уже была отпечатана, был бы выбран другой путь.

Безопасности можно добиться, гарантируя, что все передачи, для всех сеансов, между мобильным устройством и облачной службой и между облачной службой и контроллером стойки сдачи багажа, осуществляются согласно защищенным криптографическим протоколам. В настоящее время предпочтителен протокол защищенного WebSocket (WSS). Для аутентификации и авторизации транзакций между всеми уровнями используются веб-жетоны JSON (JWT). JWT является компактным, URL-безопасным средством представления претензий между сторонами путем их кодирования как объектов JSON, которые можно снабжать цифровой подписью или шифровать.

В приложении для мобильного устройства, используются алгоритмы HMAC (код аутентификации сообщений на основе хэш-функции) между мобильным устройством и облачной службой. Каждый клиент (например, авиакомпания) принимает единую комбинацию ID пользователя и пароля. На session_start, эти учетные данные передаются облачной службе, которая удостоверяет их. JWT генерируется с использованием секретного ключа. Мобильное устройство отвечает за отправку JWT с каждым запросом. Новый JWT может генерироваться в любое время облачной службой. Мобильный клиент отвечает за сохранение JWT для каждого события, принятого от облачной службы, и за возвращение последней версии при последующих запросах.

Между контроллером стойки сдачи багажа и облачной службой также используются алгоритмы HMAC. Каждый контроллер стойки сдачи багажа заранее конфигурируется уникальным id, именем пользователя и паролем. При первом запуске модуля контроллер регистрируется в облачной службе, передавая свои уникальные учетные данные с запросом регистрации. В случае успешной регистрации, ответ облачной службы содержит JWT, который потребуется в каждом сообщении от контроллера к облачной службе.

В порядке альтернативы может использоваться шифрование открытым/секретным ключом RSA.

API распоряжается взаимодействиями между облачной службой 220 и контроллером 235, между облачной службой 220 и мобильным устройством 200 и между облачной службой 220 и обоими контроллером и мобильным устройством (в режиме посредника).

Каждое событие или операция API переносится в полезной нагрузке JSON по защищенному соединению WebSocket (WSS) и содержит оператор события (op). Тип оператора используется для маршрутизации сообщения на подходящий обработчик.

Сеанс между мобильным приложением и стойкой сдачи багажа инициируется в ходе start_session, длится с использованием JsonWebToken и заканчивается либо с окончанием, либо с превышением лимита времени вызова сеанса. Клиент мобильного приложения отвечает за передачу жетона с каждым вызовом, обращенным к облачной службе. За это может отвечать SDK, поскольку только он осуществляет связь с облачной службой через соединение WebSocket.

1. Облачная служба - мобильное устройство

Основная команда отправляется в следующем формате:

Этот формат пригоден для всех вызовов API кроме start_session, в котором будет отправляться ID пользователя и пароль приложения. В результате, возвращаемый жетон указывает успешную аутентификацию и активный сеанс со стойкой сдачи багажа. ID транзакции является необязательным для инициатора запроса. Если ID транзакции принят, предпочтительно, но не обязательно, возвращать его в полезной нагрузке ответа.

reply

reply представляет собой универсальный ответ, отправленный либо облачной службой, либо мобильным устройством. Сообщение несет информацию, относящуюся к предыдущему запросу, и (необязательный) ID транзакции. Он может использоваться для квитирования запроса в отсутствие конкретной полезной нагрузки ответа. Этот API является двунаправленным.

Описание полей

Ключ Значение Необходим op reply да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет for {api запроса} да result успешный или неудачный да reason_code причина неудачи условно

Пример

Коды причины (tbd)

Код Описание NO_RESPONSE Служба не ответила в течение периода ожидания NOT_SUPPORTED Универсальный ответ на запрос. Примеры включают в себя печать багажной квитанции, печать талона.

Start_session

start_session запрашивает, чтобы сеанс со стойкой сдачи багажа, обозначенной посредством id, начинался с клиентом. Учетные данные передаются в запросе. Каждый клиент системы будет иметь уникальный набор учетных данных. Учетные данные не уникальны для каждого пользователя приложения. Это однонаправленный, асинхронный запрос. В результате этого вызова клиент будет принимать либо событие session_ready, либо событие no_session. Направление в целом является направлением от мобильного приложения к облачной службе.

Описание полей

Ключ Значение Необходим op session_start да txid ID транзакции нет uid ID пользователя, обеспеченный клиентом да pwd Пароль, обеспеченный клиентом да bagdrop_id ID стойки сдачи багажа, обеспеченный в ходе обнаружения да

Пример

session_ready

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

Описание полей

Ключ Значение Необходим op session_ready да txid Возвращаемый ID транзакции нет token Жетон сеанса, обеспеченный службой да bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да config Пара значений ключа сконфигурированных возможностей стойки сдачи багажа. Значения TBD. нет

Пример

no_session

no_session является одним из двух событий, являющихся результатом запроса start_session. Он извещает клиента о том, что сеанс со стойкой сдачи багажа не удалось начать. Код причины будет присоединен к ответу. Направление является, в целом, направлением от облачной службы к мобильному приложению.

Описание полей

Ключ Значение Необходим op no_session да txid ID транзакции нет reason_code Верный код причины (см. таблица) нет bagdrop_id ID стойки сдачи багажа да

Пример

Коды причины

Код Описание OUT_OF_SERVICE Стойка сдачи багажа не работает. IN_USE Стойка сдачи багажа используется, осуществляется сеанс.

end_session

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

Описание полей

Ключ Значение Необходим op end_session да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да reason_code Причина окончания сеанса нет

Пример

Коды причины

Код Описание PROCESS_COMPLETE Любая сторона считает, что регистрация последовательности операций завершена. USER_REQUESTED Пользователь (пассажир) запросил остановить процесс UNIT_ERROR Стойка сдачи багажа обнаружила некоторую ошибку или нарушение работы и не может продолжать. SESSION_TIMEOUT Время ожидания сеанса истекло BAGGAGE_ERROR Возникла проблема, не позволяющая зарегистрировать этот багаж

scale_result

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

Описание полей

Ключ Значение Необходим op scale_result да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да weight Вес багажа да dimension Размеры багажа да weight_unit Используемые единицы (K=килограммы, P=фунты) да dimension_unit Используемые единицы (I=дюймы, M=миллиметры) да bhs_rules Матрица правил BHS нет bhs_rules.weight Ограничение по весу нет bhs_rules.dimension Ограничение по размеру нет bhs_rules.weight_unit Используемые единицы условно bhs_rules.dimension_unit Используемые единицы условно result Численная рекомендация (см. раздел кодов причины) да

Пример

Коды причины

Код Описание PASSED Вес/размер удовлетворяют всем требованиям FAILED_WEIGHT_AIRLINE Ограничение авиакомпании по весу не выполняется FAILED_WEIGHT_BHS Ограничение BHS по весу не выполняется FAILED_SIZE_AIRLINE Ограничение авиакомпании по размеру не выполняется FAILED_SIZE_BHS Ограничение BHS по размеру не выполняется PLACE_IN_TUB_RETEST Рекомендательный код для помещения багажа в ящик и на весы

print_bagtag

print_bagtag отправляется мобильным устройством облачной службе. Когда запрос доставляется на стойку сдачи багажа, он считается вызовом посредника. Запрос содержит изображение, подлежащее печати, например в формате PECTAB. Направление является направлением от мобильного приложения к облачной службе.

Описание полей

Ключ Значение Необходим op print_bagtag да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да image Изображение, подлежащее печати да format Формат изображения (например PECTAB) да

Пример

Форматы

Код Описание PECTAB Параметрическая таблица

induct_bag

induct_bag отправляется мобильным устройством облачной службе. Когда запрос доставляется на стойку сдачи багажа, он считается вызовом посредника. Предполагается, что запрос направляется на стойку сдачи багажа для инициирования ввода багажа в систему обработки багажа. Этот вызов является необязательным в зависимости от конфигурации. Например, некоторые конфигурации могут требовать, чтобы багаж автоматически вводился после некоторого определенного этапа, в частности, если багажная квитанция заранее отпечатана, и присоединена к багажу. Направление является направлением от мобильного приложения к облачной службе.

Описание полей

Ключ Значение Необходим op induct_bag да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да

Пример

print_receipt

print_receipt отправляется мобильным устройством облачной службе. После доставки запроса на стойку сдачи багажа, он считается вызовом посредника. Запрос содержит изображение, подлежащее печати, например в формате PECTAB.

Направление является направлением от мобильного приложения к облачной службе. Ожидается ответ.

Описание полей

Ключ Значение Необходим op print_receipt да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет bagdrop_id ID стойки сдачи багажа, с которой осуществляется сеанс да image Изображение, подлежащее печати да format Формат изображения (например PECTAB) да

Пример

Форматы

Код Описание PECTAB Параметрическая таблица

2. Облачная служба - контроллер

Основная команда отправляется в следующем формате:

Этот формат пригоден для всех вызовов API кроме register, в котором будет отправляться уникальный ID стойки обработки багажа, имя пользователя и пароль. ID транзакции является необязательным для инициатора запроса. Если ID транзакции принят, предпочтительно, но не обязательно, возвращать его в полезной нагрузке ответа.

reply

reply представляет собой универсальный ответ, отправленный либо облачной службой, либо контроллером. Сообщение несет информацию, относящуюся к предыдущему запросу, и (необязательный) ID транзакции. Он может использоваться для квитирования запроса в отсутствие конкретной полезной нагрузки ответа. Этот API является двунаправленным.

Описание полей

Ключ Значение Необходим Op ответ да Token Жетон сеанса, обеспеченный службой да Txid ID транзакции нет For {api запроса} да Result успешный или неудачный да reason_code причина неудачи условно

Примеры

Коды причины

Код Описание NO_RESPONSE Служба не ответила в течение периода ожидания

register

register отправляется контроллером сдачи багажа (модулем CUTE, CUSS или другим) в облачную службу. Это одноразовое сообщение, отправляемое первый раз, когда контроллер переводится в онлайн. Контроллер принимает одно из двух событий в результате запроса register, registered или registration_failed. Направление является направлением от контроллера к облачной службе.

Описание полей

Ключ Значение Op register bagdrop_id Заранее сконфигурированный ID стойки username Заранее сконфигурированное имя пользователя стойки password Заранее сконфигурированный пароль стойки

Пример

registered

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

Описание полей

Ключ Значение op registered token Жетон сеанса, обеспеченный службой

Пример

registration_failed

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

Описание полей

Ключ Значение op registration_failed

Пример

Коды причины

Код Описание UNKOWN_UNIT_ID Стойка сдачи багажа не найдена в базе данных (должна быть заранее сконфигурирована в облачной службе). BAD_CREDENTIALS Имя пользователя и/или пароль неверны

deregister

deregister отправляется контроллером сдачи багажа (модулем CUTE, CUSS или другим) в облачную службу. Запрос API сообщает облачной службе, что контроллер переведен в резерв, и его запись удалена из системы. Направление является направлением от контроллера к облачной службе.

Описание полей

Ключ Значение op deregister token Жетон сеанса, обеспеченный службой bagdrop_id Заранее сконфигурированный ID стойки username Заранее сконфигурированное имя пользователя стойки password Заранее сконфигурированный пароль стойки

Пример

mark_available

mark_available отправляется контроллером сдачи багажа (модулем CUTE, CUSS или другим) в облачную службу. Запрос API сообщает облачной службе, что контроллер теперь доступен для приема сеансов. Если контроллер уже доступен, облачная служба будет игнорировать запрос. Во всех случаях, квитирование будет отправляться обратно. Направление является направлением от контроллера к облачной службе.

Описание полей

Ключ Значение op mark_available token Жетон сеанса, обеспеченный службой

Пример

mark_unavailable

mark_available отправляется контроллером сдачи багажа (модулем CUTE, CUSS или другим) в облачную службу. Запрос API сообщает облачной службе, что контроллер недоступен для приема сеансов. Если контроллер уже отмечен как недоступный, облачная служба будет игнорировать запрос. Во всех случаях, квитирование будет отправляться обратно. Направление является направлением от контроллера к облачной службе.

Описание полей

Ключ Значение Op mark_unavailable Token Жетон сеанса, обеспеченный службой

Пример

Коды причины

Код Описание MAINTENANCE Контроллер переводится в оффлайн для обслуживания MODE_CHANGE Стойка сдачи багажа переходит в другой режим, например, в ручной режим

scale_result

scale_result отправляется стойкий сдачи багажа облачной службой. Ответ включает в себя набор ограничений по весу/размеру аэропорта или системы обработки багажа. Направление является направлением от контроллера к облачной службе.

Описание полей

Ключ Значение op scale_result token Жетон сеанса, обеспеченный службой weight Вес багажа dimension Размеры багажа weight_unit Используемые единицы (K=килограммы, P=фунты) dimension_unit Используемые единицы (I=дюймы, M=миллиметры) bhs_rules Матрица правил BHS bhs_rules.weight Ограничение по весу bhs_rules.dimension Ограничение по размеру bhs_rules.weight_unit Используемые единицы bhs_rules.dimension_unit Используемые единицы result Численная рекомендация (см. раздел кодов причины)

Пример

Коды причины

Код Описание PASSED Вес/размер удовлетворяют всем требованиям FAILED_WEIGHT_AIRLINE Ограничение авиакомпании по весу не выполняется FAILED_WEIGHT_BHS Ограничение BHS по весу не выполняется FAILED_SIZE_AIRLINE Ограничение авиакомпании по размеру не выполняется FAILED_SIZE_BHS Ограничение BHS по размеру не выполняется PLACE_IN_TUB_RETEST Рекомендательный код для помещения багажа в ящик и на весы

print_bagtag

print_bagtag отправляется облачной службой на контроллер. Когда запрос инициируется мобильным устройством, он считается вызовом посредника. Запрос содержит изображение, подлежащее печати, например в формате PECTAB. Направление является направлением от облачной службы на контроллер облака. Ожидается ответ от контроллера.

Описание полей

Ключ Значение Необходим op print_bagtag да token Жетон сеанса, обеспеченный службой да Transaction_id ID транзакции нет image Изображение, подлежащее печати да format Формат изображения (например PECTAB) да

Пример

Форматы

Код Описание PECTAB Параметрическая таблица

induct_bag

induct_bag отправляется облачной службой на контроллер. Когда запрос инициируется на мобильном устройстве, он считается вызовом посредника. Предполагается, что запрос направляется на стойку сдачи багажа для инициирования ввода багажа в систему обработки багажа. Этот вызов можно рассматривать как необязательный на основании конфигурации. Например, некоторые конфигурации могут требовать, чтобы багаж автоматически вводился после некоторого определенного этапа, в частности, если багажная квитанция заранее отпечатана, и присоединена к багажу. Направление является направлением от облачной службы к контроллеру. Ожидается ответ.

Описание полей

Ключ Значение Необходим op induct_bag да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет

Пример

print_receipt

print_receipt отправляется облачной службой на контроллер. Когда запрос исходит от мобильного устройства, он считается вызовом посредника. Запрос содержит изображение, подлежащее печати, например в формате PECTAB. Направление является направлением от мобильного приложения к облачной службе. Ожидается ответ.

Описание полей

Ключ Значение Необходим op print_receipt да token Жетон сеанса, обеспеченный службой да txid ID транзакции нет image Изображение, подлежащее печати да format Формат изображения (например PECTAB) да

Пример

Форматы

Код Описание PECTAB Параметрическая таблица

Как описано, система содержит приложение внешнего интерфейса, которое является либо уникальное приложение, либо модуль на веб-сайте авиакомпании/аэропорта. Это интерфейс, через который авиакомпании и/или аэропорты предоставляют своим пассажирам услугу приема багажа. Внутренняя программная машина реализует логику для процесса самостоятельного сдачи багажа и возбуждает процесс. API обеспечивает связь между приложением, внутренней программной машиной и оборудованием системы обработки багажа и периферийными устройствами самостоятельной сдачи багажа, например, принтером и весами. Другие быстродействующие периферийные устройства могут включать в себя автоматизированные устройства чтения и устройства оценивания багажа, например, оборудование BHS может содержать новые или существующие транспортерные ленты и весы.

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

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

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

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

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

Изобретение относится к области сервисов, специально предназначенных для беспроводных сетей связи, а именно к автоматизированному взаимодействию с пассажирскими службами, например обработке багажа. Техническим результатом является обеспечение упрощения процедуры взаимодействия между мобильными устройствами и функциями самообслуживания за счет исключения необходимости предварительного знания мобильным устройством определенной функции самообслуживания. Информация билета, например посадочный талон авиакомпании, может храниться на мобильном устройстве. Присутствие устройства геолокации, например маяка Bluetooth, обнаруживается мобильным устройством в месте вылета, например аэропорту. При обнаружении мобильным устройством дополнительного устройства геолокации, когда мобильное устройство находится вблизи функции самообслуживания, на мобильном устройстве запускается приложение, которое направляет мобильное устройство к функции самообслуживания, например стойке сдачи багажа, и инструктирует пользователя мобильного устройства, как использовать функцию самообслуживания. 3 н. и 22 з.п. ф-лы, 10 ил.

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

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

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

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

2. Способ по п. 1, в котором билет связан с рейсом пассажира и включает в себя идентификацию пассажира и рейса.

3. Способ по п. 2, в котором информация билета содержит посадочный талон.

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

5. Способ по п. 4, в котором устройством геолокации является маяк Bluetooth.

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

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

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

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

10. Способ по п. 8, содержащий после размещения багажа на стойке сдачи багажа взвешивание багажа, определение, превышает ли вес разрешенный вес, и если вес превышает разрешенный вес, взимание оплаты штрафа за превышение нормы багажа через приложение.

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

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

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

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

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

14. Способ по п. 13, в котором приложение активируется путем сканирования или формирования изображения штрихкода с использованием мобильного устройства.

15. Система для облегчения взаимодействия между владельцем билета и функцией самообслуживания, связанной с билетом, содержащая:

функцию самообслуживания;

мобильное устройство, причем на мобильном устройстве хранится информация, относящаяся к билету;

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

по меньшей мере один сервер, на котором хранится компьютерное программное обеспечение для осуществления этапов:

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

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

16. Система по п. 15, в которой билет связан с рейсом пассажира и включает в себя идентификацию пассажира и рейса.

17. Система по п. 15, в которой информация билета содержит посадочный талон.

18. Система по п. 17, в которой по меньшей мере одно устройство геолокации представляет собой маяк Bluetooth.

19. Система по п. 15, в которой приложение запрашивает информацию билета, хранящуюся на мобильном устройстве, и передает информацию билета на сервер.

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

21. Система по п. 15, содержащая систему управления вылетом, в которой функцией самообслуживания является стойка сдачи багажа, содержащая систему обработки багажа и контроллер сдачи багажа, и информацией, относящейся к билету, является посадочный талон, содержащий передачу информации о пассажире в посадочном талоне системе управления вылетом.

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

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

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

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