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

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

 

Область техники, к которой относится изобретение

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

Уровень техники

Обычно, авиакомпании совместно используют общую инфраструктуру, такую как вычислительные устройства, которые, в общем, предоставляются аэропортом, чтобы обслуживать своих пассажиров. Известные совместно используемые общие инфраструктурные решения являются негибкими, дорогостоящими, трудными в развертывании и работе и не приспосабливают без сложностей новейшую технологию, такую как использование мобильных устройств. Это обусловлено тем, что известные решения вынуждают авиакомпании работать в окружении с наименьшим связующим звеном. Например, конкретная версия Microsoft Windows™, конкретная версия Adobe™ Flash™ или конкретная версия JAVA™, которые обычно используются посредством совместно используемых устройств в окружении аэропорта, могут определять то, как известные решения взаимодействуют или осуществляют доступ к конкретным службам. Это может приводить к техническим трудностям в предоставлении доступа к совместно используемым устройствам.

Также следует принимать во внимание, что известные платформы, такие как платформа Microsoft™ Windows™, которая может управлять совместно используемыми устройствами, представляют собой закрытые платформы. Это вынуждает пользователей осуществлять доступ к устройствам в локальном окружении аэропорта посредством локального интерфейса, чтобы обмениваться данными с платформой. Таким образом, отсутствуют условия для возможности коммутироваться удаленно с одним или более устройствами в локальном окружении аэропорта.

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

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

Сущность изобретения

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

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

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

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

Базовая функциональность решения предоставляет общий API, который обеспечивает возможность приложениям авиакомпании динамически подписываться на совместно используемую или выделенную инфраструктуру в любом местоположении в любом доступном аэропорту в глобальном масштабе. Совместно используемая или выделенная инфраструктура не ограничена аэропортами, и она может включать в себя автомобильные парковки, отели, железнодорожные станции, конференц-центры, центры города, круизные суда и т.д. API может использовать идентификационные данные местоположения для того, чтобы ассоциировать пользовательские сеансы авиакомпании с совместно используемой инфраструктурой. Идентификационные данные местоположения основаны на несложном соглашении о присвоении имен, которое уникально идентифицирует любую инфраструктуру в аэропортах и местоположениях не в аэропортах. Клиентские приложения могут получать идентификационные данные местоположения рядом различных способов, к примеру, как QR-метки, радиомаяки, NFC и т.д.

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

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

Варианты осуществления изобретения могут использовать архитектуру, которая имеет возможность предоставлять доступ к совместно используемой инфраструктуре в распределенном скелете. Эта реализация не ограничена конкретной версией приложений Microsoft™ Windows™ или Linux™, или Cisco™ IOx™, или Androd™.

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

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

Согласно дополнительному аспекту настоящего изобретения, предусмотрено компьютерное обрабатывающее устройство для предоставления доступа к одному или более электронным устройствам. Устройство содержит средство (103) обработки, выполненное с возможностью: i. определять идентификатор местоположения, ассоциированный с событием входа пользователя в учетную запись; ii. ассоциировать идентификатор местоположения с идентификатором пользовательского сеанса; и iii. передавать (3013) идентификатор местоположения и ассоциированный идентификатор пользовательского сеанса в приложение (109).

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

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

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

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

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

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

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

Варианты осуществления изобретения используют решение, называемое "решением на основе портала следующего поколения (NGP)". Решение может реализовываться посредством предоставления 2 различных каналов. Эти каналы могут упоминаться как канал для устройств и канал для графического пользовательского интерфейса (GUI). Означенное, вместе с интернет-браузером с поддержкой HTML 5, позволяет предоставлять множество вышеуказанных преимуществ.

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

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

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

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

Таким образом, варианты осуществления изобретения могут быть основаны на облачной платформе, такой как технология Microsoft™ Azure™, в частности, на использовании IoT-концентратора, оболочки предоставления служб, API-шлюза, потоковой аналитики и машинного обучения. Решение компонуется с использованием многогранной безопасности, в частности, через использование потоковой аналитики, машинного обучения и глубокого обучения, чтобы профилировать поведение пользователей и системы, чтобы идентифицировать и адаптироваться к аномалиям.

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

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

Краткое описание чертежей

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

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

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

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

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

В этом конкретном варианте осуществления, службы или модули интерфейса прикладного программирования (API) компонуются на платформе Microsoft AZURE. Тем не менее, могут использоваться другие платформы, известные специалистам в данной области техники, такие как облачная платформа Amazon Web Services (AWS), облачная платформа IBM или облачная платформа Google.

Дополнительно, следует принимать во внимание, что функциональность может реализовываться на любом языке программирования, например, могут использоваться HTML 5, С++™, JAVA™ и.xml, а также другие языки программирования, которые известны для специалистов в данной области техники. Например, варианты осуществления изобретения могут использовать один из этих языков программирования, чтобы предоставлять веб-службу.

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

В этом конкретном варианте осуществления, система содержит три различных зоны: API-окружение 103, окружение 109 приложений и окружение 105 аэропорта.

Обычно, одна или более из этих зон находятся в различных физических местоположениях. Например, API-окружение 103 может быть физически расположено в конкретном штате, таком как Калифорния в Соединенных Штатах, в то время как локальное окружение 105 аэропорта может быть расположено, например, в Богемии в Соединенных Штатах. Конкретное окружение 109 приложений авиакомпании, размещающее одно или более приложений 141, 143, 145, также может находиться в Соединенных Штатах. Окружение приложений может функционально соединяться с системой управления вылетами, которая может размещаться, например, в другом регионе, местоположении или стране, к примеру, в Германии.

В другом конкретном примере, API-окружение 103 может быть физически расположено в Нидерландах, в то время как одно или более пользовательских устройств 107 и ассоциированных GUI, выполняющихся на устройствах, могут быть расположены во Франкфурте, Германия, в то время как одно или более совместно используемых устройств 108 могут быть расположены в Богемии, Соединенные Штаты. Окружение приложений и ассоциированные приложения 141, 143, 145 также могут быть расположены в Соединенных Штатах, в то время как система управления вылетами или другая внутренняя интерфейсная система 102 расположена в Германии.

Описание пользовательских устройств 107, совместно используемых устройств 108 и локальных и удаленных окружений

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

Вторая группа вычислительных устройств 108 может содержать любое одно или более из принтера либо сканера или считывателя, устройства на стойке регистрации, устройства на стойке на посадку, киоска (к примеру, киоска для печати посадочного талона или багажной бирки), устройства на стойке приема багажа, устройства для проведения досмотра или устройства для обеспечения автоматического выхода на посадку. Другими словами, вторая группа вычислительных устройств 108 связана с совместно используемыми инфраструктурными вычислительными устройствами. Сканер или считыватель обычно выполнен с возможностью считывать посадочный талон или багажную бирку, паспорт или удостоверение личности либо другой машиночитаемый документ. Это обычно выполняется с использованием оптического сканирования посадочного талона или багажной бирки с использованием алгоритмов оптического распознавания символов (OCR), которые известны для специалистов в данной области техники.

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

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

Описание основных функциональных компонентов

Система 100 может содержать любой один или более следующих функциональных компонентов: один или более модулей или интерфейсов 111 для предоставления одной или более служб. Модули обычно, соответственно, функционально соединяются с одним или более приложений 141, 143, 145. Дополнительно, каждый из модулей или интерфейсов может функционально соединяться с одним или более устройствами 108. Любой из функциональных компонентов в API-окружении 103 может упоминаться как модуль для выполнения одной или более различных функциональных операций.

Например, сервер или компьютер 101 может быть выполнен с возможностью выполнять интерфейс прикладного программирования (API) в API-окружении 103. Компьютер-сервер обычно функционально соединяется, через средство проводной или беспроводной передачи, которое должно быть известно для специалистов в данной области техники, с любым одним или более различными функциональными компонентами, показанными на фиг. 1, 2 и 3 из чертежей.

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

Обычно, локальное окружение 105 функционально соединяется с API-окружением 103 через протоколы проводной или беспроводной связи, которые известны для специалистов в данной области техники. Аналогично, удаленное окружение 109 обычно функционально соединяется с API-окружением 103 через протоколы проводной или беспроводной связи, которые известны для специалистов в данной области техники.

Описание базы 104 данных и радиомаяка 110

Как показано на фиг. 1 из чертежей, база 104 данных может предоставляться в качестве части системы. Обычно данные, ассоциированные с базой данных, сохраняются в средстве хранения данных или запоминающем устройстве, таком как постоянное запоминающее устройство или оперативное запоминающее устройство. Тем не менее, не существенно то, что база данных расположена в API-окружении. Например, база данных может предоставляться в любом местоположении, если она функционально соединяется с API-окружением Azure. В базе данных обычно выполняется поиск посредством API 106. База данных обычно содержит один или более различных идентификаторов радиомаяков, таких как UUID, и один или более различных идентификаторов (идентификаторов) местоположений. Ассоциирование между каждым идентификатором радиомаяка и каждым идентификатором местоположения

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

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

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

deviceId: "413dc6c0a03d4d6a9cd2c1=".

Дополнительно, чтобы различать между различной

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

Например, тип устройства LSR может указывать сканнер штрих-кода, используемый для того, чтобы сканировать посадочный талон или багажную бирку. Тип устройства или метка MSR может указывать то, что устройство представляет собой считыватель магнитных карт с проведением, используемый для того, чтобы считывать карту лояльности или кредитную карту. Другие типы устройств или метки могут представлять собой ВТР, указывающую то, что устройство представляет собой принтер багажных бирок или принтер посадочных талонов, называемый "АТР (принтером для автоматической выписки билетов и посадочных талонов)", что указывает то, что устройство представляет собой принтер посадочных талонов. Комбинация типа устройства и идентификатора местоположения обеспечивает возможность уникальной идентификации конкретного устройства в конкретной области аэропорта.

Описание идентификационных данных пользовательского сеанса и служб 114 аутентификации

Модуль 114 предоставления служб аутентификации может предоставляться в API-окружении 103. Это обеспечивает возможность пользователям подписываться на систему, а также предоставляет последующий доступ к системе с именем и паролем для входа пользователя в учетную запись.

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

Описание опубликованных интерфейсов

Один или более интерфейсов или функциональных компонентов, показанных на фиг. 1 из чертежей, могут представлять собой интерфейсы, которые публикуются или становятся доступными для третьих сторон за пределами API-окружения 103. Например, конфигурационный портал 115, веб-прокси-служба 113 и API-службы 111 и конкретные интерфейсы 117 предоставления служб для устройств могут рассматриваться в качестве опубликованных интерфейсов. Опубликованные интерфейсы имеют 2 различных вида ответственности.

Во-первых, API или службы 111 предоставляют обмен данными между одним или более приложениями 141, 143, 145, выполняющимися в удаленном окружении 109, и одним или более устройствами 107, 108, работающими в локальном окружении аэропорта.

Во-вторых, сведения, связанные с конкретными характеристиками устройств и возможностями работы конечных пользователей, предоставляются через конфигурационный портал 115, показанный на фиг. 1. Конфигурационный портал 115 может эффективно интегрировать API-данные с интерфейсом устройств, который соединяет интерфейс 117 предоставления служб для устройств с одним или более совместно используемыми устройствами 108 в окружении аэропорта. Это обеспечивает возможность системе использовать полные характеристики устройств 108. Ниже подробнее описываются конфигурационный портал 115 и ассоциированные конфигурационные настройки, ассоциированные с каждым совместно используемым устройством 108.

Функциональное описание API 111: функция подтверждения приема и маршрутизации

Один или более API 111, предоставленных в API-окружении, могут иметь две основных функции. Во-первых, они передают сообщения подтверждения приема в ответ на прием сообщения(й) 121, 122 из одного или более приложений 141, 143, 145 в окружении 109 удаленных приложений. Во-вторых, они имеют функцию маршрутизации сообщений в службу для корректных устройств в API-интерфейсе 117 предоставления служб для устройств. Обычно, это необходимо, поскольку определенное число различных служб для устройств предоставляются в интерфейсе 117 предоставления служб для устройств. Например, службы в интерфейсе 117 предоставления служб для устройств могут быть связаны с печатью посадочного талона или печатью багажной бирки либо сканированием посадочного талона или багажной бирки, либо со считыванием кредитной карты или карты лояльности с использованием считывателя магнитных карт с проведением, и т.п.

Таким образом, API-служба(и) 111 может выполнять функцию как маршрутизации сообщений в корректную службу в интерфейсе 117 предоставления служб для устройств, так и отправки сообщения подтверждения приема, чтобы подтверждать то, что запрос из одного из приложений 141, 143, 145 в окружении удаленных приложений корректно принят посредством API-службы 111.

API 301 оболочки CUTE

API 301, показанный на фиг. 3 из чертежей, также может предоставляться и расположенный в API-окружении 103. Он упоминается как API оболочки CUTE. Одна из функций приложения 301 заключается в том, чтобы транслировать между различными используемыми протоколами. Дополнительно, приложение 301 также может транслировать команды между API-окружением 103 и окружением 109 удаленных приложений. Помимо этого, API выполняет функцию аутентификации, чтобы проверять то, что сообщения 122, принимаемые из окружения удаленных приложений, ассоциированы с подлинным пользователем. API оболочки CUTE является, в частности, полезным при интегрировании унаследованных приложений авиакомпании для использования в NGP-систему. Тем не менее, это, конечно, является необязательным, и приложения авиакомпании могут быть выполнены с возможностью непосредственно принимать сообщения из NGP-системы, в пределах потребности из API 301 оболочки CUTE.

Описание обмена данными между функциональными компонентами

На фиг. 1 обмен данными между различными функциональными компонентами представляется посредством стрелок, помеченных 121, 122, 123, 124, 125, 126, 127, 128 и 129. Конечно, в целях прозрачности, показана не вся связь между различными функциональными компонентами. Тем не менее эти дополнительные сведения подробно описываются ниже.

В одном конкретном примере, обмен 121, 122 сообщениями между API-службами 111 и соответствующими и обычно ассоциированными приложениями 141, 143 в окружении удаленных приложений, показанном на фиг. 1, может реализовываться с использованием XML-сообщений формата Java Script Object Notation (JSON™). Он представляет собой формат обмена данными на основе языка программирования Java™ Script. Он подробнее описывается со ссылкой на фиг. 3 из нижеприведенных прилагаемых чертежей. Конечно, могут использоваться другие протоколы обмена сообщениями, известные специалистам в данной области техники.

Подробное описание размещения и функциональности радиомаяков

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

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

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

Приложение обычно выполнено с возможностью обнаруживать один или более радиомаяков 110 посредством протоколов беспроводной связи, таких как Bluetooth. После того, как приложение обнаруживает UUID радиомаяка, он отправляется в API-окружение 103.

Идентификатор радиомаяка или UUID-данные, например, могут представлять собой 32-значный буквенно-цифровой код. Код, например, может иметь формат 1 АЕ18С1 C-6C7B-4AED-B166-4462634DA855, который ассоциирован с радиомаяком. API также может возвращать одно или более из majorld = 14, minorld = 2. В другом конкретном примере, API 106 может возвращать одно или более из UUID = 1 14A4DD8-5B2F-4800-A079-BDCB21392BE9, majorld = 1100, minorld = 1292; majorld и minorld могут использоваться для того, чтобы различать между радиомаяками в конкретном районе, имеющем общий UUID. API 106 может возвращать данные, ассоциированные с одним или более радиомаяков.

Описание того, как UUID, сохраненные в базе 104 данных, преобразуются в идентификаторы местоположений

В API-окружении 103, преобразование идентификаторов из идентификатора радиомаяка 110 в идентификатор местоположения может выполняться в качестве службы. Таким образом, в качестве части процесса начального конфигурирования, идентификатор радиомаяка и идентификатор местоположения передаются в API-окружение. Идентификатор местоположения может иметь форму буквенно-цифровой строки, такой как "JFKT5CK01", которая указывает то, что радиомаяк, и в силу этого, пользовательское устройство 108 расположены в аэропорту John F Kennedy, терминал 5, стойка 01 регистрации пассажиров.

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

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

База данных также может включать в себя карту локального окружения аэропорта. Это обеспечивает возможность визуального представления физического местоположения радиомаяка(ов) 110, а также ассоциированных пользовательских устройств 107, которые находятся около каждого радиомаяка 110.

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

Дополнительное описание идентификатора местоположения

Как описано выше, идентификатор (идентификатор) местоположения может рассматриваться в качестве ассоциирования или линии связи между каналом 12 4 связи между устройствами и каналом 125 GUI-связи, показанным на фиг. 1.

Дополнительно, может предоставляться определенное число различных ассоциаций между каналом 12 4 связи и каналом 12 5 связи и одним из приложений 141, 143, 145, выполняющихся в окружении 109 удаленных приложений. Это обеспечивает возможность пользователю использовать несколько местоположений.

Как указано выше, местоположение может определяться с использованием радиомаяка, NFC или метки. Идентификатор (идентификатор) местоположения может синтаксически анализироваться посредством внутренней интерфейсной службы.

Нижеприведенное описание акцентирует внимание на дополнительных сведениях относительно принципа идентификатора (идентификатора) местоположения. Идентификатор местоположения может соответствовать формату любого из нижеприведенных примеров:

1. BOH-PREPROD-T01-GATE01-WKS-001

2. JFK-T01-GATE03-WKS-002

3. MIA-ADM-FLR1-CONF1-WKS-001

Пример 1

В этом примере, аэропорт = ВОН, район = опытное производство, терминал = 1, выход = 1 и рабочая станция = 1.

Пример 2

В этом примере, аэропорт = JFK, терминал = 1, выход = 03 и рабочая станция = 2.

Пример 3

В этом примере, аэропорт = MIA, район = администрация, этаж = 1, конференц-зал = 1 и рабочая станция = 001.

Эти примеры задают относительное местоположение или местоположение, которое может находиться в любом местоположении в пределах одного или более предварительно определенных районов. Идентификаторы местоположений могут задавать районы, области или объемы в двумерном или трехмерном пространстве. Двух- или трехмерное пространство может задаваться посредством одной или более координат X, Y или Z, которые ассоциированы с каждым районом или пространством. Координаты, задающие каждый район или пространство, могут сохраняться в базе данных, к примеру, в базе 112 данных, наряду с ассоциированным идентификатором местоположения, задающим каждый район или пространство.

В вышеприведенных примерах, идентификатор местоположения может задавать различные области. Обычно, по меньшей мере, некоторые из различных областей перекрываются с одной или с другой либо могут содержаться полностью в другой области. Таким образом, аэропорт может рассматриваться в качестве области 1, район администрации может рассматриваться в качестве подобласти 2, и конференц-зал может рассматриваться в качестве подобласти 3 для подобласти 2. Подобласть 3 может полностью содержаться в подобласти 2. Аналогично, подобласть 2 может полностью содержаться в подобласти 1.

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

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

Дополнительно, могут предоставляться база данных аббревиатур районов и ассоциированных пояснений этих аббревиатур.

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

Например, предположим, что регистрационный киоск развертывается на Таймс-сквер, Нью-Йорк.

Идентификатор местоположения может задаваться посредством NYC-TSQ-…

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

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

Таким образом, идентификатор местоположения обычно начинается с IATA-заданного кода, указывающего местоположение, такого как JFK, LGA, LAX, или известного сокращения местоположения, такого как NYC.

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

Описание типа устройства или общей метки устройства, чтобы различать между различными типами совместно используемых устройств 108

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

Это может осуществляться посредством ассоциирования одного из совместно используемых устройств 108 с конкретным идентификатором местоположения и меткой типа устройства. Пример меток типа устройства представляет собой ATP, ВТР, LSR, MSR, как описано выше.

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

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

В качестве первого варианта, совместно используемое устройство 108 может уникально определяться на основе идентификатора местоположения и метки типа устройства, такой как ATP, LSR ВТР.

В качестве второго варианта, совместно используемое устройство 108 уникально идентифицируется с использованием UUID радиомаяка, который преобразуется в идентификатор JFKT5CK01 местоположения и метку АТР. Это означает то, что местоположение совместно используемых устройств 108 является идентичным или аналогичным местоположению пользовательских устройств 107. Идентификатор радиомаяка, такой как UUID радиомаяка, может предоставлять линию связи или ассоциирование между идентификатором совместно используемого устройства или меткой и идентификатором местоположения.

Фиг. 2 чертежей показывает принципиальную схему конкретного варианта осуществления, в котором предоставляется адаптер 201. Этот адаптер предоставляется для современных устройств 107 в аэропорту, которые не допускают соединение с облаком 203 IoT-концентратора непосредственно. Таким образом, служба адаптера используется для того, чтобы обеспечивать возможность унаследованному устройству функционировать в качестве IoT-устройства. Этот адаптер вместе с интерфейсом устройств публикуется, чтобы обеспечивать возможность производителям устройств разрабатывать устройства, которые имеют собственную IoT-поддержку. Адаптер 2 01, показанный на фиг. 2, также может упоминаться как полевой шлюз (FG), показанный на фиг. 1 из чертежей.

Идентификатор местоположения абстрагирует позицию

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

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

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

Подробное описание API-интерфейса 117 предоставления служб для устройств

API-интерфейс 117 предоставления служб для устройств может предоставляться в API-окружении.

API-интерфейс 127 предоставления служб для устройств предоставляет интерфейс с любым одним или более совместно используемыми устройствами 108. Это обеспечивает возможность перечисления и обеспечения доступности служб, которые могут выполнять любые одно или более совместно используемых локальных устройств, для использования посредством любого из пользовательских устройств 107.

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

Дополнительные сведения относительно характера печати могут предоставляться посредством API предоставления служб для устройств. Например, они могут указывать то, что принтер допускает печать багажной бирки, которая может присоединяться к багажу пассажира. Аналогично, API предоставления служб для устройств может указывать то, что принтер имеет возможность печатать посадочный талон с конкретным форматом или размером либо согласно листу или таблице с конкретным стилем. Например, принтер посадочных талонов может печатать посадочный талон с использованием РЕСТАВ-языка управления печатью. При этом, данные, которые должны печататься на посадочном талоне, форматируются согласно одной или более таблицам.

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

Конфигурация рабочих станций и ассоциированных периферийных устройств

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

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

После того, как рабочая станция или портативное устройство запущено на этапе ЗОЮ, инженер-установщик запускает браузер и вводит NGP URL-адрес для того, чтобы соединяться с NGP-порталом. Установщик обычно должен вводить учетные данные системы безопасности, чтобы начинать процесс установки. NGP-портал предоставляет интуитивный GUI, чтобы направлять установщика таким образом, чтобы соединять и конфигурировать периферийные устройства. Этот процесс автоматически устанавливает и конфигурирует все необходимое программное обеспечение на рабочей станции на основе идентификатора местоположения, предоставленного установщиком на этапе ЗОН. Обычно, GUI NGP-портала установки требует от установщика тестировать все периферийные устройства для проверки достоверности успешной установки. Периферийные устройства, в принципе, могут представлять собой любое совместно используемое устройство 108, такое как принтер посадочных талонов или принтер багажных бирок.

Пользователь затем вводит конкретный URL-адрес в браузере, выполняющемся на пользовательском устройстве 107, чтобы осуществлять доступ к NGP-системе. Обычно, каждая авиакомпания имеет различный URL-адрес, чтобы осуществлять доступ к системе.

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

Нижеприведенное описание предполагает то, что пользователь предварительно создает учетную запись с NGP-системой таким образом, что пользователь имеет имя пользователя и пароль, сохраненные в системе, которая предоставляет доступ к системе. Дополнительно, оно также предполагает то, что устройство 107 оснащено браузером для того, чтобы соединяться с NGP-порталом, который предоставляет доступ к API-окружению. Обычно, термин "API-окружение 103" используется наравне с термином "NGP-портал" или "система". Оно также предполагает то, что одно или более периферийных устройств, таких как принтер багажных бирок или принтер посадочных талонов, сконфигурированы так, как описано выше.

Решение для портативных устройств

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

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

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

Идентификатор (идентификатор) местоположения связывает или ассоциирует 2 канала 12 4, 12 5. Он информирует платформу в отношении того, с каким принтером в локальном окружении 107 аэропорта должно обмениваться данными приложение 141, 143, 145 в удаленном окружении.

Когда пользователь входит в учетную запись из планшетного компьютера или другого устройства 107, предварительно определенный идентификатор местоположения отправляется в API-окружение 103. Альтернативно, когда пользователь входит в учетную запись, он может вручную выбирать свое местоположение. Местоположение может определяться с использованием радиомаяка либо с использованием связи ближнего радиуса действия (NFC) или QR-метки, как указано выше. Таким образом, агенты авиакомпании могут приносить собственные планшетные компьютеры и просто приближаться к стойкам в аэропорту, киоскам, местам приема багажа и другим местоположениям, чтобы выполнять функции регистрации и посадки.

Планшетный компьютер может быть ассоциирован с одним из устройств на стойках (например, в киоске или в месте приема багажа) с использованием, например, радиомаяка или NFC. Это обеспечивает возможность устройству принимать идентификатор (идентификатор) местоположения и, для портативного устройства, передавать идентификатор местоположения в API-окружение 103.

Таким образом, пользователь может приносить портативное вычислительное устройство 107 в локальное окружение 105 аэропорта, чтобы осуществлять доступ к API-окружению 103.

Пользователь запускает на устройстве 107 приложение, которое обнаруживает радиомаяк 110, который является близлежащим к пользователю, с использованием протоколов беспроводной связи, таких как NFC, чтобы обнаруживать идентификатор радиомаяка, к примеру, UUID.

Приложение, выполняющееся на пользовательском устройстве 107, может отправлять в беспроводном режиме запрос в поисковый API 106, расположенный в API-окружении. Запрос включает в себя UUID, и запрос включает в себя команду, которая инструктирует API 106 выполнять поиск в базе 104 данных на предмет идентификаторов радиомаяков, сохраненные в базе данных, которые совпадают с идентификатором радиомаяка, обнаруженным посредством API, выполняющегося на пользовательском устройстве 107.

После того, как API 107 определяет совпадение между UUID-идентификатором, ассоциированным с обнаруженным радиомаяком, и идентификатором радиомаяка, сохраненным в базе данных, далее API 106 выполняет поиск в базе данных на предмет данных местоположения или, другими словами, идентификатора (идентификатора) местоположения, ассоциированного с совпадающим идентификатором радиомаяка, сохраненным в базе данных. Ниже подробнее описывается конкретный формат идентификатора (идентификатора) местоположения.

Решение для стационарной стойки

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

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

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

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

3. NGP-система затем может динамически компоновать меню со значками приложений, которое отображается пользователю, при этом каждый значок представляет собой URL-адрес, ассоциированный с внутренними интерфейсными службами 141, 143, 145 на основе приложений авиакомпании. URL-адрес имеет три ассоциированных параметра: LocationID, UserSessionID и NGP URL.

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

Подробные этапы и сообщения последовательности операций

Если не указано иное, различные функциональные компоненты, показанные на фиг. 1 и 3, могут реализовываться с использованием API-вызова, такого как API-вызов с передачей репрезентативного состояния (REST) с использованием HTTP-протокола.

Таким образом, данные в рамках сообщений, показанных на фиг. 3, обычно имеют формат буквенно-цифровой строки и ассоциированного поля, задающего тип данных, который также может иметь формат буквенно-цифровой строки. Дополнительно, различные функциональные компоненты, показанные в API-окружении 103 и окружении 109 приложений, могут реализовываться как различные модули, которые соединяются друг с другом, чтобы обмениваться данными по мере необходимости между различными модулями.

Обращаясь теперь еще раз к блок-схеме последовательности операций способа по фиг. 3, пользователю указывается вводить имя пользователя или идентификатор пользователя и пароль (UserLogin), чтобы входить в учетную запись в NGP-системе. Сообщение 3012 входа пользователя в учетную запись в силу этого отправляется из пользовательского устройства 107 в API-окружение 103. Окно входа пользователя в учетную запись обычно отображается в ответ на ввод, пользователем, конкретного URL-адреса в браузере, как описано выше.

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

Чтобы осуществлять доступ к конкретному URL-адресу, пользовательскому устройству может предоставляться сертификат безопасности. Сертификат безопасности может предоставляться по отдельному каналу, и сертификат может аннулироваться в любой точке. Доступ к NGP-системе обычно не предоставляется, если не предоставлен соответствующий сертификат безопасности.

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

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

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

Если мобильное устройство считывает идентификатор радиомаяка, идентификатор радиомаяка отправляется в API-окружение из пользовательского устройства 107 через проводное или беспроводное соединение. Затем приложение 106 выполняет поиск в базе 104 данных, чтобы находить идентификатор радиомаяка, соответствующий или совпадающий с идентификатором радиомаяка, считываемым из радиомаяка 110. API 106 затем определяет идентификатор местоположения, сохраненный в базе 104 данных, который ассоциирован с идентификатором местоположения, совпадающим с радиомаяком. Таким образом, API 106 имеет возможность определять идентификатор местоположения, ассоциированный с радиомаяком. Обычно, все функциональные компоненты, показанные на фиг. 1 из чертежей, имеют возможность осуществлять доступ к идентификатору (ID) местоположения, ассоциированному с конкретным идентификатором радиомаяка, при необходимости. Определенный идентификатор местоположения затем может передаваться обратно в пользовательское устройство 107.

Таким образом, NGP-система и обычно API 10 6, выполняющий окружение приложений, принимают идентификатор местоположения из стационарной рабочей станции, или API 10 6, выполняющийся в API-окружении 103, определяет идентификатор местоположения посредством выполнения поиска в базе 104 данных на предмет идентификатора местоположения, который совпадает с конкретным идентификатором радиомаяка. Это обычно выполняется в ответ на прием, посредством API 106, идентификатора радиомаяка из пользовательского устройства 107.

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

После того как пользователь успешно входит в учетную запись в API-окружении 103, на этапе 3012, сообщение 3013 о событии входа в учетную запись отправляется из интерфейса 114 предоставления служб аутентификации в NGP-портале в API 301 оболочки CUTE. Обычно, сообщение 3013 о событии входа в учетную запись содержит местоположение идентификации пользователя данных в форме идентификатора местоположения и идентификатора пользовательского сеанса, называемого "user_session_ID". Идентификатор пользовательского сеанса может формироваться посредством API 114 предоставления служб аутентификации. Специалистам в данной области техники должно быть известно, что идентификатор пользовательского сеанса идентифицирует пользовательский сеанс и может представлять собой буквенно-цифровую строку.

Сообщение о событии входа в учетную запись может содержать необязательный идентификатор авиакомпании или идентификатор (идентификатор) группы пользователей. Также может использоваться идентификатор региона, такой как "США", "восточное побережье США", "западное побережье США", "Нидерланды", "Ирландия" и "Азия". Это является полезным, если, например, несколько различных экземпляров API-окружения должны предоставляться в различных местоположениях, и в силу этого обеспечивает возможность предоставления глобального решения. Данные в сообщении о событии могут иметь формат буквенно-цифровой строки.

В одном конкретном примере, user_session_ID включает данные, задающие пользователя, и данные, задающие ассоциирование или группу, с которой ассоциирован пользователь. Например, данные, задающие ассоциирование, могут представлять собой строку, такую как "ВА" или "АА", которая может задавать авиакомпанию как "British Airways™" или "American Airlines™", соответственно. Другие ассоциирования, например, такие как ассоциирования между наземными операторами, могут связываться с пользователем. Обычно, URL-адрес, используемый для того, чтобы осуществлять доступ к NGP-системе, используется для того, чтобы преобразовывать, ассоциировать или предоставлять соединение между идентификатором местоположения, идентификатором пользовательского сеанса и идентификатором авиакомпании.

На этапе 3014, пользователю предоставляется меню, называемое "меню приложения", на основе учетных данных защиты при входе в учетную запись и определенного идентификатора местоположения. Это может осуществляться посредством отправки, посредством одного из API в API-окружении 103 (к примеру, API 114 предоставления служб аутентификации), вызова в пользовательское устройство 107. Обычно, меню приложения предоставляется в качестве URL-адреса (который может представлять собой буквенно-цифровую строку), который указывает на соответствующий URL-адрес приложения 141, 143, 145 в окружении 109 удаленных приложений авиакомпании. Таким образом, меню может предоставлять функциональность, которая обеспечивает возможность пользователю выполнять одну или более различных функций, с использованием пользовательского устройства, в конкретном локальном окружении аэропорта. Два конкретных примера функций, которые могут выполняться пользователем с использованием пользовательских устройств в локальном окружении 105 аэропорта, могут представлять собой печать багажной бирки или посадочного талона с использованием одного или более совместно используемых устройств 108.

Таким образом, с использованием одного из пользовательских устройств 107, пользователь имеет возможность щелкать один из пунктов меню, и это обеспечивает возможность подключения к приложению в удаленном окружении авиакомпании. CITRIX™-приложение может использоваться для того, чтобы выполнять этот этап, хотя другие приложения могут использоваться для того, чтобы удаленно запускать одно из приложений 141, 143, 145 из одного из устройств 107 в локальном окружении 105 аэропорта.

Этап отображения меню позиций и функциональность для того, чтобы обеспечивать возможность удаленного запуска одного из приложений 141, 143, 145, может выполняться с использованием приложения в API-окружении 103 (например, с использованием одного из API 111), которое может упоминаться как портальное NGP-приложение, чтобы выполнять поиск в базе 112 данных сохраненных предварительно сконфигурированных настроек, задающих типы приложений, доступных для пользователя в конкретном местоположении. Это приложение может сначала аутентифицировать пользователя и затем определять то, какие приложения должны быть доступны для пользователя при входе в учетную запись с использованием клиентского устройства 107 в конкретном локальном окружении 105.

Таким образом, портальное NGP-приложение 103 имеет возможность определять то, какие приложения предварительно сконфигурированы для этого пользователя, на основе местоположения. Аналогичным образом, авиакомпания может удалять приложения для пользователя на основе идентификатора и местоположения пользователя.

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

Авиакомпания может конфигурировать требуемые приложения 141, 143, 145, которые доступны для конкретного пользователя в конкретном местоположении, посредством входа в учетную запись на конфигурационном портале 115. База 112 данных, ассоциированная с API 115 конфигурационного портала, может сохранять настройки, которые задают тип приложения, которое конкретный пользователь, идентифицированный посредством их идентификатора пользователя, имеет доступным при входе в учетную запись в этом конкретном местоположении. Например, пользователь может иметь приложения для печати посадочного талона или печати багажной бирки, выполненные с возможностью быть доступными, когда он входит в учетную запись. Это может выполняться на основе идентификатора и местоположения пользователя.

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

Меню приложения обеспечивает возможность пользователю выбирать одно из доступных приложений 141, 143, 145 в окружении 109 удаленных приложений (LH-приложение). Это может выполняться посредством опубликованной и подписанной связи между NGP API-системой 103 и приложением 301 оболочки CUTE, показанным на фиг. 3 из чертежей.

Обычно, Приложение оболочки CUTE расположено в окружении 109 удаленных приложений, клиентское приложение 301 оболочки CUTE может выступать в качестве посредника между унаследованными приложениями 131, 134, 145 авиакомпании и приложениями 111 в АР I-окружении.

Одна из функций приложения 301 заключается в том, чтобы транслировать между различными используемыми протоколами. Дополнительно, приложение 301 также может транслировать команды между API-окружением 103 и окружением 109 удаленных приложений. Таким образом, Приложение 301 оболочки CUTE может быть необязательным в зависимости от типа приложения, используемого в удаленном окружении авиакомпании. Тем не менее, базовые данные, которыми обмениваются между NGP API-окружением 103 и приложением в удаленном окружении 109 авиакомпании, обычно являются идентичными независимо от того, используется или нет Приложение оболочки CUTE.

В ответ на выбор, пользователем, одного из приложений 141, 143, 145, указываемых в меню, пользовательское устройство 107 затем обменивается данными с одним из приложений 141, 143, 145 в окружении 109 удаленных приложений, чтобы запускать одно из приложений 141, 143, 145 с использованием сообщения 3015. Как указано выше, этап 3015 выполняется с использованием линии связи с приложением в удаленном окружении 109 авиакомпании. Таким образом, одно из приложений 141, 143, 145 в удаленном окружении аэропорта запускается на основе информации, принимаемой в сообщении 3015, такой как идентификатор клиента или пользователя.

Следует отметить, что обычно линия связи или сообщение 3015 не разрешает отправку каких-либо ассоциированных параметров, за исключением URL-адреса. Таким образом, на этапе 3020, когда конкретное приложение 141, 143, 145 в удаленном окружении 109 авиакомпании запускается с использованием URL-адреса, одно из удаленных приложений авиакомпании также обычно осуществляет локальный вызов в локальное CITRIX-окружение, чтобы определять идентификатор клиента, который может идентифицировать устройство 107, которое запускает конкретный пользовательский сеанс.

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

Наоборот, когда одно из приложений 141, 143, 145 в удаленном окружении 109 запускается, экземпляр приложения начинает перенаправление портов. Это обеспечивает возможность одному из приложений 141 принимать идентификатор клиента, поскольку локальное CITRIX-окружение передает идентификатор клиента в приложение 141, выполняющееся в окружении удаленных приложений. Он обычно отправляется из пользовательского устройства 107 в приложение 141 через CITRIX-интерфейс в ответ на прием, посредством пользовательского устройства 107, такого запроса из приложения или CITRIX-интерфейса в окружении 109 удаленных приложений.

Например, идентификатор клиента может идентифицировать конкретного пользователя по имени и идентифицировать тип устройства, используемого для того, чтобы запускать удаленное приложение 141, 143, 145. Таким образом, идентификатор клиента может иметь форму "NAME_TABLET_1". Клиентское или пользовательское устройство 107 передает идентификатор клиента в CITRIX-окружение (которое обычно находится в окружении удаленных приложений), например, посредством средства 129 связи. Вышеописанный вход пользователя в учетную запись обычно ассоциирован с конкретным идентификатором (идентификаторами) клиента.

На этапе 3030, приложение 141 отправляет сообщение 3030 получения списка устройств в API 301 оболочки CUTE. Сообщение со списком устройств включает в себя определенный идентификатор клиента, обычно в качестве буквенно-цифровой строки.

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

Сообщение 3030 получения списка устройств, отправленное посредством одного из приложений 141, 143, 145 в окружении удаленных приложений в API 301 оболочки CUTE, инструктирует API оболочки CUTE предоставлять список устройств, ассоциированный с конкретным приложением 141, которое запущено.

Обычно, сообщение 3030 включает в себя определенный идентификатор клиента и данные, задающие тип документа, который должен обрабатываться, такой как посадочный талон или багажная бирка. Таким образом, сообщение 3030 может содержать текст, к примеру, буквенно-цифровой текст в форме "BP" или ВТ", который указывает то, что, соответственно, должен обрабатываться посадочный талон или багажная бирка.

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

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

Чтобы выполнять преобразование, API 301 оболочки CUTE использует информацию, принимаемую в сообщении 3013 о событии входа в учетную запись. Таким образом, оболочка CUTE может использовать идентификатор местоположения и идентификатор сеанса, принимаемые в сообщении 3013, чтобы отображать принимаемый идентификатор клиента в ассоциированный идентификатор местоположения.

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

Таким образом, API 301 оболочки CUTE транслирует идентификатор клиента (который может быть ассоциирован с конкретным пользователем или устройством), принимаемый в сообщении 3030, в идентификатор местоположения (который может быть ассоциирован с конкретным пользователем или устройством).

На этапе 3040, API 301 оболочки CUTE отправляет сообщение 3040 с подпиской для определения местоположения в конфигурационный портал 115 в API-окружении 103, чтобы подписываться на конкретное местоположение через одну из API-служб 111, с использованием идентификатора местоположения, определенного посредством API 301 оболочки CUTE. Обычно сообщение с подпиской для определения местоположения содержит параметры, задающие идентификатор местоположения и идентификатор пользовательского сеанса.

API-служба 115 конфигурационного портала может передавать подтверждение приема в ответ на прием сообщения 3040 с подпиской для определения местоположения, хотя это сообщение не показано на фиг. 3 вследствие его необязательного характера.

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

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

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

- Одна авиакомпания может иметь несколько пользователей или агентов, подписанных на местоположение, через приложение(я) 141, 143, 145 авиакомпании.

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

Сообщение 3040 с подпиской для определения местоположения обычно содержит идентификатор местоположения и идентификационную информацию пользовательского сеанса и необязательно параметр идентификатора аэропорта. Как описано выше, параметр идентификатора местоположения задает идентификатор местоположения используемой рабочей станции или портативного устройства 107, идентификатор пользовательского сеанса задает идентификатор сеанса вошедшего в учетную запись пользователя, идентификатор авиакомпании может задавать коды авиакомпаний, к примеру, код авиакомпании-члена IATA, и обычно задается посредством буквенно-цифровых строк. Необязательно, временная метка также может быть включена в примерное JSON-сообщение 3040 с запросом на подписку для определения местоположения, показанное ниже:

API-служба 111 в NGP API-окружении 103 принимает сообщение 3040 и обменивается данными с интерфейсом 117 предоставления служб для устройств через сообщения 131 и 132, чтобы определять конкретные устройства, ассоциированные с конкретным местоположением, а также ассоциированные характеристики каждого устройства. Информация может быть включена в сообщение, которое обеспечивает возможность ее маршрутизации в один из API 111, показанных на фиг. 1, если предоставляется более одной 1 API-службы 111.

Таким образом, API-интерфейс 117 предоставления служб для устройств и конфигурационный портал 115 обмениваются данными с одной из API-служб 111 в API-окружении 103, чтобы определять список устройств, ассоциированный с конкретным идентификатором местоположения, и их ассоциированные характеристики.

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

Характеристики устройств возвращаются в API 301 оболочки CUTE, который обычно составляет часть API-окружения 103.

API 301 оболочки CUTE транслирует принимаемые характеристики устройств в тип JSON-сообщений, показанный как 121 и 122 на фиг. 1 и сообщение 305 на фиг. 3.

Ниже показано примерное JSON-сообщение 3050 с ответом по подписке для определения местоположения:

Обычно сообщение 3050 с ответом по характеристикам устройств задает тип доступных совместно используемых устройств, таких как считыватель посадочных талонов (BPR), принтер багажных бирок (ВТР), принтер посадочных талонов (АТВ), и каждое устройство имеет ассоциированный идентификатор местоположения.

API 301 оболочки CUTE затем использует информацию, принимаемую в сообщении 3050 с ответом, чтобы формировать сообщение 3060 со списком устройств, которое задает устройства, доступные в конкретном местоположении.

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

Таким образом, приложение, выполняющееся в окружении авиакомпании перемещения 109, имеет возможность принимать список доступных устройств в удаленном местоположении. Этот список доступных устройств отправляется через средство 129 или 123 или 125 связи, например, через веб-прокси-функциональность 113 в API-окружении. Пользователь имеет возможность выбирать, с использованием пользовательского устройства 107, одно из доступных устройств для того, чтобы печатать конкретный тип документа.

В ответ на выбор, пользователем, одного из устройств для того, чтобы печатать конкретный тип документа, приложение 141 в удаленном окружении затем отправляет открытое сообщение 3070 устройства в Приложение 301 оболочки CUTE, чтобы открывать одно из устройств в списке устройств. Если только одно устройство возвращается в сообщении 3060 со списком устройств, то API 301 оболочки CUTE формирует один РМ-дескриптор, ассоциированный с требуемым устройством. Обычно, РМ-дескриптор уникально идентифицирует конкретное устройство, в течение конкретного пользовательского сеанса.

API 301 оболочки CUTE возвращает параметр PMHandle в приложение 141 в окружении 109 удаленных приложений.

Если сообщение 3060 со списком устройств идентифицирует более одного устройства 108, то обычно разный параметр РМ-дескриптора формируется для каждого отдельного устройства, и обычно каждый параметр является уникальным для конкретного сеанса.

Таким образом, каждый запрос устройства, исходящий из LH-приложения 109, управляется в качестве отдельного сеанса, который идентифицируется посредством РМ-дескриптора.

Сообщение 3070 может иметь форму XSPMOpen-вызова для каждого устройства на основе принимаемого (3060) списка конфигураций устройств. Он создает сеанс с устройством, возвращает РМ-дескриптор. Элементы вызова могут включать в себя любое одно или более из следующего:

PMRET PMENTRY XSPMOpen (PSZ DevName, PPMHANDLE, ULONG OpenOption, PSZ AirilinelD, SHORT DataWaitTime, ULONG Reserved).

API 301 оболочки CUTE обычно создает РМ-дескриптор, который может быть уникальным для конкретного сеанса. РрррРМ-дескриптор может уникально идентифицировать одно из совместно используемых устройств 108. РрррРМ-дескриптор обычно возвращается в удаленный API 109 с использованием сообщения 3080.

Сообщение 3080 обычно отправляется в ответ на XSPMOpen-вызов.

Сообщение может содержать любой один или более следующих элементов кода: PMSaveHandle, ChangedDataFlag, RequestType, Length, CRC, SequenceNumber, AppPMHandle, SaveAppBuffer, ChangedDataFlag, ActivityFlag, NotifySem, IPCHandle, AppBufferAddr, Command, PMHandle, ReturnCode, Status, LocalFlags, Version, DeviceName, AirlinelD, UserName, OpenOption, WksName, ExtStatus, DevDwnFlushTime, DataWaitTime, Reserved

CUTE-функциональность преобразования конкретного PM-дескриптора в идентификатор (идентификатор) устройства

При обработке конкретного запроса на печать, API 301 оболочки CUTE включает в себя функциональность, чтобы транслировать РМ-дескриптор, задающий конкретное устройство, которое выполнено с возможностью использовать приложение 141, в идентификатор (ID) устройства. В одном конкретном примере, идентификатор устройства может содержать определенный идентификатор местоположения и ассоциированную метку. Преобразование может выполняться посредством сравнения сохраненного РМ-дескриптора, ассоциированного с конкретным устройством, с сохраненными данными, задающими идентификатор местоположения и метку устройства.

Как указано выше, последовательности сообщений 3030, 3060, 3070, 3080 могут составлять часть одного пользовательского сеанса. Таким образом, сохраненный РМ-дескриптор(ы) обычно обновляется каждый раз, когда новый пользовательский сеанс инициируется.

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

Сообщения 3083 также являются схематическими и показывают то, как приложение, выполняющееся в удаленном окружении авиакомпании, может входить в учетную запись в системе удаленного резервирования или управления вылетами. Это является необязательным, поскольку любые пассажирские данные, такие как PNR-данные, ассоциированные с конкретным пассажиром, могут сохраняться в системе 100.

Пример печати посадочного талона или багажной бирки

Нижеприведенный пример акцентирует внимание на конкретном примере агента или пассажира с использованием приложения, выполняющегося на устройстве 107, чтобы выполнять функцию печати посадочного талона или багажной бирки в совместно используемом устройстве 108 с использованием приложения 141, 143, 145, выполняющегося в окружении 109 удаленных приложений, которое обменивается данными с локальным окружением 105 аэропорта через API-окружение 103.

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

Эта информация обеспечивает возможность системе 102 резервирования или управления вылетами (DCS) уникально идентифицировать бронирование пассажира и идентифицировать данные, которые следует отправлять обратно в приложение 141, 143 или 14 5.

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

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

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

Дополнительно, если пассажир регистрирует багаж, то DCS создает идентификатор в форме регистрационного номера (LPN) для этого багажа. DCS возвращает информацию багажа, идентификатор аэропорта и номер рейса и любой ассоциированный или связанный LPN для багажа в окружение 109 приложений авиакомпании.

Таким образом, удаленное приложение 141, 143, 145 может извлекать резервирование на основе записи имени пассажира (PNR), сохраненное в базе данных. Оно обычно создается, когда создается бронирование пассажира. Поскольку большое число PNR может сохраняться в базе данных, каждая PNR идентифицируется посредством локатора записи.

Обычно, каждая PNR содержит любое одно или более из имени пассажира, сведений билета, таких как номер билета, маршрут, по меньшей мере, одного сегмента рейса и имя человека, предоставляющего информацию или выполняющего бронирование. Маршрут может задаваться посредством кода аэропорта вылета (такого как New York, NYC), кода аэропорта прибытия (такого как London Heathrow, LHR), диспетчеризованной даты и времени вылета и диспетчеризованной даты и времени прибытия.

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

Следует принимать во внимание, что багажные бирки и посадочные талоны могут задаваться в документах IATA RPS, таких как правила и RP (практические рекомендации) IATA, к примеру правила 740, а также RP1740a IATA по обработке багажных бирок и правила 722е, а также RP1723 IATA по обработке посадочных талонов.

Обычно в GUI, выполняющийся на пользовательском устройстве 107, предоставляется подтверждение того, что запись для конкретного пассажира найдена. Дополнительно, данные, извлеченные из системы 102 управления вылетами, возвращаются в одно из приложений 141 в окружении приложений. API-служба 111 предоставляет в одно из приложений 141 подтверждение того, что данные успешно приняты, и выполняет функцию маршрутизации, чтобы направлять данные в корректную службу в интерфейсе предоставления служб для устройств.

На этапе 3090, конкретное приложение 141, выбранное для использования пользователем с использованием пользовательского устройства 107, отправляет сообщение 3090 печати посадочного талона или багажной бирки. Это может осуществляться с использованием XSPMAPI-обмена сообщениями/связи. Он задает библиотеки и связь, используемую посредством унаследованных приложений.

Обычно, данные, включенные в сообщение 3090 печати посадочного талона или багажной бирки, основаны на АЕА-формате.

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

Обычно, сообщение 3090 для печати посадочного талона или багажной бирки использует устаревший протокол на основе РЕСТАВ, чтобы предоставлять макет для посадочного талона и багажной бирки. Сообщение 3090 отправляется с использованием сокетной TCP/IP-связи на основе структуры языка С.

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

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

PMRET PMENTRY XSPMWrite (PMHANDLE PMHandle, PPMDATABUFFER PPMBuf, ULONG WriteOption, HEV Semaphore, ULONG Reserved), которые должны быть известны для специалистов в данной области техники.

API оболочки CUTE затем транслирует сообщение 3090 в формат, который является подходящим для обработки посредством NGP-системы, чтобы формировать сообщение 3100.

Сообщение 3100 основано на HTML-шаблоне, данных посадочного талона или багажной бирки и шаблоне, и API 301 оболочки CUTE формирует, например, сообщение 3100 печати изображений.

Сообщение 3100 обычно основано на JSON с использованием пар ключ/значение и передается с использованием веб-API. Оболочка CUTE анализирует сообщение 3090, чтобы идентифицировать конкретные поля, к примеру, поля, задающие номер выхода или место, и имеет возможность различать между этими полями.

API 301 оболочки CUTE, показанный на фиг. 3, преобразует данные из устаревшего протокола сообщения 3090 в протокол сообщения 3100. Другими словами, API 301 оболочки CUTE транслирует сообщение 3090 в пары ключ/значение, а также может добавлять информацию, сохраненную посредством системы 103. API оболочки CUTE преобразует сообщение 3090, например, посредством использования HTML-шаблона для макета посадочного талона.

Служба 301 оболочки CUTE затем создает сообщение 3100 печати посадочного талона или багажной бирки, которое отправляется в API-окружение 103, например, с использованием JSON-сообщения. Это может рассматриваться в качестве трансляции унаследованной команды печати в новую NGP-команду печати и файл.

Ниже приводится примерный формат сообщения 3100 печати BP/ВТ:

PrintDocumentRQ:

Таким образом, следует принимать во внимание, что сообщение 3100, сформированное посредством API оболочки CUTE, может содержать идентификатор (идентификатор) местоположения

(Locationld) и метку устройства. Как описано выше, идентификатор местоположения может содержать буквенно-цифровые данные, такие как "LAX-Tl-GateB21-WKS-001" или "JFK-T01-GATE03-WKS-002". В примерном сообщении 3100 печати, показанном выше, метка устройства включена в поле "локатора". Из этого можно видеть, что совместно используемое устройство-принтер 108 фактически представляет собой принтер багажных бирок (ВТР). Тем не менее, отдельное поле метки устройства и ассоциированное значение могут предоставляться в сообщении 3100, например, в качестве пар ключ/значение. Дополнительно, сообщение 3100 может содержать любое одно или более из полей, показанных в вышеуказанных сообщениях, например, любые из данных, требуемых для того, чтобы печатать багажную бирку или посадочный талон.

Ниже приведено примерное сообщение 3130 подтверждения печати документа. Сообщение 3130 подтверждения может отправляться посредством одного из приложений в API-окружении 103 в API 301 оболочки CUTE:

PrintDocumentAck:

Ниже показано примерное сообщение 3110 запроса на печать документа, сформированное посредством одного из 131 API, 132, 117 в API-окружении 103. Сообщение 3110 формируется на основе информации, принимаемой в сообщении 3100 посредством одного из приложений в API-окружении 103. В примерном сообщении 3110, предоставляется уникальный идентификатор устройства, который обеспечивает возможность уникальной идентификации конкретного устройства посредством поля "DeviceId". Данные, ассоциированные с сообщением 3110 печати, также включаются ниже в качестве "CommandData" и могут включать в себя любое одно или более из данных, включенных в сообщение 3100, требуемое для того, чтобы печатать или обрабатывать рассматриваемый документ, например, печатать посадочный талон или багажную бирку. Комбинация идентификатора (ID) местоположения и метки устройства может использоваться для того, чтобы уникально идентифицировать конкретное устройство, в которое должен отправляться запрос на печать документа.

Запрос на печать документа:

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

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

Например, во время начальной настройки системы, приложение в конфигурационном портале 115 создает GUID (глобально уникальный идентификатор) или, другими словами, deviceId: "413dc6c0a03d4d6a9cd2c1=". Может предоставляться API в NGP-системе 103, который преобразует "413dc6c0a03d4d6a9cd2c1=" в идентификатор местоположения и метку устройства. Преобразование идентификатора устройства в идентификатор местоположения и метку устройства может выполняться с помощью поиска, с использованием API, данных, сохраненных в базе данных.

Примерный JSON-формат запросов с файловыми данными и конфигурацией:

Таким образом, альтернативно или в дополнение к GUID, описанному выше, комбинация идентификатора местоположения и метки устройства используется для того, чтобы уникально идентифицировать то, в какое совместно используемое устройство должно маршрутизироваться сообщение 3110 печати посадочного талона или багажной бирки. Таким образом, это сообщение задает устройство, в которое следует отправлять запрос на печать, в форме идентификатора устройства. Идентификатор местоположения и метка, такая как АТР, могут преобразовываться в конкретный идентификатор устройства.

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

Интерфейс 117 предоставления служб для устройств выбирает службу для корректных устройств, такую как печать посадочного талона или багажной бирки. Это выполняется на основе информации, задающей документ, который должен печататься. Выбранная служба в 117 затем выбирает требуемый шаблон, требуемый для того, чтобы печатать данные согласно формату, такому как посадочный талон или багажная бирка, заданный посредством РЕСТАВ-формата, и кодирует принимаемые данные согласно формату. Таким образом, AMQP-сообщение, отправленное в совместно используемое устройство, может отправляться с данными, кодированными в PDF-формате, также задающими тип документа, такой как посадочный талон или багажная бирка.

В случае унаследованных принтеров посадочных талонов и принтеров багажных бирок, необязательный полевой шлюз, показанный как FR на фиг. 1, который маршрутизирует сообщение в одно из совместно используемых обнаруженных устройств на основе идентификатора местоположения и метки устройства, такой как АТР. Сертификат также используется. Он транслирует идентификатор местоположения и метку, такую как АТР, в уникальный идентификатор устройства.

В ответ на прием сообщения 3110 с запросом на то, чтобы печатать посадочный талон или багажную бирку, совместно используемое устройство 108 может передавать необязательное сообщение 3120 подтверждения приема. Как указано выше, API 111 также может предоставлять сообщение 3130 подтверждения приема обратно в одно или более приложений 141, 143, 145, выполняющихся в совместно используемом окружении авиакомпании, касательно того, что запрос корректно принят. Сообщения подтверждений приема могут маршрутизироваться через полевой шлюз, который принимает сообщение 3130 подтверждения приема из приложения 111 в API-окружении.

Как упомянуто выше, API-служба(и) 111 выполняют функцию определения типа запроса, принимаемого из приложения 141 в окружении приложений (например, печать посадочного талона или багажной бирки), определения того, какая служба в интерфейсе 117 предоставления служб для устройств должна обрабатывать запрос.

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

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

В дополнение к печати посадочного талона и багажных бирок, другие устройства, такие как OCR, LSR, MSR и устройства для обеспечения выходов на посадку поддерживаются с использованием идентичной технологии. В этом примере, структура сообщений показана как 3150, 3160 и 3170 на фиг. 3 из чертежей.

Закрытие приложений

Агент авиакомпаний должен выходить из DCS и закрывать LH-приложение. Это должно завершать сеанс LH-приложения CITRIX со службой оболочки CUTE. Агент авиакомпании выходит из NGP, и клиентское устройство возвращается на экран входа в учетную запись. NGP-система затем публикует событие выхода из учетной записи в службу оболочки CUTE, что обеспечивает возможность службе оболочки CUTE высвобождать все ресурсы, ассоциированные с пользовательским сеансом и LH-приложением.

Подробное описание маршрутизатора 118 и протокольных AMQP-сообщений

В API-окружении 103, может предоставляться API 118 маршрутизатора. Он может выполнять функцию, аналогичную функции API-службы 111. Маршрутизатор имеет функцию анализа сообщения, принимаемого из одного из интерфейса 117 предоставления служб для устройств. Он имеет функцию маршрутизации сообщений 124 в корректное устройство 108 в локальном окружении.

Маршрутизатор 118 анализирует сообщение 124, принимаемое из интерфейса 117 предоставления служб для устройств. Это может осуществляться посредством анализа сообщения на уровне информации заголовка, который задает тип устройства. Заголовок может уникально идентифицировать то, в какое совместно используемое устройство 108 должно передаваться конкретное сообщение.

Каждое из совместно используемых устройств 108 подвергается процессу регистрации в API-окружении. В качестве части процесса регистрации, каждому устройству 108 выдается маркер. Маркер обеспечивает возможность совместно используемым устройствам 108 соединяться с облаком 119.

Маркер включен в заголовок сообщения для сообщения 124, и посредством анализа маркера, API 118 маршрутизатора может определять то, в какое устройство в локальном окружении 108 аэропорта должно отправляться сообщение.

Интерфейс 117 предоставления служб для устройств также обрабатывает информацию, принимаемую посредством сообщения 131, преобразует данные в формат PDF-сообщений. Конкретный интерфейс 117 предоставления служб для устройств преобразует принимаемые данные в формат PDF-сообщений, задающий посадочный талон или багажную бирку, заданный, например, согласно РЕСТАВ-формату.

Дополнительно, в одном конкретном примере, протокол обмена сообщениями по усовершенствованному протоколу организации очередей сообщений (AMQP) используется для того, чтобы отправлять сообщение из интерфейса 117 предоставления служб для устройств через маршрутизатор 118 и обычно также через облачный интерфейс 119 в совместно используемое устройство 108. Это подробнее описывается со ссылкой на фиг. 3 из чертежей. AMQP представляет собой открытый стандарт для передачи сообщений между приложениями. Единица данных AMQP упоминается как кадр. Девять различных кадров задаются для того, чтобы инициировать, управлять и завершать перенос сообщений. Сообщения отправляются по линии связи с использованием кадра переноса данных. Сообщения в линии связи обычно протекают только в одном направлении.

В примере, показанном на фиг. 1 из чертежей, веб-прокси-служба 113 предоставляется в API-окружении. Веб-прокси-служба обычно функционально соединяется как с окружением 109 удаленных приложений (и в силу этого с одним из приложений, к примеру, с 145 или 143 или 141 в окружении 109 приложений перемещения), так и с одним или более пользовательскими устройствами 107, показанными в локальном окружении 105 аэропорта. Веб-прокси-функциональность может предоставлять GUI-подключение к приложениям авиакомпании. Веб-прокси-служба также может предоставлять GUI-подключение к планшетному компьютеру, рабочей станции и дисплею 107 киоска в окружении аэропорта.

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

Описание интерфейса предоставления служб на основе характеристик

Также может предоставляться интерфейс предоставления служб на основе характеристик, не показанный на фиг. 1 из чертежей. Обычно, эта функциональность предоставляется в интерфейсе 117 предоставления служб для устройств. Альтернативно, интерфейс предоставления служб на основе характеристик может предоставляться в качестве отдельной API-службы, функционально соединенной с API 117 предоставления служб для устройств.

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

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

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

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

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

Интерфейс предоставления служб на основе характеристик определяет тип данных и конфигурации данных, требуемые посредством каждого из совместно используемых устройств 108. Обычно, предоставляется база 112 данных, которая сохраняет настройки характеристик и конфигурационные настройки, ассоциированные с каждым устройством.

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

Абонентские авиакомпании могут просматривать базу данных характеристик устройств и модифицировать ее через конфигурационный портал 115.

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

Определенные данные считываются из посадочного талона, такие как имя пассажира. Эти данные упоминаются как данные посадочного талона. Имя пассажира, в сочетании с любым одним или более из текущей даты и времени и кода аэропорта, может быть достаточным для одной или более внутренних интерфейсных систем, таких как система 102 управления вылетами, чтобы выполнять проверку того, что посадочный талон включает в себя данные, которые соответствуют пассажиру в базе данных записей имен пассажиров (PNR).

Если посадочный талон, отсканированный посредством агента, подтверждается, система 102 управления вылетами отправляет сообщение подтверждения посадочного талона в окружение 109 удаленных приложений. Оно принимается посредством одного из приложений 141, 143, 145 в окружении удаленных приложений и передается через 121 в API-службу 111 и затем из API-службы через 131 в интерфейс 117 предоставления служб для устройств. Интерфейс 117 предоставления служб для устройств затем передает это сообщение через 124 в совместно используемое устройство-сканер 108.

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

Именно API предоставления служб на основе характеристик, помеченный как CS на фиг. 1, получает эти данные характеристик устройств из базы данных. API предоставления служб на основе характеристик обычно расположен в службах 117 для устройств.

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

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

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

Например, предположим, что совместно используемое устройство 108 представляет собой DESCO™ VGR-устройство. Это устройство может иметь любую одну или более следующих характеристик: считывание/сканирование паспортов, считывание/сканирование посадочных талонов, считывание/сканирование кредитных или дебетовых карт или функция управления посадкой на выходе.

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

Из вышеозначенного следует принимать во внимание, что это VGR-устройство имеет 4 сконфигурированных характеристики.

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

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

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

- Сканирование или считывание посадочного талона.

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

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

- Они могут сигнализировать в агент то, что DCS подтверждает то, что выдан достоверный посадочный талон с именем и номером места конкретного пассажира.

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

В качестве второго примера, устройство может представлять собой ACCESS™ VGR-устройство. Это устройство имеет только одну характеристику, а именно, чтобы функционировать в качестве функции управления посадкой на выходе, и оно не может считывать паспорт или считывать кредитную карту. Таким образом, если конкретное приложение в окружении удаленных приложений 141, 143, 145 подписано на это устройство в конкретном местоположении, то эта одна характеристика перечислена напротив этого устройства.

Для каждого устройства, сохраняется ассоциированная с совместно используемым устройством 108 конфигурационная информация. Например, конфигурационные настройки могут быть связаны с конкретными настройками, выбранными, чтобы предоставлять аудио- или визуальное подтверждение сообщения подтверждения, к примеру, конкретный выбор относительно числа коротких писков, к примеру, 1, 2 или 3, чтобы указывать то, что посадочный талон подтверждается.

Эта конфигурационная информация передается с помощью сообщения 124. Это представляет собой отличие от известных систем, в которых такая конфигурационная информация устройств должна проходить через все функциональные компоненты посредством сообщений 125, 123, 121 и 131.

Интерфейс предоставления служб на основе характеристик предоставляет отдельные службы для устройств, заданные посредством характеристик устройств, а не марок и моделей устройств. Это абстрагирует управление устройством и любые сведения по физическим устройствам от приложения авиакомпании/аэропорта. Это заключает в себе перечисление и сегментацию огромного количества характеристик устройств и отдельное назначение базовому списку физических устройств. Таким образом, может предоставляться база данных или список характеристик устройств (которые могут развертываться в качестве одного из совместно используемых устройств 108 в окружении аэропорта). Список или база данных может сохраняться в устройстве 112 хранения данных. Аналогично, база 104 данных может сохраняться в устройстве хранения данных.

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

API 111 предоставляет регулируемый и управляемый доступ для устройств 107, 108 в аэропорту к приложениям 141, 143, 145 в удаленном окружении аэропорта 109 на основе интерфейса и конфигурационных настроек. Администраторы аэропорта могут независимо конфигурировать устройства 107, 108 и приложения 141, 143, 145 аэропорта в API конфигурационного портала, за счет этого обеспечивая их доступность для авиакомпаний, наземных операторов и других объектов, работающих в аэропорту локально или удаленно. Администраторы авиакомпаний могут независимо конфигурировать пользователей и приложения и назначать их устройствам в аэропортах, обеспечивая их немедленную работоспособность. Авиакомпании и администраторы аэропорта могут создавать дополнительных администраторов и делегировать часть или все зоны ответственности.

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

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

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

Несколько различных пользователей могут совместно использовать канал 124 передачи данных и канал 125 для графического пользовательского интерфейса (GUI), показанный на фиг. 1.

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

Разрешение обратной совместимости

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

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

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

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

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

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

Когда эти данные принимаются, они могут синтаксически анализироваться.

NGP-интерфейсы

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

Интерфейс авиакомпании/аэропорта

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

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

Описание модуля машинного обучения

В одном конкретном варианте осуществления, модуль машинного обучения или глубокого обучения может предоставляться в API-окружении 103. Модуль машинного обучения может выполнять потоковую аналитику. Он может отслеживать связь между окружением 109 удаленных приложений или локальным окружением 105 аэропорта либо и между тем, и между другим. Например, может определяться конкретное поведение, такое как число считываемых документов в форме паспорта, посредством одного из совместно используемых устройств 108, в минуту. Если число превышает предварительно определенное пороговое значение, то может предоставляться флаг. Это может обеспечивать возможность оператору анализировать поведение и определять то, должно или нет разрешаться поведение. Доступ к API-окружению может быть запрещен в ответ на определение того, что число считываний в минуту превышает пороговое значение. Аналогично, модуль машинного обучения может быть выполнен с возможностью отслеживать число считывателей или сканеров, принимающих сообщение из API-окружения. Аналогично, если это значение превышает предварительно определенное пороговое значение, то это может указывать нарушение безопасности системы. В силу этого, доступ к API-окружению 103 может быть запрещен на основе определения. Таким образом, библиотека приемлемых шаблонов поведения может формироваться для каждого совместно используемого устройства 108 и пользовательского устройства 107.

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

Платформенный интерфейс

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

Служба на основе полевого шлюза

Служба на основе полевого шлюза, показанная как FG на фиг. 1 из чертежей, загружаемый пакет обычно инициируется в ответ на соединение с конфигурационным порталом 115. В качестве части пакетной загрузки, ассоциированный сертификат безопасности также загружается с пакетом. Один идентификатор (ID) местоположения определен, как указано выше, идентификатор местоположения передается в службу на основе полевого шлюза. Служба на основе полевого шлюза соединяется с API-окружением 103. Полевой шлюз использует загруженный сертификат и ранее определенный идентификатор местоположения. Таким образом, полевой шлюз использует сертификат и определенный идентификатор местоположения для того, чтобы соединяться с конфигурационным порталом. Это обеспечивает возможность конфигурационному порталу определять конкретную конфигурацию, необходимую для устройств в этом местоположении.

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

Все метки устройств регистрируются в IoT-концентраторе, и маркер ассоциирован с каждой меткой и, в силу этого, устройством.

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

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

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

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

Далее представлено дополнительное описание того, как конкретное устройство, такое как, например, принтер посадочных талонов или багажных бирок, может уникально идентифицироваться с использованием идентификатора местоположения и метки устройства (LocationID.Device_Label). Оно имеет конкретное применение для устаревших унаследованных принтеров или устройств, которые, возможно, должны быть совместимыми с системой, способом и устройством для предоставления доступа к совместно используемой инфраструктуре или устройствам.

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

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

Пользователь затем выбирает конкретный идентификатор местоположения, который совпадает с его текущим местоположением, например, идентификатор местоположения "MUM-T1-SBD-001" может распознаваться пользователем как ассоциированный с "аэропорт Мумбаи, терминал 1, район 001 автоматического приема багажа".

Другой пример идентификатора местоположения представляет собой "JFK-T1-GATE1-WKS-001", который может распознаваться пользователем как ассоциированный с "аэропорт США, John F Kennedy, терминал 1, выход 1, рабочая станция 001".

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

Device_label может принимать форму "MSR", которая может указывать то, что устройство представляет собой считыватель магнитных карт с проведением, используемый для того, чтобы считывать карту лояльности или кредитную карту. Другие типы устройств или метки могут представлять собой ВТР, указывающую то, что устройство представляет собой принтер багажных бирок или принтер посадочных талонов, называемый "АТР (принтером для автоматической выписки билетов и посадочных талонов)", что указывает то, что устройство представляет собой принтер посадочных талонов, как описано выше.

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

Содержимое файла инициализации:

Файл инициализации может шифроваться с использованием PGP-подписи и сохраняться в Azure Blob-контейнере для хранения данных (контейнере "FglnitFile") или в средстве хранения данных, или в базе 104 данных. В этом контейнере, может быть предусмотрен субконтейнер для каждого местоположения ["FgInitFile_<LocationId>.lck"]. Этот файл обычно сохраняется и является доступным с помощью SAS-маркера со сроком истечения в 4 часа.

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

После запуска, компонент полевого шлюза выполняет поиск на предмет инициализации для файла, который может называться "FgInitFile_*.*.lck". Если компонент полевого шлюза успешно находит файл инициализации, он отправляет запрос в службу определения местоположения, которая может составлять часть API-окружения 103, чтобы получать сертификат безопасности для каждого совместно используемого устройства 108 или службы, выполняющейся на рабочей станции.

Чтобы получать сертификат безопасности, компонент или служба на основе полевого шлюза вызывает службу конфигурирования местоположения, которая может составлять часть API-окружения 103, чтобы получать сертификат.

Когда служба определения местоположения принимает запрос на сертификат безопасности, она проверяет достоверность маркера (чтобы подтверждать, например, то, что маркер является достоверным, и то, что он не истек). Служба определения местоположения также может проверять достоверность LocationId или, другими словами, проверять то, что принимаемый LocationId соответствует одному из ранее сохраненных LocationId, сохраненных в базе 104 данных.

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

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

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

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

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

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

Таким образом, следует принимать во внимание, что совместно используемые устройства взаимодействуют с платформой на IoT-протоколах, таких как протокол обмена сообщениями для телеметрической MQ-транспортировки или телеметрической транспортировки очереди сообщений (MQTT). Для обеспечения возможности означенного, существующие унаследованные устройства, которые могут не иметь интерфейсов на основе Интернета и высокоуровневых протоколов обмена сообщениями, имеют интерфейс с полевым шлюзом. Полевой шлюз реализует функциональность уровня устройств и управляет сложным взаимодействием на предмет безопасности с платформой, чтобы обеспечивать то, что верифицированные устройства начинают взаимодействовать, посредством выборки зашифрованных маркеров и их применения к связи между устройствами. Полевой шлюз также предпринимает несколько локальных действий на основе данных устройства, чтобы предоставлять скоростные возможности работы на основе предварительно определенных конфигураций.

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

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

Сервер может содержать процессор компьютера, выполняющий один или более серверных процессов для обмена данными с клиентскими устройствами. Серверные процессы содержат машиночитаемые программные инструкции для выполнения операций настоящего изобретения. Машиночитаемые программные инструкции могут представлять собой либо исходный код, либо объектный код, написанный на/в любой комбинации подходящих языков программирования, включающих в себя процедурные языки программирования, такие как С, объектные ориентируемые языки программирования, такие как С#, С++, Java, языки подготовки сценариев, языки ассемблера, инструкции машинного кода, инструкции на основе архитектуры набора инструкций (ISA) и задающие состояние данные.

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

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

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

Пользовательский интерфейс может предоставляться, например, в форме виджета, встраиваемого в веб-сайт, в качестве приложения для устройства или на выделенной посадочной веб-странице. Машиночитаемые программные инструкции для реализации графического пользовательского интерфейса могут загружаться на клиентское устройство из машиночитаемого носителя хранения данных через сеть, например, через Интернет, локальную вычислительную сеть (LAN), глобальную вычислительную сеть (WAN) и/или беспроводную сеть. Инструкции могут сохраняться на машиночитаемом носителе хранения данных в клиентском устройстве.

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

Машиночитаемые программные инструкции могут сохраняться на энергонезависимом материальном машиночитаемом носителе. Машиночитаемый носитель хранения данных может включать в себя одно или более из электронного устройства хранения данных, магнитного устройства хранения данных, оптического устройства хранения данных, электромагнитного устройства хранения данных, полупроводникового устройства хранения данных, портативного компьютерного диска, жесткого диска, оперативного запоминающего устройства (RAM), постоянного запоминающего устройства (ROM), стираемого программируемого постоянного запоминающего устройства (EPROM или флэш-памяти), статического оперативного запоминающего устройства (SRAM), портативного постоянного запоминающего устройства на компакт-дисках (CD-ROM), универсального цифрового диска (DVD), карты памяти в формате Memory Stick, гибкого диска.

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

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

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

i. определять идентификатор местоположения для пользователя;

ii. ассоциировать идентификатор местоположения с идентификатором пользователя для пользователя; и

iii. передавать (3013) идентификатор местоположения и ассоциированный идентификатор пользователя в приложение (301),

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

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

3. Система по п.1 или 2, в которой средство (103) обработки дополнительно выполнено с возможностью формировать сообщение (3013) о событии входа в учетную запись, предпочтительно в ответ на прием сообщения (3012) входа пользователя в учетную запись, при этом предпочтительно средство (103) обработки дополнительно выполнено с возможностью отправлять сообщение о событии входа пользователя в учетную запись в приложение (301).

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

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

6. Система по любому из предшествующих пунктов, дополнительно содержащая приложение (101, 111) для приема сообщения (3100), содержащего первые данные, задающие данные, которые должны обрабатываться одним из устройств (108) в ответ на запрос со стороны пользователя, и при этом предпочтительно первые данные содержат этот или какой-либо идентификатор местоположения, ассоциированный с пользователем или дополнительным пользователем.

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

8. Система по любому из предшествующих пунктов, в которой приложение (101, 111) выполнено с возможностью формировать дополнительное сообщение (3110) для обработки, по меньшей мере, некоторых из первых данных.

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

10. Система по любому из предшествующих пунктов, в которой средство (103) обработки функционально соединено с первым каналом (124) связи и вторым каналом (125) связи, при этом предпочтительно первый канал (124) связи связан или ассоциирован со вторым каналом с использованием идентификатора местоположения.

11. Система по п.10, в которой только данные, задающие документ, который должен обрабатываться, передаются по первому каналу (124) связи, и при этом предпочтительно только данные, задающие характеристики устройств, ассоциированные с упомянутыми одним или более устройствами (108), передаются по второму каналу (125) связи.

12. Система по п.10 или 11, в которой средство (103) обработки коммуникационно соединено с третьим каналом (121, 122) связи и четвертым каналом (123) связи, при этом предпочтительно третий канал (124) связи связан или ассоциирован с четвертым каналом связи с использованием идентификатора местоположения.

13. Система по п.12, в которой только данные, задающие документ, который должен обрабатываться, передаются по третьему каналу (121, 122) связи, при этом предпочтительно только данные, задающие характеристики устройств, ассоциированные с упомянутыми одним или более устройствами (108), передаются по четвертому каналу (123) связи.

14. Система по любому из предшествующих пунктов, дополнительно содержащая модуль полевого шлюза (FG) или приложение для уникальной идентификации одного из множества устройств (108) на основе идентификатора местоположения и метки устройства, ассоциированной с устройством, причем предпочтительно идентификатор местоположения и метка устройства предоставляются в конкатенированном поле в сообщении (3100), при этом предпочтительно система дополнительно содержит модуль или приложение (117, 118) для уникального определения того, в какое из множества устройств (108) следует отправлять сообщение (3110), на основе уникального идентификатора устройства, ассоциированного с каждым устройством, причем предпочтительно система дополнительно содержит одно или более устройств (108) для обработки данных или документа, причем предпочтительно документ представляет собой посадочный талон или багажную бирку, и при этом предпочтительно эти одно или более устройств (108) дополнительно выполнены с возможностью печатать или считывать данные или документ.

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

i. определяют идентификатор местоположения для пользователя;

ii. ассоциируют идентификатор местоположения с идентификатором пользователя для пользователя; и

iii. передают (3013) идентификатор местоположения и ассоциированный идентификатор пользователя в приложение (301),

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

16. Способ обработки данных по п.15, дополнительно содержащий этапы, на которых:

принимают сообщение (3012) о событии входа пользователя в учетную запись, ассоциированное с пользователем, и

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

17. Способ обработки данных по п.15 или 16, дополнительно содержащий этапы, на которых:

формируют сообщение (3013) о событии входа в учетную запись в ответ на прием сообщения (3012) входа пользователя в учетную запись, и

отправляют сообщение о событии входа пользователя в учетную запись в приложение (301).

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

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

20. Способ обработки данных по любому одному из пп.15-19, дополнительно содержащий этап, на котором принимают посредством приложения (101, 111) сообщение (3100), содержащее первые данные, задающие данные, которые должны обрабатываться одним из устройств (108) в ответ на запрос со стороны пользователя, и при этом предпочтительно первые данные содержат этот или какой-либо идентификатор местоположения, ассоциированный с пользователем или дополнительным пользователем.

21. Способ обработки данных по п.20, в котором первые данные дополнительно содержат любое одно или более из метки устройства, ассоциированной с идентификатором местоположения, причем предпочтительно первые данные содержат дополнительный идентификатор местоположения, конкатенированный с меткой устройства, причем предпочтительно первые данные ассоциированы с идентификатором пользовательского сеанса, при этом предпочтительно первые данные содержат данные, задающие документ, который должен обрабатываться одним из устройств (108), причем предпочтительно первые данные содержат идентификатор местоположения, ассоциированный с пользователем или дополнительным пользователем, причем предпочтительно первые данные содержат данные, задающие посадочный талон или багажную бирку, при этом приложение (101, 111) выполнено с возможностью формировать дополнительное сообщение (3110) для обработки, по меньшей мере, некоторых из первых данных.

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

23. Способ обработки данных по любому одному из пп.15-22, в котором только данные, задающие документ, который должен обрабатываться, передаются по первому каналу (124) связи, и при этом только данные, задающие характеристики устройств, ассоциированные с упомянутыми одним или более устройствами (108), передаются по второму каналу (125) связи, причем первый канал (124) связи связан или ассоциирован со вторым каналом с использованием идентификатора местоположения.

24. Способ обработки данных по п.23, в котором только данные, задающие документ, который должен обрабатываться, передаются по третьему каналу (121, 122) связи, и при этом только данные, задающие характеристики устройств, ассоциированные с упомянутыми одним или более устройствами (108), передаются по четвертому каналу (123) связи, причем третий канал (124) связи связан или ассоциирован с четвертым каналом связи с использованием идентификатора местоположения.

25. Способ обработки данных по любому одному из пп.15-24, дополнительно содержащий этапы, на которых:

уникально идентифицируют одно из множества устройств (108) на основе идентификатора местоположения и метки устройства, ассоциированной с устройством, причем идентификатор местоположения и метка устройства предоставляются в конкатенированном поле в сообщении (3100), и

уникально определяют, в какое из множества устройств (108) следует отправлять сообщение (3110), на основе уникального идентификатора устройства, ассоциированного с каждым устройством,

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

26. Машиночитаемый носитель информации, на котором сохранены машиноисполняемые инструкции, которые при их исполнении процессором в вычислительном устройстве предписывают вычислительному устройству осуществлять способ по любому одному из пп.15-25.