Patent Description:
The use of aircraft, including for both recreational purposes and for commercial purposes, is becoming increasingly prevalent. As the cost of operating aircraft continues to fall and the ease of operation increases, many new pilots are starting to take part in flight operations. One barrier to entry for new pilots--and an ongoing struggle for even experienced pilots--is being able to properly ensure that a planned flight does not violate any flight restrictions. Even when a pilot can properly review all relevant flight restrictions for a planned flight area before a given flight, there is currently no way for the pilot to remain informed of changes to the relevant flight restrictions between planning and takeoff. The increased use of mobile devices with small, touch-only interfaces only exacerbates these problems.

What is desired are systems that can allow both experienced and novice pilots to easily plan flights to avoid violation of flight restrictions, even when using mobile devices with small touch-only interfaces. What is also desired are systems that will monitor for changes in relevant flight restrictions and proactively notify a pilot when changes are detected before and/or during a flight.

<CIT> discloses a system configured to: mine flight plan data for a current flight plan, navigational data, and vertical situation display data; obtain notification data items originating from onboard avionics systems and systems external to the aircraft that indicate upcoming conditions that will affect the current flight plan; automatically analyze the mined flight plan data and the notification data items to identify a sensed deviation condition; automatically identify an aircraft-related deviation condition from an aircraft failure event; receive flight crew notification of a non-sensed deviation condition; automatically generate a plurality of flight plan deviation options to accommodate a sensed deviation condition, an aircraft-related deviation condition, or a non-sensed deviation condition; and present graphical elements representative of the flight plan deviation options to the flight crew on an integrated interactive graphical user interface.

<CIT> discloses an airspace controller for creating and managing dynamic airspace for different users. The airspace controller may produce different dynamic airspace for each user by continually updating static controlled airspace maps with user-specific flight information including user-planned flights, authorization status of the user's flights, waivers, controlled airspace restrictions, and real-time flight telemetry. The airspace controller may generate a static airspace map for all users with different airspace user interface ("UI") elements at different regions that correspond to different airspace restrictions in effect at those regions. The airspace controller may create dynamic airspace for each user by modifying the static airspace map to include flight UE elements over regions of the static airspace map where user-defined flights are to occur. The flight UE element may include shapes that correspond to flight areas defined for a flight plan, and one of several graphical representations to identify authorization status of the flight.

In some embodiments, a non-transitory computer-readable medium having logic stored thereon is provided, as defined in claim <NUM>.

In some embodiments, a system that includes a user device and a restriction management system is provided, as defined in claim <NUM>.

Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified. Not all instances of an element are necessarily labeled so as not to clutter the drawings where appropriate. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles being described.

<FIG> is a schematic illustration of a system for managing flight operations according to various aspects of the present disclosure. As shown, the system <NUM> includes a pilot <NUM> who wishes to operate an aircraft <NUM> within an area of operations <NUM> (illustrated as an overhead map view). Typically, flying an aircraft within the area of operations <NUM> will be subject to various regulations issued by local authorities, national authorities, licensing bodies, and other entities. However, these various regulations are not generally postable in an easy-to-review format, particularly for a pilot <NUM> using a user device <NUM> such as a smartphone or other mobile device for communications.

In embodiments of the present disclosure, a restriction management system <NUM> is provided that collects flight restrictions relevant to the use of the aircraft <NUM> by the pilot <NUM> in the area of operations <NUM>, and provides information that allows the user device <NUM> to present the restriction information in a format easy to consume on the user device <NUM>. Further, the restriction management system <NUM> continues to monitor restriction information for a planned flight to check for any changes and will transmit a notification to the user device <NUM> if the restrictions change in a meaningful way, thus allowing the pilot <NUM> to plan a flight far in advance without having to repeatedly re-check the plan to ensure that the planned flight will still be allowable.

<FIG> is a block diagram that illustrates aspects of a non-limiting example embodiment of a restriction management system according to various aspects of the present disclosure. The illustrated restriction management system <NUM> may be implemented by any computing device or collection of computing devices, including but not limited to a desktop computing device, a laptop computing device, a mobile computing device, a server computing device, a computing device of a cloud computing system, and/or combinations thereof. The restriction management system <NUM> is configured to generate dynamic checklists by determining restrictions that are relevant to a planned flight area during a planned flight period of time, and providing information associated with those restrictions for presentation to a user. In some embodiments, the restriction management system <NUM> is also configured to monitor for changes in the determined restrictions before and during the planned flight period of time, and to notify the user in the event that a change is detected.

As shown, the restriction management system <NUM> includes one or more processors <NUM>, one or more communication interfaces <NUM>, a restriction data store <NUM>, a user data store <NUM>, and a computer-readable medium <NUM>.

In some embodiments, the processors <NUM> may include any suitable type of general-purpose computer processor. In some embodiments, the processors <NUM> may include one or more special-purpose computer processors or AI accelerators optimized for specific computing tasks, including but not limited to graphical processing units (GPUs), vision processing units (VPTs), and tensor processing units (TPUs).

In some embodiments, the communication interfaces <NUM> include one or more hardware and or software interfaces suitable for providing communication links between components. The communication interfaces <NUM> may support one or more wired communication technologies (including but not limited to Ethernet, FireWire, and USB), one or more wireless communication technologies (including but not limited to Wi-Fi, WiMAX, Bluetooth, <NUM>, <NUM>, <NUM>, <NUM>, and LTE), and/or combinations thereof.

As shown, the computer-readable medium <NUM> has stored thereon logic that, in response to execution by the one or more processors <NUM>, cause the restriction management system <NUM> to provide a user management engine <NUM>, a restriction gathering engine <NUM>, a restriction calculation engine <NUM>, a restriction analysis engine <NUM>, and an environmental information engine <NUM>.

As used herein, "computer-readable medium" refers to a removable or nonremovable device that implements any technology capable of storing information in a volatile or non-volatile manner to be read by a processor of a computing device, including but not limited to: a hard drive; a flash memory; a solid state drive; random-access memory (RAM); read-only memory (ROM); a CD-ROM, a DVD, or other disk storage; a magnetic cassette; a magnetic tape; and a magnetic disk storage.

In some embodiments, the user management engine <NUM> is configured to create and manage records for users stored in the user data store <NUM>. The user records may include information such as pilot attributes for a pilot, aircraft attributes for aircraft to be operated by the pilot, contact information for the pilot (including but not limited to one or more addresses to which notifications can be transmitted), and/or other information.

In some embodiments, the restriction gathering engine <NUM> is configured to retrieve information from other sources that represents restriction information, and to store corresponding restriction definitions in the restriction data store <NUM>. In some embodiments, the restriction gathering engine <NUM> may provide a user interface that allows restriction information to be entered directly into the restriction management system <NUM>, and may create and store restriction definitions based on the restriction information entered into the user interface.

In some embodiments, the environmental information engine <NUM> is configured to retrieve transient environmental information, including but not limited to weather condition information and/or weather prediction information, from external sources. In some embodiments, the restriction calculation engine <NUM> is configured to calculate restriction definitions that are based on transient information from other sources (such as information gathered by the environmental information engine <NUM>), and to store the calculated restriction definitions in the restriction data store <NUM>.

In some embodiments, the restriction analysis engine <NUM> is configured to generate and transmit information for presenting lists of checklist items. In some embodiments, the restriction analysis engine <NUM> is configured to determine which restriction definitions are relevant to a given planned flight area during a planned flight period of time, and to base the information for presenting the lists of checklist items on the relevant restriction definitions. In some embodiments, the restriction analysis engine <NUM> may also be configured to continue monitoring for updated restriction definitions that may be relevant before and during the planned flight period of time, and to transmit notifications to contact information stored in the user record in the user data store <NUM> when changes are detected.

Further description of the configuration of each of these components is provided below.

As used herein, "engine" refers to logic embodied in hardware or software instructions, which can be written in one or more programming languages, including but not limited to C, C++, C#, COBOL, JAVA™, PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Go, and Python. An engine may be compiled into executable programs or written in interpreted programming languages. Software engines may be callable from other engines or from themselves. Generally, the engines described herein refer to logical modules that can be merged with other engines, or can be divided into sub-engines. The engines can be implemented by logic stored in any type of computer-readable medium or computer storage device and be stored on and executed by one or more general purpose computers, thus creating a special purpose computer configured to provide the engine or the functionality thereof. The engines can be implemented by logic programmed into an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another hardware device.

As used herein, "data store" refers to any suitable device configured to store data for access by a computing device. One example of a data store is a highly reliable, high-speed relational database management system (DBMS) executing on one or more computing devices and accessible over a high-speed network. Another example of a data store is a key-value store. However, any other suitable storage technique and/or device capable of quickly and reliably providing the stored data in response to queries may be used, and the computing device may be accessible locally instead of over a network, or may be provided as a cloud-based service. A data store may also include data stored in an organized manner on a computer-readable storage medium, such as a hard disk drive, a flash memory, RAM, ROM, or any other type of computer-readable storage medium. One of ordinary skill in the art will recognize that separate data stores described herein may be combined into a single data store, and/or a single data store described herein may be separated into multiple data stores, without departing from the scope of the present disclosure.

<FIG> are a flowchart that illustrates a non-limiting example embodiment of a method of providing a dynamic flight checklist according to various aspects of the present disclosure. In the method <NUM>, the restriction management system <NUM> helps generate dynamic checklists that illustrate whether a planned flight will comply with various flight restrictions in the planned flight area, and also continues to monitor the flight restrictions in case there are changes before the planned flight period of time. By doing so, the restriction management system <NUM> helps a pilot <NUM> plan in advance for aircraft operations without having to repeatedly manually confirm that the plan is still valid before the planned flight period of time.

From a start block, the method <NUM> proceeds to block <NUM>, where a pilot <NUM> provides one or more pilot attributes to a user management engine <NUM> of a restriction management system <NUM>. At block <NUM>, the user management engine <NUM> creates a user profile for the pilot <NUM> in a user data store <NUM> of the restriction management system <NUM>, and at block <NUM>, the user management engine <NUM> stores the pilot attributes in the user profile.

The pilot attributes may include characteristics of the pilot <NUM> that are relevant to determining whether a given flight restriction would apply to the pilot <NUM>. For example, these pilot attributes may include, but are not limited to, a type of license held by the pilot <NUM>, a license number of a license held by the pilot <NUM>, a number of flight hours held by the pilot <NUM>, how recently the pilot <NUM> has flown, a number of authorizations previously obtained by the pilot <NUM>, a current location of the pilot <NUM>, an age of the pilot <NUM>, and a local time of the pilot <NUM>. The pilot attributes may also include one or more pieces of data more directly relevant to operation of the restriction management system <NUM>, including but not limited to a usemame/password for the pilot <NUM> to access the restriction management system <NUM>, contact information associated with the pilot <NUM>, address information of a user device <NUM> of the pilot <NUM>, device tokens for a notification service, and communication preferences for the pilot <NUM>. By storing the contact information and/or address information for the pilot <NUM>, the restriction management system <NUM> will be able to transmit notifications for presentation to the pilot <NUM> upon detecting changes in the restrictions determined for a planned flight.

At block <NUM>, the pilot <NUM> provides one or more aircraft attributes to the user management engine <NUM>, and at block <NUM>, the user management engine <NUM> stores the aircraft attributes in the user profile. In some embodiments, the user management engine <NUM> may create a separate aircraft record in the user data store <NUM> (or another data store), and may associate the user profile with the aircraft record. Any aircraft attributes relevant to the operation of the restriction management system <NUM> may be provided by the pilot <NUM>, including but not limited to one or more of an aircraft model, an aircraft type (e.g., fixed wing, rotary wing, etc.), an aircraft registration number, an aircraft weight or mass, an aircraft payload capacity, an aircraft maximum operating speed, an aircraft minimum operating speed, an aircraft minimum turning radius, an aircraft minimum operating altitude, an aircraft maximum operating altitude, an aircraft lighting configuration, an aircraft communication capability, an aircraft communication address, and one or more levels of aircraft autonomy.

At subroutine block <NUM>, the restriction management system <NUM> updates restriction definitions stored in a restriction data store <NUM> of the restriction management system <NUM>. On an initial execution of the method <NUM>, the restriction data store <NUM> may be empty, and the procedure executed at subroutine block <NUM> may add an initial set of restriction definitions to the restriction data store <NUM>. If the restriction data store <NUM> already includes one or more restriction definitions, the procedure executed at subroutine block <NUM> may modify or remove existing restriction definitions as well as adding new restriction definitions. Any suitable procedure may be used to update the restriction definitions at subroutine block <NUM>, including but not limited to the procedure <NUM> illustrated in <FIG> and described in further detail below.

At block <NUM>, the pilot <NUM> transmits flight plan information to the restriction management system <NUM> from a user device <NUM>, the flight plan information including a planned flight area and a planned flight period of time. In some embodiments, the restriction management system <NUM> stores the flight plan information in association with the user profile, such that the restriction management system <NUM> will be able to communicate with the pilot <NUM> regarding the planned flight using the contact information in the user profile.

In some embodiments, the user device <NUM> presents a user interface that allows the pilot <NUM> to specify the planned flight area in any suitable two-dimensional or three-dimensional format. In some embodiments, the user interface allows the pilot <NUM> to specify a point on a map and a radius around the point to define the planned flight area. In some embodiments, the user interface allows the pilot <NUM> to draw boundaries of the planned flight area on a map. In some embodiments, the user interface allows the pilot <NUM> to specify a start location, an end location, and an optional set of waypoints between the start location and end location to define a path, and a margin around the defined path is used as the planned flight area. In some embodiments, the user interface allows the pilot <NUM> to specify one or more altitude floors or ceilings for various portions of the planned flight area such that the planned flight area is a three-dimensional volume. In some embodiments, the pilot <NUM> may not specify any planned altitude information.

In some embodiments, the planned flight period of time may be specified by a planned flight start time and a planned flight end time, by a planned flight start time and a planned flight duration, or in any other suitable way. In some embodiments, various portions of the planned flight area may be associated with planned flight periods of time in which the aircraft <NUM> is expected to be within the portion of the planned flight area, such that the planned flight area may be considered a four-dimensional volume.

At block <NUM>, a restriction analysis engine <NUM> retrieves an initial set of restriction definitions relevant to the planned flight area and the planned flight period of time from the restriction data store <NUM>. In some embodiments, the restriction data store <NUM> stores the restriction definitions using S2 technologies to compress the geometry information to be searched against, and the S2 technologies are used to find restriction definitions that affect areas that intersect the planned flight area. In some embodiments, the restriction analysis engine <NUM> may simplify the initial search in order to generate a smaller data set to be compared to the full detail of the planned flight area and planned flight period of time. For example, the restriction analysis engine <NUM> may search the restriction data store <NUM> based on a two-dimensional projection of the planned flight area in order to reduce the complexity of the initial query, and may then compare the limited set of results to the full three-dimensional representation of the planned flight area and/or based on the planned flight period of time.

In some embodiments, the restriction analysis engine <NUM> may retrieve the initial set of restriction definitions (and the updated sets of restriction definitions discussed below) based on not just the planned flight area and the planned flight period of time, but also on one or more pieces of information stored in the user profile associated with the pilot <NUM>, such as pilot attributes or aircraft attributes. For example, different restriction definitions may be retrieved for a first pilot <NUM> with a first license status than for a second pilot <NUM> with a different license status. As another example, different restriction definitions may be retrieved for a first aircraft <NUM> with a mass higher than a given threshold than for a second aircraft <NUM> with a mass lower than the given threshold. This will cause different presentations of sets of checklist items as discussed below for pilots having different pilot attributes and for aircraft having different aircraft attributes.

In some embodiments, the flight plan information may also include other information relevant to the flight, including but not limited to a type of flight to be performed (e.g., a recreational flight, a commercial non-licensed flight, a commercial licensed flight, a delivery, or an emergency flight). The type of flight to be performed may change the restriction definitions retrieved for a given flight, or the checklist items presented for a given flight, even with the same aircraft <NUM> and/or pilot <NUM>. In some embodiments, the user device <NUM> may provide a user interface element that allows the pilot <NUM> to specify the type of flight.

At block <NUM>, the restriction analysis engine <NUM> generates information for presenting a set of checklist items based on the initial set of restriction definitions. In some embodiments, the set of checklist items may indicate the presence or absence of various types of restrictions within the planned flight area or a portion thereof. For example, the set of checklist items may include whether or not the planned flight area includes permanent restricted airspace, fire hazards, a controlled airport/approach path/departure path, an uncontrolled airport, a danger area, a marine park, a no-fly zone, a heliport, a heliport with instrument approach, national parks, or restricted areas.

If the initial set of restriction definitions includes one or more of these types of items, the associated checklist items may be presented in a color indicating a failure (such as red) or with an icon indicating a failure (such as an X), or in a color indicating a warning (such as yellow) or with an icon indicating a warning (such as an exclamation point) (e.g., if there is a restriction definition that indicates a no-fly zone, a "no-fly zone" checklist item may be presented with a red X). For checklist items for which no restriction definitions are included in the initial set of restriction definitions, the associated checklist items may be presented in a color indicating success (such as green) or with an icon indicating success (such as a checkmark) (e. g, if there are no restriction definitions that indicate a no-fly zone, a "no-fly zone" checklist item may be presented with a green checkmark).

The method <NUM> then proceeds to a continuation terminal ("terminal A").

From terminal A (<FIG>), the method <NUM> proceeds to block <NUM>, where the restriction analysis engine <NUM> transmits the information for presenting the set of checklist items to the user device <NUM>. In some embodiments, the restriction analysis engine <NUM> may transmit the initial set of restriction definitions itself to the user device <NUM>, and the user device <NUM> may make the comparison of the initial set of restriction definitions to the checklist items to determine colors/icons to be associated with each checklist item in the presentation. In some embodiments, the restriction analysis engine <NUM> may make the comparison, and may transmit the checklist item statuses to the user device <NUM> for presentation.

At block <NUM>, the user device <NUM> presents the set of checklist items for the planned flight area. <FIG> illustrate a non-limiting example embodiment of a presentation of a set of checklist items made by a user device according to various aspects of the present disclosure.

<FIG> illustrates an example where the set of checklist items indicates that no restriction definitions are included in the initial set of restriction definitions for the checklist items. In <FIG>, the user device <NUM> displays a map <NUM> and a checklist <NUM>. The checklist <NUM> is associated with the specific location indicated on the map <NUM> by a pin <NUM>. The map <NUM> shows a restriction boundary <NUM> that was retrieved by the restriction analysis engine <NUM>, but because the pin <NUM> is outside the restriction boundary <NUM>, the checklist <NUM> does not reflect the restriction definition associated with the restriction boundary <NUM>. As shown, each of the checklist items in the checklist <NUM> was not associated with a restriction definition for the location indicated by the pin <NUM>, and so each checklist item in the checklist <NUM> includes a checkmark to indicate success. The checklist <NUM> also includes a heading that indicates that all checklist items passed, and the pin <NUM> includes a checkmark to further indicate that all checklist items passed. Further checklist items may be available and accessible by tapping on the arrow at the bottom of the checklist <NUM>.

In some embodiments, the specific status of the items in the checklist <NUM> may change by moving the location indicated by the pin <NUM>. In some embodiments, the pilot <NUM> may drag the pin <NUM> to different portions of the map <NUM> to check restrictions in other locations. In some embodiments, the pilot <NUM> may scroll the map <NUM> under the pin <NUM> to check restrictions in other locations.

<FIG> illustrates an example where the pin <NUM> has been moved to be within the restriction boundary <NUM>. For the purposes of <FIG>, the restriction definition associated with the restriction boundary <NUM> indicates restricted airspace that requires approval before operating aircraft therein, and the pilot <NUM> should be warned about operating within the restriction boundary <NUM>. Accordingly, when the pin <NUM> is within the restriction boundary <NUM>, the checkmark within the pin <NUM> has changed to an exclamation point. Further, the heading of the checklist <NUM> has changed to "Use Caution," and the "restricted airspace" checklist item is now associated with an exclamation point instead of a checkmark in the checklist <NUM>. The "restricted airspace" checklist item has also been augmented with additional information relating to the restriction. This information may be provided as part of the restriction definition.

<FIG> illustrates another example where the pin <NUM> has been moved to be within the restriction boundary <NUM>. For the purposes of <FIG>, multiple restriction definitions are associated with the restriction boundary <NUM>: the restriction definition of <FIG> that indicated that the airspace requires approval, and another restriction definition that indicates that the location is associated with a controlled airport. Because aircraft operations are not allowed near the controlled airport, the pin <NUM> now displays an X and the heading of the checklist <NUM> has changed to "No Fly. " The "controlled airspace" checklist item is now associated with a X in the checklist <NUM>, and the "restricted airspace" checklist item is associated with the same exclamation point as <FIG>. One will note that due to the higher severity of the "controlled airport" restriction, the "controlled airport" checklist item has been sorted to the top of the checklist <NUM>, followed by the warning checklist items, followed by the successful checklist items. By providing clear indications of pass/warning/fail conditions for the checklist items, by providing overall pass/warning/fail indications on the pin <NUM> and in the header of the checklist <NUM>, and by reordering the checklist <NUM> to put the highest severity issues at the top, the interface presented on the user device <NUM> helps overcome the small display real estate available on the user device <NUM> and the relatively imprecise touch-based input on the user device <NUM> to nevertheless provide a highly useful review of flight restrictions relevant to the planned flight area.

Returning to <FIG>, at decision block <NUM>, a determination is made regarding whether the planned flight has taken off yet. In some embodiments, this may occur by the restriction analysis engine <NUM> comparing a current time to the planned flight period of time. In some embodiments, this may occur by the restriction analysis engine <NUM> receiving telemetry information from the aircraft <NUM>, and determining that the planned flight has begun based on the telemetry information. In these embodiments, if the planned flight period of time has started but the telemetry information does not indicate that the flight has begun, the restriction analysis engine <NUM> may update the planned flight period of time based on the current time.

If the flight has not yet taken off, then the result of decision block <NUM> is NO, and the method <NUM> proceeds to subroutine block <NUM>. At subroutine block <NUM>, the restriction management system <NUM> updates restriction definitions stored in the restriction data store <NUM>. Any suitable technique may be used at subroutine block <NUM> to update the restriction definitions stored in the restriction data store <NUM>, including but not limited to the procedure <NUM> illustrated in <FIG> and discussed in further detail below. Typically, the actions of subroutine block <NUM> are similar to the actions of subroutine block <NUM> of <FIG>.

At block <NUM>, the restriction analysis engine <NUM> waits an amount of time based on a time remaining before the planned flight period of time, and at block <NUM>, the restriction analysis engine <NUM> retrieves an updated set of restriction definitions relevant to the planned flight area and the planned flight period of time from the restriction data store <NUM>. Similar techniques may be used to retrieve the updated set of restriction definitions as were used to retrieve the initial set of restriction definitions at block <NUM>.

At a high level, the method <NUM> is repeatedly checking for updated restriction definitions relevant to a planned flight area and a planned flight period of time at a rate that increases over time. By waiting for an amount of time based on a time remaining before the planned flight period of time at block <NUM>, the method <NUM> can conserve computing and communication resources at times long before the planned flight period of time when having up-to-date information is of lesser importance, and can prioritize the accuracy and timeliness of the information closer to the planned flight period of time when having up-to-date information is of higher importance.

For example, in some embodiments, the amount of time that the restriction analysis engine <NUM> waits at block <NUM> decreases the closer the current time is to the beginning of the planned flight period of time, such that the actions after block <NUM> occur more frequently the closer the current time is to the beginning of the planned flight period of time. In some embodiments, the amount of time the restriction analysis engine <NUM> waits may decay exponentially before the planned flight period of time. In some embodiments, the amount of time the restriction analysis engine <NUM> waits may shrink based on an amount of time until the planned flight period of time to a minimum threshold amount of time, at which point the amount of time will remain at the minimum threshold amount of time.

In some embodiments, obtaining the benefits of decreasing the amount of time the restriction analysis engine <NUM> waits at block <NUM> may not be needed. For example, the amount of time between the current time and the planned flight period of time may be small enough that the benefits of changing the frequency of checking for updated restriction definitions over time may not be noticeable. As another example, the number of aircraft <NUM>, pilots <NUM>, or planned flights managed by the restriction management system <NUM> may be small enough that conservation of computing power and/or communication bandwidth may not be necessary. As yet another example, the computing power and/or communication bandwidth available to the restriction management system <NUM> may be large enough that the benefits gained by decreasing the amount of time the restriction analysis engine <NUM> waits may not noticeably improve performance of the restriction management system <NUM>. In such embodiments, the restriction analysis engine <NUM> may wait for a constant amount of time at block <NUM> on multiple iterations of the method <NUM>.

At decision block <NUM>, a determination is made regarding whether there are any changes between the initial set of restriction definitions and the updated set of restriction definitions. In some embodiments, the restriction analysis engine <NUM> may store a record of the initial set of restriction definitions, and may compare the updated set of restriction definitions to the stored initial set of restriction definitions to determine whether there are any changes. In some embodiments, the updated set of restriction definitions may only include restriction definitions that were newly stored in the restriction data store <NUM> or updated in the restriction data store <NUM> since the previous query at block <NUM>, and so the determination at decision block <NUM> may be based on whether the updated set of restriction definitions is empty.

If there are no changes between the initial set of restriction definitions and the updated set of restriction definitions, then the result of decision block <NUM> is NO, and the method <NUM> returns to decision block <NUM> to continue to monitor for changes in the restriction definitions. Otherwise, if there are changes between the initial set of restriction definitions and the updated set of restriction definitions, the result of decision block <NUM> is YES, and the method <NUM> proceeds to block <NUM>.

At block <NUM>, the restriction analysis engine <NUM> generates information for presenting an updated set of checklist items based on the updated set of restriction definitions. In some embodiments, the information and the generation thereof may be similar to the generation of the information for presenting the set of checklist items described above at block <NUM>, but using the updated set of restriction definitions (or a combination of the initial set of restriction definitions along with the updated set of restriction definitions, if the updated set of restriction definitions only includes new/updated restriction definitions instead of all relevant restriction definitions).

At block <NUM>, the restriction analysis engine <NUM> transmits a notification to the user device <NUM>. The restriction analysis engine <NUM> may use any suitable technique or combination of techniques to transmit the notification to the user device <NUM>, including but not limited to a push notification supported by an operating system of the user device <NUM> (including but not limited to an Apple Push Notification service (APNs) notification or a Google Cloud Messaging notification), an application-directed SMS message, an email, and an HTTP push. In some embodiments, the addressing information, device tokens, and/or other information for transmitting the notification to the user device <NUM> is stored in the user profile for use at block <NUM>.

At block <NUM>, the restriction analysis engine <NUM> transmits the information for presenting the updated set of checklist items to the user device <NUM>. In some embodiments, the information for presenting the updated set of checklist items may be included in the notification transmitted in block <NUM>. In some embodiments, the notification transmitted in block <NUM> may merely indicate the existence of the information, and the user device <NUM> may retrieve the information for presenting the updated set of checklist items from the restriction analysis engine <NUM> in response to receiving the notification.

The method <NUM> then returns to decision block <NUM> to monitor for further changes to the restriction definitions. On subsequent iterations, the set of updated restriction definitions will also be considered at decision block <NUM> when determining whether any changes are present in the newly updated set of restriction definitions.

Returning to decision block <NUM>, if it is determined that the flight has taken off, then the result of decision block <NUM> is YES, and the method <NUM> proceeds to a continuation terminal ("terminal B"). In some embodiments, proceeding to terminal B could be optional. In such embodiments, the method <NUM> may terminate if the result of decision block <NUM> is YES, or may terminate at the start of the planned flight period of time.

From terminal B (<FIG>), the method <NUM> proceeds to block <NUM>, where the aircraft <NUM> transmits telemetry information to the restriction management system <NUM>. In some embodiments, the telemetry information may include information regarding the status of the aircraft <NUM>, including but not limited to position, altitude, attitude, and/or speed information.

At decision block <NUM>, a determination is made regarding whether the flight is done. In some embodiments, the determination at decision block <NUM> may be based on whether the reported speed, altitude, and position of the aircraft <NUM> indicate that the aircraft <NUM> has landed and/or reached a planned end location of the planned flight area. In some embodiments, the determination at decision block <NUM> may be based on whether the pilot <NUM> has indicated to a user interface provided by the user device <NUM> that the flight is done.

If the determination is that the flight is not done, then the result of decision block <NUM> is NO, and the method <NUM> proceeds to block <NUM>. At block <NUM>, the restriction analysis engine <NUM> compares the telemetry information to the flight plan information, and at decision block <NUM>, a determination is made regarding whether the telemetry information matches the flight plan information. In some embodiments, the comparison includes the restriction analysis engine <NUM> comparing the position, altitude, and/or other elements of the telemetry information to the planned flight area and the planned flight period of time to determine whether the position, altitude, and/or other elements are still within the planned flight area during the planned flight period of time.

If the determination is that the telemetry information does match the flight plan information, then the result of decision block <NUM> is YES, and the method <NUM> returns to block <NUM> to monitor further telemetry information. Otherwise, if the determination is that the telemetry information does not match the flight plan information, then the result of decision block <NUM> is NO, and the method <NUM> proceeds to block <NUM>.

At block <NUM>, the restriction analysis engine <NUM> updates the flight plan information to encompass the telemetry information. In some embodiments, the restriction analysis engine <NUM> may update the planned flight area to include a position/altitude of the aircraft <NUM> indicated by the telemetry information. In some embodiments, the restriction analysis engine <NUM> may update the planned flight area to include this position/altitude plus a predetermined radius or volume around the position/altitude indicated by the telemetry information. In some embodiments, the restriction analysis engine <NUM> may consider the attitude and speed of the aircraft <NUM> in determining an area or volume to add to the planned flight area (e.g., the restriction analysis engine <NUM> may add more area in a direction of travel of the aircraft <NUM>, and less area in other directions).

In some embodiments, the restriction analysis engine <NUM> may update the planned flight period of time to include at least the current time indicated by the telemetry information. In some embodiments, the restriction analysis engine <NUM> may update the planned flight period of time to include not only the current time indicated by the telemetry information, but also a predetermined additional amount of time. In some embodiments, the restriction analysis engine <NUM> may update the planned flight period of time to include the current time indicated by the telemetry information and a predicted amount of time remaining in the flight. The predicted amount of time remaining in the flight may be determined using any suitable technique, including but not limited to determining an amount of charge left in a battery of the aircraft <NUM> or determining an amount of time it would take the aircraft <NUM> to reach an endpoint of the flight from its current position.

At block <NUM>, the restriction analysis engine <NUM> retrieves a new set of restriction definitions relevant to the updated flight plan information from the restriction data store <NUM>. In some embodiments, the new set of restriction definitions is retrieved using techniques similar to those used in block <NUM> to retrieve the initial set of restriction definitions and/or in block <NUM> to retrieve the updated set of restriction definitions.

At decision block <NUM>, a determination is made regarding whether there are any changes between the new set of restriction definitions and the initial set of restriction definitions. Again, in some embodiments, the determination is made using similar techniques to those described at decision block <NUM>, but with the new set of restriction definitions being compared to the initial set of restriction definitions. In some embodiments, if an updated set of restriction definitions was determined to have changes at decision block <NUM>, then the comparison at decision block <NUM> may be performed between the new set of restriction definitions and a combination of the initial set of restriction definitions and the updated set of restriction definitions.

If it is determined that there are no changes between the new set of restriction definitions and the initial set of restriction definitions, then the result of decision block <NUM> is NO, and the method <NUM> again returns to block <NUM> to monitor further telemetry information. Otherwise, if there are changes between the new set of restriction definitions and the initial set of restriction definitions, then the result of decision block <NUM> is YES, and the method <NUM> proceeds to block <NUM>.

At block <NUM>, the restriction analysis engine <NUM> generates information for presenting a new set of checklist items based on the new set of restriction definitions, at block <NUM>, the restriction analysis engine <NUM> transmits a notification to the user device <NUM>, and a block <NUM>, the restriction analysis engine <NUM> transmits the information for presenting the new set of checklist items to the user device <NUM>. The actions of blocks <NUM>-<NUM> are similar to those discussed above in blocks <NUM>-<NUM>, and so are not discussed here in detail again for the sake of brevity. One difference is that, in some embodiments, if there are any checklist items that are newly indicated as a failure in the new set of checklist items, additional actions may be taken by the restriction analysis engine <NUM>, including but not limited to transmitting a command to the aircraft <NUM> to land immediately or otherwise cause the failed checklist item to be addressed.

The method <NUM> then returns to block <NUM> to monitor further telemetry information.

<FIG> is a flowchart illustrating a non-limiting example embodiment of a procedure for updating stored restriction definitions according to various aspects of the present disclosure. The procedure <NUM> illustrated in <FIG> is a non-limiting example of a procedure suitable for use at subroutine block <NUM> and/or subroutine block <NUM> of the method <NUM> described above. In the procedure <NUM>, the restriction management system <NUM> gathers restriction definitions from various sources and adds/updates restriction definitions stored in the restriction data store <NUM> as appropriate.

Each restriction definition may include various features that define the associated flight restriction. For example, in some embodiments each restriction definition may define an area or a volume covered by the restriction. As another example, in some embodiments each restriction definition may include a start time and end time for the restriction, or a period of the day during which the restriction is in effect. As yet another example, in some embodiments each restriction definition may include a type of the restriction, wherein the type specifies what conditions are represented by the restriction definition.

Many different types of restrictions may be represented by the restriction definitions. As some non-limiting examples, types of restrictions may include temporary or permanent no-fly zones (in which no operations are permitted), fire hazards (in which operations that pose fire risks are not allowed), a controlled airport/approach path/departure path (in which unlicensed operations may be restricted but licensed and permitted operations may be allowed), an uncontrolled airport (in which unlicensed operations may be restricted but licensed operations may be allowed), a danger area, a marine park, a heliport, a heliport with instrument approach, national parks, or any other type of restriction on aircraft operation. In some embodiments, each type of restriction is associated with a checklist item as discussed above.

From a start block, the procedure <NUM> proceeds to block <NUM>, where a restriction gathering engine <NUM> receives a set of manual restriction definitions via a user interface. In some embodiments, the restriction gathering engine <NUM> may generate the user interface, which may accept input from users for defining the manual restriction definitions using any suitable technique. As one non-limiting example, the restriction gathering engine <NUM> may present a map interface that allows a user to select a point and a radius, to draw an outline, or to specify an area for the restriction definition using the map in any other way. The interface may also allow a user to specify an altitude ceiling and/or floor for the restriction definition, a time period during which the restriction definition is in effect, and a type for the restriction definition.

At block <NUM>, the restriction gathering engine <NUM> retrieves a set of external restriction definitions from one or more third-party data sources. In some embodiments, the restriction gathering engine <NUM> may query one or more third-party data sources, such as governmental agencies or commercial sources of flight planning information, to obtain the external restriction definitions.

At block <NUM>, an environmental information engine <NUM> collects transient environmental information from one or more data sources, and at block <NUM>, a restriction calculation engine <NUM> determines a set of calculated restriction definitions based on the transient environmental information. In some embodiments, transient environmental information may include past weather condition information, current weather condition information, and/or future weather prediction information, and the set of calculated restriction definitions may include restriction types based on the weather information. As a non-limiting example, the environmental information engine <NUM> may retrieve weather prediction information that indicates a given area is expected to experience high winds at a given time. The restriction calculation engine <NUM> may then create a restriction definition of a type that indicates that operation of aircraft under a certain weight is dangerous or forbidden within the given area.

At block <NUM>, the restriction gathering engine <NUM> updates contents of a restriction data store <NUM> based on the set of manual restriction definitions, the set of external restriction definitions, and the set of calculated restriction definitions. In some embodiments, the restriction gathering engine <NUM> may normalize the format of the manual restriction definitions, the external restriction definitions, and the calculated restriction definitions to each be in a matching format used by the restriction data store <NUM>.

In some embodiments, the restriction gathering engine <NUM> may check whether the restriction data store <NUM> already includes the restriction definitions before adding them to the restriction data store <NUM>. If the restriction data store <NUM> does not yet include a given restriction definition, then the restriction gathering engine <NUM> may simply add the given restriction definition to the restriction data store <NUM>. If the restriction data store <NUM> does include the given restriction definition, the restriction gathering engine <NUM> may check to see if there are any differences between the stored version of the restriction definition and the given restriction definition. If there are no differences, the restriction gathering engine <NUM> may skip adding the given restriction definition to the restriction data store <NUM>, but if there are differences, then the restriction gathering engine <NUM> may either update the stored restriction definition to match the given restriction definition or may delete the stored restriction definition and may replace it with the given restriction definition. In some embodiments, when adding or updating restriction definitions stored in the restriction data store <NUM>, the restriction gathering engine <NUM> may include a timestamp, thus allowing the restriction analysis engine <NUM> to be able to retrieve restriction definitions added or updated after a given time.

The procedure <NUM> then proceeds to an end block and returns control to its caller.

<FIG> and <FIG> illustrate a non-limiting example of an aircraft in accordance with various aspects of the present disclosure. The illustrated embodiment of an unmanned aerial vehicle (UAV <NUM>) is a vertical takeoff and landing (VTOL) unmanned aerial vehicle (UAV) that includes separate propulsion units <NUM> and propulsion units <NUM> for providing horizontal and vertical propulsion, respectively. UAV <NUM> is a fixed-wing aerial vehicle, which as the name implies, has a wing assembly <NUM> that can generate lift based on the wing shape and the vehicle's forward airspeed when propelled horizontally by propulsion units <NUM>. <FIG> is a perspective top view illustration of UAV <NUM> while <FIG> is a bottom side plan view illustration of UAV <NUM>.

The illustrated embodiment of UAV <NUM> includes a fuselage <NUM>. In one embodiment, fuselage <NUM> is modular and includes a battery module, an avionics module, and a mission payload module. These modules are detachable from each other and mechanically securable to each other to contiguously form at least a portion of the fuselage <NUM> or UAV main body.

The battery module includes a cavity for housing one or more batteries for powering UAV <NUM>. The avionics module houses flight control circuitry of UAV <NUM>, which may include a processor and memory, communication electronics and antennas (e.g., cellular transceiver, Wi-Fi transceiver, etc.), and various sensors (e.g., global positioning sensor, an inertial measurement unit (IMU), a magnetic compass, etc.). The mission payload module houses equipment associated with a mission of UAV <NUM>. For example, the mission payload module may include a payload actuator for holding and releasing an externally attached payload. In another embodiment, the mission payload module may include a camera/sensor equipment holder for carrying camera/sensor equipment (e.g., camera, lenses, radar, LIDAR, pollution monitoring sensors, weather monitoring sensors, etc.).

The illustrated embodiment of UAV <NUM> further includes horizontal propulsion units <NUM> positioned on wing assembly <NUM>, which can each include a motor, shaft, motor mount, and propeller, for propelling UAV <NUM>. The illustrated embodiment of UAV <NUM> includes two boom assemblies <NUM> that secure to wing assembly <NUM>.

The illustrated embodiments of boom assemblies <NUM> each include a boom housing <NUM> in which a boom is disposed, vertical propulsion units <NUM>, printed circuit boards <NUM>, and stabilizers <NUM>. Vertical propulsion units <NUM> can each include a motor, shaft, motor mounts, and propeller, for providing vertical propulsion. Vertical propulsion units <NUM> may be used during a hover mode where UAV <NUM> is descending (e.g., to a delivery location) or ascending (e.g., following a delivery). Stabilizers <NUM> (or fins) may be included with UAV <NUM> to stabilize the UAV's yaw (left or right turns) during flight. In some embodiments, UAV <NUM> may be configured to function as a glider. To do so, UAV <NUM> may power off its propulsion units and glide for a period of time.

During flight, UAV <NUM> may control the direction and/or speed of its movement by controlling its pitch, roll, yaw, and/or altitude. For example, the stabilizers <NUM> may include one or more rudders <NUM> for controlling the UAV's yaw, and wing assembly <NUM> may include elevators for controlling the UAV's pitch and/or ailerons <NUM> for controlling the UAV's roll. As another example, increasing or decreasing the speed of all the propellers simultaneously can result in UAV <NUM> increasing or decreasing its altitude, respectively. The UAV <NUM> may also include components for sensing the environment around the UAV <NUM>, including but not limited to audio sensor <NUM> and audio sensor <NUM>.

Many variations on the illustrated fixed-wing aerial vehicle are possible. For instance, aerial vehicles with more wings (e.g., an "x-wing" configuration with four wings), are also possible. Although <FIG> and <FIG> illustrate one wing assembly <NUM>, two boom assemblies <NUM>, two horizontal propulsion units <NUM>, and six vertical propulsion units <NUM> per boom assembly <NUM>, it should be appreciated that other variants of UAV <NUM> may be implemented with more or fewer of these components.

It should be understood that references herein to an "unmanned" aerial vehicle or UAV can apply equally to autonomous and semi-autonomous aerial vehicles. In a fully autonomous implementation, all functionality of the aerial vehicle is automated; e.g., pre-programmed or controlled via real-time computer functionality that responds to input from various sensors and/or pre-determined information. In a semi-autonomous implementation, some functions of an aerial vehicle may be controlled by a human operator, while other functions are carried out autonomously. Further, in some embodiments, a UAV may be configured to allow a remote operator to take over functions that can otherwise be controlled autonomously by the UAV. Yet further, a given type of function may be controlled remotely at one level of abstraction and performed autonomously at another level of abstraction. For example, a remote operator may control high level navigation decisions for a UAV, such as specifying that the UAV should travel from one location to another (e.g., from a warehouse in a suburban area to a delivery address in a nearby city), while the UAV's navigation system autonomously controls more fine-grained navigation decisions, such as the specific route to take between the two locations, specific flight controls to achieve the route and avoid obstacles while navigating the route, and so on. In some embodiments, UAV <NUM> may be fully controlled by a remote pilot, with little to no autonomous capability.

In the preceding description, numerous specific details are set forth to provide a thorough understanding of various embodiments of the present disclosure. One skilled in the relevant art will recognize, however, that the techniques described herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring certain aspects.

The order in which some or all of the blocks appear in each method flowchart should not be deemed limiting. Rather, one of ordinary skill in the art having the benefit of the present disclosure will understand that actions associated with some of the blocks may be executed in a variety of orders not illustrated, or even in parallel.

Claim 1:
A non-transitory computer-readable medium having logic stored thereon that, in response to execution by one or more processors of a restriction management system (<NUM>), causes the restriction management system to perform actions for automatically generating notifications of flight restrictions, the actions comprising:
receiving (<NUM>), by the restriction management system, flight plan information, wherein the flight plan information includes a planned flight area and a planned flight period of time;
querying (<NUM>), by the restriction management system, a restriction data store to retrieve an initial set of restriction definitions relevant to the flight plan information;
generating (<NUM>), by the restriction management system, information for presenting a checklist based on a comparison of restriction definitions from the initial set of restriction definitions to a set of checklist items;
transmitting (<NUM>), by the restriction management system, the information for presenting the checklist to a user device for presentation;
re-querying (<NUM>), by the restriction management system, the restriction data store to retrieve an updated set of restriction definitions relevant to the flight plan information;
comparing (<NUM>), by the restriction management system, the updated set of restriction definitions to the initial set of restriction definitions;
periodically (<NUM>) repeating at least the re-querying and comparing actions at a rate that increases over time up to the planned flight period of time; and
transmitting (<NUM>), by the restriction management system, a notification to the user device in response to detecting a difference between the updated set of restriction definitions and the initial set of restriction definitions.