FIELD OF THE INVENTION The present application relates to a system and method for monitoring unmanned aircraft. In particular, the invention relates to a system and method for securely storing a registry of unmanned aircraft data including aircraft position information such that it can only be accessed by the relevant user entities. BACKGROUND TO THE INVENTION

The prevalence of unmanned aircraft, sometimes known as drones, is on the increase and these unmanned aircraft are often used for activities such as aerial photography, structural inspections, land surveying, surveillance, law enforcement or traffic reporting. For these operations, drones offer a lowered risk to personnel and an increase in cost efficiency in comparison to mobilising a manned aircraft.

Smaller drones, e.g. those weighing around 25kg or less, such as recreational drones, are typically not regulated in the same manner as manned aircraft and unmanned aircraft that are above this weight level. Whilst this improves access to drones for some recreational and light commercial purposes, this may cause problems if it is desired to operate the drones in a busy area of airspace, for example in the vicinity of an airport. Whilst drone operators are usually required to notify airport operators if they intend to operate a drone within a given distance of an airport location, for example within around 5 miles from the airport's reference point, the airport operators will not be aware of where the drones are at any given time and there may be difficulties for the airport operators to identify the owner of a given drone that may be of concern.

The rates of accidents or mishap involving drones are up to 300 times greater than the average for general aviation and the costs for damaged equipment can run into hundreds of thousands of dollars, notwithstanding indirect costs relating to injury, death or derivative liability. As a result, the applicant has appreciated that it is desirable to provide systems and methods that enable professional aviation safety standards, training and risk management strategies to be applied to the operation of such drones in order to ensure the continual safety performance and assurance drones and their owners / operators. Moreover, the applicant has appreciated that it would be desirable to provide an improved system for overseeing and controlling the use of drones that is scalable and can handle the processing of the large amounts of data that would be generated by such drones. SUMMARY OF THE INVENTION

The invention is defined in the independent claims to which reference should now be directed. Advantageous features are set out in the dependent claims. In a first aspect, the invention relates to a system for monitoring the position of one or more unmanned aircraft. The system comprises a receiver unit configured to receive

identification information uniquely identifying an unmanned aircraft and to receive aircraft position information corresponding to the unmanned aircraft; at least one network node in communication with a plurality of further network nodes to form a distributed networking database; and a processor configured to receive the identification information and aircraft position information received at the receiver unit and to parse and store the received aircraft position information associated with the identification information in the at least one network node. The system is configured to replicate aircraft position information updates to the at least one node across the plurality of further network nodes and to receive updates comprising ownership details corresponding to the owner of a given uniquely identified unmanned aircraft, from the plurality of further network nodes for replication on the at least one node. The data stored on the distributed networking database is encrypted cryptographically such that each item of cryptographically encrypted data stored in the distributed networking database can only be decrypted by a user if they have access to an appropriate cryptographic key corresponding to the given item of data stored in the distributed networking database. Advantageously, this provides a distributed record of drone location and ownership data that is quick, efficient and secure with highly scalable access to a high volume of data from the unmanned aircraft. The level of access rights for both the writing and reading of different types of data points is also highly customisable. Moreover, this provides the safe and efficient integration of Unmanned Aircraft Systems (UAS), also known as drones, into civil airspace and providing traffic management. Optionally, the distributed networking database is a permissioned blockchain. Optionally, the encrypted data stored on the distributed networking database is encrypted using public- key cryptography. This increases the security of the blockchain system and the drone data stored on the blockchain.

Optionally, the at least one network node forms a blockchain network and the method uses a consensus engine comprising at least one of proof of authority, proof of work, or a byzantine fault tolerant algorithm. In this manner, the blockchain can be distributed across a number of nodes and the proof and fault methodologies advantageously make it more difficult for malicious parties to manipulate the stored data in a lasting way. Optionally, the encrypted data is stored in a smart contract. This advantageously enables the system to provide deterministic computation with associated verified outcomes in a simple, efficient and secure manner such that high volumes of data can be stored and processed. Optionally, the system further comprises an alerting module: wherein the receiver unit is further configured to receive the coordinates of a defined region of airspace; wherein the processor is further configured to compare the received aircraft position information corresponding to the unmanned aircraft and the defined region of airspace; and wherein the alerting module is configured to generate an alert if the aircraft position information corresponding to the unmanned aircraft is determined to correspond to a location within the defined region of airspace. This enables intelligent alerting to be provided by the system based on the received drone location data and the region of airspace / jurisdictional area of a given entity / user of the system. Optionally, the processor is configured to associate the received coordinates of a defined region of airspace with a given regulatory authority and wherein the alerting module is configured to output the generated alert to the given regulatory authority, wherein the generated alert comprises the ownership details. Advantageously, the system may send the intelligent alerting to the given regulatory authority for the region of airspace in question and may include the ownership details necessary for the regulatory authority to action a response to the generated alert.

Optionally, the receiver unit is further configured to receive a flight plan identifying a plurality of waypoints defining a future flight of the unmanned aircraft, wherein the processor is further configured to compare the plurality of waypoints defining a future flight and the defined region of airspace, and wherein the alerting module is configured to send the flight plan to the given regulatory authority for approval if the flight plan is determined to intersect the defined region or airspace. In this manner, flight plans can be entered into the system and be automatically processed and sent to the relevant regulatory authority for approval.

Optionally, the processor is further configured to compare the flight plan identifying a plurality of waypoints defining a future flight of the unmanned aircraft with received aircraft position information corresponding to the unmanned aircraft, to identify any deviations and to send the details of the comparison to one of either the given regulatory authority or an owner of the unmanned aircraft identified in the ownership details. In this manner, the system advantageously enables user entities to monitor deviations between the received aircraft position information of a flight that is in progress, or has been completed, and the previously submitted flight plan for that unmanned aircraft or drone. Optionally, the number of the plurality of nodes corresponds to the number of user entities of the system, wherein each node is configured to be accessed by a given user entity respectively and wherein the user entities comprise at least one of a regulatory authority having a given airspace jurisdiction, an owner of the unmanned aircraft or a manufacturer of unmanned aircraft. Accordingly, the respective user entities are able to access a node of the distributed database that is local to them, which advantageously improves the scalable nature of the system as well as its processing responsiveness.

Optionally, the respective user entities are only able to decrypt a subset of the data stored on the plurality of nodes according to a permissions level associated with the respective user entity. This improves the security of the system, whilst still enabling each node to store a complete copy of the database or database.

Optionally, the receiver unit is further configured to receive aircraft specification data, from at least one manufacturer of unmanned aircraft, to be associated with a given unmanned aircraft, and wherein the cryptographic encryption prevents user entities other than the at least one manufacturer of unmanned aircraft from storing aircraft specification data in the distributed networking database. In this manner, the access rights for modifying certain specifications of the unmanned aircraft can be limited to the user entities that manufacture the unmanned aircraft or drone in question. This improves the accuracy and reliability of the drone specifications. In a second aspect, the invention relates to a method for monitoring the position of one or more unmanned aircraft, the method comprising: receiving, at a receiver unit, identification information uniquely identifying an unmanned aircraft and aircraft position information corresponding to the unmanned aircraft; receiving and parsing, at a processor, the identification information and aircraft position information received at the receiver unit; storing, in at least one network node of a distributed networking database, the aircraft position information associated with the identification information; replicating the aircraft position information from the at least one node to a plurality of further network nodes of the distributed networking database; and receiving, at the at least one node, updates comprising ownership details corresponding to the owner of a given uniquely identified unmanned aircraft from the plurality of further network nodes for replication on the at least one node; wherein storing the data on the distributed networking database comprises encrypting the stored data cryptographically; and wherein each item of cryptographically encrypted data that is stored in the distributed networking database can only be decrypted by a user if they have access to an appropriate cryptographic key corresponding to the given item of data stored in the distributed networking database.

Advantageously, this provides a distributed record of drone location and ownership data that is quick, efficient and secure with highly scalable access to a high volume of data from the unmanned aircraft. The level of access rights for both the writing and reading of different types of data points is also highly customisable. Moreover, this provides the safe and efficient integration of Unmanned Aircraft Systems (UAS), also known as drones, into civil airspace and providing traffic management. Optionally, the distributed networking database is a permissioned blockchain. Optionally, encrypting the stored data cryptographically comprises encrypting the data using public-key cryptography. This increases the security of the blockchain system and the drone data stored on the blockchain. Optionally, the at least one network node forms a blockchain network and the method uses a consensus engine comprising at least one of proof of authority, proof of work, or a byzantine fault tolerant algorithm. In this manner, the blockchain can be distributed across a number of nodes and the proof and fault methodologies advantageously make it more difficult for malicious parties to manipulate the stored data in a lasting way. Optionally, the encrypted data is stored in a smart contract. This advantageously enables the system to provide deterministic computation with associated verified outcomes in a simple, efficient and secure manner such that high volumes of data can be stored and processed.

Optionally, the method further comprises: receiving, at the receiver unit, the coordinates of a defined region of airspace; comparing, at the processor, the received aircraft position information corresponding to the unmanned aircraft and the defined region of airspace; and generating an alert, at an alerting module, if the aircraft position information corresponding to the unmanned aircraft is determined to correspond to a location within the defined region of airspace. This enables intelligent alerting to be provided by the system based on the received drone location data and the region of airspace / jurisdictional area of a given entity / user of the system.

Optionally, the method further comprises: associating, at the processor, the received coordinates of a defined region of airspace with a given regulatory authority; and outputting, from the alerting module, the generated alert to the given regulatory authority, wherein the generated alert comprises the ownership details. Advantageously, the system may send the intelligent alerting to the given regulatory authority for the region of airspace in question and may include the ownership details necessary for the regulatory authority to action a response to the generated alert.

Optionally, the method further comprises: receiving, at the receiver unit, a flight plan identifying a plurality of waypoints defining a future flight of the unmanned aircraft;

comparing, at the processor, the plurality of waypoints defining a future flight and the defined region of airspace; and sending, from the alerting module, the flight plan to the given regulatory authority for approval if the flight plan is determined to intersect the defined region or airspace. In this manner, flight plans can be entered into the system and be automatically processed and sent to the relevant regulatory authority for approval.

Optionally, the method further comprises: comparing, at the processor, the flight plan identifying a plurality of waypoints defining a future flight of the unmanned aircraft with received aircraft position information corresponding to the unmanned aircraft, identifying any deviations, and sending the details of the comparison to one of either the given regulatory authority or an owner of the unmanned aircraft identified in the ownership details. In this manner, the system advantageously enables user entities to monitor deviations between the received aircraft position information of a flight that is in progress, or has been completed, and the previously submitted flight plan for that unmanned aircraft or drone.

Optionally, the number of the plurality of nodes corresponds to the number of user entities of the system, wherein each node is configured to be accessed by a given user entity respectively and wherein the user entities comprise at least one of a regulatory authority having a given airspace jurisdiction, an owner of the unmanned aircraft or a manufacturer of unmanned aircraft. Accordingly, the respective user entities are able to access a node of the distributed database that is local to them, which advantageously improves the scalable nature of the system as well as its processing responsiveness.

Optionally, the respective user entities are only able to decrypt a subset of the data stored on the plurality of nodes according to a permissions level associated with the respective user entity. This improves the security of the system, whilst still enabling each node to store a complete copy of the database or database.

Optionally, the method further comprises receiving, at the receiver unit, aircraft

specification data from at least one manufacturer of unmanned aircraft for associating with a given unmanned aircraft, and wherein the cryptographic encryption prevents user entities other than the at least one manufacturer of unmanned aircraft from storing aircraft specification data in the distributed networking database. In this manner, the access rights for modifying certain specifications of the unmanned aircraft can be limited to the user entities that manufacture the unmanned aircraft or drone in question. This improves the accuracy and reliability of the drone specifications.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

Figure 1 is a schematic representation of a system according to an embodiment of the invention;

Figure 2 is an illustration of a map showing the positions of registered drones;

Figure 3 is an illustration of a map showing the specific details of a selected drone from the map of Figure 2;

Figure 4 is an illustration of a map showing the flight path for a registered drone; and Figure 5 is an illustration of a map showing the flight path for a registered drone with a highlighted comparison showing deviations from a previously submitted flight plan for the registered drone. DETAILED DESCRIPTION

Figure 1 shows an unmanned aircraft or drone 10 that is equipped with a transponder system for transmitting aircraft position information and other telemetry data of the unmanned aircraft to a receiver unit 12 of a system 14 via a communications network or data link 16. The data link 16 may include one or more of a local area network (LAN), a wide area network (WAN), the internet, a mobile telephony communication system or a satellite communication system; however, the data link 16 is preferably a wireless communication system. The receiver unit 12 of the system 14 is further connected to a processor 18, which in turn is connected to a network node 20. The receiver unit 12 may represent a single port or connection for receiving data, or may alternatively represent a plurality of sub-unit receiver units that each operate on one or more ports or connections. In Figure 1 , two further network nodes 20' are depicted. The network node 20 and further network nodes 20' are connected by communications lines 22 to form a distributed networking database. Whilst Figure 1 illustrates the nodes as being connected in a linear manner, the skilled person will appreciate that these network nodes could be connected in any network topology and using wired connections, wireless connections, or a combination of wired and wireless connections. For example, the network nodes may be connected in any one of the following topologies: point-to-point, star, ring, bus, mesh, or a hybrid topology. The further network nodes 20' are also connected to respective receiver units 12' and processors 18'. The aircraft position information and other telemetry data output by the drone 10 may be generated and output by a transmitter, which may be built into the drone hardware at the time of manufacturing or alternatively it may be installed on the drone hardware after manufacturing. The transmitter hardware stores or accesses a unique identification code that can be associated with the connected drone in order to uniquely identify the drone when transmitting the aircraft position information and/or other telemetry data. This unique identification code may be, for example, a string of numbers and or letters. The data will typically be transmitted from the drone transmitter hardware to the system 14 using a Global System for Mobile Communications (GSM) network, although any other suitable communications network may be used, such as Very High Frequency (VHF), Ultra High Frequency (UHF) or other Radio Frequency (RF) electromagnetic waves. In some embodiments, the drone may communicate directly to ground based systems or alternatively via one or more other drones. For example, these other drones may form a mesh network for communication between the originating drone and the ground based systems.

The aircraft position information transmitted by the transmitter may be collected by an onboard Global Positioning System (GPS) unit or any other known method to collect longitude and latitude (LLA) information. In a preferred embodiment, the LLA information is collected from an external source of GPS data so that the system does not need to rely on the drone's internal GPS data, which may be less accurate or less reliable by comparison.

In a preferred embodiment, the drone 10 may transmit the aircraft position information and/or other telemetry data to the system 14 in substantially real-time or near real-time. Alternatively, the aircraft position information and/or other telemetry data may be stored locally at the drone or at an intermediate storage location whilst the drone is in flight and then the aircraft position information and/or other telemetry data for the flight may subsequently be forwarded or sent to the system 14.

The receiver unit 12 and/or processor 18 are preferably able to parse, standardise and store aircraft position information and other telemetry data in a number of different data formats (such as Keyhole Markup Language (KML), Keyhole Markup Language Zipped (KMZ) and GPS Exchange Format (GPX) in order to accommodate and interpret the output from drones produced by various manufacturers. KML is an Extensible Markup Language (XML) notation intended for expressing geographic annotation and visualization within typically internet-based two-dimensional maps and three-dimensional Earth browsers. A sample extract from a KML file may be as follows:

<altitudeMode>absolute</altitudeMode>

<when>2016-01 -08T10:43:27Z</when>

<gx:coord>6.5875906 46.5777525 573.1966591 </gx:coord>

<when>2016-01 -08T10:43:28Z</when> <gx:coord>6.5875906 46.5777472 573.2246742</gx:coord>

<when>2016-01 -08T10:43:28Z</when>

<gx:coord>6.587592 46.5777481 573.3686562</gx:coord>

<when>2016-01 -08T10:43:28Z</when>

<gx:coord>6.587592 46.5777494 573.4686317</gx:coord>

As can be seen from the above sample, KML sets out a reference frame for measuring altitude and a timestamp followed by a corresponding three-dimensional coordinate using the applicable markup language. However, it will be appreciated that other data formats may be used with the respective systems being programmed appropriately to interpret such file formats.

In the preferred embodiment, the distributed networking database 20, 20' may use distributed ledger technology and may be referred to as a blockchain database. This could be implemented as a private or permissioned blockchain database using a proof of authority consensus engine or as a public blockchain using a proof of work consensus engine. Preferably, a private blockchain network having a proof of authority consensus engine is used in combination with earned value management based chains and a practical byzantine fault tolerant algorithm.

This means that nodes 20' are not required to solve arbitrarily difficult mathematical problems, as is the case when using a proof of work consensus engine, and instead the nodes 20' may use a hard configured authority that allows each of them to create and add certain types of new blocks to the blockchain and to secure the blockchain.

Advantageously, this also makes it easier to maintain the blockchain and to keep the block issuers accountable.

In a further preferred embodiment, there will always be at least one authoritative node 20, 20' that signs and validates all transactions to be stored in the blockchain ledger. For example, the authoritative node, or validator node, may be network node 20. The authoritative node, or nodes, act as witnesses to the blockchain ledgers and improve the integrity of the ledger since a copy of each transaction is stored in each of the nodes.

The data stored on the private blockchain may be encrypted cryptographically such that it can only be decrypted by a user if the user has access to an appropriate cryptographic key that corresponds to the particular item of data stored on the private blockchain that the user trying to decrypt. This may be achieved by encrypting the data in a smart contract using private key in the public-key cryptography system.

The private blockchain of the preferred embodiment uses public-key cryptography. In one embodiment, each node of the distributed networking database 20, 20' comprises a server application 24, 24' and a blockchain ledger or blockchain node 26, 26'. The privacy of the data is preferably setup on the server applications 24, 24' with access to the data being established using public and/or private keys that will be read by the server applications. RESTful and JSON APIs are preferably used to interface with the server applications 24, 24' over the internet. The RESTful API uses HTTP requests to handle data

(representational state transfer) using actions such as get, post, put or delete; whereas the JSON API is a remote procedure call that pulls data from a source by sending a request to the source, as is familiar to the person skilled in the art. The JSON API is preferably used to interface with the blockchain ledger 26, 26', which is the database of all of the entries and transactions held in the blockchain system. This aggregation of data will form a registry of drone information and transactions that is substantially immutable, i.e. it will be very difficult for the blockchain ledger 26, 26', containing the registry of drone data, to be changed whilst still maintaining the internal consistency of the blockchain. If one of the copies of the blockchain ledger is tampered with in this manner, then it will be readily apparent that the chain of data is not consistent and thus this untrusted modified version of the blockchain can be rejected and preferably overwritten with a copy of the consistent blockchain ledger from one of the other network nodes in the distributed networking database 20, 20'.

The transmitter may act as a blockchain wallet is this situation. Specifically, the blockchain wallet may hold a cryptographic key so that it is able to sign transactions corresponding to the location events that it will send over the air to the drone registry system. This cryptographic key is preferably a private key that will not visible to anyone and will be securely stored in the drone hardware such that it cannot be extracted from the drone hardware. For example, the cryptographic key may be stored in a secure element within the drone hardware. Alternatively, the information may be signed by the entity that initially receives the location event transmissions from the relevant drone for forwarding to the drone registry system. If it is the drone that signs the location information data, then a cryptographic proof check may be carried out when the location information is received by the system in order to verify that the received information has not been tampered with and that it was indeed sent by the identified drone.

The users of the registry of drone information implemented in the blockchain system may include the operators of the drones and the regulatory authorities that regulate the operation of the drones, for example the use of drones in a given jurisdiction or region of airspace. The regulatory authorities may include aviation authorities that oversea and regulate all aspects of aviation in a large region, such as the whole of the United Kingdom, as well as those responsible for smaller regions of airspace, such as the air traffic controllers assigned to the airspace around a given airport. These various users of the registry of drone information may be referred to herein as entities. In a preferred embodiment, each user entity is provided with their own blockchain node server and each entity accesses the distributed networking database system 20, 20' via their own blockchain node server 20' and by using a cryptographic key that has been assigned to the entity in order to sign any transactions it makes. In this context, a transaction is understood to comprise any reading and/or writing of data from or to the blockchain ledger respectively.

Each entity is issued with a private key and a public key for authentication to their node 20'. The node 20' contains a copy of the functionality, e.g. a server application 24', in addition to a copy of the blockchain ledger 26' (i.e. the database) with all of the data that will be encrypted. Using a privacy framework, it is possible to control which items of data each of the respective entities may access. Whilst each entity stores a copy of the entire database on their respective blockchain ledger 26', the data is always encrypted and so the entity will only be able to decrypt the information that their private or public key, i.e. their access / permissions level, enables them to do so. The type of cryptographic key required will depend on the type of cryptography being used, for example asymmetric key encryption encrypts data using the public key and decrypts using the private key, whereas symmetric key algorithms use a private key for both the encryption and decryption of the data.

This decentralised system using a plurality of nodes provides increased security for the system since a malicious individual would first need to breach the network and then to take control of a majority of the nodes in order to hack the blockchain environment of the system. This makes it incredibly difficult for a party to hack the system and create a false record that will be accepted and persist in the system.

In one embodiment, the blockchain node server corresponding to each entity may be created using a virtual machine within the systems private network and creating a new node instance for the respective entity in that virtual machine. This may be realised using docker container technology. Other authentication mechanisms are also preferably enacted at this stage of registration into the system so that it can be verified that the user entity is indeed the intended user entity.

For example, the user entity may be sent a confirmation email and/or SMS text message containing a link or code that is necessary to authenticate or validate the account being set up. Moreover, the individual completing the user entity registration may be required to upload or otherwise include an image or scan of an identity card identifying the individual, for example a national identification card or passport. Further details may also be required during registration of a user entity with the system, for example an identification of the licences for unmanned aircraft operation held by the user entity or the individuals comprised within the user entity. Once the virtual machine has been created and the blockchain node has been generated for that specific entity by replication, cryptographic keys will be created for authentication by the entity and these will then be shared with the entity. As discussed above, these cryptographic keys will only allow the entity to access the data within the blockchain ledger that the entity has been permissioned to access, even though the blockchain ledger that is stored locally to the user will contain all of the data of each of the other user entities in an encrypted form. For example, a drone operator may be provided with cryptographic keys that only enables the drone operator to access data relating to the drones that they have registered with the system. By implementing the system in this way, the drone registry is advantageously able to scale horizontally and to accommodate as many user entities as required simply by creating new virtual machines to add new blockchain nodes 20' to the system corresponding to each of the new user entities. This advantageously enables the system to resist any detrimental impact to the performance of the drone registry distributed blockchain network system when adding new user entities. Indeed, the more blockchain nodes that there are in the system, the more secure the system will be since it will be more difficult for a malicious hacker to control the substantial proportion of the blockchain nodes that would be required in order to successfully hack the system and tamper with the data records in a manner that would not be detected and corrected. Accordingly, the invention advantageously provides a scalable solution that is capable of processing large amounts of data coming from drones in real time.

In a preferred embodiment, all of the encrypted data stored in the distributed networking database 20, 20' is preferably stored in the form of a plurality of smart contracts. A smart contract is a computerised protocol that stores a set of rules for negotiating and governing a contract. This provides a deterministic computation and verified outcomes so that the smart contract is able to automatically verify the contract and then execute and enforce the agreed terms, depending on what is requested by the initiating entity.

Within the context of the present invention, the types of data that may be stored in the smart contracts include:

Drone Location Event Data - This type of smart contract may store each of the location events associated with a specific drone;

Drone Location Filed Flight Plan - This type of smart contract may store each of the flight plans that have been submitted by a drone operator as will be discussed further below;

Drone Location Live Flight Plan - This type of smart contract may store each of the location events that are associated with a specific flight plan;

Entity Registration - This type of smart contract may store entity identity data as well as data used for authentication of the user;

Drone Registration - This type of smart contract may store the data relating to each of the drones registered to the system, for example make, type, unique identification number and the associated owner or operator;

Drone Modification - This type of smart contract may store each update to modify previous drone data, since data in the blockchain cannot be deleted;

Drone Transfer - This type of smart contract may store records of each transfer of ownership of a drone from one drone operator entity to another drone operator entity;

Drone De-Registration - This type of smart contract may store records relating to drones that have been decommissioned;

· Drone Expiration - This type of smart contract may store expired drone data; and Drone Zone Location Perimeter - This type of smart contract may store a geographic perimeter enclosing a zone or region and may further associate this region with a specific entity of the plurality of user entities. As set out above, the smart contracts may store the various items of data in a manner that is very flexible and scalable since new fields of data can easily be added by introducing a new type of smart contract.

The drone aircraft location information data stored in the Drone Location Live Flight Plan smart contract for all of the registered drones, whether currently stationary or flying, may be parsed and displayed in a map view as illustrated in Figure 2. As discussed previously, the number of drones that will be visible will depend on the access permissions of the entity viewing the map data. For example, if the entity is a drone operator, the smart contracts, in combination with their cryptographic key, may enable them to view the locations of all of the drones that are currently registered to them, but not the locations of any other drones that are registered to the system. This may include the current location of each drone. This drone data is extracted from the blockchain for each of the associated drones.

Mapping data of the area or jurisdiction may be stored locally or obtained through an API call or another known method.

Filtering criteria may be entered in order to limit the displayed drones to those matching the entered filtering criteria. By clicking a given drone, additional specific details regarding the registered drone may be displayed to the user entity as shown in the pop-up box in Figure 3. For example, this data may include the name and/or identification number of the drone, the manufacturer and weight of the drone as well as the start and finish time and date and mission identification number of the most recent mission flown by that drone.

By clicking on the mission identification number displayed for the specific drone in Figure 3, the user will be taken to a further map showing the flight path for the identified mission number as shown by the triangular path overlaid on Figure 4.

Drone operators may submit flight plans in advance of a given drone flight taking place. This may be for a regulatory authority to authorise a given flight plan or simply to give prior notice and warning of the intended flight path. In some circumstances, it may be mandatory for a drone operator to submit an intended drone flight plan for an upcoming flight of a given drone in advance of the drone flight taking place. Such flight plan data may also be viewed overlaid on the mapping data in advance of the relevant drone flight taking place, in a similar manner to the live drone location information as discussed above. This will enable the drone operator to submit its flight plan to the authorities for approval. It is also a way for drone operators to prepare their inspection missions and keep a record of each mission.

During the live drone flight corresponding to the submitted flight plan data, or alternatively after the live drone flight has been completed, the flight plan data and the actual flight path data of the drone may be overlaid onto the same mapping data so that they can be contrasted and compared. As shown by the areas of white blocks shown in Figure 5, the deviations or discrepancies between the initially submitted flight plan and the actual flight path of the drone may be highlighted to show the non-conforming areas.

Smart contracts may also store certain types of logic that are configured to execute a given type of action based on a given condition. These logic smart contracts are preferably a separate type of smart contract from those that store the encrypted data. For example, the "Drone Zone Location Perimeter" smart contract may store a zone around an airport delimited by a perimeter, which may be in the form of a polygon. However, in some embodiments these function may be combined into a reduced number of smart contracts that both store encrypted data and store some types of action logic.

The same smart contract, or a further smart contract, may be configured to execute itself and to send an alert to the specific entity that is associated with the zone if it is determined that a proposed flight plan associated with one of the registered drones intersects the zone. This smart contract alert may notify the entity that a given drone is scheduled to fly through or above the associated zone on a given time and day and the alert may also comprise a copy of part or all of the proposed flight plan. The flight plan for a given registered drone may be entered by the drone operator using mapping tools. In some embodiments, the filing of a flight plan may be mandatory prior to any such flight mission being undertaken.

In this manner, all registered regulatory entities may receive the flight plan request from the drone operator if the flight plan is within the authority or jurisdiction of the regulatory entity. For example, an airport could register itself as a regulatory entity on the Drone Registry so that it will then be able to see all of the live and planned drone flights in and around its vicinity. The smart contracts may also be configured to provide alerting based on live flight data that is being received from a drone connected to the system. For example, the smart contract may cause an alert to be generated and sent to the specific entity that is associated with the zone if it is determined that the received aircraft position information associated with one of the registered drones intersects the zone. The Smart contract may further be configured such that this alert is supressed or not generated if it is determined that a flight plan for the registered drone matches the received aircraft position information where the flight plan has been authorised or approved by the specific entity that is associated with the zone.

Alternatively, the administrative or regulatory entities may want to introduce a restricted or no-fly zone, area or perimeter. Using the above smart contracts, the regulatory entity can choose to view a list of all of the drones registered to operators within a jurisdiction as well as viewing all of the registered drones that are currently flying in the area or perimeter, for example by plotting the near real-time aircraft positioning information on an electronic map. This type of geofencing may also be used to create an alert every time a new drone is determined to enter the no-fly zone. If a drone operator subsequently attempts to submit a flight plan that intersects, or flies very close to, the no-fly zone then they may be

automatically alerted to this situation and the presence of the no-fly zone or other alerted zone. In some embodiments, received bad weather predictions may cause no-fly zones to be automatically created around the bad weather areas during the predicted times.

Due to the nature of the blockchain, the flight plans will also be retained in memory after the flight. This will allow the drone operator to easily archive logs of past flight plans as well as to re-submit any such flight plans to the authorities for further future drone flights. Users may also have the ability to see the flight path of a drone in near real-time versus an illustration of the flight plan that was initially submitted for authorisation.

When a user selects a specific drone to see its mission plan, they will get a map view with the "real" flight plan overlaid on top. The system will parse both the filed flight plan and compare it to the flight that was flown. This real time flight plan will also be stored within the Drone Registry for data analytics & audit purposes. Any differences between the submitted flight plan and the actual route of the flight may be provided by the system in an alert to the drone operator and/or the administrative entity that has authority over the region of airspace that the drone was operating in. As set out above, the blockchain itself stores a ledger of the various data events

(transactions) that are signed by the relevant cryptographic keys. The use of smart contracts further enable the system to store structured and inter-related data structures on the blockchain, including business and permissions logic that can be enforced by the distributed network on the blockchain.

For example, the smart contracts can be configured such that only a node can provide aircraft position information data and only a registered regulatory entity can approve a flight plan of a mission. These aspects are enforced not only at the application level, but also within the blockchain itself in the smart contract. This means that the blockchain will not accept a transaction that does not comply with the permissions rules that have been defined in the smart contract.

For some drone operators, secrecy of their operations may be a high priority. For example, some law enforcement or governmental agencies / secret security agencies undertaking surveillance activities or other similar types of activities may want to further restrict the entities that can track their registered drones. For such secret drone operators, it may be possible for them to register their secret drone operator details and their corresponding drone details so that they can review and monitor the flight activities of their drones;

however, the flight authorities, regulatory authorities, or any other third parties may not be provided with the permissions level / cryptographic keys required to decrypt data relating to these secret drone operators, their drones and the activities of those drones, even if the drones are operating within their jurisdiction. This will provide these secret drone operator entities with access to monitor the their undisclosed drones and to receive the above alerts, such as when their drone has entered, or is about to enter, a region of restricted airspace, such as a no-fly zone.

As described above, two of the predominant users of the system may be the operators of the drones, e.g. companies that may own a fleet of drones used for inspection purposes, and the administrative or regulatory entities, for example civil aviation authorities, airports, airlines and other companies and governmental bodies, that oversee the use of the relevant airspace. These regulatory entities may be provided with the access rights necessary to be able to view all of the drones within their jurisdiction and their flight positioning information. Another type of user of the system may be a manufacturer of the drones themselves.

Drone manufacturers may also be able to register as users of the system such that they can update or modify drone information and add drone details for new drones that are introduced to the market and decommission old drone models. This enables the information about the different drone models to be verified as being legitimate, trustworthy and up-to-date by the actual manufacturers of the drones.

The security of the drone registry system may then be enhanced by restricting registrable types of drones to be only those where the corresponding drone specifications have been input by registered by drone manufacturers as authorised drone types. For example, a drone manufacturer may register a new drone model or modify the details of a current drone model and a drone operator may register the details of the drones that they operate or update said details. Blocks cannot be deleted so modifications must be stored separately and linked to the original data marking it as a replacement for the original data.

Moreover, drone manufacturers may optionally be permitted to obtain overall statistics on the drone models that they make, e.g. the number of flights recorded for each of their drone models, the breakdown of the number of each drones of each model type that are registered with the system and the total hours flown for each drone type / total. In one embodiment, the drone operators may also be able to access statistics such that they can compare their own statistics with those of other drone manufacturers.

Because all of this data is stored and maintained on the drone registry, the system will be able to determine the number of hours flown by type of drone, the number of individual flights with the associated mission information, the number of registered drones, the number of drones that have flown at least one mission within a given time period and the geographic coverage or hotspots of drone flights in a given area and/or over a given period of time. By aggregating all of the data types discussed above within the encrypted blockchain data of the drone registry, the drone registry is able to become a database of reference that can be viewed as a common truth between the multiple user entities that use the drone registry. In this manner, the system advantageously addresses the needs of local and international regulatory authorities for drone registration and legislation in the situation where all operational drones will have to be centrally registered. The Drone Registry also enables the respective local and international regulatory authorities to enforce drone flight violations (for example by issuing fines for infractions) and to monitor drone flights in their respective jurisdictions.

Using the blockchain privacy framework described above drone operators may be able to make access to their data stored in their node available to insurance providers. For example, the insurance providers may desire to perform an audit of the drone operator and to see proof of the total number of drones that have been registered by the drone operator, when they were registered and what types of flight missions they have been used for. The drone operators may also give the insurance providers access to the total number of missions and the total time flown per drone or aggregate across the drone operator entity.

In view of the high security neutrality of the drone registry system, the system and its data will be trusted by all of the entities or parties. Thus a similar situation may also apply if the drone operator wants to permit access to another auditing authority so that the drone operator's activities can undergo auditing, commercial inspection, compliance and monitoring operations to ensure that the relevant legislation and standards are being met.

In summary, allowing access to the Drone Registry to insurance providers and/or auditors will give these entities access to reliable and trustworthy data so that they can: reduce risk, improve safety and build confidence in the reliability of the operations carried out by respective drone operators. They may also implement a robust safety management system to improve the efficiency and safety of the drone operator's organisation and to ensure and prove that operations are conducted with high levels of due diligence and corporate responsibility.

Moreover, the system may help to implement a risk management program to track and improve the key safety performance indicators of the drone operators or regulatory entities, increase reliability , traceability and transparency of drone usage, improve mitigation strategies and controls and comply with any national and international regulatory or custom requirements. For example, in some countries it is mandatory to register an unmanned aircraft or drone in order to securely and legally fly the drone for inspection missions.

It is important to note that the data of a 10 minute drone flight may be estimated to comprise 6,000 event entries for storing in the database. As an example, we can assume that the drone registry system is monitoring 500 registered drones in a given region / jurisdiction and that each of the drones flies on average one 10 minute flight each day. This would then equate to 3 million location event entries per day that must be parsed and stored by the system in the blockchain. It is estimated that, by 2050, there will be 7.5 million drones operating in Europe and so it is clear that innovations such as the present invention are much needed in the industry.

Since all the data, entries & transactions will be stored substantially permanently on the blockchain, there will be very large amounts of data available that could be accessed for statistical and data analytics purposes using big data. This big data may then be used to produce predictions about the usage of drones and their corresponding operations.

Additional data may also be input into the system to enhance any predictions that may be based on the drone registry data.

For example, the intention or mission type of a drone mission may be associated with each drone flight. Furthermore, data such as weather data, flight information from manned aircraft and other airport traffic control related data may be combined with the drone registry data for big data aggregation and analysis. By aggregating some of these data types within the drone registry system, it will be possible to predict the best type of drone model to fly and the best time for the mission based on various criteria. For example in order to avoid congestion of air traffic that may occur at a typical time of day or in a given month or week.

Preferably, the drone registry data may be stored to the blockchain using a database protocol; for large data sets, one such example is the BigChainDB database protocol. This provides an improved facilitation of the decentralisation of the database on a large scale, whilst still providing sub-second latency when storing petabytes of data and has a performance rating of 1 million writes per second throughput. As discussed above, this low latency and high volume capability provides significant benefit to the drone registry system of the present invention.