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 .
Drawings
The drawings were received on May 12th 2023. These drawings are accepted.
Status of the Claims
This action is in response to the applicant’s filing on October 6th 2025;
Claims 1-20 are pending and examined below.
Response to Arguments
Applicant’s amendments with respect to the rejection of claims under 35 USC § 103 have been fully considered but are moot. While the Examiner notes that the applicant is arguing the claim limitations recite " … (ii) generating summary data from the uploaded fault data, the summary data providing a final state of faults described in the fault data… “. Therefore, the rejection has been withdrawn; However, upon further consideration a new ground(s) of rejection is made for Claims 1 over Dixit (Patent No. US10964130B1) in view of Misenheimer (Patent No. US20220063839A1) and Martin (Patent No. US20200047914A1).
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.
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.
Claims 1-4. 7-9, 15 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Dixit (Patent No. US10964130B1) in view of Misenheimer (Patent No. US20220063839A1) and Martin (Patent No. US20200047914A1).
Regarding claim 1 Dixit teaches a method of facilitating diagnosis of anomalies in an engine of an aircraft, comprising; (See Dixit column 5, line 55-67 and column 6, line 1-3; “Operational Flight Program (OFP) 102 encompasses hardware and software for managing the overall operation of the vehicle. OFP 102 includes a runtime diagnostics engine IVHMExec 104. OFP 102 may also be implemented as a standalone avionics IVHM computer attached passively to the avionics data buses, actively interfaced with mission planning systems, and actively interfaced with ground systems and maintenance systems 122. IVHMExec 104 includes a diagnostic Model Based Reasoner (MBR) Engine 106. MBR Engine 106 combines a physical model of a vehicle system or subsystem with input data describing the system state, then performs deterministic inference reasoning to determine whether the system is operating normally, if any system anomalies exist, and if so, to isolate and identify the locations and types of faults and false alarms that exist.”);
the FST including a GUI (graphical user interface) having a set of UI (user interface) controls; and in response to a user operation of one or more of the UI controls; (See Dixit column 37, line 37-58; “FIGS. 36-37 provide a block diagram of an exemplary Fleet Level Prognostics System 3600 for which user selectable controls are provided by GUI 3601, as shown in more detail in FIG. 44. The exemplary GUI 3601 consists of a menu bar 3602 with a plurality of menus, a toolbar 3603 with a plurality of actionable button icons configured to initiate actions as indicated by the names in the tooltips 3604 shown when the mouse hovers over the button icons. The main screen body 3605 is a table that displays rows of all available aircraft where each row displays one aircraft as identified by tail number (aircraft from the fleet of like-type aircrafts are individually identified by their tail numbers). Each column in the table may display attributes particular to an aircraft tail number, such as, its serial number, tail number, mission capability (ground based, partially mission capable (PMC), non-mission capable (NMC) and fully mission capable (FMC)), it's zone, it's location, and other user defined attributes. Each displayed aircraft can be mouse selected to show its state, equipment assets, etc. The GUI has modes of operation which are role-based, i.e. each role pertains to different usage by personnel having different objectives.”);
Dixit does not teach but Misenheimer teaches, while the aircraft is in flight, recording, by an ECU (engine control unit) coupled to the engine, fault data generated in real time by the engine; (See Misenheimer paragraph 0038 and Figure 1 and 2 “…the aircraft system 100 may include a variety of sensors that may detect faults during a flight. In known systems, the faults may be identified and recorded by the ECU 200 or other components of the aircraft system 100 based on the sensor data...”);
PNG
media_image1.png
836
664
media_image1.png
Greyscale
while the aircraft is not in flight, running an FST (field service tool) by a computer coupled to the ECU; (See Misenheimer paragraph 0047 and Figure 1 and 2; “After the aircraft 130 completes a flight and lands, and a maintenance crew performs maintenance on the aircraft 130, the fault output module 248 may access the fault data 238b in the data storage component 236 and output an indication of each fault that occurred during the flight…”); (i) uploading the fault data from the ECU to the FST; (See Misenheimer paragraph 0044; “Referring still to FIG. 2…The fault detection module 242 may store information regarding detected faults as fault data 238b in the data storage component 236.”).
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer ECU connected to the computer and to upload the fault data. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the ECU connected to the computer and to upload the fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Dixit does not teach but Martin teaches, and (ii) generating summary data from the uploaded fault data, the summary data providing a final state of faults described in the fault data; (See Martin paragraph 0080-0081 and 0085-0086;” Both the temporal precursor network 128 and the summary table 126 provide maintenance personnel, an operator of the aircraft 100, or other users with different manners in which to view and confidently assess potential causal chains of events. The temporal precursor network 128, for instance, visually depicts events that are statistically likely to have led to other events, as well as visually depicts which aircraft subsystems are experiencing more events than others. Using the temporal precursor network 128, a user can trace events between multiple different aircraft subsystems and/or electrical buses. As an example, seconds after a flight control subsystem fault code is signaled, fault codes in two other subsystems might be signaled. However, only one of those two subsequent fault codes might be statistically dependent on the flight control subsystem fault code, and the temporal precursor network 128 can depict that causal chain, thereby enabling a user to confidently eliminate the possibility that the other of the two subsequent fault codes is being caused by the flight control subsystem fault code. Other examples are possible as well.
Furthermore, the summary table 126 provides a concise summary of events having threshold-high statistical dependence. Using the summary table 126, a user can view and navigate through the summary table 126 to quickly search for and identify chains of events that are of interest, as well as confidently eliminate chains of events that, while shown to be statistically dependent, might not actually be casually related. The ability for a user to discern which chains of events are, in actuality, causal chains with a root cause can be even further assisted by the fault diagnostics computing device 106 indexing additional measurements in the summary table 126, examples of which will be discussed in more detail below.
In some implementations, the fault diagnostics computing device 106 can rank-order sequences of related events based on one or more factors, such as the values of statistical dependence. For example, if a first sequence of related events has a higher value of statistical dependence than a second sequence of related events, the first sequence of related events can be ranked higher than the second sequence of related events. The summary table 126 can include an indication of this ranking, such as by a number (e.g., 1, 2, 3, etc.) or other text, or can include the highest-ranked sequence of related events at a first, top row of the summary table 126 and lower-ranked sequences of related events in lower rows. Other examples are possible as well.
In some implementations, a user can select a row of the summary table 126, which can trigger the fault diagnostics computing device 106 to display supplemental information associated with the sequence of related events to which the selected row corresponds. For example, the fault diagnostics computing device 106 could be triggered to display the temporal precursor network 128 and highlight or otherwise emphasize the nodes in the temporal precursor network 128 that correspond to the selected sequence of related events. Additionally or alternatively, the fault diagnostics computing device 106 could be triggered to retrieve and display additional information about the aircraft subsystems and/or electrical buses involved in the sequence of related events, such as a visual indication (e.g., a diagram or map) of where the aircraft subsystems and/or electrical buses are within the aircraft 100 and/or other information. Other examples are possible as well.”).
Both Dixit and Martin are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Martin providing a final state of faults described in the fault data. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 2 Dixit in view of Misenheimer and Martin teaches the method of claim 1, Dixit teaches, wherein generating the summary data includes, for a particular fault type, consolidating multiple fault messages of the uploaded fault data for the particular fault type into a single fault message that provides the final state of the particular fault type; (See Dixit column 16, line 17-67 and column 17, line 1-21 ; “The off normal measurement module 1245 receives the respective sensor data from the anomaly/degradation detection module 1240. Module 1245 makes parameter distance measurements of the values associated with each sensor output relative to normal parameter values for the determined mode of operation. Based on these parameter distance measurements, the off normal measurement module 1245 makes a determination for each sensor output of whether the function being sensed by the sensor is operating within a normal mode or if an anomaly exists. If the sensor output value falls within the corresponding normal value window, a normal operation is determined, i.e. the function is operating within anticipated range of operation. If the sensor output falls outside the corresponding normal value window, and anomaly of operation is determined, i.e. the function is operating with degraded performance or failure, or problem with the sensor or its calibration exists. Refer to the tag conditional codes as explained above. Such a tag is applied to each sensor output and transmitted to the set anomaly and degradation flag module 1250. Module 1250 incorporates such a tag with each of the sensor output values which are transmitted as outputs 1162 to the data conditioning module 1165. FIG. 13 is a block diagram of an embodiment of the data fusion module 1170 as shown in FIG. 11. The fusion module 1170 may be implemented by software running on a microprocessor-based computer. A data mapper module 1310 receives incoming streams of sensor data 1305 from data conditioning modules 1125, 1145 and 1165. This module maps or correlates the data from the incoming sensor streams so that the data from different sensors that are correlated, as explained above, are integrated into respective groups within a moving time window. That is, as the time window moves, sensor outputs occurring within that time window are those to be mapped into correlated groups. Since the incoming sensor data has been standardized to a common data rate, the time within each time window can be selected to capture one data output for each sensor. Since the sensors that will be supplying data are known in advance and groups of sensors that are correlated can be manually predetermined, the correlation information (sets of sensors that are correlated) to can be stored in memory and utilized to route the respect of sensor outputs by the data mapper into respective correlated groups. These groups of correlated sensor outputs are input to fuse data module 1315 which analyzes the data for a correlated group of sensor outputs, including sensor outputs in the group determined to be degraded/anomalous, against a stored set of initial performance parameters for the corresponding group of correlated sensors. The fuse data module 1315 fuses or integrates the data for a correlated group of sensor outputs into a single data set that is tagged with conditional fault or anomaly codes to assist in further analysis provided by the diagnostic model based reasonor engine 106. The fused output data from the fuse data module 1315 is an input to the parameter characterization module 1320 which compares the data associated with each correlated group of sensor outputs with outputs from single sensors that are part of the respective correlated group of sensors. This comparison preferably utilizes the corresponding outputs from single sensors from a past or last state. Such a comparison with a past output sensor state is useful for showing and predicting future states that may indicate off-normal behaviors or at least trending towards off-normal behaviors. The results of such comparisons are stored in a queue and then output as an organized set as outputs 1175 to the MBR engine 106 for further analysis. The queue allows for variable data rate output to accommodate any processing latency required in the MBR Engine 106, while managing the input data rates 1175 without loss of data (by dynamically allocating more processor RAM for queue as needed and releasing the allocated RAM when not needed).”).
Regarding claim 3 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit further teaches, wherein generating the summary data for the particular fault type includes constructing the single fault message to include: a fault code that identifies the fault; an ECU channel from which the fault originated, as one of a primary channel or a secondary channel; a final fault status of the particular fault type as one of active or inactive; and a lamp indicator that identifies a cockpit lamp that the fault caused to illuminate; (See Dixit column 13, line 17-26; “ The other data 1130 represents other information obtained from sensors or monitoring such as hardware and software BIT, system fault codes, warnings, cautions, advisories, meteorological, and biological (heart rate, etc. of the vehicle operator, e.g. pilot) data. Signals associated with this information are further processed by the A/D converter 1135, alarm detector 1140, and data conditioning 1145 which perform similar functions as explained above for the corresponding A/D converter 1115, alarm detector 1120, and data conditioning 1125, respectively.”; also see Dixit column 14-15, line 48-26; “The data fusion module 1170 analyzes the mapped sensor data within a time window that increments over time, either on a group basis for the sensor data included within a predetermined group of correlated sensors or on an individual basis where sensor data is not part of any group. The data fusion module 1170 makes a determination based on stored usage and operational norm information for each group/individual of sensor data of whether a tag should be associated with the group/individual sensor data, where the tag consists of one of a predetermined set of conditional codes. Each conditional code is mapped to and compared to similar fault code generated by the component. The conditional codes are then transmitted for further processing in MBR Engine 106 (FIG. 2), while the fault codes and conditional codes are stored in non-volatile memory. For example, a conditional code of “0″” indicates the sensed attributes of a component are within a normal range of operation; a “1” represents a component anomaly/failure; “2” represents a detected false positive that could be caused by the normal range of operation window for the sensor being so wide as to include an undesired operational condition; “3” represents a detected false negative that could be caused by a sensor failure or too narrow a window of normal range calibration for the sensor such that real anomaly supporting evidence misses the MBR Engine 106 detection cycle.
The sensor data along with the conditional codes are transmitted from the data fusion module 1170 to the diagnostic model-based reasoner engine 106 for further analysis. The data fusion module 1170 is implemented in software that runs on a microprocessor/computer capable of mapping the sensor data streams into correlated groups, comparing the respective sensor values against a dynamic normal window of operation having an upper and lower threshold, determining if an anomaly/fault associated with one sensor in a group is supported by a correlation of an anomaly/fault by another sensor in the group, and encoding the respective sensor data with an error code tag representative of the malfunction/fault determined.
FIG. 12 is a block diagram of an embodiment of the anomaly and degradation detector 1160 of FIG. 11. This detector is preferably implemented by software running on Graphical Processing Units (GPU) such as on a system-on-a-chip that has hundreds, if not thousands, of GPU processor cores available for processing. This supports the concurrent processing of the outputs from a large number of sensors.”; and see Dixit column 20, line 34-46; “This example illustrates a near-failing component. It must be repaired or replaced very soon, i.e. preferably upon return of associated vehicle to a depot. The baseline slope is increasing continuously without a downturn and sharply. If this is a critical component, vehicle safety is comprised if vehicle operations continue as is. The operator of the vehicle should return to base. The parameter data is tagged as a critical anomaly (for a critical component) with an alarm that will be processed immediately by the MBR engine 106 and information displayed to pilot or transmitted to ground based pilot (assuming the vehicle is an aircraft) for immediate action.”).).
Regarding claim 4 Dixit in view of Misenheimer and Martin teaches the method of claim 3, Dixit further teaches, wherein constructing the single fault message to include the fault code further includes: accessing a database or other file based on the fault code to identify a human-readable description of the fault; and providing the human-readable description of the fault in the single fault message; (See Dixit column 14-15, line 48-26; “The data fusion module 1170 analyzes the mapped sensor data within a time window that increments over time, either on a group basis for the sensor data included within a predetermined group of correlated sensors or on an individual basis where sensor data is not part of any group. The data fusion module 1170 makes a determination based on stored usage and operational norm information for each group/individual of sensor data of whether a tag should be associated with the group/individual sensor data, where the tag consists of one of a predetermined set of conditional codes. Each conditional code is mapped to and compared to similar fault code generated by the component. The conditional codes are then transmitted for further processing in MBR Engine 106 (FIG. 2), while the fault codes and conditional codes are stored in non-volatile memory. For example, a conditional code of “0″” indicates the sensed attributes of a component are within a normal range of operation; a “1” represents a component anomaly/failure; “2” represents a detected false positive that could be caused by the normal range of operation window for the sensor being so wide as to include an undesired operational condition; “3” represents a detected false negative that could be caused by a sensor failure or too narrow a window of normal range calibration for the sensor such that real anomaly supporting evidence misses the MBR Engine 106 detection cycle.
The sensor data along with the conditional codes are transmitted from the data fusion module 1170 to the diagnostic model-based reasoner engine 106 for further analysis. The data fusion module 1170 is implemented in software that runs on a microprocessor/computer capable of mapping the sensor data streams into correlated groups, comparing the respective sensor values against a dynamic normal window of operation having an upper and lower threshold, determining if an anomaly/fault associated with one sensor in a group is supported by a correlation of an anomaly/fault by another sensor in the group, and encoding the respective sensor data with an error code tag representative of the malfunction/fault determined.
FIG. 12 is a block diagram of an embodiment of the anomaly and degradation detector 1160 of FIG. 11. This detector is preferably implemented by software running on Graphical Processing Units (GPU) such as on a system-on-a-chip that has hundreds, if not thousands, of GPU processor cores available for processing. This supports the concurrent processing of the outputs from a large number of sensors.”; and see Dixit column 20, line 34-46; “This example illustrates a near-failing component. It must be repaired or replaced very soon, i.e. preferably upon return of associated vehicle to a depot. The baseline slope is increasing continuously without a downturn and sharply. If this is a critical component, vehicle safety is comprised if vehicle operations continue as is. The operator of the vehicle should return to base. The parameter data is tagged as a critical anomaly (for a critical component) with an alarm that will be processed immediately by the MBR engine 106 and information displayed to pilot or transmitted to ground based pilot (assuming the vehicle is an aircraft) for immediate action.”).).
Regarding claim 7 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit also teaches, further comprising, upon uploading the fault data from the ECU to the FST, automatically storing the uploaded fault data in a log file accessible by the computer, such that no additional user action is required for storing the uploaded fault data in the log file; (See Dixi column 6, line 44-54; “Recorded Data 126 includes log files, complete time-stamped state of the equipment, for example, snapshots, time-stamped fault/failure anomalies, detections, isolations, and any functional assessments on the isolations. The log files also include the MBR Engine software states (version number, failures & reboots) as well as identification of other aircraft software, their version number, if failed their state at failure, reboots of software, and functional assessments that lead to the failure. Collection of this data allows for the replay of diagnostics visualization of the actual events that occurred on the aircrafts,”).
Regarding claim 8 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit also teaches, further comprising: operating the engine while the aircraft is not in flight; (See Dixit column 38, line 6-10; “prognostics system goes into an autonomous mode and establishes various data socket links with the COMMS System 3605 which receives data from various aircrafts in flight or other in ground operations such as pre-flight testing, taxiing, and pre-launch.”);
converting, by the FST, the real-time data from raw units into human-readable engineering units; and displaying, by the GUI, the real-time data in the human-readable engineering units.; (See Dixit column 12 and 13, line 65-16; “…the digital output from different sensors may have a different number of digits or may have different ways of encoding values, data formatting converts these values into standardized data representations and formats (i.e., floats, integers, binary bits, etc.), as well as padding of digits of data as necessary. Also, because the sensor data rate (frequency) will typically differ for different sensors, converting each sensor data stream into a data stream having a common data rate, e.g. 50 Hz, makes it easier to integrate and process the information from such a variety of sensors and data branches. The data conditioning 1125 can be implemented on a microprocessor which can make formatting changes to provide conformity of the expression of the sensor values, and can also utilize a common clock to establish time synchronized signals into a single common data rate for the respective digital sensor outputs which may require either up-sampling or down-sampling of each sensor data stream to convert it to the target common data rate, e.g. 50 Hz.”; also See Dixit column 13, line 27-41; “The high-frequency sensors 1150 provide high data rate analog information and may for example include sensors such as, stress gauges, strain gauges, accelerometers, vibration sensors, transducers, torque gauges, acoustics sensors, optical sensors, etc. Such sensor outputs are converted to a digital signal representation by A/D converter 1155 and are input to the anomaly/degradation detector 1160 (see FIG. 12 and text for a more detailed description) in which functions to make determinations of whether each of the sensor data streams represents an anomaly and/or degradation condition is made. If one or both such conditions are determined to exist for a sensor value, the corresponding digital sensor data is output with embedded flag indication at output 1162 which contains real-time sensor information at a down sampled sensor date rate.”; also see Dixit column 10, line 32-39; “As explained above, GUI 114 contains a direct method to run the MBR model using recorded flight data 118 with Test Manager 116. FIG. 8 shows a representative Test Manager window with a New Test pop-up window 702. When Flight Replay Test 704 is selected, a suitable test simulated data or actual flight data file can be selected from options 706 and loaded into Test Manager 116 in FIG. 2.”).
Dixit does not teach but Misenheimer teaches, receiving, by the FST, real-time data acquired by the ECU from sensors configured to measure parameters of the engine; (See Misenheimer paragraph 0038; “…the aircraft system 100 may include a variety of sensors that may detect faults during a flight. In known systems, the faults may be identified and recorded by the ECU 200 or other components of the aircraft system 100 based on the sensor data…”);
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer to implement the real-time data acquired by the ECU from sensors. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 9 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit does not teach but Misenheimer teaches, further comprising preventing, by the FST, users from changing engine parameters except for a limited set of allowed parameters selected to avoid a need for a service visit while having no effect on safety or compliance; (See Misenheimer paragraph 0050; “…for steps of the checklist that comprise checking whether parameter values are within acceptable ranges, the checklist output module 252 may access the fault data 238b in the data storage component 236 and determine whether parameter values identified in the checklist are within acceptable ranges. Then, the checklist output module 252 may output an indication of the parameter values that are within acceptable ranges and a corresponding indication that those values do not need to be checked by the maintenance crew.”).
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer to implement changing a limited set of engine parameters. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 15 Dixit in view of Misenheimer and Martin teaches the method of claim 9, Dixit does not teach but Misenheimer teaches, wherein the limited set of allowed parameters includes a control for resetting an offset of a TPS (throttle position sensor) within the engine; (See Misenheimer paragraph 0021; “…A FADEC system generally functions by receiving a plurality of input variables of a current flight condition, including, but not limited to, air density, throttle lever position, engine temperature, engine pressure, and/or the like. The inputs are received, analyzed, and used to determine operating parameters such as, but not limited to, fuel flow, stator vane position, bleed valve position, and/or the like. The FADEC system may also control a start or a restart of the engines 140. The operating parameters of the FADEC can be modified by installing and/or updating software, such as the software that is distributed by the aircraft system 100 described herein. As such, the FADEC can be programmatically controlled to determine engine limitations, receive engine health reports, receive engine maintenance reports and/or the like to undertake certain measures and/or actions in certain conditions.”).
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer to implement changing a limited set of engine parameters. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 17 Dixit teaches a computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of a computerized apparatus; (See Dixit column 23, line 38-65; “FIG. 25 is a block diagram of an exemplary computing system 2500 for implementing the high frequency sensor analysis and integration with low frequency sensor data. Central to the computing system on system on chip (SOC) is microprocessor 2505 which may also include an arithmetic processing unit and/or a graphical processing unit (GPU). Alternatively, a GPU may be used by itself to process some of the computations/decisions of FIGS. 23 and 24, i.e. other than “graphical” information. A read-only memory (ROM) 2510 contains stored program instructions and data for use by the microprocessor 2505. A random-access memory (RAM) 2515 is also used by the microprocessor 2505 as a location where data may be stored and later read (the GPU also has its own RAM). A nonvolatile memory device 2520 is utilized to store instructions and/or data that will not be lost upon a loss of power to the computing system. An input/output (I/O) buffer 2525 is coupled to the microprocessor 2505 and facilitates the receipt of external data and the transmission of data from the microprocessor to external devices. Input devices 2530 represent conventional ways for a user to input information to the computing system, e.g. keyboard, mouse, etc. Output devices 2535 are conventional ways for information to be conveyed from the computer system to a user, e.g. video monitor, printer, etc. Depending on the number of parallel cores of the microprocessor 2505 (or the GPU), all cores provide sufficient computational power needed to process the data from all of the sensors in accordance with the steps explained above…”); cause the computerized apparatus to perform a method of facilitating diagnosis of anomalies in an engine of an aircraft; (See Dixit column 24, line 3-18; “As will be understood by those skilled in the art, the ROM 2510 and/or nonvolatile storage device 2520 will store an operating system by which the microprocessor 2505 is enabled to communicate information to and from the peripherals as shown. More specifically, sensor data is received through the I/O 2525, stored in memory, and then processed in accordance with stored program instructions to achieve the detection of anomalies and degradation of components associated with the respective sensors. Based on the analysis of the sensor data as explained above, those skilled in the art will know how to implement in the computer system software to determine different length moving averages such as discussed with regard to FIGS. 18-21 over consecutive moving data windows and compare the respective values of the different length moving averages with stored threshold values for a particular mode of operation.”);
the FST including a GUI (graphical user interface) having a set of UI (user interface) controls; and in response to a user operation of one or more of the UI controls; (See Dixit column 37, line 37-58; “FIGS. 36-37 provide a block diagram of an exemplary Fleet Level Prognostics System 3600 for which user selectable controls are provided by GUI 3601, as shown in more detail in FIG. 44. The exemplary GUI 3601 consists of a menu bar 3602 with a plurality of menus, a toolbar 3603 with a plurality of actionable button icons configured to initiate actions as indicated by the names in the tooltips 3604 shown when the mouse hovers over the button icons. The main screen body 3605 is a table that displays rows of all available aircraft where each row displays one aircraft as identified by tail number (aircraft from the fleet of like-type aircrafts are individually identified by their tail numbers). Each column in the table may display attributes particular to an aircraft tail number, such as, its serial number, tail number, mission capability (ground based, partially mission capable (PMC), non-mission capable (NMC) and fully mission capable (FMC)), it's zone, it's location, and other user defined attributes. Each displayed aircraft can be mouse selected to show its state, equipment assets, etc. The GUI has modes of operation which are role-based, i.e. each role pertains to different usage by personnel having different objectives.”).
Dixit does not teach but Misenheimer teaches, the method comprising: running an FST (field service tool), the ECU coupled to the engine and configured to record fault data generated in real time by the engine; (See Misenheimer paragraph 0038 and Figure 1-2; “…the aircraft system 100 may include a variety of sensors that may detect faults during a flight. In known systems, the faults may be identified and recorded by the ECU 200 or other components of the aircraft system 100 based on the sensor data…”);
(i) uploading the fault data from the ECU to the FST; (See Misenheimer paragraph 0044; “Referring still to FIG. 2…The fault detection module 242 may store information regarding detected faults as fault data 238b in the data storage component 236.”).
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer to implement the fault data acquired by the ECU from sensors. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Dixit does not teach but Martin teaches, and (ii) generating summary data from the uploaded fault data, the summary data providing a final state of faults described in the fault data; (See Martin paragraph 0080-0081 and 0085-0086;” Both the temporal precursor network 128 and the summary table 126 provide maintenance personnel, an operator of the aircraft 100, or other users with different manners in which to view and confidently assess potential causal chains of events. The temporal precursor network 128, for instance, visually depicts events that are statistically likely to have led to other events, as well as visually depicts which aircraft subsystems are experiencing more events than others. Using the temporal precursor network 128, a user can trace events between multiple different aircraft subsystems and/or electrical buses. As an example, seconds after a flight control subsystem fault code is signaled, fault codes in two other subsystems might be signaled. However, only one of those two subsequent fault codes might be statistically dependent on the flight control subsystem fault code, and the temporal precursor network 128 can depict that causal chain, thereby enabling a user to confidently eliminate the possibility that the other of the two subsequent fault codes is being caused by the flight control subsystem fault code. Other examples are possible as well.
Furthermore, the summary table 126 provides a concise summary of events having threshold-high statistical dependence. Using the summary table 126, a user can view and navigate through the summary table 126 to quickly search for and identify chains of events that are of interest, as well as confidently eliminate chains of events that, while shown to be statistically dependent, might not actually be casually related. The ability for a user to discern which chains of events are, in actuality, causal chains with a root cause can be even further assisted by the fault diagnostics computing device 106 indexing additional measurements in the summary table 126, examples of which will be discussed in more detail below.
In some implementations, the fault diagnostics computing device 106 can rank-order sequences of related events based on one or more factors, such as the values of statistical dependence. For example, if a first sequence of related events has a higher value of statistical dependence than a second sequence of related events, the first sequence of related events can be ranked higher than the second sequence of related events. The summary table 126 can include an indication of this ranking, such as by a number (e.g., 1, 2, 3, etc.) or other text, or can include the highest-ranked sequence of related events at a first, top row of the summary table 126 and lower-ranked sequences of related events in lower rows. Other examples are possible as well.
In some implementations, a user can select a row of the summary table 126, which can trigger the fault diagnostics computing device 106 to display supplemental information associated with the sequence of related events to which the selected row corresponds. For example, the fault diagnostics computing device 106 could be triggered to display the temporal precursor network 128 and highlight or otherwise emphasize the nodes in the temporal precursor network 128 that correspond to the selected sequence of related events. Additionally or alternatively, the fault diagnostics computing device 106 could be triggered to retrieve and display additional information about the aircraft subsystems and/or electrical buses involved in the sequence of related events, such as a visual indication (e.g., a diagram or map) of where the aircraft subsystems and/or electrical buses are within the aircraft 100 and/or other information. Other examples are possible as well.”).
Both Dixit and Martin are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Martin providing a final state of faults described in the fault data. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 18 Dixit in view of Misenheimer and Martin teaches the computer program product of claim 17, Dixit does not teach but Misenheimer teaches wherein the method further comprises preventing, by the FST, users from changing engine parameters except for a limited set of allowed parameters selected to avoid a need for a service visit while having no effect on safety or compliance; (See Misenheimer paragraph 0050; “…for steps of the checklist that comprise checking whether parameter values are within acceptable ranges, the checklist output module 252 may access the fault data 238b in the data storage component 236 and determine whether parameter values identified in the checklist are within acceptable ranges. Then, the checklist output module 252 may output an indication of the parameter values that are within acceptable ranges and a corresponding indication that those values do not need to be checked by the maintenance crew. As such, the number of steps of the checklist that need to be performed by the maintenance crew is reduced, thereby increasing the efficiency of the maintenance crew.”).
Both Dixit and Misenheimer are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Misenheimer to implement changing a limited set of engine parameters. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user by allow the user to receive more accurate aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Dixit (Patent No. US10964130B1) in view of Misenheimer (Patent No. US20220063839A1), Martin (Patent No. US20200047914A1) and Lee (Patent No. US20220135244A1).
Regarding claim 5 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit does not teach but Lee teaches, wherein said one or more of the UI controls includes at least one control for establishing a timespan over which fault messages are uploaded and/or displayed by the FST, said at least one control allowing user selection between (i) an interval of time since an immediately previous engine overhaul and (ii) an interval of time since fault messages in the ECU were last cleared; (See Lee paragraph 0030; “Maintenance personnel may then use the device(s) 110 to access the data associated with (or relevant to) the engine fault and accordingly perform maintenance on the engine 10 to troubleshoot malfunctions. As will be discussed further below, the data associated with the engine fault may be output at (e.g., rendered or otherwise displayed on) the device(s) 110 and maintenance personnel may access the data via a suitable input/output device, such as a video display and keyboard, associated with their device 110. In particular, the fault codes and associated indication messages contained in the engine fault data may be accessed and used to direct maintenance efforts. After carrying out appropriate corrective actions or responses to each fault code, the maintenance personnel may further update maintenance logs (or records) associated with the engine 10 and/or the aircraft 100. The maintenance record(s) may be indicative of date(s) and time(s) at which engine and/or aircraft maintenance has been performed.”).
Both Dixit and Lee are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Lee fault data decoding. No new functionality would arise from the combination and the combination would improve usability of Dixit by providing human-readable data to analyze. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 6 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit does not teach but Lee teaches, wherein the GUI of the FST further includes a set of controls for clearing faults stored in the ECU, and wherein the method further comprises (i) the GUI receiving a user operation to clear faults stored in the ECU and (ii) the FST thereafter clearing the faults in the ECU; (See Lee paragraph 0030; “Maintenance personnel may then use the device(s) 110 to access the data associated with (or relevant to) the engine fault and accordingly perform maintenance on the engine 10 to troubleshoot malfunctions. As will be discussed further below, the data associated with the engine fault may be output at (e.g., rendered or otherwise displayed on) the device(s) 110 and maintenance personnel may access the data via a suitable input/output device, such as a video display and keyboard, associated with their device 110. In particular, the fault codes and associated indication messages contained in the engine fault data may be accessed and used to direct maintenance efforts. After carrying out appropriate corrective actions or responses to each fault code, the maintenance personnel may further update maintenance logs (or records) associated with the engine 10 and/or the aircraft 100. The maintenance record(s) may be indicative of date(s) and time(s) at which engine and/or aircraft maintenance has been performed.”).
Both Dixit and Lee are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Lee set of controls. No new functionality would arise from the combination and the combination would improve usability of Dixit by including a set of controls to allow the workers to check and update maintenance logs. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 10-14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dixit (Patent No. US10964130B1) in view of Misenheimer (Patent No. US20220063839A1), Martin (Patent No. US20200047914A1) and Debelak (Patent No. US20150081194A1).
Regarding claim 10 Dixit in view of Misenheimer and Martin teaches the method of claim 9, Dixit does not teach but Debelak teaches, wherein the limited set of allowed parameters includes a setting in the ECU that records a total number of engine hours in which the engine has been in service; (See Debelak paragraph 0052; “…One embodiment provides that during the operation of the internal combustion engine 100 the operating data in the engine identification module 3 are updated be the electronic engine control unit 2. Operating data comprise, for example, the engine operating hours and the injector wear. Likewise, the engine identification module 3 can constitute a redundant data memory for the electronic engine control unit 2 in which the learned data values are stored.”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record a total number of engine hours. No new functionality would arise from the combination and the combination would improve usability of Dixit by allowing to identifying engine operating hours and the injector wear. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 11 Dixit in view of Misenheimer and Martin teaches the method of claim 10, Dixit does not teach but Debelak teaches, wherein the engine has a current total number of engine hours, and wherein the method further comprises: replacing the ECU with a new ECU; (See Debelak paragraph 0048; “…It is also conceivable that a specific number of starting attempts or a time limit is predefined. If, for example, after a defect the electronic engine control unit is replaced with a new one, the correct pairing of the engine control unit/internal combustion engine is ensured by means of the method…”); and operating the FST to update the total number of engine hours of the new ECU to match the current total number of engine hours of the engine; (See Debelak paragraph 0052; “…One embodiment provides that during the operation of the internal combustion engine 100 the operating data in the engine identification module 3 are updated be the electronic engine control unit 2. Operating data comprise, for example, the engine operating hours and the injector wear…”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record a total number of engine hours. No new functionality would arise from the combination and the combination would improve usability of Dixit by allowing to identifying engine operating hours and schedule the ECU replacement. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 12 Dixit in view of Misenheimer and Martin teaches the method of claim 9, Dixit does not teach but Debelak teaches, wherein the limited set of allowed parameters includes a setting in the ECU that records an engine serial number; (See Debelak paragraph 0034 and 0046; “…With respect to the control unit, for example the serial number, part number, design version and CCS can be stored…At least one microprocessor and a memory module, for example E.sup.2PROM for storing an engine identification and engine specifics are arranged in the engine identification module 3. Engine identification is to be understood as meaning the engine type, the engine part number and the serial number. Engine specifics are the individual properties of the internal combustion engine which are determined on an acceptance test bench...”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record engine serial number. No new functionality would arise from the combination and the combination would improve usability of Dixit by recording engine serial number to identify the correct engines for testing. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 13 Dixit in view of Misenheimer and Martin teaches the method of claim 12, Dixit does not teach but Debelak teaches, wherein the engine has a particular engine serial number, and wherein the method further comprises: replacing the ECU with a new ECU; (See Debelak paragraph 0048; “…It is also conceivable that a specific number of starting attempts or a time limit is predefined. If, for example, after a defect the electronic engine control unit is replaced with a new one, the correct pairing of the engine control unit/internal combustion engine is ensured by means of the method…”); and operating the FST to update a setting in the new ECU that records the engine serial number to match the particular engine serial number of the engine; (See Debelak paragraph 0052; “…One embodiment provides that during the operation of the internal combustion engine 100 the operating data in the engine identification module 3 are updated be the electronic engine control unit 2. Operating data comprise, for example, the engine operating hours and the injector wear…”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record engine serial number. No new functionality would arise from the combination and the combination would improve usability of Dixit by recording engine serial number to identify the correct engines for testing. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 14 Dixit in view of Misenheimer and Martin teaches the method of claim 12, Dixit does not teach but Debelak teaches, further comprising: moving the ECU from the engine to a second engine; (See Debelak paragraph 0048; “…It is also conceivable that a specific number of starting attempts or a time limit is predefined. If, for example, after a defect the electronic engine control unit is replaced with a new one, the correct pairing of the engine control unit/internal combustion engine is ensured by means of the method…”); and operating the FST to update the setting in the ECU that records the engine serial number such that the setting matches an engine serial number of the second engine; (See Debelak paragraph 0062 and Figure 4; “The sequence of the maintenance steps S1 to S4 can also be reversed if an upload of engine data from an engine 20 is necessary to the manufacturer region HH, this can be necessary, for example, within the scope of diagnostic maintenance or data protection. For this purpose, the non-volatile storage medium 30 can be operated, for example, as a data logger memory which continuously logs operating data or as a crash recorder memory of the maintenance software module 60. Maintenance proves advantageous in particular in the case of replacement of an engine or of a pool motor; in this case for saving analog data and operating data (upload) and transferring it into a new device (download). Both may also be necessary when a control unit is replaced in order to save software data in terms of uploading and transferring into a new device (downloading)…”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record engine serial number. No new functionality would arise from the combination and the combination would improve usability of Dixit by recording engine serial number to apply correct stings in the ECU. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 19 Dixit in view of Misenheimer and Martin teaches the method of claim 18, Dixit does not teach but Debelak teaches,, wherein the limited set of allowed parameters includes a setting in the ECU that records a total number of engine hours in which the engine has been in service; (See Debelak paragraph 0052; “…One embodiment provides that during the operation of the internal combustion engine 100 the operating data in the engine identification module 3 are updated be the electronic engine control unit 2. Operating data comprise, for example, the engine operating hours and the injector wear. Likewise, the engine identification module 3 can constitute a redundant data memory for the electronic engine control unit 2 in which the learned data values are stored.”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record a total number of engine hours. No new functionality would arise from the combination and the combination would improve usability of Dixit by allowing to identifying engine operating hours and the injector wear. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 20 Dixit in view of Misenheimer and Martin teaches the method of claim 9, Dixit does not teach but Debelak teaches, wherein the limited set of allowed parameters includes a setting in the ECU that records an engine serial number; (See Debelak paragraph 0034; “…With respect to the control unit, for example the serial number, part number, design version and CCS can be stored…”).
Both Dixit and Debelak are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Debelak record engine serial number. No new functionality would arise from the combination and the combination would improve usability of Dixit by recording engine serial number to apply correct stings in the ECU. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Dixit (Patent No. US10964130B1) in view of Misenheimer (Patent No. US20220063839A1) and Martin (Patent No. US20200047914A1).
Regarding claim 16 Dixit in view of Misenheimer and Martin teaches the method of claim 2, Dixit further teaches, the TLO being triggered in response to a fault condition in the aircraft that must be addressed within a determined amount of time before the aircraft is deemed non-flightworthy; (See Dixi column 21, line 39-49; “This procedure is also utilized for nominal data to reduce its output size. It is anticipated that this information will be used in both real time for prediction of a future state/value of the component and in a non-real time environment such as for maintenance analysis performed at a maintenance location. The output 1220 may be transmitted such as wirelessly to the ground control station and/or maintenance location or may be stored locally in non-volatile storage and later transferred from storage to the maintenance location or retrieved from vehicle by a connected hand held device running the PMD Viewer.”).
Dixit does not teach but Volponi teaches, wherein the GUI of the FST displays an amount of time remaining following a TLO (time-limited operation); (See Volponi paragraph 0066-0067 and Figure 9 and 10; “FIG. 9 …The GUI 900 can access multiple databases, such as data repository 120A-120N of FIG. 2, fleet event history 202 of FIG. 2, and other data sources (not depicted) for fault records and associated data. As shown in FIG. 9, a filter interface 902 can allow events to be accessed based on customer name,”).
Both Dixit and Volponi are in the same field of diagnosis of anomalies. It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to modify Dixit method of facilitating diagnosis of anomalies with Volponi to implement the GUI that is having UI controls. No new functionality would arise from the combination and the combination would improve usability of Dixit by allow the user to access and interpret aircraft engine fault data. Further, finding that one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LIDIA KWIATKOWSKA whose telephone number is (571)272-5161. The examiner can normally be reached Monday-Friday 8:00-5:00.
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, Scott A. Browne can be reached at (571) 270-0151. 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.
/L.K./Examiner, Art Unit 3666
/SCOTT A BROWNE/Supervisory Patent Examiner, Art Unit 3666