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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/12/2026 has been entered.
Response to Arguments
Claim objections
The previously raised objections to claims 4 and 16 have been overcome by Applicant’s amendment and are therefore withdrawn.
Claim rejections - 35 USC 112
Applicant's arguments filed on 1/12/2026 have been fully considered but they are not persuasive.
Specifically, Applicant argues the following:
“The Final Office Action dated October 10, 2025 (hereinafter the ‘Final Office Action’) asserts that independent claims 1, 12, and 13 contain features that fail to comply with the enablement requirement”. (Remarks, page 1, last ¶)
…
“To ensure that the features explicitly recited in the claims align with the specification, applicant has amended the claims to recite ‘wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions.’” (Remarks, page 3, ¶ 2)
“These amendment clarifies (1) that the artifact (which includes executable instructions) is defined as part of (in) a code signing certificate, (2) that the code signing certificate defining the artifact is used to sign the code, and (3) that the result is a signature including a copy of the executable instructions of the artifact.” (Remarks, page 3, ¶ 3)
The Examiner respectfully responds: because a code signing certificate does not include executable instructions, an artifact that includes executable instructions cannot be part of a code signing certificate. In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. RFC 5280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (May 2008) Section 4.1 shows the following basic fields of a X.509 certificate:
PNG
media_image1.png
753
1289
media_image1.png
Greyscale
PNG
media_image2.png
758
867
media_image2.png
Greyscale
As seen above, the basic fields of a X.509 certificate do not include any executable instructions. Therefore, the artifact that includes executable instructions recited in claims 1, 12 and 13 cannot be part of a code signing certificate. In other words, there is no existence of working examples for an artifact comprising executable instructions being part of a code signing certificate. Therefore, undue experimentation is needed to make or use the invention based on the content of the disclosure. Thus, independent Claims 1, 12 and 13 and their dependent claims are not enabled by the disclosure.
Claim rejections - 35 USC 103
Applicant's arguments filed on 1/12/2026 have been fully considered but they are not persuasive.
Specifically, Applicant argues the following:
“the amended claim features clarify that the artifact is defined in a code signing certificate and that the code signing certificate is used to sign code releases such that the signature includes a copy of the set of executable instructions of the artifact. That is, the claim does not recite that the artifact is signed and, instead, that the artifact is defined in a code signing certificate which is used to sign code releases”. (Remarks, page 5, ¶ 4)
“Thus, Kalle does not teach enforcing a policy that causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced as claimed.” (Remarks, page 5, ¶ 5)
The Examiner respectfully responds: Kalle discloses in [0058]: “the O-RAN SI trust broker 400 is configured to receive signed artifacts from the plurality of vendors 300. For example, upon building a software image and upon performing a successful image scan for vulnerability, a vendor signs the software image and pushes or transmits the signed image to the O-RAN SI trust broker 400. Here, the vendor may sign the software image with a private key, and may transmit the software image with a digital certificate (e.g., X.509 certificate) issued by the vendor's certificate authority (CA). The signature may correspond to a hash value (or digest) obtained by applying a predetermined hash function to the software image and encrypted using the private key. According to an embodiment, the vendor may transmit the software image together with the digital certificate and an encrypted signature (encrypted using the vendor's private key corresponding to the public key included in the digital certificate).” Because the code signature of Kalle is generated by encrypting the hash of the code with the vendor's private key corresponding to the public key included in the code signing certificate, and an artifact is part of a code signing certificate according to Applicant’s argument filed on 1/12/2026, Kalle teaches enforcing at least one policy in a computing infrastructure, wherein the at least one policy causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced, wherein the artifact includes a set of executable instructions, wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact, wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions, as recited in claims 1, 12 and 13.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Independent Claims 1, 12 and 13 recite “enforcing at least one policy in a computing infrastructure, wherein the at least one policy causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced, wherein the artifact includes a set of executable instructions, wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact, wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions”. The only explanation on this claim limitation in the specification is the following excerpt:
[0078] Once the artifact has been defined, instructions of the artifact may be incorporated into code releases via signing and utilized to implement various disclosed embodiments. To this end, the artifact may be defined as part of a code signing certificate or other piece of data to be used for signing code releases such that any signatures signed using that certificate or data includes an instance of the artifact in the form of a copy of the executable code of the artifact.
In order to determine compliance with the enablement requirement of 35 U.S.C. 112(a), the Federal Circuit developed a framework of factors in In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988), referred to as the Wands factors to assess whether any necessary experimentation required by the specification is "reasonable" or is "undue." These factors include, but are not limited to:
(A) The breadth of the claims;
(B) The nature of the invention;
(C) The state of the prior art;
(D) The level of one of ordinary skill;
(E) The level of predictability in the art;
(F) The amount of direction provided by the inventor;
(G) The existence of working examples; and
(H) The quantity of experimentation needed to make or use the invention based on the content of the disclosure.
Regarding factor (F), the inventor provided no direction on how to define an artifact comprising executable instructions as part of a code signing certificate or other piece of data to be used for signing code releases.
Regarding factor (G), there is no existence of working examples for “code releases in the computing infrastructure to be signed using instances of an artifact”. Because a code signing certificate does not include executable instructions, an artifact that includes executable instructions cannot be part of a code signing certificate. In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. RFC 5280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (May 2008) Section 4.1 shows the following basic fields of a X.509 certificate:
PNG
media_image1.png
753
1289
media_image1.png
Greyscale
PNG
media_image2.png
758
867
media_image2.png
Greyscale
As seen above, the basic fields of a X.509 certificate do not include any executable instructions. Therefore, the artifact that includes executable instructions recited in claims 1, 12 and 13 cannot be part of a code signing certificate. Because there is no existence of working examples for an artifact comprising executable instructions being part of a code signing certificate, undue experimentation is needed to make or use the invention based on the content of the disclosure.
Thus, independent Claims 1, 12 and 13 and their dependent claims are not enabled by the disclosure.
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 1, 2, 4-8, 11-14, 16-20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Criscione (US 2022/0345477), and further in view of Kalle (US 2024/0104192).
Regarding claims 1, 12 and 13, Criscione teaches A method for mitigating vulnerabilities and exposures (see title: “Automatic Vulnerability Mitigation In Cloud Environments”), comprising:
determining at least one mitigation action for mitigating a first vulnerable state (see [0024] and Fig. 1: “The vulnerability monitor 140 of the vulnerability system 100 is configured to evaluate a security state of the cloud environment 130. … Here, the security state refers to an analysis as to whether the cloud environment 130 include some asset or resource 132 with a particular weakness of vulnerability V.” And see [0039] and FIG. 3: “At operation 302, the method 300 receives an indication 142 that a target resource 132T includes a vulnerability V.”) using a mitigation knowledge base, wherein the mitigation knowledge base defines a plurality of mitigation actions for each of a plurality of second vulnerable states (see [0039] and FIG. 3: “At operation 304, the method 300 receives a plurality of rules 150, 150a-n configured to mitigate vulnerabilities for cloud environment resources 132. At operations 306, the method 300 determines whether the plurality of rules 150, 150a-n includes one or more rules 150 corresponding to the vulnerability V of the target resource 132T. At operation 308, when the plurality of rules 150, 150a-n includes the one or more rules 150 corresponding to the vulnerability V of the target resource 132T, the method 300 applies a reversible mitigation action 232 associated with a respective rule 150 of the one or more rules 150 corresponding to the vulnerability V of the target resource 132T.” The Examiner interprets “a plurality of rules 150, 150a-n configured to mitigate vulnerabilities for cloud environment resources 132” taught in operation 304 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. The Examiner further interprets “when the plurality of rules 150, 150a-n includes the one or more rules 150 corresponding to the vulnerability V of the target resource 132T, the method 300 applies a reversible mitigation action 232 associated with a respective rule 150 of the one or more rules 150 corresponding to the vulnerability V of the target resource 132T” taught in operation 308 as determining at least one mitigation action for mitigating a first vulnerable state using 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 [0028] and Fig. 2B: “The rules 150 may refer to a set of desired outcomes for when particular vulnerabilities V are present in a resource 132 of the cloud environment 130. Some examples of rules 150 includes rules 150 that define access restrictions (e.g., limit access to the target resource 132T to a specific country, authenticated user(s), etc.), rules 150 that generate notifications or alerts (e.g., sent to a security operations center (SOC), an administrator of the cloud environment 130 or client data, or other types of owners with oversight controls regarding the target resource 132T), rules 150 that trigger some level of monitoring (e.g., increased monitoring) of the target resource 132T, rules 150 that initiate logs (e.g., logs of resource behavior or network traffic), rules 150 that generate a forensic-relevant snapshot (e.g., at some frequency or instance in time), or rules 150 that compound two or more rules 150 together.” The Examiner interprets rules 150 that define access restrictions, rules 150 that generate notifications or alerts, ), rules 150 that trigger some level of monitoring, rules 150 that generate a forensic-relevant snapshot and rules 150 that compound two or more rules 150 together 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 [0031] and Fig. 2: “when the plurality of rules 150 include one or more rules that correspond to the vulnerability V of the target resource 132T (or are deemed applicable by the rule engine 220), the actuator 230 apples a mitigation action 232 associated with a respective rule 150 (e.g., one of the applicable rules 150 from the rule engine 220) of the one or more rules 150 corresponding to the vulnerability V of the target resource 132T (e.g., applies a rule 150 deemed applicable by the rule engine 220).”).
Criscione fails to teach enforcing at least one policy in a computing infrastructure, wherein the at least one policy causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced, wherein the artifact includes a set of executable instructions, wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact, wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions.
However, Kalle discloses enforcing at least one policy in a computing infrastructure (see [0062] and Fig. 3: “Because there is a trust relationship between the O-RAN SI trust broker 400 and the O-RAN system 500 (e.g., telco operator, O-RAN operator, and/or O-Cloud operator), the software can be verified by verifying the image signature using the trust broker CA certificate before installation in the O-RAN system 500.” The Examiner interprets the O-RAN system 500 as a computing infrastructure. The Examiner further interprets “the software can be verified by verifying the image signature using the trust broker CA certificate before installation in the O-RAN system 500” as enforcing at least one policy in a computing infrastructure.),
wherein the at least one policy causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced (see [0085] and Fig. 7: “At (6), the O-RAN trust broker policy engine signs the image. This process is repeated for each of the O-RAN software images (artifacts) from multiple suppliers. For example, this process may be as described above with reference to FIG. 6. The signed artifacts may be stored in the O-RAN SI registry.”),
wherein the artifact includes a set of executable instructions, wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact (see [0057] and Fig. 3: “The O-RAN SI trust broker 400 is configured to receive software or software components (artifacts) provided by the plurality of O-RAN vendors 300”. Kalle discloses that artifacts include software or software components. Additionally, software or software components include a set of executable instructions. Therefore, Kalle teaches wherein the artifact includes a set of executable instructions. Because Kalle teaches signing artifacts, Kalle also discloses wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact),
wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions (Kalle discloses in [0058]: “the O-RAN SI trust broker 400 is configured to receive signed artifacts from the plurality of vendors 300. For example, upon building a software image and upon performing a successful image scan for vulnerability, a vendor signs the software image and pushes or transmits the signed image to the O-RAN SI trust broker 400. Here, the vendor may sign the software image with a private key, and may transmit the software image with a digital certificate (e.g., X.509 certificate) issued by the vendor's certificate authority (CA). The signature may correspond to a hash value (or digest) obtained by applying a predetermined hash function to the software image and encrypted using the private key. According to an embodiment, the vendor may transmit the software image together with the digital certificate and an encrypted signature (encrypted using the vendor's private key corresponding to the public key included in the digital certificate).” Because the code signature of Kalle is generated by encrypting the hash of the code with the vendor's private key corresponding to the public key included in the code signing certificate, Kalle teaches wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions).
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 Criscione by adding the step of enforcing at least one policy in a computing infrastructure, wherein the at least one policy causes code releases in the computing infrastructure to be signed using instances of an artifact when enforced, wherein the artifact includes a set of executable instructions, wherein the artifact includes a set of executable instructions such that the set of executable instructions of the artifact are incorporated into the code releases when the code releases are signed using instances of the artifact, wherein the artifact is defined in a code signing certificate, wherein the code signing certificate is used to sign the code releases such that a signature signed using the code signing certificate includes a copy of the set of executable instructions, which is taught by Kalle. It would have been obvious because doing so improves security by enabling a computing infrastructure to verify the authenticity and integrity of computer codes before running the computer codes.
Criscione also differs from claims 1, 12 and 13 in that it fails to disclose wherein the at least one mitigation action is performed by executing at least a portion of the executable code of the artifact.
When Criscione is modified in view of Kalle as described above, 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 Criscione by letting the at least one mitigation action taught by Criscione be performed by executing at least a portion of the executable code of the artifact disclosed by Kalle. It would have been obvious because doing so improves security by enabling a computing infrastructure to verify the authenticity and integrity of computer codes performing the at least one mitigation action before executing the computer codes.
Regarding claims 2 and 14, Criscione fails to explicitly teach causing deployment of at least one instance of the artifact in the computing infrastructure.
However, Kalle teaches causing deployment of at least one instance of the artifact in the computing infrastructure (see [0100]: “Referring to FIG. 10, a plurality of O-RAN customers or operators (e.g., a plurality of different O-RAN operators and a plurality of different O-Cloud operators) have a trust relationship with the O-RAN trust broker in accordance with example embodiments, and may securely pull (e.g., over a TLS 1.2/1.3 connection) desired artifacts from the centralized trust broker for onboarding onto their systems/clouds.”).
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 Criscione by adding the step of causing deployment of at least one instance of the artifact in the computing infrastructure taught by Kalle. It would have been obvious because doing so improves security by including computer codes in an artifact and signing the artifact to ensure the authenticity and integrity of the artifact and the computer codes before running the computer codes.
Criscione also differs from claims 2 and 14 in that it fails to disclose wherein the at least one mitigation action is performed via the deployed at least one instance of the artifact.
When Criscione is modified in view of Kalle as described above, 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 Criscione by letting the at least one mitigation action taught by Criscione be performed via the deployed at least one instance of the artifact disclosed by Kalle. It would have been obvious because doing so improves security by including computer codes for performing at least one mitigation action in an artifact and signing the artifact to ensure the authenticity and integrity of the artifact and the computer codes before running the computer codes.
Regarding claims 4 and 16, Criscione fails to teach defining the artifact via the set of executable instructions, wherein the at least one instance of the artifact is deployed via the enforcement of the at least one policy.
However, Kalle discloses defining the artifact via the set of executable instructions (see [0057] and Fig. 3: “The O-RAN SI trust broker 400 is configured to receive software or software components (artifacts) provided by the plurality of O-RAN vendors 300”. Kalle discloses that artifacts include software or software components. Additionally, software or software components include a set of executable instructions. Therefore, Kalle teaches defining the artifact via the set of executable instructions.), wherein the at least one instance of the artifact is deployed via the enforcement of the at least one policy (see [0100]: “Referring to FIG. 10, a plurality of O-RAN customers or operators (e.g., a plurality of different O-RAN operators and a plurality of different O-Cloud operators) have a trust relationship with the O-RAN trust broker in accordance with example embodiments, and may securely pull (e.g., over a TLS 1.2/1.3 connection) desired artifacts from the centralized trust broker for onboarding onto their systems/clouds.”).
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 Criscione by adding the step of defining the artifact via the set of executable instructions wherein the at least one instance of the artifact is deployed via the enforcement of the at least one policy, which is taught by Kalle. It would have been obvious because doing so improves security by enabling a computing infrastructure to verify the authenticity and integrity of executable instructions before executing the executable instructions.
Regarding claims 5 and 17, Criscione further teaches 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”).
Regarding claims 6 and 18, Criscione further teaches 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”).
Regarding claims 7 and 19, Criscione further teaches 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.”).
Regarding claims 8 and 20, Criscione further 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 (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.” ).
Regarding claims 11 and 23, Criscione further teaches 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.”).
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Criscione (US 2022/0345477), further in view of Kalle (US 2024/0104192), and further in view of Banzhof (US 2006/0101517).
Regarding claims 3 and 15, Criscione modified in view of Kalle 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 Criscione modified in view of Kalle 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 9, 10, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Criscione (US 2022/0345477), further in view of Kalle (US 2024/0104192), and further in view of Rogers (US 2008/0209563).
Regarding claims 9 and 21, Criscione modified in view of Kalle fails to teach 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.
In the same field of endeavor, Rogers discloses a runtime mitigation engine, wherein the determined at least one mitigation action includes altering executable code at runtime (see Abstract: “redirection techniques can be utilized to protect against insecure functionality, to mitigate scripting vulnerabilities, and to protect vulnerable exception handlers. In at least some embodiments, a program can be protected from a security vulnerability by using a runtime shield which changes the behavior of the program while it is running.” Rogers inherently teaches altering executable code at runtime because the behavior of the program, while the program is running, is controlled by executable code. Therefore, changing the behavior of the program while it is running necessarily involves altering executable code at runtime.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Criscione modified in view of Kalle by letting the plurality of mitigation engines include a runtime mitigation engine taught by Rogers, wherein the determined at least one mitigation action includes altering executable code at runtime, as taught by Rogers. It would have been obvious because Rogers teaches that doing so “provides a redirection solution that addresses the vulnerability” (see Abstract: “The shield effectively provides a redirection solution that addresses the vulnerability”).
Regarding claims 10 and 22, Rogers further teaches wherein the altering of the executable code at runtime includes modifying at least one of: at least one function (see [0026]: “One way of implementing a shield and its associated rule or rules is to describe the shield using a shield descriptor which is composed of a vulnerability descriptor which describes which function, method or interface is vulnerable, and a mitigation descriptor which describes the particular mitigation for that vulnerability descriptor. For example, assume that a vulnerability has been detected with regard to the Alert( ) function and that, responsively, a shield has been activated. Now, when program 108 attempts to call the Alert( ) function, the call is redirected to the appropriate shield.”), and at least one rule.
Conclusion
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