DETAILED ACTION
This office action is responsive to request for continued examination filed on April 15, 2026 in this application Al Mohsin et al., U.S. Patent Application No. 18/396,347, (Filed December 26, 2023) (“Mohsin”). Claims 1, 2, 6-8, 12, 13, and 17 - 20 were pending. Claims 1, 12, and 20 are amended. Claims 1, 2, 6-8, 12, 13, and 17 - 20 are pending.
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 of on April 15, 2026 has been entered.
Response to Arguments
1. With respect to Applicant’s argument on pg. 7 of the Applicant’s Remarks (“Remarks”) stating that the amended claims overcome the rejection made under 35 USC 101, examiner respectfully agrees.
2. With respect to Applicant’s argument on pgs. 8 – 12 of the Remarks stating that prior art reference Shelke fails to teach different remediation measures and instead merely teaches different ways of performing the same remediation measure, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §103, § Claim 1.
Shelke teaches, as noted in Applicant’s arguments, that remediations may be automatic, semi-automatic, and manual at ¶ 0064. Shelke makes clear that these are not merely the same remediation performed in different ways but rather three separate remediation modules that are executed by the URA agent. Id. While the argued limitations of claim one state that there are more aggressive levels for some remediation actions there are no differences between the remediation action claimed beyond this characterization of aggressiveness levels. Thus, the different remediation modules of Shelke which perform different types of remediation actions teach the claimed remediation actions having aggressiveness levels. Id at ¶¶ 0059 – 0061, 0064.
Therefore, the current prior art teaches different remediation measures.
3. With respect to Applicant’s argument on pgs. 12 - 13 of the Remarks stating that prior art reference Shelke fails to teach performing the remediations automatically, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §103, § Claim 1.
As described supra, Shelke teaches three separate remediation modules that are executed by the URA agent. Id. at Id at ¶¶ 0059 – 0061, 0064. To the extent each remediation module may result in some manual action being performed by a user at a subsequent time, there is still a disclosure of automatically executing, by the URA agent, three different remediation modules which each cause a remediation step to be performed. The claims do not appear to limit the automatic performance of the remediations to requiring automatic performance of all steps of each remediation without any user involvement.
Therefore, the current prior art teaches performing the remediations automatically.
Claim Rejections - 35 USC § 101
In light of Applicant’s amendments the rejections made under 35 USC 101 are withdrawn.
Claim Rejections 35 U.S.C. §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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 6-8, 12, 13, and 17 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kurian et al., United States Patent Application Publication No. 20210374767 (Published December 2, 2021, filed June 2, 2020) (“Kurian”) in view of Shelke et al., United States Patent Application Publication No. 2022/0365771 (Published November 17, 2022, filed May 14, 2021) (“Shelke”), and Gupta et al., United States Patent Application Publication No. 2024/0248833 (Published July 25, 2024, filed January 23, 2023) (“Gupta”).
Claims 1, 12, and 20
With respect to claims 1, 12, and 20, Kurian teaches the invention as claimed including a method for device incompliance remediation, the method comprising:
generating an inventory of one or more endpoints comprising a first endpoint; determining a compliance state of each of the one or more endpoints for a compliance definition based on a compliance rule; determining that the first endpoint is incompliant based on its respective compliance state; {A list of endpoint compliance states for endpoints is generated, such as a queue of workload node non-compliance event data, the compliance state is compared to requirements rules to identify non-compliance such as a encryption failure like a too short or an incorrect password, then remediation actions required by the compliance state failing to satisfy the rule are performed for each entry in the non-compliance list such as running notification scripts or setting a password parameter value, the results of the remediation action including failures are recorded in a new list such as an event tracking log and remediation failures found in the new list may be retried again. Kurian at ¶¶ 0066, 0068, 0075, 0092 (receive non-compliance events from workload nodes); id. at ¶¶ 0067 & 0076 (queue of non-compliant nodes are prioritized by level according to time sensitivity and timestamps); id. at ¶¶ 0067, 0080, 0081 (remediation action is performed); id. at ¶¶ 0068, 0084, 0092 (list of remediation action results, or status, is created in a data store event tracking log and failed actions are retried and a counter of retries is recorded).}
However, Kurian doesn’t explicitly teach the limitation:
associating the first endpoint with two or more remediation actions, the two or more remediation actions ordered according a corresponding level, wherein a following remediation action has a more aggressive level than its previous remediation action; iteratively, until the two or more ordered remediation actions are exhausted or the first endpoint is determined to be compliant based on an updated compliance state of the first endpoint, wherein the updated compliance state is determined after each iteration: performing, on the first endpoint, an nth remediation action of the two or more remediation actions, wherein the value of n is given by a counter that increments with each iteration; …perform a manual remediation for the first endpoint in response to the two or more remediation actions being exhausted and the updated compliance state of the first endpoint indicating that the first endpoint is incompliant. {EN: Under the Broadest Reasonable Interpretation consistent with the specification the claimed process is interpreted as ending when the first endpoint is determined to be compliant. This may be after the first remediation action is performed. Since just one remediation may be performed under the BRI, the limitations directed to ordering remediations and performing n number of remediations are interpreted as not occurring under the BRI.
Shelke does teach this limitation. Shelke teaches that the device updating method, as taught in Kurian, may include where an “update readiness assistant” agent performs a software update, such as to an operating system, conduct scans to identify any failed aspects of the update, and then increments through a plurality of automated remediation script modules of increasing levels, checking after each module to see if the failure has been cured, including where the modules include automated, then semi-automated, and then finally manual remediation. Shelke at Abstract; id. at ¶¶ 0059 – 0061, 0064, 0066, 0074 – 0076, 0078.
Kurian and Shelke are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software configuration updating, and both are trying to solve the problem of how to remediate update errors.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a device updating method, as taught in Kurian, with applying multiple remediation actions, as taught in Shelke. Shelke teaches that the update process must be made “smoother and simpler.” Id. at ¶ 0005. Therefore, one having ordinary skill in the art would have been motivated to combine a device updating method, as taught in Kurian, with applying multiple remediation actions, as taught in Shelke, for the purpose of using a known update remediation process using multiple remediation methods to ensure update readiness with a process that requires updates be completed successfully.}
However, Kurian and Shelke doesn’t explicitly teach the limitation:
generating, automatically, a ticket in the ticketing system to [perform a manual remediation action] {Gupta does teach this limitation. Gupta teaches that incremental automated remediation of update failures which results in a required manual remediation, as taught in Kurian and Shelke, may include where, after a plurality of software errors, automated remediation attempts are performed resulting in failed remediation and then a ticket is generated and routed to a user to complete a manual remediation step. Gupta at Abstract; id. at ¶¶ 0032, 0034 – 0037, 0040, 0042.
Kurian, Shelke, and Gupta are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software remediation, and both are trying to solve the problem of how to remediate software errors.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine multiple remediation actions followed by a manual remediation, as taught in Kurian and Shelke, with using a ticketing system for the manual remediation, as taught in Gupta. Shelke teaches that the update process must be made “smoother and simpler.” Id. at ¶ 0005. Therefore, one having ordinary skill in the art would have been motivated to combine multiple remediation actions followed by a manual remediation, as taught in Kurian and Shelke, with using a ticketing system for the manual remediation, as taught in Gupta, for the purpose of using a known update remediation process using multiple automated remediations and ticketing for manual remediation to ensure update readiness with a process that requires updates be completed successfully including the use of manual remediation steps.}
Claims 2 and 13
With respect to claims 2 and 13, Kurian, Shelke, and Gupta, teach the invention as claimed including:
wherein the two or more remediation actions comprise at least one of installing a software, starting a service, setting a value of a parameter, creating a file, deleting a file, and running a script. {A list of endpoint compliance states for endpoints is generated, such as a queue of workload node non-compliance event data, the compliance state is compared to requirements rules to identify non-compliance such as a encryption failure like a too short or an incorrect password, then remediation actions required by the compliance state failing to satisfy the rule are performed for each entry in the non-compliance list such as running notification scripts or setting a password parameter value, the results of the remediation action including failures are recorded in a new list such as an event tracking log and remediation failures found in the new list may be retried again. Kurian at ¶¶ 0066, 0068, 0075, 0092 (receive non-compliance events from workload nodes); id. at ¶¶ 0067 & 0076 (queue of non-compliant nodes are prioritized by level according to time sensitivity and timestamps); id. at ¶¶ 0067, 0080, 0081 (remediation action is performed); id. at ¶¶ 0068, 0084, 0092 (list of remediation action results, or status, is created in a data store event tracking log and failed actions are retried and a counter of retries is recorded).}
Claims 6 and 17
With respect to claims 6 and 17, Kurian, Shelke, and Gupta, teach the invention as claimed including:
wherein the compliance definition comprises an encryption compliance and {A list of endpoint compliance states for endpoints is generated, such as a queue of workload node non-compliance event data, the compliance state is compared to requirements rules to identify non-compliance such as a encryption failure like a too short or an incorrect password, then remediation actions required by the compliance state failing to satisfy the rule are performed for each entry in the non-compliance list such as running notification scripts or setting a password parameter value, the results of the remediation action including failures are recorded in a new list such as an event tracking log and remediation failures found in the new list may be retried again. Kurian at ¶¶ 0066, 0068, 0075, 0092 (receive non-compliance events from workload nodes); id. at ¶¶ 0067 & 0076 (queue of non-compliant nodes are prioritized by level according to time sensitivity and timestamps); id. at ¶¶ 0067, 0080, 0081 (remediation action is performed); id. at ¶¶ 0068, 0084, 0092 (list of remediation action results, or status, is created in a data store event tracking log and failed actions are retried and a counter of retries is recorded).}
an operating system patching compliance. {Updating includes updating the software of an operating system. Shelke at ¶ 0002.}
Claims 7 and 18
With respect to claims 7 and 18, Kurian, Shelke, and Gupta, teach the invention as claimed including:
wherein the compliance state is one of compliant, incompliant, unknown, and inapplicable. {A list of endpoint compliance states for endpoints is generated, such as a queue of workload node non-compliance event data, the compliance state is compared to requirements rules to identify non-compliance such as a encryption failure like a too short or an incorrect password, then remediation actions required by the compliance state failing to satisfy the rule are performed for each entry in the non-compliance list such as running notification scripts or setting a password parameter value, the results of the remediation action including failures are recorded in a new list such as an event tracking log and remediation failures found in the new list may be retried again. Kurian at ¶¶ 0066, 0068, 0075, 0092 (receive non-compliance events from workload nodes); id. at ¶¶ 0067 & 0076 (queue of non-compliant nodes are prioritized by level according to time sensitivity and timestamps); id. at ¶¶ 0067, 0080, 0081 (remediation action is performed); id. at ¶¶ 0068, 0084, 0092 (list of remediation action results, or status, is created in a data store event tracking log and failed actions are retried and a counter of retries is recorded).}
Claims 8 and 19
With respect to claims 8 and 19, Kurian, Shelke, and Gupta, teach the invention as claimed including:
wherein the compliance rule comprises a compliance scope that determines whether the compliance rule applies to each of the one or more endpoints. {A list of endpoint compliance states for endpoints is generated, such as a queue of workload node non-compliance event data, the compliance state is compared to requirements rules to identify non-compliance such as a encryption failure like a too short or an incorrect password, then remediation actions required by the compliance state failing to satisfy the rule are performed for each entry in the non-compliance list such as running notification scripts or setting a password parameter value, the results of the remediation action including failures are recorded in a new list such as an event tracking log and remediation failures found in the new list may be retried again. Kurian at ¶¶ 0066, 0068, 0075, 0092 (receive non-compliance events from workload nodes); id. at ¶¶ 0067 & 0076 (queue of non-compliant nodes are prioritized by level according to time sensitivity and timestamps); id. at ¶¶ 0067, 0080, 0081 (remediation action is performed); id. at ¶¶ 0068, 0084, 0092 (list of remediation action results, or status, is created in a data store event tracking log and failed actions are retried and a counter of retries is recorded).}
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m..
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, Lewis Bullock can be reached on 571-272-3759. 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.H./ May 2, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights