Patent Description:
Large air-cargo operators are constrained by the limited time available to optimally plan and load air cargo. These operators have hundreds of aircrafts operating out of hub-and-spoke network airports where consignments are loaded onto or unloaded from aircrafts to be dispatched to their final destination. However, up until now cargo flight planning have used ground based simulation and modelling systems utilizing historical, predicted data for the calculations. Large air-cargo operators are faced with challenges such as lack of sufficient time for adequate load planning and execution, and lack of accurate information about dynamic parameters of en route aircrafts. The present disclosure is directed to overcoming one or more of these issues.

Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art, or suggestions of the prior art, by inclusion in this section.

<CIT> discloses a distributed system for flight and route management of one or more aircraft. <CIT> discloses systems and methods for handling luggage for an aircraft. <CIT> discloses systems and methods for processing aircraft flight information and flight plan information. <CIT> discloses a method for en-route flight path optimization.

According to certain aspects of the disclosure, systems and methods are disclosed to provide aircraft cargo planning using real-time aircraft intelligence through a Connected-FMS services as a Software as a Service (SaaS) platform.

The invention is defined by the independent claims, to which reference should now be made.

As described above, there has been consistent growth in air-traffic over the past several years. Large air-cargo operators are constrained by the limited time available to optimally plan and load air cargo. These operators have hundreds of aircrafts operating out of hub-and-spoke network airports where consignments are loaded onto or unloaded from aircrafts to be dispatched to their final destination. Conventional cargo flight planning techniques may only involve ground based simulation and modelling systems utilizing historical, predicted data for the calculations.

Some of the challenges faced by the air-freight industry currently include lack of time for adequate load planning and execution, and lack of accurate information about dynamic parameters of en-route aircrafts. Weight and balance of the cargo also are important factors in aircraft load planning as the weight and balance need to be calculated for each flight leg individually. Cargo flights often contain multiple legs and, after each leg, certain unit load devices (ULDs) might be loaded or unloaded while others continue onto the next flight leg. Rearranging the continuing ULDs between two flight legs might save fuel or allow the aircraft to load more weight. Inefficient center of gravity (CG) at takeoff due to sub-optimal placement of cargo containers in the cargo holds lead to increased fuel usage in subsequent legs of the flight. Thus, a need exists to implement a novel simulation engine that uses the power of connected APIs to get dynamic aircraft parameters in real time from each aircraft, and feed them to fleet aircraft operators so they can accurately and predictably plan cargo flights.

Accordingly, the following embodiments describe systems and methods for providing one or more fleet aircraft operators with access to dynamic parameters of en-route aircrafts. According to certain aspects of the present disclosure, real-time parameters may be received from aircrafts and the received parameters may be input into a simulation engine to optimally plan cargo load, cargo placement within the cargo hold, optimal center of gravity, and any other flight parameter adjustments. As described in further detail below, providing dynamic aircraft parameters in real time from any one of a plurality of aircrafts may result in improvement in refining cargo planning in various aspects. By allowing fleet aircraft operators to access dynamic parameters, the operators may be able to plan cargo more efficiently by utilizing data that is current, accurate, and predictable.

The subject matter of the present description will now be described more fully hereinafter with reference to the accompanying drawings, which form a part thereof, and which show, by way of illustration, specific exemplary embodiments. An embodiment or implementation described herein as "exemplary" is not to be construed as preferred or advantageous, for example, over other embodiments or implementations; rather, it is intended to reflect or indicate that the embodiment(s) is/are "example" embodiment(s). Subject matter can be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any exemplary embodiments set forth herein; exemplary embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software per se). The following detailed description is, therefore, not intended to be taken in a limiting sense.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter include combinations of exemplary embodiments in whole or in part.

The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section. Both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the features, as claimed.

In this disclosure, the term "based on" means "based at least in part on. " The singular forms "a," "an," and "the" include plural referents unless the context dictates otherwise. The term "exemplary" is used in the sense of "example" rather than "ideal. " The term "or" is meant to be inclusive and means either, any, several, or all of the listed items. The terms "comprises," "comprising," "includes," "including," or other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, or product that comprises a list of elements does not necessarily include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. Relative terms, such as, "substantially" and "generally," are used to indicate a possible variation of ±<NUM>% of a stated or understood value.

Referring now to the appended drawings, <FIG> shows an overview of an exemplary environment <NUM> according to one or more embodiments of the present disclosure. The environment <NUM> may, for example, include a plurality of aircrafts <NUM>, a connected FMS Cloud services platform <NUM>, a Ground Fleet Management services platform <NUM>, Air Cargo Operator IT systems <NUM>, third party data sources <NUM>, a Fleet Loader/Dispatcher <NUM>, and a simulation engine <NUM>. The connected FMS cloud services platform <NUM> may be a cloud-based platform that provides FMS services to any user who has authorized access to the platform, as described in further detail below.

As shown in <FIG>, each of the aircrafts <NUM> may also include an FMS API (flight management system application programming interface) <NUM> which may be comprised of an onboard FMS 161a, a cockpit gateway 161b, and an EFB/PED (electronic flight bag/personal electronic device) 161c. Onboard FMS 161a may be any specialized computer system physically installed in an aircraft (e.g., the cockpit), and may be programmed and/or customized to service the flight crew of the aircraft with in-flight tasks. A cockpit gateway 161b may be a device that integrates all sources of data (e.g., flight operation data, maintenance data) on an aircraft and sends the data to the appropriate operators of the aircraft at time intervals specified by the operators. As an example, the cockpit gateway 161b may host several services which enable the connectivity between the ground system and the FMS 161a. The services may be to query the onboard fuel quantity of an aircraft, to query the onboard weight of the aircraft, to query the predicted fuel level of the aircraft at landing, to query the predicted weight of the aircraft at landing, to query the fuel flow between the left and right fuel tanks of the aircraft, and to query the change in the center of gravity (CG) of the aircraft. An EFB/PED 161c may be a computer device carried by a pilot of a flight crew, which may store, for example, navigational charts, maps for air and ground operations of an aircraft, a flight plan management system, an aircraft operating manual, a flight-crew operating manual, software applications which automate flight-related or avionics-related computation tasks, and/or any application or data which may be installed in a computing platform. Each of the plurality of aircraft FMS API <NUM> may communicate with the air fleet management API of the connected FMS Cloud services platform <NUM> via communication link <NUM>.

The onboard FMS 161a, the cockpit gateway 161b, and the EFB/PED 161c may include one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with FMS services. For example, the onboard FMS 161a, the cockpit gateway 161b, or the EFB/PED 161c may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a computer (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer), a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device. The onboard FMS 161a, the cockpit gateway 161b, and the EFB/PED 161c may be in communication with one another via wired or wireless connections, or any other suitable means of communication protocol.

As further shown in <FIG>, the simulation engine <NUM> may be comprised of the fuel modeling engine <NUM>, the minimum equipment list (MEL) modeling engine <NUM>, the weight and center of gravity (CG) modeling engine <NUM>, and the flight optimizer engine <NUM>. The simulation engine <NUM> may be in communication with the connected FMS Cloud services platform <NUM>, the Ground Fleet Management services platform <NUM>, the Air Cargo Operator IT systems <NUM>, the third party data sources <NUM>, and Fleet Loader/Dispatcher <NUM> via the API MASHUP communication link <NUM>. The simulation engine <NUM> may be built in to the connected FMS Cloud services platform <NUM>, or may be implemented separately but connected to the connected FMS Cloud services platform <NUM> via an air fleet management API communications link <NUM>.

In one embodiment, the operation of the simulation engine <NUM> in the environment <NUM> may be as follows. Aircraft <NUM> may communicate information such as the tail number of the aircraft and flight data to the connected FMS Cloud services platform <NUM> via the aircraft FMS API <NUM> using communication link <NUM>. Communication link <NUM> may be digital communication mechanism or any existing data-link or radio mechanism. Flight data from the aircraft may include the predicted fuel available in the aircraft when it lands, the predicted weight of the aircraft when it lands, any jettison or anomalous fuel quantity which would affect the predicted fuel level and the weight of the aircraft, the fuel flow data between the left and right pumps as desired by the crew, the predicted estimated time of arrival (ETA) of the aircraft at a stopover airport, any unplanned diversion from original flight path by the crew due to weather, traffic or other issues, and any minimum equipment list (MEL) constraints developed by the en-route aircraft. The flight data may be transmitted automatically by the aircraft FMS API <NUM> without aircraft crew intervention, or it may be transmitted by request from the aircraft crew. In the embodiment where the simulation engine <NUM> is built in to the connected FMS Cloud services platform <NUM>, the flight data may be transmitted directly to the simulation engine <NUM>. In the embodiment where the simulation engine <NUM> is separate from the connect FMS Cloud services platform <NUM>, the flight data may be transmitted to the simulation engine <NUM> via the air fleet management API communications link <NUM>.

The simulation engine <NUM> may also receive planning data from Ground Fleet Management services platform <NUM>, the Air Cargo Operator IT system <NUM>, the third party data sources <NUM>, and Fleet Loader/Dispatcher <NUM>. The simulation engine <NUM> may then perform simulations based on all the data received using one or more of the fuel modeling engine <NUM>, the MEL modeling engine <NUM>, the Weight and CG modeling engine <NUM>, and the flight optimizer engine <NUM>. As an example, the fuel modeling engine <NUM> using all of the received data may predict the fuel at landing at the next destination based on the current fuel consumption, flight path deviations due to traffic or weather, holding and taxing time at the destination. The model may also include the flight performance degradation due to mechanical failures to predict fuel that would be available when the aircraft lands. As another example, the weight and CG modeling engine <NUM> using all of the received data may simulate different placements of cargo within the cargo hold and the resultant impact on fuel weight and fuel usage. This simulation would change dynamically due to fuel burn along the flight. Therefore this simulation may be performed once for the whole flight path or multiple times during the flight path, depending on the requirements of the fleet operator. As another example, the MEL modeling engine <NUM> using all of the received data may predict any minimum equipment level constraints developed by the en-route aircraft. For example, one or more pieces of equipment may fail during the flight, and the MEL modeling engine <NUM> may perform simulations based on operational states of the equipment. In another example, the flight optimizer engine <NUM> using all of the received data may perform simulations to optimize flight. The result of the optimized flight could be in the form of speed or time constraints. The simulation may decide if the aircraft needs to speed up to meet time constraints or slow down and save fuel while accounting for ground cargo handling needs comprising shipment arrival delay, departing flight delay, high cost of missing cargo deadlines like overnight shipping, etc.. If the simulation results in any modification in flight parameters, then a notification may be sent to the aircraft crew via communication link <NUM> to the FMS API <NUM> to make appropriate changes to the flight parameters.

In practice, there may be additional devices, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in <FIG>. Furthermore, two or more devices shown in <FIG> (e.g., EFB/PED 161c and cockpit gateway 161b) may be implemented within a single device, or a single device shown in <FIG> (e.g., EFB/PED 161c, onboard FMS 161a, cockpit gateway 161b) may be implemented as multiple, distributed devices.

<FIG> depicts a close up overview of an exemplary environment of interconnections between the Connected FMS Cargo and Fuel Services system with aircraft onboard FMS and Airline Operation Control (AOC) Center Systems, according to one aspect of the present disclosure. As shown in <FIG>, environment <NUM> may include a cloud <NUM>, airline operation control (AOC) center systems <NUM>, and aircraft operators <NUM>. The cloud <NUM> interfaces with the aircraft operators <NUM> via the communication channel <NUM>. The cloud <NUM> interfaces with the AOC center system <NUM> via the communication channel <NUM>.

The cloud <NUM> may be comprised of FMS digital twins <NUM> and a simulation engine <NUM>. The FMS digital twins <NUM> may include a plurality of off board FMS clones <NUM>. The simulation engine <NUM> may comprise a weather model <NUM>, a traffic model <NUM>, a performance model <NUM>, an airport model <NUM>, a fuel model <NUM>, a Minimum Equipment List (MEL) model <NUM>, a weight and CG model <NUM>, and a flight optimizer model <NUM>. Furthermore, the AOC center systems <NUM> may comprise an FMS simulation model <NUM>, a performance model <NUM>, a weather model <NUM>, a cargo weight database <NUM>, a passenger weight database <NUM>, and a fuel data database <NUM>. The aircraft operators <NUM> may comprise a plurality of aircrafts <NUM>, and each aircraft <NUM> may contain an onboard FMS <NUM>.

In some implementations, the cloud <NUM> may correspond to the connected FMS cloud services platform <NUM> and simulation engine <NUM> depicted in <FIG>. In some implementations, the simulation engine <NUM> may correspond to the simulation engine <NUM> depicted in <FIG>. In the embodiment shown in <FIG>, the simulation engine <NUM> is built into cloud <NUM>, and the simulation engine <NUM> may include other simulation models than those depicted in <FIG>.

As further shown in <FIG>, an exemplary operation of environment <NUM> will be discussed herein. The AOC center systems <NUM> may contain data relevant to cargo planning, for example data related to cargo weight, passenger weight, and fuel data. As depicted in <FIG>, the AOC center systems <NUM> may perform its own simulation using the FMS simulation <NUM>, performance model <NUM>, and weather model <NUM>. However in other embodiments, the AOC center systems <NUM> may not have the simulation models and rely solely on the simulation engine <NUM>. AOC center systems <NUM> may then transmit the cargo planning data to the cloud <NUM> via communication channel <NUM>. At cloud <NUM>, the cargo planning data may be entered into the simulation model <NUM> to perform one or more simulations using the weather model <NUM>, traffic model <NUM>, performance model <NUM>, airport model <NUM>, fuel model <NUM>, MEL model <NUM>, weight and CG model <NUM>, and flight optimizer model <NUM>. In one embodiment, once the simulations are complete, any modification in flight parameters may be sent to the one or more off-board FMS clones <NUM>. The one or more off-board FMS clones <NUM> may then synchronize the modification in flight parameters via communication channel <NUM> with the onboard FMS <NUM> of an en-route aircraft <NUM>. In another embodiment, once the simulations are complete, any modification in flight parameters may be sent to the onboard FMS <NUM> of an en-route aircraft <NUM> via communications channel <NUM>, bypassing the one or more off-board FMS clones <NUM>.

The number and arrangement of modules, devices, and networks shown in <FIG> are provided as an example. In practice, there may be additional modules and devices, fewer modules, devices and/or networks, different modules, devices and/or networks, or differently arranged modules, devices and/or networks than those shown in <FIG>. Furthermore, two or more devices included in environment <NUM> of <FIG> may be implemented within a single device, or a single device in the environment <NUM> of <FIG> may be implemented as multiple, distributed devices.

<FIG> depicts an exemplary component diagram comprising various components utilized by any one of a plurality of modeling engines disclosed in <FIG> and <FIG>. The component diagram <NUM> may include a trajectory builder <NUM>, integrators <NUM>, an aero engine database <NUM>, and a rules database <NUM>.

The functions of the components in the diagram <NUM> will be discussed herein with respect to the modeling engines as depicted in <FIG> and <FIG>. For example the fuel modeling engine <NUM>, MEL modeling engine <NUM>, weight and CG modeling engine <NUM>, flight optimizer engine <NUM>, the fuel model <NUM>, MEL model <NUM>, weight and CG model <NUM>, and flight optimizer model <NUM> may all incorporate the components of diagram <NUM> to perform the respective simulations.

The MEL modeling engine <NUM> may receive a minimum equipment list (MEL) for an aircraft and then convert the list into rules that are added to the rules database <NUM>. The trajectory builder <NUM> may utilize the rules in the rules database <NUM> as constraints and generate a trajectory of the aircraft. For example, the MEL list may include the following condition: inactive icing pack, operable altitude restricted to <NUM> feet. Based on this condition, the MEL modeling engine <NUM> may create a rule that states: activate altitude constraint rule with value <=<NUM> with the applicability to all flight phases. The trajectory builder <NUM>, while generating a trajectory, may check the rule database <NUM> and see the activate altitude constraint rule with a value of <=<NUM> feet and may not generate a vertical profile that exceeds the altitude of <NUM> feet.

The fuel modeling engine <NUM>, weight and CG modeling engine <NUM>, and flight optimizer engine <NUM> may all use aircraft state data supplied by the onboard FMS 161a of the aircraft <NUM>. The component that computes data required for fuel model, weight and CG model, and flight optimization may be the integrators <NUM>. The integrators <NUM> may be used to advance aircraft state along a lateral flight plan to compute the vertical profile. Integrators <NUM> may use the aero engine database <NUM> provided by aircraft manufactures to compute parameters like aircraft drag, fuel flow, thrust setting parameters (TSP) and optimum speeds. The integrators <NUM> may use the equations of motion for an aircraft with the assumption that said aircraft is a point mass. Integrators <NUM> may set the data defining aircraft performance for the start point of the integration segment (point A), then evaluate aircraft's equation of motion to advance predicted aircraft state to the end point (point B) of the integration segment. The data that is used (i.e., input) for this computation may include, altitude, distance to destination, flight phase, ground speed, gross weight, temperature deviation, true air speed, and time in seconds. The data that is computed based on the input data may include mach speed, temperature ratio, pressure ratio, acceleration, flight path angle, drag, fuel flow, engine thrust, vertical speed, and integration segment length, etc. Elapsed time for a segment may be calculated by ground speed, and distance may be used to calculate time taken for a segment. Fuel flow may be computed by referencing aircraft manufacturer provided aero engine database <NUM> with input parameters such as pressure altitude, mach number, calibrated airspeed, temperature and pressure ratio. Once fuel flow is calculated, the calculated fuel flow may be used to compute the gross weight of the aircraft at point B.

The flight optimizer engine <NUM> may use the trajectory builder <NUM> to determine fuel usage at each candidate altitude in cruise phase. The trajectory builder <NUM> may use wind information at each candidate altitude to get accurate fuel data. The candidate altitude with least fuel usage may be provided as a recommended altitude for fuel savings. The weight and CG modeling engine <NUM> may use a standard model to calculate the center of gravity of the aircraft. Inputs for the calculation may be received from the onboard FMS 161a and may include at least the amount of fuel left in each tank, leading to accurate center of gravity computation based on the payload and how it is distributed in the cargo load area.

The operations of the component diagram <NUM> and the fuel modeling engine <NUM>, MEL modeling engine <NUM>, weight and CG modeling engine <NUM>, and flight optimizer engine <NUM> described above are examples and not to be construed as limiting. The component diagram <NUM> may include more components or less components, or components arranged in a different sequence. The various modeling engines may utilize the component diagram <NUM> as described or may be programmed to utilize different components or functions.

<FIG> depicts a flowchart of an exemplary method <NUM> for integrating real-time aircraft intelligence for cargo planning.

First, the exemplary method <NUM> may begin with receiving, using the FMS API <NUM> onboard aircraft <NUM>, real-time flight data (Step <NUM>). The real-time flight data may comprise at least one of the predicted fuel available in the aircraft when the aircraft lands, the predicted weight of the aircraft when the aircraft lands, any jettison or anomalous fuel quantity which would affect the predicted fuel level and the weight of the aircraft, the fuel flow data between the left and right pumps as desired by the crew, the predicted estimated time of arrival (ETA) of the aircraft at a stopover airport, any unplanned diversion from original flight path by the crew due to weather, traffic or other issues, and any minimum equipment list (MEL) constraints developed by the en-route aircraft.

The exemplary method <NUM> of <FIG> may then receive, from the third party data sources <NUM>, real-time weather and/or traffic data for the flight path of the aircraft (step <NUM>). Furthermore, real-time planning data may be received from at least one of Ground Fleet Management services platform <NUM>, the Air Cargo Operator IT systems <NUM>, and Fleet Loader/Dispatcher <NUM> (step <NUM>). The data received in steps <NUM>, <NUM>, and <NUM> may then be input into the simulation engine <NUM> to calculate any flight modification parameters (step <NUM>). Once the simulation is completed, then the exemplary method <NUM> may proceed to step <NUM> where any flight modification parameters may be transmitted to the aircraft crew via communication link <NUM> to the FMS API <NUM> where appropriate flight changes may be made to the en-route aircraft <NUM>.

Although <FIG> shows exemplary blocks, in some implementations, process <NUM> may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in <FIG>.

<FIG> depicts an environment <NUM> that displays an exemplary operation of the cargo planning system by the fleet aircraft operator.

In one embodiment, environment <NUM> may include an airport operations team <NUM>, a cargo sales team <NUM>, a cargo loaders team <NUM>, an airline modeling and simulation team <NUM>, an airline cargo planning system <NUM>, and a connected FMS cargo and fuel services <NUM>. In some implementations, the connected FMS cargo and fuel services <NUM> may correspond to the Connected FMS cloud services platform <NUM> and simulation engine <NUM> depicted in <FIG>. In other implementations, the connected FMS cargo and fuel services <NUM> may correspond to the cloud <NUM> depicted in <FIG>.

In the exemplary environment <NUM>, the fleet aircraft operator may have various teams examine different data for different aircrafts in the fleet. For example, the airport operations team <NUM> may be able to view via the operations dashboard that <NUM> pounds of additional weight and <NUM> pounds of additional fuel are required to be loaded on flight BA753 at Phoenix Sky Harbor international Airport (KPHX). The cargo sales team <NUM> may able to view via the sales dashboard that the current weight of cargo for flight BW373 is <NUM> pounds and current fuel for flight BW373 is <NUM> gallons. When the flight is expected to land at KPHX, the aircraft is expected to have <NUM> gallons of fuel left with a <NUM>% of variance in landing fuel. The cargo loaders team <NUM> may be able to view, via the loading dashboard that for flight GF673, there are <NUM> pounds of fuel in the left fuel tank and <NUM> pounds of fuel in the right fuel tank. The weight and balance at three points throughout the aircraft is <NUM> pounds, <NUM> pounds, and <NUM> pounds respectively. The data obtained by the airport operations team <NUM>, the cargo sales team <NUM>, and the cargo loaders team <NUM>, may be submitted to the connected FMS cargo and fuel services <NUM>, thereby enabling the airlines modeling and simulation team <NUM> to perform simulations to more efficiently plan cargo loading. For example, the following simulations can be performed by the airline modeling and simulation team <NUM>: (<NUM>). determine how much weight can be taken in Phoenix to Los Angles (KLAX) flight route at flight level <NUM>; (<NUM>). determine how much fuel has to be passed from left to right tanks for the KDVT to KFLG flight route; and (<NUM>). which section of cargo can be loaded or unloaded for <NUM> pounds without affecting the center of gravity of the aircraft. Once the simulations are completed, any flight modification parameters may then be transmitted to the airline cargo planning system <NUM> for the fleet aircraft operators.

Although <FIG> shows examples of fleet aircraft operator teams and the data and simulations available to the teams, in some implementations, environment <NUM> may have additional fleet aircraft operator teams, fewer fleet aircraft operator teams, different fleet aircraft operator teams, additional data and simulations, fewer data and simulations, or different data and simulations.

<FIG> depicts one of a plurality of exemplary user interfaces that may be used by the fleet aircraft operators or airline personnel to utilize the techniques disclosed herein. User interface <NUM> may include a date selector <NUM>, a time selector <NUM>, a flight selector <NUM>, query buttons <NUM>, <NUM>, <NUM>, and <NUM>, cargo placement icon <NUM>, fuel burn prediction icon <NUM>, a next flight indicator section <NUM>, an offset expected icon <NUM>, and a weather deviation icon <NUM>.

According to <FIG>, a fleet aircraft operator or airline personnel may select a data range using the data selector <NUM>, a time range using the time selector <NUM>, and one or multiple specific flights using the flight selector <NUM>. Then the operator or personnel may select cargo placement icon <NUM> to view or input the current cargo loaded in the aircraft, select the fuel burn prediction icon <NUM> to view or input the fuel usage prediction of the aircraft, select the offset expected icon <NUM> to view or input any diversion from the aircraft's original flight path, and/or select the weather deviation icon <NUM> to view or input any dynamic weather issues that could affect the aircraft's flight path.

Then the fleet aircraft operator or airline personnel may select any one of the query buttons <NUM>, <NUM>, and <NUM> depending on the information that is needed. For example, if the operator or personnel wants to know how much fuel is need for the next flight, the operator or personnel may select the query button <NUM>. If the operator or personnel wants to know how much cargo can be loaded for the next flight, the operator or personnel may select the query button <NUM>. If the operator or personnel wants to know how much fuel would be used when the aircraft is reaching destination, the operator or personnel may select the query button <NUM>. After selecting one or a combination of the query buttons, the operator or personnel may then select the query button <NUM> to fetch the answers for each of the queries and the answers would be displayed in the next flight indicator section <NUM>. For example, given the parameters selected by the operator or personnel, the fuel required for the aircraft for next flight is 600lbs and the cargo that can be planned for the aircraft is 300lbs.

Although <FIG> shows an exemplary user interface, in some implementations, interface <NUM> may include additional user interface elements, fewer user interface elements, different user interface elements, or differently arranged user interface elements than those depicted in <FIG>.

<FIG> depicts a high-level functional block diagram of an exemplary computer device or system, in which embodiments of the present disclosure, or portions thereof, may be implemented, e.g., as computer-readable code. In some implementations, the onboard FMS <NUM>, the EFB 161c (depicted in <FIG>) may be consistent with or similar to device <NUM>. Additionally, or alternatively, the AOC center systems <NUM>, the cloud <NUM> may each be consistent with or similar to device <NUM>. Additionally, each of the exemplary computer servers, databases, user interfaces, modules, and methods described above with respect to <FIG> may be implemented in device <NUM> using hardware, software, firmware, tangible computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination of such may implement each of the exemplary systems, user interfaces, and methods described above with respect to <FIG>.

If programmable logic is used, such logic may be executed on a commercially available processing platform or a special purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.

For instance, at least one processor device and a memory may be used to implement the above-described embodiments. A processor device may be a single processor or a plurality of processors, or combinations thereof. Processor devices may have one or more processor "cores.

Various embodiments of the present disclosure, as described above in the examples of <FIG>, may be implemented using device <NUM>. After reading this description, it will become apparent to a person skilled in the relevant art how to implement embodiments of the present disclosure using other computer systems and/or computer architectures. Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

As shown in <FIG>, device <NUM> may include a central processing unit (CPU) <NUM>. CPU <NUM> may be any type of processor device including, for example, any type of microprocessor device. As will be appreciated by persons skilled in the relevant art, CPU <NUM> also may be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. CPU <NUM> may be connected to a data communication infrastructure <NUM>, for example, a bus, message queue, network, or multi-core message-passing scheme.

Device <NUM> also may include a main memory <NUM>, for example, random access memory (RAM), and also may include a secondary memory <NUM>. Secondary memory <NUM>, e.g., a read-only memory (ROM), may be, for example, a hard disk drive or a removable storage drive. Such a removable storage drive may comprise, for example, a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive in this example reads from and/or writes to a removable storage unit in a well-known manner. The removable storage unit may comprise a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by the removable storage drive. As will be appreciated by persons skilled in the relevant art, such a removable storage unit generally includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory <NUM> may include other similar means for allowing computer programs or other instructions to be loaded into device <NUM>. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units and interfaces, which allow software and data to be transferred from a removable storage unit to device <NUM>.

Device <NUM> also may include a communications interface ("COM") <NUM>. Communications interface <NUM> allows software and data to be transferred between device <NUM> and external devices. Communications interface <NUM> may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface <NUM> may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface <NUM>. These signals may be provided to communications interface <NUM> via a communications path of device <NUM>, which may be implemented using, for example, wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.

The hardware elements, operating systems and programming languages of such equipment are conventional in nature, and it is presumed that those skilled in the art are adequately familiar therewith. Device <NUM> also may include input and output ports <NUM> to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. Of course, the various server functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the servers may be implemented by appropriate programming of one computer hardware platform.

The systems, apparatuses, devices, and methods disclosed herein are described in detail by way of examples and with reference to the figures. The examples discussed herein are examples only and are provided to assist in the explanation of the apparatuses, devices, systems, and methods described herein. None of the features or components shown in the drawings or discussed below should be taken as mandatory for any specific implementation of any of these the apparatuses, devices, systems, or methods unless specifically designated as mandatory. For ease of reading and clarity, certain components, modules, or methods may be described solely in connection with a specific figure. In this disclosure, any identification of specific techniques, arrangements, etc. are either related to a specific example presented or are merely a general description of such a technique, arrangement, etc. Identifications of specific details or examples are not intended to be, and should not be, construed as mandatory or limiting unless specifically designated as such. Any failure to specifically describe a combination or sub-combination of components should not be understood as an indication that any combination or sub-combination is not possible. It will be appreciated that modifications to disclosed and described examples, arrangements, configurations, components, elements, apparatuses, devices, systems, methods, etc. can be made and may be desired for a specific application. Also, for any methods described, regardless of whether the method is described in conjunction with a flow diagram, it should be understood that unless otherwise specified or required by context, any explicit or implicit ordering of steps performed in the execution of a method does not imply that those steps must be performed in the order presented but instead may be performed in a different order or in parallel.

Claim 1:
A computer-implemented method for fleet based aircraft cargo flight planning, the method comprising:
receiving, by a processor, real-time flight data associated with at least one flight parameters of an aircraft (<NUM>, <NUM>), wherein the real-time flight data comprise at least one of an onboard aircraft (<NUM>, <NUM>) fuel quantity, an onboard aircraft (<NUM>, <NUM>) weight, a predicted aircraft (<NUM>, <NUM>) fuel level at landing, a predicted aircraft (<NUM>, <NUM>) weight at landing, an aircraft (<NUM>, <NUM>) fuel flow status, and a change in aircraft (<NUM>, <NUM>) center of gravity;
receiving, by the processor, real-time weather data along a flight path of the aircraft (<NUM>, <NUM>);
receiving, by the processor, real-time planning data of the aircraft (<NUM>, <NUM>), wherein the real-time planning data comprise at least one of a traffic diversion status, minimum equipment list constraints, a cargo weight, and an estimate time of arrival of the aircraft (<NUM>, <NUM>) at a stopover airport;
calculating, by a simulation engine (<NUM>, <NUM>) executed by the processor, flight modification parameters using the real-time flight data, the real-time weather data, and the real-time planning data, wherein the flight modification parameters comprise at least one of an increase in speed and a decrease in speed, and wherein calculating the flight modification parameters comprises accounting for ground cargo handling needs, wherein the ground cargo handling needs comprise shipment arrival delay, departing flight delay or high cost of missing cargo deadlines; and
transmitting, by the processor, the flight modification parameters to a flight management system, FMS, of the aircraft (<NUM>, <NUM>), wherein the at least one flight parameters of the aircraft (<NUM>, <NUM>) is adjusted based on the flight modification parameters such that the aircraft increases in speed or decreases in speed to account for the ground cargo handling needs.