Система, устройство и способ обеспечения информации о пассажирах или пользователях
Изобретение относится к области информационных технологий. Техническим результатом является обеспечение возможности согласованного объединения частичных данных из различных источников в один полномочный набор данных. Система обработки данных, содержащая средство обработки, верифицирует источники данных на основании ключей; объединяет наборы данных, ассоциированные с источниками данных; определяет, уполномочен ли каждый источник данных обновлять один или более элементов данных, ассоциированных с каждым из первого, второго и третьего набора данных; если средство обработки определяет, что два или более из источников данных уполномочены обновлять один или более одинаковых элементов данных, общих для двух или более из наборов данных, осуществления арбитража между обновлениями из источников данных на основании того, какое обновление является наиболее новым по времени, или на основании весового коэффициента, ассоциированного с каждым элементом данных, причём весовой коэффициент зависит от источника данных. 3 н. и 12 з.п. ф-лы, 9 ил.
Область техники, к которой относится изобретение
Данное изобретение относится к системе, устройству, способу или компьютерной программе для обеспечения информации либо данных пассажиров или пользователей. Более конкретно, данное изобретение относится к системе, устройству и способу агрегирования данных из определенного числа других источников. Информация обычно выдается пассажиру, агенту службы безопасности, представителю авиакомпании или другому агенту в аэропорту или в другом транспортном узле, таком как железнодорожная станция или автобусная станция.
Уровень техники
В отрасли авиаперевозок, состояние рейса всегда находится в состоянии изменения, и для точной идентификации состояния рейса необходимо множество источников данных. Состояние рейса может включать в себя:
– время вылета/прибытия по расписанию,
– оцененное и фактическое время вылета/прибытия,
– выход на посадку и терминал отправления в аэропорту,
– выход и терминал прибытия в аэропорту,
– номер багажной ленты в аэропорту прибытия,
– буквенно–цифровые данные, отображаемые на экране в аэропорту, к примеру, «задержан», «начинается посадка», «идёт посадка», «посадка закончена» и т.д.,
– тип воздушного судна и регистрационный номер.
Для любого рейса, направляющегося из аэропорта A в аэропорт B, некоторые из этих данных обеспечиваются исключительно авиакомпанией, некоторые из этих данных обеспечиваются исключительно аэропортом A, и некоторые из этих данных обеспечиваются исключительно аэропортом B. Кроме того, в обновлении этих данных могут участвовать другие организации, такие как управление воздушным движением.
Каждая авиакомпания и аэропорт обычно имеет собственную базу данных для рабочих данных о рейсах. Они не всегда являются согласованными, и это приводит к несогласованным данным, и не существует «одна версии истины». Для отрасли важно иметь один согласованный вид всех данных для всех рейсов. Без этого возникает путаница при управлении работой аэропорта, работой авиакомпании и при осуществлении связи с клиентами.
Раскрытие изобретения
Изобретение определено в прилагаемой формуле изобретения, к которой далее следует обратиться.
Варианты осуществления изобретения направлены на разрешение вышеуказанных проблем посредством создания компьютерного обрабатывающего устройства для определения, следует ли разрешить или запретить доступ к базе данных или средству хранения данных, ассоциированному с устройством, причем устройство содержит: средство приема для приема данных, в частности, информации состояния, при этом данные подписаны посредством ключа; при этом устройство содержит средство для или выполнено с возможностью определения происхождения данных посредством сравнения ключа с одним или более ключей, сохраненных в базе данных или в средстве хранения данных, для идентификации источника данных; выполнения поиска в базе данных или в средстве хранения данных, для определения одного или более правил доступа, ассоциированных с источником данных, при этом правила доступа определяют, разрешен ли или запрещен доступ для записи к базе данных или средству хранения данных для упомянутых данных. Предпочтительно устройство разрешает или запрещает доступ для записи к базе данных или средству хранения данных на основании определенного правила или правил. Обычно средство приема представляет собой приемное устройство.
Варианты осуществления изобретения направлены на разрешение вышеуказанных проблем посредством создания компьютерного обрабатывающего устройства для определения информации состояния, ассоциированной с рейсом между пунктом A отправления и пунктом B назначения, причем устройство содержит первый адаптер, выполненный с возможностью:
– определения ключа защиты и приёма первой информации состояния, ассоциированной с источником, происхождением или получателем данных. Пункт отправления, например, может представлять собой аэропорт, такой как Хитроу, Лондон, LHR, тогда как пункт назначения, например, также может представлять собой аэропорт, такой как международный аэропорт Майами.
Варианты осуществления изобретения нацелены на разрешение вышеуказанных проблем посредством создания системы для обработки данных, содержащей средство обработки, выполненное с возможностью:
– определения из первого набора данных, ассоциированного с первым источником данных, первого уникального ключа, ассоциированного с первым источником данных, при этом первый набор данных содержит множество различных первых элементов данных;
– определения из второго набора данных, ассоциированного со вторым источником данных, второго уникального ключа, ассоциированного со вторым источником данных, при этом второй набор данных содержит множество различных вторых элементов данных, при этом первый набор данных и второй набор данных совместно используют по меньшей мере один общий элемент данных, и при этом по меньшей мере некоторые первые элементы данных отличаются от вторых элементов данных. Предпочтительно первый источник данных и второй источник данных верифицируются на основании ключей. Более предпочтительно система объединяет первый набор данных и второй набор данных в агрегированный набор данных, если каждый источник данных верифицирован в качестве источника данных.
Варианты осуществления изобретения извлекают данные из базы данных, причем данные идентифицируются посредством уникального ключа. Данные в базе данных могут обновляться на основании одного или более правил разрешения на запись. Обычно предусматриваются различные правила на основании того, исходит ли информация о состоянии от аэропорта вылета или аэропорта прибытия или от авиакомпании либо ассоциирована ли она с ними. Каждый адаптер может поставлять данные в узел или обрабатывающее устройство, выполняющее смарт–контракт, который содержит код, который подписывает данные с помощью закрытого ключа.
Варианты осуществления изобретения обеспечивают ориентированную на отрасль службу информации о рейсах, которая агрегирует все данные относительно всех рейсов и рационализирует эти иногда конфликтующие данные в один набор данных для каждого рейса, а затем сохраняет их по технологии на основе распределенного реестра (DLT). Все участники системы могут управлять узлом DLT и в силу этого непрерывно иметь точные данные, реплицированные в своей системе.
Это имеет преимущество, состоящее в обеспечении полного вида рейса, а не только вида, ориентированного на один аэропорт, а также вида информации о рейсе из полномочных источников. Кроме того, с помощью смарт–контракта для объединения данных и DLT для распределения данных каждый пользователь в системе может быть уверен в том, что все пользователи просматривают одинаковую информацию.
Краткое описание чертежей
Ниже описан вариант осуществления изобретения только в качестве примера и с обращением к сопровождающим чертежам, на которых:
Фиг. 1 является принципиальной схемой основных функциональных компонентов, осуществляющих изобретение;
Фиг. 2 показывает примерную информацию состояния и источники данных;
Фиг. 3 показывает примерную информацию состояния и источники данных;
Фиг. 4 показывает примерную информацию состояния и источники данных;
Фиг. 5 показывает примерную информацию состояния и источники данных;
Фиг. 6 показывает примерную информацию состояния и источники данных;
Фиг. 7 показывает примерную информацию состояния и источники данных;
Фиг. 8 является блок–схемой, показывающей этапы, выполняемые посредством варианта осуществления изобретения; и
Фиг. 9 является блок–схемой, показывающей этапы, выполняемые посредством другого варианта осуществления изобретения.
Осуществление изобретения
Нижеприведенное описание относится к системе для использования в области авиаперевозок, но это является примерным, и также поясняются другие варианты применения изобретения. Например, система может использоваться в других туристических отраслях, таких как железнодорожная, автобусная, автомобильная, либо фактически в любой среде, в которой должна агрегироваться информация из определенного числа других источников.
Кроме того, описанные нижеприведенные варианты осуществления могут быть реализованы с использованием языка программирования на C++ с использованием, например, OpenCV–библиотеки. Тем не менее, это является примером, и могут использоваться другие языки программирования, известные специалистам в данной области техники, такие как JAVA и.xml.
Обращаясь к фиг. 1, обычно функциональные компоненты, показанные в метке 100 на фиг. 1, осуществляются в закрытом виртуальном облаке. Доступ к облаку защищается посредством имени пользователя и пароля. Обычно, облако базируется на одном или более компьютерах или серверах. Один конкретный пример облака, которое может осуществлять функциональные аспекты этого изобретения, представляет собой облако веб–служб AmazonTM или закрытое виртуальное облако. При этом могут выбираться различные диапазоны IP–адресов, могут создаваться подсети, таблицы маршрутов и могут конфигурироваться сетевые шлюзы.
Система может содержать любой один или более из одного или более адаптеров 101, 103, 105. Каждый адаптер 101, 103, 105 функционально соединяется с соответствующей базой 107, 109, 111 данных. Обычно, каждый адаптер опрашивает одну из баз данных на периодической основе, например, каждую минуту. В качестве альтернативы, базы данных могут поставлять данные в каждый адаптер 101, 103, 105.
Обычно доступ к каждой базе данных обеспечивается посредством ключа, такого как ключи 102, 104, 106 защиты API. Обычно ключи 102, 104 и 106 представляют собой одинаковые ключи, но в принципе они могут отличаться. Обычно, соединение каждого соответствующего адаптера, такого как 101, с базой 107 данных осуществляется через средство 113, 115, 117 проводной или беспроводной связи, которое должно быть известно для специалистов в данной области техники, такое как HTTPS.
Кроме того, каждый адаптер 101, 103, 105 соединён при функционировании с узлом 119, 121, 123 по технологии на основе распределенного реестра (DLT). Опять же, соединение каждого адаптера, такого как адаптер 101, с соответствующим узлом DLT обычно осуществляется через средство проводной или беспроводной связи, которое должно быть известно для специалистов в данной области техники. Обычно, доступ к каждому узлу 119, 121, 123 защищается посредством соответствующего ключа 125, 127, 129. Ключи 125, 127, 129 представляют собой открытые или закрытые ключи шифрования. Обычно каждый из ключей 125, 127, 129 отличается, и каждый из них может быть ассоциирован с конкретной авиакомпанией или аэропортом. Каждый ключ может обеспечивать возможность уникальной идентификации и/или верификации конкретной авиакомпании или аэропорта, либо другими словами, источника данных. Таким образом, каждый источник данных может определяться в качестве подлинного или аутентифицированного. Стрелки 151, 153, 155 на фиг. 1 являются схематичными стрелками, представляющими канал проводной или беспроводной связи между каждым равноправным узлом или узлом 119, 121, 123 и соответствующим адаптером 101, 103, 105. Он может определяться согласно протоколу защищенной передачи гипертекста (HTTPS).
Структура данных по стандарту информации о рейсах (FLIFO)
Элементы данных для состояния рейса являются общепринятыми, и имеется множество различных доступных стандартов. Варианты осуществления изобретения могут использовать стандарт прозрачной передачи туристических данных ACRISTM, который представляет собой стандарт, согласованный посредством соответствующих органов, таких как ACITTM, IATATM и SITATM.
Этот стандарт может содержать, либо другими словами, содержать любые один или более элементов, перечисленных ниже, и группируется посредством объекта, который может отправлять обновления этой информации. Обычно, эти данные имеют буквенно–цифровой формат с синтаксическим элементом или полем, определяющим тип данных и ассоциированное значение, обычно также в буквенно–цифровом формате или строке:
– данные авиакомпании (которые представляют собой данные, которые может определять только авиакомпания),
– обслуживающая авиакомпания,
– номер выполняемого рейса,
– маркетинговая авиакомпания(и),
– номер(а) маркетинговых рейсов,
– аэропорт вылета,
– аэропорт прибытия,
– время вылета/прибытия по расписанию,
– данные аэропорта (которые представляют собой данные, которые может определять только аэропорт),
– выход на посадку,
– выход при прибытии,
– стойка(ки) регистрации пассажиров,
– багажная лента,
– отображаемый текст FIDS («посадка», «посадка закончена», «начинается посадка», «ожидайте в зале» и т.д.),
– данные авиакомпании/аэропорта (они представляют собой элементы данных, которые может определять авиакомпания и аэропорт),
– оцененное время вылета/прибытия,
– фактическое время вылета/прибытия.
Некоторые из этих элементов данных показаны на фиг. 2–7 чертежей.
События FLIFO
Предусмотрены некоторые события в течение жизненного цикла рейса, которые могут оказывать влияние на данные информации о рейсах:
– авиакомпания публикует расписание,
– аэропорт вылета назначает стойки регистрации пассажиров, выход на посадку,
– аэропорт прибытия назначает выход при прибытии и багажную ленту.
Кроме того, любая комбинация следующих событий может оказывать влияние на информацию о рейсах:
– экипаж опаздывает на рейс или болен и требуется резервный экипаж,
– пассажиры опаздывают на посадку, и необходимо выгрузить багаж,
– затор в аэропорту вылета или прибытия,
– выход недоступен при прибытии,
– управление воздушным движением задерживает рейс.
Важно отметить, что означенное представляет собой лишь небольшую выборку типов событий, которые могут инициировать обновления состояния рейса, и что данные состояния рейса могут обновляться непрерывно в течение всего жизненного цикла рейса.
Работа системы
Далее будет описан вариант осуществления изобретения со ссылкой на вид архитектуры по фиг. 1 чертежей и блок–схемы по фиг. 8 и 9.
В схематичном виде по фиг. 1, системы AODB (рабочая база данных аэропорта/авиакомпании) содержат информацию о рейсах, известную для каждой авиакомпании/аэропорта. Кроме того, адаптеры 101, 103, 105 могут служить для соединения полномочных систем аэропорта и авиакомпании с технологией на основе распределенного реестра. Они зачастую известны как «оракул», т.е. полномочный надежный источник информации, подлежащей сохранению в DLT.
С использованием открытой или закрытой (в которой обеспечивается контролируемый доступ, например, с использованием имени пользователя и пароля) DLT или блокчейна, могут сохраняться цифровые записи (к примеру, отсканированная багажная бирка), могут передаваться цифровые активы (к примеру, трансферный рейс – трансферный багаж), и могут выполняться смарт–контракты (запись WTR, выплата PAX или счет для авиакомпании).
Эти данные могут агрегироваться через смарт–контракты, выполняющиеся в DLT. Данные могут объединяться с существующими данными (если данные уже существуют), а затем реплицируются по всем узлам в блокчейне. Маркер (или кредит) формируется для каждой участвующей авиакомпании/аэропорта, которая поставляет обновления в систему.
Получение данных
Первый или второй, или третий адаптеры выполнены с возможностью считывания одного или более синтаксических элементов, ассоциированных с первой информацией состояния или второй информацией состояния или третьей информацией состояния. Информация состояния обычно конфигурирована согласно первому формату, и адаптеры преобразуют или синтаксически анализируют синтаксические элементы во второй формат, который отличается от первого формата.
Каждый адаптер обычно является конкретным для источника данных авиакомпании или аэропорта. Каждый источник данных, который вызывает адаптер, обычно имеет различную конечную точку, различный формат данных и различный механизм для того, чтобы вызывать службу. Адаптер обычно выполнен с возможностью выполнения конкретного вызова в источник данных авиакомпании или аэропорта. Адаптер также имеет возможность синтаксически анализировать и преобразовывать данные из этого источника данных в стандартный формат данных ACRIS JSON.
В качестве примера, адаптер LHR может осуществлять вызов на основе веб–служб SOAP XML по HTTPS в конечную точку LHR. Вызов на основе веб–служб защищается посредством маркера ключей API, и этот маркер обычно добавляться в качестве части вызова на основе служб. Служба LHR возвращает информацию, ассоциированную с одним или более рейсов, в формате XML. Адаптер LHR обычно затем преобразует эти данные XML в стандартный формат данных ACRIS. Адаптер затем присваивает данным штамп с помощью ключей LHR таким образом, что смарт–контракт в блокчейне может верифицировать то, что LHR представляет собой источник этих данных. Каждый адаптер имеет собственный уникальный ключ, идентифицирующий авиакомпанию или аэропорт.
Уникальный идентификатор рейса
В зависимости от конкретного числа рейсов, выполняющихся из пункта отправления или в пункт назначения, рейс может уникально идентифицироваться посредством добавления в конец любого одного или более следующих полей:
– дата вылета по расписанию, которая может представляться посредством синтаксического элемента «originDate»,
– аэропорт вылета, который может представляться посредством синтаксического элемента «departureAirport»,
– обслуживающая авиакомпания, которая может представляться посредством синтаксического элемента «operatingAirline.iataCode»,
– номер выполняемого рейса, который может представляться посредством синтаксического элемента «flightNumber.trackNumber».
Например, идентификатор «2017–04–01LHRBA0122» идентифицирует рейс 122 BA из LHR, вылетающий 01.04.2017. В другом примере, буквенно–цифровая строка «2017–05–05LHRBA0734» может уникально идентифицировать рейс номер 0734, вылетающий из Хитроу, Лондон 05 мая 2017 года, который обслуживается компанией British Airways. Таким образом, ключ может определяться посредством данных, определяющих аэропорт вылета или пункт отправления рейса, и предпочтительно данных, определяющих дату вылета, ассоциированную с рейсом, и дополнительно предпочтительно данных, определяющих оператора или поставщика рейса, а также факультативный номер рейса.
Это известно как уникальный ключ для рейса, хотя уникальный ключ не показан на фиг. 1. Когда один из адаптеров 101, 103, 105 поставляет рейс в блокчейн, варианты осуществления изобретения могут обеспечивать функциональность в компьютере, на сервере или в системе для формирования уникального ключа для рейса и выполнения поиска в блокчейне на предмет совпадающего рейса. Эта функциональность может реализовываться посредством любого из функциональных компонентов, показанных на фиг. 1. Если рейс не существует, то данные ACRIS публикуются как есть в блокчейне, и создается запись нового рейса. Если рейс существует, то данные рейса извлекаются из блокчейна, и начинается процесс объединения данных.
Описание процесса объединения
Как отмечено выше, каждый объект в системе (авиакомпания, аэропорт вылета, аэропорт прибытия) имеет только частичный вид данных, и информация из каждого источника должна объединяться в один вид.
Некоторые примеры
– Авиакомпания первоначально публикует расписание рейсов. Оно должно включать в себя базовую информацию, такую как аэропорт вылета/прибытия, времена вылета по расписанию и прибытия и номер рейса.
– По мере того как приближается время вылета (обычно в пределах 24 часов), аэропорт вылета должен назначить стойки регистрации пассажиров, выходы на посадку. Аэропорт прибытия также должен назначить информацию о выходах при прибытии и о багажной ленте.
– В течение жизненного цикла рейса возникает множество обновлений этой информации, отражающих изменяющиеся текущие события в обоих аэропортах и в авиакомпании (и во внешних источниках, такие как забастовки управления воздушным движением).
Компьютер, сервер или система, осуществляющие изобретение, в смарт–контракте, могут объединять частичные данные из этих различных источников в один полномочный набор данных информации о рейсах. Система обычно также применяет правила в смарт–контракте для исключения недопустимых обновлений и арбитража потенциально конфликтующих обновлений. Пример недопустимого обновления представляет собой попытку авиакомпании обновить состояние рейса для рейса, который ей не выполняется. Например, British Airways не может обновлять информацию о рейсе для рейса Ryanair.
Другой пример представляет собой попытку аэропорта обновить данные для рейса, не проходящего через этот аэропорт. В ходе рейса из Хитроу в аэропорт Дублина аэропорт Амстердама не может отправлять обновления для этого конкретного рейса. Компьютер, сервер или система, реализующие изобретение, могут реализовывать функциональность, которая обеспечивает идентификацию этих обновлений функциональностью смарт–контрактов и при необходимости предотвращает их запись в блокчейне.
Имеются другие обновления данных, которые требуют арбитража; к примеру, когда конфликтующие обновления исходят из объектов, которые уполномочены на обновление данных рейса. Например, авиакомпания и аэропорт могут в итоге получать цикл конфликтующих обновлений оцененного времени вылета: функциональность смарт–контрактов определяет, какое из них является корректным, и какое из них должно быть записано в качестве полномочного обновления в DLT. Варианты осуществления изобретения могут обеспечивать следующие функциональные решения этого:
– последнее поступление является полномочным. Он представляет собой алгоритм, который не предпринимает попытки определения корректности, а лишь определяет, что последнее обновление является самым полномочным;
– взвешенное полномочие. Этот алгоритм обеспечивает присвоение более высоких весовых коэффициентов некоторым полям в зависимости от источника. Например, информации обновления выхода от аэропорта присваивается приоритет от отношению к обновлению той же информации от авиакомпании.
Правила, реализуемые посредством одного из узлов 119, 121, 123 или шлюзов 131, 133, 135, реализованных на компьютерном обрабатывающем устройстве, могут определяться согласно любому одному или более из следующего.
1. Любой объект (авиакомпания или аэропорт) может публиковать новый рейс в блокчейне. Этот объект может публиковать все данные относительно рейса, логические правила для ограничения обновлений не должны применяться в фазе создания рейса.
2. Объект «пассажиры» должен передаваться в открытом тексте и обычно шифруется перед хранением в блокчейне и должен быть видимым только для объектов, связанных с рейсом.
3. В одном конкретном примере, следующие поля вообще не могут изменяться:
– originDate
– departureAirport
– operatingAirline
– flightNumber
– departure.scheduled
– arrival.scheduled.
4. Авиакомпания может обновлять любые поля (за исключением полей, перечисленных в пункте 3).
5. После того, как рейс создан, аэропорт вылета может обновлять любые поля, за исключением:
– полей, перечисленных № 3,
– объекта прибытия.
6. После того, как рейс создан, аэропорт прибытия может обновлять любые поля, за исключением:
– полей, перечисленных в № 3,
– объекта вылета.
Кредиты/маркеры
Предусмотрен принцип отслеживания того, какой объект (авиакомпания, аэропорт) вносит самые ценные данные для рейса. Каждый раз, когда объект поставляет допустимое обновление рейса в систему, этот объект кредитуется маркером. Это позволяет системе отслеживать, кто выполняет наибольший объем работ для поддержания данных о рейсах актуальными. В сценарии, в котором доступ к данным монетизируется, эти маркеры могут использоваться на следующем этапе для идентификации того, кому следует платить, и какая сумма должна быть выплачена этому объекту.
Отображение данных из множества источников
Нижеприведенное описание обеспечивает выборку различных источников данных, и то, как они могут объединяться согласно вариантам осуществления изобретения.
1. Нижеприведенная таблица 1 показывает примерные данные из авиакомпании. Следует обратить внимание, что эти данные не содержат информацию выхода на посадку/терминала либо любую информацию выхода/терминала при прибытии. Это обусловлено тем, что авиакомпания не управляет этой информацией, и она зачастую не назначается до приближения вылета (в пределах 24 часов). В то же время запланированная авиакомпания указывается заранее, вплоть до двенадцати месяцев.
{
"MarketingCarrierCode": "BA",
"FlightNumber": 1476,
"Sector": {
"DepartureStatus": "Estimated",
"ArrivalStatus": "Estimated",
"DepartureAirport": "GLA",
"ArrivalAirport": "LHR",
"ScheduledDepartureDateTime": "2017–04–24T10:00:00",
"ScheduledArrivalDateTime": "2017–04–24T11:30:00",
"ReportedDepartureDateTime": "2017–04–24T10:00:00",
"ReportedArrivalDateTime": "2017–04–24T11:33:00",
"OperatingCarrierCode": "BA",
"AircraftTypeCode": 319,
"MatchesRequest": true
}
}
Таблица 1. Примерные данные JSON из авиакомпании, которые могут определяться как пары ключ/значение либо синтаксические элементы и ассоциированные значения данных.
2. Нижеприведенная таблица 2 показывает примерные данные из аэропорта прибытия. Эти данные имеют формат XML (в отличие от данных JSON от авиакомпании). Кроме того, поскольку он представляет собой аэропорт прибытия, отсутствует информация относительно того, в какое время рейс вылетел (по расписанию, оцененное или фактическое). Аэропорт прибытия знает только то, когда и на какой выход/терминал должен приземляться рейс. Также следует отметить, что аэропорт имеет отличающийся тип оборудования относительно авиакомпании (319 по сравнению с 320). Это требует специальной обработки при объединении (фаза 3)
<flight>
<flightIdentifier>BA1476</flightIdentifier>
<flightNumber>1476</flightNumber>
<airlineIataRef>BA</airlineIataRef>
<aircraftEquipmentIataRef>320</aircraftEquipmentIataRef>
<origin>
<airportIataRef>GLA</airportIataRef>
</origin>
<destination>
<airportIataRef>LHR</airportIataRef>
<terminalCode>5</terminalCode>
<terminalCode>22</terminalCode>
<status code="LD" statusTime="2014–07–11:30:00.000Z">
<interpretedStatus>Landed 11:30</interpretedStatus>
<category>INFO</category>
<messages>
<message>
<text>Landed</text>
<data>11:28</data>
</message>
</messages>
</status>
<scheduledDateTime>
<UTC>2017–04–24T11:30:00.000</UTC>
<local>2017–04–24T11:30:00.000</local>
<utcOffset>0</utcOffset>
</scheduledDateTime>
</destination>
<stops count="0"/>
<isHadacabCancelled>false</isHadacabCancelled>
</flight>
Таблица 2. Примерный XML из аэропорта прибытия, который может определяться как пары ключ/значение либо синтаксические элементы и ассоциированные значения данных.
3. Нижеприведенная таблица 3 показывает результирующий объединенный набор данных. Именно стандарт данных ACRIS содержит элементы для данных прибытия и вылета. Эти данные JSON содержат объединенные данные из авиакомпании и аэропорта прибытия для этого конкретного рейса.
Помимо этого, логика объединения данных предполагает, что если имеется различие данных по определенным элементам (в этом случае, по авиационному оборудованию), данные авиакомпании получают приоритет, поскольку авиакомпания управляет используемым воздушным судном и должна вносить последнее изменение, по которому аэропорт не имеет сведений. Кроме того, данные дополнены с другими внешними наборами данных. Исходя из того, что вышеуказанные данные имеют только код IATA для авиакомпании, процесс объединения также имеет возможность выполнять поиск других стандартов оформления кода (в этом случае ICAO) и извлекать применимое название для авиакомпании. Это дополнительно повышает качество данных.
{
operatingAirline: {
iataCode: "BA",
icaoCode: "BAW",
name: "British Airways"
},
aircraftType: {
icaoCode: "A319",
modelName: "319",
registration: ""
},
flightNumber: {
airlineCode: "BA",
trackNumber: "1476"
},
departureAirport: "GLA",
arrivalAirport: "LHR",
originDate: "2017–04–24",
arrival: {
scheduled: "2017–04–24T10:30",
actual: "2017–04–24T10:30",
terminal: "5",
gate: "22",
baggageClaim: {
carousel: ""
}
},
flightStatus: "Landed",
via: []
}
Таблица 3. Примерный объединенный набор данных JSON. Он может определяться как пары ключ/значение либо синтаксические элементы и ассоциированные значения данных.
Функциональность узлов 119, 121, 123
Они обычно содержат дополнительный код или логику, выполненную с возможностью выполнения конкретной функции, такой как функциональность смарт–контракта. Обычно один или более узлов 119, 121, 123 содержат код, который определяет то, должен ли разрешаться или запрещаться запрос на запись, принимаемый из одного из адаптеров 101, 103, 105 через проводную или беспроводную защищенную линию связи, к примеру, через HTTPS. Эта функциональность может упоминаться как шлюз, шлюзовой контроллер или механизм обработки правил (не показаны на фиг. 1 чертежей), который определяет то, когда запрос на то, чтобы записывать данные в базу данных, должен разрешаться, и когда запрос на то, чтобы записывать данные в базу данных, должен запрещаться.
Каждый шлюз 131, 133, 135 может быть выполнен с возможностью выполнения следующей функциональности. Это описание варианта осуществления изобретения акцентирует внимание на функциональности одного из шлюзов 131, 133, 135. Обычно каждый узел 119, 121 и 123 адаптирует одинаковую или аналогичную функциональность для шлюза относительно функциональности, описанной ниже. Таким образом, функциональность каждого шлюза 131, 133, 135 может реализовываться в соответствующем узле 119, 121, 123.
Каждый из адаптеров 101, 103, 105 может периодически поставлять определенную информацию состояния в соответствующий узел 119, 121, 123 через линии 151, 153, 155 проводной или беспроводной связи, такие как HTTPS. Обычно это осуществляется в ответ на опрос, посредством одного из адаптеров 101, 103, 105, одной из соответствующих баз 107, 109, 111 данных, которые могут быть ассоциированы с каждым адаптером. Информационные данные состояния, поставляемые из одного из адаптеров 101, 103, 105 в один из узлов 119, 121, 123 или шлюзов 131, 133, 135, обычно шифруются с использованием одного из ключей 125, 127, 129, показанных на фиг. 1. Данные могут поставляться с использованием вызова REST API, который может включать в себя один из ключей, как описано выше. Обычно, каждый из ключей 125, 127, 129, используемых для того, чтобы подписывать данные, представляет собой открытый или закрытый ключ. Кроме того, каждый из ключей 125, 127, 129 обычно отличается. Кроме того, каждый ключ 125, 127, 129 может использоваться для идентификации источника или происхождения данных. Ключ может уникально идентифицировать происхождение или источник данных, сохраненных в базах 107, 109, 111 данных. В одном конкретном примере, каждый из адаптеров выполнен с возможностью опроса конкретной базы 107, 109, 111 данных с конкретной частотой.
Первый адаптер 101 может быть выполнен с возможностью опроса первой базы данных с первой частотой. Второй адаптер 103 может быть выполнен с возможностью опроса второй базы 109 данных со второй частотой. Третий адаптер 105 может быть выполнен с возможностью опроса третьей базы 111 данных с третьей частотой. Третья частота может быть более частой или менее частой, чем первая частота или вторая частота, в зависимости от реализации. Первая частота может соответствовать или быть практически равной второй частоте.
Каждый адаптер затем принимает информационные данные состояния из одного из источников данных. Данные могут передаваться согласно форматам данных XML или JSON, как описано выше, в каждый узел.
В ответ, каждый из узлов 119, 121, 123 или шлюзов 131, 133, 123 может формировать команду записи, которая также может отправляться в качестве части рабочих данных, запрашивающую то, что синтаксические элементы, определенные в информации состояния, должны записываться в базу данных или один из узлов 119, 121, 123. Обычно, данные периодически отправляются из каждого адаптера 101, 103, 105 в соответствующий узел 119, 121, 123, например, с частотой приблизительно в 1 минуту.
Соответственно, на этапе 801, один или более узлов 119, 121, 123 или шлюзов 119, 121, 123 принимают данные из соответствующего адаптера 101, 103, 105. Обычно, данные подписываются посредством ключа. Затем один или более узлов 119, 121, 123 или шлюзов 119, 121, 123 определяют идентификационные данные, ассоциированные с данными либо, другими словами, с происхождением данных, на этапе 803. Это может выполняться с использованием ключа.
Например, в варианте осуществления по фиг. 1, данные, сохраненные в базе 107 данных, исходят из/ассоциированы с аэропортом, таким как Хитроу, Лондон, LHR. Данные, сохраненные в базе 109 данных, исходят из/ассоциированы с авиакомпанией, такой как British AirwaysTM. Данные, сохраненные в базе 111 данных, исходят из/ассоциированы с поставщиком информационных данных состояния рейса.
Каждый узел 119, 121, 123 или шлюз 131, 133, 135 может определять идентификационные данные, ассоциированные с данными, на основании ключей 125, 127, 129, используемых посредством адаптеров для того, чтобы подписывать данные. Как подробнее описано ниже, шлюзовой контроллер блокирует или разрешает запрос на запись в узел или базу данных на основании одного или более правил, сохраненных в каждом узле. Обычно предусматривается один набор правил, и он реплицируется по каждому узлу. Тем не менее в принципе для каждого источника данных могут быть предусмотрены различные правила.
Таким образом, каждый узел 119, 121, 123 или шлюз 131, 133, 135 может определять идентификационные данные, ассоциированные с данными, из характеристик того, как подписываются данные. Поскольку каждый ключ может отличаться, каждый узел 119, 121, 123 или шлюз 131, 133, 135 имеет возможность определять то, какой ключ использован для того, чтобы подписывать данные, например, ключ, ассоциированный с British Airways, или ключ, ассоциированный с аэропортом Дублина, или ключ, ассоциированный с аэропортом Хитроу, Лондон.
После определения, обычно уникально, источника данных, каждый узел 119, 121, 123 или шлюз 131, 133, 135 выполняет поиск в другой базе данных, сохраняющей правила, определяющие, должен ли разрешаться или запрещаться запрос на т запись данных в базу данных или узел.
Ниже подробнее описываются конкретные подробные правила, сохраненные в базе данных или узлах 119, 121, 123, или шлюзах 119, 121, 123, но обычно предусматриваются различные правила в зависимости от того, ассоциирована ли информация или данные состояния с аэропортом вылета или с аэропортом прибытия или с авиакомпанией.
Правила определяют, какой из синтаксических элементов, определенных в информации состояния, принимаемой посредством одного из узлов 119, 121, 123 или шлюзов 119, 121, 123 из одного из адаптеров 101, 103, 105, может записываться или объединяться с существующими синтаксическими элементами, сохраненными в одном из узлов.
На основании определенных правил, каждый из различных синтаксических элементов и происхождения данных сверяется с правилом. Доступ для записи для обновления каждого синтаксического элемента, сохраненного в узле, разрешается или запрещается на основании правил на этапе 805.
В другом аспекте, одно или более полей или синтаксических элементов, передаваемых в/из любого из функциональных компонентов, показанных на фиг. 1, могут шифроваться.
В одном конкретном примере, синтаксические элементы или данные, ассоциированные с оцененным расписанием вылета, являются открытыми и могут подписываться с помощью открытого ключа. Таким образом, все стороны с доступом к виртуальной сети 100, показанной на фиг. 1, могут дешифровать эту информацию.
Тем не менее определенные поля или синтаксические элементы, ассоциированные с информацией состояния, могут шифроваться с помощью закрытого ключа. Например, синтаксический элемент «число пассажиров на воздушном судне» может защищаться посредством трехстороннего шифрования.
При этом конкретный вариант применения означенного может заключаться в том, что аэропорт, возможно, должен определять общее число пассажиров, прибывающих, например, для каждого рейса или за заданный период времени на конкретную дату. Кроме того, аэропорт, возможно, должен определять, сколько из этих прибывающих пассажиров требуют инвалидного кресла.
Эти данные могут обеспечиваться посредством источника авиакомпании с использованием одного из адаптеров, такого как адаптер 103, и могут быть включены в информацию состояния, извлеченную из базы 109 данных, и передаваться в узел 121, например, с использованием средства передачи или передающего устройства. Таким образом может обеспечиваться закрытый ключ или трехсторонняя блокировка, например, между аэропортом вылета, таким как Хитроу, Лондон, авиакомпанией, такой как BA, и аэропортом прибытия, таким как Дублин, так что одно или более полей или синтаксических элементов в информации состояния, извлеченной из баз 107, 109 данных, такой как число пассажиров или/и число пользователей в инвалидном кресле, являются видимыми только этим трем сторонам.
Это означает то, что даже если третья сторона должна создавать приложение для того, чтобы выполнять запрос в базу данных, сохраненную в одном из узлов, она не должна иметь возможность дешифровать конкретные синтаксические элементы или поле, поскольку они защищаются от просмотра посредством трехсторонней блокировки. Трехсторонняя блокировка или шифрование с использованием закрытого ключа определенных данных или синтаксических элементов может применяться к другим синтаксическим элементам, которые связаны с конфиденциальными данными.
Как описано выше, варианты осуществления изобретения извлекают данные рейсов из множества источников, таких как база (107) данных аэропорта, авиакомпании (109) и информация (111) о рейсах. Затем данные сохраняются в блокчейне или DLT. Данные могут представлять собой полные объекты рейса либо любой один или более из частичных элементов рейса, к примеру, любой один или более из элементов данных, показанных на фиг. 2–7.
Кроме того, может обеспечиваться интерфейс программирования, такой как API, ассоциированный с базой 111 данных, который разрешает доступ к объединенному набору данных, сохраненному в блокчейне. API может содержать функциональность, которая обеспечивает возможность определения первого ключа, ассоциированного с рейсом, на основании одного или более полей входных данных, к примеру, любого одного или более из данных, уникально идентифицирующих конкретный рейс, как пояснено выше. Это показано как этап 901 на фиг. 9 чертежей. На этапе 903, первая информация состояния, ассоциированная с первым ключом, извлекается из базы данных блокчейна или другой базы данных с использованием (уникального) ключа. API затем может извлекать любое одно или более полей данных, показанных на фиг. 2–7, из одной базы данных. Обычно, один или более элементов данных, показанных на фиг. 2–7, выводятся на монитор, на дисплей или в средство отображения пользователям системы.
В некоторых конкретных примерах, каждый из узлов 119, 121, 123 или шлюзов 119, 121, 123 может быть выполнен с возможностью шифрования некоторых полей, сохраненных в базе данных. Может использоваться алгоритм трехстороннего шифрования.
Например, поля, которые не являются высококонфиденциальными, которые могут быть связаны с общей информацией расписания прибытия или вылета, могут быть «открытыми» и не обязательно зашифрованными.
Тем не менее, некоторые данные могут сохраняться в качестве конфиденциальных данных посредством их шифрования, например, с использованием алгоритма трехстороннего шифрования.
В одном конкретном примере, предположим, что аэропорт прибытия представляет собой Дублин, и адаптер, соединенный с базой данных Дублина, пытается обновлять выход на посадку, в таком случае это обновление отклоняется, поскольку обычно только базе данных аэропорта вылета, либо другими словами, адаптеру, соединенному с базой данных аэропорта вылета, разрешается доступ для записи к базе данных, чтобы обновлять поля, для которых только аэропорт вылета является доверенным в отношении обновления. Это сохраняет целостность полей, сохраненных в блокчейне.
Таким образом, адаптеру, соединенному с базой данных аэропорта вылета, обычно разрешается обновлять только информацию, ассоциированную с вылетом, и не разрешается, например, обновлять любую информацию, ассоциированную с прибытием, или информацию, ассоциированную с пассажирским багажом.
Аналогично, адаптеру, соединенному с базой данных аэропорта прибытия, обычно разрешается обновлять только информацию, ассоциированную с прибытием, и не разрешается, например, обновлять любую информацию, ассоциированную с вылетающим рейсом.
Таким образом, различные поднаборы полей, сохраненных в базе данных, могут обновляться только посредством определенных адаптеров с данными из конкретного источника, согласно определенным правилам доступа.
Жизненный цикл рейса
Жизненный цикл рейса представляет собой начальный объект рейса и все последующие обновления рейса. Нижеприведенный пример показывает тип обновлений, которые могут выполняться посредством вариантов осуществления изобретения, согласно которым сторона обеспечивает данные. Обновления представляются в типичном порядке, в котором варианты осуществления изобретения обрабатывают данные.
Обновление № 1 на основе авиакомпании:
– авиакомпания публикует информацию о расписании рейсов (номер рейса, аэропорты вылета/прибытия, дату/время вылета/прибытия).
Обновление № 1 на основе аэропорта вылета:
– аэропорт вылета обновляет этот рейс информацией стоек регистрации пассажиров,
– аэропорт вылета обновляет этот рейс информацией терминала/выхода на посадку.
Обновление № 2 на основе авиакомпании:
– авиакомпания обновляется оцененным временем вылета.
Обновление № 1 на основе аэропорта прибытия:
– аэропорт прибытия обновляет этот рейс выходом при прибытии.
Обновление № 2 на основе аэропорта вылета:
– аэропорт вылета обновляет этот рейс фактическим временем вылета.
Обновление № 2 на основе аэропорта прибытия:
– аэропорт прибытия обновляет этот рейс фактическим временем прибытия,
– аэропорт прибытия обновляет этот рейс номером багажной ленты.
Формат данных
Данные рейсов передаются в блокчейн с использованием структуры данных ACRIS с некоторыми дополнительными полями, добавленными в этом примере.
Дополнительные поля:
– passengers – эта структура данных содержит данные относительно рейсов, которые указывают число пассажиров в каждом салоне и число пассажиров, требующих помощи с инвалидным креслом. Данные обычно должны шифроваться и быть видимыми только релевантным сторонам, а именно, авиакомпании, аэропорту вылета и аэропорту прибытия,
– flightDataChanges – эта структура данных содержит предысторию всех изменений. Она составляет часть структуры данных только для удобства, чтобы способствовать отладкой и обеспечивать легкодоступную предысторию обновлений рейса.
Любое одно или более вышеописанных полей данных могут сохраняться в базе 111 данных SITA. Обычно, предоставляется API, который обеспечивает возможность запроса базы данных таким образом, что данные дополнительных полей могут извлекаться из базы 111 данных.
Из вышеописанного, следует принимать во внимание, что варианты осуществления изобретения могут использовать блокчейн с контролируемым доступом или DLT, которая использует смарт–контракт для объединения данных и арбитража, когда имеются конфликтующие данные. Данные из систем AODB авиакомпании и аэропорта объединяются и сохраняются в блокчейне. Обычно узлы блокчейна существуют в центрах обработки данных SITA, IAG и LHR.
Фиг. 2–7 чертежей обеспечивают иллюстрацию процесса обновления базы данных или блокчейна с данными, такими как информация состояния. В этом конкретном примере, данные ассоциированы с конкретным рейсом, BA0724 из Хитроу, Лондон, LHR, в Женеву, GVA, с вылетом по расписанию в 6:45 и прибытием 9:20, причем они также показывают то, что рейс вылетел.
Фактическое время вылета показано как 6:43 из терминала 5, выхода B:38. Оцененное время прибытия 9:35 в терминале 1 показывается, и выход при прибытии еще не назначен.
На фиг. 2 показывается состояние или предыстория обновлений. Например, он показывает то, что аэропорт прибытия, GVA, пытается обновлять фактическое время и то, что это обновление не авторизовано или разрешено. Напротив, в нижней части фиг 2 показано то, что авиакомпания имеет разрешение или авторизована на то, чтобы обновлять данные с фактическим временем вылета в 6:43. Аналогично, фиг. 3–6 показывают примеры конкретных источников данных, пытающихся обновлять данные, сохраненные в базе данных, и примеры, в которых запись данных разрешена или запрещена. Фиг. 7 показывает некоторые примерные поля или синтаксические элементы.
Блок–схема последовательности операций способа по фиг. 8 и 9 иллюстрирует работу примерной реализации систем, способов и компьютерных программных продуктов согласно различным вариантам осуществления настоящего изобретения. Каждый блок на блок–схемах последовательности операций способа или блок–схемах может представлять модуль, содержащий одну или более выполняемых компьютерных инструкций или часть инструкции, для реализации логической функции, указываемой в блоке. Порядок блоков в схеме предназначен только для того, чтобы иллюстрировать пример. В альтернативных реализациях, логические функции, проиллюстрированные в конкретных блоках, могут возникать не в порядке, указанном на чертежах. Например, два блока, показанные как смежные друг с другом, могут выполняться одновременно или, в зависимости от функциональности, в обратном порядке. Каждый блок на блок–схеме последовательности операций способа может реализовываться в программном обеспечении, аппаратных средствах либо в комбинации программного обеспечения и аппаратных средств.
Из вышеописанного следует принимать во внимание, что система, устройство и способ может включать в себя вычислительное устройство, такое как настольный компьютер, переносной компьютер, планшетный компьютер, персональное цифровое устройство, мобильный телефон, смартфон.
Устройство может содержать процессор компьютера, выполняющий один или более серверных процессов для обмена данными с клиентскими устройствами. Серверные процессы содержат машиночитаемые программные инструкции для выполнения операций настоящего изобретения. Машиночитаемые программные инструкции могут представлять собой либо исходный код, либо объектный код, написанный на/в любой комбинации подходящих языков программирования, включающих в себя процедурные языки программирования, такие как C, объектные ориентируемые языки программирования, такие как C#, C++, Java, языки подготовки сценариев, языки ассемблера, инструкции машинного кода, инструкции на основе архитектуры набора инструкций (ISA) и определяющие состояние данные.
Сети проводной или беспроводной связи, описанные выше, могут представлять собой общедоступную, частную, проводную или беспроводную сеть. Сеть связи может включать в себя одно или более из локальной вычислительной сети (LAN), глобальной вычислительной сети (WAN), Интернета, системы мобильной телефонной связи или системы спутниковой связи. Сеть связи может содержать любую подходящую инфраструктуру, включающую в себя медные кабели, оптические кабели или волокна, маршрутизаторы, брандмауэры, коммутаторы, шлюзовые компьютеры и краевые серверы.
Система, описанная выше, может содержать графический пользовательский интерфейс. Варианты осуществления изобретения могут включать в себя экранный графический пользовательский интерфейс. Пользовательский интерфейс может быть предусмотрен, например, в форме виджета, встраиваемого в веб–узел, в качестве приложения для устройства или на выделенной посадочной веб–странице. Машиночитаемые программные инструкции для реализации графического пользовательского интерфейса могут загружаться на клиентское устройство из машиночитаемого носителя хранения данных через сеть, например, через Интернет, локальную вычислительную сеть (LAN), глобальную вычислительную сеть (WAN) и/или беспроводную сеть. Инструкции могут сохраняться на машиночитаемом носителе хранения данных в клиентском устройстве.
Специалисты в данной области техники должны принимать во внимание, что изобретение, описанное в данном документе, может быть осуществлено полностью или частично в качестве способа, системы обработки данных или компьютерного программного продукта, включающего в себя машиночитаемые инструкции. Соответственно, изобретение может принимать форму полностью аппаратного варианта осуществления или варианта осуществления, объединяющего программное обеспечение, аппаратные средства и любой другой подходящий подход или оборудование.
Машиночитаемые программные инструкции могут сохраняться на постоянном материальном машиночитаемом носителе. Машиночитаемый носитель хранения данных может включать в себя одно или более из электронного устройства хранения данных, магнитного устройства хранения данных, оптического устройства хранения данных, электромагнитного устройства хранения данных, полупроводникового устройства хранения данных, портативного компьютерного диска, жесткого диска, оперативного запоминающего устройства (RAM), постоянного запоминающего устройства (ROM), стираемого программируемого постоянного запоминающего устройства (EPROM или флэш–памяти), статического оперативного запоминающего устройства (SRAM), портативного постоянного запоминающего устройства на компакт–дисках (CD–ROM), универсального цифрового диска (DVD), карты памяти в формате Memory Stick, гибкого диска.
Примерные варианты осуществления изобретения могут реализовываться как схемная плата, которая может включать в себя CPU, шину, RAM, флэш–память, один или более портов для работы соединенного оборудования ввода–вывода, такого как принтеры, дисплей, клавишные панели, датчики и камеры, ROM, подсистему связи, такую как модем и среды связи. Следующие пронумерованные пункты составляют дополнительное описание изобретения.
1. Компьютерное обрабатывающее устройство (119, 121, 123, 131, 133, 135) для определения, следует ли разрешить или запретить доступ к базе данных или средству хранения данных, ассоциированному с устройством, причем устройство содержит:
a. средство приема для приема данных, в частности, информации состояния, при этом данные подписаны посредством ключа;
– при этом устройство выполнено с возможностью:
i. определения происхождения данных посредством сравнения ключа с одним или более ключей, сохраненных в базе данных или в средстве хранения данных, для идентификации источника данных;
ii. выполнения поиска в базе данных или в средстве хранения данных для определения одного или более правил доступа, ассоциированных с источником данных, при этом правила доступа определяют, разрешен ли или запрещен доступ для записи к базе данных или средству хранения данных для данных; и
iii. разрешения или запрета доступа для записи к базе данных или средству хранения данных на основании определенного правила или правил.
2. Компьютерное обрабатывающее устройство по пункту 1, в котором данные содержат множество различных полей, и при этом база данных или средство хранения данных содержит множество различных полей.
3. Компьютерное обрабатывающее устройство по пункту 2, в котором одно или более различных правил доступа предусмотрены по меньшей мере для двух или более из различных полей.
4. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором данные ассоциированы с рейсом между пунктом A отправления и пунктом B назначения.
5. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, дополнительно выполненное с возможностью разрешения или запрета доступа к поднабору полей, сохраненных в базе данных или в средстве хранения данных, на основании определенного правила или правил.
6. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, дополнительно выполненное с возможностью шифрования одного или более полей, ассоциированных с принимаемыми данными, на основании одного или более правил шифрования, сохраненных в базе данных или в средстве хранения данных, и при этом предпочтительно шифрование выполняется с использованием трехстороннего шифрования.
7. Компьютерное обрабатывающее устройство для определения информации состояния, ассоциированной с рейсом между пунктом A отправления и пунктом B назначения, причем устройство содержит:
a. первый адаптер, выполненный с возможностью:
– определения первого ключа, ассоциированного с рейсом; и
– приёма первой информации состояния, ассоциированной с первым ключом.
8. Компьютерное обрабатывающее устройство по пункту 1, при этом устройство дополнительно содержит:
a. второй адаптер, выполненный с возможностью:
i. приёма второй информации состояния, ассоциированной с первым ключом, при этом вторая информация состояния отличается от первой информации состояния.
9. Компьютерное обрабатывающее устройство по пункту 2, при этом устройство дополнительно содержит:
a. третий адаптер, выполненный с возможностью:
i. приёма третьей информации состояния, ассоциированной с первым ключом, при этом третья информация состояния отличается от первой информации состояния и второй информации состояния.
10. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором первый набор правил ассоциирован с первой информацией состояния, при этом правила определяют, какие из одного или более синтаксических элементов информации состояния рейса, сохраненных в базе данных, могут обновляться посредством первого адаптера.
11. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором второй набор правил ассоциирован со второй информацией состояния, при этом правила определяют, какие из одного или более синтаксических элементов информации состояния рейса, сохраненных в базе данных, могут обновляться посредством второго адаптера.
12. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором третий набор правил ассоциирован с третьей информацией состояния, при этом правила определяют, какие из одного или более синтаксических элементов информации состояния рейса, сохраненных в базе данных, могут обновляться посредством первого адаптера.
13. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором первый ключ разрешает доступ к базе данных, ассоциированной с авиакомпанией или аэропортом.
14. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором процессор дополнительно выполнен с возможностью выполнения вызова на основе служб в базу данных, ассоциированную с транспортным узлом, и при этом предпочтительно вызов на основе служб представляет собой вызов на основе веб–служб SOAP XML, передаваемый с использованием протокола защищенной передачи, или вызов REST API.
15. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором вызов на основе служб содержит первый ключ.
16. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором любое одно или более из первой информации состояния и второй информации состояния и третьей информации состояния содержит данные, определяющие различные аспекты информации состояния, в частности аэропорт вылета, выход на посадку, аэропорт прибытия, выход при прибытии, информацию расписания рейсов, ассоциированную с авиакомпанией, и при этом предпочтительно данные форматированы согласно буквенно–цифровому формату данных, такому как формат данных XML или JSON.
17. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором первый или второй или третий адаптеры выполнены с возможностью считывания одного или более синтаксических элементов, ассоциированных с первой информацией состояния или второй информацией состояния или третьей информацией состояния, при этом информация состояния конфигурирована согласно первому формату, и преобразования синтаксических элементов во второй формат, который отличается от первого формата.
18. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором любое одно или более из первого адаптера, второго адаптера или третьего адаптера выполнено с возможностью присвоения штампа любому одному или более из первой информации состояния, второй информации состояния и третьей информации состояния посредством первого ключа.
19. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором каждый из первого, второго или третьего адаптера 101, 103, 105 или узлов 119, 121, 123 выполнен с возможностью объединения принимаемой первой информации состояния и второй информации состояния и предпочтительно третьей информации состояния в агрегированные данные, причем агрегированные данные предпочтительно содержат буквенно–цифровой формат.
20. Компьютерное обрабатывающее устройство по пункту 1, в котором любой один или более из первого адаптера, второго адаптера или третьего адаптера дополнительно выполнен с возможностью приёма данных состояния рейса, содержащих любой один или более из синтаксических элементов, определяющих:
– время вылета или/и прибытия по расписанию;
– оцененное и фактическое время вылета/прибытия;
– выход на посадку или/и терминал, ассоциированный с аэропортом;
– выход или/и терминал при прибытии, ассоциированный с аэропортом;
– номер багажной ленты, ассоциированный с аэропортом прибытия;
– информацию состояния рейса, в частности данные, определяющие рейс как «задержан» или «начинается посадка», или «идет посадка», или «посадка закончена»; и
– тип воздушного судна и регистрационный номер.
21. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором процессор дополнительно выполнен с возможностью определения, совпадают ли любые один или более дополнительных синтаксических элементов, ассоциированных с первой информацией состояния и второй информацией состояния, и предпочтительно третьей информацией состояния, на основании сравнения синтаксических элементов.
22. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором процессор дополнительно выполнен с возможностью рационализации одного или более определенных совпадающих синтаксических элементов посредством выбора только одного из совпадающих синтаксических элементов, ассоциированных с одной из первой или второй, или третьей информации состояния рейса, и предпочтительного отбрасывания совпадающих синтаксических элементов, ассоциированных с другой информацией состояния рейса.
23. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором процессор дополнительно выполнен с возможностью передачи агрегированных данных или любой из первой информации состояния и второй информации состояния и третьей информации состояния в один или более узлов (119, 121, 123) или другое вычислительное устройство, ассоциированное с распределенным реестром, и при этом агрегированные данные или данные передаются периодически.
24. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором вычислительное устройство или другое вычислительное устройство или узел выполнены с возможностью формирования уникального ключа для рейса на основании любого одного или более из данных, определяющих дату вылета по расписанию, аэропорт вылета, обслуживающую авиакомпанию и выполняемый рейс.
25. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором другое вычислительное устройство или узел выполняет поиск в другой базе данных на предмет данных, совпадающих с уникальным ключом для рейса.
26. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором другое вычислительное устройство или узел создает запись рейса, содержащую любое одно или более из данных, определяющих расписание вылета, расписание прибытия, текущую дату, обслуживающую авиакомпанию, номер рейса, аэропорт вылета и аэропорт прибытия, и при этом предпочтительно запись рейса создается только в том случае, если база данных не содержит данные, совпадающие с уникальным ключом для рейса, и сохраняет агрегированные данные в записи рейса в базе данных.
27. Компьютерное обрабатывающее устройство по любому из предшествующих пунктов, в котором процессор дополнительно выполнен с возможностью отправки агрегированных данных на дисплей в аэропорту, при этом отображаемая информация состояния содержит данные, определяющие состояние рейса, в частности, буквенно–цифровой текст, содержащий любое одно или более из данных, определяющих рейс как «задержан», «идёт посадка» или «посадка закончена», либо должен ли пассажир, ассоциированный с рейсом, отправиться к заданному номеру выхода.
28. Способ определения информации состояния, ассоциированной с рейсом между пунктом A отправления и пунктом B назначения, при этом способ содержит этапы по любому из предшествующих пунктов.
29. Компьютерный программный продукт, который при выполнении осуществляет способ по любому из предшествующих пунктов.
30. Устройство для определения информации состояния, ассоциированной с рейсом между пунктом A отправления и пунктом B назначения, причем устройство содержит:
a. средство для определения первого ключа, ассоциированного с рейсом;
b. средство для приема первой информации состояния, ассоциированной с первым ключом.
1. Система обработки данных, содержащая средство обработки, выполненное с возможностью:
– определения из первого набора данных, ассоциированного с первым источником данных, первого уникального ключа, ассоциированного с первым источником данных, при этом первый набор данных содержит множество различных первых элементов данных;
– определения из второго набора данных, ассоциированного со вторым источником данных, второго уникального ключа, ассоциированного со вторым источником данных, при этом второй набор данных содержит множество различных вторых элементов данных, при этом первый набор данных и второй набор данных совместно используют по меньшей мере один общий элемент данных, и при этом по меньшей мере некоторые первые элементы данных отличаются от вторых элементов данных;
– верификации первого источника данных и второго источника данных на основании ключей;
– объединения первого набора данных и второго набора данных в агрегированный набор данных, если каждый источник данных верифицирован в качестве источника данных;
– определения из третьего набора данных, ассоциированного с третьим источником данных, третьего уникального ключа, ассоциированного с третьим источником данных, при этом третий набор данных содержит множество различных третьих элементов данных, при этом первый набор данных, и второй набор данных, и третий набор данных совместно используют по меньшей мере один общий элемент данных, и при этом по меньшей мере некоторые первые элементы данных отличаются от третьих элементов данных;
– верификации третьего источника данных на основании третьего ключа;
– объединения агрегированного набора данных и третьего набора данных, если третий источник данных верифицирован в качестве источника третьих данных;
- определения, уполномочен ли каждый источник данных обновлять один или более элементов данных, ассоциированных с каждым из первого набора данных и второго набора данных и третьего набора данных;
- если средство обработки определяет, что два или более из источников данных уполномочены обновлять один или более одинаковых элементов данных, общих для двух или более из наборов данных, осуществления арбитража между обновлениями из источников данных на основании того, какое обновление является наиболее новым по времени, или на основании весового коэффициента, ассоциированного с каждым элементом данных, причём весовой коэффициент зависит от источника данных.
2. Система по п. 1, дополнительно содержащая средство приема, выполненное с возможностью приёма первого набора данных из первого источника данных, и/или средство приема, выполненное с возможностью приёма второго набора данных из второго источника данных, и/или средство приема, выполненное с возможностью приёма третьего набора данных из третьего источника данных.
3. Система по одному из пп. 1 или 2, в которой каждый элемент данных содержит пару ключ/значение.
4. Система по п. 1, дополнительно содержащая определение, включают ли в себя первый набор данных и второй набор данных одинаковые элементы данных.
5. Система по п. 1, в которой, если определено, что первый набор данных и второй набор данных включают в себя одинаковые общие элементы, взвешивают значения, ассоциированные с общими элементами, на основании источника данных, ассоциированного с первым набором данных, и источника данных, ассоциированного со вторым набором данных.
6. Система по любому из пп. 1-5, дополнительно содержащая прием обновленного первого набора данных с первой частотой и прием обновленного второго набора данных со второй частотой.
7. Система по п. 6, в которой вторая частота выше первой частоты.
8. Система по любому из предшествующих пунктов, в которой первый источник данных ассоциирован с пунктом отправления рейса, и при этом второй источник данных ассоциирован с пунктом назначения рейса.
9. Система по любому из предшествующих пунктов, в которой данные ассоциированы с рейсом или полётом между пунктом отправления и пунктом назначения, причём любое одно или более из первых данных состояния, и вторых данных состояния, и третьих данных состояния содержит данные, определяющие различные аспекты информации состояния, ассоциированные с аэропортом вылета, выходом при вылете, аэропортом прибытия, выходом при прибытии, информацией расписания рейсов, ассоциированной с авиакомпанией, и при этом данные имеют формат согласно буквенно-цифровому формату данных, такому как формат данных XML или JSON, причём упомянутые данные или данные состояния содержат один или более синтаксических элементов, определяющих:
- время вылета и/или прибытия по расписанию;
- оцененное и фактическое время вылета/прибытия;
- выход на посадку и/или терминал вылета, ассоциированный с аэропортом;
- выход и/или терминал прибытия, ассоциированный с упомянутым или некоторым аэропортом;
- номер багажной ленты, ассоциированный с аэропортом прибытия;
- информацию о состоянии рейса, в частности данные, определяющие рейс как задержанный или в состоянии начала посадки, посадки или окончания посадки; и
- тип и бортовой номер воздушного судна, и
при этом упомянутый дополнительный ключ является уникальным ключом для упомянутого или какого-либо рейса, основанным на одном или более из данных, определяющих планируемый выход на посадку вылета, аэропорт вылета, обслуживающую авиакомпанию и обслуживаемый рейс, и
при этом система выполнена с возможностью формирования записи рейса, содержащей одно или более из данных, определяющих расписание вылетов, расписание прилётов, дату обслуживания, обслуживающую авиакомпанию, номер рейса, аэропорт вылета и аэропорт прибытия, и при этом запись рейса создаётся, только если упомянутая или некоторая база данных не содержит данные, совпадающие с уникальным ключом для рейса, и сохранения агрегированных данных в записи рейса в базе данных,
причём система дополнительно выполнена с возможностью отправки агрегированных данных на дисплей в аэропорту, причём отображаемая информация состояния содержит данные, определяющие состояние рейса, определённым буквенно-цифровым текстом, содержащим любое одно или более из данных, определяющих, задержан ли рейс, идёт ли посадка или заканчивается ли посадка, или то, следует ли пассажиру, ассоциированному с рейсом, пройти к заданному номеру выхода на посадку.
10. Способ обработки данных, содержащий этапы, на которых:
– определяют из первого набора данных, ассоциированного с первым источником данных, первый уникальный ключ, ассоциированный с первым источником данных, при этом первый набор данных содержит множество различных первых элементов данных;
– определяют из второго набора данных, ассоциированного со вторым источником данных, второй уникальный ключ, ассоциированный со вторым источником данных, при этом второй набор данных содержит множество различных вторых элементов данных, при этом первый набор данных и второй набор данных совместно используют по меньшей мере один общий элемент данных, и при этом по меньшей мере некоторые первые элементы данных отличаются от вторых элементов данных;
– верифицируют первый источник данных и второй источник данных на основании ключей; и
– объединяют первый набор данных и второй набор данных в агрегированный набор данных, если каждый источник данных верифицирован в качестве источника данных;
– определяют из третьего набора данных, ассоциированного с третьим источником данных, третий уникальный ключ, ассоциированный с третьим источником данных, при этом третий набор данных содержит множество различных третьих элементов данных, при этом первый набор данных, и второй набор данных, и третий набор данных совместно используют по меньшей мере один общий элемент данных, и при этом по меньшей мере некоторые первые элементы данных отличаются от третьих элементов данных;
– верифицируют третий источник данных на основании третьего ключа;
– объединяют агрегированный набор данных и третий набор данных, если третий источник данных верифицирован в качестве источника третьих данных;
- определяют, уполномочен ли каждый источник данных обновлять один или более элементов данных, ассоциированных с каждым из первого набора данных, и второго набора данных, и третьего набора данных;
- определяют, уполномочены ли два или более из источников данных обновлять один или более одинаковых элементов данных, общих для двух или более из наборов данных, осуществляют арбитраж между обновлениями из источников данных на основании того, какое обновление является наиболее новым по времени, или на основании весового коэффициента, ассоциированного с каждым элементом данных, причём весовой коэффициент зависит от источника данных.
11. Способ по п. 10, дополнительно содержащий этап, на котором принимают первый набор данных из первого источника данных, и/или принимают второй набор данных из второго источника данных, и/или принимают третий набор данных из третьего источника данных.
12. Способ по любому из пп. 10, 11, в котором каждый элемент данных содержит пару ключ/значение.
13. Способ по п. 10, в котором, если определено, что первый набор данных и второй набор данных включают в себя одинаковые общие элементы, выполняют взвешивание значений, ассоциированных с общими элементами, на основании источника данных, ассоциированного с первым набором данных, и источника данных, ассоциированного со вторым набором данных.
14. Способ по любому из пп. 10-12, дополнительно содержащий этапы, на которых принимают обновленный первый набор данных с первой частотой и принимают обновленный второй набор данных со второй частотой, и при этом вторая частота выше первой частоты, и при этом первый источник данных ассоциирован с пунктом отправления рейса, и при этом второй источник данных ассоциирован с пунктом назначения рейса.
15. Машиночитаемый носитель, на котором сохранён компьютерный программный продукт, который при выполнении осуществляет способ по любому из пп. 10-14.
