Route determining system, device and method therefor

Abstract

The application relates to a route determining system, device and method therefor. The technical field relates to a navigation system for a vehicle or transportation means. The method includes using the origin and destination to determine the plurality of regions through which a potential route between the origin and destination passes, determining whether each region is a claimed region associated with a controlling entity, and in response to determining that one or more responses from each controlling entity comprises a disapproval reference identifier, determining a subsequent potential route between the origin and destination wherein the subsequent potential route at least partially passes through one or more further regions. This method can provide more efficient route planning for a vehicle.

Description

ROUTE DETERMINING SYSTEM, DEVICE AND METHOD THEREFORFIELD OF THE INVENTION

[0001] This invention relates to a route determining system, apparatus, method or computer program for providing a route determining system for a vehicle or transportation means. The invention may also relate to a navigation system for a vehicle or transportation means. More particularly, this invention relates to a system, device and method for determining a route or / and navigating a drone or other manned or unmanned aerial vehicle from an origin to a destination.BACKGROUND OF THE INVENTION

[0002] Currently, there is a lack of standard tools or framework for an entity to control its direct airspace while the use of new flying objects such as electric vertical take-off and landing (eVTOL), vertiports or drone operators increases.

[0003] In recent years, the use of unmanned drones has increased, particularly in urban areas. This has lead to an increase in the number of vehicles needing to request flight plans. The availability of cheap, easy to use drones has made droneusage more accessible than ever before.

[0004] Additionally, it can be difficult for drone operators to obtain flight plan permission. Typically, a vehicle is required to seek permission from a controlling entity before it can travel through a controlled region, such as an airport. In legacy Air Transport Industry traffic control systems, the governance is distributed between a national network of operators and airports, with aircraft operators requesting flights between airports. However, a problem with such legacy systems is that they typically do not easily scale with rapidly increasing vehicle numbers.

[0005] Typical flight plans (as used for commercial passenger planes) involve the pilot needing to manually fill out a flight plan and file this plan with an airspace’s controlling entity - typically an air traffic control tower located at the airport the pilot wishes to take off from. This form includes various information about the flight plan, including the airline name, flight number, the type of aircraft and equipment, the intended airspeed and cruising altitude, and the flight plan route (e.g. departure airport, airspaces that will be crossed, and destination airport). In the air traffic control tower, this flight plan is manually reviewed and approved before clearance to fly is given to the pilot.

[0006] The result of this is that manual approval is required for each flight. As flight numbers increase, it can be difficult for the limited number of air traffic controllers to review and approve the increasing number of flight plans. In addition to this, because manual review of each flight plan is needed, there is an increased risk of an air traffic controller mis-approving a flight, for example by approving a dangerous flight plan or a flight plan with errors. This system also breaks down when aerial vehicles take off and land outside of the region controlled by an air traffic control tower, as is increasingly the case with drone flights.

[0007] Additionally, during route planning for a vehicle, it may be desirable to account for vehicle restrictions between a routes origin and destination points. Certain airspaces may be restricted (e.g. over a military base or a government building), and certain airspaces may have certain rules regarding the vehicles, cargo, or route that can be taken through them. It would be advantageous to provide a method which allows a vehicles compliance with such rules to be quickly and automatically authenticated, in order to improve the ease and speed at which flight plans can be created and approved.

[0008] Therefore, a need exists for a method capable of improving the ability to plan a route for a vehicle to follow which passes through controlled regions without by reducing the need for manual human input and approval.SUMMARY OF THE INVENTION

[0009] The present disclosure provides a method for determining a travel route for a vehicle between an origin point and a destination point through a set of claimed regions, the method comprising: determining the origin point and the destination point, and using these points to define an area surrounding the origin and destination points; retrieving information about the surrounding area, including a list of regions inside of the surrounding area; determining a potential route for the vehicle to follow between the origin point and destination point; determining what claimed regions operated by a controlling entity and unclaimed regions not operated by a controlling entity the planned route passes through; contacting the controlling entity of each claimed region to request permission to travel through the region; receiving a response from the controlling entity: wherein if permission is granted, receiving an approval reference ID from the controlling entity, and storing this approval reference ID, wherein if permission is denied, receiving a disapproval reference ID from the controlling entity, storing this disapproval reference ID, and performing the steps of: determining a subsequent potential route between theorigin and destination, contacting the controlling entity of each claimed region to request permission to travel through the region, and receiving a response from the controlling entity; until an approved route is obtained, where an approved route has an approval reference ID granting permission to travel through a region obtained and stored for each region along a potential route; sending a travel request confirmation to each controlling entity whose region the approved route passes through using the approval reference ID; and storing the approved route with the list of confirmation IDs.

[0010] By providing a method capable of contacting the controlling entity of a claimed region when planning a route, a user is able to plan a route which accounts for restrictions between an origin and destination. For example, when planning a route between A and B, it may be trivial to determine whether a region is unclaimed (in which the vehicle is free to pass through, without needing to comply with an associated set of rules) or restricted (in which case the vehicle cannot pass through under any circumstances) - such information may be publicly available and easy to determine, e.g. from a map.

[0011] However, there may also exist a controlled region - a region where the ability of a vehicle to pass through is at the discretion of the entity which controls the region. In this situation it is not simple to determine whether a vehicle will be allowed to pass through that region, as permission to pass through the region may be at the discretion of a controlling entity.

[0012] By contacting the controlling entity of claimed regions as part of the travel route planning process, the method is able to plan better routes by enabling the vehicle to pass through previously uncontactable regions.

[0013] In a particular embodiment, the vehicle comprises an aerial vehicle; the claimed and unclaimed regions comprise airspaces wherein the shape of the airspaces may be defined by a surface and a corresponding altitude range; and the travel route comprises a flight plan for the vehicle.

[0014] In another particular embodiment, the vehicle is an unmanned drone.

[0015] This method is particularly advantageous when used with an aerial vehicle, the regions comprise airspaces, and the travel route being determined is a flight plan.

[0016] As discussed below, aerial vehicles are being increasingly used, yet the current method for requesting a flight plan is slow, prone to human error, and difficult to scale.

[0017] By contrast, the claimed method is particularly advantageous in allowing increased automation of planning flight plans. This is particularly beneficial where the vehicle is an unmanned drone, where the ability to reduce the need for human intervention may help to improve efficiency and scalability, and is particularly desirable.

[0018] In a particular embodiment, whilst performing the step of contacting the controlling entity of each claimed region to request permission to travel through the region, regions for which a valid approval reference ID along the potential route have already been obtained for a previous potential route are not contacted again.

[0019] By providing a method which does not contact regions for which a valid approval reference ID along a potential route has already been obtained, the efficiency of the method is improved, and the amount of data transferred between a vehicle operator and a controlling entity is reduced.

[0020] Whilst searching for a valid route for the vehicle to travel across (i.e. a route where all controlled regions give the vehicle permission to cross) the operator may contact regions to request permission to travel through the region along a first route, which is granted, but that route may then be rejected (e.g. due to a different region along the route rejecting the route). The operator may then plan a second route involving the controlled region which the vehicle has already been approved to travel through. By reusing the previously obtained approval ID, the method is able to reduce the time spent waiting for the controlled region to send another approval reference ID, and reduce the amount of data sent transferred between a vehicle operator and a controlling entity (as the operator only needs to contact the controlled region once, not twice or more).

[0021] In a particular embodiment, determining whether a potential route passes through a previously disapproved region is performed preferably by determining whether a disapproval reference ID is stored for that region. If the potential route is determined to pass through a through a previously disapproved region, a subsequent potential route between the origin and destination is determined.

[0022] By providing a method capable of determining if a potential route passes through an already disapproved region, the efficiency of the method is improved, and the amount of data transferred between a vehicle operator and a controlling entity is reduced.

[0023] If a route passes through a region which has already been rejected or disapproved, the method may determine that the subsequent route will be rejected without needing to contact any further claimed regions. This allows the method toreduce the amount of data transferred between a vehicle operator and controlling entities, as the operator does not need to contact controlling entities regarding a route which is guaranteed to be rejected.

[0024] In a particular embodiment, determining a route involves minimising the distance travelled by the vehicle and I or the time the vehicle spends travelling between the origin and destination points.

[0025] By determining a proposed route by minimising distance and / or time travelled by the vehicle, the method produces quicker travel routes which are typically preferred by vehicle operators.

[0026] In a particular embodiment, determining a subsequent potential route between the origin and destination includes: prioritising routes which include regions where a valid approval reference ID has already been obtained.

[0027] By prioritising routes which include regions where a valid approval reference ID has already been obtained, the method reduces the amount of data that needs to be sent to find an allowable route. Specifically, if approval reference ID’s can be reused for subsequent potential travel routes, then selecting a route where, for example, the operator already has approval reference ID’s for 2 / 3 of the claimed regions along the route, then the amount of data the operator needs to send for that route is reduced, since the operator only needs to contact the one remaining claimed region, and the chances of finding an allowable route sooner may be increased.

[0028] In a particular embodiment, the method further comprises providing the approved route to the guidance system of a vehicle for the vehicle to follow.

[0029] By providing the route to a vehicle’s guidance system, the vehicle is able to follow the approved route with reduced human intervention. This may improve and increase the autonomy of the vehicle.

[0030] In a particular embodiment, the list of claimed regions within the surrounding area is obtained from an external database which defines the geographical extent of the region using GPS coordinate data and altitude data, and where an associated smart contract address is published.

[0031] By providing a method which is able to obtain information regarding claimed regions and associated smart contract address information from an external database, the method allows a vehicle or operator to obtain up-to-date information regarding claimed regions without requiring local storage.

[0032] In a particular embodiment, contacting a controlling entity of each claimed region involves submitting a travel route request to a device, such as a computerhosting or storing a smart contract. The device hosting the smart contract provides an approval or disapproval reference ID depending on whether the device hosting the smart contract approves or disapproves the potential route.

[0033] In a particular embodiment, requesting permission to travel through the region comprises providing information to the controlling entity of a claimed region, and the device hosting the smart contract compares the received information with a set of rules associated with the region, wherein the rules define criteria the vehicle or potential travel route must meet in order for the travel route to be approved, and approving the request to travel through the region based on whether the rules are met, or rejecting the request if they are not.

[0034] By providing a method which incorporates the use of smart contracts in approving or disapproving routes, the method increases its ability to be automated. Smart contracts are computer programs able to automatically approve or disapprove a contract based on whether certain rules are met. By applying this to vehicle route planning, a smart contract can determine whether or not to allow a vehicle to pass through a claimed region on their proposed travel route based solely on information provided by thee operator, without requiring human approval by the regions controlling entity. This improves the efficiency and scalability of the method.

[0035] In a particular embodiment, the information or data supplied preferably comprises some or all of an origin point, destination point, time of departure, time of arrival, type of vehicle, license information of a vehicle operator, or a cargo being carried, and the rules preferably comprise some or all of time periods vehicles may pass through a region, allowed types of vehicles, vehicle noise, license information of a vehicle operator, or types of cargo.

[0036] The information supplied by an operator, or the rules associated with a smart contract, may relate to various features of the vehicle to better define the types of vehicles that may pass through an area. For example, the rules may require the operator to verify they have the correct licencing information first of all.

[0037] In a particular embodiment, approval or disapproval reference IDs are stored by sending this information to a local wallet.

[0038] By storing approval and disapproval ID in a local wallet, the reference ID’s can be used by operator later without needing to obtain the reference ID’s from a remote server, thereby reducing the amount of data the operator needs to send out.

[0039] According to an aspect of the present invention a system for determining a route for a vehicle between an origin and designation is provided. The system comprises a storage system, configured to store executable code, a controller,configured to execute the stored code, and a user interface, configured to communicate with an operator.

[0040] According to an aspect of the present invention a system for navigating a vehicle along a route between an origin and designation is provided. The route between the origin and destination traverses one or more regions and each region has associated rules defining whether a particular request to enter each region is approved or denied. The system comprises: processing means configured to determine a route between the origin and destination wherein the route only traverses regions which approve a request to enter each region and wherein each request to enter each region is approved or denied based on the rules associated with each region.

[0041] This provides an alternative embodiment of the invention capable of allowing a vehicle to navigate between and origin and destination whilst accounting for regions with rules defining what vehicles may pass through.

[0042] The above and other features will become apparent from the following description and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The following description is made with reference to aerial vehicles such as drones by way of example only. However, embodiments of the may advantageously be used by any aerial vehicle including and not limited to fixed wing aircraft, nonfixed wing aircraft, such as helicopters, hovercraft and so on. Further, embodiments of the invention may be used in other travel industries, such as rail, coach, car, or indeed in any environment where travel between an origin and destination is restricted in terms of the route or space through which the vehicle is allowed to pass.

[0044] The following embodiments described may be implemented using a C++ programming language using for example an OpenCV library. However, this is exemplary and other programming languages known to the skilled person may be used such as JAVA, and .xml.

[0045] In order to best describe the manner in which the above-described embodiments are implemented, as well as define other advantages and features of the disclosure, an exemplary detailed description is provided below and is illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the invention and are not therefore to be considered tobe limiting in scope, the examples will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0046] Figure 1 is a schematic illustration of various regions which may segment an area. In one embodiment, these regions may represent airspaces;

[0047] Figure 2 is a schematic illustration of the functionality performed by a device or computer program when executing a smart contract interaction between two parties;

[0048] Figure 3 is a schematic illustration demonstrating generation of a flight plan request for use by a vehicle travelling along route between two points by requesting permission to fly a particular route through a series of controlled airspaces;

[0049] Figure 4 is a flow chart illustrating the steps which may be performed to generate an approved vehicle travel route;

[0050] Figure 5 is a flow chart illustrating the steps that may be followed following a response from a controlling entity associated with a region, depending on whether the flight plan request is approved or disapproved;

[0051] Figure 6 is a schematic illustration of a Distributed Application (DApp) which can be used by an operator to perform the method steps discussed with respect to figures 4 and 5;

[0052] Figure 7 is a further schematic illustration of the DApp shown in figure 6, showing the interactions between the operator, DApp, and blockchain network;

[0053] Figure 8 is a schematic diagram of the interactions or data flow between the operator, front and back ends of the DApp, blockchain network and nodes, smart contracts, and entity which provides information relating to the surrounding region (i.e. a yellow pages service) when planning a travel route, for example when performing the method steps of figures 4 and 5; and

[0054] Figure 9 shows an example of code that may be stored by the operator as confirmation the flight plan has been accepted and confirmed. Types of data that may be stored may include an operator ID, the date and time, vehicle type and ID, transport type, origin, destination, and a confirmation ID alongside the ID of the airspace that provided it.DETAILED DESCRIPTION

[0055] Various embodiments of the disclosed methods and arrangements are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in therelevant art will recognize that other components, configurations, and steps may be used without parting from the scope of the disclosure.

[0056] Figure 1 schematically illustrates a number of regions which may segment an area.

[0057] An area may be split up into one or more regions. These regions may be controlled by a controlling entity. The controlling entity may have the authority to set rules regarding who and what vehicles are able to enter the region.

[0058] In one embodiment, these regions may correspond to airspaces. The shape of an airspace may be defined as a three dimensional shape. This shape could be described by a surface and a corresponding altitude range. For example, the shape of the airspace could correspond to a circle, as shown by region 100, with an altitude range between ground level and 1000 meters.

[0059] However, the surface need not be limited to a circle, as with airspace 100. The surface may be a square as shown with airspace 106, a triangle, pentagon, or any other shape. The airspace surface need not be a regular shape, but may instead be irregular. An airspace may correspond to an irregular shape between other defined airspaces, for example with airspace 108 which exists in the space between airspaces 100, 102, 104, and 106. Additionally, the shape of the airspace surface may change at different altitudes. It should be noted that airspaces do not necessarily need to tessellate a region or area so that there are no gaps between regions. For example claimed airspaces may be separated by unclaimed airspaces. However, in some cases adjacent airspaces may tesselate with one another such that there are no gaps between the adjacent or neighbouring airspaces.

[0060] For example, an airspace for an airport could be the entire airport infrastructure with the runways and associated air lanes up to a certain altitude in which airport operation want to control access to any object.

[0061] In another example, an airspace for a residential area could be the surface of that area coupled with an altitude in which operating a flying object like a drone could impact the populations noise or privacy.

[0062] An airspace may be claimed by a controlling entity. Controlled airspaces 100, 102, 104, and 106 may have corresponding controlling entities 200, 202, 204, and 206.

[0063] There may be a number of reasons for an entity to claim an airspace. For example, it can be a way to control the traffic of flying objects like drones over a dense area. This could also limit the type of operations vehicle may perform within the airspace, for example not allowing vehicles to carry passengers under a certainaltitude over a residential area. Entities such as police or firefighters could have priority and access through any airspace, even without meeting the rules associated with the controlled airspace.

[0064] The controlling entity for an airspace may be any eligible entity, for example an entity which can be directly impacted by any flying objects entering its direct airspace. An example of an eligible entity could be an airport within a region.

[0065] An authority 300 may validate eligible entities and airspace claims of each controlling entity 200. The authority 300 defines the governance of airspace attribution and definition. For example, there may be a qualification of an airspace and its ownership based on criteria such as population density, fastest access to some aggregation points like airports, train stations, or business zones.

[0066] There may also be some regions or airspaces unclaimed or unmanaged, with no controlling entity. These unmanaged airspaces may take the form of a space between claimed airspaces, for example airspace 108. These unclaimed airspaces may have no rules restricting what vehicles may pass through the airspace.

[0067] When an entity has been assigned as the controlling entity of an airspace, there may also be a definition of the rules to be applied. These rules may define what vehicles may pass through a given region or airspace, and may include rules relating to the type of vehicle that can pass through a given region, the date, the time, who is using the vehicle (e.g. if the vehicle is a police, medical, or firefighter vehicle), the time the vehicle will enter or exit the region, the cargo carried by the vehicle, the average or maximum speed of the vehicle, the average or maximum noise generated by the vehicle when travelling, and any licence information associated with the vehicle or vehicle operator.

[0068] Operators are identified as entities allowed to request a flight plan with airspace owners or controlling entities. They may correspond to human operators who manually control vehicles during transportation, or may correspond to an automated vehicle driver, such as an Al or automated controller which controls the vehicle. They may be authenticated by the same authority 300 that classifies airspaces. Operators may be classified per type, as a drone operator to carry goods unmanned, as an eVTOL operator to carry passengers or as a security service for example.

[0069] Security services such as police or firefighters are operators with a specific attribute. This attribute may mean the operators cannot be denied access through aclaimed airspace. To book a flight plan through an airspace an operator should be fully identifiable as an entity and with a type.

[0070] Rules may be predefined by the authority 300 using templates depending on the features or type of region. For example, there may be templates for residential areas as a function of the population density. For example, regions with a high population density may have stricter limits of flight times, cargo a vehicle may carry, and the noise generated by the vehicle when travelling, when compared to a region with a lower population density.

[0071] A set of rules for residential area with high density may for example:• Limit the type of vehicle• Prevent vehicle travel out of business hours• Prevent vehicle travel below this within certain areas of the region, e.g. prevent flight below a certain altitude• Request unmanned vehicles to provide some certifications

[0072] Whereas a set of rules for residential area with low density may• Allow vehicle travel anytime• Allow any type of vehicle• Allow vehicle travel only between two waypoints

[0073] Airspaces may also be classified based on the rules associated with the airspace. For example, the UK standard classifies airspaces between classes A and G. Class G is an uncontrolled airspace with no restrictions on which aircraft can enter it, any equipment the aircraft must carry, or on the routes taken by the aircraft. In a class A airspace, all aircraft passing through the airspace are subject to Air Traffic Control clearance. Further, Air Traffic Control separates each flight be a predetermined distance.

[0074] An airspace claimed by a vertiport may use another template depending on its gate capacity for example. An airspace over an activity area may use another template depending on the type of goods to be carried and transported.

[0075] The templates or sets of rules associated with regions may be maintained and published centrally. Any claimed region may be managed by those predefined and agreed set of rules to avoid inconsistency for operators requesting flight plans.

[0076] Figure 2 is a schematic illustration of the functionality performed by a device or computer program when executing a smart contract interaction between two parties.

[0077] Whilst the example in figure 2 shows an interaction for a flight plan request, this smart contract interaction functionality could be used to generate any travelrequest through controlled regions, and need not be limited to aerial travel or flying vehicles.

[0078] A smart contract interaction may occur between a vehicle operator and the controlling entity for a region or airspace. The vehicle operator may contact the controlling entity using a user interface.

[0079] The user interface for the operator could be a web browser-based GUI that is the front-end of a Decentralized Application (DApp). The DApp may be written in Javascript, but could alternatively be written in C, C++, Python, or any other programming language. A DApp may be a program that accepts and provides communications with the operator or it may be very complex with interactions with multiple databases. The DApp may interface with the Smart Contracts that are running on a Blockchain node through the DApp backend, allowing the operator to interact with them and request flight plans.

[0080] A claimed airspace smart contract can be described as a set of events associated with a set of rules and assets. Any update on that asset may trigger an event to the operator.

[0081] An example of a smart contract interaction that may occur between an operator and a controlling entity is shown in figure 2.

[0082] Firstly, having previously established that an operator 400 wishes to pass through a region I airspace 100 controlled by controlling entity 200, the operator may then submit a request to the relevant smart contract associated with that entity. As part of this request, the operator may provide information such as operator type, vehicle type, flight type, scheduled time of departure, scheduled time of arrival, origin point, destination point, or any additional information which may be used to evaluate whether the vehicle meets the rules associated with the controlled region and smart contract.

[0083] On reception of this request the smart contract processes that event using coded rules and information provided by the operator. That processing generates a new event 500. The information provided along with the smart contract request may be stored.

[0084] This information is then evaluated to see whether the vehicle meets the rules associated with the controlled region and smart contract.

[0085] If the vehicle is found to not meet some or all of the rules associated with the smart contract, then the request may be rejected 510. The smart contract may then contact the operator 400 to inform them that their request has been rejected. As part of this, the smart contract may provide the operator with a reference IDindicating that the flight request has been denied. The smart contract may also provide the reason(s) why the request was rejected.

[0086] If the flight request has been rejected because the operator has failed to provide the smart contract with information necessary to check whether the operator and vehicle meet one of the smart contracts rules, the smart contract may inform the operator about the missing information that is required. The smart contract may prompt the operator to re-submit their flight plan request with this additional information.

[0087] When the operator 400 receives the disapproval reference ID, the operator may store this reference ID for later use. This reference ID may be used by the operator when making a request, for example when planning alternative flight plans. If the operator sees that a disapproval reference ID has been issued for a particular region, then the operator may disregard any proposed flight plans which pass through that region without contacting any further regions along the proposed flight path.

[0088] Alternatively, the flight plan request may be approved 520 by the smart contract. This may correspond to the information provided by the operator meeting some or all of the rules set out in the smart contract. . The smart contract may then contact the operator 400 to inform them that their request has been approved. As part of this, the smart contract may provide the operator with a reference ID indicating that the flight request has been approved. The smart contract may also provide the reason(s) why the request was approved.

[0089] When the operator 400 receives the approval reference ID, the operator may store this reference ID for later use. An approval reference ID may take the form of refl D=1. A disapproval reference ID may take the form of reflD=0. This reference ID may be used by the operator when making a future flight plan request, for example when planning alternative flight plans. If the operator sees that an approval reference ID has been issued for a particular region, then the operator may prioritise or favour any proposed flight plans which pass through that region.

[0090] The operator may contact the smart contract again after the flight plan has been approved 520 in order to finalise and confirm the flight plan 530. This can be particularly useful where the flight plan to be followed by the vehicle passes through multiple controlled airspaces and requires multiple confirmations from different smart contracts. Once an approval reference ID has been obtained from each smart contract along a proposed flight plan, the operator may contact each smart contract again to finalise confirmation of the travel route. As part of this, the operator mayprovide the smart contract with the previously obtained approval reference ID in order to reduce the need for rechecking that the vehicle meets the airspaces rules.

[0091] This final step can be particularly useful when airspaces limit the number of aerial vehicles which can travel through it, and grant vehicles permission to travel through the airspace on a first come first serve basis. An operator can request to pass through an airspace and have their claim prioritised before later vehicles, even if the final travel route has not been finalised yet. Later, when the final travel route has been obtained (i.e. the vehicle has received an approval reference ID from every claimed airspace along a travel route) the travel route can be confirmed. As part of this, the operator may receive confirmation the travel route has been approved along with a confirmatory reference ID.

[0092] Figure 3 is a schematic illustration demonstrating how a vehicle may plan a travel route between two points.

[0093] Figure 3 shows how an area may be segmented into various claimed 700, 710, 720, 730, and 750 and unclaimed 740 airspaces. These claimed airspaces may have associated smart contracts 705, 715, 725, 735, and 755 as described with reference to figure 2.

[0094] In figure 3, an operator may seek to fly a vehicle, such as a drone, between points A and B. Once the start and end points of the flight plan are decided, the operator may obtain information relating to the surrounding region. This may involve contacting an entity which records and may provide the list of airspaces, their rules, and an address for the smart contracts associated with these airspaces. For example, this may be authority 300, or a separate entity entirely.

[0095] The operator may propose a first flight plan. A proposed flight plan is a travel route that the operator would like the vehicle to travel along in order to travel from A to B, but that the operator has not yet had confirmation from all the airspaces along the proposed flight plan that it has approval to pass through. This flight plan may correspond to the shortest distance route, the quickest route, or may be optimised for any other feature. The first flight pan passed through claimed airspaces 700, 720, and 750.

[0096] The operator may contact all airspaces simultaneously, or may contact the airspaces in a particular order, for example in the actual flight path order. This may help to reduce unnecessary computations should the flight plan be rejected, by allowing the operator to stop contacting airspaces along a potential route once an airspace has rejected the flight plan, since the flight plan cannot be used no matter how the subsequently contacted airspaces respond to the request.

[0097] The operator may first contact the smart contract 705 associated with airspace 700. It is found that the operator vehicle meets the rules associated with this airspace, and so the operator may be granted approval to pass through the airspace and provided with an approval reference ID.

[0098] Airspace 720 may be a restricted airspace, meaning no vehicles are allowed to travel through it. The operator may contact a smart contract 725 associated with airspace 720. The smart contract 725 may automatically reject the flight plan 510 due to it being a restricted airspace.

[0099] Alternatively, airspace 720 may have no smart contract 725. Instead, when contacting authority 300 to obtain the list of airspaces and their rules, airspace 720 may be listed as “restricted”, corresponding to no vehicles being able to pass through that airspace. The operator may therefore understand there is no need to request a flight plan 500 with that airspace, as it is certain to be denied. The operator may mark this airspace as restricted or disapproved, and may generate its own disapproval reference ID.[000100] As airspace 720 has been disapproved, this means the first proposed flight plan is no longer valid. The operator may continue to contact other airspaces along the route, such as airspace 750, to request permission to travel through the region. This information may be used by the operator when planning subsequent routes; for example, the operator may prioritise selecting flight plans which make use of airspaces for which the operator already has an approval reference ID in order to reduce the number of further requests the operator must make.[000101] The operator then selects a second route. This route may be the most optimised route for some parameter (e.g. minimises time spent travelling, minimises distance travelled) after the first route. The operator may also prioritise routes where the operator already has approval reference IDs for some of the airspaces. For example, in this case the operator already has an approval reference ID for airspace 700. The operator may therefore not search for the second fastest route after the first route, but instead search for the second fastest route after the first route which also passes through airspace 700.[000102] Additionally, the operator may avoid generating proposed routes which pass through airspaces which have already rejected the vehicle for a previous flight plan. This may help to avoid the operator generating flight plans which are certain to be rejected, improving efficiency.[000103] The operator may not contact smart contract 705 in order to request an approval reference ID if an approval reference ID has already been obtained for aprevious flight plan. Alternatively, the operator may still need to contact smart contract 705 to request a new reference ID due to the change of flight plan, or due to other changes to the request (e.g. change in the time the vehicle will enter or exit the airspace).[000104] The operator may then contact smart contract 715 in order to request entry to airspace 710. The operator may submit a flight plan request 500, along with information (e.g. the time the vehicle will enter and exit the airspace). In this example, airspace 710 may have an associated rule on the smart contract 715 which prohibits vehicles travelling in airspace 710 between the hours of 7pm and 7am. The vehicle in this example may wish to enter the airspace 710 at time 11pm, and may submit this information as part of its flight plan request 500. The smart contract may then compare the information provided its set of rules, and determine that the vehicle does not meet one or all of these rules. The flight plan request is therefore rejected 510.[000105] After this, the operator determines a third potential flight path. This may be the third fastest flight plan which passes through approved airspace 700 and avoids disapproved airspaces 720 and 710.[000106] As with airspace 700, the operator contacts airspace 730 via smart contract 735, and receives approval, along with an approval reference ID.[000107] The flight plan passes through unclaimed airspace 740. This airspace does not have a controlling entity, and has no smart contract or enforced rules for vehicles to follow. As such, the operator does not need to request permission from a controlling entity or smart contract to travel through this airspace.[000108] As with airspace 700, the operator contacts airspace 750 via smart contract 755, and receives approval, along with an approval reference ID.[000109] Once approval and an approval reference ID has been obtained for each claimed airspace along a flight path, the operator confirms the flight plan request with each smart contract for each airspace along the flight path. This may involve sending the approval reference ID received from each smart contract back to the contract along with some data to confirm the final flight path. This data may include an airspace ID, operator ID, date and time, and the previously supplied approval reference ID. When the final flight path is confirmed with the smart contract 530, the smart contract may then send confirmation to the operator that the final flight plan is approved, which may include a confirmation reference ID. These confirmation IDs may be used to identify that a vehicle has permission to be in an airspace when it travels along the flight path.[000110] Figure 4 shows a flow chart 1000 illustrating the steps required for to plan a vehicle travel route. Specifically, the method determines a travel route for a vehicle between an origin point and a destination point through a set of managed regions.[000111] At step 1010, the operator may determining the origin point and the destination point, and use these points to define an area surrounding the origin and destination points. The origin and destination points may correspond to the start and end points of the flight plan - e.g. where the vehicle is going to start from, and where the vehicle is going to finish. These points may be used to define a surrounding area around the origin and destination points, with the intention to identify an area that will encompass the flight path of the vehicle. This may be done by using the distance, X, between the origin and destination points in a straight line. The surrounding area could then be a square with side length X with its centre in the middle of the origin and destination points. Alternatively, the area could be a circle of radius X with its centre in the middle of the origin and destination points. However, any shape could be used to define the surrounding area, so long as both the origin and destination points are encompassed within it. A bigger surrounding area will provide the operator with a larger number of potential flight plans to choose from, but will also increase the computing power and data transfer required. The size of the surrounding area can therefore be altered in order to optimise between these two factors. This step can be performed by an operator filing using a Web III using a DApp front end, as shown in step 2010 of figure 8. The operator may input the origin and destination points and defining the surrounding area.[000112] This step may involve the operator submitting a flight plan between an origin and destination point through its DApp webservice. This submission may include data such as an operator ID, the date I expected schedule, origin and destination coordinates, the type of vehicle, the type of transport, and a preferred route based on the distance or travel time.[000113] At step 1020, the operator retrieves information about the surrounding area, including a list of regions inside of the surrounding area. This may involve retrieving information about any region I airspace that passes through the surrounding area defined in the previous step. This may involve having the DApp front end call an entity, such as authority 300, using an Application Programming Interface (API) to retrieve the list of airspaces within the defined surrounding area, as shown in step 2020 of figure 8. This list of airspaces may include information regarding the geographical extent of the airspace, any type (e.g. rules template) associated with the airspace, the controlling entity which owns or controls the airspace, a list of rulesassociated with the airspace, and an address for the smart contract associated with the controlled airspace.[000114] This step may involve the DApp of the operator retrieving the list of claimed airspaces between the origin and destination points through a request to the yellow pages (e.g. authority 300) to get the list and attributes of all claimed airspaces in that area. Examples of claimed airspace attributes include an airspace ID, an associated perimeter (e.g. a shape as a set of GPS positions and an altitude range), rules associated with the airspace (this could be listed as a set of standard rules using JSON format, or the type or class of the airspace could be provided which is associated with a certain rules template, which the DApp may either have stored or can obtain from a separate stored location), and a smart contract address associated with the airspace where a flight plan request can be submitted.[000115] At step 1030, the operator determines a potential route for the vehicle to follow between the origin point and destination point. This may be performed by the DApp front end trying the shortest distance route between the origin and destination points (e.g. a straight line). Alternatively, the DApp may optimise the potential route for other parameters, such as routes with the shortest time, lowest energy consumption, or where the vehicle arrives at the destination point or exits an airspace closest to a desired time.[000116] The operator may determine its preferred path between the origin and the destination. For the operator the preferred path can be based on distance, estimated energy consumption, travel time, or estimated time of arrival. Alternatively, by compiling the optimised routes for multiple attributes the operator DApp may determine the preferred path and the list of claimed airspaces to fly through.[000117] At step 1040, the operator determines what claimed and unclaimed regions the planned route passes through. This may involve using information obtained regarding the various airspaces in the surrounded area in step 1020.[000118] At step 1050, the operator contacts a controlling entity of each claimed region to request permission to travel through the region. An example of this may having the operator contact a smart contract associated with each claimed airspace. The address for each smart contract may be obtained during step 1020, from an entity which stores information regarding airspaces. The operator DApp may submit a flight plan request to each of these smart contracts, with the request containing information such as an operator ID, the date and potential flight schedule, the type of vehicle, the type of cargo being carried, whether the vehicle is associated with acertain entity (such as the police, fire brigade, or ambulance service), licencing information regarding the vehicle or vehicle operator, the intended time the vehicle will enter I exit the airspace, and information regarding credits to allow the vehicle to pass through the airspace, for example to pay a toll. This may involve the DApp front end identifying the corresponding smart contracts for each controlled region the potential route passes through, and submitting the various flight plan requests for each controlled airspace to the DApp backend, as shown in step 2030 of figure 8. The DApp backend may then send a corresponding event through a signed transaction to each identified claimed airspace along the potential route, as shown in step 2040 of figure 8. Each airspace smart contract receives a transaction event from the operator node for the flight plan request, which includes any mandatory information required by the smart contract, as shown in step 2050 of figure 8.[000119] This may involve the operator submitting a flight plan request to each claimed airspace identified by sending a request event to each smart contract. This may involve providing the smart contract with data such as an operator ID, proposed date and schedule, the type of vehicle, and the type of transport.[000120] At step 1060, the operator receives a response from the controlling entity. Depending on whether the claimed airspace approves or denies the flight plan request, different subsequent steps may occur. Details of additional steps which can be performed following step 1060 are shown in figure 5. This may involve each smart contract sending a transaction to the operator node, as shown in step 2060 of figure 8. The blockchain node verifies the transaction and sends the received event to the DApp back end, as shown in step 2070 of figure 8. The DApp front end receives the flight plan request and reference ID for each airspace, as shown in step 2080 of figure 8. If all airspace smart contracts approved the proposed route, then the DApp front end can confirm the route, as shown in step 2081 of figure 8. If some airspace smart contracts reject the proposed route, then the DApp front end calculates a new route and sends flight plan requests to the new airspace smart contracts until it can confirm a route, as shown in step 2082 of figure 8.[000121] At step 1061 , the operator receives an approval reference ID from the controlling entity. The claimed airspace smart contract sends its approval by generating an event. This event may include data such as an airspace ID, and operator ID, the date and schedule of the flight plan, and an approval reference ID.[000122] At step 1062, the operator stores this approval reference ID. This data may be stored locally to the DApp and operator, or may be stored remotely. The data may be stored in a blockchain wallet.[000123] Alternatively, the controlling entity may disapprove of a travel route. At step 1063, the operator receives a disapproval reference ID from the controlling entity. The claimed airspace smart contract sends its disapproval by generating an event. This event may include data such as an airspace ID, an operator ID, the date and schedule of the flight plan, and a disapproval reference ID.[000124] At step 1064, the operator stores this disapproval reference ID. This data may be stored locally to the DApp and operator, or may be stored remotely. The data may be stored in a blockchain wallet.[000125] At step 1065, the operator determines a subsequent potential route between the origin and destination. This process may be similar to that discussed in step 1030. As the operator will already possess information about the surrounding area and airspaces the proposed route passes through, the operator can optimise routes to avoid potential routes the operator knows will be disapproved. For example, the operator may be aware that an airspace is restricted, or may have already have had permission denied for a previous potential route the operator generated. As such, the operator may automatically reject all routes which pass through such a region, or avoid generating any such routes at all. This may save computing power and reduce unneeded data transfer, as the operator does not spend time requesting permission to travel through an airspace for a flight plan the operator already knows will be rejected.[000126] At step 1066, the operator contacts the controlling entity of each claimed region the planned route passes through to request permission to travel through the region, except if a valid approval reference ID for[000127] After performing step 1060, an approved route is obtained, where an approved route has an approval reference ID granting permission to travel through a region obtained and stored for each region along a potential route. This may include the DApp front end receiving all approvals from all airspace smart contracts for the proposed route and submitting the route to the operator for confirmation through a Web III, as shown in step 2090 of figure 8.[000128] At step 1070, the operator sends a travel request confirmation to each controlling entity whose region the approved route passes through using the approval reference ID. If the operator confirms the route the DApp front end may send flight plan confirmation to each airspace smart contract using the approval reference ID received with their previous approval, as shown in step 2100 of figure 8. The DApp back end may then send a confirmation event through a signed transaction to each smart contract associated with the proposed route, as shown instep 2110 of figure 8. Each airspace smart contract may then receive a confirmation event for a flight plan request with the mandatory information signed by the node of the operator to confirm the flight plan request, as shown in step 2120 of figure 8.[000129] This may involve the DApp sending a confirmation request to all controlling entities I smart contracts as soon as the operator DApp receives flight plan request approvals from all claimed airspaces for a complete route from the origin to destination points. In response to this, each controlling entity I smart contract may generate a confirmation event including data such as the airspace ID, operator ID, flight plan date and schedule, approval reference ID, and confirmation ID.[000130] At step 1080, the operator stores the approved route with the list of confirmation IDs. These confirmation IDs may be used by the operator and vehicle to prove the vehicle has permission to travel through a given airspace. For example, the vehicle may be asked to provide identification before it enters a given airspace, which could include a confirmation ID amongst other identifiers, such as a vehicle ID or operator ID.[000131] This may include the operator DApp storing all confirmation IDs as proof of the approved flight plan in its local wallet.[000132] The flowchart illustrates the operation of an example implementation of systems, methods, and computer program products according to various embodiments of the present invention. Each block in the flowchart or block diagrams may represent a module comprising one or more executable computer instructions, or a portion of an instruction, for implementing the logical function specified in the block. The order of blocks in the diagram is only intended to be illustrative of an example. In alternative implementations, the logical functions illustrated in particular blocks may occur out of the order noted in the figures. For example, two blocks shown as adjacent one another may be carried out simultaneously or, depending on the functionality, in the reverse order. Each block in the flowchart may be implemented in software, hardware or a combination of software and hardware.[000133] Communications between the various entities described previously and subsequently may be achieved using a communications network which may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephony communication system (such as 3G, 4G, or 5G systems), or a satellite communication system. Communications may use communication protocols such as Internet Protocol (IP), File Transfer Protocols (FTP), and Bluetooth Protocols. Communications may be encrypted.[000134] The various software and communications described herein may be implemented using any appropriate functionality. In some embodiments, the application (e.g. the DApp) used by the operator to interact with the controlling entity or smart contract may be a Javascript application. Communications may be realised according to the Hypertext Transfer Protocol (HTTP), for example, and may make use of any wired or wireless local area networks which may be available. Alternatively[000135] Figure 6 shows a schematic example of the Decentralized Application, DApp, system the operator may use to determine and submit a flight plan. The DApp may come with a front-end (for example a webservice to find preferred routes and submit flight plans) and a back-end (for example a blockchain node to submit and receive transactions).[000136] Each operator DApp can be part of a distributed ledger, for example a blockchain network. This ledger may be private or public.[000137] The user interface for an operator could be a web browser-based GUI that is the front-end of a Decentralized Application (DApp) written in JavaScript for example.[000138] A DApp may be a program that accepts and provides basic communications with the operator, or can additionally have interactions with multiple databases. The DApp may also interface with the Smart Contracts that are running on a Blockchain node through the DApp backend. The Blockchain network can be public (Ethereum, Tezos) or a private enterprise (Hyperledger).[000139] The process for an operator to request a flight plan (from A to B) as described above may involve the operator retrieving the definition of the area with existing claimed airspaces. The operator may file its flight plan request through the DApp front-end by providing the mandatory information like origin, destination, schedule, type of flight, type of aircraft.[000140] The DApp front-end may identify the shortest path and retrieve the different owned airspaces concerned through a yellow page service listing airspaces and the address of associated smart contract.[000141] The yellow pages could be provided from a central service exposing an API or could be hosted on a distributed network like Interplanetary File System (IPFS). By providing the departure and destination location, the yellow pages returns the list of owned airspace smart contract addresses in that zone. Each airspace owner should register its smart contract within the yellow pages service to be listed. Asmart contract address uniquely identified a smart contract on a blockchain network and can only send transactions in response to receiving a transaction.[000142] The DApp front-end sends a request through the DApp back-end to each smart contract using their address to submit a flight request. The DApp back-end interfaces with the blockchain node typically using a communication protocol like gRPC over Internet or LAN if local.[000143] If one or several smart contracts reject the flight plan then the DApp frontend may receive a notification from the DApp back-end and may find another shortest path avoiding the airspaces which refused.[000144] The DApp front-end will retry until it gets all involved airspaces approvals for a path. As soon as a path has been identified the DApp front-end through the back- end will submit a confirmation to each airspace to finalize the flight plan.[000145] Figure 7 shows a worked example of a how a DApp allows an operator planning a flight plan to interact with the smart contracts stored on a blockchain network, in this case the Ethereum network.[000146] As described above, the operator may interact with the DApp front-end through a III. This front end and III may be coded in HTML. The front-end may interact with the back-end of the DApp, which may be coded in Javascript. The back-end may communicate with the smart contracts located on a blockchain network (e.g. Ethereum) via the operator node. This process may be reversed for the smart contract to communicate with the operator.[000147] Figure 8 shows a schematic diagram of the interactions between the operator, front and back ends of the DApp, blockchain network and nodes, smart contracts, and entity which provides information relating to the surrounding region (i.e. a yellow pages service). Details of these steps are given in the discussion of figures 4 and 5 above.[000148] Figure 9 shows an example of code that may be stored by the operator as confirmation the flight plan has been accepted and confirmed. Types of data that may be stored may include an operator ID, the date and time, vehicle type and ID, transport type, origin, destination, and a confirmation ID alongside the ID of the airspace that provided it.[000149] It will be appreciated that the system, device and method may include a computing device, such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a mobile telephone, a smartphone.[000150] The device may comprise a computer processor running one or more server processes for communicating with client devices. The server processes comprisecomputer readable program instructions for carrying out the operations of the present invention. The computer readable program instructions may be or source code or object code written in or in any combination of suitable programming languages including procedural programming languages such as C, object orientated programming languages such as C#, C++, Java, scripting languages, assembly languages, machine code instructions, instruction-set-architecture (ISA) instructions, and state-setting data.[000151] The wired or wireless communication networks described above may be 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 telephony communication system, or a satellite communication system. The communications network may comprise any suitable infrastructure, including copper cables, optical cables or fibres, routers, firewalls, switches, gateway computers and edge servers.[000152] The system described above may comprise 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 an application for a device, or on a dedicated landing web page. Computer readable program instructions for implementing the graphical user interface may be downloaded to the client device from a computer readable storage medium via a network, for example, the Internet, a local area network (LAN), a wide area network (WAN) and / or a wireless network. The instructions may be stored in a computer readable storage medium within the client device.[000153] As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product including computer readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.[000154] The computer readable program instructions may be stored on a non- transitory, 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, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory(SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.[000155] Exemplary embodiments of the invention may be implemented as a circuit board which may include a CPU, a bus, RAM, flash memory, one or more ports for operation of connected I / O apparatus such as printers, display, keypads, sensors and cameras, ROM, a communications sub-system such as a modem, and communications media.[000156] The following clauses provide additional embodiments of the invention: A method for determining a route for a transportation means between an origin and designation through a plurality of regions, the method comprising: a. using the origin and destination to determine the plurality of regions through which a potential route between the origin and destination passes; b. determining, for each of the plurality of regions, whether each region is a claimed region associated with a controlling entity or an unclaimed region not associated with a controlling entity; c. sending a message to each controlling entity associated with each claimed region wherein each message comprises a request for permission to travel at least partially through each region; d. receiving a response from each controlling entity, wherein if permission is granted the response comprises an approval reference identifier, ID, or wherein if permission is denied the response comprises a disapproval reference identifier, ID; e. determining whether each response from each controlling entity comprises a disapproval reference identifier, ID; and f. in response to determining that one or more of the responses from each controlling entity comprises a disapproval reference identifier, ID, determining a subsequent potential route between the origin and destination wherein the subsequent potential route at least partially passes through one or more further regions. The method of clause 1 further comprising approving the route or subsequent potential route if the route or further route only at least partially passes through one or more regions or further regions from which an approval reference identifier, ID, has been received. The method of any preceding clause further comprising: a. determining, for each of the one or more further regions, whether each further region is a claimed region associated with a controlling entity or an unclaimed region not associated with a controlling entity.4. The method of clause 2 further comprising: a. sending a message to each controlling entity associated with each further claimed region wherein each message comprises a request for permission to travel at least partially through each further region.5. The method of clause 3 further comprising receiving a response from each controlling entity associated with each further region, wherein if permission is granted the response comprises an approval reference identifier, ID, orwherein if permission is denied the response comprises a disapproval reference identifier, ID.6. The method of any one of clauses 2 to 4 further comprising: a. determining whether each response from each controlling entity for the subsequent route comprises an approval reference identifier, ID; and b. in response to determining that each response from each controlling entity for the subsequent route comprises an approval reference identifier, ID, sending a travel request confirmation to each controlling entity of each region associated with the subsequent route to confirm the potential route between the origin and destination as a confirmed route between the origin and destination origin and destination.7. The method of any one of clauses 1 to 4 further comprising storing each approval reference identifier, ID, and / or each disapproval reference identifier in a storage means or memory.8. The method of any preceding clause further comprising receiving data defining the origin and destination.9. The method of any preceding clause further comprising storing the approved route with the list of confirmation IDs.10. The method of any preceding clause wherein each region or further region has associated rules defining whether a particular request to enter each region is approved or denied.11 . The method of any one of clauses 1 to 9 wherein the route only traverses regions or further regions which approve a request to enter each region and preferably wherein each request to enter each region is approved or denied based on the or one or more rules associated with each region or further region.12. The method of clause 1 , wherein: the vehicle comprises an aerial vehicle;the claimed and unclaimed regions comprise airspaces wherein the shape of the airspaces may be defined by a surface and a corresponding altitude range; and the travel route comprises a flight plan for the vehicle.13. The method of any previous clause, wherein the transportation means is an unmanned or manned drone.14. The method of any previous clause wherein the step of determining a subsequent potential route only sends one or more requests to each claimed further region associated with the further route for regions for which a valid approval reference ID has not been received.15. The method of any previous clause, wherein determining the potential route or subsequent potential route comprises minimising the distance travelled by the transportation means and I or the time the vehicle spends travelling between the origin and destination points.16. The method of any previous clause, wherein determining the subsequent potential route between the origin and destination comprises: prioritising routes which include regions where a valid approval reference ID has already been received.17. The method of any one of clauses 2 to 16 wherein the method further comprises providing the approved route to the guidance system of the transportation means for the transportation means to follow.18. The method of any previous clause, wherein data defining each region or further region is obtained from a database and / or wherein the or data defines the geographical extent of each region using GPS coordinates data and preferably altitude data.19. The method of any previous clause further comprising sending a request to a database comprising data defining a smart contract address associated with each region or further region.20. The method of any previous clause, wherein contacting each controlling entity of each claimed region comprises submitting the request for permission to travel at least partially travel through each region to a server or computer configured to execute a smart contract, and wherein the computer or server provides an approval or disapproval reference ID depending on whether the server or computer executing the smart contract approves or disapproves the potential route.21 . The method of clause 20 wherein requesting permission to travel through the region comprises providing information, associated with the or a journey between the origin and destination or / and the transportation means or / and cargo, to each controlling entity of each claimed region, and preferably wherein the computer or server configured to execute the smart contract compares the received information with the or one or more of rules associated with each region and preferably wherein the or one or more rules define criteria the vehicle or potential travel route must meet in order for the travel route to be approved, and approving the request to travel through the region based on whether the rules are met, or rejecting the request if the rules are not met.22. The method of clause 21 , wherein the information supplied comprises any one or more of data defining an origin point, destination point, time of departure, time of arrival, type of vehicle, license information of a vehicle operator, or a cargo being carried23. The method of any preceding claim wherein the or one or more rules comprise some or all of time periods vehicles may pass through a region, allowed types of vehicles, vehicle noise, license information of a vehicle operator, or types of cargo.24. The method of any previous clause, wherein approval or disapproval reference IDs are stored by sending the approval or disapproval reference IDs to a digital wallet stored on a further computer or server.25. A system for determining a route for a transportation means between an origin and designation, wherein the system is configured to perform the method steps of any one or more of clauses 1 to 24, the system comprising: the or a storage means or memory configured to store executable code; a processor configured to execute the stored code; and a user interface, configured to communicate with an operator.26 A system for determining a route for a transportation means between an origin and designation wherein the route between the origin and destination traverses a plurality of regions and where each region has associated rules defining whether a particular request to at least partially traverse each region is approved or denied, wherein the system comprises: a. processing means configured to determine the route between the origin and destination wherein the route at least partially only traverses regions for which an approval of a request to enter each region has been received and wherein each request to enter each region is approved or denied based on the rules associated with each region.

Claims

Claims1 . A method for determining a route for a transportation means between an origin and designation through a plurality of regions, the method comprising: a. using the origin and destination to determine the plurality of regions through which a potential route between the origin and destination passes; b. determining, for each of the plurality of regions, whether each region is a claimed region associated with a controlling entity or an unclaimed region not associated with a controlling entity; c. sending a message to each controlling entity associated with each claimed region wherein each message comprises a request for permission to travel at least partially through a region the entity controls; d. receiving a response from each controlling entity, wherein if permission is granted the response comprises an approval reference identifier, ID, or wherein if permission is denied the response comprises a disapproval reference identifier, ID; e. determining whether each response from each controlling entity comprises a disapproval reference identifier, ID; and f. in response to determining that one or more of the responses from each controlling entity comprises a disapproval reference identifier, ID, determining a subsequent potential route between the origin and destination wherein the subsequent potential route at least partially passes through one or more further regions.

2. The method of claim 1 further comprising approving the route or subsequent potential route if the route or further route only at least partially passes through one or more regions or further regions from which an approval reference identifier, ID, has been received.

3. The method of any preceding claim further comprising: a. determining, for each of the one or more further regions, whether each further region is a claimed region associated with a controlling entity or an unclaimed region not associated with a controlling entity.

4. The method of claim 2 further comprising: a. sending a message to each controlling entity associated with each further claimed region wherein each message comprises a request for permission to travel at least partially through each further region.

5. The method of claim 3 further comprising receiving a response from each controlling entity associated with each further region, wherein if permission is granted the response comprisesan approval reference identifier, ID, or wherein if permission is denied the response comprises a disapproval reference identifier, ID.

6. The method of any one of claims 2 to 4 further comprising: a. determining whether each response from each controlling entity for the subsequent route comprises an approval reference identifier, ID; and b. in response to determining that each response from each controlling entity for the subsequent route comprises an approval reference identifier, ID, sending a travel request confirmation to each controlling entity of each region associated with the subsequent route to confirm the potential route between the origin and destination as a confirmed route between the origin and destination origin and destination.

7. The method of any one of claims 1 to 4 further comprising storing each approval reference identifier, ID, and / or each disapproval reference identifier in a storage means or memory.

8. The method of any preceding claim further comprising receiving data defining the origin and destination.

9. The method of any preceding claim further comprising storing the approved route with the list of confirmation IDs.

10. The method of any preceding claim wherein each region or further region has associated rules defining whether a particular request to enter each region is approved or denied.11 . The method of any one of claims 1 to 9 wherein the route only traverses regions or further regions which approve a request to enter each region and preferably wherein each request to enter each region is approved or denied based on the or one or more rules associated with each region or further region.

12. The method of claim 1 , wherein: the vehicle comprises an aerial vehicle; the claimed and unclaimed regions comprise airspaces wherein the shape of the airspaces may be defined by a surface and a corresponding altitude range; and the travel route comprises a flight plan for the vehicle.

13. The method of any previous claim, wherein the transportation means is an unmanned or manned drone.

14. The method of any previous claim wherein the step of determining a subsequent potential route only sends one or more requests to each claimed further region associated with the further route for regions forwhich a valid approval reference ID has not been received.

15. The method of any previous claim, wherein determining the potential route or subsequent potential route comprises minimising the distance travelled by the transportation means and I or the time the vehicle spends travelling between the origin and destination points.

16. The method of any previous claim, wherein determining the subsequent potential route between the origin and destination comprises: prioritising routes which include regions where a valid approval reference ID has already been received.

17. The method of any one of claims 2 to 16 wherein the method further comprises providing the approved route to the guidance system of the transportation means for the transportation means to follow.

18. The method of any previous claim, wherein data defining each region or further region is obtained from a database and / or wherein the or data defines the geographical extent of each region using GPS coordinates data and preferably altitude data.

19. The method of any previous claim further comprising sending a request to a database comprising data defining a smart contract address associated with each region or further region.

20. The method of any previous claim, wherein contacting each controlling entity of each claimed region comprises submitting the request for permission to travel at least partially travel through each region to a server or computer configured to execute a smart contract, and wherein the computer or server provides an approval or disapproval reference ID depending on whether the server or computer executing the smart contract approves or disapproves the potential route.21 . The method of claim 20 wherein requesting permission to travel through the region comprises providing information, associated with the or a journey between the origin anddestination or / and the transportation means or / and cargo, to each controlling entity of each claimed region, and preferably wherein the computer or server configured to execute the smart contract compares the received information with the or one or more of rules associated with each region and preferably wherein the or one or more rules define criteria the vehicle or potential travel route must meet in order for the travel route to be approved, and approving the request to travel through the region based on whether the rules are met, or rejecting the request if the rules are not met.

22. The method of claim 21 , wherein the information supplied comprises any one or more of data defining an origin point, destination point, time of departure, time of arrival, type of vehicle, license information of a vehicle operator, or a cargo being carried23. The method of any preceding claim wherein the or one or more rules comprise some or all of time periods vehicles may pass through a region, allowed types of vehicles, vehicle noise, license information of a vehicle operator, or types of cargo.

24. The method of any previous claim, wherein approval or disapproval reference IDs are stored by sending the approval or disapproval reference IDs to a digital wallet stored on a further computer or server.

25. The method of any previous claim, wherein the plurality of regions includes at least two regions, the at least two regions being controlled by different controlling entities.

26. A system for determining a route for a transportation means between an origin and designation, wherein the system is configured to perform the method steps of any one or more of claims 1 to 25, the system comprising: the or a storage means or memory configured to store executable code; a processor configured to execute the stored code; and a user interface, configured to communicate with an operator.

27. A system for determining a route for a transportation means between an origin and designation wherein the route between the origin and destination traverses a plurality of regions and where each region has associated rules defining whether a particular request to at least partially traverse each region is approved or denied, wherein the system comprises: a. processing means configured to determine the route between the origin and destination wherein the route at least partially only traverses regions for which an approval of a request to enter each region has been received and wherein eachrequest to enter each region is approved or denied based on the rules associated with each region.

28. The system of claim 27, configured to perform the method steps of any of claims 1 to 25.

Images