DETAILED ACTION
Claims 1-21 are presented for examination. This Final Office Action is made in response to the communication filed August 10, 2026.
Claims 1-21 are rejected under 35 USC 101 as ineligible.
Claims 1-21 are rejected under 35 USC 103 as obvious over Koenemann in view of Divan.
Response to Arguments
35 USC 101: The Applicant’s arguments have been considered but are not persuasive. As an initial matter, the Applicant’s methods, including the creating steps, can all be characterized as mental processes, as, at the level at which the limitations are claimed, the claims merely recites automation of activities practically performable in the mind or with simple aids. The claims merely recite refining and hashing data, which was done before the advent of computers. The Applicant’s specific arguments will be addressed in the order presented.
Step 2A, Prong 1: The Applicant attempts to argue that the determination of Prong 1 is a holistic determination of whether the entire claim is an abstract idea. However, this is not the purpose of Prong 1. The purpose of Prong 1 is to identify the limitations that are elements of the abstract idea and identify elements that are additional limitations in the claims. The Applicant has not disputed that the steps of the claims can be practically performed in the mind and has not provided any rebuttal to the steps using hashing algorithms according to the Applicant’s disclosure being textual placeholders for being mathematical concepts. Contrary to the Applicant’s assertion, Prong 1 does not involve whether a claim is directed to an abstract idea. It merely questions whether an abstract idea is recited at all. The directed to inquiry is addressed in Step 2A, Prong 2, and is determined based on whether the additional limitations integrate the abstract idea into a practical application.
Step 2A, Prong 2: The Applicant attempts to argue that the claim includes additional limitations integrate the recited abstract idea into a practical application. However, the Applicant fails to appreciate that the claim must include an additional limitation that contributes to the integration into a practical application. The Applicant asserts that the claim need only recite an improvement. However, to integrate under Prong 2, the improvement must come from the additional limitations. The Office Action explicitly stated which elements are abstract ideas and which elements are additional limitations. The Office Action demonstrated why the additional limitations recited fail to integrate the abstract idea into a practical application.
creating a set of data extract files from simulation logs: The Applicant attempts to assert that this limitation is not mere data gathering. In its broadest reasonable sense, this claim limitation merely selects data, based on some criterion/a, to prepare it for further analysis. This is akin to the MPEP 2106.05(g) examples: “iii. Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price” “v. Consulting and updating an activity log.” It is also in a class of insignificant extra-solution activity of selecting a particular data source or type of data to be manipulated, similar to examples: “i. Limiting a database index to XML tags” “ii. Taking food orders from only table-based customers or drive-through customers” “iii. Selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display.” The Applicant asserts that this step is intertwined with the remaining steps, but it is not any more intertwined than other data gathering/sorting steps that do not, by law, confer eligibility. The Applicant then describe the advantages conferred by the identified abstract idea, but, as demonstrated in the rejection, the advantages are conferred entirely by the abstract idea. Also, as mentioned, when construed in the broadest reasonable sense, the claim recites nothing more than automation of the abstract idea, which, under Recentive, fails to confer eligibility. Accordingly, the claim is directed to the abstract idea.
Step 2B: The Applicant is expected to demonstrate that the additional limitations, in, combination with the other elements of the claim, must provide significantly more than the abstract idea, that would confer an inventive concept. However, in order for this to be true, the additional elements must contribute to the inventive concept. As shown in the art of record, using merkle trees to characterize data is a conventional, longstanding practice, regardless of the type of data on which the technique is used. Further still, the identified additional limitation of “creating” is mere data gathering/sorting and is well-understood, routine, and conventional (WURC) activity, so it cannot confer eligibility under MPEP 2106.05(g) and 2106.05(f). Also, the creating step identified as an additional limitation in the rejection is alternatively characterizable as a mental process, as extracting data to create data files is practically performable in the mind or with simple aids, so it is alternatively characterizable as an element of the abstract idea itself. The claims, when considered as a whole, take in data, process data, and provide an output, without reciting any specific improvement to any technology. Further, the claims do nothing with the final determinations that would demonstrate an integration into a practical application or a showing of additional limitations that contribute to an inventive concept. Also, as mentioned, when construed in the broadest reasonable sense, the claims recite nothing more than automation of the abstract idea, which, under Recentive, fails to confer eligibility, regardless of whether the use of the computer operating in its generic sense confers a speedup. Accordingly, the claim is directed to the abstract idea. Accordingly, the rejections are maintained.
35 USC 103: The Applicant’s arguments have been considered and are not persuasive. The Applicant’s arguments will be addressed in the order presented in the Applicant’s response.
Koenemann allegedly fails to teach a consolidated simulation run signature based determination framework: The Applicant alleges that the Koenemann reference fails to teach generating unique signatures for data runs. The Applicant attempts to distinguish by stating that the signature is not merely a compressed test response but a structured aggregation of multiple simulation-signatures corresponding to different extracted data elements of a simulation run. This is not persuasive, as the element teaching aggregate signatures comes from the secondary reference of Merkle trees. Also, as mentioned in the rejection, Koenemann teaches in paragraph [0039] that signature compactors hash the information from the runs. Also, as stated in Koenemann paragraph [0005], “Typically, diagnostic software compares one or more actual fail sets with simulated fail sets. These simulated fail sets can be created, for example, by injecting one fault at a time from a fault list into a representation of the design-under-test (e.g., based on the netlist of the design under test) and fault simulating each fault for all or some of the scan tests. The simulated fail sets can thus identify which response bit or bits fail for a given test and for a given fault. Actual fail set information can be compared to the simulated fail set information in order to identify faults whose fail behavior is compatible with the observed fail behavior in the actual fail set.”
The claim allegedly recites performance of deviation detection data simulation-run level for an indication of diversion across simulation runs: Koenemann teaches generating a fault dictionary across multiple simulation runs and using those signatures for fault detection. Koenemann also teaches adding simulation fault signatures to the dictionary after a new fault is detected (Koenemann [0005]-[0015]. That is, every run is The language of the claim, under the broadest reasonable interpretation, is taught by the system of Koenemann using the hashing of Divan. They teach comparisons of data executions across test runs and between test runs. The claims are written broadly enough to encompass this.
Divan allegedly teaches hashing different information: Koenemann teaches hashing of the simulation data. Divan teaches hashing similar to Merkle trees, which teaches the terms of the claims. The Applicant attempts to read limitations into the claim, such as “hashing at a different abstraction level.” Pains were taken to find references that are on-point and teach the features of the specification, including hashing, but the independent claims do not recite hashing. Claims 4, 5, and 15 do, but the rejection clearly demonstrates where those elements are taught.
Divan does not teach generating signatures from simulation logs: Perhaps. But Koenemann does, as indicated in the rejections. This amounts to attacking the references separately, rather than in combination.
Bulleted allegations that the combination fails to teach elements:
Generating multiple unique signatures from simulation log-derived extract files; storing the signatures in a structured signature log file representing a simulation run: The Koenemann references using hashes to generate unique signatures for simulation runs. The Divan reference includes Merkle trees that do several layers of hashing to get to a consolidated signature. All data is stored at least as intermediate data for analysis, but it is also stored if it reveals another fault, and will be representative of the simulation run.
Generating a consolidated signature representing an ENTIRE simulation execution: This is not in the claims. The Applicant is reading this limitation in from the ether, but it is not in the claims.
Comparing consolidated signatures cross executions: The Koenemann reference initially runs test simulations with injected faults to determine consolidated fault signatures. The Koenemann reference then compares later test signatures across different simulation runs to determine if there is a fault. The claim language is sufficiently broad to be taught by these elements of Koenemann. Further, Koenemann compares signatures for each new fault entered into the dictionary.
Conclusion: The Applicant’s arguments are not persuasive. The rejections are maintained.
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-21 are rejected under 35 U.S.C. 101 because the claimed subject matter is directed to an abstract idea without significantly more. The claims recite mental processes that are capable of being performed in the mind with the aid of pen and paper. Any computer elements are merely generic computing elements. Further, the process steps recited by the claims do not result in any practical application, let alone recite any additional limitations that integrate the abstract idea into a practical application. Further, the use of hashing algorithms (including common ones such as Merkel tree hashing and Merkel signatures) is a longstanding practice and is well-understood, routine, and conventional activity. The methods are intended to cover a Merkle tree, a hashing construct with sublevels of concatenated hashes, which was invented in 1979. The Merkle signature, used in cryptography since its invention, was postulated by Merkle in 1988. The Merkle publications are provided on the record.
The steps performed by the recited methods are akin to common manual analysis techniques used by simulation experts for centuries, and clearly does not require the use of the computer. The recitation of terms like simulation logs, data extract files, signature log files, scripts, data extract files, algorithm, token merely amount to simple automation of an equivalent manual process of consolidating data using methods to recognize patterns in the data. This has also been conventionally performed on computers for decades. The use of Merkel type trees for encryption and data reduction is entirely conventional, as is the use of data signatures to detect differences in data. Please refer to the following references of record that demonstrate the conventionality of these methods and the extent to which the claims merely automate otherwise manual tasks: (Merkle/Hash Trees) The Merkle references; Preneel; Szydlo; and Hu. (Digital Signatures For Simulation Fault Detection) Gass; Cervantes; Yilmaz; The Rajski references; Robinson; Cheng; Tonoyan; Naslund; Ross; Koenemann; Maaref; Koprowski; Huott; Patelli Hamilton; and Hapke.
Mere automation of a manual process practically performable in the mind does not confer eligibility at Step 2A, Prong 2 or Step 2B. The court in Recentive dictated:
Finally, the claimed methods are not rendered patent eligible by the fact that (using existing machine learning technology) they perform a task previously undertaken by humans with greater speed and efficiency than could previously be achieved. We have consistently held, in the context of computer-assisted methods, that such claims are not made patent eligible under § 101 simply because they speed up human activity. See, e.g., Content Extraction, 776 F.3d at 1347; DealerTrack, 674 F.3d at 1333. Whether the issue is raised at step one or step two, the increased speed and efficiency resulting from use of computers (with no improved computer techniques) do not themselves create eligibility. See, e.g., Trinity Info Media, LLC v. Covalent, Inc., 72 F.4th 1355, 1363 (Fed. Cir. 2023) (rejecting argument that “humans could not mentally engage in the ‘same claimed process’ because they could not perform ‘nanosecond comparisons’ and aggregate ‘result values with huge numbers of polls and members’”) (internal citation omitted); Customedia Techs., LLC v. Dish Network Corp., 951 F.3d 1359, 1365 (Fed. Cir. 2020) (holding claims abstract where “[t]he only improvements identified in the specification are generic speed and efficiency improvements inherent in applying the use of a computer to any task”); compare McRo, 837 F.3d at 1314– 16 (finding eligibility of claims to use specific computer techniques different from those humans use on their own to produce natural-seeming lip motion for speech).
The Applicant’s claims are nothing more than automating existing, longstanding, WURC practices. Accordingly, the claims are ineligible. Please see the detailed rejections that follow.
Independent Claims
Claim 1 (Statutory Category – Process)
Step 2A – Prong 1: Judicial Exception Recited?
Yes, the claims recite mental processes and mathematic concepts, which are abstract ideas.
Claim 1 recites:
generating a unique signature for each of the set of data extract files; creating a signature log file comprising the unique signature generated for each of the set of data extract files; (Mental Process Creating and using a cypher to encode data has been done for centuries prior to the advent of computers. Therefore it is practically performable in the mind or with the aid of pen and paper, rendering it an evaluation, a mental process, an abstract idea.)
generating a consolidated signature for the signature log file; (Mental Process Creating and using a cypher to encode data has been done for centuries prior to the advent of computers. This is just using a second cypher on an existing cypher. Therefore it is practically performable in the mind or with the aid of pen and paper, rendering it an evaluation, a mental process, an abstract idea.)
comparing the consolidated signature with a prior consolidated signature generated for a prior simulation run; and determining whether the current simulation run deviates from the prior simulation run, based on the comparison between the consolidated signature and the prior consolidated signature. (Mental Process Comparing encodings to find if a difference exists has been done for centuries before the advent of the computer and is, therefore, practically performable in the mind or with the aid of pen and paper, rendering it an evaluation, a mental process, an abstract idea.)
Claim 1 recites mental processes, which are abstract ideas.
Claim 1 recites an abstract idea.
Step 2A – Prong 2: Integrated into a Practical Solution?
No.
Claim 1 recites the following additional limitations:
creating a set of data extract files from simulation logs associated with a current simulation run;
This is mere data gathering akin to the MPEP 2106.05(g) examples: “i. Performing clinical tests on individuals to obtain input for an equation” “v. Consulting and updating an activity log, Ultramercial,” “i. Limiting a database index to XML tags” “iii. Selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display.” Accordingly, this is extra-solution activity and fails to integrate the abstract ideas into a practical application.
Claim 1 fails to recite any additional limitations that integrate the abstract idea into a practical application.
Claim 1 is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept?
No.
Claims 1 recites the following additional limitations:
creating a set of data extract files from simulation logs associated with a current simulation run;
This is well-understood, routine, and conventional (WURC) activity akin to the MPEP 2106.05(d) examples: “iii. Electronic recordkeeping” “iv. Storing and retrieving information in memory” “v. Electronically scanning or extracting data from a physical document” “i. Determining the level of a biomarker in blood by any means “ “v. Analyzing DNA to provide sequence information or detect allelic variants” “vi. Arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price.” Also, please see the following references of record that demonstrate this limitation is WURC: . Because this limitation is WURC, it fails to combine with the other elements of the claim to provide significantly more than the abstract idea that would confer an inventive concept.
The additional limitations fail to combine with the other elements of the claim to provide significantly more than the abstract idea that would confer an inventive concept.
Claim 1 is ineligible.
Claim 11 (Statutory Category – Machine)
Claim 11 recites a computer with processor and memory that conducts the method of claim 1. The method executed by the computer is rejected for at least the same reasons as claim 1. Further, the recitation of a system for analysing simulation data that includes a processor and a memory coupled to the processor to execute instructions is a generic computing element recited at a high level that, under MPEP 2106.05(f), fails to confer eligibility at Step 2A, Prong 2 and at Step 2B.
Accordingly claim 11 is ineligible.
Claim 21 (Statutory Category – Machine)
Claim 21 recites a CRM that conducts the method of claim 1. The method executable from the CRM is rejected for at least the same reasons as claim 1. Further, the recitation of a CRM is a generic computing element recited at a high level that, under MPEP 2106.05(f), fails to confer eligibility at Step 2A, Prong 2 and at Step 2B.
Accordingly claim 12 is ineligible.
Dependent Claims
Claims 2 and 12
generate a [rubric] to scan the simulation logs of the current simulation run to create a set of data extract files.
Generating a rubric for determining which data to use in analysis fails to confer eligibility for the same reasons as the create step of claim 1. Also, setting criteria for filtering data is practically performable in the mind with the aid of pen and paper, which makes it an evaluation, a mental process, an abstract idea. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
Script
A script is a generic computing algorithm that is easily substitutable with the aforementioned rubric. This means that the script fails to confer eligibility under 2106.05(f). Also, the script is a placeholder representing automation of an otherwise manual task. As previously demonstrated, under Recentive, mere automation of a manual process fails to confer eligibility. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 2 and 12 are ineligible.
Claims 3 and 13
wherein creating the set of data extract files comprises executing the [rubric] on the simulation logs based on a user input.
Determining which data to use in analysis based on a rubric is practically performable in the mind with the aid of pen and paper, which makes it an evaluation, a mental process, an abstract idea. Accordingly this limitation fails to provide additional limitations that confer eligibility.
Script
A script is a generic computing algorithm that is easily substitutable with the aforementioned rubric. This means that the script fails to confer eligibility under 2106.05(f). Also, the script is a placeholder representing automation of an otherwise manual task. As previously demonstrated, under Recentive, mere automation of a manual process fails to confer eligibility. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 3 and 13 are ineligible.
Claims 4 and 14
wherein generating the unique signature for a data extract file from the set of data extract files comprises: generating at least two hash codes for the data extract file, wherein generating a hash code from the at least two hash codes comprises: executing a unique hashing algorithm on the data extract file to generate the hash code from the at least two hash codes; and concatenating the at least two hash codes to generate the unique signature for the data extract file.
Using a cypher to encrypt words, concatenating the encrypted words, and then using a cypher to further encrypt those concatenated, encrypted words is practically performable in the mind or with the aid of pen and paper, so this limitation is an evaluation, a mental process, an abstract idea. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 4 and 14 are ineligible.
Claims 5 and 15
wherein generating the consolidated signature for the signature log file comprises: generating at least two hash codes for the signature log file, wherein generating a hash code from the at least two hash codes comprises: executing the unique hashing algorithm on the signature log file to generate the hash code from the at least two hash codes; and concatenating the at least two hash codes to generate the consolidated signature for the signature log file.
Using a cypher to encrypt words, concatenating the encrypted words, and then using a cypher to further encrypt those concatenated, encrypted words and continuing this process up a Merkel tree/signature, is practically performable in the mind or with the aid of pen and paper, so this limitation is an evaluation, a mental process, an abstract idea. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 5 and 15 are ineligible.
Claims 6 and 16
wherein creating the signature log file comprises sequentially storing the unique signature generated for each of the set of data extract files, wherein the unique signature generated for each of the set of data extract files is sequentially stored based on a sequence of creation of each of the set of data extract files.
Organizing data is considered insignificant extra-solution activity and WURC for the same reasons as the independent claims’ create/creating steps and fail to confer eligibility for at least the same reasons.
The claims fail to provide any additional limitations that confer eligibility.
Claims 6 and 16 are ineligible.
Claims 7 and 17
wherein creating the signature log file comprises: assigning a token to each of the set of data extract files; and storing the unique signature generated for each of the set of data extract files in association with the assigned token.
Assigning a token/label to a file (e.g., putting a label on a paper file folder) is mere data gathering/organization and is insignificant extra-solution activity and WURC for the same reasons as the independent claims’ create/creating steps and fail to confer eligibility for at least the same reasons.
The claims fail to provide any additional limitations that confer eligibility.
Claims 7 and 17 are ineligible.
Claims 8 and 18
wherein comparing the consolidated signature with the prior consolidated signature comprises: matching the consolidated signature generated for the current simulation run with the prior consolidated signature generated for the prior simulation run; and identifying a mismatch between the consolidated signature and the prior consolidated signature in response to matching.
Comparing words/strings is practically performable in the mind or with the aid of pen and paper, so this limitation is an evaluation, a mental process, an abstract idea. Also, as demonstrated in the references of record, the using of time series data hash comparisons to determine inconsistencies is a longstanding practice and conventional. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 8 and 18 are ineligible.
Claims 9 and 19
comparing the unique signature generated for each of the set of data extract files of the current simulation run with a prior unique signature generated for the corresponding prior data extract file of the prior simulation run, upon identifying the mismatch between the consolidated signature and the prior consolidated signature, wherein the comparing comprises: matching the unique signature generated for each of the set of data extract files with the prior unique signature generated for the corresponding prior data extract file; and identifying a mismatch between the unique signature generated for at least one of the set of data extract files and the prior unique signature generated for the corresponding prior data extract file.
Comparing words/strings to identify mismatches is practically performable in the mind or with the aid of pen and paper, so this limitation is an evaluation, a mental process, an abstract idea. Also, as demonstrated in the references of record, the using of time series data hash comparisons to determine inconsistencies is a longstanding practice and conventional. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 9 and 19 are ineligible.
Claims 10 and 20
identifying from the set of data extract files, at least one data extract file with deviations based on the mismatch identified between the unique signature of the at least one data extract file and the prior unique signature of the corresponding prior data extract file.
Comparing words/strings to identify mismatches is practically performable in the mind or with the aid of pen and paper, so this limitation is an evaluation, a mental process, an abstract idea. Also, as demonstrated in the references of record, the using of time series data hash comparisons to determine inconsistencies is a longstanding practice and conventional. Accordingly, this limitation fails to provide additional limitations that confer eligibility.
The claims fail to provide any additional limitations that confer eligibility.
Claims 10 and 20 are ineligible.
Claim Rejections - 35 USC § 103
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.
Claims 1-21; Koenemann and Divan
Claim(s) 1-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2007/0038911 A1 to Koenemann et al. (Koenemann) in view of NPL: “Metadata-based measurements transmission verified by a Merkle Tree” by Divan et al (Divan).
Claims 1, 11, and 21
Regarding claim 11, teaches:
A system for analysing simulation data, the system comprising: a processor; and a memory coupled to the processor, wherein the memory stores processor-executable instructions, which, on execution, causes the processor to: (Koenemann [0007] “FIG. 1 is a block diagram 100 illustrating an exemplary method for fault diagnosis using a pre-calculated fault-dictionary approach for a circuit-under-test having no compression hardware. The exemplary method is divided into three phases: a pre-test processing phase 110, a test phase 112, and a post-test processing phase 114. In the pre-test processing phase 110, fault simulation 120 is performed to generate a fault dictionary 122 comprising entries that indicate what faults may have generated an observed failing response. Fault simulation 120 can be performed, for example, by simulating the presence of one or more faults (defined by a fault list 124) in the design-under-test (defined, for example, by a netlist 126 or other design database) as one or more test patterns 128 are applied to the design-under-test. In FIG. 1, the resulting fault dictionary entries correspond to the full failing test responses (the "uncompressed symptoms." [0036] “Moreover, any of the disclosed methods can be used in a computer simulation or other EDA environment, where test patterns, test responses, and compressed fail sets (e.g., failing signatures) are determined or otherwise analyzed using representations of circuits, which are stored on one or more computer-readable media. For presentation purposes, the present disclosure sometimes refers to a circuit or circuit component by its physical counterpart (for example, scan chain, MISR, and other such terms). It should be understood, however, that any reference in the disclosure or the claims to a physical component includes both the physical component and representation of the physical component as used in simulation or other such EDA environments.” – The system conducts simulations to determine faults. [0032] “The disclosed embodiments can be implemented in a wide variety of environments. For example, any of the disclosed techniques can be implemented in software comprising computer-executable instructions stored on computer-readable media (e.g., one or more CDs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as hard drives)). Such software can comprise, for example, electronic design automation ("EDA") software (e.g., a logic built-in self-test ("LBIST") tool or automatic test pattern generation ("ATPG") tool) used to design and synthesize BIST hardware for a particular design-under-test, perform fault simulation, dictionary generation, and/or fault diagnostics for the design-under-test. The design-under-test can be implemented in a variety of different circuits, including application specific integrated circuits ("ASICs"), programmable logic devices ("PLDs") such as field-programmable gate arrays ("FPGAs"), and systems-on-a-chip ("SoCs") having digital, analog, or mixed-signal components thereon. These particular software implementations should not be construed as limiting in any way, however, as the principles disclosed herein are generally applicable to other software tools. “ – Computer with processors and memory)
create a set of data extract files from simulation logs associated with a current simulation run; (Koenemann [0058] “In other embodiments, however, bit-level test responses are received from the circuit having the design-under-test and the signature is generated by simulating or emulating application of the test responses to a signature generator.”
generate a consolidated signature for the [simulation logs] ; (Koenemann [0039] “Sequential compactors (also referred to as "time compactors") such as Multiple-Input Signature Registers (MISRs) typically used for Logic BIST and for some test data compression approaches, essentially hash the error information” [0058] “At process block 304, signatures from each interval are generated”)
compare the consolidated signature with a prior consolidated signature generated for a prior simulation run; and (Koenemann [0005] “ Typically, diagnostic software compares one or more actual fail sets with simulated fail sets. These simulated fail sets can be created, for example, by injecting one fault at a time from a fault list into a representation of the design-under-test (e.g., based on the netlist of the design under test) and fault simulating each fault for all or some of the scan tests. The simulated fail sets can thus identify which response bit or bits fail for a given test and for a given fault. Actual fail set information can be compared to the simulated fail set information in order to identify faults whose fail behavior is compatible with the observed fail behavior in the actual fail set.” [0007] “In the pre-test processing phase 110, fault simulation 120 is performed to generate a fault dictionary 122 comprising entries that indicate what faults may have generated an observed failing response. Fault simulation 120 can be performed, for example, by simulating the presence of one or more faults (defined by a fault list 124) in the design-under-test (defined, for example, by a netlist 126 or other design database) as one or more test patterns 128 are applied to the design-under-test. ” [0015] “[0015] In one embodiment, a method of diagnosing faults in a circuit is disclosed. In this embodiment, a signature produced by a signature generator is received. The signature corresponds to the circuit's response to no more than one test pattern. The signature is compared to entries of a fault dictionary. An entry of the fault dictionary is matched to the signature if the entry identifies a fault that explains the signature. The fault is stored in a list of fault candidates. The signature generator can be located on the circuit, and the signature can be produced by the signature generator during production testing of the circuit. The signature generator can also be a representation of a signature generator. In this implementation, for example, the circuit's bit-level response to the test pattern can be received and the signature corresponding to the circuit's bit-level response can be determined using the representation of the signature generator. ” [0017] “The signature analysis subsystem of this embodiment is configured to compare a respective signature received from the signature generator to entries of a fault dictionary and to create a list of potential fault candidates if the respective signature is a failing signature and if the failing signature matches one or more entries in the fault dictionary.” – Signatures of simulation data are compared with other signatures of fault data from prior simulations.)
determine whether the current simulation run deviates from the prior simulation run, based on the comparison between the consolidated signature and the prior consolidated signature. (Koenemann [0013] “ Run-times can often be further reduced using logic consistency checking. In general, if the error locations are known exactly or can at least be tightly bounded, the number of fault candidates considered in post-test simulation can be effectively reduced. A dynamic fault dictionary 246 is generated as a result of fault simulation 240. The entries of the dynamic fault dictionary 246 correspond to the full failing test responses (the "uncompressed symptoms") resulting from the potential faults in the partial fault list. At 250, the uncompressed symptoms are compared and matched with the actual uncompressed fail sets to determine which faults best explain the observed test responses. A list of potential faults locations 252 (also referred to as "fault candidates" or "callouts") is produced as a result of the comparison and matching 250. The list of potential fault sites can then be used to help locate the actual fault site on the failing circuit.” – The signatures are compared to determine potential simulations faults from the data. Then, once the potential faults are identified, the data the signature represents is compared to determine if there is a fault. This is based on the comparison of the current and prior signatures.)
Koenemann teaches that compression methods, such as hashing algorithms or MISRs, are used to make reduced data signatures of the testing log data and that data, including fault data, is arranged in trees (Koenemann [0012] “The use of compression during the testing of integrated circuits has become widespread. In general, compression helps reduce the volume of test data required for even traditional stuck-at test sets. Such sets, for example, often exceed the capacity of automatic test equipment ("ATE") used to test today's multimillion-gate integrated circuits. Moreover, due to the limited bandwidth between the circuit-under-test ("CUT") and the ATE, the use of compressed test data and compressed test responses can decrease test time, and thus the test cost.” [0039] “Sequential compactors (also referred to as "time compactors") such as Multiple-Input Signature Registers (MISRs) typically used for Logic BIST and for some test data compression approaches, essentially hash the error information” [0040] “For example, certain exemplary embodiments of the disclosed technology are capable of performing dictionary-based diagnostics directly from failing signatures without the need for retest and bit-level data logging. Further, some embodiments of the disclosed technology use a compact, signature-based stop-on-nth-error fault dictionary and a diagnostic technique that is based on the single-location paradigm.” [0042] “Exact matching, however, is possible because an error signature predicted from simulated error locations will exactly match the actual signature error if the simulated and actual error locations are the same. Accordingly, exact matching diagnostic methods are well-suited and desirably used for direct diagnosis from signatures.” [0034] “For example, a list comprising suspect scan cells or fault candidates (corresponding to possible defect locations in the design-under-test) produced by the application of any of the disclosed embodiments can be stored on computer readable-media. Such diagnostic results can be created or updated at a local computer or over a network (e.g., by a server computer). As used herein, the term "list" refers to a collection or arrangement of data that is usable by a computer system. A list may be, for example, a data structure or combination of data structures (such as a queue, stack, array, linked list, heap, or tree) that organizes data for better processing efficiency, or any other structured logical or physical representation of data in a computer system or computer-readable media (such as a table used in a relational database).”), but Koenemann does not appear to explicitly teach, but Koenemann in view of teaches:
generate a unique signature for each of the set of data extract files; create a signature log file comprising the unique signature generated for each of the set of data extract files; generate a consolidated signature for the signature log file; (NOTE: This is a basic Merkle tree structure, as is clear from the dependent claims. In a Merkle tree, the child nodes are hashes of data, sometimes sequential time-series data, and the parent nodes are hashes of the concatenation of the hashed child nodes. This is also further explored for signature analysis in the cryptography context in Merkle’s follow up work regarding Merkle signatures that make signatures based on the Merkle trees. The original papers for these are provided on the record. However, the secondary reference used is a more recent derivative work. ALSO Divan Page 9, Right Column, 5. Merkle’s tree and the measurement streams “AMerkle’s tree is a binary tree where each leaf node contains a hash of the data (no data itself), while each intermediate node up to the root contains a new hash computed from the descendent nodes. […] “Thus, each leaf node contains the hash of the associated data chunk, while its father node will contain the hash computed from the descendent nodes. For example, the node indicated with a number 4 in Fig. 4, contains the hash computed from the nodes 8 and 9, and in this way successively until the root. Merkle’s schema allows verifying the data integrity in a distributed environment through a few operations based on hash, while the rest of the data are not required. For example, it lets suppose that a huge data file is spread out in eight data chunks and they are distributed in different nodes of a cluster. For some reason, it is necessary to verify the integrity of the data chunk number 4 (See Fig. 4, node 11). For that purpose, the corresponding node will use only the hashes related to the node 10 (i.e., h(3)), 4 (i.e., h(1;2)), and 3 (i.e., h(h(5;6);h(7;8))). Thus, through the comparison of h(h((h(3); h(4));h(1;2));3) with the root hash from the rest of the data chunks, the node could know whether the data chunk is valid (i.e., the hashes match) or not (i.e., the hashes have some difference).” See Also Fig. 4 on page 9 (shown below) – The claimed unique signatures are child nodes of the claimed consolidated signature in the Merkle tree. In an alternative mapping the set of data extract files could be child nodes of the unique signatures in the Merkle tree.)
PNG
media_image1.png
509
645
media_image1.png
Greyscale
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to modify the generic hashing compression of Koenemann by the specific Merkle tree hashing of Divan because the person of ordinary skill in the art would be motivated by the aim of Koenemann to compress data by hashing to look to Divan, which provides an efficient Merkle tree hashing method for detecting data anomalies (Koenemann [0012] “The use of compression during the testing of integrated circuits has become widespread. In general, compression helps reduce the volume of test data required for even traditional stuck-at test sets. Such sets, for example, often exceed the capacity of automatic test equipment ("ATE") used to test today's multimillion-gate integrated circuits. Moreover, due to the limited bandwidth between the circuit-under-test ("CUT") and the ATE, the use of compressed test data and compressed test responses can decrease test time, and thus the test cost.” [0039] “Sequential compactors (also referred to as "time compactors") such as Multiple-Input Signature Registers (MISRs) typically used for Logic BIST and for some test data compression approaches, essentially hash the error information” [0014] “In particular, the disclosed technology concerns diagnosing faults from signatures produced by sequential (or time) compactors, such as multiple input signature registers ("MISRs").”; Divan Abstract “The Data Stream Processing Strategy (DSPS) is focused on the automatization of measurement projects based on a measurement framework. The measurement adapter (MA) is an architecture component located on mobile devices aims to integrate heterogeneous data sources (i.e., sensors). The Gathering Function (GF) is the component responsible for interacting and receiving measures from the MAs, and it resides on the Stream Processing Engine (SPE). MA and GF share the project definition based on a measurement framework to foster data interoperability, while MA regulates the frequency, size, and route related to data transmission. As contributions (i) The brief data message is introduced to optimize the data transmission keeping immutable the hierarchical data organization based on the project definition, and (ii) The integrity record for mobile and SPE environments is described based on a Merkle Tree. This allows optimizing each data transaction, incorporating a historical integrity record both MA and SPE. The proposals and simulations have been implemented on the cincamimis, cincamipd, mair, and pabmmcommons libraries, which are freely available on GitHub under the terms of the Apache 2.0 licence. Four simulations are explained to detail how to measures were obtained. Interesting results show that the brief data message consumes 17.50 KB to transmit 1000 measures (2.4 times smaller than JSON), while a message with 200 measures could be generated and compressed using GZIP in 25.12 ms (2.43 times faster than JSON). 196 KB is required to keep 17 min of the integrity history in a MA, being created in 4.85 ms.”)
Regarding claim 1, claim 1 recites the method executed by the system of claim 11, so claim 1 is rejected for at least the same reasons as claim 11.
Regarding claim 21, claim 21 recites a CRM that is an embodiment of the memory recited in claim 11, so claim 21 is rejected for at least the same reasons as claim 11.
Claims 2 and 12
Regarding claim 12, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
generating a script configured to scan the simulation logs of the current simulation run to create the set of data extract files. (Koenemann [0073] “ The signature generator 516 used in implementations of the exemplary system 500 can be any of a wide variety of signature generators and can be further modified or enhanced to achieve other desirable functions. For example, in certain implementations, a scan chain masking circuit (not shown) is coupled between the outputs of the scan chains and the inputs of the signature generator. The scan chain masking can be configured, for example, to selectively mask one or more of the scan chains on a test-by-test or cycle-by-cycle basis and be controlled, for example, to mask unknown states from being loaded into the signature generator. In some implementations, a linear phase shifting network (not shown) is coupled between the outputs of the scan chains and the inputs of the signature generator. In still other implementations, a linear space compactor network (not shown) is coupled between the outputs of the scan chains and the inputs of the signature generator, thereby creating an additional compaction stage which does not significantly impact the possible diagnostic resolution.” – Data is extracted from simulation/test logs to be used to determine signatures.)
Regarding claim 2, claim 2 recites the method conducted by claim 12, so claim 2 is rejected for at least the same reasons as claim 12.
Claims 3 and 13
Regarding claim 13, Koenemann in view of Divan teaches the features of claim 12, and further teaches:
wherein creating the set of data extract files comprises executing the script on the simulation logs based on a user input. (Koenemann [0059] “The signature-based fault dictionary of this embodiment is created to account for the interval-based application of the test patterns. In general, the interval length of this or any of the disclosed embodiments can be selected in order to account for and better utilize the single-location fail assumption. For example, the interval length can be specified by the user, determined automatically based on a desired resolution, or otherwise determined by the EDA software with which it is used. In desirable embodiments, the interval length corresponds to one test response or less.” [0076] “At process block 610, a description of the design-under-test and signature generator is received. The description can be, for example, a logic netlist or other design file.” – The creation of the set of files is based on user input.)
Regarding claim 3, claim 3 recites the method conducted by claim 13, so claim 3 is rejected for at least the same reasons as claim 13.
Claims 4 and 14
Regarding claim 14, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
wherein generating the unique signature for a data extract file from the set of data extract files comprises: generating at least two hash codes for the data extract file, wherein generating a hash code from the at least two hash codes comprises: executing a unique hashing algorithm on the data extract file to generate the hash code from the at least two hash codes; and concatenating the at least two hash codes to generate the unique signature for the data extract file. (NOTE: Again, this is just generating a Merkle tree representation. ALSO Divan Page 9, Right Column, 5. Merkle’s tree and the measurement streams “AMerkle’s tree is a binary tree where each leaf node contains a hash of the data (no data itself), while each intermediate node up to the root contains a new hash computed from the descendent nodes. […] “Thus, each leaf node contains the hash of the associated data chunk, while its father node will contain the hash computed from the descendent nodes. For example, the node indicated with a number 4 in Fig. 4, contains the hash computed from the nodes 8 and 9, and in this way successively until the root. Merkle’s schema allows verifying the data integrity in a distributed environment through a few operations based on hash, while the rest of the data are not required. For example, it lets suppose that a huge data file is spread out in eight data chunks and they are distributed in different nodes of a cluster. For some reason, it is necessary to verify the integrity of the data chunk number 4 (See Fig. 4, node 11). For that purpose, the corresponding node will use only the hashes related to the node 10 (i.e., h(3)), 4 (i.e., h(1;2)), and 3 (i.e., h(h(5;6);h(7;8))). Thus, through the comparison of h(h((h(3); h(4));h(1;2));3) with the root hash from the rest of the data chunks, the node could know whether the data chunk is valid (i.e., the hashes match) or not (i.e., the hashes have some difference).” See Also Fig. 4 on page 9 (shown below) – The claimed hash codes are generated and concatenated to form the signature that is a hash of the concatenated hashed codes. These are just elements of a Merkle tree.)
PNG
media_image1.png
509
645
media_image1.png
Greyscale
Regarding claim 4, claim 4 recites the method conducted by claim 14, so claim 4 is rejected for at least the same reasons as claim 14.
Claims 5 and 15
Regarding claim 15, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
wherein generating the consolidated signature for the signature log file comprises: generating at least two hash codes for the signature log file, wherein generating a hash code from the at least two hash codes comprises: executing the unique hashing algorithm on the signature log file to generate the hash code from the at least two hash codes; and concatenating the at least two hash codes to generate the consolidated signature for the signature log file. (NOTE: Again, this is just generating a Merkle tree representation. ALSO Divan Divan Page 9, Right Column, 5. Merkle’s tree and the measurement streams “AMerkle’s tree is a binary tree where each leaf node contains a hash of the data (no data itself), while each intermediate node up to the root contains a new hash computed from the descendent nodes. […] “Thus, each leaf node contains the hash of the associated data chunk, while its father node will contain the hash computed from the descendent nodes. For example, the node indicated with a number 4 in Fig. 4, contains the hash computed from the nodes 8 and 9, and in this way successively until the root. Merkle’s schema allows verifying the data integrity in a distributed environment through a few operations based on hash, while the rest of the data are not required. For example, it lets suppose that a huge data file is spread out in eight data chunks and they are distributed in different nodes of a cluster. For some reason, it is necessary to verify the integrity of the data chunk number 4 (See Fig. 4, node 11). For that purpose, the corresponding node will use only the hashes related to the node 10 (i.e., h(3)), 4 (i.e., h(1;2)), and 3 (i.e., h(h(5;6);h(7;8))). Thus, through the comparison of h(h((h(3); h(4));h(1;2));3) with the root hash from the rest of the data chunks, the node could know whether the data chunk is valid (i.e., the hashes match) or not (i.e., the hashes have some difference).” See Also Fig. 4 on page 9 (shown below) – The claimed hash codes are generated and concatenated to form the signature that is a hash of the concatenated hashed codes. These are just elements of a Merkle tree.)
PNG
media_image1.png
509
645
media_image1.png
Greyscale
Regarding claim 5, claim 5 recites the method conducted by claim 15, so claim 5 is rejected for at least the same reasons as claim 15.
Claims 6 and 16
Regarding claim 16, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
wherein creating the signature log file comprises sequentially storing the unique signature generated for each of the set of data extract files, wherein the unique signature generated for each of the set of data extract files is sequentially stored based on a sequence of creation of each of the set of data extract files. (NOTE: Divan teaches a sequential Merkle scheme where elements are stored sequentially/chronologically, Divan Page 10, Left Column, Third Paragraph “Fig. 5 describes a representation of an integrity record with a capacity to store the last four transactions. The oldest transaction is located in the left extreme of the leaves, while the newest transaction is the extreme right of the leaves. When a new transaction is incorporated, node 1 (the oldest transaction in Fig. 5) is discarded, giving its place to node 2 who becomes in the new oldest transaction. In the same way, node 3 becomes in the new node 2, node 4 becomes in the new 3, and finally, the new transaction occupies the slot 4. In this record, the leaves do not need to compute the hash, due to the MD5 hash coming from the brief data message is recycled. However, the intermediate nodes up to the root need to be recomputed.” SEE ALSO Fig. 5 on Page 10 (shown below) – The reference shows that the signatures are sequentially stored based on the sequence of creation. (e.g., as elements of the Merkle tree)
PNG
media_image2.png
518
648
media_image2.png
Greyscale
Regarding claim 6, claim 6 recites the method conducted by claim 16, so claim 6 is rejected for at least the same reasons as claim 16.
Claims 7 and 17
Regarding claim 17, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
wherein creating the signature log file comprises: assigning a token to each of the set of data extract files; and storing the unique signature generated for each of the set of data extract files in association with the assigned token. (Koenemann [0078] “Through fault simulation of the modeled faults and signature emulation, a signature-based fault dictionary is created and persistently stored at process block 614. The signature-based fault dictionary can, for example, contain information that: (1) for each fault, identifies which design under test and test set the fault is associated with; (2) for each fault, identifies one or more tests in which the respective fault is detected (the fault-detecting patterns); (3) for each such fault-detecting pattern, records the emulated fault signature (or error signature) corresponding to the simulated faulty circuit behavior in the presence of the fault; (4) for each fault, contains records for at least a predefined minimum number of the fault-detecting patterns; and/or (5) for some or all of the fault-detecting patterns, indicates whether the associated fault is detected in fewer patterns than the minimum number.” – The data files are stored in association with information/a token that identifies the data.)
Regarding claim 7, claim 7 recites the method conducted by claim 17, so claim 7 is rejected for at least the same reasons as claim 17.
Claims 8 and 18
Regarding claim 18, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
wherein, to compare the consolidated signature with the prior consolidated signature, the processor executable instructions further cause the processor to: match the consolidated signature generated for the current simulation run with the prior consolidated signature generated for the prior simulation run; and identify a mismatch between the consolidated signature and the prior consolidated signature in response to matching. (Koenemann [0058] “At process block 304, signatures from each interval are generated, output, and compared to those in a signature-based fault dictionary (for example, a signature-based fault dictionary created from simple model faults, such as stuck-at and/or transition fault models). In some embodiments, the signature generator is located on the circuit having the design-under-test and comprises, for example, a MISR. In other embodiments, however, bit-level test responses are received from the circuit having the design-under-test and the signature is generated by simulating or emulating application of the test responses to a signature generator. Furthermore, in some embodiments, the signature generator (e.g., a MISR) is reset (or otherwise corrected to a known state) between each interval so that previously observed signatures error from one interval will not contaminate or otherwise affect the signatures of subsequent intervals.” – A comparison is done to determine whether signatures match. [0060] “For example, the initial suspect fault location list can be generated using single-location diagnostics with a signature-based fault dictionary created from simple model faults. Single-location diagnostics typically assume that defects tend to cause fail behaviors that exactly match the fail behavior of simple fault models (for example, a single stuck-at fault location) in at least some failing tests, even though that behavior may not be consistent for all failing and passing tests. Thus, exemplary embodiments of the disclosed direct diagnosis methodology desirably, though not necessarily, use an exact (or complete) matching criteria. For example, in one exemplary embodiment, fault locations with matching behavior for at least one failing test are used to form an initial set of suspect fault locations. The information from this initial set of suspect fault locations may then be used to derive reasonably accurate diagnostic scorings and classifications.” – The match may be a complete or partial match, the partial match including am identified mismatch from the comparison.)
Regarding claim 8, claim 8 recites the method conducted by claim 18, so claim 8 is rejected for at least the same reasons as claim 18.
Claims 9 and 19
Regarding claim 19, Koenemann in view of Divan teaches the features of claim 11, and further teaches:
compare the unique signature generated for each of the set of data extract files of the current simulation run with a prior unique signature generated for the corresponding prior data extract file of the prior simulation run, upon identifying the mismatch between the consolidated signature and the prior consolidated signature, wherein the comparing comprises: match the unique signature generated for each of the set of data extract files with the prior unique signature generated for the corresponding prior data extract file; and identify a mismatch between the unique signature generated for at least one of the set of data extract files and the prior unique signature generated for the corresponding prior data extract file. (Koenemann [0061] “With the single-location assumption, it is possible and practical to use a signature-based fault dictionary based on simple model faults (for example, stuck-at and/or transition fault models) for the initial logic diagnostics. For example, the fault dictionary can be created once, up-front, by performing diagnostic fault simulation for each test interval and for each simple fault. Further, in some embodiments of the disclosed technology, faults are dropped after they have been detected more than some specified or predetermined number of times, such as after two times, three times, or any other desirable number of times. The dictionary of this embodiment is therefore a "stop-on-nth-error" dictionary. As part of dictionary creation, for each fault-detecting interval, the test responses can be compacted into a signature by simulating the same signature generation method that is implemented on the circuit-under-test or otherwise used to compress the test responses. Further, in certain implementations, error signatures can be produced and recorded instead of the raw signatures. The error signatures typically correspond to the difference between the expected fault free signature for the interval and the faulty signature with the fault present. For linear signature generators (such as a Multiple-Input-Signature Registers ("MISRs")), the difference can be calculated as the bitwise Exclusive-OR ("XOR") of the two signatures (though a bitwise XNOR operation can alternatively be used). For instance, circuits-under-test can fail with the same error signature in different patterns even if the raw signatures are different. This commonality in the error signatures can be beneficial for achieving faster common failure mode analysis as well as for further reducing the size of the fault dictionary.” – Koenemann contemplates a test in which multiple failures have to be detected over time to determine that a fault is occurring. This involves multiple comparisons between current and prior signatures of the tests/simulations being run. Also, this could be an example of the first run of the model after the testing was conducted in Koenemann to determine the fault dictionary, which would also read on the claim.)
Regarding claim 9, claim 9 recites the method conducted by claim 19, so claim 9 is rejected for at least the same reasons as claim 19.
Claims 10 and 20
Regarding claim 20, Koenemann in view of Divan teaches the features of claim 19, and further teaches:
identify from the set of data extract files, at least one data extract file with deviations based on the mismatch identified between the unique signature of the at least one data extract file and the prior unique signature of the corresponding prior data extract file. (Koenemann [0061] “With the single-location assumption, it is possible and practical to use a signature-based fault dictionary based on simple model faults (for example, stuck-at and/or transition fault models) for the initial logic diagnostics. For example, the fault dictionary can be created once, up-front, by performing diagnostic fault simulation for each test interval and for each simple fault. Further, in some embodiments of the disclosed technology, faults are dropped after they have been detected more than some specified or predetermined number of times, such as after two times, three times, or any other desirable number of times. The dictionary of this embodiment is therefore a "stop-on-nth-error" dictionary. As part of dictionary creation, for each fault-detecting interval, the test responses can be compacted into a signature by simulating the same signature generation method that is implemented on the circuit-under-test or otherwise used to compress the test responses. Further, in certain implementations, error signatures can be produced and recorded instead of the raw signatures. The error signatures typically correspond to the difference between the expected fault free signature for the interval and the faulty signature with the fault present. For linear signature generators (such as a Multiple-Input-Signature Registers ("MISRs")), the difference can be calculated as the bitwise Exclusive-OR ("XOR") of the two signatures (though a bitwise XNOR operation can alternatively be used). For instance, circuits-under-test can fail with the same error signature in different patterns even if the raw signatures are different. This commonality in the error signatures can be beneficial for achieving faster common failure mode analysis as well as for further reducing the size of the fault dictionary.” – Koenemann contemplates a test in which multiple failures have to be detected over time to determine that a fault is occurring. This involves multiple comparisons between current and prior signatures of the tests/simulations being run. Also, this could be an example of the first run of the model after the testing was conducted in Koenemann to determine the fault dictionary, which would also read on the claim.)
Regarding claim 10, claim 10 recites the method conducted by claim 20, so claim 10 is rejected for at least the same reasons as claim 20.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is referenced in the above 35 USC 101 rejection, illustrating the claims represent longstanding practices and conventional activity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAY MICHAEL WHITE whose telephone number is (571) 272-7073. The examiner can normally be reached Mon-Fri 11:00-7:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Pitaro can be reached at (571) 272-4071. 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.
/J.M.W./Examiner, Art Unit 2188
/RYAN F PITARO/Supervisory Patent Examiner, Art Unit 2188
