RU2772374C2 - System, device and method for providing information on passengers or users - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: data processing system containing a processing means verifies sources of key base data; combines datasets associated with data sources; determines, whether each data source is authorized to update one or more data elements associated with each of the first, the second or the third dataset. If the processing means determines that two or more of data sources are authorized to update one or more similar data elements common for two or more of datasets, arbitration is performed between updates from data sources based on which update is the newest in time, or based on a weight factor associated with each data element, wherein the weight factor depends on the data source.

EFFECT: providing the possibility of agreed combination of partial data from different sources into one authorized data set.

15 cl, 9 dwg

Description

The field of technology to which the invention belongs

This invention relates to a system, device, method or computer program for providing information or data to passengers or users. More specifically, this invention relates to a system, apparatus, and method for aggregating data from a number of other sources. The information is usually given to the passenger, a security agent, an airline representative, or another agent at an airport or other transportation hub such as a train station or bus station.

State of the art

In the airline industry, flight status is always in a state of change, and many sources of data are needed to accurately identify flight status. Flight status may include:

– scheduled departure/arrival time,

– estimated and actual time of departure/arrival,

- boarding gate and departure terminal at the airport,

– exit and arrival terminal at the airport,

– baggage carousel number at the airport of arrival,

– alphanumeric data displayed on the screen at the airport, for example, “delayed”, “boarding in progress”, “boarding in progress”, “boarding completed”, etc.,

– aircraft type and registration number.

For any flight from airport A to airport B, some of this data is provided exclusively by the airline, some of this data is provided exclusively by airport A, and some of this data is provided exclusively by airport B. In addition, other organizations may be involved in updating this data. such as air traffic control.

Each airline and airport usually has its own database for operational flight data. They are not always consistent and this results in inconsistent data and there is no "one version of the truth". It is important for the industry to have one consistent view of all data for all flights. Without this, confusion arises in the management of the operation of the airport, the operation of the airline and in communication with customers.

Disclosure of invention

The invention is defined in the appended claims, which will be referred to below.

Embodiments of the invention address the above problems by providing a computer processing device for determining whether to allow or deny access to a database or data storage medium associated with the device, the device comprising: receiving means for receiving data, in particular state information, while the data is signed by means of a key; wherein the device comprises means for or configured to determine the origin of the data by comparing the key with one or more keys stored in the database or in the data storage means to identify the source of the data; performing a search on the database or storage medium to determine one or more access rules associated with the data source, wherein the access rules determine whether write access to the database or storage medium is allowed or denied for said data. Preferably, the device allows or denies write access to the database or data storage medium based on a certain rule or rules. Typically, the receiving means is a receiving device.

Embodiments of the invention address the above problems by providing a computer processing device for determining state information associated with a flight between origin A and destination B, the device comprising a first adapter configured to:

– determining the security key and receiving the first state information associated with the source, origin or destination of the data. The point of origin, for example, may be an airport such as Heathrow, London, LHR, while the destination, for example, may also be an airport such as Miami International Airport.

Embodiments of the invention aim to solve the above problems by providing a data processing system comprising processing means configured to:

– definitions from the first data set associated with the first data source, the first unique key associated with the first data source, wherein the first data set contains a plurality of different first data elements;

– definitions from the second data set associated with the second data source, the second unique key associated with the second data source, wherein the second data set contains a plurality of different second data elements, wherein the first data set and the second data set share at least one a common data element, and wherein at least some of the first data elements are different from the second data elements. Preferably the first data source and the second data source are verified based on the keys. More preferably, the system combines the first data set and the second data set into an aggregated data set if each data source is verified as a data source.

Embodiments of the invention retrieve data from a database, the data being identified by a unique key. The data in the database may be updated based on one or more write permission rules. Typically, different rules are provided based on whether the status information originates from or is associated with an airport of departure or airport of arrival, or an airline. Each adapter can supply data to a node or processing device that executes a smart contract that contains code that signs the data with a private key.

Embodiments of the invention provide an industry oriented flight information service that aggregates all data regarding all flights and rationalizes this sometimes conflicting data into one data set per flight and then stores it using distributed ledger technology (DLT). All participants in the system can manage the DLT node and therefore continuously have accurate data replicated in their system.

This has the advantage of providing a complete view of the flight, not just a single airport view, but also a view of the flight information from authoritative sources. In addition, with the smart contract for data aggregation and DLT for data distribution, each user in the system can be sure that all users are viewing the same information.

Brief description of the drawings

An embodiment of the invention is described below by way of example only and with reference to the accompanying drawings, in which:

Fig. 1 is a schematic diagram of the main functional components implementing the invention;

Fig. 2 shows exemplary state information and data sources;

Fig. 3 shows exemplary status information and data sources;

Fig. 4 shows exemplary status information and data sources;

Fig. 5 shows exemplary status information and data sources;

Fig. 6 shows exemplary state information and data sources;

Fig. 7 shows exemplary state information and data sources;

Fig. 8 is a flowchart showing steps performed by an embodiment of the invention; and

Fig. 9 is a flowchart showing steps performed by another embodiment of the invention.

Implementation of the invention

The following description relates to a system for use in the air travel industry, but this is exemplary and other applications of the invention are also explained. For example, the system can be used in other tourism industries such as rail, bus, road, or in fact any environment that needs to aggregate information from a number of other sources.

In addition, the embodiments described below can be implemented using the C++ programming language using, for example, the OpenCV library. However, this is an example and other programming languages known to those skilled in the art such as JAVA and .xml may be used.

Referring to FIG. 1, typically the functional components shown at label 100 in FIG. 1 are carried out in a closed virtual cloud. Access to the cloud is secured with a username and password. Typically, a cloud is based on one or more computers or servers. One specific example of a cloud that can implement the functional aspects of this invention is the Amazon ^TM Web Services cloud or private virtual cloud. Various IP address ranges can be selected, subnets can be created, routing tables can be created, and network gateways can be configured.

The system may include any one or more of one or more adapters 101, 103, 105. Each adapter 101, 103, 105 is operably connected to a respective database 107, 109, 111. Typically, each adapter polls one of the databases on a periodic basis, such as every minute. Alternatively, databases may supply data to each adapter 101, 103, 105.

Typically, access to each database is provided by means of a key, such as API security keys 102, 104, 106. Usually the keys 102, 104 and 106 are the same keys, but in principle they can be different. Typically, the connection of each appropriate adapter, such as 101, to the database 107 is via wired or wireless communication means 113, 115, 117, which should be known to those skilled in the art, such as HTTPS.

In addition, each adapter 101, 103, 105 is connected in operation to the node 119, 121, 123 in a distributed ledger technology (DLT). Again, the connection of each adapter, such as adapter 101, to the corresponding DLT node is typically via a wired or wireless communication medium, which should be known to those skilled in the art. Typically, access to each node 119, 121, 123 is secured with a corresponding key 125, 127, 129. Keys 125, 127, 129 are public or private encryption keys. Typically, each of the keys 125, 127, 129 is different and each may be associated with a particular airline or airport. Each key may provide the ability to uniquely identify and/or verify a particular airline or airport, or in other words, the source of the data. Thus, each data source can be defined as genuine or authenticated. Arrows 151, 153, 155 in FIG. 1 are schematic arrows representing a wired or wireless communication channel between each peer or node 119, 121, 123 and the corresponding adapter 101, 103, 105. It may be defined according to the Hypertext Transfer Protocol Secure (HTTPS).

Flight Information Standard Data Structure (FLIFO)

The data elements for flight status are generally accepted and there are many different standards available. Embodiments of the invention may use the ACRIS ^TM transparent travel data communication standard, which is a standard agreed upon by relevant bodies such as ACIT ^TM , IATA ^TM , and SITA ^TM .

This standard may contain, or in other words contain, any one or more of the elements listed below and is grouped by an entity that can send updates to this information. Typically, this data is in alphanumeric format, with a syntax element or field specifying the data type and an associated value, usually also in alphanumeric format or a string:

– airline data (which is data that only the airline can determine),

- serving airline

- flight number

– marketing airline(s),

– number(s) of marketing flights,

- departure airport

- airport of arrival,

– scheduled departure/arrival time,

– airport data (which is data that only the airport can determine),

- boarding gate

- Exit on arrival

– check-in counter(s),

- luggage tape,

– FIDS display text (“boarding”, “boarding completed”, “boarding in progress”, “hold in the hall”, etc.),

– airline/airport data (these are data elements that the airline and airport can identify),

– estimated departure/arrival time,

– actual time of departure/arrival.

Some of these data items are shown in FIG. 2–7 drawings.

FLIFO Events

There are some events during the life cycle of a flight that can affect flight information data:

– the airline publishes the timetable,

– airport of departure designates check-in counters, boarding gates,

– airport of arrival assigns an exit upon arrival and a baggage carousel.

In addition, any combination of the following events may affect flight information:

– the crew is late for the flight or is ill and a backup crew is required,

– passengers are late for boarding and it is necessary to unload luggage,

- congestion at the airport of departure or arrival,

– the exit is not available upon arrival,

- Air traffic control delays the flight.

It is important to note that the above is only a small selection of the types of events that can trigger flight status updates, and that flight status data can be updated continuously throughout the life of a flight.

System operation

Next, an embodiment of the invention will be described with reference to the architectural view of FIG. 1 of the drawings and the block diagram of FIG. 8 and 9.

In the schematic form of Fig. 1, AODB (Airport/Airline Operational Database) systems contain flight information known for each airline/airport. In addition, adapters 101, 103, 105 may serve to connect airport and airline proxy systems with distributed ledger technology. They are often known as "oracles", ie. authoritative reliable source of information to be stored in the DLT.

Using open or closed (which provides controlled access, for example, using a username and password) DLT or blockchain, digital records can be stored (for example, a scanned baggage tag), digital assets can be transferred (for example, transfer flight - transfer baggage) and smart contracts can be executed (WTR entry, PAX payout or airline invoice).

This data can be aggregated through smart contracts running in the DLT. Data can be merged with existing data (if the data already exists) and then replicated across all nodes on the blockchain. A token (or credit) is generated for each participating airline/airport that supplies updates to the system.

Getting data

The first or second or third adapters are configured to read one or more syntax elements associated with the first state information or the second state information or the third state information. The state information is typically configured according to the first format, and the adapters convert or parse the syntax elements into a second format that is different from the first format.

Each adapter is usually specific to an airline or airport data source. Each data source that an adapter calls usually has a different endpoint, a different data format, and a different mechanism for calling the service. The adapter is typically configured to make a particular call to an airline or airport data source. The adapter also has the ability to parse and convert data from this data source into the standard ACRIS JSON data format.

As an example, an LHR adapter can make a call based on SOAP XML Web Services over HTTPS to an LHR endpoint. The web service call is secured with an API key token, and this token is usually added as part of the service call. The LHR service returns information associated with one or more flights in XML format. The LHR adapter typically then converts this XML data to the standard ACRIS data format. The adapter then stamps the data using the LHR keys so that the smart contract on the blockchain can verify that the LHR is the source of the data. Each adapter has its own unique key that identifies the airline or airport.

Unique flight identifier

Depending on the specific number of flights from origin or destination, a flight can be uniquely identified by adding any one or more of the following fields to the end:

– the scheduled departure date, which may be represented by the "originDate" syntax element,

– airport of departure, which may be represented by the syntax element "departureAirport",

– the operating airline, which may be represented by the syntax element "operatingAirline.iataCode",

– the number of the flight in progress, which may be represented by the syntax element "flightNumber.trackNumber".

For example, the identifier "2017-04-01LHRBA0122" identifies flight 122 BA from LHR departing on 04/01/2017. In another example, the alphanumeric string "2017-05-05LHRBA0734" could uniquely identify flight number 0734 departing Heathrow, London on 05 May 2017 operated by British Airways. Thus, the key may be defined by data identifying the airport of departure or origin of the flight, and preferably data identifying the departure date associated with the flight, and further preferably data identifying the operator or provider of the flight, as well as an optional flight number.

This is known as the unique key for the flight, although the unique key is not shown in FIG. 1. When one of the adapters 101, 103, 105 delivers a flight to the blockchain, embodiments of the invention may provide functionality in a computer, server, or system to generate a unique key for a flight and perform a blockchain lookup for a matching flight. This functionality may be implemented by any of the functional components shown in FIG. 1. If the flight does not exist, then the ACRIS data is published as is on the blockchain and a new flight record is created. If the flight exists, then the flight data is retrieved from the blockchain and the data merging process begins.

Description of the merging process

As noted above, each entity in the system (airline, departure airport, arrival airport) has only a partial data view, and information from each source must be combined into one view.

Some examples

– The airline initially publishes flight schedules. It should include basic information such as departure/arrival airport, scheduled departure and arrival times, and flight number.

– As the departure time approaches (usually within 24 hours), the airport of departure must designate passenger check-in counters, boarding gates. The arrival airport must also assign information on arrival gates and baggage carousels.

– There are many updates to this information over the course of a flight's life cycle, reflecting changing current events at both airports and within the airline (and external sources such as air traffic control strikes).

The computer, server, or system implementing the invention, in a smart contract, can combine partial data from these various sources into one authoritative set of flight information data. The system typically also applies rules in the smart contract to exclude invalid updates and arbitrate potentially conflicting updates. An example of an invalid update is an attempt by an airline to update the flight status for a flight that it is not operating. For example, British Airways cannot update flight information for a Ryanair flight.

Another example is an attempt by an airport to update data for a flight that does not pass through that airport. During a flight from Heathrow to Dublin Airport, Amsterdam Airport cannot send updates for that particular flight. The computer, server, or system implementing the invention may implement functionality that ensures that these updates are identified by the smart contract functionality and, if necessary, prevents them from being written to the blockchain.

There are other data updates that require arbitration; for example, when conflicting updates come from entities that are authorized to update flight data. For example, an airline and an airport may end up with a cycle of conflicting estimated departure time updates: the smart contract functionality determines which one is correct and which one should be recorded as an authoritative update in the DLT. Embodiments of the invention may provide the following functional solutions to this:

– the last entry is authoritative. It is an algorithm that does not attempt to determine correctness, but only determines that the latest update is the most authoritative;

- weighted authority. This algorithm ensures that higher weights are assigned to some fields depending on the source. For example, the exit update information from the airport is given priority over updating the same information from the airline.

The rules implemented by one of the nodes 119, 121, 123 or gateways 131, 133, 135 implemented on the computer processing device may be defined according to any one or more of the following.

1. Any entity (airline or airport) can publish a new flight on the blockchain. This object can publish all data regarding the flight, logic rules to restrict updates should not be applied in the flight creation phase.

2. The "passengers" object must be transmitted in clear text and is usually encrypted before being stored on the blockchain and must be visible only to objects associated with the flight.

3. In one specific example, the following fields cannot be changed at all:

– originDate

– departureAirport

– operating Airline

– flightNumber

– departure.scheduled

– arrival.scheduled.

4. The airline may update any fields (with the exception of the fields listed in paragraph 3).

5. After the flight is created, the departure airport can update any fields, except for:

– the fields listed No. 3,

- object of arrival.

6. After the flight is created, the arrival airport can update any fields, except for:

– the fields listed in No. 3,

– Departure object.

Credits/Tokens

There is a principle of tracking which object (airline, airport) contributes the most valuable data for a flight. Each time an entity supplies a valid flight update to the system, that entity is credited with a token. This allows the system to keep track of who is doing the most work to keep flight data up to date. In a scenario where data access is being monetized, these tokens can be used in the next step to identify who should be paid and how much should be paid to that entity.

Displaying data from multiple sources

The following description provides a selection of various data sources, and how they may be combined according to embodiments of the invention.

1. Table 1 below shows sample data from an airline. Please note that this data does not include gate/terminal information or any gate/terminal arrival information. This is because the airline does not manage this information and it is often not assigned until the departure time is close (within 24 hours). At the same time, the scheduled airline is indicated in advance, up to twelve months.

{

"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

}

}

Table 1. Example JSON data from an airline, which can be defined as key/value pairs or syntax elements and associated data values.

2. Table 2 below shows approximate data from the arrival airport. This data is in XML format (as opposed to airline JSON data). Also, since it is an arrival airport, there is no information as to what time the flight departed (scheduled, estimated, or actual). The arrival airport only knows when and at which gate/terminal the flight should land. It should also be noted that the airport has a different type of equipment relative to the airline (319 compared to 320). It requires special handling when merging (phase 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>

<stop count="0"/>

<isHadacabCancelled>false</isHadacabCancelled>

</flight>

Table 2. Sample XML from an arrival airport, which may be defined as key/value pairs or syntax elements and associated data values.

3. Table 3 below shows the resulting combined data set. It is the ACRIS data standard that contains the elements for arrival and departure data. This JSON data contains the combined data from the airline and arrival airport for that particular flight.

In addition, the data merging logic assumes that if there is a difference in data for certain elements (in this case, aircraft equipment), the airline data takes precedence, since the airline operates the aircraft in use and must make the last change for which the airport does not know. In addition, the data is complemented with other external datasets. Given that the above data only has the IATA code for the airline, the merge process also has the ability to look up other coding standards (ICAO in this case) and extract the applicable name for the airline. This further improves the quality of the data.

{

operating Airline: {

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"

baggage Claim: {

carousel: ""

}

},

flightStatus: "Landed",

via: []

}

Table 3. Sample merged JSON dataset. It can be defined as key/value pairs or syntax elements and associated data values.

Node functionality 119, 121, 123

They usually contain additional code or logic designed to perform a specific function, such as the functionality of a smart contract. Typically, one or more nodes 119, 121, 123 contain code that determines whether a write request received from one of the adapters 101, 103, 105 should be allowed or denied over a wired or wireless secure link, such as over HTTPS. This functionality may be referred to as a gateway, gateway controller, or rule engine (not shown in FIG. 1 of the drawings) that determines when a request to write data to a database should be allowed and when a request to write data to the database should be prohibited.

Each gateway 131, 133, 135 may be configured to perform the following functionality. This description of an embodiment focuses on the functionality of one of the gateways 131, 133, 135. Typically, each node 119, 121, and 123 adapts the same or similar functionality to the gateway relative to the functionality described below. Thus, the functionality of each gateway 131, 133, 135 can be implemented in the corresponding node 119, 121, 123.

Each of the adapters 101, 103, 105 may periodically provide certain status information to the respective node 119, 121, 123 via wired or wireless links 151, 153, 155, such as HTTPS. This is typically done in response to a poll, via one of the adapters 101, 103, 105, one of the respective data bases 107, 109, 111 that may be associated with each adapter. State information supplied from one of the adapters 101, 103, 105 to one of the nodes 119, 121, 123 or gateways 131, 133, 135 is typically encrypted using one of the keys 125, 127, 129 shown in FIG. 1. Data may be supplied using a REST API call, which may include one of the keys as described above. Typically, each of the keys 125, 127, 129 used to sign data is a public or private key. In addition, each of the keys 125, 127, 129 is usually different. In addition, each key 125, 127, 129 can be used to identify the source or origin of the data. The key may uniquely identify the origin or source of the data stored in the databases 107, 109, 111 data. In one particular example, each of the adapters is configured to poll a particular database 107, 109, 111 at a particular frequency.

The first adapter 101 may be configured to poll the first database at a first rate. The second adapter 103 may be configured to poll the second database 109 at a second rate. The third adapter 105 may be configured to poll the third database 111 at a third rate. The third frequency may be more frequent or less frequent than the first frequency or the second frequency, depending on the implementation. The first frequency may correspond to or be substantially equal to the second frequency.

Each adapter then receives state information data from one of the data sources. Data may be transmitted according to XML or JSON data formats, as described above, to each node.

In response, each of the nodes 119, 121, 123 or gateways 131, 133, 123 may generate a write command, which may also be sent as part of the payload, requesting that the syntax elements specified in the state information be written to the database. or one of the nodes 119, 121, 123. Typically, data is periodically sent from each adapter 101, 103, 105 to the corresponding node 119, 121, 123, for example, at a frequency of approximately 1 minute.

Accordingly, at step 801, one or more nodes 119, 121, 123 or gateways 119, 121, 123 receive data from the respective adapter 101, 103, 105. Typically, the data is signed with a key. Then one or more nodes 119, 121, 123 or gateways 119, 121, 123 determine the identity associated with the data or, in other words, with the origin of the data, at step 803. This may be done using a key.

For example, in the embodiment of FIG. 1, the data stored in the database 107 is from/associated with an airport such as Heathrow, London, LHR. The data stored in the database 109 comes from/is associated with an airline such as British Airways ^TM . The data stored in the database 111 comes from/associated with a flight status information data provider.

Each node 119, 121, 123 or gateway 131, 133, 135 may determine the identity associated with the data based on the keys 125, 127, 129 used by the adapters to sign the data. As described in more detail below, the gateway controller blocks or allows a write request to a node or database based on one or more rules stored in each node. There is usually one rule set, and it is replicated across each node. However, in principle, different rules can be provided for each data source.

Thus, each node 119, 121, 123 or gateway 131, 133, 135 can determine the identity associated with the data from the characteristics of how the data is signed. Since each key may be different, each node 119, 121, 123 or gateway 131, 133, 135 has the ability to determine which key is used to sign the data, for example, the key associated with British Airways or the key associated with the airport. Dublin, or the key associated with Heathrow Airport, London.

After determining, usually uniquely, the source of data, each node 119, 121, 123 or gateway 131, 133, 135 performs a lookup in a different database that stores the rules that determine whether a request to write data to the database or node should be allowed or denied. .

The specific detailed rules stored in the database or nodes 119, 121, 123, or gateways 119, 121, 123 are described in more detail below, but different rules are usually provided depending on whether the information or state data is associated with a departure airport or an arrival airport. or with an airline.

The rules determine which of the syntax elements defined in the state information received by one of the nodes 119, 121, 123 or gateways 119, 121, 123 from one of the adapters 101, 103, 105 can be written to or combined with existing syntax elements stored in one of the nodes.

Based on certain rules, each of the various syntactic elements and data origins is checked against a rule. Write access to update each syntax element stored in the node is allowed or denied based on the rules at block 805.

In another aspect, one or more fields or syntax elements passed to/from any of the functional components shown in FIG. 1 can be encrypted.

In one specific example, the syntax elements or data associated with the estimated departure schedule are public and can be signed with a public key. Thus, all parties with access to the virtual network 100 shown in FIG. 1 can decrypt this information.

However, certain fields or syntax elements associated with state information may be encrypted with a private key. For example, the syntax element "number of passengers per aircraft" may be protected by three-way encryption.

In this case, a particular application of the above may be that the airport may need to determine the total number of passengers arriving, for example, for each flight or for a given period of time on a specific date. In addition, the airport may need to determine how many of these arriving passengers require a wheelchair.

This data may be provided by an airline source using one of the adapters, such as the adapter 103, and may be included in the state information retrieved from the database 109 and transmitted to the node 121, for example, using a transmission medium or transmitter. In this way, a private key or a three-way lock may be provided, for example between a departure airport such as Heathrow, London, an airline such as BA, and an arrival airport such as Dublin, such that one or more fields or syntax elements in the state information retrieved of the databases 107, 109, such as the number of passengers or/and the number of wheelchair users are only visible to these three parties.

This means that even if a third party needs to create an application in order to query a database stored in one of the nodes, it should not be able to decrypt specific syntax elements or fields, since they are protected from viewing by three-way blocking. Three-way locking or private key encryption of certain data or syntax elements may be applied to other syntax elements that are associated with sensitive data.

As described above, embodiments of the invention retrieve flight data from a variety of sources such as an airport database (107), airlines (109), and flight information (111). The data is then stored on the blockchain or DLT. The data may be complete flight items or any one or more of the partial flight items, such as any one or more of the data items shown in FIG. 2–7.

In addition, a programming interface, such as an API associated with the database 111, may be provided that allows access to a combined set of data stored on the blockchain. The API may include functionality that allows the first key associated with a flight to be determined based on one or more input fields, such as any one or more of the data uniquely identifying a particular flight, as discussed above. This is shown as step 901 in FIG. 9 drawings. In step 903, the first state information associated with the first key is retrieved from the blockchain database or other database using the (unique) key. The API can then retrieve any one or more of the data fields shown in FIG. 2–7 from the same database. Typically, one or more of the data items shown in FIG. 2-7 are displayed on the monitor, on the display or in the display to the users of the system.

In some specific examples, each of the nodes 119, 121, 123 or gateways 119, 121, 123 may be configured to encrypt certain fields stored in the database. A three-way encryption algorithm may be used.

For example, fields that are not highly sensitive, which may be associated with general arrival or departure schedule information, may be "public" and not necessarily encrypted.

However, some data may be kept as confidential data by encrypting it, for example, using a three-way encryption algorithm.

In one particular example, suppose the arrival airport is Dublin and the adapter connected to the Dublin database tries to update the gate, in which case this update is rejected because usually only the departure airport database, or in other words, the adapter, connected to the airport of departure database, write access to the database is allowed to update fields for which only the airport of departure is trusted for updating. This preserves the integrity of the fields stored on the blockchain.

Thus, an adapter connected to the database of the departure airport is typically only allowed to update the information associated with the departure and is not allowed to update any information associated with the arrival or information associated with the passenger baggage, for example.

Similarly, an adapter connected to an arrival airport database is typically only allowed to update information associated with an arrival and is not allowed to update any information associated with a departing flight, for example.

Thus, various subsets of fields stored in the database can only be updated by certain adapters with data from a particular source, according to certain access rules.

Flight life cycle

The flight lifecycle represents the initial flight object and all subsequent updates to the flight. The following example shows the type of updates that can be performed by embodiments of the invention in which a party provides data. Updates are presented in the typical order in which embodiments of the invention process data.

Update #1 based on the airline:

– the airline publishes information about the flight schedule (flight number, airports of departure/arrival, date/time of departure/arrival).

Update #1 based on departure airport:

– the airport of departure updates this flight with information from check-in counters,

– the departure airport updates this flight with terminal/gate information.

Update #2 based on the airline:

– the airline is updated with the estimated departure time.

Update #1 based on arrival airport:

– the arrival airport updates this flight with an exit on arrival.

Update #2 based on departure airport:

– the departure airport updates this flight with the actual departure time.

Update #2 based on arrival airport:

– the arrival airport updates this flight with the actual time of arrival,

– the arrival airport updates this flight with the baggage carousel number.

Data format

The flight data is transferred to the blockchain using the ACRIS data structure with some additional fields added in this example.

Additional fields:

– passengers – This data structure contains flight data that indicates the number of passengers in each cabin and the number of passengers requiring wheelchair assistance. The data should normally be encrypted and be visible only to the relevant parties, namely the airline, the airport of departure and the airport of arrival,

– flightDataChanges - This data structure contains a history of all changes. It forms part of the data structure for convenience only, to aid debugging and provide an easily accessible history of flight updates.

Any one or more of the data fields described above may be stored in the SITA database 111 . Typically, an API is provided that allows the database to be queried such that additional field data can be retrieved from the database 111 .

From the above, it should be appreciated that embodiments of the invention may use a controlled access blockchain or DLT that uses a smart contract to combine data and arbitrate when there is conflicting data. Data from the AODB systems of the airline and the airport is combined and stored on the blockchain. Typically, blockchain nodes exist in SITA, IAG, and LHR data centers.

Fig. 2-7 drawings provide an illustration of the process of updating a database or blockchain with data such as state information. In this particular example, the data is associated with a specific flight, BA0724 from Heathrow, London, LHR, to Geneva, GVA, scheduled to depart at 6:45 am and arrive at 9:20 am, and it also shows that the flight departed.

The actual departure time is shown as 6:43 from Terminal 5, Gate B:38. The estimated arrival time of 9:35 am in terminal 1 is shown and the gate on arrival has not yet been assigned.

In FIG. 2 shows the status or history of updates. For example, it shows that the arrival airport, GVA, is trying to update the actual time and that this update is not authorized or allowed. In contrast, the lower part of FIG. 2 shows that the airline has permission or is authorized to update the data with the actual departure time at 6:43. Similarly, FIG. Figures 3-6 show examples of specific data sources attempting to update the data stored in the database and examples in which data recording is enabled or disabled. Fig. 7 shows some exemplary fields or syntax elements.

The flow chart of the method of FIG. 8 and 9 illustrate the operation of exemplary implementations of systems, methods, and computer program products in accordance with various embodiments of the present invention. Each block in the flowcharts or block diagrams may represent a module containing one or more executable computer instructions or part of an instruction to implement the logical function indicated in the block. The order of the blocks in the diagram is for illustrative purposes only. In alternative implementations, the logic functions illustrated in specific blocks may occur out of the order shown in the drawings. For example, two blocks shown as adjacent to each other may be executed simultaneously or, depending on the functionality, in reverse order. Each block in the flowchart may be implemented in software, hardware, or a combination of software and hardware.

From the foregoing, it should be appreciated that the system, apparatus, and method may include a computing device such as a desktop computer, laptop computer, tablet computer, personal digital assistant, mobile phone, smartphone.

The device may include a computer processor that executes one or more server processes to communicate with client devices. Server processes contain machine-readable program instructions for performing the operations of the present invention. Machine readable program instructions may be either source code or object code written in/in any combination of suitable programming languages, including procedural programming languages such as C, object oriented programming languages such as C#, C++, Java, preparation languages scripting, assembly languages, machine code instructions, instructions based on instruction set architecture (ISA), and stateful data.

The wired or wireless networks described above may be a public, private, wired, or wireless network. The communications network may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephone system, or a satellite communications system. The communications network may comprise any suitable infrastructure including copper cables, optical cables or fibers, routers, firewalls, switches, gateway computers, and edge servers.

The system described above may include a graphical user interface. Embodiments of the invention may include an on-screen graphical user interface. The user interface may be provided, for example, in the form of a widget embedded in a web site, as a device application, or on a dedicated web landing page. Computer-readable program instructions for implementing a graphical user interface may be downloaded to a client device from a computer-readable storage medium over a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and/or a wireless network. The instructions may be stored on a computer-readable storage medium in the client device.

Those skilled in the art will appreciate that the invention described herein may be embodied in whole or in part as a method, data processing system, or computer program product including machine-readable instructions. Accordingly, the invention may take the form of an all-hardware implementation or an implementation combining software, hardware, and any other suitable approach or equipment.

The computer-readable program instructions may be stored on a permanent tangible computer-readable medium. The computer-readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk drive, random access memory (RAM) Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM or Flash Memory), Static Random Access Memory (SRAM), Compact Disc Portable Read Only Memory (CD-ROM), Digital Versatile Disc (DVD), memory cards in Memory Stick format, floppy disk.

Exemplary embodiments of the invention may be implemented as a circuit board that may include a CPU, a bus, RAM, flash memory, one or more ports for operating connected input/output equipment such as printers, a display, keypads, sensors, and cameras, ROM, a communication subsystem such as a modem, and communication media. The following numbered paragraphs constitute a further description of the invention.

1. Computer processing device (119, 121, 123, 131, 133, 135) for determining whether to allow or deny access to a database or data storage medium associated with the device, and the device contains:

a. receiving means for receiving data, in particular state information, wherein the data is signed with a key;

– in this case, the device is configured to:

i. determining the origin of the data by comparing the key with one or more keys stored in the database or data storage medium to identify the source of the data;

ii. performing a search on the database or storage medium to determine one or more access rules associated with the data source, the access rules determining whether write access to the database or storage medium is allowed or denied for the data; and

iii. allowing or denying write access to a database or storage medium based on a specific rule or rules.

2. The computer processing device of claim 1, wherein the data comprises a plurality of different fields, and wherein the database or data storage medium comprises a plurality of different fields.

3. The computer processing device of claim 2, wherein one or more different access rules are provided for at least two or more of the different fields.

4. A computer processing device according to any one of the preceding claims, wherein the data is associated with a flight between origin A and destination B.

5. A computer processing device according to any one of the preceding claims, further configured to allow or deny access to a subset of fields stored in the database or storage medium based on a certain rule or rules.

6. A computer processing device according to any one of the preceding claims, further configured to encrypt one or more fields associated with received data based on one or more encryption rules stored in a database or data storage medium, wherein the encryption is preferably performed using three-way encryption.

7. A computer processing device for determining state information associated with a flight between origin A and destination B, the device comprising:

a. the first adapter configured to:

– determining the first key associated with the flight; and

– receiving the first state information associated with the first key.

8. The computer processing device of claim 1, wherein the device further comprises:

a. a second adapter configured to:

i. receiving second state information associated with the first key, wherein the second state information is different from the first state information.

9. The computer processing device of claim 2, wherein the device further comprises:

a. a third adapter configured to:

i. receiving third state information associated with the first key, wherein the third state information is different from the first state information and the second state information.

10. The computer processor according to any one of the preceding claims, wherein the first set of rules is associated with the first state information, wherein the rules determine which of the one or more flight state information syntax elements stored in the database can be updated by the first adapter.

11. The computer processor according to any one of the preceding claims, wherein the second set of rules is associated with the second state information, the rules determining which of the one or more flight state information syntax elements stored in the database can be updated by the second adapter.

12. The computer processor according to any one of the preceding claims, wherein the third set of rules is associated with the third state information, the rules determining which of the one or more flight state information syntax elements stored in the database can be updated by the first adapter.

13. A computer processing device according to any one of the preceding claims, wherein the first key allows access to a database associated with an airline or airport.

14. The computer processing device according to any one of the preceding claims, wherein the processor is further configured to make a service based call to a database associated with the transport node, and preferably the service based call is a SOAP XML web services based call. , transmitted using the secure transfer protocol, or a REST API call.

15. The computer processing device according to any one of the preceding claims, wherein the service-based call contains the first key.

16. The computer processing device according to any one of the preceding claims, wherein any one or more of the first state information and the second state information and the third state information contains data specifying various aspects of the state information, such as a departure airport, gate, arrival airport, exit upon arrival, flight schedule information associated with the airline, and preferably the data is formatted according to an alphanumeric data format such as an XML or JSON data format.

17. The computer processing device according to any one of the preceding claims, wherein the first or second or third adapters are configured to read one or more syntax elements associated with the first state information or the second state information or the third state information, the state information being configured according to the first format, and converting the syntax elements to a second format that is different from the first format.

18. The computer processing device according to any one of the preceding claims, wherein any one or more of the first adapter, the second adapter, or the third adapter is configured to assign a stamp to any one or more of the first state information, the second state information, and the third state information via the first key. .

19. The computer processing device according to any one of the preceding claims, wherein each of the first, second, or third adapters 101, 103, 105 or nodes 119, 121, 123 is configured to combine received first state information and second state information, and preferably third state information. into aggregated data, the aggregated data preferably containing an alphanumeric format.

20. The computer processing device of claim 1, wherein any one or more of the first adapter, second adapter, or third adapter is further configured to receive flight state data comprising any one or more of the syntax elements defining:

– time of departure and/or arrival according to the schedule;

– estimated and actual time of departure/arrival;

– boarding gate and/or terminal associated with the airport;

– an exit or/and an arrival terminal associated with the airport;

– baggage belt number associated with the airport of arrival;

– flight status information, in particular data identifying the flight as "delayed" or "boarding in progress" or "boarding in progress" or "boarding completed"; and

– aircraft type and registration number.

21. The computer processing device according to any one of the preceding claims, wherein the processor is further configured to determine if any one or more additional syntax elements associated with the first state information and the second state information, and preferably the third state information, match based on a comparison of the syntax elements.

22. The computer processing device according to any one of the preceding claims, wherein the processor is further configured to rationalize one or more specific matching syntax elements by selecting only one of the matching syntax elements associated with one of the first or second or third flight state information, and preferentially discarding matching syntax elements associated with other flight state information.

23. The computer processing device according to any one of the preceding claims, wherein the processor is further configured to transmit the aggregated data or any of the first state information and the second state information and the third state information to one or more nodes (119, 121, 123) or other computing a device associated with a distributed ledger, and wherein the aggregated data or data is transmitted periodically.

24. A computer processing device according to any one of the preceding claims, wherein the computing device or other computing device or node is configured to generate a unique key for the flight based on any one or more of data specifying a scheduled departure date, departure airport, serving airline, and flight in progress.

25. A computer processing device according to any one of the preceding claims, wherein another computing device or node searches another database for data that matches the unique key for the flight.

26. The computer processing device according to any one of the preceding claims, wherein the other computing device or node creates a flight record containing any one or more of data specifying a departure schedule, an arrival schedule, a current date, an operating airline, a flight number, a departure airport, and an airport. arrival, and preferably a flight record is only created if the database does not contain data that matches the unique key for the flight, and stores the aggregated data in the flight record in the database.

27. A computer processing device according to any one of the preceding claims, wherein the processor is further configured to send aggregated data to a display at an airport, wherein the displayed status information contains data defining the status of the flight, in particular alphanumeric text containing any one or more than one of the data specifying whether the flight is "delayed", "boarding in progress", or "boarding completed" or whether the passenger associated with the flight should go to a given exit number.

28. A method for determining state information associated with a flight between origin A and destination B, the method comprising any one of the preceding claims.

29. A computer program product that, when executed, performs the method of any one of the preceding claims.

30. An apparatus for determining state information associated with a flight between origin A and destination B, the apparatus comprising:

a. means for determining a first key associated with the flight;

b. means for receiving first state information associated with the first key.

Claims (43)

1. A data processing system containing a processing means configured to: – definitions from the first data set associated with the first data source, the first unique key associated with the first data source, wherein the first data set contains a plurality of different first data elements; – definitions from a second data set associated with a second data source, a second unique key associated with a second data source, wherein the second data set contains a plurality of different second data elements, wherein the first data set and the second data set share at least one a common data element, wherein at least some of the first data elements are different from the second data elements; – verification of the first data source and the second data source based on the keys; – combining the first data set and the second data set into an aggregated data set if each data source is verified as a data source; – definitions from a third data set associated with a third data source, a third unique key associated with a third data source, wherein the third data set contains a plurality of different third data elements, wherein the first data set and the second data set and the third data set share at least one common data element, and at least some of the first data elements are different from the third data elements; – verification of the third data source based on the third key; – combining the aggregated data set and the third data set, if the third data source is verified as the third data source; - determining whether each data source is authorized to update one or more data elements associated with each of the first data set and the second data set and the third data set; - if the processing means determines that two or more of the data sources are authorized to update one or more of the same data elements common to two or more of the data sets, arbitrating between updates from the data sources based on which update is the most recent, or based on a weighting factor associated with each data element, with the weighting factor depending on the data source. 2. The system according to claim 1, further comprising receiving means configured to receive a first data set from a first data source, and/or receiving means configured to receive a second data set from a second data source, and/or receiving means configured with the possibility of receiving a third data set from a third data source. 3. The system according to one of paragraphs. 1 or 2, where each data element contains a key/value pair. 4. The system of claim 1, further comprising determining whether the first data set and the second data set include the same data elements. 5. The system of claim. 1, in which, if it is determined that the first data set and the second data set include the same common elements, weight the values associated with the common elements based on the data source associated with the first data set and the source data associated with the second data set. 6. The system according to any one of paragraphs. 1-5, further comprising receiving an updated first data set at a first rate and receiving an updated second data set at a second rate. 7. The system of claim. 6, in which the second frequency is higher than the first frequency. 8. The system of any one of the preceding claims, wherein the first data source is associated with the origin of the flight and the second data source is associated with the destination of the flight. 9. The system of any one of the preceding claims, wherein the data is associated with a flight or flight between a point of origin and a destination, wherein any one or more of the first state data and the second state data and the third state data contains data defining various aspects of the information states associated with a departure airport, a departure gate, an arrival airport, an arrival gate, flight schedule information associated with an airline, and wherein the data is formatted according to an alphanumeric data format such as an XML or JSON data format, wherein said data or the state data contains one or more syntax elements specifying: - time of departure and/or arrival according to the schedule; - estimated and actual time of departure/arrival; - boarding gate and/or departure terminal associated with the airport; - an exit and/or an arrival terminal associated with said or some airport; - number of the baggage belt associated with the airport of arrival; - information about the state of the flight, in particular data that determines the flight as delayed or in the state of the start of boarding, boarding or the end of boarding; and - aircraft type and tail number, and wherein said additional key is a unique key for said or any flight based on one or more of the data defining the planned departure gate, departure airport, serving airline and served flight, and wherein the system is configured to generate a flight record containing one or more of data defining a departure schedule, an arrival schedule, a service date, an operating airline, a flight number, a departure airport, and an arrival airport, and wherein the flight record is created only if said or some database does not contain data that matches the unique key for the flight, and saving aggregated data in the flight record in the database, wherein the system is further configured to send the aggregated data to a display at the airport, wherein the displayed status information contains data specifying the status of the flight in a specific alphanumeric text containing any one or more of the data specifying whether the flight is delayed, boarding in progress, or ending. boarding, or whether the passenger associated with the flight should go to a given boarding gate number. 10. A data processing method, comprising the steps of: – determine from the first data set associated with the first data source, the first unique key associated with the first data source, while the first data set contains a plurality of different first data elements; – determine from the second data set associated with the second data source, the second unique key associated with the second data source, while the second data set contains a plurality of different second data elements, while the first data set and the second data set share at least one a common data element, wherein at least some of the first data elements are different from the second data elements; – verifying the first data source and the second data source based on the keys; and – combine the first data set and the second data set into an aggregated data set if each data source is verified as a data source; – determine from the third data set associated with the third data source, the third unique key associated with the third data source, while the third data set contains a plurality of different third data elements, while the first data set, and the second data set, and the third data set share at least one common data element, and at least some of the first data elements are different from the third data elements; – verify the third data source based on the third key; – combine the aggregated data set and the third data set if the third data source is verified as the third data source; - determine whether each data source is authorized to update one or more data elements associated with each of the first data set, and the second data set, and the third data set; - determine whether two or more of the data sources are authorized to update one or more of the same data elements common to two or more of the data sets, arbitrate between updates from the data sources based on which update is the newest in time, or based on a weighting factor associated with each data element, with the weighting factor depending on the data source. 11. The method of claim 10, further comprising receiving a first data set from a first data source and/or receiving a second data set from a second data source and/or receiving a third data set from a third data source. 12. The method according to any one of paragraphs. 10, 11, in which each data element contains a key/value pair. 13. The method of claim 10, wherein if it is determined that the first data set and the second data set include the same common elements, weight values associated with the common elements based on the data source associated with the first data set, and a data source associated with the second data set. 14. The method according to any one of paragraphs. 10-12, further comprising receiving an updated first data set at a first frequency and receiving an updated second data set at a second frequency, wherein the second frequency is higher than the first frequency, and wherein the first data source is associated with the origin of the flight, and wherein the second data source is associated with the destination of the flight. 15. A computer-readable medium on which a computer program product is stored, which, when executed, carries out the method according to any one of paragraphs. 10-14.

Images