Patent Description:
<CIT> relates to a method and system for updating navigation information.

A modern aircraft, in flight, requires a navigational database (NAVDB in this document, sometimes referred to as "NDB" in the art) to provide essential data regarding airports, airways ("highways in the sky"), airport approaches (the "on-and-off ramps" to airports), terrain database(s), airport physical infrastructure, runways, navigational aids, gates, standard instrument departures (SIDs), standard terminal arrival routes (STARs), and similar data. This data is essential for safe landings and take-offs, and assists in avoiding conflicts with other air other traffic and with ground obstacles.

The NAVDB must be updated on a regular basis, on what is known as an "AIRAC cycle" which occurs every <NUM> days. These updates provide revised information for runway closures, airport maintenance, airport communication frequencies, standard instrument approaches, VHF and NDB (non-direction beacon) navigational aids, and other changes in the ground-based, aircraft-support infrastructure. (This updating may be viewed as being similar to the way car and truck drivers will update the GPS systems for their cars, and further to the way GPS updates are likely to be essential for self-driving cars in the future. Essentially, airplanes need the latest airway and airport data, as well as the latest flight procedures and rules.

In current worldwide practice, various states (whole nations or states within nations) have government or civil organizations which publish appropriate navigation data and update the data on a regular basis. The updated data is then obtained by, and consolidated by, a handful of organizations or private companies (for example, Jeppesen, Lufthansa Systems FlightNav Inc. , and others). The consolidated data is then sold in industry-standard formats to other large third-party suppliers of aircraft systems and vendors of aircraft navigational data, such as for example General Electric Aviation (G. (For example, the license server <NUM> of exemplary system <NUM> (as illustrated in <FIG> below), and which provides an updated NDVDB <NUM> at regular intervals, may be a license server maintained by a vendor such as General Electric, Inc.

Typically, aircraft data vendors such as G. AV will process the NAVDB data to compile the data in a GE-proprietary form. Compiling the data may entail, for example and without limitation: sub-setting the data based on memory-size constraints or other factors, and data compression. The compiled NAVDB is then distributed to each airline which pays the vendor (such as GE Aviation Systems (GEAS)) for the NAVDB, which is typically licensed on a fee per-aircraft basis. The NAVDB vendor will therefore typically maintain a database or listing of specific aircraft which are authorized (by contract and with a paid license fee) to receive the NAVDB updates.

In legacy systems (that is, current distribution systems), aircraft are typically not connected to the internet during time on the ground or in maintenance. Therefore, aircraft maintenance personnel use entirely local data means, such as floppy disks or Ethernet loaders, to load an updated NAVDB onto airplanes. These are direct electrical connections to a flight management system (FMS). This can cause delays in data loading, and also fails to provide any means to audit data uploads, to ensure that only properly licensed airplanes (as identified by their "tail numbers") can obtain the data. Currently, financial billing for data updates is performed on an "honor system" basis.

In legacy systems, data users (the airlines) report their fleet size to data vendors (for example, G. ) on a cyclic basis, and data vendors such as G. then charged accordingly. This is a very error-prone, coordination-heavy billing process, and with the potential for errors compounded by the lack of per-aircraft authentication of the database upload. In the worst cases, there may be sloppiness in reporting, and potentially even under-reporting of data uploads (whether by error or intent).

What is needed then, is a system and method for reliably updating an aircraft database, such as an aircraft navigation database, with the update process having suitable updating monitoring, tracking, and auditing; and all of this being done while the aircraft does not normally have a connection to a remote update server.

The present system and method addresses the above-noted deficiencies in the NAVDB upload, audit, and billing process.

In some embodiments, the present system and method employs a portable, hand-held computer, such as (for example and without limitation) an electronic flight bag (EFB), an iPad, or other tablet computer with an electronic flight bag app. The portable computing device functions as an intermediary between the database server and each aircraft. By virtue of being portable and being locally linked (over time) to different aircraft, the intermediary computing device can provide the data upload validation and auditing for accurate billing of database usage.

This ensures that each aircraft which receives an upload is entitled to receive the upload based on a paid license. As a result, billing by the database vendor is based on usage. If an FMS of a particular aircraft wants to use the NAVDB in a given cycle, it needs to authenticate against the database/license server with its tail number (or equivalent). The authentication is mediated by the intermediary computing device.

Persons skilled in the relevant arts may recognize that there are existing computing environments where computers and other similar digital computational devices maintain substantially routine, sustained communicative connection with and/or access to the internet. In such "sustained internet" environments, it is commonplace to validate/authenticate/unlock various computer software, databases, and other digital resources via a standing internet connection with a central server.

In the present context, however, such a sustained internet connection is not routinely present. Airplanes in flight, and avionics systems in general, while having radio connectivity with various ground and satellite resources, are not routinely connected to the internet. The present system and method therefore provides for database validation and activation without immediate, contemporaneous internet access, via the intermediary computing device.

Advantageous designs of embodiment of the present invention result from independent and dependent claims, the description, and the drawings. In the following, various examples of embodiments of the invention are explained in detail with the aid of the attached drawings:.

The following detailed description is merely exemplary in nature and is not intended to limit the system and methods, nor the elements or steps of the system and method, nor its applications, and its uses disclosed herein. Further, there is no intention for the scope to be bound or limited to or by any theory presented in the preceding background or summary, nor in the following detailed description. The scope of the present system and method is set forth in the appended claims, as understood in light of the written description.

It will be understood in this document that:
Description of various embodiments may use "comprising" language, indicating that the system and method may include certain elements or steps which are described; but that the system and method may also include other elements or steps which are not described, or which may be described in conjunction with other embodiments, or which may be shown in the figures only, or those which are well known in the art as necessary to the function of processing systems. However, it will be understood by one of skill in the art that in some specific instances, an embodiment can alternatively be described using the language "consisting essentially of" or "consisting of.

<FIG> illustrates an exemplary flight transport vehicle <NUM>, and more particularly an aircraft <NUM>, according to the present system and method. The aircraft <NUM> may include a fuselage <NUM>, a cockpit <NUM> positioned in the fuselage <NUM>, and wing assemblies <NUM> extending outward from the fuselage <NUM>. The aircraft <NUM> can also include multiple engines <NUM>. While a commercial fixed wing aircraft <NUM> has been illustrated, it is contemplated that aspects of the disclosure described herein can be used in any type of fixed wing, rotary wing, or convertible wing aircraft <NUM> or other flight transport vehicles <NUM>, including for example and without limitation: helicopters, re-launchable rockets, and drones.

Controllers and Avionics: The aircraft <NUM> may include one or more general aircraft controllers <NUM>, together referred to as the avionics suite <NUM>. The controllers and/or avionics suite may include a flight management computer system (FMCS) <NUM>, discussed further below. Pilot controls and visual displays <NUM> are linked to the FMCS <NUM>. The FMCS <NUM> may also interfaces with various aircraft control systems and sensors (not shown in <FIG>) to obtain operational status of the aircraft <NUM>.

<FIG> presents a block diagram or system level diagram of an exemplary controller <NUM>, such as a digital flight management computer system (FMCS) <NUM>, which may be employed according to the present system and method. FMCS <NUM> may implement or execute, for example, computer code (software or firmware) which enables the aircraft to perform the data transfers, data storage, and/or data validation methods presented in this document. The computer code for specific functions may be referred to as modules <NUM>, such as the update module <NUM> discussed further below (see <FIG>).

Exemplary controller <NUM> typically has a motherboard <NUM> which typically holds and interconnects various microchips <NUM>/<NUM>/<NUM>, and volatile and non-volatile memory or storage <NUM>/<NUM>, which together enable at the hardware level the operations of the controller <NUM>, the code modules <NUM>, and in particular enable some of the operations of the present system and method. Controller <NUM> may include, for example and without limitation:.

A hardware microprocessor <NUM>, also known as a central processing unit (CPU) <NUM> or microcontroller (MCU) <NUM>, which provides for overall operational control of the controller <NUM>. This includes but is not limited to receiving data from data files or from connections to other computers, receiving data from a target hardware platform, and sending data or files to a target hardware platform. Microprocessor <NUM> is also configured to perform the arithmetic and logical operations necessary to implement the present system and method.

Static memory or firmware <NUM> may store non-volatile operational code, including but not limited to operating system code, computer code for locally processing and analyzing data, and computer code which may be used specifically to enable the controller <NUM> to implement the modules and methods described in this document and other methods within the scope of the appended claims. CPU <NUM> may employ the code stored in the static memory <NUM> and/or dynamic memory <NUM> and/or non-volatile data storage <NUM> to implement the methods and modules described in this document and other methods.

Control circuits <NUM> may perform a variety of tasks, including data and control exchanges, as well as input/output (I/O) tasks, network connection operations, control of the bus <NUM>, and other tasks generally known in the art of processing systems. Control circuits <NUM> may also control or interface with non-volatile data storage <NUM>, and interface with aircraft sensors.

Control circuits <NUM> may also support such functions as external input/output (I/O) (for example, via USB ports, an Ethernet port, or wireless communications, not illustrated in the figure). For example, control circuits <NUM> may include an aircraft interface device (AID) <NUM> for enabling the controller <NUM> and the aircraft <NUM> in general to interface with external and/or portable computing devices.

Volatile memory <NUM>, such as dynamic RAM (DRAM), may be used to temporarily store data or program code, or code modules. Volatile memory <NUM> may also be used to temporarily store some or all of the code from static memory <NUM>/<NUM>.

Non-volatile storage <NUM> may take the form of hard disk drives, solid state drives (including flash drives and memory cards), recording on magnetized tape, storage on DVD or similar optical disks, or other forms of non-volatile storage now known or to be developed. Either static memory <NUM> or non-volatile data <NUM> may be used for persistent storage of various flight-related databases <NUM>, such as the navigational database (NAVDB or NDB) <NUM> discussed further below in this document (see <FIG>).

A system bus <NUM> provides for data communications among the CPU <NUM>, memory <NUM>, <NUM>, and non-volatile data storage <NUM>. A cockpit informational system <NUM>, which may be visual (a display screen or visual projection), audio, or both, may be integrated into or communicatively coupled with the controller <NUM>, so as to present flight data to a captain or first officer of the aircraft. The flight data presented via the cockpit informational system <NUM> may include, among other elements, airport data and navigational data obtained from the NAVDB <NUM> and other stored databases.

Other computational systems: In various embodiments, the present system and method may entail the use of a flight management computer (FMC) <NUM> as described in the exemplary embodiment of <FIG>. In various embodiments, the present system and method may employ additional or alternative computational systems <NUM>, some of which may not be part of the aircraft <NUM>. These alternative, additional, or complementary computers <NUM> may include, for example and without limitation, an electronic flight bag (EFB) <NUM>, discussed below; a portable maintenance tablet computer <NUM> or maintenance pad <NUM>, also discussed below; and/or a license server/database server <NUM> (discussed further below). Persons skilled in the relevant arts will appreciate that these other computer systems <NUM>, <NUM>, <NUM> may include many elements the same as or substantially similar to the aircraft controller <NUM> discussed above, including for example and without limitation: a CPU <NUM>, memory <NUM>, <NUM>, <NUM>, and control circuits <NUM>.

With reference now to <FIG>: Modern aircraft are equipped with a flight management system (FMS) <NUM>. In some embodiments of the present system and method, the FMS <NUM> is implemented via the flight management computer <NUM> (FMC) discussed above, which executes one or more software programs or software modules, such as an Operational Flight Program (OFP) <NUM>. (This document distinguishes between the FMC <NUM>, which is computer hardware, and the FMS <NUM>, which is the FMC <NUM> configured with suitable software programs or modules. Elsewhere in the art, the FMC <NUM> configured with FMS <NUM> may be referred to simply as the flight management computer systems (FMCS); "FMS <NUM>" as used in this document may be considered essentially the same as FMCS as may be used elsewhere. It is also noted that elsewhere in the aviation industry, "FMS" may sometimes refer to "foreign military sales", but no such usage is intended here.

An associated control and display unit <NUM> in the cockpit (discussed above), such as a Multi-Function Control Display Unit (MCDU) enables the flight crew to interact with the OPF <NUM>.

Prior to a flight, the flight crew normally enters a flight plan (a planned aircraft route) into the FMS <NUM>, so that the FMS <NUM> with appropriate flight plan will essentially fly the aircraft after takeoff until close to touchdown. This automated flying is done through the Autopilot (A/P) and Autothrottle (A/T), which may be elements of the OFP <NUM> (not illustrated in the figures) but are often instead elements of other line-replaceable units (LRUs); the A/P and A/T may navigate the aircraft along designated airways according to established procedures.

As one element of this automated navigation, the FMS <NUM> requires a Navigational Database (NAVDB) <NUM>. ("NAVDB" (<NUM>) is employed in this document, but the acronym "NDB" is frequently also employed in the art. ) The NAVDB <NUM> contains information on airports; runways for each airport; and departure and arrival procedures for each airport (which provide for what are essentially pre-defined "on-ramps" and "off-ramps" connecting airports with the airways). The source for the NAVDB <NUM> is an Aeronautical Information Publication (or AIP), a publication containing aeronautical information of a mostly persistent character (such as airport locations) which is essential to air navigation. AIPs are usually issued by or on behalf of the respective civil aviation administrations of various nations.

However, airports can change over time, as can aviation procedures. AIPs are therefore kept up-to-date by regular revisions on a fixed cycle. For operationally significant changes in information, the cycle known as the AIRAC (Aeronautical Information Regulation And Control) cycle is used: revisions are produced every <NUM> days (double AIRAC cycle) or every <NUM> days (single AIRAC cycle). In this document, for convenience and without limitation, an exemplary <NUM>-day revision cycle is assumed.

As a result, an aircraft's NAVDB <NUM> typically needs to be updated every twenty-eight (<NUM>) days in order to maintain current information such as temporary runway closures, or other equipment shut down for things like maintenance. The availability of this data is essential for flightworthiness.

Information services are therefore required by the airlines to obtain the updated NAVDBs <NUM> and to process the updated NAVDB data on the <NUM>-day cycles, with the flight management system (FMS) <NUM> of each individual aircraft <NUM> requiring an update to be stored in its persistent memory <NUM>, <NUM>. Typically, updated NAVDBs <NUM> are provided to the airlines by third-party informational services, with each airline being obligated to pay a per-aircraft fee for the updates.

Persons skilled in the relevant arts will be aware that individual aircraft <NUM> are identified by individual aircraft numbers (or tail numbers). Updated NAVDBs <NUM> are typically loaded into the FMS <NUM> of each aircraft by an aircraft maintenance crew, using tangible local (portable) data storage devices such as old-style floppy drives (which is used to help ensure data integrity and chain of custody, which is not as readily established by other data transfer means such as Bluetooth or USB connections).

As a result, in legacy aircraft, the FMS <NUM> itself or even the crew data device that is used to load the NAVDB <NUM> into the FMS <NUM> is typically not connected to the outside world. Consequently, there is no centralized verification or validation (via a validation code or similar) to ascertain that the particular FMS <NUM> of the particular aircraft <NUM>, as identified by its aircraft number, is entitled to receive the updated NAVDB <NUM>. Further, in legacy aircraft maintenance systems and operation, there is no validation that a correct NAVDB <NUM> (a most recent NAVDB from a validated source) is actually being uploaded into the FMS <NUM>.

The present system and method is directed towards the adaptation of an Intermediary Authentication Device (IAD) <NUM>, which may also be referred to as an Intermediary Upload Device <NUM>, for the upload and authentication of NAVDB updates <NUM>.

In some embodiments of the present system and method, the Intermediary Upload Device (IAD) <NUM> may be a digital processing device and/or digital computational device with a processing architecture which may be the same or similar to that of the exemplary flight management computer <NUM> (discussed above). However, in some embodiments of the present system and method, the IAD <NUM> may different from the flight management computer <NUM> at least in view of portability; while the flight management computer <NUM> is typically designed and configured to be integrated into the structure of the aircraft <NUM>, in some embodiments the IAD <NUM> may be configured as a portable computing device such as a laptop, tablet computer, or possibly some other dedicated, hand-portable computing device <NUM>.

In some embodiments of the present system and method, the IAD <NUM> may be an electronic flight bag (EFB) <NUM> for the authentication of NAVDB updates. An EFB <NUM> is a portable, general purpose computing system that helps flight crews perform multiple different flight management and/or in-flight maintenance tasks. Captains and/or first officers will typically bring an EFB <NUM> on board for each flight (with data which is customized for the airplane <NUM> and the particular flight).

In alternative embodiments of the present system and method, the IAD <NUM> may be a maintenance tablet (MT) <NUM> which is used for multiple purposes, including for the authentication of NAVDB updates. An MT <NUM> is in general a portable, general purpose computing system aircraft engineers and maintenance teams to perform ground-based aircraft maintenance between flights.

<FIG> presents a system-level diagram for an exemplary aircraft database update system (ADUS) <NUM> which in some embodiments is a distributed system. The ADUS <NUM> may be employed for any or all of updating an aircraft database, authorizing an aircraft database, validating an aircraft database, and auditing an aircraft database and/or the aircraft <NUM> itself to determine that the database <NUM> is authorized for use on or with the aircraft <NUM>.

In-flight-database: In some embodiments of the present system and method, the flight-database to be updated, validated, authorized, and/or audited may be a NAVDB <NUM>, as described elsewhere in this document. In alternative embodiments, other in-flight-databases <NUM>, either mission-critical or non-mission critical, may be applicable. ("In-flight-database" and "flight-database" are used synonymously and interchangeably for databases which may be used and accessed during aircraft flight.

Database and License Server: In some embodiments of the present system and method, the ADUS <NUM> may include a database server <NUM> and/or license server <NUM>. The license server <NUM> may store an authorized aircraft list (AAL) <NUM> of aircraft <NUM> which are authorized to receive an update to the NAVDB <NUM>. The AAL <NUM> may identify authorized aircraft by individual aircraft tail numbers or other aircraft IDs. The AAL <NUM> may include other information for auditing purposes, such as the dates of NAVDB updates, fees paid by various airlines for NAVDB updates, and other information pertinent for updating, authorizing, and/or auditing distribution and usage of the NAVDB <NUM>.

In some embodiments of the present system and method, the license server <NUM> may also store a latest, source or original NAVDB <NUM> (identified in <FIG> as the NAVDB primary). In an alternative embodiment, the NAVDB primary <NUM> may be stored on a different server from the license server <NUM>. For purposes of description and brevity only, this document assumes an exemplary system architecture where the NAVDB primary <NUM> and the list of authorized aircraft <NUM> are stored on a common or shared file server.

However, while a single data vendor license server <NUM> is illustrated in exemplary system <NUM>, additional such servers may be involved. For example, the vendor may upload the data to separate license servers <NUM> (not shown in the figure) maintained by each separate airline. Ultimately, however, license servers according to the present system and method are configured, separately or via distributed software modules, to maintain records of authorized aircraft <NUM>, and data transfer, update, licensing, and other pertinent auditing data pertaining to the distribution of digital copies of an updated NAVDB database <NUM> to specific airlines and specific airplanes <NUM>. Thus, the single AAL <NUM> shown in <FIG> is exemplary only and should not be construed as limiting.

Internet, WAN, or LAN: The exemplary aircraft database update system (ADUS) <NUM> is construed to include or to utilize a generalized, wide-area data communications system <NUM> or data network system <NUM>, such as the internet, a wide area network (WAN) or a local area network (LAN). Along with suitable communications links <NUM>, which may be wired, wireless, or a combination of both, the generalized data network <NUM> enables data communications between the license server <NUM> and the intermediary authentication devices <NUM>.

In one embodiment of the present system and method, the license server <NUM> may be a file server which is remote from the airport, such as a third-party government or corporate server <NUM>. In alternative embodiments, the license server <NUM> may be a ground-based computer local to a particular airport.

For purposes of database installation on an aircraft-which may include both an initial installation, and updates-an intermediary communications device (ICD) <NUM> may be employed. The intermediary communications device may be, for example and without limitation, an electronic flight bag (EFB) <NUM> or a maintenance tablet <NUM>, as discussed in more detail above. The ICD <NUM> may be communicatively coupled with the license server <NUM> via one or more communications links <NUM> which may be wired, fiber optic, or wireless (including for example via satellite); and such communication may occur in whole or in part through a local or wide-area network <NUM> or an extended cloud network such as the internet <NUM>. An aircraft captain first officer, or maintenance technician, may use the ICD <NUM> to obtain from the license server <NUM> the primary NAVDB <NUM>; the ICD <NUM> then stores a copy of the NAVDB <NUM> in its local persistent storage <NUM>, <NUM> as a most recently updated NAVDB <NUM>.

The ICD <NUM> may store a list of one or more aircraft IDs <NUM>" indicative of the aircraft which are authorized to receive the NAVDB updates <NUM>. The ICD <NUM> may also store a log (a list or other database) indicative of which aircraft <NUM> have actually received updated NAVDB's, either during a current round of updates and/or in the past. In various embodiments, the list of flight tail numbers/aircraft ID's <NUM>" and the update log <NUM> may be part of a single common database file or structure stored on the ICD <NUM>, or each may have separate storage on the ICD <NUM>.

Flight Management System: Subsequent to obtaining the updated NAVDB <NUM>, the captain or technician may connect the intermediate communications device <NUM> (either the EFB <NUM> or maintenance tablet <NUM>, as appropriate) with the flight management system (FMS) <NUM>. In an embodiment of the present system and method, the connection is made directly and locally, via a wired or wireless connection, and may be made via the aircraft interface device <NUM> which communicatively couples the ICD <NUM> with the FMS <NUM>. In an embodiment of the present system and method, an update module <NUM> of the FMS <NUM> may obtain the updated NAVDB <NUM> and store a copy of the NAVDB <NUM> in persistent storage on the aircraft <NUM>. The update module <NUM> may also communicate and exchange data with the intermediate communications device <NUM> for purposes of database validation, authentication, and/or auditing.

In an alternative embodiment, the ICD <NUM> may load the NAVDB <NUM> into an onboard maintenance system (OMS) (not shown in the figures) of the aircraft <NUM>. The OMS then distributes the NAVDB <NUM> to the FMS <NUM>.

Exemplary Functions of the Intermediary Communications Device: In one embodiment of the present system and method, the exemplary ADUS architecture <NUM> enables a portable, hand-carried, intermediary communications device <NUM> (such as an EFB <NUM> or maintenance tablet <NUM>) to connect with the aircraft's FMS <NUM> while maintaining live connectivity to the license server <NUM>.

In an alternative embodiment of the present system and method, the ICD <NUM> may connect with the FMS <NUM> while not being concurrently connected with the internet <NUM> or license server <NUM>. In such embodiments, the ICD <NUM> may connect with the license server <NUM> at other times (later or earlier) to authenticate an NAVDB <NUM> as valid, and to authenticate the upload of the NAVDB <NUM> to any particular aircraft <NUM>.

In some embodiments of the present system and method, other flight-related databases <NUM> may be uploaded in addition to, or in alternative to, the NAVDB <NUM>.

In some embodiments of the present system and method, the NAVDB <NUM> may be initially locked, meaning the NAVDB <NUM> is encrypted and cannot be read until unlocked. Under the present system and method, the NAVDB <NUM> is unlocked for use on a given aircraft by the ICD <NUM>, but only after the ICD <NUM> has authenticated either or both of the NAVDB <NUM> and the aircraft <NUM> in which the NAVDB <NUM> is uploaded.

In one embodiment of the present system and method, the ICD <NUM> unlocks the NAVDB <NUM> (for example, by decrypting it, or by storing a decryption key on the FMS <NUM> of the aircraft <NUM>) only after: (i) uploading the NAVDB <NUM> to the FMS <NUM>, and after (ii) validating that the particular aircraft <NUM> is entitled to the upload (meaning, the airline has paid for the upload of the NAVDB <NUM> to the particular aircraft <NUM>). The validation is performed based on the tail/aircraft number <NUM> of the aircraft <NUM>, as matched against authorized aircraft/tail numbers <NUM> obtained, by the ICD <NUM> from the license server <NUM>.

<FIG> presents a flow chart of an exemplary method <NUM> for updating a navigational database on an aircraft <NUM> via a distributed system architecture <NUM>. The method may be performed, for example, by an intermediary communication device <NUM> already described elsewhere in this document.

ICD Connects with Server: The method <NUM> begins with step <NUM>. In step <NUM> intermediary communication device <NUM>, while still independent of any specific aircraft, establishes a data communications link with a database server and/or license server <NUM> such as exemplary data vendor license server <NUM>. As part of this step, the ICD <NUM> may establish a secure communication, including an appropriate secure login with the license server, according to security, password, biometric, and other validation procedures known in the art.

Following step <NUM>, and in one embodiment [A] of the present system and method, the ICD <NUM> may automatically download the aircraft database <NUM>, in which case the method proceeds directly to step <NUM>. For example, aircraft database updates may be scheduled for certain dates according to the AIRAC cycle.

Assess if update is required: However, an alternative embodiment [B] of the present system and method may employ an optional step <NUM>. In optional step <NUM>, the ICD <NUM> may determine if it requires an update of an aircraft database <NUM>. Determination may entail, for example, identifying whether the current date is the date on which an update is supposed to occur. In an embodiment, the ICD <NUM> may identify a current version or current date of an aircraft database <NUM>, which is already stored in its persistent storage <NUM>, <NUM>, and compare that with a version or release date of the aircraft database <NUM> as stored on the license server <NUM>. If the license server <NUM> stores an aircraft database <NUM> which is more recent, or of a later version than the aircraft database <NUM> on the ICD <NUM>, then the ICD <NUM> determines that the database needs to be updated. In an alternative embodiment, it may be the license server <NUM> which communicates with the ICD <NUM> and determines if its version of the aircraft database <NUM> is a more recent version than the version on the ICD <NUM>. If in step <NUM> it is determined that the aircraft database <NUM> should be updated, the method proceeds to step <NUM>.

Upload Navigational Database to ICD: In step <NUM>, the most recent navigational database <NUM> is uploaded to the ICD <NUM> from the server <NUM>, where the ICD <NUM> then stores a copy of the database <NUM> in persistent storage as the navigational database <NUM>. The method proceeds to step <NUM>.

List of authorized aircraft: In step <NUM>, the ICD <NUM> downloads from the license server <NUM> the list of authorized aircraft, or authorized aircraft list (AAL) <NUM>. The AAL <NUM> may contain a list of aircraft which are authorized to receive the updated aircraft database <NUM>, for example with the aircraft identified by tail numbers, or other aircraft IDs.

Manual disconnection/transport of ICD: Following step <NUM>, there may be a time delay or hiatus, possibly extending minutes or hours, or in some embodiments, even days, between the performance by the ICD <NUM> of step <NUM> and the performance by the ICD of step <NUM>. During this hiatus, the user of the ICD <NUM> (who may be an aircraft captain or first officer, or aircraft maintenance person) may optionally disconnect the intermediary communication device <NUM> from the internet <NUM> and/or data license server <NUM>; and will typically transport the ICD <NUM> to an aircraft <NUM> (via hand-carriage or on-person carriage). (This procedure is not included in the flowchart of method <NUM> in <FIG>.

ICD coupled with aircraft: At the aircraft, and in step <NUM>, the aircraft captain or aircraft maintenance person establishes a physical and communicative coupling between the ICD <NUM> and the flight management system <NUM> of an aircraft <NUM>. This physical coupling may entail connecting the ICD <NUM> to the flight management computer <NUM> via connections known in the art (such as wireless connections, which may entail Wi-Fi or Bluetooth; or via a wired link such as USB, Ethernet, or fiber optic link; or via an expansion of the ACARS network). In some embodiments, the physical layer linkage may be mediated by aircraft interface device <NUM>. Also in step <NUM>, the ICD <NUM> and the flight management systems <NUM> establish signaling, logical, and data links (for example, data, session, transport, and application layer communications links) which may entail various validation and authorization procedures according to methods well known in the art.

Obtain aircraft ID number: In step <NUM>, the ICD obtains from the flight management system <NUM> or from a communications management unit (CMU) of the aircraft <NUM> an aircraft identification number <NUM>. The aircraft identification number <NUM> may be a tail number or aircraft ID, or other designated aircraft identification. In one embodiment of the present system and method, the aircraft identification number <NUM> may be stored in the persistent storage of the flight management systems <NUM>. In an alternative embodiment, the aircraft designation/ID <NUM> may be obtained manually by an aircraft captain or first officer, or aircraft maintenance personnel (for example, from an aircraft number painted on the exterior of the aircraft itself; or from a plaque in the cockpit with this information); further, the aircraft ID <NUM> may be manually entered into the ICD <NUM> (via keyboard, touch-screen interface, voice commands, or similar). The method proceeds with step <NUM>.

Validation of aircraft to receive updated data: In step <NUM>, and in one embodiment of the present system and method, the ICD <NUM> compares the aircraft identification number <NUM> for the aircraft <NUM> against the authorized aircraft list (AAL) <NUM>. The ICD <NUM> determines if the aircraft <NUM> is authorized to receive the updated aircraft database <NUM>.

In an alternative embodiment of the present system and method, the validation of the aircraft <NUM> is performed manually, by the aircraft captain, first officer, or maintenance person. The aircraft captain/maintenance person compares the aircraft ID against a list of authorized aircraft (which may be stored on the ICD <NUM>, or alternatively on another portable computing device, or even on a printed, hand-carried list). If the current aircraft <NUM> is manually confirmed by the aircraft captain/maintenance person, the same individual may initiate the upload of step <NUM> (immediately below).

Database upload: If in step <NUM> it is determined that the aircraft <NUM> is authorized to receive the updated database <NUM>, then in step <NUM> the ICD <NUM> uploads the updated database <NUM> for storage by the flight management system <NUM>. A copy <NUM> of the most recent database <NUM> is thereby stored in the flight management system <NUM>. The upload step <NUM> may also entail various data validations and integrity checks to ensure that the database was updated correctly. Step <NUM> then continues with step <NUM>.

In step <NUM>, the ICD <NUM> records the update event in a stored internal update log <NUM>, update record <NUM>, or update database <NUM> to identify that the aircraft's navigational database <NUM> was updated for the specific aircraft <NUM> identified by the tail number <NUM>.

Step <NUM> may they continue with step <NUM>.

Step <NUM> may occur immediately after step <NUM>. In an alternative embodiment step <NUM> may occur at sometime significantly later than step <NUM>, at a time when the ICD <NUM> is no longer connected with or communicated coupled with the flight management systems <NUM> (and possibly no longer even physically proximate to the airplane <NUM>). In some embodiments of the present system and method, step <NUM> may occur only after multiple different aircraft <NUM> have received updates of the NAVDB <NUM>.

In step <NUM>, the ICD <NUM> establishes a communications link with the license server <NUM>, and then sends a message to the license server <NUM> or uploads the data file, indicative that the aircraft database <NUM> was updated for the particular aircraft <NUM>.

Non-authorized aircraft: Returning to method step <NUM>, if it is determined that the aircraft tail number <NUM> does not match any tail number <NUM>. n of the AAL list <NUM>, the method proceeds with <NUM>. Step <NUM> may vary in different embodiments may according to various policy choices of the database vendor:.

In general, there are embodiments of the present system and method where the NAVDB <NUM> will always be loaded to the FMS <NUM>, but the NAVDB <NUM> may be locked until it is authorized. That way the NAVDB <NUM> is essentially "on deck", just requiring a quick license check. The detailed steps of such "on deck" approaches may vary in different embodiments.

Personal skills and relevant arts persons skilled in the relevant arts will appreciate that various additional steps may be taken, or alternative steps employed, and that the steps listed here are exemplary only. For example, in addition to uploading the updated NAVDB <NUM>, the ICD <NUM> may be employed to upload and/or download other data to or from the aircraft <NUM>, or to perform other status or communications checks pertinent to the aircraft <NUM>.

Repeated, successive updates due to (A) multiple aircraft and/or (B) the AIRIC cycle. Persons skilled in the relevant arts will appreciate the following points:.

That is, when the ICD <NUM> again communicates with the license server to obtain another database update as per step <NUM> discussed above, step <NUM> of a previous round of updates may be performed concurrently over the same data connection. Restated again: When the method <NUM> engages in step <NUM> to obtain a list of authorized aircraft <NUM> and updated database <NUM>, the method may also simultaneously perform step <NUM> so as to provide to the license server <NUM> confirmation and validation data for a prior round of updates.

In some embodiments of the present system and method, as described already above in this document, the ICD <NUM> may obtain an authorized aircraft list (AAL) <NUM> from the license server <NUM>; and the ICD <NUM> verify (or attempt to verify) that an aircraft <NUM> is eligible for the uploaded database <NUM> while the IDC <NUM> is locally, communicatively coupled with the flight management system (FMS) <NUM>.

In alternative embodiment, the ICD <NUM> may not have local storage for a list of authorized aircraft <NUM>. Instead, the ICD <NUM> may be carried to and connected to the airplane <NUM> by a aircraft captain (using an EFT <NUM>) who simply uploads the NAVDB <NUM> from the ICD <NUM> to the FMS <NUM>; or the ICD <NUM> may be a maintenance tablet <NUM> carried by a maintenance staff person to multiple airplanes <NUM>, for example according to a listing provided by the airline. In the latter case, the maintenance staff person again simply connects the ICD <NUM> to the FMS <NUM>, and uploads the updated NAVDB <NUM> without any validation involved. (Such embodiments skip the method steps <NUM> and <NUM> of exemplary method <NUM>, above.

However, in such embodiments, the ICD <NUM> still obtains from the aircraft <NUM> the aircraft identification number <NUM> (as per step <NUM> of exemplary method <NUM>). At some later time (and as per step <NUM>), the ICD <NUM> still connects with the data vendor license server (DVL server) <NUM>, and uploads to the DVL server <NUM> a transfer log <NUM> or transfer record <NUM>, indicative of the upload of the revised NAVDB <NUM> to the aircraft. The DVL server <NUM>, or associated servers and business systems, may then determine if the revised NAVDB <NUM> was uploaded to one or more unauthorized aircraft <NUM>. Upon such a determination, appropriate processing and business procedures are initiated by the DVL server (or associated business/financial systems) to reconcile financial and/or licensing disparities between the airline and the aircraft vendor.

Reference as already been made above to data encryption. For purposes of the present document, encrypting the NAVDB <NUM> is effectively equivalent to "locking" the database, so that while it may be stored on the FMS <NUM> it cannot be accessed. As already discussed above, in some embodiments the copy of the NAVDB update <NUM> stored on the ICD <NUM> may be encrypted. Encryption may serve to protect the database <NUM> from digital theft (due to hacking, or due to deliberate improper distribution to personnel with access to the ICD <NUM>). The encryption may be removed from the database <NUM> as copied to the FMS <NUM> during, or subsequent to, transfer of the NAVDB update <NUM> to the FMS <NUM>.

In an embodiment already discussed above, if an aircraft <NUM> is not authorized to receive the update, the ICD <NUM> may still proceed to upload the revised NAVDB <NUM> to the aircraft <NUM>; but with the NAVDB <NUM> having a built-in or associated software element to self-encrypt or otherwise block access to the database <NUM> (again, locking the database <NUM>) after a designated grace period. In this case, delayed authentication or database validation, and/or encryption/decryption, could be performed by a standing encryption/decryption application on the FMS <NUM> or the Aircraft Interface Device <NUM> of the aircraft, so the presence of the ICD <NUM> is not required for delayed validation.

In various embodiments, different types and levels of authentication schemes, and encryption/decryption schemes, may be employed according to methods generally known in the art. For example, in addition to the tail number/aircraft ID <NUM> (which is generally publicly known or available), each airplane <NUM> may have its own unique, private airplane identification and/or airplane password.

Asymmetric encryption methods may be employed, with the aircraft <NUM> and the ICD <NUM> each storing either the public keys or private keys (according to details of the encryption approach employed). This ensures that the signing process is tamperproof from the airline, while still allowing local or private authentication without access to the Internet. Local validation may also be facilitated by a local, virtual network (VNET) which locally links multiple ICDs <NUM> (EFBs <NUM> and/or maintenance tablets <NUM>). (The VNET is not illustrated in the figures. ) In such deployments, in an aviation context, the aircraft AID <NUM> serves as gateway to the ICDs <NUM> and/or VNET. The ICD(s) may store cached versions of the 'B' keys (obtained initially from the database vendor license server <NUM>), while each airplane <NUM> may store its own 'A' key on the AID <NUM> or other processing system.

While the present system and method has been disclosed herein in the context of a navigational database (NAVDB) <NUM>, the same methods may be applied to other aircraft databases <NUM> which may contain data or otherwise be pertinent to, or under some degree of authorization or control, of third-party resources or organizations. For example, various performance databases, such as those pertaining to aircraft drag, thrust, or fuel flow, may be uploaded and/or downloaded via the methods described herein, without requiring a direct internet connection.

The present system and method, then, can be used to more generally track which database(s) go on which aircraft. FMS-installed software applications and/or databases <NUM> may be controlled via various option codes which are updated via the ICDs <NUM> according to methods disclosed here, ensuring that airplanes employ on features or data for which they are licensed.

The present disclosure is directed towards systems and methods to employ a an ICD <NUM> to ensure that the correct and licensed third-party data <NUM> from remote servers <NUM> is routed to the correct airplanes, via cross-checking with the cloud-accessed servers, even though the airplanes <NUM> may not be connected with the cloud/internet <NUM> at the time of data downloads or uploads. The systems and methods of the present disclosure equally provide for convenient, reliable auditing/billing of data distribution to multiple aircraft.

Presented herein above, in various embodiments, are exemplary systems and methods directed towards achieving these objectives. Elements of different embodiments may be combined in various embodiments not specifically enumerated herein, and in some cases some elements may be omitted, within the scope of the appended claims. Alternative embodiments, examples, and modifications which would still be encompassed by the disclosure may be made by those skilled in the art, particularly in light of the foregoing teachings. Further, it should be understood that the terminology used to describe the disclosure is intended to be in the nature of words of description rather than of limitation.

Claim 1:
A method, comprising:
receiving at a hand-portable intermediary communications device (ICD) (<NUM>), from a remote database server (<NUM>), a flight-database (<NUM>) to be stored in a non-volatile storage (<NUM>) of the ICD (<NUM>);
establishing a local physical communicative coupling (<NUM>) between the ICD (<NUM>) and a flight transport vehicle (<NUM>);
obtaining at the ICD (<NUM>) from a flight management system (FMS) (<NUM>) of the flight transport vehicle (<NUM>) an identification number for the flight transport vehicle (<NUM>);
wherein when the flight transport vehicle (<NUM>) is not communicatively coupled with the database server (<NUM>), the ICD (<NUM>) is configured to: (i) upload the flight-database (<NUM>) for storage in the flight management system (<NUM>), and (ii) support a determination according to the identification number if the flight-transport vehicle (<NUM>) is authorized to receive the upload of the flight-database;
wherein upon a determination by the ICD (<NUM>) that the flight-transport vehicle (<NUM>) is not authorized to receive the upload, the method further comprises:
(i) storing in the FMS (<NUM>) an unlocked version of the flight-database (<NUM>),
(ii) recording in an update log of the ICD (<NUM>) an indication that the flight-transport vehicle (<NUM>) associated with the identification number was not authorized to receive the update; and
(iii) recording in the update log of the ICD (<NUM>) an indication that the flight-transport vehicle (<NUM>) received the unlocked version of the update.