DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/11/2025 has been entered.
Response to Arguments
Applicant’s arguments, see Pgs. 8-9, filed 11/11/2025, with respect to the 35 USC 112(b) rejection of claims 1-12 have been fully considered and are persuasive.
The Examiner is in agreement that the amendments to claims 1-12 correct the previously-raised indefiniteness concerns. Accordingly, the 35 USC 112(b) rejection of claims 1-12 has been withdrawn.
Applicant’s arguments, see Pgs. 9-13, filed 11/11/2025, with respect to the 35 USC 103 rejection of independent claims 1, 13, and 18 and their respective dependent claims have been fully considered and are partially persuasive.
Regarding independent claims 1, 13, and 18, Applicant argues that Duda and White fail to teach or suggest “a simulation network exterior to the aircraft… [and] an aircraft network… being separate from the simulation network, the aircraft network including at least one of sensors, actuators, control devices, or line replaceable units located within the aircraft”. The Examiner is in agreement with Applicant’s argument, as while Duda does provide a simulation network (i.e., core platform 102; see at least [0084] and [0097]), this simulation network is known to be located within the aircraft rather than being external to the aircraft (See at least [0008]-[0010], [0078]-[0080], and FIG. 1c), as discussed during the 10/22/2025 interview. The Examiner respectfully asserts, however, that Duda does teach that the aircraft network includes “at least one of sensors, actuators, control devices, or line replaceable units located within the aircraft” in at least [0081], which discusses the aircraft network (i.e., flight control system 116) incorporating data from perception system 106 and its capability to direct another subsystem (e.g., an actuation system) to operate in a manner to maintain aircraft stability.
Accordingly, the 35 USC 103 rejection of independent claims 1, 13, and 18 and their respective dependent claims has been withdrawn. However, upon further search and consideration, a new ground(s) of rejection is made in view of Duda, White, and Letsu-Dake.
Claim Objections
Claims 2 and 11 are objected to because of the following informalities:
In claim 2, “via the one or more processor” should be “via the one or more processors”
In claim 11, “via the one or more processor” should be “via the one or more processors”
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 5, 13-16, and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda et al. (US 2017/0277185 A1), hereinafter Duda, in view of White et al. (US 2003/0023740 A1), hereinafter White, and in further view of Letsu-Dake et al. (US 2019/0130767 A1), hereinafter Letsu-Dake.
Regarding claim 1, Duda teaches an aircraft network environment for an aircraft, the aircraft network environment comprising:
a simulation network… including a virtual aircraft integration system (VAIS) configured to perform a real-time simulation of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
an aircraft network of the aircraft,
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
the aircraft network being in communication with the simulation network and being separate from the simulation network,
Duda teaches ([0078]): "As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces..." Duda further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda even further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102." The Examiner has interpreted the aircraft network (i.e., flight control system 116) as being separate from the simulation network (i.e., core platform 102), as each are considered by Duda to be distinct subsystems which communicate with one another through software and/or hardware interfaces.
the aircraft network including at least one of sensors, actuators, control devices, or line replaceable units located within the aircraft;
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
communication networks;
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156."
and a configurable status console implemented within a computer system having one or more processors,
Duda teaches ([0104]): "The HMI system 104 provides a control and communication interface for the pilot (e.g., a human pilot, whether on-board or remote). The HMI system 104 is configurable to operate as a flight plan manager that enables the pilot to direct the aircrew automation system 100. The HMI system 104 can combine elements of glass cockpits, unmanned aerial vehicle (“UAV”) ground stations, and electronic flight bags (EFB) to enable effective, efficient and latency-tolerant communication between the pilot and aircrew automation system 100... The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof." One of ordinary skill in the art would recognize tablet computers, laptop computers, and/or smartphones as having one or more processors.
the configurable status console being communicatively coupled with the simulation network and the aircraft network via the communication networks,
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102."
the configurable status console, via the one or more processors, is configured to: perform an on-going scanning operation of the aircraft network and the simulation network;
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
and retrieve messaging data in real-time from the aircraft network,
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies..." Duda further teaches ([0117]): "The flight situation data perceived by the perception system 106 may be encoded and provided to the core platform 102 in real-time." Duda even further teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116." Duda still further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156."
the simulation data and the messaging data collectively including performance data and VAIS parameters;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
determine, using the simulation data and the messaging data, an overall health of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... a list of health hazards may be provide, along with one or corresponding icons to indicated one or more operational conditions that are out of range. For example, a low fuel indicator may be provided alongside a low fuel icon if fuel is low."
using status logic, determine an expected data value of the simulation data and the messaging data,
Duda teaches ([0096]): "The aircraft data structure 208 can be populated and adjusted to a specific aircraft during a knowledge acquisition phase (e.g., during initial setup) such that it contains all the information necessary to operate the aircraft. For example, when transitioning to a new aircraft, the knowledge acquisition system 114 may perform predefined activities in order to determine the layout (e.g., of the controllers/read outs, such as the cockpit instruments), performance parameters, and other characteristics of the aircraft. The predefined activities may include, for example: ... (2) procedure codification, which informs aircrew automation system 100 how to operate aircraft in normal and non-normal situations, further including the codification of checklists; (3) an aerodynamic model, which informs the aircrew automation system 100 how to fly the aircraft and what performance to expect for which aircraft configurations..." Duda further teaches ([0100]): "The anomaly detection application 218 employs machine learning techniques to monitor aircraft state, cluster, and classify sensor inputs in order to detect the presence of non-normal situations, and to identify whether a contingency has occurred. The anomaly detection application 218 is configured to compare the sensed states against a set of thresholds defined in the operational documentation for the specific aircraft (e.g., never exceed a predetermined airspeed, engine temperature, etc.)."
and evaluate the simulation data and the messaging data in relation to the expected data value to determine a configured status of at least one of an aircraft system of the aircraft, a component of the aircraft, or a simulation of the aircraft;
Duda teaches ([0101]): "In case of a contingency condition, a contingency operation application 220 executes the necessary predetermined checklists, procedures, and actions specified by the contingency application 220 in order to maintain safe operation of the aircraft or safely divert the flight. Notably, if a departure from expected performance is observed, the pilot can be alerted to a non-normal condition, thereby mitigating or avoiding potential mistakes... If an anomaly is detected, the contingency operation application 220 informs and interacts with the pilot via the HMI system 104 and ultimately executes the necessary procedure(s) to respond to the anomaly. Finally, the ISR application 222 and other flight plan-specific activity applications 224 may provide instructions, algorithms, or information to carry out operations relevant to a mission." Duda further teaches ([0155]): "After a period of time, the aircrew automation system 100 may detect that given the climb, the indicated airspeed is slowly deviating from its modeled airspeed for these pitch and power settings, indicating lower than expected values. This is an indication that the pitot heater has failed and the pitot tubes have iced up." Duda even further teaches ([0156]): "The aircrew automation system 100, however, recognizes that the airspeed data is anomalous to the rest of the flight data and its internal flight dynamics model, and aurally warns the pilot “airspeed indicator fault.”" Duda still further teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent."
and display the configured status at the configurable status console.
Duda teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent." Duda further teaches ([0035]): "In certain aspects, the human machine interface is configured to display a plurality of tasks on the touch screen display in a form of a task list. In certain aspects, each of the plurality of tasks is marked as either completed or not completed, for example, based at least in part on a pilot input via a touch screen display." Duda even further teaches ([0036]): "In certain aspects, the human machine interface is configured to display at least one of checklists, health alerts, predictions of aircraft state, and failure prognosis."
However, while Duda does teach retrieving simulation data from the simulation network (see at least [0084] and [0097]), Duda does not outright teach retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. White teaches a flight management system, comprising:
retrieve, via the communication networks, simulation data in real- time from the simulation network every 500 milliseconds or less,
White teaches ([0063]): "A simulation frame represents all the data transmitted/received within the base rate of time for the FMS computer. A "snapshot" of the data on the busses is typically taken at the beginning of the simulation frame and all the data processed by the FMS computer during the simulation frame are based on that snapshot." White further teaches ([0064]): "It should be noted that, depending on the size of the message buffer, the data transmitted on completion of a simulation frame may require more than one message buffer. It should be further noted that the frame rate for XSIM and the FMS computer need not be the same: the rate of the FMS computer might be, for example, 25 milliseconds for the simulation of one particular type of aircraft, but may be 30 milliseconds for another simulation. Other data may be required at twice the above-listed rates and may be spread over several 25 or 30 millisecond frames for performance reasons."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda to incorporate the teachings of White to provide retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. Duda and White are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of White, as doing so beneficially allows for retrieving data in real-time from the simulation network at rates as low as 25 milliseconds while allowing for data to be retrieved at rates of up to 60 milliseconds or over several 25-30 millisecond frames for performance reasons, as recognized by White ([0064]).
However, neither Duda nor White outright teach that the simulation network is exterior to the aircraft. Letsu-Dake teaches a system and method for enhancing the interactive transmission and visualization of flight data in real-time, comprising:
a simulation network exterior to the aircraft…
Letsu-Dake teaches ([0024]): "As such, in response to the vehicle data transmitted from the flight deck 106, the flight simulator 122 is enabled to receive and replicate, in real-time, the transmitted data associated with the automatic or manual response input activated at the flight deck 106. As such, the flight simulator 108 is enabled to replicate, in real-time, the functions that are currently presented at the flight deck 106. Consequently, the flight simulator 108 can implement suitable control functions that will enable the ground-based CSS 124 to navigate (e.g., utilizing rewind, forward, live controls) through the vehicle data received and thus more efficiently and effectively utilize the data to diagnose and resolve the avionics system's problem or failure involved." While the above citation makes reference to "the flight simulator 108", the Examiner notes that the reference character 108 is used elsewhere to refer to an aircraft standard communication bus (ASCB) 108 (see at least [0016] and FIG. 1) which is not described as being a flight simulator. As such, the use of reference character 108 in reference to the flight simulator appears to be erroneous. Therefore, the Examiner has interpreted "the flight simulator 108" as "the flight simulator 122".
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda and White to incorporate the teachings of Letsu-Dake to provide that the simulation network is exterior to the aircraft. Duda, White, and Letsu-Dake are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to implement the remote simulation network of Letsu-Dake, as the transmission of real-time flight data from the aircraft to the ground-based simulation network advantageously enables personnel to navigate the received data and more efficiently and effectively use the data to diagnose and resolve problems or failures in the aircraft's avionics system, as recognized by Letsu-Dake ([0024]). This ultimately serves to enhance the accuracy of diagnoses, as recognized by Letsu-Dake (see at least [0006]).
Regarding claim 2, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. Duda further teaches:
the configurable status console via the one or more processor, is further configured to continuously retrieve the performance data, the VAIS parameters and the messaging data in real-time from the aircraft network and the simulation network, to determine the health of the aircraft.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
Regarding claim 3, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. Duda further teaches:
the messaging data includes aircraft-configured message information.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies..." Duda further teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. "
Regarding claim 5, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. Duda further teaches:
the configurable status console is in wireless communication with the aircraft network and the simulation network.
Duda teaches ([0078]): "To share the duties and workload related to the execution of flight activities, the aircrew automation system 100 should be capable of executing the actions a pilot would perform routinely over the duration of a flight, regardless of the aircraft make, model, or type. An example system architecture for an aircrew automation system 100 in accordance with one aspect is shown in FIGS. 1a through 1c. As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces 156 using wired and/or wireless communication protocols and hardware. FIG. 1b illustrates an example flow of information (e.g., data) between the various subsystems." FIG. 1b, included below, depicts the connections between these subsystems. Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts." Duda even further teaches ([0117]): "The flight situation data perceived by the perception system 106 may be encoded and provided to the core platform 102 in real-time."
PNG
media_image1.png
646
837
media_image1.png
Greyscale
Regarding claim 13, Duda teaches a method of determining a configured status of at least one of an aircraft system of an aircraft, a component of the aircraft, or a simulation of the aircraft, the aircraft having an aircraft network environment comprising:
a simulation network… including a virtual aircraft integration system (VAIS) configured to perform a real-time simulation of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
an aircraft network of the aircraft,
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
the aircraft network being in communication with the simulation network and being separate from the simulation network,
Duda teaches ([0078]): "As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces..." Duda further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda even further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102." The Examiner has interpreted the aircraft network (i.e., flight control system 116) as being separate from the simulation network (i.e., core platform 102), as each are considered by Duda to be distinct subsystems which communicate with one another through software and/or hardware interfaces.
the aircraft network including at least one of sensors, actuators, control devices, or line replaceable units located within the aircraft;
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
communication networks;
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156."
and a configurable status console implemented within a computer system via a processor,
Duda teaches ([0104]): "The HMI system 104 provides a control and communication interface for the pilot (e.g., a human pilot, whether on-board or remote). The HMI system 104 is configurable to operate as a flight plan manager that enables the pilot to direct the aircrew automation system 100. The HMI system 104 can combine elements of glass cockpits, unmanned aerial vehicle (“UAV”) ground stations, and electronic flight bags (EFB) to enable effective, efficient and latency-tolerant communication between the pilot and aircrew automation system 100... The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof." One of ordinary skill in the art would recognize tablet computers, laptop computers, and/or smartphones as having one or more processors.
the configurable status console being communicatively coupled with the simulation network and the aircraft network via the communication networks,
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102."
the method comprising: performing, via the configurable status console, an on-going scanning operation of the aircraft network and the simulation network;
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
and messaging data in real-time from the aircraft network,
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies..." Duda further teaches ([0117]): "The flight situation data perceived by the perception system 106 may be encoded and provided to the core platform 102 in real-time." Duda even further teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116." Duda still further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156."
the simulation data and the messaging data collectively including performance data and VAIS parameters;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
determining, using the simulation data and the messaging data, an overall health of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... a list of health hazards may be provide, along with one or corresponding icons to indicated one or more operational conditions that are out of range. For example, a low fuel indicator may be provided alongside a low fuel icon if fuel is low."
using status logic, determining, via the configurable status console, an expected data value of the simulation data and the messaging data,
Duda teaches ([0096]): "The aircraft data structure 208 can be populated and adjusted to a specific aircraft during a knowledge acquisition phase (e.g., during initial setup) such that it contains all the information necessary to operate the aircraft. For example, when transitioning to a new aircraft, the knowledge acquisition system 114 may perform predefined activities in order to determine the layout (e.g., of the controllers/read outs, such as the cockpit instruments), performance parameters, and other characteristics of the aircraft. The predefined activities may include, for example: ... (2) procedure codification, which informs aircrew automation system 100 how to operate aircraft in normal and non-normal situations, further including the codification of checklists; (3) an aerodynamic model, which informs the aircrew automation system 100 how to fly the aircraft and what performance to expect for which aircraft configurations..." Duda further teaches ([0100]): "The anomaly detection application 218 employs machine learning techniques to monitor aircraft state, cluster, and classify sensor inputs in order to detect the presence of non-normal situations, and to identify whether a contingency has occurred. The anomaly detection application 218 is configured to compare the sensed states against a set of thresholds defined in the operational documentation for the specific aircraft (e.g., never exceed a predetermined airspeed, engine temperature, etc.)."
and evaluating, via the configurable status console, the simulation data and the messaging data in relation to the expected data value to determine the configured status;
Duda teaches ([0101]): "In case of a contingency condition, a contingency operation application 220 executes the necessary predetermined checklists, procedures, and actions specified by the contingency application 220 in order to maintain safe operation of the aircraft or safely divert the flight. Notably, if a departure from expected performance is observed, the pilot can be alerted to a non-normal condition, thereby mitigating or avoiding potential mistakes... If an anomaly is detected, the contingency operation application 220 informs and interacts with the pilot via the HMI system 104 and ultimately executes the necessary procedure(s) to respond to the anomaly. Finally, the ISR application 222 and other flight plan-specific activity applications 224 may provide instructions, algorithms, or information to carry out operations relevant to a mission." Duda further teaches ([0155]): "After a period of time, the aircrew automation system 100 may detect that given the climb, the indicated airspeed is slowly deviating from its modeled airspeed for these pitch and power settings, indicating lower than expected values. This is an indication that the pitot heater has failed and the pitot tubes have iced up." Duda even further teaches ([0156]): "The aircrew automation system 100, however, recognizes that the airspeed data is anomalous to the rest of the flight data and its internal flight dynamics model, and aurally warns the pilot “airspeed indicator fault.”" Duda still further teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent."
and displaying the configured status at the configurable status console.
Duda teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent." Duda further teaches ([0035]): "In certain aspects, the human machine interface is configured to display a plurality of tasks on the touch screen display in a form of a task list. In certain aspects, each of the plurality of tasks is marked as either completed or not completed, for example, based at least in part on a pilot input via a touch screen display." Duda even further teaches ([0036]): "In certain aspects, the human machine interface is configured to display at least one of checklists, health alerts, predictions of aircraft state, and failure prognosis.”
However, while Duda does teach retrieving simulation data from the simulation network (see at least [0084] and [0097]), Duda does not outright teach retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. White teaches a flight management system, comprising:
retrieving at the configurable status console, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less;
White teaches ([0063]): "A simulation frame represents all the data transmitted/received within the base rate of time for the FMS computer. A "snapshot" of the data on the busses is typically taken at the beginning of the simulation frame and all the data processed by the FMS computer during the simulation frame are based on that snapshot." White further teaches ([0064]): "It should be noted that, depending on the size of the message buffer, the data transmitted on completion of a simulation frame may require more than one message buffer. It should be further noted that the frame rate for XSIM and the FMS computer need not be the same: the rate of the FMS computer might be, for example, 25 milliseconds for the simulation of one particular type of aircraft, but may be 30 milliseconds for another simulation. Other data may be required at twice the above-listed rates and may be spread over several 25 or 30 millisecond frames for performance reasons."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda to incorporate the teachings of White to provide retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. Duda and White are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of White, as doing so beneficially allows for retrieving data in real-time from the simulation network at rates as low as 25 milliseconds while allowing for data to be retrieved at rates of up to 60 milliseconds or over several 25-30 millisecond frames for performance reasons, as recognized by White ([0064]).
However, neither Duda nor White outright teach that the simulation network is exterior to the aircraft. Letsu-Dake teaches a system and method for enhancing the interactive transmission and visualization of flight data in real-time, comprising:
a simulation network exterior to the aircraft…
Letsu-Dake teaches ([0024]): "As such, in response to the vehicle data transmitted from the flight deck 106, the flight simulator 122 is enabled to receive and replicate, in real-time, the transmitted data associated with the automatic or manual response input activated at the flight deck 106. As such, the flight simulator 108 is enabled to replicate, in real-time, the functions that are currently presented at the flight deck 106. Consequently, the flight simulator 108 can implement suitable control functions that will enable the ground-based CSS 124 to navigate (e.g., utilizing rewind, forward, live controls) through the vehicle data received and thus more efficiently and effectively utilize the data to diagnose and resolve the avionics system's problem or failure involved." While the above citation makes reference to "the flight simulator 108", the Examiner notes that the reference character 108 is used elsewhere to refer to an aircraft standard communication bus (ASCB) 108 (see at least [0016] and FIG. 1) which is not described as being a flight simulator. As such, the use of reference character 108 in reference to the flight simulator appears to be erroneous. Therefore, the Examiner has interpreted "the flight simulator 108" as "the flight simulator 122".
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda and White to incorporate the teachings of Letsu-Dake to provide that the simulation network is exterior to the aircraft. Duda, White, and Letsu-Dake are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to implement the remote simulation network of Letsu-Dake, as the transmission of real-time flight data from the aircraft to the ground-based simulation network advantageously enables personnel to navigate the received data and more efficiently and effectively use the data to diagnose and resolve problems or failures in the aircraft's avionics system, as recognized by Letsu-Dake ([0024]). This ultimately serves to enhance the accuracy of diagnoses, as recognized by Letsu-Dake (see at least [0006]).
Regarding claim 14, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 13. Duda further teaches:
retrieving comprises continuously retrieving the performance data, the VAIS parameters and the message data in real-time from the aircraft network and the simulation network to determine the health of the aircraft.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
Regarding claim 15, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 13. Duda further teaches:
dynamically changing of the configured status at the configurable status console based on the dynamic changing of the performance data, VAIS parameters and messaging data.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
Regarding claim 16, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 13. Duda further teaches:
decoding the VAIS parameters and messaging data of the aircraft network to determine parameters available on the aircraft network and the simulation network at a given location and time, thereby configuring system-specific status information of an aircraft or the simulation network.
Duda teaches ([0078]): "To share the duties and workload related to the execution of flight activities, the aircrew automation system 100 should be capable of executing the actions a pilot would perform routinely over the duration of a flight, regardless of the aircraft make, model, or type. An example system architecture for an aircrew automation system 100 in accordance with one aspect is shown in FIGS. 1a through 1c. As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces 156 using wired and/or wireless communication protocols and hardware. FIG. 1b illustrates an example flow of information (e.g., data) between the various subsystems." FIG. 1b, included above, depicts the connections between these subsystems. Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance). For example, as illustrated, a list of tasks may be provided alongside indicators that indicate whether the task has been completed, is being completed, or needs to be completed (e.g., a "check mark" icon to include complete, an "in progress" icon, and a "to be completed" icon)."
Regarding claim 18, Duda teaches a computer-readable, non-transitory storage medium storing instructions that, when executed by a processor, cause the processor to perform a method of determining a configured status of at least one of an aircraft system of an aircraft, a component of the aircraft, or a simulation of the aircraft, the aircraft having an aircraft network environment comprising:
a simulation network… including a virtual aircraft integration system (VAIS) configured to perform a real-time simulation of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
an aircraft network of the aircraft,
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
the aircraft network being in communication with the simulation network and being separate from the simulation network,
Duda teaches ([0078]): "As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces..." Duda further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda even further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102." The Examiner has interpreted the aircraft network (i.e., flight control system 116) as being separate from the simulation network (i.e., core platform 102), as each are considered by Duda to be distinct subsystems which communicate with one another through software and/or hardware interfaces.
the aircraft network including at least one of sensors, actuators, control devices, or line replaceable units located within the aircraft;
Duda teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116. For example, the core platform may be configured to communicate one of more commands to the flight control system 116 of the aircraft based at least in part on the flight situation data, which may be obtained from the aircraft state monitoring system 112, the perception system 106, or a combination thereof."
communication networks;
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102."
and a configurable status console being communicatively coupled with the simulation network and the aircraft network via the communication networks,
Duda teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156." Duda further teaches ([0080]): "The plurality of subsystems may include, for example, a perception system 106, an actuation system 108, a human machine interface (“HMI”) system 104, and a flight control system 116, each of which may be operatively coupled with the core platform 102." Duda even further teaches ([0104]): "The HMI system 104 provides a control and communication interface for the pilot (e.g., a human pilot, whether on-board or remote). The HMI system 104 is configurable to operate as a flight plan manager that enables the pilot to direct the aircrew automation system 100. The HMI system 104 can combine elements of glass cockpits, unmanned aerial vehicle (“UAV”) ground stations, and electronic flight bags (EFB) to enable effective, efficient and latency-tolerant communication between the pilot and aircrew automation system 100... The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
the method comprising: performing, via the configurable status console, an on-going scanning operation of the aircraft network and the simulation network;
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
and messaging data in real-time from the aircraft network,
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies..." Duda further teaches ([0117]): "The flight situation data perceived by the perception system 106 may be encoded and provided to the core platform 102 in real-time." Duda even further teaches ([0081]): "In operation, the flight control system 116 derives the aircraft state based on information data from another subsystem (e.g., perception system 106) and directs another subsystem (e.g., the actuation system 108) to operate (e.g., dynamically) in a manner to maintain aircraft stability. For example, the flight control system 116 may receive vehicle mode commands and configuration data from the core platform 102, while sending to the core platform 102 status and command information generated by the flight control system 116." Duda still further teaches ([0079]): "The aircrew automation system 100 may comprise a core platform 102 operatively coupled with a plurality of subsystems, such as those listed below. Each of the plurality of subsystems of the aircrew automation system 100 may be modular, such that the entire aircrew automation system 100 can be substantially ported to another aircraft rapidly. For example, the various subsystems may be removably and communicatively coupled to one another via the core platform 102 using one or more software and/or hardware interfaces 156."
the simulation data and the messaging data collectively including performance data and VAIS parameters;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0097]): "The core platform 102 can combine this information with data from a set of internal state sensors, which also improve redundancy and system robustness, thereby allowing the aircrew automation system 100 to generate a highly accurate estimate of the aircraft state and system statuses, and to identify deviation from expected behavior. During flight operations, the data structure is dynamically updated with real-time data gathered by, inter alia, the aircrew automation system's 100, perception system 106, the HMI system 104, as well as the aircrew automation systems 100 for internal state sensing. Once the aircraft data structure 208 for a given aircraft is populated, the aircraft data structure 208 can then be retained in an aircraft library and used for all other aircraft of the same make and model for which aircrew automation system 100 is available."
determining, using the simulation data and the messaging data, an overall health of the aircraft;
Duda teaches ([0084]): "The core platform 102 serves as the primary autonomous agent and decision-maker, which synthesizes inputs from the perception system 106 and HMI system 104 with its acquired knowledge base to determine the overall system state. The core platform 102 may process inputs from the various sensor suites and aggregate the resultant information into an understanding of current aircraft state. The resultant information may be compared against an aircraft specific file that encompasses aircrew automation system's 100 understanding of pilot intent, system health, and understanding of appropriate aircraft procedures as they relate to the aircrew automation system's 100 state estimation." Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... a list of health hazards may be provide, along with one or corresponding icons to indicated one or more operational conditions that are out of range. For example, a low fuel indicator may be provided alongside a low fuel icon if fuel is low."
using status logic, analyzing, via the configurable status console, the simulation data and the messaging data
Duda teaches ([0096]): "The aircraft data structure 208 can be populated and adjusted to a specific aircraft during a knowledge acquisition phase (e.g., during initial setup) such that it contains all the information necessary to operate the aircraft. For example, when transitioning to a new aircraft, the knowledge acquisition system 114 may perform predefined activities in order to determine the layout (e.g., of the controllers/read outs, such as the cockpit instruments), performance parameters, and other characteristics of the aircraft. The predefined activities may include, for example: ... (2) procedure codification, which informs aircrew automation system 100 how to operate aircraft in normal and non-normal situations, further including the codification of checklists; (3) an aerodynamic model, which informs the aircrew automation system 100 how to fly the aircraft and what performance to expect for which aircraft configurations..." Duda further teaches ([0100]): "The anomaly detection application 218 employs machine learning techniques to monitor aircraft state, cluster, and classify sensor inputs in order to detect the presence of non-normal situations, and to identify whether a contingency has occurred. The anomaly detection application 218 is configured to compare the sensed states against a set of thresholds defined in the operational documentation for the specific aircraft (e.g., never exceed a predetermined airspeed, engine temperature, etc.)."
and determining the configured status;
Duda teaches ([0101]): "In case of a contingency condition, a contingency operation application 220 executes the necessary predetermined checklists, procedures, and actions specified by the contingency application 220 in order to maintain safe operation of the aircraft or safely divert the flight. Notably, if a departure from expected performance is observed, the pilot can be alerted to a non-normal condition, thereby mitigating or avoiding potential mistakes... If an anomaly is detected, the contingency operation application 220 informs and interacts with the pilot via the HMI system 104 and ultimately executes the necessary procedure(s) to respond to the anomaly. Finally, the ISR application 222 and other flight plan-specific activity applications 224 may provide instructions, algorithms, or information to carry out operations relevant to a mission." Duda further teaches ([0155]): "After a period of time, the aircrew automation system 100 may detect that given the climb, the indicated airspeed is slowly deviating from its modeled airspeed for these pitch and power settings, indicating lower than expected values. This is an indication that the pitot heater has failed and the pitot tubes have iced up." Duda even further teaches ([0156]): "The aircrew automation system 100, however, recognizes that the airspeed data is anomalous to the rest of the flight data and its internal flight dynamics model, and aurally warns the pilot “airspeed indicator fault.”" Duda still further teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent."
and displaying the configured status at the configurable status console.
Duda teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent." Duda further teaches ([0035]): "In certain aspects, the human machine interface is configured to display a plurality of tasks on the touch screen display in a form of a task list. In certain aspects, each of the plurality of tasks is marked as either completed or not completed, for example, based at least in part on a pilot input via a touch screen display." Duda even further teaches ([0036]): "In certain aspects, the human machine interface is configured to display at least one of checklists, health alerts, predictions of aircraft state, and failure prognosis."
However, while Duda does teach retrieving simulation data from the simulation network (see at least [0084] and [0097]), Duda does not outright teach retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. White teaches a flight management system, comprising:
retrieving at the configurable status console, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less,
White teaches ([0063]): "A simulation frame represents all the data transmitted/received within the base rate of time for the FMS computer. A "snapshot" of the data on the busses is typically taken at the beginning of the simulation frame and all the data processed by the FMS computer during the simulation frame are based on that snapshot." White further teaches ([0064]): "It should be noted that, depending on the size of the message buffer, the data transmitted on completion of a simulation frame may require more than one message buffer. It should be further noted that the frame rate for XSIM and the FMS computer need not be the same: the rate of the FMS computer might be, for example, 25 milliseconds for the simulation of one particular type of aircraft, but may be 30 milliseconds for another simulation. Other data may be required at twice the above-listed rates and may be spread over several 25 or 30 millisecond frames for performance reasons."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda to incorporate the teachings of White to provide retrieving, via the communication networks, simulation data in real-time from the simulation network every 500 milliseconds or less. Duda and White are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of White, as doing so beneficially allows for retrieving data in real-time from the simulation network at rates as low as 25 milliseconds while allowing for data to be retrieved at rates of up to 60 milliseconds or over several 25-30 millisecond frames for performance reasons, as recognized by White ([0064]).
However, neither Duda nor White outright teach that the simulation network is exterior to the aircraft. Letsu-Dake teaches a system and method for enhancing the interactive transmission and visualization of flight data in real-time, comprising:
a simulation network exterior to the aircraft…
Letsu-Dake teaches ([0024]): "As such, in response to the vehicle data transmitted from the flight deck 106, the flight simulator 122 is enabled to receive and replicate, in real-time, the transmitted data associated with the automatic or manual response input activated at the flight deck 106. As such, the flight simulator 108 is enabled to replicate, in real-time, the functions that are currently presented at the flight deck 106. Consequently, the flight simulator 108 can implement suitable control functions that will enable the ground-based CSS 124 to navigate (e.g., utilizing rewind, forward, live controls) through the vehicle data received and thus more efficiently and effectively utilize the data to diagnose and resolve the avionics system's problem or failure involved." While the above citation makes reference to "the flight simulator 108", the Examiner notes that the reference character 108 is used elsewhere to refer to an aircraft standard communication bus (ASCB) 108 (see at least [0016] and FIG. 1) which is not described as being a flight simulator. As such, the use of reference character 108 in reference to the flight simulator appears to be erroneous. Therefore, the Examiner has interpreted "the flight simulator 108" as "the flight simulator 122".
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda and White to incorporate the teachings of Letsu-Dake to provide that the simulation network is exterior to the aircraft. Duda, White, and Letsu-Dake are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to implement the remote simulation network of Letsu-Dake, as the transmission of real-time flight data from the aircraft to the ground-based simulation network advantageously enables personnel to navigate the received data and more efficiently and effectively use the data to diagnose and resolve problems or failures in the aircraft's avionics system, as recognized by Letsu-Dake ([0024]). This ultimately serves to enhance the accuracy of diagnoses, as recognized by Letsu-Dake (see at least [0006]).
Regarding claim 19, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 18. Duda further teaches:
the retrieving further comprises continuously retrieving the performance data, the VAIS parameters and the message data in real-time from the aircraft network and the simulation network to determine the health of the aircraft.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, and Letsu-Dake in view of Egner (US 2020/0159223 A1).
Regarding claim 4, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 3. However, Duda does not outright teach that the messaging data is retrieved continuously to determine an actual rate of the messaging data for comparison to an expected rate. Egner teaches a communication system for an autonomous drone, comprising:
the messaging data is retrieved continuously to determine an actual rate of the messaging data for comparison to an expected rate.
Egner teaches ([0040]): "Autonomous flight for a drone, according to various aspects of the present disclosure, includes flying in accordance with a tracking mode, an observation mode, or a stealth mode while attempting to meet a communication criterion (e.g., minimum communication rate)..." Egner further teaches ([0204]): "The operations may further comprise comparing a communication rate to a communication rate threshold and automatically changing the distance between the drone and the object in accordance with the comparison of the sound intensity level threshold to the sound intensity level of the drone, the comparison of the object resolution threshold to the object resolution of the object in the image captured by the camera of the drone, and the comparison of the communication rate to the communication rate threshold. Comparing the communication rate may include calculating a communication ratio by dividing the communication rate of the drone by the communication rate threshold and automatically changing the distance between the drone and the object may include changing the distance until the communication ratio is equal or greater than a predetermined value."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Egner to provide that the messaging data is retrieved continuously to determine an actual rate of the messaging data for comparison to an expected rate. Duda, White, Letsu-Dake, and Egner are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Egner, as doing so beneficially allows for maintaining a communication criterion above a minimum communication rate threshold, as recognized by Egner ([0040]). The implementation of Egner advantageously allows for adjusting flight parameters and instructions in order to meet the communication requirements (see at least [0204]).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, and Letsu-Dake in view of Hendi et al. (US 2017/0339210 A1), hereinafter Hendi, and in further view of Hedrick (US 6,952,630 B2).
Regarding claim 6, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. Duda further teaches:
the performance data comprises… aircraft usage data including flight control data, fuel data,… temperature data and aircraft operations data.
Duda teaches ([0118]): "FIG. 4 illustrates an example perception system 106 operatively coupled with, inter alia, the core platform 102 (which is coupled to other subsystems, such as flight control system 116), the GPS/INS system 154, and any other input systems 412. The perception system 106 visually and/or acoustically monitors, inter alia, the cockpit instruments to generate flight situation data that can be used to derive the aircraft state from cockpit layouts, which may range from basic analog aircraft instruments to highly integrated, glass cockpit avionics suites. In addition to deriving physical state such as airspeed and altitude, the perception system 106 may also monitor instruments that are specific to aircraft systems such as fuel gauges and radios and provide secondary feedback about the status and positioning of the actuation system 108." Duda further teaches ([0119]): "As illustrated, the perception system 106 may comprise a perception controller 402 that is operatively coupled with a database 404 and a plurality of sensors, such as cameras 410 (used for the vision system), microphone 408 (used for the acoustic system), and/or other sensors 406 (e.g., temperature sensors, positional sensors, inertial sensors, etc.). The perception controller 402 may be, for example, a processor configured to feed flight situation data to (or otherwise instruct) the core platform 102 based upon information received and manipulated information received from the plurality of sensors, the database 404, and external components, such as the GPS/INS system 154 and other input systems 412."
However, Duda does not outright teach that the performance data comprises computer networks and IP systems data. Hendi teaches methods and systems for secured remote browsing from a transportation vehicle, comprising:
the performance data comprises computer networks and IP systems data,
Hendi teaches ([0043]): "In one aspect, the AVCServer 326 also tracks bandwidth usage by maintaining the data structure 348. The data structure 348 includes a time stamp for each session, an airline identifier, aircraft tail number that uniquely identifies an aircraft, a seat number, seat IP address, aircraft IP address, the seatback device type, the SBClient version number, duration of a session, uplink bandwidth used, downlink bandwidth used, keystrokes for the session and the number of mouse moves for the session. The bandwidth information may be used by the remote browser 342 to adjust content streaming based on satellite bandwidth availability. In one aspect, the remote cloud browser 342 reduces image resolution or a streaming rate when bandwidth availability is limited. "
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Hendi to provide that the performance data comprises computer networks and IP systems data. Duda, White, Letsu-Dake, and Hendi are each directed towards similar pursuits in the field of vehicle status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Hendi, as doing so beneficially allows for the reduction of used bandwidth by reducing image resolution or streaming rate of in-vehicle devices based on IP address when bandwidth availability is limited, as recognized by Hendi ([0043]).
However, Duda does not outright teach that the performance data comprises pressure data. Hedrick teaches a method and apparatus for facilitating ease of viewing and interpretation of data concurrently presented to a flight crew, comprising:
the performance data comprises… [pressure data]…
Hedrick teaches (Col. 4 line 1 - Col. 5 line 11): "The imaging data is derived or calculated by a graphics processor 20 or in communication with the controller 16 from sensor measurements and other input data and the like which is obtained from a plurality of aircraft and environmental sensors or inputs or other aircraft systems, collectively referred to herein as the sensors or sensor bank 18... Data required for moment-to-moment control of an aircraft (herein referred to as "primary data"), such as altitude, attitude, airspeed, etc. which are typically associated with so-called primary flight instruments will be presented on the display at a "full" or high illumination brightness relative to data which is not required for moment-to-moment aircraft operation (referred to herein as "secondary data"), such as indications of various engine and aircraft parameters including hydraulic pressure, engine temperature, fuel flow and remaining quantity, and electrical system voltage and status..."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, Letsu-Dake and Hendi to incorporate the teachings of Hedrick to provide that the performance data comprises pressure data. Duda, White, Letsu-Dake, Hendi, and Hedrick are each directed towards similar pursuits in the field of vehicle status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Hedrick, as the implementation of Hedrick advantageously allows for displaying parameters such as hydraulic pressure at a lower illumination value alongside fully-illuminated data considered vital to moment-to-moment control of an aircraft, as recognized by Hedrick (see at least Col. 4 line 1 - Col. 5 line 11).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, and Letsu-Dake in view of Ohtsuji et al. (US 2019/0361434 A1), hereinafter Ohtsuji.
Regarding claim 7, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. Duda further teaches:
and generate the configured status for the aircraft or components or simulation thereof.
Duda teaches ([0157]): "Drawing on a database of prior anomalies, the aircrew automation system 100 presents a set of procedural options and highlights the minimum safe altitude for the area (e.g., 8,000 ft). The pilot chooses the most conservative option, which results in wings level, pitch, and power descent to a lower altitude (e.g., 10,000 ft). The aircrew automation system 100 eases back on the power, pitches slightly down, and commences the descent." Duda further teaches ([0035]): "In certain aspects, the human machine interface is configured to display a plurality of tasks on the touch screen display in a form of a task list. In certain aspects, each of the plurality of tasks is marked as either completed or not completed, for example, based at least in part on a pilot input via a touch screen display." Duda even further teaches([0036]): "In certain aspects, the human machine interface is configured to display at least one of checklists, health alerts, predictions of aircraft state, and failure prognosis."
However, Duda does not outright teach that the configurable status console is further configured to initiate a stop of the on-going scanning operation upon request. Ohtsuji teaches a surveillance system and unmanned flying object, comprising:
the configurable status console is further configured to initiate a stop of the on-going scanning operation upon request,
Ohtsuji teaches ([0125]): "Referring to FIG. 16, if any reason why surveillance of a surveillance target being surveilled should be cancelled occurs (step S501), an unmanned aerial vehicle #1 transits a surveillance cancellation request (surveillance finish request) to a management sever 100..." Ohtsuji further teaches ([0139]): "The management server 100 that has received the notification of the start of the surveillance from the unmanned aerial vehicle #2 instructs the unmanned aerial vehicle #1 to finish the surveillance of the surveillance target... The unmanned aerial vehicle #1 that has received the instruction finishes the surveillance of the surveillance target, based on an instruction that has been received from the management server 100, and notifies the finish of the surveillance of the surveillance target to the management server 100..."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Ohtsuji to provide that the configurable status console is further configured to initiate a stop of the on-going scanning operation upon request. Duda, White, Letsu-Dake, and Ohtsuji are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Ohtsuji, as doing so beneficially allows for cancellation of on-going scanning when certain conditions are detected, including low battery capacity or hardware failure, as recognized by Ohtsuji ([0125]-[0131]).
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, and Letsu-Dake in view of Entelis et al. (US 2022/0046114 A1), hereinafter Entelis.
Regarding claim 8, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 1. However, Duda does not outright teach that the VAIS parameters comprise ARINC 664, ARINC 825 and ARINC 429 network message structure and data characteristics for simulated aircraft information. Entelis teaches a system and method for data compression based on data position, comprising:
the VAIS parameters comprise ARINC 664, ARINC 825 and ARINC 429 network message structure and data characteristics for simulated aircraft information.
Entelis teaches ([0132]): "A vehicle bus may consist of, or may comprise, an avionics bus, used as a data bus in military, commercial and advanced models of civilian aircraft. Common avionics data bus protocols, with their primary application, include Aircraft Data Network (ADN) that is an Ethernet derivative for Commercial Aircraft, Avionics Full-Duplex Switched Ethernet (AFDX) that is a specific implementation of ARINC 664 (ADN) for Commercial Aircraft, ARINC 429: “Generic Medium-Speed Data Sharing for Private and Commercial Aircraft”, ARINC 664, ARINC 629 used in Commercial Aircraft (such as Boeing 777), ARINC 708: “Weather Radar for Commercial Aircraft”, ARINC 717: “Flight Data Recorder for Commercial Aircraft”, ARINC 825 that is a CAN bus for commercial aircraft (for example Boeing 787 and Airbus A350)..." Entelis further teaches ([0385]): "Any network herein may be a vehicle network, such as a vehicle bus or any other in-vehicle network. A connected element comprises a transceiver for transmitting to, and receiving from, the network. The physical connection typically involves a connector coupled to the transceiver. The vehicle bus may consist of, may comprise, may be compatible with, may be based on, or may use a Controller Area Network (CAN) protocol, specification, network, or system." Duda and White are modified such that the network message structure and data characteristics of the VIAS parameters of Duda and White are communicated using the avionics data bus protocols of Entelis.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Entelis to provide that the VAIS parameters comprise ARINC 664, ARINC 825 and ARINC 429 network message structure and data characteristics for simulated aircraft information. Duda, White, Letsu-Dake, and Entelis are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Entelis, as utilizing the ARINC standard is beneficial, as it is the technical standard for the predominant avionics data bus used on most higher-end commercial and transport aircraft, as recognized by Entelis ([0136]).
Regarding claim 9, Duda, White, Letsu-Dake, and Entelis teach the aforementioned limitations of claim 8. Duda further teaches:
the performance data, VAIS parameters and messaging data dynamically change such that the configured status dynamically changes at the configurable status console.
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The aircrew automation system 100 also monitors system health, comparing the current system state to that expected based on the POH and other knowledge sources, and guides appropriate responses to contingencies... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance)." Duda further teaches ([0104]): "The HMI system 104 may include a human-machine interface 126, which may be based on a touch screen graphical user interface (“GUI”) and/or speech-recognition systems. The human-machine interface 126 may employ, for example, a tablet computer, a laptop computer, a smart phone, or combination thereof."
Regarding claim 10, Duda, White, Letsu-Dake, and Entelis teach the aforementioned limitations of claim 9. Duda further teaches:
the configurable status console is further configured to decode the VAIS parameters and messaging data of the aircraft network to determine parameters available on the aircraft network and the simulation network at a given location and time, to thereby configure system-specific status information of an aircraft or the simulation network.
Duda teaches ([0078]): "To share the duties and workload related to the execution of flight activities, the aircrew automation system 100 should be capable of executing the actions a pilot would perform routinely over the duration of a flight, regardless of the aircraft make, model, or type. An example system architecture for an aircrew automation system 100 in accordance with one aspect is shown in FIGS. 1a through 1c. As illustrated in FIG. 1a, the core platform 102 may operate as a central subsystem that connects the other subsystems via one or more interfaces. The subsystems may communicate with one another through software and/or hardware interfaces 156 using wired and/or wireless communication protocols and hardware. FIG. 1b illustrates an example flow of information (e.g., data) between the various subsystems." FIG. 1b, included above, depicts the connections between these subsystems. Duda further teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts... The HMI system 104 may give visual and auditory alerts to direct the pilot's attention to unattended checklist items, instruments that are displaying out-of-normal range values, or predicted events as the aircraft proceeds through the flight plan, which can be entered as a series of waypoints (for instance). For example, as illustrated, a list of tasks may be provided alongside indicators that indicate whether the task has been completed, is being completed, or needs to be completed (e.g., a "check mark" icon to include complete, an "in progress" icon, and a "to be completed" icon)."
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, Letsu-Dake, and Entelis in view of Yerli (US 11,101,874 B1).
Regarding claim 11, Duda, White, Letsu-Dake, and Entelis teach the aforementioned limitations of claim 10. However, Duda does not outright teach that the configurable status console implements the status logic, via the one or more processors, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Yerli teaches a method and system for providing in-flight network communications, comprising:
the configurable status console implements the status logic, via the one or more processor, to evaluate the aircraft network and the simulation network,
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network.
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, Letsu-Dake, and Entelis to incorporate the teachings of Yerli to provide that the configurable status console implements the status logic, via the one or more processors, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Duda, White, Letsu-Dake, Entelis, and Yerli are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Yerli, as doing so advantageously allows for disconnection from the aircraft network when it is determined that the network connection status is insecure, as recognized by Yerli (Col. 1 line 63 - Col. 2 line 11).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, Letsu-Dake, Entelis, and Yerli in view of Ganjoo (US 9,927,807 B1).
Regarding claim 12, Duda, White, Letsu-Dake, Entelis, and Yerli teach the aforementioned limitations of claim 11. Duda further teaches:
the aircraft specific decision criteria comprises… checking a temperature rate change of aircraft systems,
Duda teaches ([0113]): "The HMI system 104 may provide an intuitive display and interface that includes checklist verification and health alerts from the core platform 102 and predictions of aircraft state (e.g., fuel consumption and predicted remaining range), as well as failure prognosis and deviation alerts (e.g., “Left engine EGT is 5 degrees above normal and rising”). Thus, when the pilot selects the procedures tab 330, as illustrated in FIG. 3b, the pilot may review and monitor checklist items, as well as review any health alerts."
However, Duda does not outright teach that the aircraft specific decision criteria comprises checking aircraft test interfaces for periodic monitor message receive rate, checking simulation network interfaces for dropped frames, and checking latency of periodic monitor messages from the aircraft network and the simulation network. Ganjoo teaches command and control of unmanned vehicles, comprising:
the aircraft specific decision criteria comprises checking aircraft test interfaces for periodic monitor message receive rate,
Ganjoo teaches (Col. 2 lines 39-45): "In various embodiments, the method further includes: determining the available bandwidth for each of the hops as well as the bandwidth available via all available gateways to either local or remote cloud based control station; and selecting the best available gateway and packet routing path based on the minimum latency, packet loss and available throughput over the link." Ganjoo further teaches (Col. 17 lines 10-18): "The predicted shortest path may be a path with a fewest number of nodes between the drone and the control system; a path with the shortest latency for messages passed between the drone and the control system..."
checking simulation network interfaces for dropped frames,
Ganjoo teaches (Col. 2 lines 39-45): "In various embodiments, the method further includes: determining the available bandwidth for each of the hops as well as the bandwidth available via all available gateways to either local or remote cloud based control station; and selecting the best available gateway and packet routing path based on the minimum latency, packet loss and available throughput over the link."
checking latency of periodic monitor messages from the aircraft network and the simulation network.
Ganjoo teaches (Col. 2 lines 39-45): "In various embodiments, the method further includes: determining the available bandwidth for each of the hops as well as the bandwidth available via all available gateways to either local or remote cloud based control station; and selecting the best available gateway and packet routing path based on the minimum latency, packet loss and available throughput over the link." Ganjoo further teaches (Col. 17 lines 10-18): "The predicted shortest path may be a path with a fewest number of nodes between the drone and the control system; a path with the shortest latency for messages passed between the drone and the control system..."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, Letsu-Dake, Entelis, and Yerli to incorporate the teachings of Ganjoo to provide that the aircraft specific decision criteria comprises checking aircraft test interfaces for periodic monitor message receive rate, checking simulation network interfaces for dropped frames, and checking latency of periodic monitor messages from the aircraft network and the simulation network. Duda, White, Letsu-Dake, Entelis, Yerli, and Ganjoo are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Ganjoo, as doing so allows for the determination of a best available gateway and routing path based on the shortest latency for messages passed between the aircraft and the server, as recognized by Ganjoo (see at least Col. 2 lines 39-45 and Col. 17 lines 10-18).
Claim(s) 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duda, White, and Letsu-Dake in view of Yerli.
Regarding claim 17, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 16. However, Duda does not outright teach implementing the status logic, via the processor, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Yerli teaches a method and system for providing in-flight network communications, comprising:
implementing the status logic via the processor, to evaluate the aircraft network and the simulation network,
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network.
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Yerli to provide implementing the status logic, via the processor, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Duda, White, Letsu-Dake, and Yerli are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Yerli, as doing so advantageously allows for disconnection from the aircraft network when it is determined that the network connection status is insecure, as recognized by Yerli (Col. 1 line 63 - Col. 2 line 11).
Regarding claim 20, Duda, White, and Letsu-Dake teach the aforementioned limitations of claim 18. However, Duda does not outright teach implementing the status logic, via the processor, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Yerli teaches a method and system for providing in-flight network communications, comprising:
the method further comprises: implementing the status logic via the processor, to evaluate the aircraft network and the simulation network,
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network.
Yerli teaches (Col. 1 line 63 - Col. 2 line 11): "In some embodiments, the method may also include, after disconnecting the onboard server from the aircraft communications network checking for network connection readiness, in response to again finding a secure connection to the aircraft communications network based on the one or more connection rules, connecting the onboard server and one or more user devices to the aircraft communications network, continuing monitoring status of the connection to the aircraft communications network, and in response to determining that the network connection status is again insecure based on the one or more connection rules, disconnecting the onboard server from the aircraft communications network again. In some embodiments, the one or more connection rules include at least one of a speed threshold, an altitude threshold, an air pressure threshold, and a location threshold measured by corresponding sensing devices."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Duda, White, and Letsu-Dake to incorporate the teachings of Yerli to provide implementing the status logic, via the processor, to evaluate the aircraft network and the simulation network, wherein the status logic includes using aircraft specific decision criteria to determine a status of the aircraft network and simulation network. Duda, White, Letsu-Dake, and Yerli are each directed towards similar pursuits in the field of aircraft status monitoring. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Yerli, as doing so advantageously allows for disconnection from the aircraft network when it is determined that the network connection status is insecure, as recognized by Yerli (Col. 1 line 63 - Col. 2 line 11).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Boldrin et al. (US 2010/0131238 A1) teaches systems and methods for control system verification and health assessment of an aircraft, including monitoring of sensors, flaps, ailerons, and valves (see at least [0021]). Sugaya (US 2016/0379619 A1) teaches a wireless aircraft and noise cancelling program, including the generation and execution of a request of ending data collection (see at least [0064]). Schuchman (US 2008/0266166 A1) teaches an automatic dependent surveillance system, including communication with aircraft approximately every second (see at least [0126]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK T GLENN III whose telephone number is (571)272-5078. The examiner can normally be reached M-F 7:30AM - 4:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jelani Smith can be reached at 571-270-3969. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/F.T.G./Examiner, Art Unit 3662
/DALE W HILGENDORF/Primary Examiner, Art Unit 3662