DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Claim rejections - 35 USC § 112
The previously raised rejections under 35 U.S.C. § 112(a) enablement to claims 1-23 have been overcome by Applicant’s amendment and are therefore withdrawn.
Claim rejections - 35 USC § 103
Applicant’s arguments filed on 4/30/2026, directed at the amended claims submitted on 4/30/2026 were considered, but are moot in view of new rejections made below in response to the latest amendments by applicant.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 4, 9, 10, 12-14, 16, 21 and 22 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Ofek (US 2019/0303585).
Regarding claims 1, 12 and 13, Ofek teaches A method for mitigating vulnerabilities and exposures (see [0002]: “At least some embodiments of systems, methods, apparatus, and/or code instructions described herein, relate to code weakness mitigation and, more specifically, but not exclusively, to mitigation of firmware and/or software weaknesses and software vulnerabilities”), comprising:
enforcing at least one policy (see [0073] and Fig. 1: “Policy dataset 106E. Each micro functionality fix 106D or location may be associated with a respective policy 106D for mitigating a respective code weakness, for instance in response to receiving a signal from IDS 150 or another component and/or device.” And see [0056]: “Reference is now made to FIG. 1, which is a block diagram of components of a system 100 for mitigating code weaknesses in a target code 106A by a protected device 104 by adding micro functionality fixes 106D, optionally implemented by using hooks, for execution in run time optionally based on policies 106E implemented for example as conditional statements in exact memory locations in a running memory 106 where the code weaknesses (e.g. CVEs and/or CWEs) are optionally identified by a static analysis tool 152”) in a computing infrastructure (see [0056] and Fig. 1: “a system 100 for mitigating code weaknesses in a target code 106A by a protected device 104”), wherein the at least one policy causes code releases in the computing infrastructure to incorporate instances of an artifact when enforced, wherein the artifact includes a set of executable instructions such that a copy of the set of executable instructions of the artifact is included in the code releases when the code releases incorporate instances of the artifact (see [0070]: “Mitigation module 106B may be installed to access target code 106A at device 104 in runtime. The mitigation module receives configuration instructions 106C which include list or a dataset defining one or more memory locations in memory chip 106 hosting target code 106A and micro functionality fixes 106D each defined to be installed on one of the locations.” And see [0072]: “Each micro functionality fix 106D may be optionally a fix of, for example, 2-6 (or 1-10, or 3-12, or other ranges) code lines that set a function to be left unexecuted or semi executed so as to avoid performing one of the detected code weaknesses.” And see [0089]: “The static analysis tool may be optionally a part of a build system including the target code ….” The Examiner interprets target code 106A as code releases. The Examiner further interprets a micro functionality fix 106D as the artifact.), wherein the artifact is used as a hook to make changes at least during runtime (see [0056]: “Reference is now made to FIG. 1, which is a block diagram of components of a system 100 for mitigating code weaknesses in a target code 106A by a protected device 104 by adding micro functionality fixes 106D, optionally implemented by using hooks, for execution in run time optionally based on policies 106E implemented for example as conditional statements in exact memory locations in a running memory 106 where the code weaknesses (e.g. CVEs and/or CWEs) are optionally identified by a static analysis tool 152”);
determining at least one mitigation action for mitigating a first vulnerable state using a mitigation knowledge base (see [0094] and Fig. 2: “At 206, the configuration instructions are created, optionally by the server. The configuration instructions may be created, optionally automatically. For example, known fixes to the identified weaknesses are stored in a dataset.” And see [0073] and Fig. 1: “Policy dataset 106E. Each micro functionality fix 106D or location may be associated with a respective policy 106D for mitigating a respective code weakness, for instance in response to receiving a signal from IDS 150 or another component and/or device.” The Examiner interprets the policy dataset 106E as a mitigation knowledge base.), wherein the mitigation knowledge base defines a plurality of mitigation actions for each of a plurality of second vulnerable states, wherein the plurality of mitigation actions defined for each second vulnerable state includes at least one mitigation action for a plurality of mitigation engines (see [0096]: “The configuration instructions include instruction to install micro functionality fixes, for example by using software hooks, in these specific locations of the identified code weaknesses. Optionally a single micro functionality fix may be installed for each identified code weakness location. Alternatively, multiple micro functionality fixes are installed for a single code weakness location, where each fix may be selectively activated according to the policy.” The Examiner interprets multiple micro functionality fixes installed for a single code weakness location as a plurality of mitigation actions for each of a plurality of second vulnerable states. Also see [0017]: “two or more micro functionality fixes are installed for a single code weakness location, and a policy defines conditions for selectively activation each one of the two or more micro functionality fixes.” The Examiner interprets the two or more micro functionality fixes for a single code weakness location as a plurality of mitigation engines.); and
performing the at least one mitigation action via at least one mitigation engine of the plurality of mitigation engines (see [0098]: “Each micro functionality fix may be optionally provided with a policy such as a conditional statement, so as to be activated to prevent a specific code weakness from being executed, for instance when one or more conditions are met. For example, it fixes a respective code weakness. The conditional statement defines logic to trigger the micro functionality fix in the software hook. For instance, the conditional statement changes a state of the micro functionality fix to an active state from a non active state when a signal from a monitoring system may be identified. The conditional statement may selectively trigger one of multiple fixes.”), wherein the at least one mitigation action is performed by executing at least a portion of the executable code of the artifact (see [0072]: “Each micro functionality fix 106D may be optionally a fix of, for example, 2-6 (or 1-10, or 3-12, or other ranges) code lines that set a function to be left unexecuted or semi executed so as to avoid performing one of the detected code weaknesses.”).
Regarding claims 2 and 14, Ofek further teaches causing deployment of at least one instance of an artifact in a computing infrastructure (see [0099]: “At 208, the configuration instructions (e.g., file) are provided to the mitigation module (e.g., of the device), for example, transmitted by the server to the device over the network.” And see [0097]: “The configuration file includes one or more memory locations of one or more code weaknesses optionally obtained from the code analysis tool. Each memory location may represent a memory location of a CVE and/or a CWE in the target code. The configuration instructions further includes for each of the memory locations a micro functionality fix (e.g., a single fix or multiple fixes) or a reference thereto (referred to herein interchangeably), for instance a software hook for enabling the micro functionality fix.”), wherein the at least one mitigation action is performed via the deployed at least one instance of the artifact (see [0105]: “The mitigation module installs the micro functionality fix(s) in the respective code location(s) of the respective code weakness(s) in the running memory”. And see [0072]: “Each micro functionality fix 106D may be optionally a fix of, for example, 2-6 (or 1-10, or 3-12, or other ranges) code lines that set a function to be left unexecuted or semi executed so as to avoid performing one of the detected code weaknesses.”).
Regarding claims 4 and 16, Ofek further teaches defining the artifact via a set of executable instructions (see [0072]: “Each micro functionality fix 106D may be optionally a fix of, for example, 2-6 (or 1-10, or 3-12, or other ranges) code lines that set a function to be left unexecuted or semi executed so as to avoid performing one of the detected code weaknesses.” The Examiner interprets a micro functionality fix 106D as the artifact.); wherein the at least one instance of the artifact is deployed via the enforcement of the at least one policy (see [0073] and Fig. 1: “Policy dataset 106E. Each micro functionality fix 106D or location may be associated with a respective policy 106D for mitigating a respective code weakness, for instance in response to receiving a signal from IDS 150 or another component and/or device.”).
Regarding claims 9 and 21, Ofek further teaches wherein the plurality of mitigation engines includes a runtime mitigation engine, wherein the determined at least one mitigation action includes altering executable code at runtime ([0130]: “In use, the code analysis tool (e.g., 202 of FIG. 2) detects a memory location (e.g., 204 of FIG. 2) of a system call usage in the application, and sends this memory location together with execution policy such as blocking upon receiving an IDS signal, to the mitigation module (e.g., 208 of FIG. 2). Blocking can be simply performed by few lines of code causing a respective function to immediately return before it reaches a vulnerability point.” And see [0106]: “An executed micro functionality fix may include a small amount (e.g. 1-6 lines) of machine code lines which are added at a code weakness memory location for altering a functionality triggering a code weakness in the code weakness memory location.”).
Regarding claims 10 and 22, Ofek further teaches wherein the altering of the executable code at runtime includes modifying at least one of: at least one function (see [0106]: “An executed micro functionality fix may include a small amount (e.g. 1-6 lines) of machine code lines which are added at a code weakness memory location for altering a functionality triggering a code weakness in the code weakness memory location.”), and at least one rule.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ofek (US 2019/0303585), and further in view of Banzhof (US 2006/0101517).
Regarding claims 3 and 15, Ofek fails to teach wherein the at least one instance of the artifact is configured to track mitigation activities performed in the computing infrastructure in order to create a record of the mitigation activities performed in the computing infrastructure, wherein the at least one mitigation action is determined based on the record.
In the same field of endeavor, Banzhof discloses wherein the at least one instance of the artifact is configured to track mitigation activities performed in the computing infrastructure in order to create a record of the mitigation activities performed in the computing infrastructure, wherein the at least one mitigation action is determined based on the record (see [0058]: “It is further contemplated that the client remediation server 22 will maintain a profile of the computer systems 26A, 26B and 26C which rely on the client remediation server 22 for vulnerability resolution using the downloaded action packs and/or the remediation signatures contained in the downloaded vulnerability/remediation entries. Generally speaking, each of these profiles consists of a record or log of system information related to a respective one of the computer systems 26A, 26B and 26C. More specifically, the profile for any given one of the computer systems 26A, 26B and 26C will contain information related to remediations performed on that computer system 26A, 26B or 26C.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Ofek so that the at least one instance of the artifact is configured to track mitigation activities performed in the computing infrastructure in order to create a record of the mitigation activities performed in the computing infrastructure, wherein the at least one mitigation action is determined based on the record, as taught by Banzhof. It would have been obvious because Banzhof teaches that doing so achieves the following benefit: “The remediations performed by the action packs and/or remediation signatures can be tracked and logged so that remediations are not accidentally overwritten or undone” (see Banzhof [0065]). Additionally, Banzhof teaches that doing so achieves the following benefit: “The profiles are also useful when remediating the computer network without the use of action packs or in conjunction with the use of action packs. More specifically, by comparing profiles for the computer system 26A, 26B or 26C with the remediation signatures contained in the vulnerability/remediation entries downloaded from the VFLASH server 20, the vulnerability information acquired by the client remediation server 22, for example, by scans of the computer systems 26A, 26B and 26C by a vulnerability assessment tool, and, if appropriate, the action packs which have already been executed and the vulnerabilities to have been resolved by those action packs, the client remediation server 22 will be able to determine which remediation or remediations are required for each computer system 26A, 26B, 26C of the computer network 19 to resolve identified vulnerabilities associated therewith, particularly, those which have not been resolved by execution of one or more action packs.” (see Banzhof [0060]).
Claims 5-8, 11, 17-20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Ofek (US 2019/0303585), and further in view of Criscione (US 2022/0345477).
Regarding claims 5 and 17, Ofek fails to teach performing impact analysis on the first vulnerable state in order to determine an impact score for the first vulnerable state, wherein the at least one mitigation action is performed based on the impact score for the first vulnerable state.
In the same field of endeavor, Criscione discloses performing impact analysis on the first vulnerable state in order to determine an impact score for the first vulnerable state, wherein the at least one mitigation action is performed based on the impact score for the first vulnerable state (see [0030]: “the rule 150 may designate the risk or a risk level associated with the specific vulnerability V for the rule 150. Here, the risk may be represented as some designated value on a scale that indicates a range of risk from no risk (or “low” risk) to significant risk (e.g., “high” risk). As shown in FIG. 2B, there may be rules 150, such as the fourth rule 150d, that designate both the risk for the specific vulnerability V corresponding to the rule 150 and the importance of the target resource 132T identified by the rule 150.” And see [0036]: “the actuator 230 determines which rule 150 of the multiple rules 152 to apply as an action 232 by scoring each rule 150 based on scoring criteria 234. …the criteria 232 includes a risk for the vulnerability V and/or the importance of the target resource 132T.” And see [0037]: “For the first rule 150a, the actuator 230 generates a first mitigation action 232, 232a and a first score 236, 236a for the first mitigation action 232a. Similarly, the actuator 230 generates a second mitigation action 232, 232b for the fourth rule 150a and a second score 236, 236b for the second mitigation action 232b. Since the actuator 230 may implement either of these mitigation actions 232a, 232b, the actuator 230 determines which action 232 has a better score 236. …In the example of FIG. 2B, the criteria 234 that the actuator 230 uses to generate the score 236 is a first criteria 234, 234a that refers to a risk for the particular vulnerability V”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Ofek by adding the step of performing impact analysis on the first vulnerable state in order to determine an impact score for the first vulnerable state, wherein the at least one mitigation action is performed based on the impact score for the first vulnerable state, which is taught by Criscione. It would have been obvious because doing so predictably achieves the commonly understood benefit of prioritizing the mitigation of the vulnerable state with the greatest impact.
Regarding claims 6 and 18, Ofek fails to teach wherein the at least one mitigation action is at least one first mitigation action, further comprising: prioritizing the at least one first mitigation action with respect to a plurality of second mitigation actions based on the impact analysis.
In the same field of endeavor, Criscione discloses wherein the at least one mitigation action is at least one first mitigation action, further comprising: prioritizing the at least one first mitigation action with respect to a plurality of second mitigation actions based on the impact analysis (see [0037]: “For the first rule 150a, the actuator 230 generates a first mitigation action 232, 232a and a first score 236, 236a for the first mitigation action 232a. Similarly, the actuator 230 generates a second mitigation action 232, 232b for the fourth rule 150a and a second score 236, 236b for the second mitigation action 232b. Since the actuator 230 may implement either of these mitigation actions 232a, 232b, the actuator 230 determines which action 232 has a better score 236. Here, the actuator 230 is shown selecting the second mitigation action 232b to be implemented as the mitigation action 232 because the second mitigation action 232b has a superior score 236 when compared to the score 236a of the first mitigation action 232a. …Additionally, FIG. 2B illustrates that the criteria 234 used by the actuator 230 (e.g., to form the score 236) may be generated or obtained at the rule engine 220. …In the example of FIG. 2B, the criteria 234 that the actuator 230 uses to generate the score 236 is a first criteria 234, 234a that refers to a risk for the particular vulnerability V”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Ofek by letting the at least one mitigation action be at least one first mitigation action, further comprising: prioritizing the at least one first mitigation action with respect to a plurality of second mitigation actions based on the impact analysis, as taught by Criscione. It would have been obvious because doing so predictably achieves the commonly understood benefit of prioritizing the mitigation of the vulnerable state with the greatest impact.
Regarding claims 7 and 19, Ofek fails to teach selecting the at least one mitigation engine from among the plurality of mitigation engines based on the prioritizing of the at least one first mitigation action with respect to the plurality of second mitigation actions.
In the same field of endeavor, Criscione discloses selecting the at least one mitigation engine from among the plurality of mitigation engines based on the prioritizing of the at least one first mitigation action with respect to the plurality of second mitigation actions (see [0037]: “For the first rule 150a, the actuator 230 generates a first mitigation action 232, 232a and a first score 236, 236a for the first mitigation action 232a. Similarly, the actuator 230 generates a second mitigation action 232, 232b for the fourth rule 150a and a second score 236, 236b for the second mitigation action 232b. Since the actuator 230 may implement either of these mitigation actions 232a, 232b, the actuator 230 determines which action 232 has a better score 236. Here, the actuator 230 is shown selecting the second mitigation action 232b to be implemented as the mitigation action 232 because the second mitigation action 232b has a superior score 236 when compared to the score 236a of the first mitigation action 232a.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Ofek by adding the step of selecting the at least one mitigation engine from among the plurality of mitigation engines based on the prioritizing of the at least one first mitigation action with respect to the plurality of second mitigation actions, which is taught by Criscione. It would have been obvious because doing so predictably achieves the commonly understood benefit of prioritizing the mitigation of the vulnerable state with the greatest impact.
Regarding claims 8 and 20, Ofek fails to teach teaches wherein the plurality of mitigation engines includes a reachability mitigation engine, wherein the determined at least one mitigation action includes adjusting a configuration of at least one component in a path of reachability between the first vulnerable state and at least one asset.
In the same field of endeavor, Criscione discloses wherein the plurality of mitigation engines includes a reachability mitigation engine, wherein the determined at least one mitigation action includes adjusting a configuration of at least one component in a path of reachability between the first vulnerable state and at least one asset (see [0029]: “For the sake of explanation, if the vulnerability V relates to client data access, the client 10 may configure or communicate a rule 150 (e.g., the first rule 150a) that the access point or pathway be disconnected when this vulnerability V is present. On the other hand, if the target resource 132T that is vulnerable to unauthorized access is a not a sensitive or critical resource 132T, then the client 10 may configure or communicate a rule 150 (e.g., the third rule 150c) that the target resource 132T is relocated to a location that is more secure than its current location or that the target resource 132T receives increased monitoring.” Also see [0031]: “For instance, the mitigation action 232 may take the target resource 132T offline so that it is not accessible to external entities (e.g., exposed to the Internet) or to restrict all access to the target resource 132T.” ).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Ofek by letting the plurality of mitigation engines include a reachability mitigation engine, wherein the determined at least one mitigation action includes adjusting a configuration of at least one component in a path of reachability between the first vulnerable state and at least one asset, as taught by Criscione. It would have been obvious because doing so predictably achieves the commonly understood benefit of securing the at least one asset.
Regarding claims 11 and 23, Ofek fails to teach wherein the plurality of mitigation engines includes a compiler time mitigation engine, wherein the determined at least one mitigation action includes altering compiler time code.
In the same field of endeavor, Criscione discloses wherein the plurality of mitigation engines includes a compiler time mitigation engine, wherein the determined at least one mitigation action includes altering compiler time code (see [0029]: “The criteria and/or rule 150 may be implemented as code or as any type of automation dialect supported by the cloud service provider of the cloud environment 130.” And see [0038]: “The vulnerability manager 200 is an automated migration system in that the operations of the detector 210, the rule engine 220, and the actuator 230 occur without human intervention or requiring additional decision making input. That is, once the rules 150 have been setup for the rule engine 220, the vulnerability manager 200 automatically applies the designated set of rules 150 to a vulnerability V for a particular target resource 132T indiscriminately. … Therefore, in some examples, an organization implementing the vulnerability manager 200 provides a vulnerability-specific code or information so that only exploitation attempts targeting the specific vulnerability are blocked.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Ofek by letting the plurality of mitigation engines include a compiler time mitigation engine, wherein the determined at least one mitigation action includes altering compiler time code, as taught by Criscione. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHIMEI ZHU whose telephone number is (571)270-7990. The examiner can normally be reached 10am-6pm Monday-Friday.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/ZHIMEI ZHU/Examiner, Art Unit 2495
Prosecution Insights