DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 05/22/2026
Claims 1, 3-8, 10-15, and 17-20 are currently amended
Claims 1-20 are pending
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 .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 05/22/2026. Claims 1-20 remain pending in the application. Examiner has withdrawn the outstanding claim objections in view of the amendments.
Response to Arguments
Applicant’s arguments filed 05/22/2026, with respect to the rejections of independent claims 1, 8, and 15 and their corresponding dependent claims under 35 USC 103 have been fully considered, but they are not persuasive. Examiner respectfully submits that the previously applied combination of Hu, Deutschbein, and Thykkoottathil is sufficient to teach the claimed invention, including the newly added limitation(s). Specifically, Deutschbein teaches the amended feature “wherein if at least one security rule of the security rules is incorrect, then the at least one security rule is flaqqed for refinement”. Deutschbein teaches a system called Isadora, a security specification miner that analyzes a hardware design to observe all possible data flows and conditions in order to generate a set of security properties that will direct the flow as to prevent potential data security risks. Regarding the amended limitation, Deutschbein highlights a scenario in which Isadora’s output was compared against a set of designer-specified security properties. Each of the designer specified security properties was determined to be sub-optimal. More importantly, the comparison led to a discovery of at least one of the designer-specified security properties being violated somewhere in the data flow because the designers “determined that the design remained secure but a conditional flow had been incorrectly specified as always illegal”. In this case, Isadora also found the conditions for legality, and the observations were reported to the designers. Thus, Examiner respectfully submits that Deutschbein is sufficient to teach the amended limitation, as Isadora enabled identification of at least one security rule that was incorrect, and indicated considerations for correcting the faulty rule to be reported to the designers of the rule set.
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.
Claim(s) 1, 8, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu et al. (US 20180032760 A1), hereinafter Hu, in view of Deutschbein et al. (Deutschbein, C., Meza, A., Restuccia, F., Kastner, R., & Sturton, C. (2021). Isadora. Proceedings of the 5th Workshop on Attacks and Solutions in Hardware Security, 5–15. https://doi.org/10.1145/3474376.3487286), hereinafter Deutschbein, and Thykkoottathil et al. (Thykkoottathil, Subin, and Nagesh Ranganath (2018). Making Security Verification “SECURE”. DVCon 2018 – Design & Verification Conference, 2018. Accessed from: https://dvcon-proceedings.org/document/making-security-verification-secure/), hereinafter Thykkoottathil.
Regarding Claim 1:
Hu teaches a computer-implemented method (Hu – Paragraph [0003]: The present application describes systems and methods relating to information flow tracking and detection of unintentional design flaws of digital devices and microprocessor systems) comprising: receiving a set of security rules for a hardware design having information flow tracking logic (Hu – Paragraph [0046]: According to the implementations, security properties for a hardware design can be received in a high-level security language 213. Implementing techniques for employing a high-level programming language for specifying secure information flow and/or security properties are described in connection with FIG. 1. In the implementations, information flow control mechanisms can operate to associate the security labels 210, 212 with the data and the hardware components, or resources, within the hardware security design 200. For example, security property 213 includes labels 214, 215 and specifies a hardware-level information flow. The security property 213 specifies a particular restriction to implement a secure information flow within a hardware design); performing an information flow analysis process to determine where a design asset specified by the security rules flowed through a plurality of modules in the hardware design (Hu – Paragraph [0029]: Gate Level Information Flow Tracking (GLIFT) is an information flow tracking technology that provides the capability for analyzing the flow of information in a hardware design by tracking the data as it moves throughout the system; and Paragraph [0050]: downstream implementation operations for configuring the hardware can be realized directly from the security properties 213 as specified in the high-level security language, and without requiring the creation of a security lattice 220. According to the implementation, the high-level security language can be employed as the mechanism for mapping to security labels of a hardware design. For example, operations defined by the high-level security language can be mapped to labels of a hardware design, thereby translating the hardware design into a logic that is enabled for information flow analysis … GLIFT is employed as a security platform to implement information flow analysis on the hardware configuration); determining … that the flow of the design asset through a particular module of the plurality of modules violated one or more of the security rules (Hu – Figure 6B: Example results of a GLIFT logic simulation; and Paragraph [0085]: The simulation 600 results serve to illustrate that GLIFT precisely captures when and where key 652 leakage happened (which functional testing and verification could not do). A designer could use these results to identify the location of Trojans throughout the design by using formal proofs on the GLIFT logic to backtrack from Antena to the key; and Paragraph [0013]: The methods and systems described can employe information flow tracking techniques so as to provide gate-level logic to detect various security threats, for example hardware Trojans, which violate security properties that can be specified by designers and relating to hardware elements that may be exposed to vulnerabilities (e.g., received from untrusted sources), such as third-party IP cores. Additionally, the methods and systems described leverage a precise gate level information flow model that can be described with standard hardware description language (HDL) and verified using conventional design mechanisms; and Paragraph [0058]: As illustrated in FIG. 4A, GLIFT can be employed as the IFT technology. In this case GLIFT can precisely measures and controls all logical flows from Boolean gates. Moreover, GLIFT can be used to craft secure hardware architectures and detect security violations from timing channels. Also, GLIFT can be used to formally verify that an information flow adheres to security properties related to confidentiality and integrity … Counterexamples found during formal verification reveal harmful information flows that point to design flaws or malicious hardware Trojans that cause the system to leak sensitive information and violate data integrity; and Paragraph [0059]: The techniques diagramed in FIG. 4A can be generally characterized as having three main parts: information flow tracking (e.g., GLIFT), detection of unintentional design flaws (e.g., hardware Trojans), and the derivation of security theorems to formally prove properties. FIG. 4A illustrates a logic synthesis 410 tool that compiles an IP core 405 design to a gate-level netlist 415. Thereafter, the gate-level information-flow tracking (GLIFT) logic 420 is automatically generated. Each gate is mapped to a GLIFT logic library 425, which can be completed in linear time. The GLIFT logic is formally verified 435 against a security property 440 that the designer has written. If it passes verification (as illustrated by the arrow labeled Pass) there is no Trojan 430. If it does not (illustrated by the arrow labeled Fail), a counterexample 445 is generated, which is used to functionally test 450 the GLIFT logic to derive Trojan behavior 455); and generating a user interface (Hu – Paragraph [0105]: [0105] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input; and Paragraph [0106]: Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any combination of one or more such back-end, middleware, or front-end components) presentation that presents [a listing of the plurality of] modules through which the design asset flowed and, for a particular module … a visual indication of when the flow of the design asset through the particular module violated one or more of the security rules (Hu – Paragraph [0013]: The methods and systems described can employed information flow tracking techniques so as to provide gate-level logic to detect various security threats, for example hardware Trojans, which violate security properties that can be specified by designers and relating to hardware elements that may be exposed to vulnerabilities (e.g., received from untrusted sources), such as third-party IP cores. Additionally, the methods and systems described leverage a precise gate level information flow model that can be described with standard hardware description language (HDL) and verified using conventional design mechanisms; and Paragraph [0058]: As illustrated in FIG. 4A, GLIFT can be employed as the IFT technology. In this case GLIFT can precisely measures and controls all logical flows from Boolean gates. Moreover, GLIFT can be used to craft secure hardware architectures and detect security violations from timing channels. Also, GLIFT can be used to formally verify that an information flow adheres to security properties related to confidentiality and integrity … Counterexamples found during formal verification reveal harmful information flows that point to design flaws or malicious hardware Trojans that cause the system to leak sensitive information and violate data integrity; and Paragraph [0059]: The techniques diagramed in FIG. 4A can be generally characterized as having three main parts: information flow tracking (e.g., GLIFT), detection of unintentional design flaws (e.g., hardware Trojans), and the derivation of security theorems to formally prove properties. FIG. 4A illustrates a logic synthesis 410 tool that compiles an IP core 405 design to a gate-level netlist 415. Thereafter, the gate-level information-flow tracking (GLIFT) logic 420 is automatically generated. Each gate is mapped to a GLIFT logic library 425, which can be completed in linear time. The GLIFT logic is formally verified 435 against a security property 440 that the designer has written. If it passes verification (as illustrated by the arrow labeled Pass) there is no Trojan 430. If it does not (illustrated by the arrow labeled Fail), a counterexample 445 is generated, which is used to functionally test 450 the GLIFT logic to derive Trojan behavior 455; and Figures 6A and 6B: Example benchmark and example results of a GLIFT logic simulation associated with the benchmark; and Paragraph [0084]: FIG. 6B is a diagram of example results from GLIFT logic simulation 600 in accordance with the disclosed techniques. In some cases, a goal of a simulation 600 is to reveal how the key 652 leaks to the Antena 657 output. The key 652 flows to the Antena 657 signal, when Antena_t 658 is HIGH, denoted by the black rectangles within the boxes with dashed lines, which denote the times when Antena_t 658 is HIGH. To have no leakage, Antena_t 658 must always be LOW; and Paragraph [0085]: The simulation 600 results serve to illustrate that GLIFT precisely captures when and where key 652 leakage happened (which functional testing and verification could not do). A designer could use these results to identify the location of Trojans throughout the design by using formal proofs on the GLIFT logic to backtrack from Antena to the key).
Hu does not expressly teach performing an information flow analysis process … including populating an information flow signal database that stores security results representing to which hardware modules of the hardware design the design asset flowed wherein if at least one security rule of the security rules is incorrect, then the at least one security rule is flaqqed for refinement; determining, by querying the information flow signal database storing the security results with queries that each specify one or more individual hardware modules and security rule violations associated with the one or more hardware modules, [that the flow of the design asset through a particular module of the plurality of modules violated one or more of the security rules].
However, Deutschbein teaches performing an information flow analysis process … including populating an information flow signal database that stores security results representing to which hardware modules of the hardware design the design asset flowed (Deutschbein – Section 2.1: Isadora uses IFT at the register transfer level [6] to track data flow between registers … Tracking proceeds as follows: for each signal s in the design, a new tracking signal s^T is added along with the logic needed to track how information propagates through a design. Once the tracking signals and tracking logic are added to the design, one or more signals may be set as the information source by initializing their associated tracking signals to a nonzero value; and Section 3 and 3.1: Isadora instruments the design with IFT logic and runs the instrumented design in simulation using the user-provided set of testbenches. The result is a trace set that specifies the value of every design signal and every tracking signal at each clock cycle during simulation … To generate a trace set, the design is instrumented with IFT logic and then executed in simulation with a testbench or sequence of testbenches providing input values to the design … The state 𝜎𝑖 of the design at time 𝑖 is defined by a list of triples describing the current value of every design signal and corresponding tracking signal in the instrumented design … The end result is a set of traces for design D and testbench T: TDT = {𝜏src, 𝜏src′, 𝜏src′′, . . .}. Each trace in this set describes how information can flow from a single input signal to the rest of the signals in the design. Taken together, this set of traces describes how information flows through the design during execution of the testbench T; and Section 5.4: Information flow hardware CWEs describe source signals, sink signals, and possibly conditions. CWEs provide high level descriptions, but Isadora targets an RTL definition. To apply these high level descriptions to RTL, we first group signals for a design by inspecting Verilog files and, if available, designer notes. With the groups established, we label every property by which group-to-group flows they contain … We use these groups to find CWE-relevant, low-level signals as sources, sinks, and conditions in an Isadora property; Examiner’s Comment: the trace set(s) generated based on the flow tracking taught by Deutschbein are analogous to the claimed flow signal database in that they mirror the capability to store tuples representing the flow signals of information through a hardware design over time); wherein if at least one security rule of the security rules is incorrect, then the at least one security rule is flaqqed for refinement (Deutschbein – Section 5.3: For the Single ACW we compared Isadora’s output against security assertions developed by the AKER [39] designers using the Common Weakness Enumerations (CWE) database [1] as a guide. These assertions, the CWEs described, and the results of Isadora on the Single ACW are shown in Table 2. For each assertion Isadora mined either a property containing the assertion or found both a violation and the violating conditions for each assertion. We reported the observed violations to the designers who determined that the design remained secure but a conditional flow had been incorrectly specified as always illegal. Isadora also found the conditions for legality) determining, by querying the information flow signal database storing the security results with queries that each specify one or more individual hardware modules and security rule violations associated with the one or more hardware modules (Deutschbein – Abstract: Isadora is a methodology for creating information flow specifications of hardware designs. The methodology combines information flow tracking and specification mining to produce a set of information flow properties that are suitable for use during the security validation process … Section 2: Isadora generates two styles of information flow properties: no-flow properties, in which there is no flow of information between two design elements; and conditional-flow properties, in which there exists some flow of information between two design elements, but only when the design is in a certain state; Section 3: Then, Isadora uses an inference engine (Daikon [20]) to infer, for every flow that occurred, the predicates that specify the conditions under which the flow occurred; and Section 3.3: In the third phase, Isadora finds the conditions under which a particular flow will occur … In order to isolate the conditions for information flow between two registers, Isadora uses 𝑆_flows to find all the trace times 𝑖 at which information flows from src to s during execution of the testbench. The corresponding trace(es) are then decomposed to produce a set of trace slices that are two clock cycles in length, one for each time 𝑖 … Using trace slices, or trace windows of length two, allows dynamic invariant detection to generation predicates specifying design state both immediately prior to and concurrent with the occurrence of some flow; Examiner’s Comment: Deutschbein’s filtering of a trace set to pinpoint instances of information flow relative to conditions (including no-flow conditions) mirrors the claimed capability to query a flow signal database for locations/times at which property violations occurred during a flow), that the flow of the design asset through a particular module of the plurality of modules [violated one or more of the security rules] (Deutschbein – Section 3: Then, Isadora uses an inference engine (Daikon [20]) to infer, for every flow that occurred, the predicates that specify the conditions under which the flow occurred; and Section 3.3: In the third phase, Isadora finds the conditions under which a particular flow will occur … In order to isolate the conditions for information flow between two registers, Isadora uses 𝑆_flows to find all the trace times 𝑖 at which information flows from src to s during execution of the testbench. The corresponding trace(es) are then decomposed to produce a set of trace slices that are two clock cycles in length, one for each time 𝑖 … Using trace slices, or trace windows of length two, allows dynamic invariant detection to generation predicates specifying design state both immediately prior to and concurrent with the occurence of some flow).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hu, further incorporating Deutschbein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Deutschbein’s teaching of precise information flow tracking techniques to identify moments during a flow at which flow conditions/properties apply and should be ensured into Hu’s method for identifying security violations in a hardware design. This additional functionality would enhance Hu’s method with more precise security rules along with a method for determining the time and location during the flow at which rules were applied/violated.
The combination of Hu and Deutschbein does not expressly teach a listing of the plurality of modules.
However, Thykkoottathil teaches a user interface presentation that presents a listing of the plurality of modules through which the design asset flowed (Thykkoottathil – Figure 3: a graph view of information flow from a Source to a Destination of a hardware design, including defined hardware modules and accessible nodes in each of the modules throughout the design).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hu and Deutschbein, further incorporating Thykkoottathil to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Thykkoottathil’s teaching to display a visual representation of data flow of an asset through all modules of a hardware design into Hu and Deutschbein’s method for identifying security violations in a hardware design. This combination improves the method with further user convenience and efficiency in identifying proper and improper information flows.
Regarding Claim 8:
Claim 8 is a system claim with limitations corresponding to those of method Claim 1. Therefore, Claim 8 is rejected with the same rationale as that of the rejection of Claim 1.
Hu further teaches A system comprising: one or more computers (Hu – Paragraph [0097]: The data processing apparatus 800 also includes hardware or firmware devices including one or more processors 812, one or more additional devices 814, a computer readable medium 816, a communication interface 818, and one or more user interface devices 820) and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising (Hu – Paragraph [0097]: Each processor 812 is capable of processing instructions for execution within the data processing apparatus 800. In some implementations, the processor 812 is a single or multi-threaded processor. Each processor 812 is capable of processing instructions stored on the computer readable medium 816 or on a storage device such as one of the additional devices 814).
Regarding Claim 15:
Claim 15 is a non-transitory storage media claim with limitations corresponding to those of method Claim 1 and system Claim 8. Therefore, Claim 15 is rejected with the same rationale as that of the rejection of Claim 1 and Claim 8.
Hu further teaches one or more non-transitory computer storage media encoded with computer program instructions that when executed by one or more computers cause the one or more computers to perform operations comprising (Hu – Paragraph [0097]: Each processor 812 is capable of processing instructions for execution within the data processing apparatus 800. In some implementations, the processor 812 is a single or multi-threaded processor. Each processor 812 is capable of processing instructions stored on the computer readable medium 816 or on a storage device such as one of the additional devices 814).
Claim(s) 2-7, 9-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu in view of Deutschbein, Thykkoottathil, and Modelsim (Mentor Graphics Corporation. (2016). ModelSim® User's Manual (Software Version 10.5b). Mentor Graphics Corporation. Retrieved from https://faculty-web.msoe.edu/johnsontimoj/Common/FILES/modelsim_user.pdf), hereinafter Modelsim.
Regarding Claim 2:
The combination of Hu, Deutschbein, and Thykkoottathil teaches the method of claim 1.
The combination of Hu, Deutschbein, and Thykkoottathil does not expressly teach wherein the user interface presentation visually illustrates how long the design asset was held by each module.
However, Modelsim teaches wherein the user interface presentation visually illustrates how long the design asset was held by each module (ModelSim – P. 359: Event Time — the time intervals that show each object value change as a separate event and that shows the relative order in which these changes occur; and Figure 9-8: example of waveform view of event time and/or delta time).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hu, Deutschbein, and Thykkoottathil, further incorporating Modelsim to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Modelsim’s teaching of an interface that provides a user with an in-depth display of a user-specified circuit design simulation into Hu, Deutschbein, and Thykkoottathil’s method for identifying security violations in a hardware design. This combined functionality would provide a user with precision insight into potential flaws and security vulnerabilities in a tested hardware design.
Regarding Claim 3:
The combination of Hu, Deutschbein, Thykkoottathil, and Modelsim teaches the method of claim 2.
Modelsim further teaches wherein the user interface presentation visually distinguishes the design asset from other signals (Modelsim – P. 374: Note that the buttons in this dialog box allow you to determine the display of signals you want to put into an expression: • List only Select Signals — list only those signals that are currently selected in the parent window. • List All Signals — list all signals currently available in the parent window).
The motivation to combine the arts is the same as that of Claim 2.
Regarding Claim 4:
The combination of Hu, Deutschbein, and Thykkoottathil teaches the method of Claim 1.
The combination of Hu, Deutschbein, and Thykkoottathil does not expressly teach further comprising: receiving a selection of a particular module of the listing of the plurality of modules; and generating a waveform view that illustrates signals within the selected module and visually distinguishes signals carrying the design asset within the module.
However, Modelsim teaches further comprising: receiving a selection of a particular module of the listing of the plurality of modules (Modelsim – P. 428: A primary use of the Dataflow window is exploring the “physical” connectivity of your design. One way of doing this is by expanding the view from process to process. This allows you to see the drivers/readers of a particular signal, net, or register. You can expand the view of your design using menu commands or your mouse. To expand with the mouse, simply double click a signal, register, or process. Depending on the specific object you click, the view will expand to show the driving process and interconnect, the reading process and interconnect, or both. Alternatively, you can select a signal, register, or net, and use one of the toolbar buttons or drop down menu commands described in Table 10-1); and generating a waveform view that illustrates signals within the selected module and visually distinguishes signals carrying the design asset within the module (Modelsim – P. 433, Figure 10-8: Wave Viewer displaying inputs and outputs of a selected process).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hu, Deutschbein, and Thykkoottathil, further incorporating Modelsim to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Modelsim’s teaching of an interface that provides a user with an in-depth display of a user-specified circuit design simulation into Hu, Deutschbein, and Thykkoottathil’s method for identifying security violations in a hardware design. This addition would provide yet further insight into potential flaws and security vulnerabilities in a tested hardware design.
Regarding Claim 5:
The combination of Hu, Deutschbein, Thykkoottathil, and Modelsim teaches the method of claim 4.
Modelsim further teaches further comprising generating a waveform view that illustrates forward loads from one of the signals within the selected module (Modelsim – P. 433, Figure 10-8: Wave Viewer displaying inputs and outputs of a selected process).
The motivation to combine the arts is the same as that of Claim 4.
Regarding Claim 6:
The combination of Hu, Deutschbein, Thykkoottathil, and Modelsim teaches the method of claim 5.
Modelsim further teaches further comprising: receiving a user interface selection of a particular signal (Modelsim – P. 374: Note that the buttons in this dialog box allow you to determine the display of signals you want to put into an expression: • List only Select Signals — list only those signals that are currently selected in the parent window. • List All Signals — list all signals currently available in the parent window); and generating a path view that illustrates a path taken by the design asset through the design (Modelsim – P. 431, Figure 10-6: illustration of a highlighted path of a tracked signal).
The motivation to combine the arts is the same as that of Claim 4.
Regarding Claim 7:
The combination of Hu, Deutschbein, Thykkoottathil, and Modelsim teaches the method of claim 6.
Modelsim further teaches wherein the path view illustrates how the design asset flows from an origin through a plurality of design resources to the particular signal (Modelsim – P. 431, Figure 10-6: illustration of a highlighted path of a tracked signal).
The motivation to combine the arts is the same as that of Claim 4.
Regarding Claim 9:
Claim 9 is a system claim with limitations corresponding to those of method Claim 2. Therefore, Claim 9 is rejected with the same combination and rationale as that of the rejection of Claim 2.
Regarding Claim 10:
Claim 10 is a system claim with limitations corresponding to those of method Claim 3. Therefore, Claim 10 is rejected with the same combination and rationale as that of the rejection of Claim 3.
Regarding Claim 11:
Claim 11 is a system claim with limitations corresponding to those of method Claim 4. Therefore, Claim 11 is rejected with the same combination and rationale as that of the rejection of Claim 4.
Regarding Claim 12:
Claim 12 is a system claim with limitations corresponding to those of method Claim 5. Therefore, Claim 12 is rejected with the same combination and rationale as that of the rejection of Claim 5.
Regarding Claim 13:
Claim 13 is a system claim with limitations corresponding to those of method Claim 6. Therefore, Claim 13 is rejected with the same combination and rationale as that of the rejection of Claim 6.
Regarding Claim 14:
Claim 14 is a system claim with limitations corresponding to those of method Claim 7. Therefore, Claim 14 is rejected with the same combination and rationale as that of the rejection of Claim 7.
Regarding Claim 16:
Claim 16 is a system claim with limitations corresponding to those of method Claim 2 and system Claim 9. Therefore, Claim 16 is rejected with the same combination and rationale as that of the rejection of Claim 2 and Claim 9.
Regarding Claim 17:
Claim 17 is a system claim with limitations corresponding to those of method Claim 3 and system Claim 10. Therefore, Claim 17 is rejected with the same combination and rationale as that of the rejection of Claim 3 and Claim 10.
Regarding Claim 18:
Claim 18 is a system claim with limitations corresponding to those of method Claim 4 and system Claim 11. Therefore, Claim 18 is rejected with the same combination and rationale as that of the rejection of Claim 4 and Claim 11.
Regarding Claim 19:
Claim 19 is a system claim with limitations corresponding to those of method Claim 5 and system Claim 12. Therefore, Claim 19 is rejected with the same combination and rationale as that of the rejection of Claim 5 and Claim 12.
Regarding Claim 20:
Claim 20 is a system claim with limitations corresponding to those of method Claim 6 and system Claim 13. Therefore, Claim 20 is rejected with the same combination and rationale as that of the rejection of Claim 6 and Claim 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hu et al. (Hu, W., Ardeshiricham, A., Gobulukoglu, M. S., Wang, X., & Kastner, R. (2018). Property specific information flow analysis for hardware security verification. Proceedings of the International Conference on Computer-Aided Design, 1–8. https://doi.org/10.1145/3240765.3240839) teaches techniques for enhancing efficiency in detecting security vulnerabilities in hardware designs by eliminating properties that are not applicable to the design being observed, thus only producing false positive indications
Andraus et al. (US 20130145328 A1) teaches systems and methods for verifying abstractions of hardware designs, the verifications including identifying false positive property violations in order to refine the abstractions
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights