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 .
Detailed Action
1. The office action is in response to the communication filed 1/8/2026.
Response to Arguments
2. The applicant’s arguments filed 1/8/2025 have been taken into consideration, but are not persuasive.
A. In response to the applicant’s argument (disclosed on pg. 1 of the remarks segment) that claim 1 can’t be construed as software, per se because the claim language would require that the claimed software (first device agent module, device configuration manager, and second device agent) be executing:
According to MPEP 2106.03 I., products that do not have a physical form, such as a computer program, per se, are not directed to any of the statutory categories. Even if the claim language requires that the software be executing, the claimed system comprises of elements (first device agent module, device configuration manager, and second device agent) that are implemented as software and is not drawn to physical structure, itself. Whether or not the claim software elements are being executed as a part of the system doesn’t overcome the requirement that physical structure be claimed in order for claim language to be drawn to a statutory category.
B. In response to the applicant’s argument (disclosed on pg. 1-2 of the remarks segment) that Curtis et al fails to teach or suggest accepting and applying the management commands:
The applicant’s specification doesn’t contain a specific description of accepting/applying management commands and discloses that management commands are data created according to monitoring information that was provided to a second device agent after monitoring of a device was performed by the first device agent module (according to par [0004] & par [0048] of the applicant’s specification). The examiner maintains that the plurality of countermeasure control agents located on the same device (as disclosed in par [0037], lines 20-25 of Curtis et al) being implemented to apply countermeasures (as disclosed in par [0034] of Curtis et al) corresponding to different risk-related results being provided as a result of the same computing environment in which the countermeasure control agents are located on are being monitored (as disclosed in par [0035], lines 1-5 of Curtis et al) are obvious in light of the claim limitations because the plurality of countermeasure control agents are implemented to receive and apply the countermeasures that are implemented upon the risk-related results (e.g., monitoring information) being provided by other agents being executed on the same device.
C. In response to the applicant’s argument (disclosed on pg. 2 of the remarks segment) that Kapoor fails to teach or suggest the second device agent executing on the device:
The examiner maintains that the Kapoor reference does provide a plurality of agents being located on the same device/node and not implemented remotely (as disclosed in fig. 1D, ‘112, ‘122’,… and par [0108], lines 1-10 of Kapoor).
Claim Rejections – 35 USC 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1-10 are rejected under 35 U.S.C. 101 because the claim language is directed to non-statutory subject matter.
The claims do not fall within at least one of the four categories of patent eligible subject matter because the claimed subject matter is drawn to software, per se. The claimed system of claim 1 comprises first and second device agent modules and a device configuration manager executing on the device, which may be implemented as software being executed on the device, and the claim language doesn’t contain physical structure, such as hardware or a physical device. Although the claim discloses that the claimed first device module is executing on a device, the device itself, (or any other physical structure) is not being explicitly claimed. The claimed device configuration manager may also be drawn to a non-statutory, cloud-based entity as well. Claims 2-10 also depend on claim 1 and are also rejected under 35 USC 101.
Claim Rejections – 35 USC 103
5. 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.
6. Claims 1-7 and 11-20 are rejected under 35 USC 103 as being unpatentable over Curtis et al (US 2012/0210434) in view of Kapoor et al (US 2024/0106846).
Regarding claim 1, Curtis et al teaches a system for securing a device executing program instructions (par [0009], lines 1-2 and par [0032], lines 19-25, which disclose implementing security countermeasures for devices), comprising:
a first device agent module executing on the device (fig. 2, ‘210 and par [0037], lines 1-20, which disclose a plurality of risk collection agents), for:
monitoring the device and execution of the program instructions (fig. 2, ‘210 and par [0037], lines 1-20, which disclose the plurality of risk collection agents being used to monitor devices); and
generating monitoring information from the monitoring of the device ([0037], lines 1-20, which discloses creating data representing the risk collection reports provided by the risk collection agents);
a device configuration manager, communicatively coupled to the device (fig. 1, ‘104, fig. 2, ‘202, and par [0035], lines 18-25, which disclose an active countermeasure intelligence engine) for:
accepting the monitoring information (fig. 1, ‘104 & par [0035], lines 18-25, which disclose the active countermeasure intelligence engine receiving the discovered risk data);
generating management commands according to the monitoring information (fig. 1, ‘104 & par [0032], lines 18-25, and par [0048], lines 13-18, which disclose providing instructions to perform a mitigating action upon determining potential vulnerabilities);
a second device agent for accepting and applying the management commands (par [0037], lines 30-37 and par [0039], lines 5-15, which disclose countermeasure control agents collecting countermeasure indication correlating to the mitigating actions).
Curtis et al does not explicitly teach the second device agent executing on the device.
However, Kapoor et al further teaches the second device agent executing on the device (fig. 1D, ‘108 & par [0108], lines 4-8, which disclose a plurality of agents located on nodes of an IoT device).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
Regarding claim 2, Curtis et al teaches wherein:
the device configuration manager is communicatively coupled to a database of permitted device configurations and operations (par [0031], lines 5-7), authorized applications and libraries (par [0031], lines 5-7).
Curtis et al does not teach or suggest user permissions and rules.
However, Kapoor et al further teaches user permissions and rules (par [0755], lines 1-3).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 1.
Regarding claim 3, Curtis et al teaches wherein the monitoring information includes:
available device services (par [0031], lines 12-14, “set of…processes”);
executing software applications (par [0031], lines 12-14, “set of…processes”);
software libraries (par [0055], lines 5-7); and
signatures or patterns of potential threats (par [0036], lines 9-18, “threat attributes”).
Curtis et al does not teach or suggest wherein the monitoring information includes open device ports and suspicious abnormalities identified based on device runtime patterns.
However, Kapoor et al further teaches wherein the monitoring information includes:
open device ports (par [0488], lines 15-18, “listen ports”); and
suspicious abnormalities identified based on device runtime patterns (par [0659], lines 7-9, “detection of abnormal activity”).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 1.
Regarding claim 4, Curtis et al and Kapoor et al teach the limitations of claim 1.
Curtis et al further teaches wherein generating management commands according to the monitoring information comprises:
generating a comparison of permitted device configurations and operations to executing device configurations and operations using the monitored information (par [0035], lines 20-25, “configuration assessment”); and
generating the management commands according to the comparison (par [0047] and par [0052], “manage vulnerabilities and to sustain compliance”).
Regarding claim 5, Curtis et al teaches wherein the management commands comprise:
authorizing the executing device configurations according to the comparison (par [0028], lines 4-5, “enacting the required configuration change”);
enabling or disabling device services (par [0009], lines 10-12, “block or enabling disabled filters”);
removing or allowing software or libraries to be used on the device (par [0055], lines 6-8); and
mitigating threats (par [0036], lines 9-18, “threat attributes”).
Curtis et al does not teach or suggest wherein the management commands comprise: closing or opening device ports.
However, Kapoor et al further teaches wherein the management commands comprise:
closing or opening device ports (par [0177], lines 1-4).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
Regarding claim 6, Curtis et al does not teach or suggest wherein the device configuration manager comprises a crypto engine having a hardware security module for generating security information.
However, Kapoor et al further teaches wherein the device configuration manager comprises a crypto engine having a hardware security module for generating security information (par [0576], lines 6-7).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 5.
Regarding claim 7, Curtis et al and Kapoor et al teach the limitations of claim 1.
Curtis et al further teaches wherein the device configuration manager is cloud-based (par [0031], lines 1-2).
Regarding claim 11, Curtis et al teaches a method of securing a device executing program instructions (par [0009], lines 1-2 and par [0032], lines 19-25, which disclose implementing security countermeasures for devices), comprising:
receiving, from a first device agent module executing on the device (fig. 2, ‘210 and par [0037], lines 1-20, which disclose a plurality of risk collection agents), monitoring information, the monitoring information generated from the first device agent module monitoring the device and execution of the program instructions (fig. 2, ‘210 and par [0037], lines 1-20, which disclose the plurality of risk collection agents being used to monitor devices); and
generating, in a device configuration manager, management commands according to the monitoring information (fig. 1, ‘104 & par [0032], lines 18-25, and par [0048], lines 13-18, which disclose providing instructions to perform a mitigating action upon determining potential vulnerabilities);
providing, the management commands to a second device agent (par [0037], lines 30-37 and par [0039], lines 5-15, which disclose countermeasure control agents collecting countermeasure indication correlating to the mitigating actions).
Curtis et al does not explicitly teach the second device agent operating on the device.
Curtis et al does not explicitly teach the second device agent executing on the device.
However, Kapoor et al further teaches the second device agent executing on the device (fig. 1D, ‘108 & par [0108], lines 4-8, which disclose a plurality of agents located on nodes of an IoT device).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
Regarding claim 12, Curtis et al teaches wherein:
the device configuration manager is communicatively coupled to a database of permitted device configurations and operations (par [0031], lines 5-7), authorized applications and libraries (par [0031], lines 5-7).
Curtis et al does not teach or suggest user permissions and rules.
However, Kapoor et al further teaches user permissions and rules (par [0755], lines 1-3).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 1.
Regarding claim 13, Curtis et al teaches wherein the monitoring information includes:
available device services (par [0031], lines 12-14, “set of…processes”);
executing software applications (par [0031], lines 12-14, “set of…processes”);
software libraries (par [0055], lines 5-7); and
signatures or patterns of potential threats (par [0036], lines 9-18, “threat attributes”).
Curtis et al does not teach or suggest wherein the monitoring information includes open device ports and suspicious abnormalities identified based on device runtime patterns.
However, Kapoor et al further teaches wherein the monitoring information includes:
open device ports (par [0488], lines 15-18, “listen ports”); and
suspicious abnormalities identified based on device runtime patterns (par [0659], lines 7-9, “detection of abnormal activity”).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 1.
Regarding claim 14, Curtis et al and Kapoor et al teach the limitations of claim 11.
Curtis et al further teaches wherein generating management commands according to the monitoring information comprises:
generating a comparison of permitted device configurations and operations to executing device configurations and operations using the monitored information (par [0035], lines 20-25, “configuration assessment”); and
generating the management commands according to the comparison (par [0047] and par [0052], “manage vulnerabilities and to sustain compliance”).
Regarding claim 15, Curtis et al teaches wherein the management commands comprise:
authorizing the executing device configurations according to the comparison (par [0028], lines 4-5, “enacting the required configuration change”);
enabling or disabling device services (par [0009], lines 10-12, “block or enabling disabled filters”); and
removing or allowing software or libraries (par [0055], lines 6-8).
Curtis et al does not teach or suggest wherein the management commands comprise: closing or opening device ports.
However, Kapoor et al further teaches wherein the management commands comprise:
closing or opening device ports (par [0177], lines 1-4).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
Regarding claim 16, Curtis et al does not teach or suggest wherein the device configuration manager comprises a crypto engine having a hardware security module for generating security information and .
However, Kapoor et al further teaches wherein the device configuration manager comprises:
a crypto engine having a hardware security module for generating security information (par [0576], lines 6-7); and
a virtualized dashboard, for displaying the status of the device agents (par [0483], lines 1-3).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al according to the motivation disclosed regarding claim 15.
Regarding claim 17, Curtis et al and Kapoor et al teach the limitations of claim 11.
Curtis et al further teaches wherein the device configuration manager is cloud-based (par [0031], lines 1-2).
Regarding claim 18, Curtis et al teaches an apparatus of securing a device executing program instructions (par [0009], lines 1-2 and par [0032], lines 19-25, which disclose implementing security countermeasures for devices), comprising:
a processor (claim 1, lines 1-5, “hardware processor”);
a memory, communicatively coupled to the processor (claim 1, lines 1-5, “computer memory”), the memory storing processing instructions including processing instructions for:
receiving, from a first device agent module executing on the device (fig. 2, ‘210 and par [0037], lines 1-20, which disclose a plurality of risk collection agents), monitoring information, the monitoring information generated from the first device agent module monitoring the device and execution of the program instructions (fig. 2, ‘210 and par [0037], lines 1-20, which disclose the plurality of risk collection agents being used to monitor devices); and
generating, in a device configuration manager, management commands according to the monitoring information (fig. 1, ‘104 & par [0032], lines 18-25, and par [0048], lines 13-18, which disclose providing instructions to perform a mitigating action upon determining potential vulnerabilities);
providing, the management commands to a second device agent (par [0037], lines 30-37 and par [0039], lines 5-15, which disclose countermeasure control agents collecting countermeasure indication correlating to the mitigating actions).
Curtis et al does not explicitly teach the second device agent operating on the device.
However, Kapoor et al further teaches the second device agent executing on the device (fig. 1D, ‘108 & par [0108], lines 4-8, which disclose a plurality of agents located on nodes of an IoT device).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
Regarding claim 19, Curtis et al and Kapoor et al teach the limitations of claim 18.
Curtis et al further teaches wherein the processor instructions for generating management commands according to the monitoring information comprise processor instructions for:
generating a comparison of permitted device configurations and operations to executing device configurations and operations using the monitored information (par [0035], lines 20-25, “configuration assessment”); and
generating the management commands according to the comparison (par [0047] and par [0052], “manage vulnerabilities and to sustain compliance”).
Regarding claim 20, Curtis et al teaches wherein the management commands comprise:
authorizing the executing device configurations according to the comparison (par [0028], lines 4-5, “enacting the required configuration change”);
enabling or disabling device services (par [0009], lines 10-12, “block or enabling disabled filters”);
removing or allowing software or libraries (par [0055], lines 6-8); and
mitigating threats (par [0036], lines 9-18, “threat attributes”).
Curtis et al does not teach or suggest wherein the management commands comprise: closing or opening device ports.
However, Kapoor et al further teaches wherein the management commands comprise:
closing or opening device ports (par [0177], lines 1-4).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Kapoor et al within the concept illustrated by Curtis et al in order to improve ensuring compliance of security-related policy configuration by automatically rejecting policy-violating changes from occurring (as disclosed par [0573], lines 10-19 of Kapoor et al) because this feature would increase compliance confirmation within the embodiment disclosed by Curtis et al.
8. Claims 8-10 are rejected under 35 USC 103 as being unpatentable over Curtis et al (US 2012/0210434) in view of Kapoor et al (US 2024/0106846), further in view of Gulati et al (US 2022/0329443).
Regarding claim 8, Curtis et al and Kapoor et al do not explicitly teach wherein a lifecycle of the device comprises a deployment stage, and an operational stage wherein: in the deployment stage: the device is deployed with a secure default configuration; the device is booted with trusted boot instructions; in the operational stage: the device configuration manager generates management commands according to the monitoring information.
However, Gulati et al teaches wherein a lifecycle of the device comprises a deployment stage (par [0369], lines 1-3, “deployment management…digital lifecycle management”), and an operational stage (par [0285], lines 1-2) wherein:
in the deployment stage:
the device is deployed with a secure default configuration (par [0258] & par [0297]);
the device is booted with trusted boot instructions (par [0282], lines 1-2);
in the operational stage:
the device configuration manager generates management commands according to the monitoring information (par [0258] and par [0292]).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Gulati et al within the disclosures of Curtis et al and Kapoor et al in order to improve information security and data confidentiality using the code signing module (as disclosed par [0161], lines 5-8 of Gulati et al) because this implementation would eliminate potential data breaches within Curtis et al and Kapoor et al by using cryptographic tokens to prevent access or altering of the configuration data.
Regarding claim 9, Curtis et al and Kapoor et al do not explicitly teach wherein the management commands are encrypted and signed.
However, Gulati et al teaches wherein the management commands are encrypted and signed (par [0277], lines 1-5).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Gulati et al within the disclosures of Curtis et al and Kapoor et al according to the motivation disclosed regarding claim 8.
Regarding claim 10, Curtis et al teaches wherein the device comprises a memory (claim 1, lines 1-2).
Curtis et al and Kapoor et al do not explicitly teach wherein: the lifecycle of the device further comprises an end of life stage; and the memory of the device is wiped to irreversibly destroy secret information stored in the memory during the end of life stage.
However, Gulati et al teaches wherein:
the lifecycle of the device further comprises an end of life stage (par [0135], lines 4-5); and
the memory of the device is wiped to irreversibly destroy secret information stored in the memory during the end of life stage (par [0435], lines 11-14).
It would have been obvious to one of ordinary skill in the art, before the effective day of the invention, that one would be motivated to combine the teachings of Gulati et al within the disclosures of Curtis et al and Kapoor et al according to the motivation disclosed regarding claim 8.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Randy A. Scott whose telephone number is (571) 272-3797. The examiner can normally be reached on Monday-Thursday 7:30 am-5:00 pm, second Fridays 7:30 am-4pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RANDY A SCOTT/Primary Examiner, Art Unit 2439 20260124