Remote identification and management of manned and unmanned systems and devices

Abstract

Embodiments of the present disclosure describe a secure, scalable and extensible aircraft and other system and device identity management (IdM) system that enables services for identity provisioning (idP), and identity validation, verification and authentication (idVV&A). The identity and management system uses dual-mode local broadcast and network connected device communication elements across a wide area network. The system serves as a Source System of Record (SSoR) that securely ingests private registration data, system/device identity verification and authentication requests and returns validated identity and activity information.

Claims

1. A dual-mode system for accessing at least one of a government data system and a third-party data system to identify manned and unmanned systems and devices, comprising: a remote identification network; a remote identity management server configured to access the at least one of the government data system and the third-party data system, and further configured to securely affiliate session IDs with at least one of identity information and activity authorization information of the systems and devices, including using the access to the at least one of the government data system and the third-party data system to provide activity telemetry data to the at least one of the government data system and the third-party data system and to obtain the at least one of the identity information and the activity authorization information of the systems and devices from the at least one of the government data system and the third-party data system; a remote identification service provider connected to the remote identity management server via the remote identification network, the remote identification service provider communicating with the remote identity management server to provide authentication of credential information; a first transmitter associated with a first one of the systems and devices, the first transmitter broadcasting at least one of a first session ID and first activity telemetry data of the first one of the systems and devices; a second transmitter associated with a second one of the systems or devices and in data communication with the remote identification network, the second transmitter transmitting at least one of a second session ID and second activity telemetry data of the second one of the systems and devices to the remote identification service provider; a first hardware device including at least a first processor, a first receiver, and a first display, the first hardware device configured to receive directly from the first transmitter and display the at least one of the first session ID and the first activity telemetry data; and a second hardware device including at least a second processor and a second receiver, the second hardware device configured to receive directly from the first transmitter the at least one of the first session ID and the first activity telemetry data, and configured to communicate with the remote identification network, the second hardware device further configured to store credential information for the second hardware device and transmit the stored credential information and the at least one of the first session ID and the first activity telemetry data to the remote identification service provider, and upon authentication of the transmitted credential information to receive from the remote identification service provider at least one of the identity information and the activity authorization information for the first one and the second one of the systems and devices.

2. A dual-mode system for accessing at least one of a government data system and a third-party data system to identify a plurality of manned or unmanned systems and devices, and operable with a wide area network, comprising: a remote identity management server in data communication with the wide area network and configured to access the at least one of the government data system and the third-party data system, including using the access to provide activity data to the at least one of the government data system and the third-party data system and to obtain at least one of identification information, activity authorization information, and activity plan information for the plurality of manned and unmanned systems and devices from the at least one of the government data system and the third-party data system; a first hardware device including at least one receiver and wherein the first hardware device is: configured to receive directly from a first subset of the plurality of manned or unmanned systems and devices at least one of first identification data and first activity data for each of the first subset of the plurality of manned or unmanned systems and devices; in data communication with the wide area network; configured to receive via the wide area network from a second subset of the plurality of manned and unmanned systems and devices at least one of second identification data and second activity data for each of the second subset of the plurality of manned or unmanned systems and devices; configured to store credential information for the first hardware device and to transmit the credential information and the at least one of the first identification data and the first activity data to the remote identity management server for each of the first subset of the plurality of manned or unmanned systems and devices; and configured to receive in response from the remote identity management server additional data about the plurality of manned or unmanned systems and devices including the at least one of the identification information, the activity authorization information, and the activity plan information; and wherein the remote identity management server is further configured to mediate the additional data transmitted to the first hardware device based at least in part on the credential information and access granted under a policy.

3. The dual-mode system of claim 2, wherein the additional data pertains to at least one of an operator of at least one of the plurality of manned or unmanned systems and devices, an owner of the at least one of the plurality of manned or unmanned systems and devices, and activity of the at least one of the plurality of manned or unmanned systems and devices.

4. The dual-mode system of claim 2, wherein mediating the additional data includes masking and substituting select data of the additional data based at least in part on mediated access granted to the first hardware device by the credential information under the policy.

5. The dual-mode system of claim 4, wherein the substituting select data includes the activity authorization information selected from a group consisting of authorized, unauthorized, and unknown.

6. The dual-mode system of claim 2, wherein the first subset of the plurality of manned or unmanned systems and devices transmits at least one of the first identification data and first activity data via at least one of a transmitter and a transceiver.

7. The dual-mode system of claim 2, wherein the second subset of the plurality of manned or unmanned systems and devices transmits at least one of the second identification data and second activity data via a transceiver in data communication with the wide-area-network.

8. The dual-mode system of claim 2, further comprising: at least a second hardware device including at least one receiver, and wherein the second hardware device is: configured to receive directly from the second subset of the plurality of manned or unmanned systems and devices at least one of the second identification data and the second activity data; in data communication with the wide area network; and configured to store a second credential information for the second hardware device and to transmit the second credential information and the at least one of the second identification data and the second activity data to the remote identity management server for the second subset of the plurality of manned or unmanned systems and devices.

9. The dual-mode system of claim 8, wherein: the at least second hardware device includes at least one transmitter, and wherein the second hardware device is: configured to transmit an interrogation request to a third subset of the plurality of manned or unmanned systems and devices; configured to receive from the third subset of the plurality of manned or unmanned systems and devices at least one of third identification data and third activity data; and configured to transmit the second credential information and the at least one of the third identification data and the third activity data to the remote identity management server for the third subset of the plurality of manned or unmanned systems and devices.

10. The dual-mode system of claim 2, wherein the first hardware device includes a display and the first hardware device is: at least one of a passive and an active interrogation device; and is configured to display at least a portion of the additional data about the plurality of manned or unmanned systems and devices.

11. The dual-mode system of claim 2, wherein the first hardware device includes a handheld mobile device.

12. The dual-mode system of claim 2, wherein the first hardware device is configured to encrypt and relay the at least one of the first identification data and the first activity data for each of the first subset of the plurality of manned or unmanned systems and devices.

13. The dual-mode system of claim 2, wherein the at least one of identification information, activity authorization information, and activity plan information transmitted by the remote identity management server to the first hardware device can include personally identifiable information under the access granted to the credential information under the policy.

14. The dual-mode system of claim 2, wherein the remote identity management server provides validation of the additional data.

15. The dual-mode system of claim 2, wherein the additional data further includes real time and historical activity data about the plurality of manned or unmanned systems and devices.

16. The dual-mode system of claim 2, wherein: at least one of the remote identity management server and the at least one of the government data system and the third-party data system assigns a session ID to each of the plurality of manned or unmanned systems and devices; and at least one of the additional data and the identification information includes the session ID.

17. The dual-mode system of claim 2, wherein the first hardware device is in direct data communication with a defense system and is configured to provide validation information for each of the plurality of manned or unmanned systems and devices that is determinative of whether each is authorized or unauthorized.

18. The dual-mode system of claim 2, wherein the first hardware device includes a traffic control terminal.

19. The dual-mode system of claim 2, wherein first hardware device is carried by at least one of the manned and unmanned systems and devices.

20. A dual-mode system for accessing at least one of a government data system and a third-party data system to identify systems and devices and operable with a wide area network, comprising: a remote identity management server in data communication with the wide area network and adapted to access at least one of the government data system and the third-party data system, including using the access to provide activity data to the at least one of the government data system and the third-party data system and to obtain at least one of an identification information, activity authorization information, and activity plan information for the systems and devices from the at least one of the government data system and the third-party data systems; a first radio associated with a first one of the systems and devices, the first radio transmitting to a first hardware device at least one of identification data and activity data of the first one of the systems and devices; a second radio associated with a second one of the systems and devices and in data communication with the wide area network, the second radio transmitting at least one of identification data and activity data of the second one of the systems and devices to at least one of the remote identity management server and the at least one of the government data system and the third-party data system; the first hardware device including at least one receiver capable of receiving directly from the first radio the at least one of identification data and activity data, the first hardware device also in data communication with the wide area network, the first hardware device configured to store a first credential information for the first hardware device and to transmit the first credential information and the at least one of identification data and activity data to the remote identity management server for the first one of the systems and devices, and upon the first hardware device presenting the first credential information to the remote identity management server, the first hardware device configured to receive from the remote identity management server at least one of additional identity information, activity authorization information and activity plan information for both the first one of the systems and devices and the second one of the systems and devices; and at least a second hardware device including at least one receiver capable of receiving directly from the first radio the at least one of identification data and activity data, the second hardware device also in data communication with the wide area network, the second hardware device configured to store a second credential information for the second hardware device and to transmit the second credential information and the at least one of identification data and activity data to the remote identity management server for the first one of the systems and devices.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Some of the figures shown herein may include dimensions or may have been created from scaled drawings. However, such dimensions, or the relative scaling within a figure, are by way of example, and not to be construed as limiting.

(2) FIG. 1 is a prior art system for identifying and managing air traffic;

(3) FIG. 2 is an exemplary system for remote identification of unmanned aircraft systems, according to the present disclosure;

(4) FIG. 3 is a block diagram of an exemplary application and database structure of the system of FIG. 2, according to the present disclosure;

(5) FIG. 4 is a block diagram of an exemplary system ecosystem, according to the present disclosure;

(6) FIG. 5 is a process diagram of an illustrative embodiment of a method of mediating access to information requested by a system user, according to the present disclosure;

(7) FIG. 6 is a process diagram of an illustrative embodiment of a method of filing a flight plan with the air traffic identity and management systems of the present disclosure;

(8) FIG. 7 is a process diagram of an illustrative embodiment of a flight activity including geofencing, according to the present disclosure;

(9) FIG. 8 is a process diagram of an illustrative embodiment of an aircraft identification query, according to embodiments of the present disclosure;

(10) FIG. 9 is a block diagram of FPID and its standards-based interaction with the USS ecosystem according the present disclosure; and

(11) FIG. 10 is a block diagram illustrating how the FPID components interact with the USS ecosystem, the public and authorities according to the present disclosure.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

(12) For the purposes of promoting an understanding of the principles of the disclosure, reference will now be made to one or more embodiments, which may or may not be illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended; any alterations and further modifications of the described or illustrated embodiments, and any further applications of the principles of the disclosure as illustrated herein are contemplated as would normally occur to one skilled in the art to which the disclosure relates. At least one embodiment of the disclosure is shown in great detail, although it will be apparent to those skilled in the relevant art that some features or some combinations of features may not be shown for the sake of clarity.

(13) Any reference to invention within this document is a reference to an embodiment of a family of inventions, with no single embodiment including features that are necessarily included in all embodiments, unless otherwise stated. Furthermore, although there may be references to benefits or advantages provided by some embodiments, other embodiments may not include those same benefits or advantages, or may include different benefits or advantages. Any benefits or advantages described herein are not to be construed as limiting to any of the claims.

(14) Likewise, there may be discussion with regards to objects associated with some embodiments of the present invention, it is understood that yet other embodiments may not be associated with those same objects, or may include yet different objects. Any advantages, objects, or similar words used herein are not to be construed as limiting to any of the claims. The usage of words indicating preference, such as preferably, refers to features and aspects that are present in at least one embodiment, but which are optional for some embodiments.

(15) Flight Portal ID (FPID) Overview

(16) This disclosure describes Flight Portal ID (FPID) system and provides examples of its structure and use. The FPID system is a secure, scalable and extensible identity management (IdM) system that enables services for identity provisioning (idP), and identity validation, verification and authentication (idVV&A). These services are deployable across the entire spectrum of UAS applications. The system serves as a Source System of Record (SSoR) that securely ingests private registration data, UAS identity verification and authentication requests and returns validated identity and flight information. The FPID system enables a standards-compliant utility service that functions with the ASTM F38 Remote ID Standard.

(17) In one embodiment illustrated in FIG. 10, the FPID system 900 includes the following components:

(18) Flight Portal ID Core for Identity Management (FPID-CORE):

(19) The FPID-CORE system 910 is the foundational system for performing IdM. It includes indexing, token exchange and secure data vault services in support of its IdM functions. It performs all aggregation and correlation functions within the IdM and Verification system. This system may include software operating on a cloud or remote service and also provides a unique per-flight session ID and validates UAS operator identity with both government and third-party sources of identity. The FPID-CORE system 910 communicates to USSs 920 via a nationally scaled and load balanced, secure API gateway 924 and delivers RID lookup information to the public and authorities based on stakeholder authorization level, context and policy.

(20) Flight Portal ID Registration, Authentication and Authorization Gateway (FPID Universal Login Subsystem):

(21) The FPID Universal Login subsystem 930 is a scalable subsystem of the FPID-CORE system 910 that handles secure user registration, identity validation, authentication and authorization. This subsystem service is standards compliant and is used for registering UAS equipment, UAS ownership, UAS operators and operator licenses. It enables true identity validation (to real persons, equipment and licenses) and provides universal login (authentication) and authorization using OAuth and TLS standards. The FPID Universal Login subsystem 930 is the secure OAuth provider for an owner/operator logging into a Net-RID Service Provider USS 920 and handles all authentication for UAS connecting to the RID USS ecosystem. The services within the FPID Universal Login subsystem 930 are accessed via a secure API gateway 924.

(22) Flight Portal ID RID Verification Gateway (FPID RID Verification):

(23) FPID RID Verification subsystem 940 is a scalable subsystem of FPID-CORE 910 that handles RID Verification (running a license plate). The RID Verification subsystem feature enables the public, agencies and authorities with appropriate privilege levels to access (as applicable to privilege level). PII matched to associated flight information in the UTM system, including flight plan, flight plan authorization status and historical and real time flight data. The subsystem services within FPID RID Verification are accessed via a secure API gateway 924 (standard compliant for broadcast messages and outside the scope of the standard for net messages).

(24) Flight Portal ID Local Broadcast (FPID-LB):

(25) The FPID-LB 1012 is the firmware that controls FPID beacon broadcast hardware 1010. The FPID-LB can also be incorporated into specification-compliant OEM UAS hardware via a Software Development Kit (SDK). Standard-compliant FPID-LB broadcast messages can be read and verified on handheld and mobile devices and/or forwarded by those devices and unattended receivers using FPID-LBR 1022 to the RID network 902, e.g. operating over a wide-area network such as the internet, just like any other Net-RID message.

(26) Flight Portal ID Local Broadcast Receiver (FPID-LBR):

(27) The FPID-LBR 1022 is the software and/or software and hardware subsystem 1020 that receives RID beacon 1010 broadcasts and forwards them for verification. This subsystem is also capable of reformatting, authenticating, encrypting and relaying messages to Net-RID Service Provider USS 920 for inclusion in data exchange data streams just as any network RID message would be. An SDK is provided for fast integration with display applications such as those installed on hand-held and mobile devices.

(28) Flight Portal ID Beacon and Receiver Hardware:

(29) FPID beacons 1010 and receivers 1020 are an optional hardware component of FPID. A beacon 1010 is a low cost, low power, OEM-installable, on-aircraft RF transmitter module capable of ASTM compliant UAS RID broadcasts. A receiver 1020 may be any type of mobile or hand-held device or a headless (unattended) RF receiver connected to a network (at least intermittently). In either case, these hardware components host FPID-LB/R software 1012 and 1022. The beacons 1010 use hardware-derived encryption with FPID Universal Login to authenticate broadcast messages. The receivers 1020 are independent and can be utilized in conjunction with other airspace monitoring systems or C-UAS systems 1060 for confirming both network and broadcast RID communications, or stand alone for broadcast RID communications. Additionally, the FPID beacons 1010 are designed to function in an emergency mode, including continuation of broadcast signals in the event of power interruption from the UAS power supply.

(30) RID IdM and Verification Offered as a Public Digital Service Utility

(31) Identity Provision (idP) and Identity Verification, Validation and Authentication (IdVV&A) is only minimally covered in existing standards (slightly for broadcast and less for network) and other documents, is assumed to be a function within the FAA. The standard provides for some optional data elements for describing the flight plan but does not provide for a mechanism to indicate an approved plan during a verification process.

(32) The FPID system 900 offers RID IdM function as a public digital service utility that can be used by the USS/UTM ecosystem, government, and directly by the public. The system and service addresses security, authorization, privacy, and nationwide scalability while offering the USS/UTM ecosystem a secure and authoritative, single source of truth (SSOT) for key RID services. The benefits of this approach are the following:

(33) The approach supports the policy of making an RID license plate a publicly available resource.

(34) Authorities that maintain security with C-UAS and air defense tools need access to RID verification information that is beyond the scope of commercial UTM services.

(35) An authoritative SSOT outside the scope of the UTM/USS ecosystem is needed for initial and ongoing identity validation of all stakeholders. Identity validation first occurs during registration and provides authentication credentials only to those people and entities that can show proof that they are who they say they are.

(36) RID authentication and verification should not be a cost burden to any stakeholder. Integration across the ecosystem via a utility enables cost to be lowered for all users while supporting private sector UTMs to focus on innovation in traffic management and related services.

(37) RID IdM functions must not be compromised if a USS struggles, goes out of business, or is exposed to a vulnerability or compromise.

(38) RID needs to move across borders. Not all USS's may be eligible to move across borders. One RID IdM system enables easier logistics when integrating with multiple governments and commercial services; enabling a more efficient communication of information while also lowering the burden of policy updates or alterations.

(39) USS will struggle to provide certain RID IdM functions to defense and security operators in a compromised, contested, or combative environment.

(40) A trusted third-party can better protect user PII. Such a regulated utility provides and facilitates privacy to users on a stakeholder permission basis. This approach allows legal and regulatory separation between the regulating body, e.g. the FAA, and the public data holdings it regulates (thus helping to avoid the fox is guarding the henhouse apprehension that might otherwise occur).

(41) RID as a utility service allows USSs to focus on their core traffic management and business competencies and CAAs to focus on their core competency of regulation. Furthermore, there are distinct benefits of this utility model to agencies with C-UAS responsibilities.

(42) The Digital Service FPID System 900 can issue a Session ID to Track Flight Plan, Flight Plan Approval Status and Flight Data

(43) Session IDs are a means of protecting identifying information and obscuring patterns of UAS use. The FPID system 900 can provide a per-flight session ID as a public digital service utility for use in signifying and cross-referencing flight plan approval status, and as necessary, flight plan data and historical and near-real-time flight information.

(44) Provenance of the session ID within the public IdM utility ensures that the UAS, UAS owners and UAS operators that are associated with a particular flight plan approval are who they say they are.

(45) Additionally, members (aircraft) of the UAS community who are flying in RID-exempt air space may obtain session IDs directly from the utility in order to obscure flight pattern observation and to protect privacy if they so wish.

(46) Dual Mode Strategy with Broadcast as the Foundation

(47) Local broadcast RID can provide a base level of functionality analogous to a license plate on a car. The beacon 1010 provides this feature by allowing anyone having (with or without a network connection) a publicly available app and mobile device 1020 and 1022 to read the license plates on nearby UAS.

(48) Second, cellular coverage across the entire scope of U.S. geography currently isn't (and may never be) 100% complete and reliable. Building the foundation on broadcast RID, capable of transmitting RID messages at 15 ms intervals, provides both a primary and fall-back option for areas of non-coverage, intermittent network connections or complete network outages.

(49) Third, local broadcast provides an easily adoptable option for members of the general public and small businesses who currently do not use an always-on internet connection for UAS flight and may be concerned about cost, privacy and governmental overreach issues if required to provide an always-on connection.

(50) Fourth, local broadcast using beacon technology is capable of providing exactly the same level of RID service as network options (including the assembly of local, regional and national common operating pictures) via networks of receivers (handheld or headless).

(51) Fifth, local broadcast puts the onus for providing identification on the UAS operator and the onus for validating identification on the receiver (which could have both LB+network capabilities). While this may seem like a minor point, the legal and policy implications of blurring this line of responsibility and authority could have significant unforeseen consequences, particularly when varying state and municipal laws are invoked in conjunction with federal mandates and rules surrounding Remote ID. From a technological standpoint, basing RID on local-broadcast may invoke greater flexibility for the technology to meet the intents of policy, even as policy evolves.

(52) Sixth, local broadcast can be augmented by internet-enabled features for commercial entities and advanced applications including autonomous and BVLOS operations.

(53) Seventh, local broadcast has security advantages, including some C-UAS advantages and resilience in the event of cyber-attacks or network outages. As logistics and society become increasingly reliant on UAS operations, this resilience is key to continuation of services.

(54) Finally, local broadcast can perform as an essential basis for detect and avoid (DAA) features, especially at standoff distances.

(55) The network 902 supports a dual-mode FPID system 900 that includes network connection, but local broadcast as a foundation for the above listed reasons. Especially in regard to resilience and redundancy, and especially for the continuation of services, it is envisioned that the majority of commercial operations will include dual-mode equipage, as further outlined below.

(56) Adjust and Expand RID UAS Types

(57) The FPID system 900 can provide six types of RID to the UAS market (Table 1). Present public documents identify just three classifications, but by making broadcast RID a foundational requirement, the classification types can be expanded to cover a broader range of RID capabilities that more realistically align with user requirements and higher probability of compliance. See Example B for examples of use cases in which these RID types are used.

(58) TABLE-US-00001 TABLE 1 RID Type Classification Remote ID Type Description Operating Restrictions Non-Equipped (no beacon, Manufactured before Limited to FAA Recognized no network connectivity) Remote ID, limited Identification performance capabilities if Areas (FRIA), user requested manufactured after Remote temporary FRIA via a volume ID, or amateur-built model based UTM, or specially aircraft without Remote ID. authorized by Administrator. RID assigned to the volume of airspace via FPID SDK-USS integration and RID information available (based on stakeholder status) when airspace volume is queried. GCS Network (no local Manufactured before GCS Network ID compliant broadcast, network/internet Remote ID, amateur-built UAS would transmit a present at the Ground Control without a Remote ID beacon. periodic message that Station only. Assumes GPS Assumes firmware and GCS INCLUDES location data for latitude/longitude of UAS is application updates are the unmanned aircraft AND transmitted to the GCS via the required to enable limited the Ground Control Station. control link) RID. In this use case, the UAS will have a GPS position that can be relayed to the GCS via the control link and both GCS and UAS location can be transmitted periodically through the network/internet connection. Because there is no beacon capability on the UAS, it is suggested the 400 foot maximum flight distance from the GCS would be enforced in the control hardware to ensure visual line of sight operation. Local Broadcast RF broadcast (beacon) only. UAS must fly within the Most commercially available geographical and temporal or kit built UAS used for boundaries that UTMs personal or small business associate with a duly obtained applications. flight session ID. Control station location and operator contact information available to authorized entities. (Commercial/Advanced) RF broadcast (beacon) and UAS must fly within the Local Broadcast + Network Network connected. geographical and temporal Advanced commercial UAS boundaries that UTMs that can perform BVLOS associate with a duly obtained flight, autonomous operation, flight session ID. on-the-fly rerouting and batch Control station location and flight authorization. operator contact information available to authorized entities. Special Network connected and/or Fly within the constraints of special capability. current government and Including larger UAS military framework. equipped with ADS-B and/or Identity, flight authorization private, government or and intent promulgated on a military networking strictly need-to-know basis. capabilities. Non-Compliant No RID detectable. Intent Not allowed. unknown. Operator unknown.
Dynamic Performance-Based Airspace Classification Types

(59) The FPID system 900 supports airspace classifications for geographic areas that can also be dynamically overlaid with additional airspace restrictions as required by events. Each dynamically assigned airspace classification type determines the level of RID capability required. The dynamism of the airspace can be managed by UTMs with RID FPID system 900 acting as the keys to the airspace, verifying that the operator/aircraft meets the credentials required for that airspace type. The airspace type could alter, such as from low density to medium density based on data obtained by the UTMs managing the airspaces. Such capability and dynamism introduce significant real team safety enhancements to the airspace by requiring a higher status of RID equipage needed for future airspace management. These dynamic airspaces go beyond RID in terms of aircraft safety equipage. However, the RID of that aircraft can help to confirm the operator/aircraft has that equipage for operating in these airspaces. Table 2 specifies the distinct RID FPID system 900 capabilities while Table 3 lists the dynamic airspace classifications and the associated combinations of RID capabilities for each classification.

(60) TABLE-US-00002 TABLE 2 RID Capabilities Summary UAS RID Capability Description Broadcast UAS equipped with beacon. The license plate portion of the message must be readable by anyone with a receiving device. Broadcast messages may be placed on the network by internet-connected receivers (if within range) or used in display apps without forwarding to the internet if no connection exists. Network UAS is capable of connecting to the internet via a RF Network connection (such as cellular LTE). Dynamic Performance Based Airspace classifications may be assigned based on assessment of the likely continuity of network connections across all segments of the flight path. Session ID Broadcasting or Transmitting the Session ID broadcast/ instead of the tokenized OEM S/N indicates transmit that a Net-ID Service Provider has authorized the flight plan. Note that under certain exempt and generally approved dynamic performance based airspace designations, a session ID would be a valid means of flight pattern obfuscation but would not correspond to a Net-RID Service Provider flight plan authorization.

(61) TABLE-US-00003 TABLE 3 Performance Based Airspace Classification Airspace RID Type Recommendation (Not to be confused Broadcast/ with Airspace Network/ Classes) Description Session ID Possible Regulatory Standard Charted See FAA definition Broadcast: No VLOS only, GCS FRIA (Such as an Network: No within X distance of AMA Field) Session ID: No UA (all optional) Non-Standard FRIA Same or similar FAA Broadcast: No VLOS only. GCS Request (Such as definition, but is a Network: Yes - via within X distance of pilot's backyard; request via UTM for UTM integration for UAS. designed ideally as a temporary volume assigning RID to the a subset airspace of airspace in Class volume of airspace. designation for G, non-restricted Session ID: Optional - medium density airspace. Broadcast also airspace.) Optional. Low Density Low density airspace Broadcast: Optional Non-RID Flight usage and low density for VLOS. Mandatory allowable if UAS is of for BVLOS. flown under VLOS people/structure/ Network: Optional rules and remains ground clutter. clear of all other Example: Rural with aircraft. flat topography. Waivers available. Medium Density Medium density Broadcast: Mandatory Beyond Visual Line airspace usage. Network: Mandatory. of Sight flight Medium density requires continuous people/structure/ monitoring by UTM. ground clutter. Waivers available. Likely to be identified Pre-programmed in suburban areas. flight patterns require continuous monitoring by UTM. Can be added as an option to other categories with appropriate clearance. High Density High density airspace Broadcast: Mandatory Beyond Visual Line usage. Highly dense Network: Mandatory of Sight flight people/structure/ requires continuous ground clutter. monitoring by UTM. City or densely used Pre-programmed suburban airspaces. flight patterns require Lots of buildings, continuous complex topology, monitoring by UTM. complex RF Can be added as an environment, and risk option to other associated with urban categories with canyons. appropriate clearance. Flight plan and flight pre-approved by UTM. Session ID for flight plan approval transferred to UAS for broadcast and optional network transmission. Exempt FAA definitions Broadcast: No GCS position(s) (+ rural, range & Network: No reported prior to agricultural owned by Session ID: No flight, flight UAS owner/operator (all optional) timeframe reported or associated entity) prior to flight, flight airspace volume reported prior to flight, BVLOS possible with added RID reqs, Automated possible with added RID reqs Generally Open FAA- Broadcast: Yes VLOS only, Approved designated public, Session ID: No encrypted GCS government and Network: No location provided. commercial areas (Session and Network optional) Controlled Flight plan and flight Broadcast: Yes BVLOS & pre-approved by Session ID: Yes Automated possible UTM. Session ID for Network: conditional with added RID reqs flight plan approval on Broadcast transferred to UAS Receiver/Network for broadcast and service availability optional network in flight path transmission. Restricted Flight plan and flight Broadcast: Yes BVLOS & pre-approved by Session ID: Yes Automated possible UTM. Session ID Network: Yes with added RID reqs transferred to UAS for broadcast/network transmission. Near- real-time flight monitored by UTM. Prohibited Not allowed Not allowed Not allowed BVLOS Beyond Visual Line Broadcast: Yes Additional Operator (addendum) of Sight flight Session ID: Yes Licensing, UAS requires continuous Network: Yes equipment monitoring by UTM. continuous Network certification/ Can be added as an connectivity and requirements? option to other control required categories with appropriate clearance. Automated Pre-programmed Broadcast: Yes Additional Operator (addendum) flight patterns require Session ID: Yes Licensing, UAS continuous Network: Yes equipment monitoring by UTM. continuous Network certification/ Can be added as an connectivity and requirements? option to other control required categories with appropriate clearance. (Yes = required, No = not required)
Broadcast Messages on the Network when Available

(62) The FPID system 900 enables broadcast messages to be forwarded to a network 902 for inclusion in the Net-RID Display Provider USS 920 data streams, where possible.

(63) Broadcast messages have some technical limitations and differences from network transmitted messages. Fundamentally, broadcast is a one-way communication while network transmission can be a two-way communication.

(64) Additionally, broadcast communications currently have some limitations with regard to message size. Legacy broadcasting as defined in the standard requires the use of multiple messages to communicate the RID data. However, improved broadcast technology is overcoming these issues, essentially enabling a broadcast message to notionally fulfill the requirements of a network RID message. However, doing so also requires a networked receiver. Notionally, any networked handheld device, or appropriately equipped cellular communications tower receiving a RID broadcast message could perform the role of a network RID receiver, relaying the received broadcast messages to a Net-RID Service Provider.

(65) Forwarding broadcast messages to the network 902 allows broadcast-only UAS to be included in the larger common operating picture (COP). This also allows dual-mode equipped UAS to have redundant capabilities for RID compliance.

(66) License Plate Functionality is Available for Broadcast and Network

(67) The intent of current public policy is that the license plate functionality of RID is available to the general public. However, the FPID system 900 can optionally broaden the requirement for broadcast RID to make license plate functionality ubiquitous. Anyone with an appropriately equipped mobile or handheld device will be able to directly monitor and report non-network equipped UAS 1040 in their immediate area, with or without a cellular data connection.

(68) Additionally, adding broadcast messages, wherever possible, to the Net-RID USS data streams, makes the COP more complete and allows UAS identification in a broader geographic scope.

(69) The presently disclosed IdM FPID system 900, provided as a public digital service utility for RID, including registration, validation, provisioning and verification functions, provides a reliable and secure, nationally scaled RID system.

Example A: FPID Demonstration in Military and Homeland Defense Context

(70) FPID system 900 prototypes were previously executed in preliminary demonstrations with the US Military and government contractors at the Maneuver Fires Integrated Experiment (MFIX). While at MFIX FPID-LB 1010 equipped aircraft set flight distance records in excess of 3 KM distance and 900 M altitude with intermittent signal return. Regular signal return was generated at 2.6 KM distance and 900 M altitude. Signal returns were received both to independent FPID enabled receivers 1020 and smartphones.

(71) The FPID system 900 was integrated into a US Army Stryker, equipped with the Northrop Grumman SCUWR C-UAS system. The SCUWR operators successfully utilized FPID system 900 for positive-ID confirmation of friendly UAS, enabling them to obtain clearance to fire on hostile UAS with SCUWR's electronic warfare capability and SCUWR's 30 MM chain gun.

(72) The Flight Portal ID system 900 demonstrated the effectiveness of FPID-LB 1010 and FPID-CORE 910 prototypes at the US Army Futures Command Maneuver Fires Integrated Experiment. Summary of two successfully achieved objectives:

(73) The FPID system 900 prototype hardware performance limitations explored as engineered to the current ASTM F38 Remote ID standard Bluetooth protocol applied in a military relevant non-sterile environment:

(74) Achieved maximum distance intermittent local broadcast communications at 2.6 KM distance, 900 M altitude.

(75) Integrated with C-UAS operators.

(76) The FPID system 900 achieved successful identification of equipped aircraft 1030 when incorporated with Northrop Grumman and Liteye systems 1060.

(77) The FPID system 900 was used by Northrop Grumman C-UAS operators to confirm positive-ID of UAS and obtain clearance to fire on hostile UAS with both electronic attack and kinetic means, via a 30 MM chain gun.

(78) Urban environment testing: FPID-LB beacons 1010 and FPID equipped smartphones 1020 were ground tested in dense urban environments with high crowd volumes during a New Year's Eve celebration in downtown Indianapolis, Indiana. In these preliminary ground tests the FPID system 900 did not register any measurable environmental interference, even in crowds of roughly 400 people, most of whom had at least one emitting smart device.

(79) FPID-LB 1010 demonstrated abilities to peak around corners and transmit signals down side streets, but it was apparent that the dual Local Broadcast and Network connection would be needed for successful flight in urban canyons.

Example B: Use Case Scenarios

(80) The following scenarios use the RID and airspace classifications described in this disclosure. See Table 1 for RID Capability Types and Table 3 for Dynamic Performance-based Airspace classifications.

(81) Scenario A: Suburban Backyard Recreational Flight with Model Aircraft (Non Equipped RID Capability in FAA Recognized Identification Areas (FRIA) or Exempt Airspace)

(82) In this scenario, a modeler can fly in a UTM assigned FRIA or other exempt airspace without RID. All FAA rules regarding VLOS, distance between Unmanned Aircraft (UA) and Ground Control Station (GCS), etc. apply. Outside FRIA or exempt spaces, RID and flight constraints apply. As an examplea modeler may not be able to fly recreationally if they live in the National Capital Region around Washington D.C., just as they cannot today.

(83) Scenario B: Commercial Agricultural Flight in Rural Environments. (Standard RID Capability in Exempt Airspace)

(84) In this scenario, a commercial seed company is conducting a survey of an experimental seed field. Network connections may be compromised in this environment due to the field's rural nature. However, a beacon 1010 equipped aircraft can continue to fly and broadcast its signal so that smart-device handhelds 1020, like farmer owned tablets or law enforcement smartphones, can obtain local broadcast signals. In addition, ground receivers 1020 that are dispersed around the field environment can also identify the aircraft. RID broadcast is hypothesized to be picked up by smart-devices in aircraft, such as crop dusters.

(85) The beacon 1010 equipped UAS is designed for constant broadcast and can provide RID as a method of Detect and Avoid (DAA) to other beacon 1010 equipped UAS with two-way capabilities, or more advanced UAS with both local broadcast and network capabilities. Because of their higher performance capabilities, it is suggested that UAS equipped for both local broadcast and network capability yield right of way to lesser equipped UAS, such as the broadcast-only equipped UAS.

(86) It is suggested that broadcast-only equipped aircraft also be equipped with redundant DAA technology, such as vision sensors, on-board radar, etc., but further consideration is out of scope of this disclosure and dictated by OEM choice and FAA policy.

(87) Scenario C: University Research Team Flight in Urban Environment (Standard RID Capability in General Approved Airspace)

(88) In this scenario, a university is conducting flight experimentation and research for a new widget flown on a university owned and operated UAS built and configured for test flights over University property. The UAS is equipped with a broadcast beacon. The University provides permission for the flight over allowed areas and can monitor UAS using the broadcast license plate associated with any UAS detected. Unapproved or outside and interfering UAS can be reported to University security and local authorities.

(89) Scenario D: University Security and Local Authorities Respond to Unidentified UAS Over University Property (Non-Compliant RID Capability in General Approved Airspace)

(90) A student is flying a popular commercial drone to capture video near a crowded, outdoor event on campus. University security are unable to see a broadcast or network license plate from the drone using their mobile device display application. Security has the ability to immobilize the drone but deems its behavior to be not an immediate threat, so they canvas the area on foot and find the student with GCS within a few hundred feet of the UAS. (The drone is required by the FAA to have firmware installed that limits its use without a Network connection, but this equipment was purchased prior to the requirement. The GCS includes the student's mobile device with cellular data connectivity, but an internet connection is not being used during flight). The student is required by security to bring the drone down safely. The student is informed of University policies requiring registration for drone flights for approved purposes in conjunction with RID capabilities. The student can update his firmware to bring his system into Limited compliance. The new firmware limits drone flight to no more than 400 feet from the GCS when a network connection is not persistent and also provides network transmission of the drone's RID, GCS location and drone location using the student's existing service plan. Local authorities exercise discretion in regard to federal rules and local ordinances.

(91) Scenario E: University Student Flies Near Crowded On-Campus Event with Permission (Limited RID Capability in General Approved Airspace)

(92) The same student as in the previous scenario upgrades the firmware on his drone. The process requires online registration of the drone and the owner/pilot with the public digital service utility which validates the student's real identification and the drone's provenance with the OEM via valid manufacturer serial numbers (MSN) provided to the OEM from the utility prior to manufacture for the US market. The registration process is integrated into the OEM's firmware update services using the public utility's universal registration/login so that the student accesses a single online service (from his view). The student obtains permission from his University to fly near, but not over, a crowded event on campus in order to obtain video footage of the event. The student's mobile device, integrated into the GCS, periodically transmits the UAS OEM serial number, GCS location and UAS location to a default Net-RID service provider 920 for that region. University security staff and local law enforcement at the event can monitor the UA flight and see relevant PII if necessary. University security staff can cross reference the license plate with their approval system.

(93) Scenario F: High School Science Class Flight Over Public School Property (Standard RID Capability in General Approved Airspace)

(94) The high school science class, under the supervision of the science teacher, conducts experiments by dropping items from a robotically controlled mechanism on the UA. The UA flies over an unused athletic field during class time. The school property is in a suburban neighborhood environment. The UA is equipped with a broadcast RID beacon 1010 and no network RID or Session ID is required. Residents of nearby homes on the other side of a fence that separates school property from private property can see the license plate and some general information about the UA's purpose. Some of the mobile apps 1022 used by neighbors to detect the RID broadcast can translate and forwarding the broadcast messages to a Net-RID Service Provider 920 via the internet 902. Therefore, this UA can be viewed on any network display application with access to this geographic area and authorities 1060 with proper authorization could look up more in-depth ownership and/or piloting information for this UA (information that had been collected upon purchase/registration.)

(95) Scenario G: Commercial Small Business Flight in Mixed Rural and Suburban Environment (Standard RID Capability in General Approved Airspace)

(96) In this scenario, the commercial small business is a land surveying company with a small fleet of ten UAS. On a particular workday, six survey teams are sent out to conduct eight projects. The teams use an internet connected mobile or desktop application 1050 provided by their USS/UTM service 920 to obtain flight session IDs for each project. The teams are accessing their USS/UTM service via the public digital service utility's universal login feature 930 and receive a Session ID that originated with the utility 920. Teams transfer each ID to their respective broadcast-enabled UAS via a near field connection (NFC), Bluetooth or Wireless connection. Each session ID has been encumbered by the UTM service with the appropriate flight authorization/traffic management timeframe and airspace constraints. These flight constraints are critical for the public and local law enforcement to verify the purpose and provenance of the flights (and associated PII if necessary) as they fly near residences and public infrastructure.

(97) Scenario H: Urban Commercial Delivery (Commercial/Advanced RID Capability across a combination of General Approved, Controlled and Restricted Airspace with Automated and BVLOS Flight)

(98) In this scenario, a very large package delivery service operates a local fleet of several hundred UAS, each with multiple flights in a 24-hour period, within and nearby an urban area. The corporation has developed a USS/UTM application 1060 that logs in to its USS/UTM service provider 920 via the public utility's universal login 930, 940 and streams flight plan authorization requests to the UTM service provider who obtains Session IDs from the utility, ties them to flight plan and flight plan authorization status and returns them to the delivery service for transfer into the UAs. The UTM service assures that the BVLOS and semi-autonomous flights are monitored and adjusted via constant network 902 connectivity. Ubiquitous broadcast receivers 1020 along the flight paths provide an essential back-up for monitoring flights during any network anomalies or service dead zones crossed by the flight paths.

(99) These operations may see the UAS fleet operate through numerous urban canyons or patches of airspace that drop network service due to obstruction (buildings) or even temporary network saturation. In this event, the UAS are equipped with both broadcast and network capabilities, enabling them to continue maintaining safe and effective operation of RID services in the event of these drops in service. The RID verification system 940 can continue to provide network situational awareness of broadcast equipped aircraft with receivers 1020.

(100) USS/UTM display applications on smart devices 1020 can deliver RID information to the general public, receiving customers, or law enforcement based on the end user's stakeholder status (A police officer 1060 sees more than the general public 1060).

(101) The delivery UA can authenticate (again, using the universal login credentials and service provided by the public digital service utility 920) with a RID-equipped smart mailbox that unlocks for package delivery.

(102) Scenario I: Federal Law Enforcement Drug Trafficking Surveillance Flight Along Rural Southern Border (Commercial/Advanced RID Capability across multiple dynamic airspace types).

(103) The USS 920 recognizes this as an approved or authorized aircraft, just as it would any other approved and authorized aircraft. Airspace access, via the federal RID credential, may be waived or merely recognized as approved on the UTM side, permitting the UAS to operate unencumbered. Actual aircraft RID is recognizable only by authorized stakeholders, such as federal agencies or local law enforcement partners. The general public sees this aircraft as approved with session-ID license plate information, just like they would any other session-ID operating UAS. The agency may choose to self-identify and announce their aircraft as a LE operated aircraft should they wish.

(104) Scenario J: Multiple Stakeholder UA Flight at Sporting Event with Complex Airspace (Commercial/Advanced in Restricted Airspace)

(105) The Indianapolis 500, the largest single-day sporting event in the world, is a tremendously busy airspace with mixed manned and unmanned aircraft, special rules, and significant security considerations. In this environment only specifically credentialed and cleared UA are enabled to enter the airspace around the Indianapolis Motor Speedway. These may include public safety UA, approved film/media production UA, or other approved UA all performing both Local Broadcast and Network communications.

(106) The core IdM FPID system 900 is simultaneously feeding RID data into the Command and Control (C2) and C-UAS tools 1050 used by authorized authorities 1060 so they may conduct the airspace security mission for the Indianapolis 500.

(107) Scenario K: A law enforcement officer (LEO) investigates a suspicious UAS either seen by her own eyes or alerted to her by the general public. The LEO utilizes the approved application 1022 on their phone 1020 to query the airspace and the aircraft in question. The specialized display application queries the IdM FPID RID Verification Service 940 for information about the UAS, which includes information from the UAS registry 942 and other US government data sources 944, which is then returned to the officer. Based on a violation, or not, the officer can make a decision and take action if necessary.
Scenario L: Session ID from Utility as Single Source of Truth for air defense.

(108) A SSOT is critical for air defense. In the event of no SSOT, if there's an error and a duplicate ID, multiple ID, or missing ID is in place then an air defense/security authority is likely to engage mitigations. This would result in a negative outcome, such as a shelter in place order for the National Capital Region or the unnecessary downing of a UAS and potential collateral damages associated with that action.

Additional Features and Embodiments

(109) The systems and methods of the following additional features and/or embodiments further allows for the establishment of communications protocols in a safe and sensible manner that both protects and shares identity and other informational data at the same time. The below components of or the complete system 200 and associated methods disclosed may be combined with components of or the complete above disclosed FPID system 900.

(110) Referring to FIG. 2, and illustrative embodiment of an air traffic identity and management system 200 according to the present disclosure is illustrated. The system 200 can be used to identify and manage UAS 230 and piloted aircraft 120a-b, and generally includes one or more processors 260, an application layer 262, a data store layer 270, and a secure layer 280, for example a blockchain layer. Advantageously, system 200 is network based and can use an existing network such as a wide area network (WAN) 106; therefore, rather than depending on and requiring conductivity to a specialized, dedicated communication network, such as dedicated radio network stations 104 (FIG. 1), system 200 components and users only require a connection to WAN 106. For example, other devices or systems 296a-n, including users such as local law enforcement, existing air traffic control system 110, and the public, can access system 200 at processor 260 via WAN 106.

(111) The UAS 230 includes aircraft 231 and optional remote controller 240, used by operator 250 to remotely pilot aircraft 231. For some UAS 230, the aircraft 231 is controlled autonomously, whether onboard the aircraft of using a remote processor, for example, one of devices 296a-n running an instance of control software (not shown). A typical aircraft 231 can including identity module 232 enabling cooperation with system 200, identity module including, for example, one or more of transceiver 234, memory 236, and processor 238 to transmit and receive informational data pertinent to system 200 as further discussed below, including for example, data pertinent to identity and position and velocity, for example as determined from timing signals received from GNSS 102. In at least one embodiment, transceiver 234 is capable of direct communication with WAN 106. In at least another embodiment, communication with WAN 106 is via controller 240. For example, controller 240 can include one or more of identity module 242, transceiver 244, memory 246, and processor 248. The transceiver 244 of controller 240 provides communication with transceiver 234 of aircraft 231, for example, via a secure radio link, and the controller 240 is in communication with WAN 106, for example, via a cellular network connection. As such, informational data associated with system 200 and stored locally in UAS 230 may be stored in memory 236 and/or memory 246 and processing in UAS 230 associated with system 200 in part may be in processor 238 and/or processor 248. For example, access credentials or informational data pertinent to access credentials associated with UAS 230 and/or operator 250 may be stored in memory 236 and/or memory 246 and used to access the application layer 262, data store layer 270, and secure layer 280.

(112) The illustrative air traffic identity and management system 200 may also include passive interrogation device(s) 290. As will be described further below, the passive interrogation device 290 can be any processor, including handheld computing devices such as smartphones and tablets, that provides a position of interest to processor 260 to query. For example, sensor 291 may include a camera, GNSS receiver, and solid state accelerometer that together function with process 292 to determine the geographic position of device 290, a relative position of UAS 230 at which the camera of the device is centered on, and thus a geographic position of device the UAS. The device 290 can then transmit the position of the UAS 230, for example, approximate coordinates and altitude, in a query to processor 260, along with a user credential. As further described below, processor 260 can receive and provide at device 290 a response from processor 260 relating to the UAS 230 and/or operator 250, including for example, informational data pertinent to flight activity authorization, identity, and even the location of operator 250, depending on access policy and the authorization associated with the user and/or device 290.

(113) In one illustrative system 200, UAS 230 and interrogation device 290 may be capable of direct communication, with UAS 230 either broadcasting or responding to an interrogation request from device 290 and send informational data that can be received directly by the interrogation device 290. For example, the direct communication may be via commonly featured wireless connections such as WIFI or BLUETOOTH, or a specific aviation related technology such as ADS-B.

(114) Referring to FIGS. 2 and 3, the processor 260 may be a dedicated backend, distributed, virtual, cloud, or other former of server or other processor known in the art. An application layer 262 may include one or more of an access application 264, data access mediation application 265, authentication application 266, network communication 267, and other applications 268, including, for example, third-party apps that use system 200. The applications 264-268 may be located on a single processer 260, or may be located one or more of various processors, including processors associated with UAS 230, remote controller 240, passive interrogation device 290, and other devices and systems 296a-n. Additional applications pertinent to aspects of system 200 as are known in the art may also be included in the application layer 262.

(115) A data store layer 270 may include informational and other data pertinent to system 200 and its operation, including but not limited to one or more databases or other localized or distributed data storage architecture, including but not limited to the following registries and/or journals (non-limiting terms simply illustrative one or more collections of related informational data). An operator registry 272 can include data pertinent to operators such as remote and non-remote pilots. A device registry 273 can include data pertinent to aircraft or other devices, including for example, UAS 230 and aircraft 120a-b. An event journal 274 can include data pertinent to planned, active, or historical flight or other activity. An aeronautical registry 275 can include data pertinent to airspace, airports, geographic features, and other information pertinent to flight activity, including airspace restrictions and other regulatory information. A policy registry 276 can include informational data relating to user access to application layer 262, data store layer 270, and security layer 280, including for use by data access mediation application 265, relating to flight approval and priority for UAS 130, aircraft 120a-b, and operator 140, and relating to other aspects of interaction with and functional aspects of system 200. A local regulation registry 277 may include data pertinent to a geographic localized area, for example, state, county, city, or other territorial laws, regulations, emergency operational implications and/or conditions that may be separate from and/or more localized than typical airspace operating restrictions. Additional informational data and system data pertinent to aspects of system 200 as are known in the art may also be included in the data store layer 270.

(116) A security layer 280 may include data integrity and security aspects of system 200, for example, application of cryptographically linked data records, for example, blockchain technology, to access and content for system 200, for example, permissions-based blockchain as is discussed further below.

(117) Depicted in FIG. 4 is an exemplary secure database ecosystem 400 implemented by the identity and management system 200, according to embodiments of the present disclosure. The ecosystem 400 collects and shares information, for example, for a manned or unmanned air traffic system, or alternatively, an air traffic identity and management system comprising both manned and unmanned aircraft. At the center of the ecosystem 400 is the multi-layered secure database 402 as described herein for storing and selectively providing access to the ecosystem 400 data.

(118) The secure database 402 acts as a trusted broker of all information provided and collected within the ecosystem 400. Any ecosystem stakeholder (user) 404 may connect to the ecosystem 400, for example, using an Application Programming Interface (API), such as an unmanned traffic management system (UTM), and receive informational data pertaining to and/or provided by a multitude of sources. Such sources can include: aircraft owners 406, aircraft operators 408, aircraft and system manufacturers 410, and affiliated services 412. Informational data pertaining to aircraft owners 406 can include, without limitation, certificates, authorizations, insurance information, regulatory information, point of origin data, and/or affiliated business information. Informational data pertaining to aircraft operators 408 can include, without limitation, training data, operator competency-related data, operating activity logs, and/or operator currency. Additionally, informational data pertaining to aircraft and system manufacturers 410 can include, without limitation, firmware information, aircraft model, aircraft serial number, transceiver information, remote controller information, and/or maintenance records. Affiliated services 412 can include any additional data which may be provided by, for example, employers, insurance, aircraft databases, associations, community organizations, flight logs, certificate authorities, government regulators, manufactures, registries, owners, radars, detectors, other UTM services (e.g., AirMap, Consortiq, Geo.Network, JdxMobile, DJI, etc.), software dashboards, training bodies, and more. All of the source information may be provided to or by an aircraft system through pre-existing peripherals and devices associated with the aircraft, including the aircraft and/or controller themselves, and the telemetry and data from that aircraft.

(119) Other sources of pertinent information may be international regulatory bodies, such as the International Civil Aviation Organization (ICAO) 422, or an individual country's regulatory body 424, such as the Federal Aviation Administration (FAA) in the United States. ICAO, for example, maintains the standards for aircraft registration (e.g., tail numbers), including the alphanumeric codes that identify the country of registration (e.g., aircraft registered in the United States have tail numbers starting with N). ICAO is also responsible for issuing alphanumeric aircraft type codes containing two to four characters. These codes provide the identification that is typically used in flight plans. The FAA, on the other hand, is a United States national authority with powers to regulate all aspects of civil aviation, including the construction and operation of airports, air traffic management, and the certification of personnel and aircraft. A certificate authority 426 may review data provided by an individual country registry 424, or an international body such as ICAO 422, to ensure and establish that the data has met a specific set of requirements before providing it to the secure database 402. With the advent and growth of UAS it is also conceivable that local agencies or regulatory bodies that relate to local privacy, noise, public safety, risk, and other aspects of flight activity effecting local interests will also play a role in regulation, including identifying and managing UAS.

(120) Once the third-party information is collected by the secure database 402, the information is then broadcasted throughout the ecosystem 400, or the identity and management system network, identifying the aircraft's physical location through GNSS, geographic, geofence, or other service or hardware, including radar and radio frequency (RF) technologies, which utilize location based-services.

(121) Stakeholders 404 are any ecosystem 400 user engaging with the ecosystem 400 through an Application Program Interface (API) 420, such as the identity and management system mobile application, a third-party API, or any subsystem or peripheral of the system. Stakeholders may include, but are not limited to, the general public 414, government agencies and law enforcement officers 416, or any other users 418, such as aerospace regulators. The ecosystem 400 APIs 420 interconnect with third-party Geographic Information Systems (GIS), mapping, geofence, and location-based services to share and display an identification of an aircraft and its geographic position across a wide variety of service providers, therefore synchronizing the communication of the aircraft's identity across the network. To accomplish this, the ecosystem 400 is configured to broadcast or otherwise provide the user's identity and additional information to third-party APIs, enabling a user of the ecosystem 400 to communicate their information to all ecosystem stakeholders 404 without regard to which API the stakeholder 404 is using to access the information.

(122) The ecosystem 400 can determine what levels or types of aircraft identity information is shared to a querying stakeholder 404, for example, based on the ecosystem's 400 permission-based blockchain technology. Some stakeholders will only see whether the aircraft is cooperative and approved to fly in the airspace or they may see greater details and personally identifiable information from that aircraft and its operator/pilot. For privacy and security of the aircraft owners 406, operators 408, and manufacturers 410, some stakeholders 404, such as government stakeholders 416, may receive additional and/or more detailed information than what would be provided to a different stakeholder, for example, a general public stakeholder 414. The following are examples of queries from and data points provided to particular stakeholders 404 having varying levels of access credentials.

(123) For a query about an aircraft from the general public 414, the data access mediation application 265 (FIG. 3) may only share data indicating whether the UAS 130 or other aircraft is authorized or unauthorized to be airborne in the particular airspace queried by the user and possibly whether the UAS or other aircraft is known (cooperating) or unknown (non-cooperating) with the system 200. The system 200 can make such an authorization/non-authorization determination by reviewing the data provided from the air traffic regulating bodies participating in the ecosystem 400, for example, if the FAA has initiated a geofence to temporarily restrict air traffic within a particular airspace. The secure database 402 may also share the current geographic position of the aircraft and/or the current geographic position of and/or other information about the aircraft operator, which may be a human or a machine, if the aircraft is unmanned. These geographic positions can be reported in real-time as they will in most circumstances change while the aircraft is in flight, or if not available in real-time due to lack of connectivity with the WAN 106, may be available at a later time as discussed herein.

(124) For a query about an aircraft from a law enforcement agency 416, the data access mediation application 265 may share any information about the aircraft which may be appropriate for law enforcement to receive, such as the identity of the owner, operator, manufacturer, flight authorization status, location of the operator and/or remote controller, and/or its flight history. For example, a law enforcement agency 416 providing protection for an event or location may elect to take counter-UAS or other defensive action if a query using system 200 determines a UAS is unauthorized and/or non-cooperative with the system 200. Similarly, a user affiliated with a regulatory agency 418 may be provided access to the same or a subset of the data provided to law enforcement user 416, as appropriate.

(125) Depicted in FIG. 5 is a process diagram of an illustrative embodiment of a method of mediating access to information requested by a user of system 200. The method 500 begins 502 with an administrator of the secure database provisioning a mediated access policy 276 at step 504. Advantageously, the access policy may be a dynamic policy which reacts and responds to real-time situations, such as temporary access credential modifications instituted by law enforcement or regulatory bodies in response to particular events, as well as to policy changes promulgated by legislative, administrative law, or other processes. Next, at step 506, user set up a user credential via an API or other system affiliated user interface with the system 200. These credentials will ultimately be reviewed by the data access mediator of the secure database once a query or other request for access is made within system 200. Next, at steps 508, 510, 512, and 514, a system administrator and/or users provision the local regulatory registry 277, the aeronautical registry 275, the aircraft registry 273, and the operator registry 272, respectively. In additional to relevant airspace and airport information, the aeronautical registry 275 may include a geographic database, or the GIS, mapping, and location-based services, may be provided by third-party services and provisioned to work in affiliate with and overlay data in conjunction with the system 200 and identity and management system ecosystem. The airspace, aircraft, and operator, and optionally the manufacturer registries are each provisioned by inputting each respective portion of data into the secure database. Upon the completion of these steps, which may be performed in any order, the identity and management system ecosystem is prepared to engage with the stakeholders.

(126) At step 516, the application 264 receives a data access request, or query, from a user. Queries may be made through APIs, map based services, third party applications that have API connections to the application and/or data store layers 270 and 280, and IoT devices, including with augmented or artificial reality capabilities. For example, a user can point a mobile device (e.g., a handheld computer device, tablet or mobile phone), such as passive interrogation device 290, at a UAS 230 in the sky to query information about that aircraft. As described herein, and continuing at step 518, the data access mediation application 265 can mediate the access to the information based on the existing access policy and the stakeholder's access credentials. At step 520, the secure database determines whether the access requested is with regard to a data query or a data provision, and the results of that stakeholder's query may thereafter be provided based on the access level of stakeholder. For a data query, at step 528, the application 265 may first review the access credentials and determine whether to supply the data unaltered, or mask or substitute any data to affect the current policy with regard to the access credentials. In some instances, a law enforcement or military aircraft may require anonymity, and in such instance the data provided about the aircraft in response to a query may be restricted or substituted. Once these steps have been completed, at step 530 the data access reply is provided to satisfy the query. In other cases, for example, an inquiry by the general public, the response may simply be whether the UAS or other aircraft flight activity is authorized, unauthorized, or unknown to system 200.

(127) If, at step 520, the secure database instead determines that a provision query has been made, the method continues to step 522 to determine whether such a provision is authorized, for example, an operator 250 updating their currency or other information. If the provision was authorized, such as if the request was received from a user with the appropriate access credentials to provision the database, at step 524, the secure database will accept the provision and supplement the registry or journal with the data provided with the request and send the data access acknowledgment back at step 526.

(128) Once all query and provision requests have been completed, at step 532, the identity and management system will wait for the next data access request from a user. Access requests may be initiated manually by a person, or may be an automated user in response to events, software algorithms, AI, or other machine based functionality. Once a request is made, the process repeats beginning again at step 516, otherwise the process ends 534.

(129) Depicted in FIG. 6 is a process diagram of an illustrative embodiment of a method 600 for registering a flight plan with the air traffic identity and management system 200 of the present disclosure. The method 600 begins at step 602 and moves to step 604 wherein an aircraft operator/pilot selects an aircraft and planned flight activity. Once this step is complete, at step 606, the operator/pilot then sends, for example via other apps 268, or otherwise causes access to his/her credential, operator information, aircraft information, and planned activity data to the application 264, and the system receives such data at step 608. At step 610, the system, particularly the data access mediation application 265 mediates the operator/pilot's access based upon the operator/pilot's access credentials and the current access policy 276 as described by select portions of process 500. At step 612, the application 264 or other apps 268 will review the flight plan/event activity with regard to the known airspace restrictions, operator qualifications, and other data and/or considerations/policy shared to the air traffic identity and management system 200 which may affect the submitted plan and, at step 614, will determine whether the plan may be approved in accordance with the policies and activities which will be in affect at the time of the planned flight. If the plan is approved, at step 616, the system 200 will provision the activity journal with the planned flight activity and at step 618 send the approval back to the operator/pilot and cease the process at step 626. If the plan is not in condition for approval, at step 620 the system will determine whether a modification is available which would put the plan in condition for approval. If there is no such modification, at step 624, the system will notify the operator/pilot that the planned flight activity has been rejected and the process will cease at step 626. If a plan modification is available, at step 622, the system will send the operator/pilot the suggested modification and/or approve an amended planned activity and return the process back to the beginning at step 604.

(130) With reference to FIG. 7, the air traffic identity and management system 200 of the present disclosure's use of identity, for example, as a key can work with regulators and Unmanned Traffic Management (UTM) Service Providers (USS) to gain access to segregated airspace based upon the key or identity requirements to access this airspace. Some GIS, mapping, and location-based services may have the authority to communicate with the identity and management system 200 to allow or deny the aircraft's entry into a physical airspace based on its information key. Such airspace could be Temporary Flight Restricted (TFR) airspace, VIP airspace, military airspace, airspace around critical infrastructure, or other local or federal airspace and/or flight activity designations within a changing and dynamic air traffic environment. As described by process 700, an area of interest may be geofenced to restrict access to that and be broadcasted to the network. For example, only certain operators or other users with the proper identity and credentials may gain access to this airspace and begin a flight activity within or fly through the geofence boundary.

(131) Depicted in FIG. 7 is a process diagram of an illustrative embodiment of a flight activity including a geofence, according to embodiments of the present disclosure. The process 700 begins at step 702 and proceeds to step 704 wherein the aircraft system is powered up and, at step 706, the operator and aircraft data is sent, for example, by the aircraft 231 or controller 240 of a UAS 230. At step 708, the application 264 or other app 268 receives the data access request. At step 710, the system 200, particularly the data access mediation application 265, mediates the access request based upon the operator/pilot's access credentials and the current access policy as described by select portions of processes 500 and 600. At step 712, the system will determine whether commencement of the flight activity may be approved in accordance with the airspace policies and activities which will be in affect at the time of the flight. If the activity is not approved, at step 714, the system will send the denial and return to step 706 to wait for a new request to be submitted. If the activity is approved, at step 716, the system will supplement the activity journal with data and at step 718 send the approval to the operator/pilot. At step 720, the operator/pilot receives the approval and, at step 722, sends the flight event activity data stream in real-time as the flight is in progress. The system will continually receive, at step 724, the data stream and make determinations about whether the aircraft is operating outside of the authority provided it by the approval. At steps 726 and 728, in no particular order, the system can specifically check the aircraft position and flight data received with regard to the existing geofence boundaries and traffic conditions in the aircraft's airspace. At step 730, the system will analyze the data from steps 726 and 728 and determine whether a geofence boundary or traffic condition has been violated by the aircraft, including relative to a priority assigned to the flight activity in accordance with policy. If there is a conflict, at step 734, the system will send the operator/pilot remediation instructions. At step 736, the operator/pilot will receive those instructions, whether the instructions are provided to a pilot in the cockpit or by an unmanned system operator on the ground. In the case of an unmanned aircraft operator 250, the instructions may be provided to the operator through the unmanned system controller 240 or the operator's connected mobile device. At step 732, if there is alternatively no conflict with geofence boundaries or traffic conditions, the system will send the operator/pilot such acknowledgement and, at step 738, determine whether the activity is complete. If the activity is complete, the process ends at step 740, otherwise the process returns to step 722 wherein the flight activity data steam is again provided and processes accordingly.

(132) With reference to FIG. 8, any user, for example any person in the general public and interested in the identification of a manned or unmanned aircraft 230, can use a device 290 (e.g. a handheld computer device, tablet, or mobile phone) running an API 268 compatible with the air traffic identity and management system 200 of the present disclosure to identify the aircraft when the user points their device at the aircraft. The application 268 can utilize the smart phone's camera to visually identify the aircraft on the screen, and the system may use the geographic location of the device 290 along with the directional orientation the device is facing and triangulation techniques known in the art using the smart phone's movement and relative camera angles to the aircraft 230 to determine an estimated range to develop a geographic position of the aircraft 230 to search. the local airspace for aircraft that are operating based on their electronic broadcast through the identity and management system. More specifically, the mobile device application is configured to utilize both the mobile device orientation and geographic location, along with the geographic location of the aircraft reporting its position within the identity and management system 200, to identify the aircraft that public user is querying. The position of the aircraft system and the position in which the aircraft system is located may be based at least in part on GPS trilateration.

(133) Depicted in FIG. 8 is a process diagram of an illustrative embodiment of an aircraft identification query, according to embodiments of the present disclosure. Although a public user is described herein as the exemplary user of the system embodied by this process 800, it should be understood that any user, such as a government or law enforcement user, or any machine may implement the process 800.

(134) The process 800 begins at step 802. At step 804, wherein the public user powers the passive interrogation device 290. As described herein, the passive interrogation device 290 may include a handheld computer device, tablet, mobile phone, or any other device such as an air traffic control workstation which is capable of interrogating an air traffic identity and management system, optionally without any active communication with the target aircraft 230. At step 806, the user observes the aircraft 230 which the user wishes to retrieve identifying information for. At step 808, the user points the interrogation device 290 toward the aircraft, and the interrogation device using sensors 291 and other possible inputs, including GNSS 102, determine the geographic position of the aircraft 230. At step 810, that information is sent to application 264 to query the aircraft identification data, along with a user credential. The application 264 receives the access request and credential at step 812. At step 814, the identity and management system 200 will correlate the estimated geographic location received from the interrogation device, which can be a combination of the geographic location and the orientation of the device along with estimated range, with the known aircraft data provided to flight activity event journal 274 of the system 200, for example, such as by processes 600 and/or 700. If no data is found from the correlation, at step 816, the system can provision a new flight event activity into the event journal 274. Otherwise, if data is found from the correlation, at step 818, the system will mediate the data access by way of the data access mediation application 265 utilizing the existing access policy in conjunction with the user credentials. Upon making a data access determination for the specific user, at step 820, the system will determine whether the aircraft information should be masked or substituted for any reason, such as if a covert law enforcement or military operation is in progress, and/or if the querying user is only authorized a generalized, substituted response that the flight activity is authorized or unauthorized. Once the system 200 determines which data to provide to the user, at step 822, the system responds to the user and provides the data to the device 290. At step 824, the user receives the data pertaining to the aircraft and, at step 826, the interrogation device can display or otherwise communicate the data to the user. The process then concludes at step 828.

(135) The air traffic identity and management system of the present disclosure could be applied to several types of Internet of Things (IoT) or internet-connected devices which are in need of identifying the authenticated and verified user of the device. More specifically, the air traffic identity and management system can be used as a trusted broker to authenticate and verify the authenticity of users in any type of data sharing ecosystem. This can include user-directed and owned Internet of Things (IoT) devices, unmanned devices, or individuals interacting with financial data systems.

(136) Today's identity-tracking systems are in need of security reform. Identity systems are commonly inefficient, corrupted, or stolen. The repeated defeat of identity will not stand as acceptable in the evolving cyber environment. The air traffic identity and management system described herein, as an advanced and secure permissioned blockchain, can work across the variety of social systems that require authenticated identity.

(137) The user's identity is built by populating the identity and management system with information sourced from the connected services and natively entered and verified data from the user. The combination of this information, regularly updated via the APIs, make up the user's identity and management system.

(138) Sharing of identity is done on a permission basis. The user may opt to share a portion of or the entirety of their identity information with certain types of users, components, and third parties in a UTM ecosystem and elsewhere through the Internet or other connected network. These third parties and other users could be customers of the user, regulators, the public, and other service providers. The underlying basis is that this is a permission based blockchain and that allows the user to share their information with a wide variety of stakeholders, but those stakeholders are only able to gain access to the information that they've been permitted to view and interact with. Access to identity information from these third parties is through identity and management system APIs. There are at least two methods for tracking aircraft.

(139) Telemetry data packets can be paired with the identity blockchain information-enabling rapid up to date query and tracking of aircraft and devices connected to the identification and management system while also enabling the secure transmission of information contained in the blockchain.

(140) Aircraft/device telemetry data can also be packaged directly into the identity and management system blockchain information. This is done so periodically throughout the operation of the aircraft, enabling the enhanced security and verification of tracking when paired with the more rapid telemetry data packets that are paired, but not directly included into the identity and management system blockchain.

(141) The telemetry data packets notify location based services, including the identity and management system mobile application, that the system user aircraft/device is nearby or requesting access to the airspace or area administered by the location based service provider. While the location based service queries the identity and management system blockchain information to get access to the information that it needs to verify and authenticate the identity of the user and allow access to the aircraft/device.

(142) Security.

(143) As a permissioned based blockchain, the identity and management system is highly secure through the use of hash keys that link blocks together. In one embodiment, all blocks in the chain must authenticate to a previous block in the chain, establishing a secure provenance of information.

(144) Connectivity.

(145) The system's flexibility to build upon its blocks allows for API integration into the chain to build up on and contribute to the information that constitutes the identity of the user. This information, via the third parties, can be wide and vast, but the sealing of it in the blocks for permissioned viewing is highly desirable to the identity and management system and not previously known.

(146) Interoperability.

(147) The identity and management system is designed to be interoperable with a variety of existing and future systems and users-enabling the widespread dissemination and access to the blocks, based on stakeholder permission to view the information within the blocks. The identity and management system's flexibility is designed to allow access from nearly any internet connected device or service that has an approved API for connecting to and querying the identity and management system user identities.

(148) Interaction with Evolving Technologies & Policies

(149) The interoperability allows for it to not just be accessed, but also broadcast across physical and cyber mediums. The information keys can be accessed via broadcast radio, BLUETOOTH, or WIFI, and, pending the correct key is utilized, the third party user with the permission can gain access to the identity information that is broadcast through that transmission.

(150) The identity and management system is designed to handle changes in the types of information that is required to be broadcast or shared from a policy standpoint. The flexibility of APIs to allow third party access assists with this from a technical perspective, but the identity and management system is setup to handle a wide variety of information so it is still functional in the event of policy alterations.

(151) ID Through Permissioned Blockchain:

(152) A blockchain based system can collect disparate information related to the user. The user authorizes the system to act as a trusted broker of their information to share with stakeholders who have permissions to access certain levels of personally identifiable information. The blockchain system according to this disclosure can connect to a variety of information and sources that range from associations, insurance policies, government databases and registries, private databases and registries, as well as the aircraft that the operator is flying.

(153) The APIs that connect to the aircraft pull information from the aircraft into the system, linking it with the personal identifiable information. Such information could include the ground station, the aircraft, GPS location, make/model/firmware versions, and telemetry of the aircraft.

(154) The identity, via the blockchain system, is queryable based on the location of the aircraft, or the IoT connected device. Queries may take place through integrations of internet connected devices or devices that have local network connectivity to the BLUETOOTH and WIFI channels that the aircraft or it's respective remote controller are broadcasting.

(155) The above functionality is built through a series of APIs that can be plugged into third party applications, devices, and hardware that can produce similar to like functionality.

(156) The identity of the aircraft and their users can also be used in conjunction with geofencing services to act as a key to gain access to those airspaces. Access to those airspaces is based upon the matching keys of the identity. The geofences and keys are dynamic and capable of altering permission for the IoT device to enter based upon the content of the identity that is represented in the blockchain system.

(157) Blockchain is a transformation in the design of the ledgerit allows multiple parties to share information digitally in a distributed manner that is built upon the trust of previous records, or information blocks, in an efficient manner. It is most commonly understood as the technology that underpins crypto-currencies, but its ability to share information and establish trust is what makes it valuable and what makes it useful for the UAS industry and regulators as a registration and identity system.

(158) A permissioned blockchain allows operators to register their information and allows regulators and operators to determine who can access and view ledger records. In an example flight with 26 record inputs the regulator may need to see information points A, B, and C of a flight's information block to identify and authorize the UAS operator, aircraft, and flight. At the same time the public may only be privy to information points A and E (if any) and the operator's client privy to information points C, F, G, and Z. Information points could range from name to location to certifications. In this way, the operator's identity is both shared and protected while simultaneously establishing a trust with the public, client, and regulator. Robust identification based on trust may be the future of UAS operations, but it need not be Orwellian. All users can expand into a new era of interconnectivity with this model. An operator's personal or confidential information isn't compromised and the public is delivered assurance and peace of mind that the aircraft that just flew overhead is authorized to be there and is not engaged in malicious behavior. This distributed permission of information builds trust with the public, ensures authority, and is critical in the forward progression of the industry.

(159) The protection of the operator's information is vital. There are numerous examples of malicious and even violent behavior exhibited by individuals towards UAS operators. Exposing operator identifiable information is unacceptable, could jeopardize the operator or business, and does not follow suite with the practice of manned aircraft in US Class G airspace or even automobile registration and operation. The blockchain can however advise the public that the operation is authorized while granting the regulators the information they need for an operator to fly in a variety of airspaces or across boarders. We do not suggest that every flight need to submit identity to a regulator or public, but we know that it will be required in certain types of operations and airspaces for which the blockchain can be a solution.

(160) Security is addressed through the blockchain's distribution and cryptographic processes for sealing records, preventing their tamper or alteration. No system will ever be perfectly secure, but the crypto-key and record dependent system in a blockchain is robust and helps to fulfill trust and verification through access of records. To break it would require enough computing power and expertise to alter the majority of the system-a difficult task considering the nature of the industry's size. Interfacing with other security protocols, such as SSL, is not impossible and further layers can be introduced should they become necessary. The security of blockchain systems is well recognized and has been implemented by the government of Estonia for many of their information networks as well as NATO, the U.S. Department of Defense, and the European Union.

(161) The transformation of data in this system, like an ID, is instant and flexible. The ledger can be synchronized amongst regulators for case of information transaction when transitioning airspaces or boarders. Regulators can immediately identify if the operator has the proper documentation they need to prove airworthiness or access to their airspace in a trusted system.

(162) We envision regulators working on the same global blockchain so that all regulators can verify users amongst the industry, distributing identity verification around the globe, bridging trust gaps between states that benefit users, regulators, and operators.

(163) Trust is the necessary factor to gain access to airspace and the blockchain can verify a complete record of flights, permissions, certificates, training, and other information that may be necessary to grant access to airspace.

(164) A fascinating and powerful function of the blockchain is that it does not care if the operator is a human or a computer. It doesn't know the difference between a heart and a processor, but it can facilitate the registration, identification, and system interaction of both human, machine, and the people who may be responsible for the machines. This facilitation is critical for expansion of the industry as manual operations share the skies with automated operations.

(165) While examples, one or more representative embodiments and specific forms of the disclosure have been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive or limiting. The description of particular features in one embodiment does not imply that those particular features are necessarily limited to that one embodiment. Some or all of the features of one embodiment can be used in combination with some or all of the features of other embodiments as would be understood by one of ordinary skill in the art, whether or not explicitly described as such. One or more exemplary embodiments have been shown and described, and all changes and modifications that come within the spirit of the disclosure are desired to be protected.

(166) Element Numbering

(167) The below list includes element numbers and at least one word used to describe the member and/or feature represented by the element number. It is understood that none of the embodiments disclosed herein are limited to these descriptions, other words may be used in the description or claims to describe a similar member and/or feature, and these element numbers can be described by other words that would be understood by a person of ordinary skill reading and reviewing this disclosure in its entirety.

(168) TABLE-US-00004 100 Prior Art Aircraft Identity and Management System 102 GNSS System 104 Dedicated Radio Network 106 Wide Area Network 110 ATC 120 Manned Aircraft 122 Transponders 130 Unmanned Aircraft System (UAS) 132 UAS Aircraft 134 UAS Transceiver 140 Remote Controller 142 Remote Transceiver 144 UAS Operator 200 Inventive Air Traffic Identity and Management System 230 Aircraft System (Manned or Unmanned) 232 Aircraft Module 234 Aircraft Transceiver 236 Aircraft Memory 238 Aircraft Processor 240 Remote Controller 242 Controller Module 244 Controller Transceiver 246 Controller Memory 248 Controller Processor 250 Operator 260 System Processor 262 Application Layer 264 Application 265 Data Access Mediation Application 266 Authentication Application 267 Comm. w/ Network 268 Other Apps (e.g., 3rd Party) 270 Data Store Layer 272 Operator Database 273 Devices/Aircraft Database 274 Events/Activity Database 275 Aeronautical Database 276 Policy Database 277 Local Regulation Database 280 Security Layer/Blockchain Layer 290 Interrogation Device 291 Device Sensor 292 Device Processor 296a-n Other Devices/Systems (ATC, ADS-B, Other Apps) 400 Secure Database Ecosystem 402 Secure Database 404 Stakeholder/User 406 Informational data pertaining to an owner of aircraft systems 408 Informational data pertaining to an operator of aircraft systems 410 Informational data pertaining to an manufacturer of aircraft systems 412 Informational data pertaining to affiliated services of aircraft systems 414 Public Stakeholders/User 416 Government/Law Enforcement Stakeholders/User 418 Other Stakeholders/User 420 Application Program Interface 422 ICAO Registry 424 Country Registry 426 Certificate Authority 900 FPID System 902 RID Network 910 FPID Core subsystem 920 USS 924 API Gateway 930 Registration and Login Gateway 940 Verification Service Gateway 942 FAA Registry Database 944 Other Gov't Data/Database Services 1010 RID beacon 1012 RID firmware 1020 RID receiver 1022 RID software 1030 Networked UAS 1040 Non-networked equipped UAS 1050 User access/display software 1060 Users/User Systems