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 .
Status
This action is in response to the amendment filed on 7/24/2025. Claims 1-20 are pending. Claims 1, 7, 9, are amended. No claims have been added. No claims have been cancelled.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive. The applicant has argued the previous 101 stating “The claims present an improvement in the functioning of a computer under MPEP § 2106.04(d)(1). Claim 1 provides additional elements that include 1) a computer processor, 2) a first data element, 3) a first layer in a data hierarchy, 4) one or more layers, 5) clustering data elements, and 6) a display. The first data element, first layer in data hierarchy, one or more layers, and clustering data elements are all utilized to improve the functioning of a computing device. As Applicant indicates in the Original Specification "clustering data at a per-layer basis for hierarchical MRO job data provides a significant improvement in computational flexibility efficiency. Processing all job data together (e.g., for a given milestone or collection of milestones), as might be done on some solutions, would require a very large amount of memory and computational resources. Instead, clustering the job data on a per-layer basis ... allows for approximation of a critical path with significantly less memory and computational resources." Original Specification Para. [0028] (emphasis added). As a result, the specification explicitly indicates that the additional elements provide an improvement in computational flexibility efficiency of the computer processor.” Applicant’s arguments are not persuasive. It appears as though the applicant is arguing that clustering of data for processing would be an improvement to the efficiency of the computer processor. Although grouping of data may lead to the data being processing quicker. This would not be an improvement to the technology, this would merely be an improvement to abstract idea. Computers are a known tool for processing data in an efficient manner. The grouping of like data would at most arguably be an improvement to the abstract idea and not an improvement to the technology. Applicant has not shown that the claimed components operate in an unconventional manner. The specification's statement that clustering at a per-layer basis saves memory and computation does not demonstrate that the computer itself functions differently the language merely describes the benefit of the abstract idea. Generic computers performing their basic functions (processing, storing, displaying) do not make a claim eligible.
The applicant has cited multiple court cases specifically Enfish, McRO, Visual Memory, Finjan, and SRI in the arguments. However, the fact patterns of the cases do that follow the fact pattern of applicant’s claimed invention. For example in reference to Enfish, the applicant’s claims are not directed to a self-referential table for a computer database, in McRO, the claims where directed to automatic lip synchronization and facial expression animation, in Visual Memory LLC the claims were directed to an enhanced computer memory system, In Finjan the claims were directed to virus scanning, in SRI, the claims were directed to detecting suspicious activity by using network monitors and analyzing network packets. The claims that were cited include fact patterns that involve self-referential tables, automatic lip synchronization, an enhanced computer memory system, virus scanning, and detecting suspicious activity. In each case cited by Applicant, the Federal Circuit found eligibility because the claims recited a specific technical implementation that improved the computer, network, memory, or software architecture itself not merely the efficiency of an abstract process running on a generic computer. Here, the claims recite generic computer components (processor, display) performing abstract data organization functions (clustering, layering) at a high level of generality. Applicant’s invention at most is directed to grouping data for processing. Applicant’s claims are not analogous with the cited court cases. The first step of the Alice framework “asks whether the focus of the claims is on the specific asserted improvement in [the relevant technology] or, instead, on a process that qualifies as an ‘abstract idea’ for which computers are invoked merely as a tool.” Applicant’s invention merely uses a computer as a tool.
The applicant has argued “In addition, claim 1 recites "a first layer in a data hierarchy leads to a second layer and a third layer; selecting a second data element from the first layer comprising data relating to maintenance of a vehicle; generating a second plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in the second layer and the third layer in the data hierarchy that depend from the first layer; identifying a second one or more jobs relating to maintenance of the vehicle in each of the second plurality of clusters, based on at least one of: (i) a start date for the respective job or (ii) an end date for the respective job; using the first plurality of clusters and the second plurality of clusters to identify longest data paths within each of the first layer, the second layer, and the third layer based on the identified one or more jobs, each respective longest data path comprising a plurality of jobs." As such, Applicant presents in the claim how during approximating of a critical path related to maintenance results in a significant improvement in computational flexibility efficiency with significantly less memory and computational resources compared to previous methods used to determine a critical path.” The examiner respectfully disagrees. The portions that the applicant has argued are not considered by the examiner as additional elements, are in fact not additional elements. Data is not considered an additional element. Upon reading the applicant’s it appears that layers as claimed are merely levels in a workflow diagram, this would also not be considered an additional element. And lastly clustering data is known in the art to mean to organize similar data points into groups, known as clusters, based on their shared characteristics or attributes. At most applicant has a specific way of organizing data, however, a piece of data reorganized would not be considered an additional element. The claim language cited by Applicant selecting data elements, generating clusters, identifying jobs, and finding longest data paths within hierarchical layers describes steps for organizing and analyzing data. These are quintessentially abstract operations: organizing information into hierarchies, grouping related data, and finding optimal paths through a dataset are all mental processes or mathematical concepts that could be performed by a human with pen and paper. The fact that these steps are performed on a computer does not make them patent-eligible.
The applicant has argued the claims in view of Finjan. The examiner respectfully disagrees. In Finjan Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299 (Fed. Cir. 2018), the claimed invention involves a method of virus scanning that scans an application program, generates a security profile identifying any potentially suspicious code in the program, and links the security profile to the application program. The claims were held patent eligible because the court concluded that the claimed method recites specific steps that accomplish a result that realizes an improvement in computer functionality. In particular, the method generates a security profile that identifies both hostile and potentially hostile operations, and can protect the user against both previously unknown viruses and "obfuscated code." This is an improvement over traditional virus scanning, which only recognized the presence of previously- identified viruses. The method also enables more flexible virus filtering and greater user customization. In the instant application the applicant does not claim an improvement over traditional virus scanning in conventional industry practice therefore the arguments and association are not viewed as analogous. The inquiry as to whether claims are directed to an abstract idea “often turns on whether the claims focus on ‘the specific asserted improvement in computer capabilities ... or, instead, on a process that qualifies as an “abstract idea” for which computers are invoked merely as a tool.’” Finjan, Inc. v. Blue Coat Sys., Inc., 879 F.3d 1299, 1303 (Fed. Cir. 2018) (quoting Enfish, LLC, 822 F.3d at 1335–36). Even considering a generically recited computer of the method these are invoked merely as tools performing the generic computer functions of selecting, generating, identifying, approximating, and displaying data. Applicant’s arguments are not found persuasive. In Finjan, the technical improvement was intrinsic to the claims themselves that the security profile was inherently a technical construct tied to how the computer handled downloaded content. Here, the vehicle maintenance context is simply the field to which the abstract data organization and analysis is applied. Limiting an abstract idea to a particular technological environment or industry does not make it patent-eligible.
The “Applicant additionally points the Examiner to Ex parte Desjardins, Appeal 2024-000567, Application No. 16/319,040 (PTAB Apps. Rev. Sept. 26, 2025), that explains "claims directed to an improvement in the functioning of a computer, or an improvement to other technology or technical field are patent eligible. See MPEP §§ 2106.04(d)(1) and 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1339 (Fed. Cir. 2016) and McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1315 (Fed. Cir. 2016))." As also explained by the PTAB in Exparte Desjardins, "an assertion [of the improvement] in the Specification alone is insufficient to support a patent eligibility determination, absent a subsequent determination that the claim itself reflects the disclosed improvement. See MPEP §2106.05(a) (citing Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1316 (Fed. Cir. 2016))." The PTAB in Ex parte Desjardins reasoned that the claims at issue reflected improvements to training of an artificial intelligence (AI) model in part because claimed improvement allowed AI systems to "us[e] less of their storage capacity" and enables "reduced system complexity," and based thereon, the ARP found that the claims integrate an abstract idea into a practical application. Here the claimed subject matter results in a significant improvement in computational flexibility efficiency with significantly less memory and computational resources compared to previous methods used to determine a critical path and is similarly eligible as a practical application of an integrated abstract idea.” The examine respectfully disagrees. The argued improvement specifically the reduced memory usage and computational efficiency is asserted in the specification but the claim language itself does not recite any specific mechanism, structure, or technical implementation that achieves this improvement. The claims recite functional steps (clustering, identifying, generating paths) without specifying how the computer implements these steps in a manner that concretely reduces memory usage or computational load. In Desjardins eligibility was found after determining that the claim language itself reflected the disclosed improvement i.e., that the specific technical steps recited in the claims were the mechanism by which the AI system achieved reduced storage and complexity. The PTAB did not find eligibility based solely on the specification's assertion of improvement. The Examiner finds that the claims do not reflect the alleged improvement in their language. The steps of clustering data elements by layer, identifying jobs by dates, and identifying longest paths do not, recite any specific technical mechanism that reduces memory usage or computational load in an unconventional way. The improvement remains an assertion in the specification but not claimed by the claims.
The applicant has argued “Additionally, Applicant respectfully requests Examiner to consider Applicant's arguments in view of the recently issued Deputy Commissioner for Patents Kim's Memorandum of Aug. 4, 2025 entitled "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101" (herein after "the Kim Memo"). The Memo encourages Examiners to consider "the claim as a whole." Kim Memo Pg. 3. The Patent Office instructs that "the additional limitations should not be evaluated in a vacuum, completely separate from the recited judicial exception. Instead, the analysis should take into consideration all claim limitations and how these limitations interact and impact each other when evaluating whether the exception is integrated into a practical application." Id. Pgs. 3-4. Clearly, the extensive steps claimed when not evaluated in a vacuum show Applicant is claiming in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the alleged exception. See MPEP § 2106(e).” The examiner respectfully disagrees. The Applicant argues that the claims go meaningfully beyond merely linking the abstract idea to a particular technological environment. No matter how specific the abstract idea is, the specificity of the abstract idea itself is not the same as integration into a practical application. The claims specify how the abstract data organization and path analysis is performed (layer-by-layer, cluster-by-cluster) but do not specify how the computer itself is improved or operates unconventionally as a result. Under the Kim Memorandum's own framework, additional limitations that "merely include instructions to apply the exception" or that reflect "the abstract idea itself" do not establish a practical application and that is precisely what the additional limitations here do.
The applicant has argued “In sum, the Kim Memo appears to be addressing the exact current situation where an Applicant has a technology related to an improvement within a computer - e.g., a technology that improves computational flexibility efficiency with significantly less memory and computational resources compared to previous methods used to determine a critical path. Thus, Applicant respectfully requests reconsideration of the rejection in light of the Kim Memo.” The examiner respectfully disagrees. The claim must itself reflect the improvement. The applicant has not identified, nor can the Examiner find, specific claim language that recites how the computer achieves reduced memory usage or improved computational flexibility at a technical level. The Kim Memorandum does not relax this requirement it however reinforces it by instructing Examiners to look at what the claim limitations actually recite and how the limitations interact.
The applicant has argued “To this end, the Kim Memo also reminds Examiners that if it is a "close call" as to whether a claim is eligible, the Examiner should only make a rejection when it is more likely than not (i.e., more than 50%) that the claim is ineligible under 35 U.S.C. 101. Kim Memo Pg. 5. A rejection of a claim should not be made simply because an Examiner is uncertain as to the claim's eligibility. Id. In all, the claims clearly present an improvement to a computer, and the Specification is tailored to explain how and why the improvement to the computer is achieved. The claims are eligible and the rejection under 35 U.S.C. § 101 should be withdrawn.” The examiner respectfully disagrees. The Kim Memorandum's "close call" guidance is directed to situations where an Examiner is genuinely uncertain as to whether a claim is eligible and cannot determine, one way or the other, whether the abstract idea is integrated into a practical application. That is not the situation here. The Examiner has conducted a thorough analysis of the claims under the two-step Alice/Mayo framework, considered all of Applicant's arguments, reviewed the cited case law and PTAB decisions. Based on this comprehensive analysis, the Examiner is confident that the claims are directed to an abstract idea without meaningful integration into a practical application. The rejection is not based on uncertainty, it is based on a well-reasoned determination that the claims fail to recite a specific technical implementation that would constitute a practical application under 101.
The applicant has argued “All dependent claims depend on an independent claim and are eligible for at least the same reasons. Additionally, dependent claim 7 recites generating a plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in the second layer and the third layer in the data hierarchy that depend from the first layer, further comprises identifying the second layer in the data hierarchy that depends from the first layer, identifying the third layer in the data hierarchy that depends from the second layer and generating a respective cluster for each of the third layer and the second layer. In this manner claim 7 provides additional specific steps related to how a significant improvement in computational flexibility efficiency with significantly less memory and computational resources compared to previous methods used to determine a critical path is accomplished.” The examiner respectfully disagrees. These additional steps merely elaborate on the hierarchical data organization scheme already recited in the independent claim. They describe the logical structure of the data hierarchy in greater detail specifically which layers depend from which other layers but do not recite any specific technical mechanism by which the computer identifies or processes these layers in an unconventional way. Identifying hierarchical relationships between data layers is itself an abstract organizational concept, and generating clusters does not make the claims any less abstract.
The previous 101 rejection is maintained and updated in view of applicant’s amendments.
The applicant has amended the claims and has argued the claimed limitations in view of the previous 102 rejection. The previous search was updated and the previous rejection was also updated. As can be seen in at least claim 1, the applicant is merely using a general purpose computer for processing the steps of the invention. Although the applicant uses the term layer and data hierarchy that is a way of organizing data in a structured, tree-like format, with each level representing a different level of detail or abstraction. There is nothing in the claims related to “computer architecture.” Computer architecture is the design of a computer system, including how its components are organized and how they interact to process data and execute instructions. The applicant is merely claiming at most clustering and layering of the data, this is not related to or analogous to computer architecture. Applicant’s arguments are not found persuasive. The previous prior art rejections are maintained and updated in view of applicant’s amendments. Applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because the claim(s) as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. The claim(s) is/are directed to the abstract idea of generating data related to maintaining a vehicle and displaying steps for maintaining the vehicle. The claimed invention is directed to an abstract idea without significantly more.
Step 2A Prong 1
The claim(s) recite(s) (mathematical relationships/formulas, mental process or certain methods of organizing human activity). Specifically the independent claims recite:
(a) mental process: as drafted, the claim recites the limitation of generating data elements, identifying jobs relating to the maintenance of a vehicle, generating paths which comprise jobs, selecting data elements, generating clusters of data elements, identifying one or more jobs, identify longest data paths, approximating a critical path, and displaying the steps for maintaining a vehicle, which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “a processor” nothing in the claims precludes the determining step from practically being performed in the human mind. For example, but for the processor language, the claim encompasses the user manually identifying and displaying maintenance for a vehicle. The mere nominal recitation of a generic processing device does not take the claim limitation out of the mental processes grouping. For example claim 1 does not claim or require the use of any type of technology. The claimed limitation is a mental process.
(c) certain methods of organizing human activity: The claim as a whole recites a method of organizing human activity. The claimed invention is a method that allows for users to determine the maintenance steps for the claimed vehicle. The claimed tasks amounts to “managing personal behavior — by giving explicit instructions to the user,” i.e., subject matter falling within the “[c]ertain methods of organizing human activity” grouping of abstract ideas (Final Act. 6). See 2019 Revised Guidance, 84 Fed. Reg. at 52. Thus, the claim recites an abstract idea.
Step 2A Prong 2
Independent claims 1, 11, and 16 do not integrate the judicial exception into a practical application. Claim 1 is a method comprising “a computer processor of a system, a display of the system, steps for maintaining the vehicle determined by the critical path.” Claim 12 is “a non-transitory computer-readable medium… computer program code… one or more computer processors.” Claim 16 is a system “a computer processor; and a memory having instructions stored thereon which, when executed on the computer processor.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, generate, identify, or display data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f). Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 6-10, 14, 15, 19, 20, further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which does not integrate the judicial exception into a practical application.
Dependent claim 2 introduces the additional element of “wherein the vehicle is an aircraft and maintenance of the vehicle relates to maintenance, repair, and overhaul of the aircraft.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 3-5, 13, 18 introduces the additional element of a “graphical user interface (UI).” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claims 12, 17, introduces the additional element of a “wherein the vehicle is an aircraft and maintenance of the vehicle” and “graphical user interface (UI).” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Thus the problem the claimed invention is directed to answering the question based on generated and displaying data for maintaining a vehicle. This is not a technical or technological problem but is rather in the realm of business or maintenance management and therefore an abstract idea.
Step 2B
Independent claims 1, 11, and 16 do not comprise anything significantly more than the judicial exception. As can be seen above with respect to Step 2A, Prong 2, Claim 1 is a method comprising “a computer processor of a system, a display of the system, steps for maintaining the vehicle determined by the critical path.” Claim 12 is “a non-transitory computer-readable medium… computer program code… one or more computer processors.” Claim 16 is a system “a computer processor; and a memory having instructions stored thereon which, when executed on the computer processor.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Dependent claims 6-10, 14, 15, 19, 20, further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which is not anything significantly more than the judicial exception.
Dependent claim 2 introduces the additional element of “wherein the vehicle is an aircraft and maintenance of the vehicle relates to maintenance, repair, and overhaul of the aircraft.” The claim employs generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. This type of generally linking is not anything significantly more than the judicial exception. See MPEP 2106.05(h).
Dependent claims 3-5, 13, 18 introduces the additional element of a “graphical user interface (UI).” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Dependent claims 12, 17, introduces the additional element of a “wherein the vehicle is an aircraft and maintenance of the vehicle” and “graphical user interface (UI).” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Therefore based on the above analysis as conducted based on MPEP 2106 from the United States Patent and Trademark Office the claims are viewed as a court recognized abstract idea, are viewed as a judicial exception, does not integrate the claims into a practical application, does not provide significantly more, and does not provide an inventive concept, therefore the claims are ineligible.
Accordingly, claims 1-20 are rejected under 35 USC 101.
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.
Claim(s) 1-7, 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sinex (US 20020010532 A1) in view of Fleiner et al. (US 20230107048 A1) in further view of Cao et al. (US 20230195986 A1).
Regarding claim 1, Sinex teaches a method, comprising: selecting, with a computer processor, a first data element from a first layer in a data hierarchy comprising data relating to maintenance of a vehicle including job data (¶ 14, The present invention is an aircraft maintenance tracking system for tracking aircraft maintenance required on an aircraft. The aircraft maintenance tracking system includes means for tracking accumulated usage data of the aircraft, means for receiving a list of routine tasks required to be performed on the aircraft, means for tracking task accomplishment data for each routine task, means for determining a maintenance due point for each routine task, means for identifying maintenance due tasks as those routine tasks for which a difference between the maintenance due point of the routine task and the accumulated usage data of the aircraft is less than a user-defined critical value, and means for reporting maintenance due tasks. ¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 117, According to the present invention, a system and method are provided for dynamically managing, in real-time, aircraft maintenance requirements. The system and method of the present invention brings a distributed computing framework of using client/server and Internet technologies to the field of aircraft maintenance, allowing end-users to react quickly to the dynamics of everyday events. The system and method of the present invention take advantage of a process of using the Internet browser technology to deliver real-time distributed software products for the aircraft maintenance industry. ¶ 31, 47, 52, 71, 115, Fig. 4-7, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
generating, with a computer processor, a plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in one or more layers in the data hierarchy that depend from the first layer (¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 33-34, MRB program manager 22 takes aircraft maintenance requirements 14 and creates a maintenance program for aircraft 12. MRB program manager 22 allows an airline operator to organize all of the maintenance tasks into logical groups based on frequency, type, and an airline's operational/scheduling preferences 20. As a result, MRB program manager 22 provides a customized maintenance schedule that allows the airline to not only keep track of each maintenance task individually, but also carry out the maintenance tasks much more efficiently. ¶ 117, According to the present invention, a system and method are provided for dynamically managing, in real-time, aircraft maintenance requirements. The system and method of the present invention brings a distributed computing framework of using client/server and Internet technologies to the field of aircraft maintenance, allowing end-users to react quickly to the dynamics of everyday events. The system and method of the present invention take advantage of a process of using the Internet browser technology to deliver real-time distributed software products for the aircraft maintenance industry. ¶ 36-37, 40, 47, 52, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
identifying, with a computer processor, one or more jobs relating to maintenance of the vehicle in each of the plurality of clusters, based on at least one of: (i) a start date for the respective job or (ii) an end date for the respective job (¶ 39, FIG. 3 illustrates example graphical user interface (GUI) 50 used in conjunction with MRB program manager 22 of system 10. In the example of FIG. 3, the tasks of a test aircraft are organized into a plurality of checks including A checks 52. Other types of checks not illustrated in FIG. 3 are C checks, eight-year checks, flight cycle checks, and special checks. In GUI 50, column 54 lists the name of each check. Column 56 details the number of tasks included within each of the plurality of checks. Column 58 details the forecasted hours required to complete each task. Column 60 lists the form number of each task. Columns 62 list the time control points (or interval periods at which each of the plurality of checks is to be performed). The time control point may be listed as a specific number of flight hours, flight cycles or months. For each of the plurality of checks, buttons are provided to allow an airline operator to revise the checks ("Revise" button in column 64), view the tasks within the check ("View" button in column 66), or generate a checklist of the tasks within the check ("Checklist" button in column 68). ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 117, According to the present invention, a system and method are provided for dynamically managing, in real-time, aircraft maintenance requirements. The system and method of the present invention brings a distributed computing framework of using client/server and Internet technologies to the field of aircraft maintenance, allowing end-users to react quickly to the dynamics of everyday events. The system and method of the present invention take advantage of a process of using the Internet browser technology to deliver real-time distributed software products for the aircraft maintenance industry. ¶ 52, 57-58, 73, 109);
generating, with a computer processor, a path for each of the plurality of clusters based on the identified one or more jobs, each respective path comprising a plurality of jobs (¶ 8, To minimize the number of days the aircraft is removed from operation, a maintenance plan must be developed to assign and monitor the completion of tasks. The development of such a plan is made more difficult by the identification of non-routine tasks during the maintenance, back orders on parts which preclude the completion of certain tasks and the failure to complete timely critical path tasks (those which prevent subsequent tasks from being completed). No computer-based method exists to dynamically prepare such a maintenance plan using dynamically changing information, such as available labor hours, sequence and dependency of tasks, and the addition of non-routine tasks. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 117, According to the present invention, a system and method are provided for dynamically managing, in real-time, aircraft maintenance requirements. The system and method of the present invention brings a distributed computing framework of using client/server and Internet technologies to the field of aircraft maintenance, allowing end-users to react quickly to the dynamics of everyday events. The system and method of the present invention take advantage of a process of using the Internet browser technology to deliver real-time distributed software products for the aircraft maintenance industry. ¶ 52, 78, 83, 87);
selecting a second data element from a layer in a data hierarchy comprising data relating to maintenance of a vehicle (¶ 14, The present invention is an aircraft maintenance tracking system for tracking aircraft maintenance required on an aircraft. The aircraft maintenance tracking system includes means for tracking accumulated usage data of the aircraft, means for receiving a list of routine tasks required to be performed on the aircraft, means for tracking task accomplishment data for each routine task, means for determining a maintenance due point for each routine task, means for identifying maintenance due tasks as those routine tasks for which a difference between the maintenance due point of the routine task and the accumulated usage data of the aircraft is less than a user-defined critical value, and means for reporting maintenance due tasks. ¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 31, 47, 71, 115, Fig. 4-7, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
generating a second plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in one or more layers in the data hierarchy that depend from the first layer (¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 33-34, MRB program manager 22 takes aircraft maintenance requirements 14 and creates a maintenance program for aircraft 12. MRB program manager 22 allows an airline operator to organize all of the maintenance tasks into logical groups based on frequency, type, and an airline's operational/scheduling preferences 20. As a result, MRB program manager 22 provides a customized maintenance schedule that allows the airline to not only keep track of each maintenance task individually, but also carry out the maintenance tasks much more efficiently. ¶ 78, In GUI 250, the user can select button 262 ("Work Card") to access a particular task's printable work card for distribution to the crew members. Alternatively, crew members can print their own work cards when checking into DAMP manager 26 to see what tasks have been assigned to them (preferably presented in sequential order of how they should be completed). Not shown in FIG. 11a, GUI 250 can also provide a revise button to allow the user to access a task revision screen for a particular task. ¶ 36-37, 40, 47, 75, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
identifying a second one or more jobs relating to maintenance of the vehicle in each of the second plurality of clusters, based on at least one of: (i) a start date for the respective job or (ii) an end date for the respective job (¶ 39, FIG. 3 illustrates example graphical user interface (GUI) 50 used in conjunction with MRB program manager 22 of system 10. In the example of FIG. 3, the tasks of a test aircraft are organized into a plurality of checks including A checks 52. Other types of checks not illustrated in FIG. 3 are C checks, eight-year checks, flight cycle checks, and special checks. In GUI 50, column 54 lists the name of each check. Column 56 details the number of tasks included within each of the plurality of checks. Column 58 details the forecasted hours required to complete each task. Column 60 lists the form number of each task. Columns 62 list the time control points (or interval periods at which each of the plurality of checks is to be performed). The time control point may be listed as a specific number of flight hours, flight cycles or months. For each of the plurality of checks, buttons are provided to allow an airline operator to revise the checks ("Revise" button in column 64), view the tasks within the check ("View" button in column 66), or generate a checklist of the tasks within the check ("Checklist" button in column 68). ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 57-58, 73, 109);
generating a path for each of the second plurality of clusters based on the identified one or more jobs, each respective path comprising a plurality of jobs (¶ 8, To minimize the number of days the aircraft is removed from operation, a maintenance plan must be developed to assign and monitor the completion of tasks. The development of such a plan is made more difficult by the identification of non-routine tasks during the maintenance, back orders on parts which preclude the completion of certain tasks and the failure to complete timely critical path tasks (those which prevent subsequent tasks from being completed). No computer-based method exists to dynamically prepare such a maintenance plan using dynamically changing information, such as available labor hours, sequence and dependency of tasks, and the addition of non-routine tasks. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 78, 83, 87);
approximating, with a computer processor, a critical path relating to maintenance of the vehicle (¶ 95, Section 414 of GUT 410 lists all tasks having more hours applied to them than last estimated. Column 416 lists the task number and description of each task, column 418 lists the estimated number of hours to complete that task, column 420 lists the actual hours accrued (so far) to that task, column 422 provides a box in which the crew lead can supply a new estimate of the time remaining on that task, and column 424 provides the crew numbers of crews assigned to that task. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 117, According to the present invention, a system and method are provided for dynamically managing, in real-time, aircraft maintenance requirements. The system and method of the present invention brings a distributed computing framework of using client/server and Internet technologies to the field of aircraft maintenance, allowing end-users to react quickly to the dynamics of everyday events. The system and method of the present invention take advantage of a process of using the Internet browser technology to deliver real-time distributed software products for the aircraft maintenance industry. ¶ 52, 85, 48-49.);
and displaying, on a display of the system, steps for maintaining the vehicle determined by the critical path (¶ 64-65, An example implementation of DAMP manager 26 is illustrated in FIGS. 9-17. FIG. 9 illustrates example graphical user interface (GUI) 190 used in conjunction with DAMP manager 26. GUI 190 is an example status screen of system 10. Screen 190 shows in real-time the current maintenance status of aircraft 12. Section 192 of GUI 190 displays the tail number of aircraft 12 (US248 in this example) and user name (Melling). Section 192 also includes pull-down menus 194. Each pull-down menu 194 provides additional levels of access in DAMP manager 26. Thus, a crew member would be provided with only one pull-down menu, while senior management would be provided with several pull-down menus. In this example, user Melling is provided with five pull-down menus. In addition, section 192 includes button 196 ("Log Off") which allows the user to log off of DAMP manager 26. ¶ 77, To assign a crew member to a task, the user simply checks box 258 under the name of the crew member to whom the task is assigned. Once the task is assigned, the crew member may sign onto the task, at which time the clock starts running on that crew member to collect the total amount of time spent on that task. If a crew member has not logged into DAMP manager 26, a visual cue 260, such as a red square drawn around his corresponding check box 258, may be displayed to instantly alert the user of which employees are absent, whereas a green box could be used to indicate that a crew member is awaiting task assignment. A similar visual cue could be provided if the crew member is in training. This visual signal is helpful because tasks cannot be assigned to crew member who are absent or in training. ¶ 88-89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 68, 79-81).
Sinex does not specifically teach wherein the first layer in a data hierarchy leads to a second layer and a third layer.
However, Fleiner teaches wherein the first layer in a data hierarchy leads to a second layer and a third layer (Fig. 1, 2, 4, 6-11, disclose various workflow diagrams with multi levels, ¶ 5-7, disclose upstream and down stream clusters, ¶ 44-45, disclose levels and layers of the hierarchy. ¶ 62).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform wherein the first layer in a data hierarchy leads to a second layer and a third layer as claimed, as taught/suggested by Fleiner. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to management systems involving the grouping of resource information clusters. One of ordinary skill in the art would have recognized that applying the known technique of Fleiner would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Fleiner to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such leveled features into similar systems. Further, applying wherein the first layer in a data hierarchy leads to a second layer and a third layer as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to encourage specialization and isolation of data.
Sinex does not specifically teach identifying the longest path data.
However, Cao teaches using the first plurality of clusters and the second plurality of clusters to identify longest data paths within each of the first layer, the second layer, and the third layer based on the identified one or more jobs, each respective longest data path comprising a plurality of jobs (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.);
approximating, with the computer processor, a critical path relating to maintenance of the vehicle by combining the longest data path (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform identifying the longest path data, as taught/suggested by Cao. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to critical path analysis. One of ordinary skill in the art would have recognized that applying the known technique of Cao would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cao to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such longest path features into similar systems. Further, applying identifying the longest path data as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to determine the critical path, specifically the specific sequence of operations, dependencies, or physical connections that takes the maximum amount of time, distance, or effort to complete within each layer.
Regarding claim 2, Sinex teaches wherein the vehicle is an aircraft and maintenance of the vehicle relates to maintenance, repair, and overhaul of the aircraft (¶ 9, Airlines can further save costs by escalating, when permissible, the intervals at which tasks are performed. Based upon reliability data collected by an airline during maintenance of their own aircrafts, the FAA may allow the airline to more favorably escalate tasks beyond the requirements of the MRB document (i.e, require the task to be performed at longer intervals). Thus, if a task to inspect a particular part is performed as required every six months, and the part is consistently (throughout the fleet) in good condition, the task may be escalated to one a year (or some other interval). Such escalations of tasks can significantly affect the time and cost of maintaining an airline's fleet of aircraft. A reliability program thus modifies, for a particular airline only, an aircraft's MRB document by changing the intervals required between overhauls, inspections and checks of aircraft equipment. Guidance on reliability program elements is listed in Advisory Circular (AC) 120-17, Maintenance Program Management Through Reliability Methods, as amended, the Airline/Manufacturer Maintenance Program Planning Document, MSG-2/3, and/or Maintenance Tasks. ¶ 97-99, Reliability manager 28 also collects all the information regarding rotable parts (those parts which can be repaired) including when they were installed, when they were removed, what were the non-routine tasks performed in their life cycle, when they came in for line maintenance checks and their parent-child relationship with other rotable parts. Reliability manager 28 allows airlines to evaluate whether or not a rotable part is actually meeting the manufacturer's predicted life limits. In addition, reliability manager 28 analyzes the maintenance program produced by MRB program manager 22 and the maintenance logbook produced by tracking manager 24 to analyze the reliability of each rotable part. If a rotable part never has a deficiency within the suggested inspection interval, the airline may modify its maintenance program based upon the reliability data produced by reliability manager 28. ¶ 100-101, A reliability program establishes the time limitations or standards for determining intervals between overhauls, inspections and checks of aircraft equipment. Guidance on reliability program elements is listed in Advisory Circular (AC) 120-17, Maintenance Program Management Through Reliability Methods, as amended, the Airline/Manufacturer Maintenance Program Planning Document, MSG-2/3, and/or Maintenance Tasks. A reliability program typically collects reliability data from sources including unscheduled removals of parts, confirmed failures of parts, pilot reports, sampling inspections, shop findings, functional checks, bench checks, service difficulty reports, mechanical interruption summaries and other sources the airline considers appropriate. ¶ 14, 24).
Regarding claim 3, Sinex teaches maintaining the vehicle using the approximated critical path, comprising: generating a first graphical user interface (UI) for displaying the steps for maintaining the vehicle determined by the critical path (¶ 63-64, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 87, GUT 320 presents the following information about a selected task: task card number 322, work order number 324, aircraft tail number 326, aircraft serial number 328, accrued flight hours 330, accrued cycles 332, and date 334. GUT 320 also presents a series of steps 336 which provide instructions on how the task is to be performed. In the example illustrated, there are two steps (A and B), with step B having two sub-steps (1 and 2). Columns 338 and 339 indicate what skill types should perform each step. GUT 320 is configured according to the standards of the airline operator for which DAMP manager 26 is designed. ¶ 76-78, In GUI 250, the user can select button 262 ("Work Card") to access a particular task's printable work card for distribution to the crew members. Alternatively, crew members can print their own work cards when checking into DAMP manager 26 to see what tasks have been assigned to them (preferably presented in sequential order of how they should be completed). Not shown in FIG. 11a, GUI 250 can also provide a revise button to allow the user to access a task revision screen for a particular task. ¶ 49, Fig. 4-7).
Regarding claim 4, Sinex teaches wherein maintaining the vehicle using the approximated critical path further comprises: generating a second graphical UI displaying a plurality of jobs in the critical path and a plurality of employees suitable to work on one or more of the plurality of jobs (¶ 51-52, In the heavy maintenance environment, each individual maintenance team member, from mechanic to top-tier management, has a specific job to complete. An ideal maintenance plan for an aircraft would take into account the knowledge and experience of all employees working to maintain the aircraft. DAMP manager 26, in a sense, allows each employee to contribute to the overall maintenance production plan. In the DAMP system, each employee is given the tools they need to do their job. Each employee has access to computer screens containing information relevant to the completion of their own job. In using the system, each employee enters information into the system in response to the computer screens presented to the employee. That information is processed by DAMP manager 26, with the end result being that the mechanics always know exactly what tasks on which to work. Additionally, DAMP manager 26 creates a history of events to enable production coordinators to identify what works and what does not work in the maintenance plan. ¶ 57-59, At step 172, mechanics sign into DAMP manager 26 to retrieve their task cards. When the mechanic signs in and accepts a first task, the clock starts running on the first task, and when the employee signs onto a second task, the clock stops running on the first task. DAMP manager 26 uses this information to monitor the amount of time spent completing each task. Later, the actual times can be compared to the forecasted times to determine if the maintenance program is on schedule. This information can also be accumulated over a number of checks, and used by crew leads to determine which employees are most efficient at each task. ¶ 111-113, In addition, personnel training manager 32 compares personnel training records 16 with FAA training requirements 18 to monitor which tasks each employee is qualified to perform. By integrating personnel training manager 32 with DAMP manager 26, crew leads can quickly ascertain which mechanics have the training necessary to perform specific tasks, thereby ensuring that only qualified mechanics are assigned to tasks. The FAA has very strict standards regarding the training required of aircraft mechanics. Before a mechanic can independently perform a task, the FAA requires that the mechanic have either been previously supervised performing the task or been specifically trained for that task. ¶ 114-116, Fig. 17-18, 4-7).
Regarding claim 5, Sinex teaches scheduling a first employee of the plurality of employees to work on a first job of the plurality of jobs based on an input to the second graphical UI (¶ 71, Flow chart 232 shows, in real-time, a list of all tasks that are required to be completed during the maintenance check of aircraft 12. Time scale 240 chronologically displays the number of days in the check. In flow chart 232, a width of task bar 242 indicates the time duration of a specific task, while the location of task bar 242 indicates its placement in the overall schedule. As flow chart 232 is dynamically updated, completed tasks will be represented by their actual duration and placement, while incomplete tasks will be represented by their planned duration and placement. ¶ 73-75, FIG. 11 a illustrates example graphical user interface (GUI) 250 used in conjunction with DAMP manager 26. GUI 250 is an example crew assignment screen listing tasks assigned to a specific crew working on aircraft 12. Again, section 252 displays information about aircraft 12 and the user, as well as pull-down menus and a log off button. In this example, user "Roche" has access to only two pull-down menus (compared with five in FIG. 9), indicating that user "Roche" has less access to DAMP manager 26 than user "Melling" of FIG. 9. ¶ 77-79, To assign a crew member to a task, the user simply checks box 258 under the name of the crew member to whom the task is assigned. Once the task is assigned, the crew member may sign onto the task, at which time the clock starts running on that crew member to collect the total amount of time spent on that task. If a crew member has not logged into DAMP manager 26, a visual cue 260, such as a red square drawn around his corresponding check box 258, may be displayed to instantly alert the user of which employees are absent, whereas a green box could be used to indicate that a crew member is awaiting task assignment. A similar visual cue could be provided if the crew member is in training. This visual signal is helpful because tasks cannot be assigned to crew member who are absent or in training. ¶ 51, 57-58, 113-116).
Regarding claim 6, Sinex teaches wherein identifying one or more jobs relating to maintenance of the vehicle in each of the plurality of clusters further comprises: determining that each of the identified one or more jobs comprises at least one of: (i) an earliest start date for the respective cluster or (ii) a latest end date for the respective cluster (¶ 57-58, At step 172, mechanics sign into DAMP manager 26 to retrieve their task cards. When the mechanic signs in and accepts a first task, the clock starts running on the first task, and when the employee signs onto a second task, the clock stops running on the first task. DAMP manager 26 uses this information to monitor the amount of time spent completing each task. Later, the actual times can be compared to the forecasted times to determine if the maintenance program is on schedule. This information can also be accumulated over a number of checks, and used by crew leads to determine which employees are most efficient at each task. ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 49).
Regarding claim 7, Sinex teaches wherein generating a plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in the second layer and the third layer in the data hierarchy that depend from the first layer, further comprises: identifying a second layer in the data hierarchy that depends from the first layer; and generating a respective cluster for each of the third layer and the second layer (¶ 49, FIG. 7 illustrates example graphical user interface (GUI) 140 used in conjunction with tracking manager 24. GUI 140 is an example "Tasks Due" screen 140 of system 10. Screen 140 shows, in real-time, a list of tasks due within a user-specified range of dates, hours, or cycles. The user can enter a number of hours 142, a number of cycles 144, or a date 146, and click on button 148 ("Retrieve Records") to retrieve a list of tasks due within the entered range. The resulting screen lists the task descriptions 150, the date last completed 152 (as well as the flight hours and flight cycles accrued by that completion date), the time limits 154 (or time control point), and the time remaining 156 for each task. The time remaining column will preferably provide a graphical cue to the user as to which tasks are overdue, which are nearing their due date, and which are not yet due. Such a graphical cue could be color-coding the remaining time information. In the example of FIG. 7, cells could be colored red to signify overdue tasks (not shown), cells 158 could be colored yellow to signify task which will be due within the user-specified range, and cells 159 could be colored white to signify tasks which are not yet due and outside the user-specified range. As the tasks are completed, the historical record for each task is updated in real-time to the current status. Screen 140 assists the user in developing the best plan and work order for an aircraft to insure that tasks are completed in a timely manner. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 40, 54-55, 68, 98-99, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set)).
Sinex does not specifically teach wherein the first layer in a data hierarchy leads to a second layer and a third layer.
However, Fleiner teaches identifying a third layer in the data hierarchy that depends from the second layer (Fig. 1, 2, 4, 6-11, disclose various workflow diagrams with multi levels, ¶ 5-7, disclose upstream and down stream clusters, ¶ 44-45, disclose levels and layers of the hierarchy. ¶ 62).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform identifying a third layer in the data hierarchy that depends from the second layer, as taught/suggested by Fleiner. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to management systems involving the grouping of resource information clusters. One of ordinary skill in the art would have recognized that applying the known technique of Fleiner would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Fleiner to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such leveled features into similar systems. Further, applying identifying a third layer in the data hierarchy that depends from the second layer would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to encourage specialization and isolation of data.
Regarding claims 9, Sinex teaches approximating a critical path relating to maintenance of the vehicle based on connecting a first path relating to the second plurality of clusters with a second path relating to the plurality of clusters (¶ 95, Section 414 of GUT 410 lists all tasks having more hours applied to them than last estimated. Column 416 lists the task number and description of each task, column 418 lists the estimated number of hours to complete that task, column 420 lists the actual hours accrued (so far) to that task, column 422 provides a box in which the crew lead can supply a new estimate of the time remaining on that task, and column 424 provides the crew numbers of crews assigned to that task. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 85, 48-49.).
Regarding claim 10, Sinex teaches generating the first path for the first data element based on the plurality of clusters; and generating the second path for the second data element based on the second plurality of clusters (¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 33-34, MRB program manager 22 takes aircraft maintenance requirements 14 and creates a maintenance program for aircraft 12. MRB program manager 22 allows an airline operator to organize all of the maintenance tasks into logical groups based on frequency, type, and an airline's operational/scheduling preferences 20. As a result, MRB program manager 22 provides a customized maintenance schedule that allows the airline to not only keep track of each maintenance task individually, but also carry out the maintenance tasks much more efficiently. ¶ 78, In GUI 250, the user can select button 262 ("Work Card") to access a particular task's printable work card for distribution to the crew members. Alternatively, crew members can print their own work cards when checking into DAMP manager 26 to see what tasks have been assigned to them (preferably presented in sequential order of how they should be completed). Not shown in FIG. 11a, GUI 250 can also provide a revise button to allow the user to access a task revision screen for a particular task. ¶ 39, FIG. 3 illustrates example graphical user interface (GUI) 50 used in conjunction with MRB program manager 22 of system 10. In the example of FIG. 3, the tasks of a test aircraft are organized into a plurality of checks including A checks 52. Other types of checks not illustrated in FIG. 3 are C checks, eight-year checks, flight cycle checks, and special checks. In GUI 50, column 54 lists the name of each check. Column 56 details the number of tasks included within each of the plurality of checks. Column 58 details the forecasted hours required to complete each task. Column 60 lists the form number of each task. Columns 62 list the time control points (or interval periods at which each of the plurality of checks is to be performed). The time control point may be listed as a specific number of flight hours, flight cycles or months. For each of the plurality of checks, buttons are provided to allow an airline operator to revise the checks ("Revise" button in column 64), view the tasks within the check ("View" button in column 66), or generate a checklist of the tasks within the check ("Checklist" button in column 68). ¶ 36-37, 40, 47, 75).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sinex (US 20020010532 A1) in view of Fleiner et al. (US 20230107048 A1) in further view of Cao et al. (US 20230195986 A1) in further view of Nathan et al. (US 20200184739 A1).
Regarding claim 8, Sinex teaches the limitations of claims 7, Sinex does not specifically teach the specific depending layers as claimed in claim 8.
However, Nathan teaches wherein the respective cluster for the third layer is generated before the respective cluster for the second layer based on the third layer depending from the second layer (¶ 41, In an exemplary embodiment, a maintenance activity 22 is configured in a Blockchain Network by a set of rules 12 and maintenance data and maintenance tasks stored in a blockchain digital ledger 15. That is, an on-demand “app” 60 is connected through the cloud or integrated in an application on an on-board avionics system such as the FMS (or for that matter integrated in a replacement avionic part). The aircraft flying hours, the activities of the checks and dependency among these checks are stored in the digital ledger 15 of the Blockchain Network 10. For example, the checks can be configured as rules 12 for executing a maintenance activity 22. Based on the list of activities for a particular maintenance plan, a sequence of maintenance activities 22 is sent (from the Blockchain Network 10) to the mobile device 40 for display to the user by use of the app 60 of the mobile client 50. The sequence and the critical path of the activity is provided by an order of execution and assignment to maintenance engineers with a time of start and end. This information is stored in a digital ledger of the Blockchain Network and the ledger maintenance activity can be checked by individual maintenance engineer. This process will ensure the completeness of all checks for each activity and the execution of the checks in a right order for each activity to allow for proper validation and compliance. ¶ 46-47, FIG. 2 illustrates a diagram 200 of an application for processing checks of scheduled activities, sequence/order of activities, assignment of activities with time stamps of the aircraft for use with the blockchain maintenance network in accordance with an embodiment. The application (hereinafter “app”) 210 may be configured (i.e. its processing and analysis parts) in a number of ways to reside in part on a mobile device or a server or in the cloud and is coupled to the avionics equipment 240 or ground server 245 to collect usage data for maintenance of the aircraft by accessing a database of aircraft activities 220 to check activities of the aircraft and by checking aircraft flying hours and a calendar checking from a flying hours/calendar database 230. The app 210 may include or be coupled to an analysis engine 215 and processing engine (i.e. orchestrator) 260 for checking the activities, the schedules, sequences and the assignments given to aircraft personnel with time stamps from the blockchain Network 270 stored in the digital ledger 280. In various embodiments, the activities are checked in a schedule to a maintenance personnel performing the activity in accordance with a time stamp from the Blockchain Ledger at 262. That is each activity performed by a maintenance personnel should be performed to a corresponding time stamp. Next, at 264, the maintenance activities are checked in an order in accordance with time stamps of a Blockchain ledger. At 268, the activities when assigned to maintenance personnel are checked by time stamps to ensure that the assignment orders are correct. The analysis engine 250 may use various algorithmic solutions, more specifically algorithms to identify tasks for compliance with activities by a schedule, a given sequence or order, and assignment by the time stamp data from the blockchain ledger. ¶ 60, 63, 9-11).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform the depending layers as claimed, as taught/suggested by Nathan. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to aviation management systems for aircraft maintenance. One of ordinary skill in the art would have recognized that applying the known technique of Nathan would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Nathan to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such layered features into similar systems. Further, applying the depending layers as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to preserve the importance of the sequence of tasks.
Claim(s) 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sinex (US 20020010532 A1) in view of Cao et al. (US 20230195986 A1).
Regarding claim 11, Sinex teaches a non-transitory computer-readable medium containing computer program code that, when executed by operation of one or more computer processors, performs operations comprising (¶ 23-25, FIG. 1 is a simplified block diagram of system 10 in accord with the present invention for dynamically managing, in real-time, aircraft maintenance requirements. System 10 interfaces with a plurality of aircraft, such as aircraft 12, corresponding aircraft maintenance requirements, such as aircraft maintenance requirements 14, personnel training records 16, FAA training requirements 18, and user preferences 20. System 10 is a multiple component system which includes Maintenance Review Board (MRB) program manager 22, aircraft tracking manager 24, Dynamic Aircraft Maintenance Production (DAMP) manager 26, reliability manager 28, electronic publications manager 30 and personnel training manager 32. ¶ 39-40, 48-49, 123);
selecting a first data element from a first layer in a data hierarchy comprising data relating to maintenance of a vehicle including job data (¶ 14, The present invention is an aircraft maintenance tracking system for tracking aircraft maintenance required on an aircraft. The aircraft maintenance tracking system includes means for tracking accumulated usage data of the aircraft, means for receiving a list of routine tasks required to be performed on the aircraft, means for tracking task accomplishment data for each routine task, means for determining a maintenance due point for each routine task, means for identifying maintenance due tasks as those routine tasks for which a difference between the maintenance due point of the routine task and the accumulated usage data of the aircraft is less than a user-defined critical value, and means for reporting maintenance due tasks. ¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 31, 47, 71, 115, Fig. 4-7, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
generating a plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in one or more layers in the data hierarchy that depend from the first layer (¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 33-34, MRB program manager 22 takes aircraft maintenance requirements 14 and creates a maintenance program for aircraft 12. MRB program manager 22 allows an airline operator to organize all of the maintenance tasks into logical groups based on frequency, type, and an airline's operational/scheduling preferences 20. As a result, MRB program manager 22 provides a customized maintenance schedule that allows the airline to not only keep track of each maintenance task individually, but also carry out the maintenance tasks much more efficiently. ¶ 36-37, 40, 47, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
identifying one or more jobs relating to maintenance of the vehicle in each of the plurality of clusters, based on at least one of: (i) a start date for the respective job or (ii) an end date for the respective job (¶ 39, FIG. 3 illustrates example graphical user interface (GUI) 50 used in conjunction with MRB program manager 22 of system 10. In the example of FIG. 3, the tasks of a test aircraft are organized into a plurality of checks including A checks 52. Other types of checks not illustrated in FIG. 3 are C checks, eight-year checks, flight cycle checks, and special checks. In GUI 50, column 54 lists the name of each check. Column 56 details the number of tasks included within each of the plurality of checks. Column 58 details the forecasted hours required to complete each task. Column 60 lists the form number of each task. Columns 62 list the time control points (or interval periods at which each of the plurality of checks is to be performed). The time control point may be listed as a specific number of flight hours, flight cycles or months. For each of the plurality of checks, buttons are provided to allow an airline operator to revise the checks ("Revise" button in column 64), view the tasks within the check ("View" button in column 66), or generate a checklist of the tasks within the check ("Checklist" button in column 68). ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 57-58, 73, 109);
using the plurality of clusters within the first layer based on the identified one or more jobs, each respective path comprising a plurality of jobs (¶ 8, To minimize the number of days the aircraft is removed from operation, a maintenance plan must be developed to assign and monitor the completion of tasks. The development of such a plan is made more difficult by the identification of non-routine tasks during the maintenance, back orders on parts which preclude the completion of certain tasks and the failure to complete timely critical path tasks (those which prevent subsequent tasks from being completed). No computer-based method exists to dynamically prepare such a maintenance plan using dynamically changing information, such as available labor hours, sequence and dependency of tasks, and the addition of non-routine tasks. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 78, 83, 87);
approximating a critical path relating to maintenance of the vehicle based on the generated paths for each of the plurality of clusters (¶ 95, Section 414 of GUT 410 lists all tasks having more hours applied to them than last estimated. Column 416 lists the task number and description of each task, column 418 lists the estimated number of hours to complete that task, column 420 lists the actual hours accrued (so far) to that task, column 422 provides a box in which the crew lead can supply a new estimate of the time remaining on that task, and column 424 provides the crew numbers of crews assigned to that task. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 85, 48-49.);
and displaying steps for maintaining the vehicle determined by the critical path (¶ 64-65, An example implementation of DAMP manager 26 is illustrated in FIGS. 9-17. FIG. 9 illustrates example graphical user interface (GUI) 190 used in conjunction with DAMP manager 26. GUI 190 is an example status screen of system 10. Screen 190 shows in real-time the current maintenance status of aircraft 12. Section 192 of GUI 190 displays the tail number of aircraft 12 (US248 in this example) and user name (Melling). Section 192 also includes pull-down menus 194. Each pull-down menu 194 provides additional levels of access in DAMP manager 26. Thus, a crew member would be provided with only one pull-down menu, while senior management would be provided with several pull-down menus. In this example, user Melling is provided with five pull-down menus. In addition, section 192 includes button 196 ("Log Off") which allows the user to log off of DAMP manager 26. ¶ 77, To assign a crew member to a task, the user simply checks box 258 under the name of the crew member to whom the task is assigned. Once the task is assigned, the crew member may sign onto the task, at which time the clock starts running on that crew member to collect the total amount of time spent on that task. If a crew member has not logged into DAMP manager 26, a visual cue 260, such as a red square drawn around his corresponding check box 258, may be displayed to instantly alert the user of which employees are absent, whereas a green box could be used to indicate that a crew member is awaiting task assignment. A similar visual cue could be provided if the crew member is in training. This visual signal is helpful because tasks cannot be assigned to crew member who are absent or in training. ¶ 88-89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 79-81).
Sinex does not specifically teach identifying the longest path data.
However, Cao teaches using the plurality of clusters to identify the longest data paths within the first layer (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.);
approximating a critical path … based on the generated paths for each of the plurality of clusters using the longest data paths (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform identifying the longest path data, as taught/suggested by Cao. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to critical path analysis. One of ordinary skill in the art would have recognized that applying the known technique of Cao would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cao to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such longest path features into similar systems. Further, applying identifying the longest path data as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to determine the critical path, specifically the specific sequence of operations, dependencies, or physical connections that takes the maximum amount of time, distance, or effort to complete within each layer.
Regarding claim 12, 17, Sinex teaches wherein the vehicle is an aircraft and maintenance of the vehicle relates to maintenance, repair, and overhaul of the aircraft (¶ 9, Airlines can further save costs by escalating, when permissible, the intervals at which tasks are performed. Based upon reliability data collected by an airline during maintenance of their own aircrafts, the FAA may allow the airline to more favorably escalate tasks beyond the requirements of the MRB document (i.e, require the task to be performed at longer intervals). Thus, if a task to inspect a particular part is performed as required every six months, and the part is consistently (throughout the fleet) in good condition, the task may be escalated to one a year (or some other interval). Such escalations of tasks can significantly affect the time and cost of maintaining an airline's fleet of aircraft. A reliability program thus modifies, for a particular airline only, an aircraft's MRB document by changing the intervals required between overhauls, inspections and checks of aircraft equipment. Guidance on reliability program elements is listed in Advisory Circular (AC) 120-17, Maintenance Program Management Through Reliability Methods, as amended, the Airline/Manufacturer Maintenance Program Planning Document, MSG-2/3, and/or Maintenance Tasks. ¶ 97-99, Reliability manager 28 also collects all the information regarding rotable parts (those parts which can be repaired) including when they were installed, when they were removed, what were the non-routine tasks performed in their life cycle, when they came in for line maintenance checks and their parent-child relationship with other rotable parts. Reliability manager 28 allows airlines to evaluate whether or not a rotable part is actually meeting the manufacturer's predicted life limits. In addition, reliability manager 28 analyzes the maintenance program produced by MRB program manager 22 and the maintenance logbook produced by tracking manager 24 to analyze the reliability of each rotable part. If a rotable part never has a deficiency within the suggested inspection interval, the airline may modify its maintenance program based upon the reliability data produced by reliability manager 28. ¶ 100-101, A reliability program establishes the time limitations or standards for determining intervals between overhauls, inspections and checks of aircraft equipment. Guidance on reliability program elements is listed in Advisory Circular (AC) 120-17, Maintenance Program Management Through Reliability Methods, as amended, the Airline/Manufacturer Maintenance Program Planning Document, MSG-2/3, and/or Maintenance Tasks. A reliability program typically collects reliability data from sources including unscheduled removals of parts, confirmed failures of parts, pilot reports, sampling inspections, shop findings, functional checks, bench checks, service difficulty reports, mechanical interruption summaries and other sources the airline considers appropriate. ¶ 14, 24);
the operations further comprising: maintaining the vehicle using the approximated critical path generating a first graphical user interface (UI) for displaying the steps for maintaining the vehicle determined by the critical path (¶ 63-64, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 87, GUT 320 presents the following information about a selected task: task card number 322, work order number 324, aircraft tail number 326, aircraft serial number 328, accrued flight hours 330, accrued cycles 332, and date 334. GUT 320 also presents a series of steps 336 which provide instructions on how the task is to be performed. In the example illustrated, there are two steps (A and B), with step B having two sub-steps (1 and 2). Columns 338 and 339 indicate what skill types should perform each step. GUT 320 is configured according to the standards of the airline operator for which DAMP manager 26 is designed. ¶ 76-78, In GUI 250, the user can select button 262 ("Work Card") to access a particular task's printable work card for distribution to the crew members. Alternatively, crew members can print their own work cards when checking into DAMP manager 26 to see what tasks have been assigned to them (preferably presented in sequential order of how they should be completed). Not shown in FIG. 11a, GUI 250 can also provide a revise button to allow the user to access a task revision screen for a particular task. ¶ 49, Fig. 4-7).
Regarding claim 13, 18, Sinex teaches wherein maintaining the vehicle using the approximated critical path further comprises: generating a second graphical UI displaying a plurality of jobs in the critical path and a plurality of employees suitable to work on one or more of the plurality of jobs (¶ 51-52, In the heavy maintenance environment, each individual maintenance team member, from mechanic to top-tier management, has a specific job to complete. An ideal maintenance plan for an aircraft would take into account the knowledge and experience of all employees working to maintain the aircraft. DAMP manager 26, in a sense, allows each employee to contribute to the overall maintenance production plan. In the DAMP system, each employee is given the tools they need to do their job. Each employee has access to computer screens containing information relevant to the completion of their own job. In using the system, each employee enters information into the system in response to the computer screens presented to the employee. That information is processed by DAMP manager 26, with the end result being that the mechanics always know exactly what tasks on which to work. Additionally, DAMP manager 26 creates a history of events to enable production coordinators to identify what works and what does not work in the maintenance plan. ¶ 57-59, At step 172, mechanics sign into DAMP manager 26 to retrieve their task cards. When the mechanic signs in and accepts a first task, the clock starts running on the first task, and when the employee signs onto a second task, the clock stops running on the first task. DAMP manager 26 uses this information to monitor the amount of time spent completing each task. Later, the actual times can be compared to the forecasted times to determine if the maintenance program is on schedule. This information can also be accumulated over a number of checks, and used by crew leads to determine which employees are most efficient at each task. ¶ 111-113, In addition, personnel training manager 32 compares personnel training records 16 with FAA training requirements 18 to monitor which tasks each employee is qualified to perform. By integrating personnel training manager 32 with DAMP manager 26, crew leads can quickly ascertain which mechanics have the training necessary to perform specific tasks, thereby ensuring that only qualified mechanics are assigned to tasks. The FAA has very strict standards regarding the training required of aircraft mechanics. Before a mechanic can independently perform a task, the FAA requires that the mechanic have either been previously supervised performing the task or been specifically trained for that task. ¶ 114-116, Fig. 17-18, 4-7);
and scheduling a first employee of the plurality of employees to work on a first job of the plurality of jobs based on an input to the second graphical UI (¶ 71, Flow chart 232 shows, in real-time, a list of all tasks that are required to be completed during the maintenance check of aircraft 12. Time scale 240 chronologically displays the number of days in the check. In flow chart 232, a width of task bar 242 indicates the time duration of a specific task, while the location of task bar 242 indicates its placement in the overall schedule. As flow chart 232 is dynamically updated, completed tasks will be represented by their actual duration and placement, while incomplete tasks will be represented by their planned duration and placement. ¶ 73-75, FIG. 11 a illustrates example graphical user interface (GUI) 250 used in conjunction with DAMP manager 26. GUI 250 is an example crew assignment screen listing tasks assigned to a specific crew working on aircraft 12. Again, section 252 displays information about aircraft 12 and the user, as well as pull-down menus and a log off button. In this example, user "Roche" has access to only two pull-down menus (compared with five in FIG. 9), indicating that user "Roche" has less access to DAMP manager 26 than user "Melling" of FIG. 9. ¶ 77-79, To assign a crew member to a task, the user simply checks box 258 under the name of the crew member to whom the task is assigned. Once the task is assigned, the crew member may sign onto the task, at which time the clock starts running on that crew member to collect the total amount of time spent on that task. If a crew member has not logged into DAMP manager 26, a visual cue 260, such as a red square drawn around his corresponding check box 258, may be displayed to instantly alert the user of which employees are absent, whereas a green box could be used to indicate that a crew member is awaiting task assignment. A similar visual cue could be provided if the crew member is in training. This visual signal is helpful because tasks cannot be assigned to crew member who are absent or in training. ¶ 51, 57-58, 113-116).
Regarding claim 14, 19, Sinex teaches wherein identifying one or more jobs relating to maintenance of the vehicle in each of the plurality of clusters further comprises: determining that each of the identified one or more jobs comprises at least one of: (i) an earliest start date for the respective cluster or (ii) a latest end date for the respective cluster (¶ 57-58, At step 172, mechanics sign into DAMP manager 26 to retrieve their task cards. When the mechanic signs in and accepts a first task, the clock starts running on the first task, and when the employee signs onto a second task, the clock stops running on the first task. DAMP manager 26 uses this information to monitor the amount of time spent completing each task. Later, the actual times can be compared to the forecasted times to determine if the maintenance program is on schedule. This information can also be accumulated over a number of checks, and used by crew leads to determine which employees are most efficient at each task. ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 49).
Regarding claims 15, 20, Sinex teaches approximating a critical path relating to maintenance of the vehicle based on connecting a first path relating to the second plurality of clusters with a second path relating to the plurality of clusters (¶ 95, Section 414 of GUT 410 lists all tasks having more hours applied to them than last estimated. Column 416 lists the task number and description of each task, column 418 lists the estimated number of hours to complete that task, column 420 lists the actual hours accrued (so far) to that task, column 422 provides a box in which the crew lead can supply a new estimate of the time remaining on that task, and column 424 provides the crew numbers of crews assigned to that task. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 85, 48-49.).
Regarding claim 16, Sinex teaches a computer processor; and a memory having instructions stored thereon which, when executed on the computer processor, performs operations comprising (¶ 23-25, FIG. 1 is a simplified block diagram of system 10 in accord with the present invention for dynamically managing, in real-time, aircraft maintenance requirements. System 10 interfaces with a plurality of aircraft, such as aircraft 12, corresponding aircraft maintenance requirements, such as aircraft maintenance requirements 14, personnel training records 16, FAA training requirements 18, and user preferences 20. System 10 is a multiple component system which includes Maintenance Review Board (MRB) program manager 22, aircraft tracking manager 24, Dynamic Aircraft Maintenance Production (DAMP) manager 26, reliability manager 28, electronic publications manager 30 and personnel training manager 32. ¶ 39-40, 48-49, 123);
selecting a first data element from a first layer in a data hierarchy comprising data relating to maintenance of a vehicle including job data (¶ 14, The present invention is an aircraft maintenance tracking system for tracking aircraft maintenance required on an aircraft. The aircraft maintenance tracking system includes means for tracking accumulated usage data of the aircraft, means for receiving a list of routine tasks required to be performed on the aircraft, means for tracking task accomplishment data for each routine task, means for determining a maintenance due point for each routine task, means for identifying maintenance due tasks as those routine tasks for which a difference between the maintenance due point of the routine task and the accumulated usage data of the aircraft is less than a user-defined critical value, and means for reporting maintenance due tasks. ¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 31, 47, 71, 115, Fig. 4-7, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
generating a plurality of clusters of data elements relating to maintenance of the vehicle, based on clustering data elements in one or more layers in the data hierarchy that depend from the first layer (¶ 24, From aircraft maintenance requirements 14, MRB program manager 22 extracts maintenance tasks required for aircraft 12 and, for each task, time control points (or limits by which the task must be performed). MRB program manager uses this information to allow an airline operator to organize these tasks into logical groups which can be simultaneously performed. MRB program manager 22 provides the maintenance plan, along with the corresponding time control points, to aircraft tracking manager 24. ¶ 33-34, MRB program manager 22 takes aircraft maintenance requirements 14 and creates a maintenance program for aircraft 12. MRB program manager 22 allows an airline operator to organize all of the maintenance tasks into logical groups based on frequency, type, and an airline's operational/scheduling preferences 20. As a result, MRB program manager 22 provides a customized maintenance schedule that allows the airline to not only keep track of each maintenance task individually, but also carry out the maintenance tasks much more efficiently. ¶ 36-37, 40, 47, data layers are different levels or stages of data processing within a data architecture, and data clusters to be groups of data points (typically formed through a clustering algorithm that identify patterns in the data set));
identifying one or more jobs relating to maintenance of the vehicle in each of the plurality of clusters, based on at least one of: (i) a start date for the respective job or (ii) an end date for the respective job (¶ 39, FIG. 3 illustrates example graphical user interface (GUI) 50 used in conjunction with MRB program manager 22 of system 10. In the example of FIG. 3, the tasks of a test aircraft are organized into a plurality of checks including A checks 52. Other types of checks not illustrated in FIG. 3 are C checks, eight-year checks, flight cycle checks, and special checks. In GUI 50, column 54 lists the name of each check. Column 56 details the number of tasks included within each of the plurality of checks. Column 58 details the forecasted hours required to complete each task. Column 60 lists the form number of each task. Columns 62 list the time control points (or interval periods at which each of the plurality of checks is to be performed). The time control point may be listed as a specific number of flight hours, flight cycles or months. For each of the plurality of checks, buttons are provided to allow an airline operator to revise the checks ("Revise" button in column 64), view the tasks within the check ("View" button in column 66), or generate a checklist of the tasks within the check ("Checklist" button in column 68). ¶ 89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 57-58, 73, 109);
using the plurality of clusters to identify paths within the first layer based on the identified one or more jobs, each respective path comprising a plurality of jobs (¶ 8, To minimize the number of days the aircraft is removed from operation, a maintenance plan must be developed to assign and monitor the completion of tasks. The development of such a plan is made more difficult by the identification of non-routine tasks during the maintenance, back orders on parts which preclude the completion of certain tasks and the failure to complete timely critical path tasks (those which prevent subsequent tasks from being completed). No computer-based method exists to dynamically prepare such a maintenance plan using dynamically changing information, such as available labor hours, sequence and dependency of tasks, and the addition of non-routine tasks. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 78, 83, 87);
approximating a critical path relating to maintenance of the vehicle based on the generated paths for each of the plurality of clusters (¶ 95, Section 414 of GUT 410 lists all tasks having more hours applied to them than last estimated. Column 416 lists the task number and description of each task, column 418 lists the estimated number of hours to complete that task, column 420 lists the actual hours accrued (so far) to that task, column 422 provides a box in which the crew lead can supply a new estimate of the time remaining on that task, and column 424 provides the crew numbers of crews assigned to that task. ¶ 63, DAMP manager 26 constantly updates the overall completion time and tracks critical path jobs which will prevent subsequent jobs from being done. Thus, steps 164-180 are repeated until the maintenance check on the aircraft is complete. ¶ 55, At step 166, DAMP manager 26 generates a proposed flow for the aircraft. This flow may further be broken down by zone. In creating a proposed flow, DAMP manager 26 considers whether the completion of certain tasks is essential for the completion others. ¶ 85, 48-49.);
and displaying steps for maintaining the vehicle determined by the critical path (¶ 64-65, An example implementation of DAMP manager 26 is illustrated in FIGS. 9-17. FIG. 9 illustrates example graphical user interface (GUI) 190 used in conjunction with DAMP manager 26. GUI 190 is an example status screen of system 10. Screen 190 shows in real-time the current maintenance status of aircraft 12. Section 192 of GUI 190 displays the tail number of aircraft 12 (US248 in this example) and user name (Melling). Section 192 also includes pull-down menus 194. Each pull-down menu 194 provides additional levels of access in DAMP manager 26. Thus, a crew member would be provided with only one pull-down menu, while senior management would be provided with several pull-down menus. In this example, user Melling is provided with five pull-down menus. In addition, section 192 includes button 196 ("Log Off") which allows the user to log off of DAMP manager 26. ¶ 77, To assign a crew member to a task, the user simply checks box 258 under the name of the crew member to whom the task is assigned. Once the task is assigned, the crew member may sign onto the task, at which time the clock starts running on that crew member to collect the total amount of time spent on that task. If a crew member has not logged into DAMP manager 26, a visual cue 260, such as a red square drawn around his corresponding check box 258, may be displayed to instantly alert the user of which employees are absent, whereas a green box could be used to indicate that a crew member is awaiting task assignment. A similar visual cue could be provided if the crew member is in training. This visual signal is helpful because tasks cannot be assigned to crew member who are absent or in training. ¶ 88-89, GUT 340 includes the following real-time information, all of which can be edited in GUT 340: task description 342, number of crew members required 344, estimated time 346, actual time accrued 348, target day for accomplishment 350, delay amount 352, estimated start day 354, assigned crew number 356, milestone the task must precede 358, milestone the task must follow 360, task dependency 362, task card number 364, sequence number 366, and zone number 368. ¶ 79-81).
Sinex does not specifically teach identifying the longest path data.
However, Cao teaches using the plurality of clusters to identify the longest data paths within the first layer based on the identified one or more jobs, each respective longest data path comprising a plurality of jobs (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.);
approximating a critical path … based on the generated paths for each of the plurality of clusters using the longest data paths (¶ 21, 45, discloses identifying levels of longest path input. ¶ 23, 40-42, discloses the various layers of data.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Sinex to include/perform identifying the longest path data, as taught/suggested by Cao. This known technique is applicable to the system of Sinex as they both share characteristics and capabilities, namely, they are directed to critical path analysis. One of ordinary skill in the art would have recognized that applying the known technique of Cao would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cao to the teachings of Sinex would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such longest path features into similar systems. Further, applying identifying the longest path data as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the system to determine the critical path, specifically the specific sequence of operations, dependencies, or physical connections that takes the maximum amount of time, distance, or effort to complete within each layer.
Other pertinent prior art includes Kim et al. (US 20140343999 A1) which discloses workflow scheduling in asset-intensive projects and more particularly to techniques for risk-aware project scheduling techniques. Sinex (US 20010032114 A1) which discloses managing an aircraft maintenance program for an aircraft operated by an operator. Wezter et al. (US 8266066 B1) which discloses aircraft maintenance programs. Hegazi (US 20120265570 A1) which discloses critical path scheduling.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMIE H AUSTIN whose telephone number is (571)272-7363. The examiner can normally be reached Monday, Tuesday, Thursday, Friday 7am-2pm.
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, Brian Epstein can be reached at (571) 270 5389. 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.
JAMIE H. AUSTIN
Examiner
Art Unit 3625
/JAMIE H AUSTIN/Primary Examiner, Art Unit 3625