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
The present office action is responsive to communication filed on 11/13/2025. Claims 1 and 6-8 have been amended. Claim 2 has been previously cancelled. Claim 9 and 10 has been added. Claims 1 and 3-10 are currently pending.
Applicant’s arguments filed on 11/13/2025, with respect to the rejections of claims 1 and 3-8 with regards to 35 USC 103 over David et al. (US PGPub No. 20180191738-A1) in view of Williams et al. (US PGPub No. 20170142138-A1) and Banzhof et al. (US PGPub No. 20060101517-A1 ) specifically with the amended limitation of the server and a data processing system, as seen in pages 6-8 of the Remarks, are met have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new grounds of rejection of is made in view of Henderson et al. (US PGPub No. 20190342323-A1), Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), Bardsley et al. (US PG Pub No. 20050022021-A1), Mylrea et al. (US PGPub No. 20210173940-A1), and David et al. (US PGPub No. 20170295188-A1).
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-10 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 written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 5, and 6:
The claims recite, inter alia, that a “vulnerability response rule set … specifies responses of the data processing system,” that “each of the responses is associated with one or more conditions and one or more functions of the data processing system,” and that such “responses” are ascertained and “carried out” based on whether associated conditions are met, in the context of broadly recited “data processing system[s]” and “functions” that, under the broadest reasonable interpretation, encompass essentially any computing platform and any type of software behavior. The claims likewise recite “conditions” that depend on “the data processing system and a vulnerability or both” without limiting those conditions to any particular type of system attribute, vulnerability attribute, or relationship between them. The specification, however, does not define “responses,” “executable actions,” “functions,” or “conditions” in a way that materially limits these genera, and largely repeats the same broad labels (e.g., a vulnerability response rule set “comprising executable actions for remediating vulnerabilities,” a device that “generates a response … and carries out the response (action) encoded in the rule set”), while providing only a small number of concrete examples in a narrow technical setting—namely, an embedded vehicle/robot control system that, in response to specific vulnerabilities, may ignore suspicious TPMS readings, turn logging off when Log4J is used, temporarily disable remote software updating when a particular HSM algorithm is vulnerable, or execute shell‑command–type configurations such as updating packages, reconfiguring software, closing ports, disabling services, adding filters, or turning specific functions off. The disclosed “functions” and “subfunctions” are limited to those of the embedded control system (e.g., engine control, telematics, multimedia, connectivity, braking), and the “conditions” are illustrated only by examples such as whether TPMS is available, whether Log4J is used in the main unit, or whether a specific HSM algorithm is in use. These few, closely related examples in a single embedded safety/security domain do not constitute a representative number of species commensurate with the full breadth of the claimed genera of “responses,” “conditions,” and “functions” applicable to arbitrary data processing systems and functions across diverse architectures and application domains. Accordingly, the specification as filed does not reasonably convey to one of ordinary skill in the art that the inventor had possession, as of the filing date, of the invention to the extent the claims encompass the broad genera of “responses” (and corresponding executable actions), “conditions,” and “functions” for any data processing system and functions beyond the specifically exemplified embedded vehicle/robot control scenarios and their particular remedial behaviors, conditions, and controlled functions.
To overcome the rejection under 35 U.S.C. § 112(a): The written description requirement may be satisfied by amending the claims such that the scope of the recited “responses,” “conditions,” and “functions” more closely corresponds to the embodiments described in the specification. As disclosed, responses are implemented as executable software actions or routines stored in memory and executed by a processor to directly control operation of the embedded data processing system or the associated robot device (e.g., disabling or reconfiguring specific embedded control functions or services, such as TPMS, logging, or remote update capabilities), the “functions” and “subfunctions” are control or monitoring functions of an embedded robot/vehicle system (e.g., engine control, multimedia, telematics, braking), and the “conditions” are tied to concrete system and vulnerability attributes in that context (e.g., whether TPMS is available, whether Log4J is present, whether a particular HSM algorithm is used). Narrowing the independent claims to such embedded/robot control systems and to responses, conditions, and functions of the type actually illustrated in the specification would more closely align the scope of the claimed genera with the disclosed species. Dependent claims 3, 4, and 7-10 depend, directly or indirectly, from independent claim 1 and therefore incorporate the limitations reciting “responses,” “conditions,” and “functions” as set forth therein. Because these dependent claims do not further limit or clarify the scope of the recited responses, conditions, or functions in a manner that overcomes the written description deficiency discussed above, they are rejected under 35 U.S.C. § 112(a) for the same reasons as their respective independent claims.
Dependent claims 3, 4, and 7-10 depend, directly or indirectly, from independent claim 1 and therefore incorporate the limitations reciting “responses” as set forth therein. Because these dependent claims do not further limit or clarify the scope of the recited response in a manner that overcomes the written description deficiency discussed above, they are rejected under 35 U.S.C. § 112(a) for the same reasons as their respective independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 5, and 6 are indefinite because they fail to particularly point out and distinctly claim the subject matter regarded as their invention. Specifically, the claims recite terms and relationships such as “function of the data processing system”, “associated with”, “relates”, and “whether the condition is met depends on the data processing system and a vulnerability or both”, without providing objective boundaries for determining their scope. The claim further relies on undefined concepts such as when a function is “available” and how responses are “ascertained”. In the absence of clear definitions or objective criteria, a person of ordinary skill in the art would not be able to determine the metes and bounds of the claim with reasonable certainty.
To overcome the rejection under 35 U.S.C. § 112(b): The indefiniteness may be overcome by amending the claims to clarify the meaning and scope of the recited terms and relationships, such as “function of the data processing system”, “associated with”, “relates”, and “whether the condition is met depends on the data processing system and a vulnerability or both”, and by providing objective criteria for determining when a condition is met, when a function is available, and how response are ascertained. Clarifying the concepts in a manner consistent with the disclosure would enable a person of ordinary skill in the art o determine the metes and bounds of the claim with reasonable certainty.
Dependent claims 3, 4, and 7-10 depend, directly or indirectly, from independent claim 1 and therefore incorporate the limitations reciting as “function of the data processing system”, “associated with”, “relates”, and “whether the condition is met depends on the data processing system and a vulnerability or both” as set forth therein. Because these dependent claims do not further limit or clarify the scope of the recited response in a manner that overcomes the indefiniteness discussed above, they are rejected under 35 U.S.C. § 112(b) for the same reasons as their respective independent claims.
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.
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.
Claims 1 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1) and Sheridan et al. (US Pat No. 11036868-B2) .
With respect to claim 1, Henderson teaches a method (¶0003: Example methods, devices, and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.”) for remediating vulnerabilities of a data processing system, the method comprising the following steps: (¶0128: When security vulnerabilities are discovered on an enterprise's managed network, the enterprise may seek to carry out remediation of such security vulnerabilities with the help of remediator(s).);
storing, by the data processing system, a vulnerability response rule set which specifies responses of the data processing system in the data processing system, (¶0135: As seen in Figure 6A,Furthermore, as shown, computing system 302 may include a database 604 and server device(s) 606. The server device(s) 606 may engage in communications with managed network 300, client device 616, and/or other entities. .The database 604 may contain a key 608, assignment rules 610, and grouping rules 612, at least some of which may be set in accordance with preferences of the managed network 300's enterprise (e.g., set via a GUI of a client device in communication with the computing system 602).);
wherein each of the responses is associated with one or more conditions and [one or more functions] of the data processing system, (¶0140: In any case, the assignment rules 610 may set condition(s) for assigning vulnerable conditions(s) for assigning vulnerable configuration items to remediators. More specifically, each remediator may be represented by a remediator may be represented by a remediator identifier in the database 604.);
wherein, for each condition, whether the condition is met depends on the data processing system and a vulnerability or both; (¶0140: Further, a condition may be an expression referring to one or more attributes. These attributes may include item attributes and/or vulnerability attributes. For example, a given expression may refer to (i) a particular security vulnerability, (ii) a particular type of user, (iii) a particular type of operating system, (iv) particular hardware characteristics, (v) particular software characteristics, and/or (vi) a particular type of network, among others.);
Henderson does not disclose:
receiving, by the data processing system from a server, a notification about a vulnerability of the data processing system;
However, Hering teaches receiving, by the data processing system from a server, a notification about a vulnerability of the data processing system; (¶0044: As seen in Figure 5, Later, after receiving new vulnerability information, server 151 may determine that based on the stored operating system information for mobile communication device 101, the vulnerability could affect mobile communication device 101. However, server 151 may require additional identification information from mobile communication device 101 in order to determine whether the device is actually affected. Server 151 may request additional configuration information from mobile communication device 101. Server 151 will receive the requested identification information and then sends accurate vulnerability information to the device 101.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hering with regards to receiving, by the data processing system from a server, a notification to the method of Henderson in order to inform the data processing system to take action to address the vulnerability which further secures the system (Hering ¶0019).
Henderson in view of Hering does not disclose:
wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system,
ascertaining, by the data processing system, one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and the ascertained response is associated with at least one function to which the vulnerability relates; and carrying out, by the data processing system, the one or more ascertained responses,
wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system.
wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system,
However, Sheridan teaches wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system, (¶0036: In some embodiments, the data and/or metadata associated with the vulnerability may be determined by applying one or more security vulnerability rules 338. Security vulnerability rules 338 may include rules authored by a security subject matter expert and/or may include rules based on specific domain knowledge. Security vulnerability rules 338 may also include one or more security vulnerability criteria that may be used to determine whether a security vulnerability exists. Such security vulnerability rules may be stored in a security vulnerability rules table that is configured to allow an auto-remediation engine to selectively apply the rules to a source code representation and use the results of the rules to identify security vulnerabilities.);
ascertaining, by the data processing system, one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and (¶0047-0050: Figure 6, illustrates a diagram 600 of the elements and types of security fix rule as described in connection with Figure 1. A security fix rule 602, which expresses a security fix, may be based on one or more criteria 604. Because a security fix rule 602 is designed to associate a security fix to a type of security vulnerability, there may be unspecified values such as, for example, the location of the vulnerability in the security fix rule 602. ) the ascertained response is associated with at least one function to which the vulnerability relates; and (¶0057: A security patch rule 1002 may be based on a security fix rule as described herein in connection with FIG. 6. A security patch rule may express one or more security fixes for vulnerabilities identified by scanning a source code representation, and is designed to explicitly map a security fix rule to a specific security vulnerability by, for example, determining locations within the source code representation to apply the security patch.);
carrying out, by the data processing system, the one or more ascertained responses, wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system. (¶0057: The review elements 1010 may include additional parameters that may be filled in by a process or user as well as the status of the security patch rule (i.e., whether it is ready for review, whether it has been reviewed and is ready to be finalized with additional parameters, or whether it has been finalized and is ready to be applied. The review process is further explained in ¶0044-0046: As seen in a combination of Figure 4 and 5, the one or more security patch rules may then be verified 414 by a security patch rule verification process and/or by a security subject matter expert. Those security patch rules that are not verified 416 may be discarded 418 and a report 408 indicating the unverified security patch rules may be generated. If it is determined to accept the changes 512, the auto-remediation engine may then complete any updates to the security patch rule 514 from the provided additional parameters, may apply the security patch rule 516 to the source code to produce the patched source code, and then may verify the patched source code 518. If the patched source code is verified 520, the auto-remediation engine may commit the patched source code 522. If the patched source code is not verified 520, a report 524 to that effect may be generated. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sheridan with regards to a function and ascertaining a response to the method of Henderson in view of Hering in order to reduce the chances of remediation failure and make the system more stable (Sheridan ¶0002).
With respect to claim 6, Henderson teaches a data processing system configured to remediate vulnerabilities of the data processing system, (¶0003: Example methods, devices, and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.”) the data processing system configured to execute: (¶0128: When security vulnerabilities are discovered on an enterprise's managed network, the enterprise may seek to carry out remediation of such security vulnerabilities with the help of remediator(s).);
storing a vulnerability response rule set which specifies responses of the data processing system in the data processing system, (¶0135: As seen in Figure 6A,Furthermore, as shown, computing system 302 may include a database 604 and server device(s) 606. The server device(s) 606 may engage in communications with managed network 300, client device 616, and/or other entities. .The database 604 may contain a key 608, assignment rules 610, and grouping rules 612, at least some of which may be set in accordance with preferences of the managed network 300's enterprise (e.g., set via a GUI of a client device in communication with the computing system 602).);
wherein each of the responses is associated with one or more conditions and [one or more functions] of the data processing system, (¶0140: In any case, the assignment rules 610 may set condition(s) for assigning vulnerable conditions(s) for assigning vulnerable configuration items to remediators. More specifically, each remediator may be represented by a remediator may be represented by a remediator identifier in the database 604.);
wherein, for each condition, whether the condition is met depends on the data processing system and a vulnerability or both; (¶0140: Further, a condition may be an expression referring to one or more attributes. These attributes may include item attributes and/or vulnerability attributes. For example, a given expression may refer to (i) a particular security vulnerability, (ii) a particular type of user, (iii) a particular type of operating system, (iv) particular hardware characteristics, (v) particular software characteristics, and/or (vi) a particular type of network, among others.);
Henderson does not disclose:
receiving, from a server, a notification about a vulnerability of the data processing system;
However, Hering teaches receiving, from a server, a notification about a vulnerability of the data processing system; ; (¶0044: As seen in Figure 5, Later, after receiving new vulnerability information, server 151 may determine that based on the stored operating system information for mobile communication device 101, the vulnerability could affect mobile communication device 101. However, server 151 may require additional identification information from mobile communication device 101 in order to determine whether the device is actually affected. Server 151 may request additional configuration information from mobile communication device 101. Server 151 will receive the requested identification information and then sends accurate vulnerability information to the device 101.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hering with regards to receiving, by the data processing system from a server, a notification to the method of Henderson in order to inform the data processing system to take action to address the vulnerability which further secures the system (Hering ¶0019).
Henderson in view of Hering does not disclose:
wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system,
ascertaining one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and the ascertained response is associated with at least one function to which the vulnerability relates; and carrying out the one or more ascertained responses, wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system.
wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system,
However, Sheridan wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system, (¶0036: In some embodiments, the data and/or metadata associated with the vulnerability may be determined by applying one or more security vulnerability rules 338. Security vulnerability rules 338 may include rules authored by a security subject matter expert and/or may include rules based on specific domain knowledge. Security vulnerability rules 338 may also include one or more security vulnerability criteria that may be used to determine whether a security vulnerability exists. Such security vulnerability rules may be stored in a security vulnerability rules table that is configured to allow an auto-remediation engine to selectively apply the rules to a source code representation and use the results of the rules to identify security vulnerabilities.);
ascertaining, by the data processing system, one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and (¶0047-0050: Figure 6, illustrates a diagram 600 of the elements and types of security fix rule as described in connection with Figure 1. A security fix rule 602, which expresses a security fix, may be based on one or more criteria 604. Because a security fix rule 602 is designed to associate a security fix to a type of security vulnerability, there may be unspecified values such as, for example, the location of the vulnerability in the security fix rule 602. ) the ascertained response is associated with at least one function to which the vulnerability relates; and (¶0057: A security patch rule 1002 may be based on a security fix rule as described herein in connection with FIG. 6. A security patch rule may express one or more security fixes for vulnerabilities identified by scanning a source code representation, and is designed to explicitly map a security fix rule to a specific security vulnerability by, for example, determining locations within the source code representation to apply the security patch.);
carrying out, by the data processing system, the one or more ascertained responses, wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system. (¶0057: The review elements 1010 may include additional parameters that may be filled in by a process or user as well as the status of the security patch rule (i.e., whether it is ready for review, whether it has been reviewed and is ready to be finalized with additional parameters, or whether it has been finalized and is ready to be applied. The review process is further explained in ¶0044-0046: As seen in a combination of Figure 4 and 5, the one or more security patch rules may then be verified 414 by a security patch rule verification process and/or by a security subject matter expert. Those security patch rules that are not verified 416 may be discarded 418 and a report 408 indicating the unverified security patch rules may be generated. If it is determined to accept the changes 512, the auto-remediation engine may then complete any updates to the security patch rule 514 from the provided additional parameters, may apply the security patch rule 516 to the source code to produce the patched source code, and then may verify the patched source code 518. If the patched source code is verified 520, the auto-remediation engine may commit the patched source code 522. If the patched source code is not verified 520, a report 524 to that effect may be generated. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sheridan with regards to a function and ascertaining a response to the method of Henderson in view of Hering in order to reduce the chances of remediation failure and make the system more stable (Sheridan ¶0002).
With respect to claim 7, Henderson teaches a non-transitory computer-readable medium on which is stored a computer program (¶0016: In a third example embodiment, an article of manufacture may include a non-transitory computer-readable medium, having stored thereon program instructions that, upon execution by a computing system, cause the computing system to perform operations in accordance with the first and/or second example embodiments.) including instructions for remediating vulnerabilities of a data processing system, the instructions, when executed by a processor, causing the processor to perform the following steps: (¶0128: When security vulnerabilities are discovered on an enterprise's managed network, the enterprise may seek to carry out remediation of such security vulnerabilities with the help of remediator(s).);
storing a vulnerability response rule set which specifies responses of the data processing system in the data processing system, (¶0135: As seen in Figure 6A,Furthermore, as shown, computing system 302 may include a database 604 and server device(s) 606. The server device(s) 606 may engage in communications with managed network 300, client device 616, and/or other entities. .The database 604 may contain a key 608, assignment rules 610, and grouping rules 612, at least some of which may be set in accordance with preferences of the managed network 300's enterprise (e.g., set via a GUI of a client device in communication with the computing system 602).);
wherein each of the responses is associated with one or more conditions and [one or more functions] of the data processing system, (¶0140: In any case, the assignment rules 610 may set condition(s) for assigning vulnerable conditions(s) for assigning vulnerable configuration items to remediators. More specifically, each remediator may be represented by a remediator may be represented by a remediator identifier in the database 604.);
wherein, for each condition, whether the condition is met depends on the data processing system and a vulnerability or both; (¶0140: Further, a condition may be an expression referring to one or more attributes. These attributes may include item attributes and/or vulnerability attributes. For example, a given expression may refer to (i) a particular security vulnerability, (ii) a particular type of user, (iii) a particular type of operating system, (iv) particular hardware characteristics, (v) particular software characteristics, and/or (vi) a particular type of network, among others.);
Henderson does not disclose:
receiving, from a server, a notification about a vulnerability of the data processing system;
However, Hering teaches receiving, from a server, a notification about a vulnerability of the data processing system; (¶0044: As seen in Figure 5, Later, after receiving new vulnerability information, server 151 may determine that based on the stored operating system information for mobile communication device 101, the vulnerability could affect mobile communication device 101. However, server 151 may require additional identification information from mobile communication device 101 in order to determine whether the device is actually affected. Server 151 may request additional configuration information from mobile communication device 101. Server 151 will receive the requested identification information and then sends accurate vulnerability information to the device 101.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hering with regards to receiving, by the data processing system from a server, a notification to the method of Henderson in order to inform the data processing system to take action to address the vulnerability which further secures the system (Hering ¶0019).
Henderson in view of Hering does not disclose:
wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system,
ascertaining one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and the ascertained response is associated with at least one function to which the vulnerability relates; and carrying out the one or more ascertained responses, wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system.
However, Sheridan teaches wherein each of the responses is associated with one or more conditions and one or more functions of the data processing system, (¶0036: In some embodiments, the data and/or metadata associated with the vulnerability may be determined by applying one or more security vulnerability rules 338. Security vulnerability rules 338 may include rules authored by a security subject matter expert and/or may include rules based on specific domain knowledge. Security vulnerability rules 338 may also include one or more security vulnerability criteria that may be used to determine whether a security vulnerability exists. Such security vulnerability rules may be stored in a security vulnerability rules table that is configured to allow an auto-remediation engine to selectively apply the rules to a source code representation and use the results of the rules to identify security vulnerabilities.);
ascertaining, by the data processing system, one or more responses from the vulnerability response rule set, such that, for each ascertained response, the one or more conditions with which the ascertained response is associated are met for the vulnerability and the data processing system and (¶0047-0050: Figure 6, illustrates a diagram 600 of the elements and types of security fix rule as described in connection with Figure 1. A security fix rule 602, which expresses a security fix, may be based on one or more criteria 604. Because a security fix rule 602 is designed to associate a security fix to a type of security vulnerability, there may be unspecified values such as, for example, the location of the vulnerability in the security fix rule 602. ) the ascertained response is associated with at least one function to which the vulnerability relates; and (¶0057: A security patch rule 1002 may be based on a security fix rule as described herein in connection with FIG. 6. A security patch rule may express one or more security fixes for vulnerabilities identified by scanning a source code representation, and is designed to explicitly map a security fix rule to a specific security vulnerability by, for example, determining locations within the source code representation to apply the security patch.);
carrying out, by the data processing system, the one or more ascertained responses, wherein the one or more conditions are met only if a function associated with the condition is available in the data processing system. (¶0057: The review elements 1010 may include additional parameters that may be filled in by a process or user as well as the status of the security patch rule (i.e., whether it is ready for review, whether it has been reviewed and is ready to be finalized with additional parameters, or whether it has been finalized and is ready to be applied. The review process is further explained in ¶0044-0046: As seen in a combination of Figure 4 and 5, the one or more security patch rules may then be verified 414 by a security patch rule verification process and/or by a security subject matter expert. Those security patch rules that are not verified 416 may be discarded 418 and a report 408 indicating the unverified security patch rules may be generated. If it is determined to accept the changes 512, the auto-remediation engine may then complete any updates to the security patch rule 514 from the provided additional parameters, may apply the security patch rule 516 to the source code to produce the patched source code, and then may verify the patched source code 518. If the patched source code is verified 520, the auto-remediation engine may commit the patched source code 522. If the patched source code is not verified 520, a report 524 to that effect may be generated. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sheridan with regards to a function and ascertaining a response to the method of Henderson in view of Hering in order to reduce the chances of remediation failure and make the system more stable (Sheridan ¶0002).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), Papaxenopoulos et al. (US PGPub No. 20180336356-A1 ), and Shulman-Peleg et al. (US PGPub No. 20190036978-A1).
With respect to claim 3, the combination of Henderson in view of Hering and Sheridan teaches the method of claim 1 (see rejection of claim 1 above) but does not teach wherein the vulnerability response rule set is hierarchically structured so that, starting from one or more functions of the data processing system, paths to the responses are included, which include one or more subfunctions, wherein each subfunction is a subfunction of the function or subfunction preceding it in the path, and one or more conditions.
However, Papaxenopoulos teaches wherein the [vulnerability response rule set is hierarchically structured] so that, starting from one or more functions of the data processing system, paths to the responses are included, which include one or more subfunctions, (¶0037-0040: As seen in Figure 3, for performing auto-remediation on security vulnerabilities in source code as described in Figure 1 and in accordance with an example. A source code representation 302 of a subset of set of source code associated with a computer system can be scanned 304 to produce vulnerability data 306 as described above. In some examples, the data and/or metadata associated with the vulnerability can be determined by applying one or more security vulnerability rules 338. For example, the vulnerability data 306 can include position data and/or metadata that can be used to determine a location within the source code representation where the source code can be most vulnerable or that can be used to determine a location within the source code representation where a security patch (paths to responses are included) can be most effectively applied to remediate the vulnerability. These operations, to be performed efficiently, can be performed by a computer. Security vulnerability rules 338 can include rules authored by a security subject matter expert and/or can include rules based on specific domain knowledge. Security vulnerability rules 338 can also include one or more security vulnerability criteria that can be used to determine whether a security vulnerability exists.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Papaxenopoulos with regards to the paths to response to the method of Henderson in view of Hering and Sheridan in order to maintain security of such complex systems can be made be made more difficult when such components frequently change (Papaxenopoulos ¶0003).
Henderson in view of Hering, Sheridan, and Papaxenopoulos does not disclose:
vulnerability response rule set is hierarchically structured wherein each subfunction is a subfunction of the function or subfunction preceding it in the path, and one or more conditions.
However, Shulman-Peleg teaches vulnerability response rule set is hierarchically structured (¶0083: As seen in Figure 5,in the case of the second example, in some embodiments, operation 506 generates a directed acyclic graph (e.g., DAG 300 of Figure 3) storing the hierarchy of security policies.). wherein each subfunction is a subfunction of the function or subfunction preceding it in the path, and one or more conditions. (¶0088-0091: As seen in Figure 6,in some embodiments, in operation 606 the security agent uses the parameters from the first execution environment to identify an appropriate path in a directed acyclic graph (DAG) of rules and/or security policies and enforces the rules and/or security policies from the identified appropriate path. In operation 608, the security agent intercepts a first subset of events associated with the first execution environment. In some embodiments, the first subset of events are defined by the retrieved security policies.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Shulman-Peleg with regards to the vulnerability response rule set being hierarchically and the subfunction to the method of Henderson in view of Hering, Sheridan, and Papaxenopoulos in order to protecting against disrupted functionality and prevent compromised data (Shulman-Peleg: ¶0003-0009).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), and Bardsley et al. (US PGPub No. 20050022021-A1).
With respect to claim 4, the combination of Henderson in view of Hering and Sheridan teaches the method of claim 1 (see rejection of claim 1 above) but does not teach the wherein each of at least some of the conditions is that no protection program is available for a function associated with the condition.
However, Bardsley teaches wherein each of at least some of the conditions is that no protection program is available for a function associated with the condition. (¶0085: at Block 2610, in response to identification of a potentially vulnerable system/level or subsystem/level in a TMV at Block 2550, the TMIB vulnerability/countermeasures vector data for the TMV system or subsystem level is accessed. At Block 2620, the TMIB vulnerability/countermeasures vector data is compared with each TMV vulnerability vector. If a match is found at Block 2630, and if the TMV data supersedes the TMIB data at Block 2640, then at Block 2650, the TMIB vulnerability/countermeasures data is reset with data from the TMV. On the other hand, if a match is not found at Block 2630, then the new TMIB vulnerability countermeasures vector data from the TMV is added at Block 2670.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Bardsley with regards to the condition to the method of Henderson in view of Hering, and Sheridan in order to discover new vulnerabilities that could impact the system negatively and allow for further analysis to be taken with regards to remedial actions ( Bardsley ¶0013).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), and Feiertag et al. (US PGPub No. 20190306198-A1).
With respect to claim 5, the combination of Henderson in view of Hering and Sheridan teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose the data processing system is an embedded system for controlling a robot device.
However, Feiertag teaches wherein the data processing system is an embedded system for controlling a robot device. (¶0017: An application can be a web application or server running on a web or application server, a mobile application running on a mobile device, a client or server application running on a desktop computer, or any other form of software, including embedded systems in a vehicle, appliance, airplane, weapon system, robot, or the like).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Feiertag with regards to the embedded system for controlling a robot device to the method of Henderson in view of Hering, and Sheridan in order to provide application security and auditing at low levels of granularity with high levels of configurability and efficiency (Feiertag: ¶0005-0007).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), and Naldurg et al. (US PGPub No. 20080104665-A1).
With respect to claim 8, the combination of Henderson in view of Hering and Sheridan teaches the method of claim 1 (see rejection of claim 1 above) but does not teach wherein receiving the notification from the server about the vulnerability of the data processing system [includes the vulnerability meeting one or more filtering conditions. ](¶0044: As seen in Figure 5, Later, after receiving new vulnerability information, server 151 may determine that based on the stored operating system information for mobile communication device 101, the vulnerability could affect mobile communication device 101. However, server 151 may require additional identification information from mobile communication device 101 in order to determine whether the device is actually affected. Server 151 may request additional configuration information from mobile communication device 101. Server 151 will receive the requested identification information and then sends accurate vulnerability information to the device 101.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hering with regards to receiving, by the data processing system from a server, a notification to the method of Henderson and Sheridan in order to inform the data processing system to take action to address the vulnerability which further secures the system (Hering ¶0019).
Henderson in view of Hering and Sheridan does not disclose:
includes the vulnerability meeting one or more filtering conditions.
However, Naldurg teaches includes the vulnerability meeting one or more filtering conditions. (¶0068-0078 : Vulnerability Specification: Table 3 specifies information flows that are undesirable. The variables in the relations can be interpreted in the context of the specific models. Results were obtained by employing the facility on both WINDOWS XP and SELinux. The vulnerability reports indicate possible attacks. The specifications can be refined by adding appropriate filters to improve the relevance of vulnerabilities the facility finds. When employed with specifications in Table 1, together with vulnerability specifications from Table 3, the tool produced 4853 vulnerabilities over 1326 unique resources. To make results of the tool more relevant, the execute rule in Table 1 can be further refined. Thus implementation details that improve the usability of the facility can be pushed to the model level, retaining the power of abstraction at the property specification level. After this additional filtering, the tool produced 176 vulnerability reports on 58 different resources. Every report was a plausible vulnerability. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Naldurg with regards to the notifications to the method of Henderson in view of Hering and Sheridan in order to improve the usability and to reduce white noise which are vulnerabilities that are benign (Naldurg ¶0077 & ¶0083).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), and Mylrea et al. (US PGPub No. 20210173940-A1).
With respect to claim 9, the combination of Henderson in view of Hering and Sheridan teaches the method of claim 1 (see rejection of claim 1 above) but does not teach wherein the receiving, by the data processing system from the server, the notification about the vulnerability of the data processing system comprises: receiving, by the data processing system from the server via an application programming interface (API), a vulnerability report including one or more vulnerabilities; and identifying, by the data processing system, the vulnerability from among the one or more vulnerabilities of the vulnerability report based on one or more filtering conditions.
However, Mylrea teaches receiving, by the data processing system from the server (¶0065-0067: As seen in Figure 7, the server 702 can also provide other tools connected with cyberattack monitoring and risk assessment, such as situational awareness routines 740 that can be connected with, e.g., ICS CERT 742 or other cybersecurity services 744. The server 702 can also include SIEM integration 746 (security information and event management) to provide security alerts and monitoring. For example, SIEM integration 746 can use security logs including data from the database 728 or other data processed or generated by the server 712 to generate data analytics from the found device exposures, so that the organization or utility can automatically interact with SIEM.) via an application programming interface (API), (¶0037: Representative examples use application programming interfaces (APIs) of web spiders to extract information from associated databases. Using these API connections, disclosed examples can generate detailed cybersecurity vulnerability reports, provide near-real-time alerts, and keep track of historical results.);
a vulnerability report including one or more vulnerabilities; and identifying, by the data processing system, the vulnerability from among the one or more vulnerabilities of the vulnerability report based on one or more filtering conditions. (¶0067-0069: Query results can be filtered and mapped and stored in a database 728 so that results can be used to send risk and vulnerability updates to the clients 704a-704d (via API). The results can also be processed through a risk bucketing routine 730 can categorize devices based on CVSS scores associated with the vulnerabilities 722. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Mylrea with regards to reporting vulnerabilities via API to the method of Henderson in view of Hering, and Sheridan in order to provide real-time alerts with regards to the vulnerabilities (Mylrea: ¶0037-0040).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Henderson et al. (US PGPub No. 20190342323-A1) in view of Hering et al. (US PGPub No. 20110119765-A1), Sheridan et al. (US Pat No. 11036868-B2), Mylrea et al. (US PGPub No. 20210173940-A1), and David et al. (US PGPub No. 20170295188-A1 ).
With respect to claim 10, the combination of Henderson in view of Hering, Sheridan, and Mylrea teaches the method of claim 9 (see rejection of claim 9 above) but does not disclose wherein the vulnerability report is received from the manufacturer of the data processing system via the API.
However, David teaches wherein the vulnerability report is received from the manufacturer of the data processing system via the API. (¶0042: As seen in Figure 1B, by adding an endpoint security layers and policies 158a-n to ECUs 156a-n so that they use policies outlining whitelists of permitted processes, binaries, etc., the ECUs 156a-n are able to provide an early intrusion detection system capable of early detection of unexpected behavior or operation of a dropper (example intrusions) and immediately report on the attack attempt in real-time, as indicated by step 162. The early intrusion detection and warning can give the original equipment manufacturers (OEMs) and system providers of the vehicle 152 (and its subparts) time to address the threat, as indicated by the computer system 164 providing real-time status information to a client computing device 168 with information 170 on malware that has been blocked across the ECUs 156a-n (step 166).);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of with regards to reporting vulnerabilities via API to the method of Henderson in view of Hering, Sheridan, and Mylrea in order to provide time for the manufacturer to address vulnerabilities (David: ¶0042).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437