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 .
Claims 1-20 are presented for examination.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 101
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claims 1, 10, 17, and 20:
Claim 1 (non-transitory storage medium), Claim 10 (System), Claim 17 (Method), and Claim 20 (CRM for Method) are directed to the abstract idea of analyzing system vulnerability data, determining corrective actions, and executing network remediation.
Step 2A, Prong 1 (Judicial Exception): The claims recite limitations to "perform artificial intelligence-based simulations of cyber-attacks, to assist in determining... how a simulated cyber-attack might occur... and how to use information to preempt possible escalations" and to "perform a remediation task to correct one or more misconfigurations... and return the one or more components back to a trusted operational state." These limitations recite mental processes (observing data, evaluating risk, and deciding on a course of action to secure a network) and mathematical concepts (the execution of algorithmic models via a "large language model").
Step 2A, Prong 2 (Practical Application): The claims do not integrate the abstract idea into a practical application. The claims merely recite applying the abstract idea using generic computing components (e.g., "orchestrator module," "one or more processors," "large language model") operating as functional black boxes to achieve a desired result. The claims fail to recite how the large language model technically interfaces with the network components to execute the "remediation task" or correct the misconfigurations at the system level.
Step 2B (Inventive Concept): The additional elements recited in the claims (e.g., a storage medium, a computing device) are recited at a high level of generality and represent well-understood, routine, and conventional computer components performing their basic functions. They do not amount to significantly more than the abstract idea itself.
Dependent claims 2-9, 11-16 and 18-19:
Claims 2 and 11 adds the step of initiating a series of API calls to acquire external exposure information. This represents insignificant extra-solution activity—specifically, mere data gathering using conventional networking techniques (API calls)—which does not integrate the abstract idea into a practical application or supply an inventive concept.
Claims 3 and 12 limit the gathered data to specific categories ("user context information", "known cyber-attack paths", and "pattern of life event data"). Restricting an abstract idea to a particular technological environment or specifying the type of data being gathered fails to confer eligibility.
Claims 4 and 13 further limit the "pattern of life event data" to traffic patterns and log data. Similar to Claim 3, classifying the specific data types being analyzed does not transform the abstract idea into a patent-eligible technological improvement.
Claim 5 adds the limitation of assigning an "external exposure score" to prioritize computing devices. This adds a mathematical calculation step to the claim, which is itself an abstract idea, and does not provide an inventive concept to overcome the 101 rejections.
Claim 6 adds conducting analytics on functionality (analyzing settings, software updates, and software presence). This is a classic mental process of reviewing and analyzing collected data. It fails to provide a specific technical solution to a technical problem.
Claims 7 and 14 adds accessing a threat technique data store, determining alignment, and factoring that alignment into a recommendation message. This recites comparing data and outputting a result, which are routine data processing steps and mere post-solution activity.
Claims 8 and 15 add establishing communications and acquiring misconfiguration and cloud resource information from a cloud service provider. This is conventional network communication acting as mere data gathering.
Claims 9 and 16 add obtaining threat landscape data to factor into a recommendation message. Outputting a text-based recommendation based on gathered data is a standard mental process and insignificant post-solution activity.
Claim 18 adds the steps of initiating API calls to acquire information and assigning an external exposure score. This combines mere data gathering with a mathematical calculation. It is rejected for failing to provide significantly more than the abstract idea.
Claim 19 adds acquiring misconfiguration information from a cloud service provider. This constitutes conventional data gathering and is rejected for failing to supply an inventive concept.
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-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claims contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
The independent claims (1, 10, and 17) require a "large language model" (LLM) that is configured to "perform a remediation task to correct one or more misconfigurations in one or more components... and return the one or more components back to a trusted operational state."
Large language models are inherently generative AI models that output text or code based on probabilistic token prediction. While the specification describes the LLM generating recommendations for remediation (e.g., Para [0159]: "The misconfiguration remediation suggestion module 460 generates the second recommendation message 480... along with a listing of steps"), the claims demand that the LLM itself performs the remediation task to actively correct misconfigurations.
Undue Experimentation: The specification treats the technical execution of this autonomous, LLM-driven remediation as a functional black box. It mentions that an LLM can be provided with API specifications (Para [0041]), but fails to disclose the specific architecture, safety guardrails, translation layers, or logic required to allow a generative text model to reliably and autonomously execute write-commands to reconfigure live network hardware or cloud infrastructure without human intervention. A person of ordinary skill in the art would have to undertake undue experimentation to bridge the gap between an LLM generating a natural language "recommendation" and an LLM actively "returning the components back to a trusted operational state."
Claims 1-20 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.
Claim 1 recites that the second orchestrator module (which includes the LLM) is configured to "perform a remediation task to correct one or more misconfigurations." Claim 10 recites “preform a remediation task to correct one or more misconfigurations”. Claim 17 recites “performing, using the large language model, a remediation task”. However, the specification repeatedly describes this module (Element 450 in FIG. 4) as a "misconfiguration remediation suggestion module" (Paras [0159]-[0160]). The specification clearly describes this module as generating recommendations and providing a "listing of steps (e.g., in text format, URL links, etc.) to perform the recommended operations." The specification primarily supports an LLM that outputs textual suggestions rather than an LLM that actively executes the correction of the misconfiguration itself.
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-20 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, 10 and 17 recite “trusted operational state”. This is a relative term/term of degree. What defines a "trusted" state versus an "untrusted" state? The specification mentions returning systems to a "trusted operational state" (e.g., Paras [0113], [0133]), but it does not provide an objective baseline, metric, or boundary for what constitutes "trusted”. Without a clear standard in the specification, a person of ordinary skill in the art cannot determine the objective scope of "trusted," rendering the claims indefinite.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fellows et al., US 2023/0164158 in view of Marsenic et al, US 2023/0132703 and further in view of Humphrey et al, US 2021/0273961.
Regarding claim 1, Fellows teaches a non-transitory storage medium including software configured, when executed by one or more processors, to enhance cyber threat detection or a response to a cyber threat detected by a cybersecurity appliance of a cybersecurity system (Fig. 1 and Paragraph 0183: the cyber security appliance 100 with the multiple Artificial Intelligence-based engines is implemented on computer 1. Computer 1 on the first computer system 10 has the electronic hardware, modules, models, and various software processes of the cyber security appliance 100; and therefore, runs threat detection for detecting threats to the first computer system. As such, the computer system includes one or more processors), the software comprising:
a first orchestrator module including at least a first [large language model] that is configured, when executed by the one or more processors, to perform artificial intelligence-based simulations of cyber-attacks, to assist in determining (i) how a simulated cyber-attack might occur in a selected computing device protected by the cybersecurity system, and (ii) how to use simulated cyber-attack information to preempt possible escalations of an ongoing actual cyber-attack (a “prediction engine” using “artificial intelligence algorithms configured and trained to perform a fourth machine-learned task of artificial based simulations of cyber-attacks to assist in determining 1) how a simulated cyberattack might occur…and 2) how to use the simulated cyberattack information to preempt possible escalations…”, 0016, 0026, 0055); and
a second orchestrator module including at least a second [large language model] that is configured, when executed by the one or more processors, to perform a remediation task to correct one or more misconfigurations in one or more components associated with the cybersecurity system and return the one or more components back to a trusted operational state (a “cyber security restoration engine” taking “remedial actions to remediate one or more nodes of the system being protected back to a trusted operation state”, 0008, 0014. Detecting and acting upon a “simple system misconfiguration”, 0034.).
Fellows lacks or does not expressly disclose a first and a second large language mode.
However, Marsenic teaches the use of Natural Language Processing (NLP) to parse unstructured data (e.g. job titles, filenames, organizational hierarchy) to generate the impact scores used by the attack simulator and remediation engines (0059-0060, 0071).
While Fellows teaches returning a system to a trusted sate, Humphrey teaches the AI automatically interacting with external/cloud systems to correct permission states (misconfigurations). Humphrey teaches an AI cybersecurity system that operates generating “natural language prose” reports and utilizing investigation “scripts”, (remediating misconfigurations, 0015, 0114, 0158).
A person of ordinary skill in the art would recognize an LLM as simply and advanced, contemporary implementation of the Natural Language Processing (NLP) algorithms taught in Marsenic. Substituting generic NLP algorithms with an LLM is a predictable use of an upgraded technology to perform the exact same language-parsing and reasoning functions, yielding a predictable result. Therefore, it would have been obvious, to one of ordinary skill in the art, before the effective filing date of the claimed invention, to substitute the NPL models of Marsenic and Humphrey’s AI cybersecurity system into the system of Fellows to include a Large Language Model, in order to perform the simulation analytics and remediation parsing.
Regarding claim 2, Fellows, as modified above, generally mentions APIs for taking action but does not explicitly detail the sub-components of the orchestrator initiating API calls to acquire external exposure information. However, Humphrey further discloses wherein the first orchestrator module comprises a mitigation remediation suggestion module configured to initiate a series of application programming interface (API) calls to multiple computing devices including the selected computing device to acquire information associated with the computing devices. (using “Application Programming Interfaces (APIs)” to interface with external system and devices to pull capabilities and orchestrate actions, 0049. 0273: An API trigger/control signal via third party inputs…to manually trigger investigations which rely on third-party data. 0158: The connector may send an API request.). Neither Fellows nor Humphrey explicitly focuses on scoring how exposed a device is to the outside world for the purpose of running simulations. However, Marsenic teaches including external exposure information associated with each of the computing devices (0005: the “remediation suggester module”. 0118-0122: calculating the external exposure information, noting that the system evaluates “externally facing servers” by checking their patch-levels, non-standard service ports, and cloud storage permissions to calculate an “ingress probability” (how likely they are to be explodes to/penetrated by an outsider).
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fellows to integrate the API data gathering mechanisms of Humphrey and the exposure scoring analytics of Marsenic to optimize the platform’s threat defense capabilities.
Regarding claim 3, Fellows, as modified above, further discloses the non-transitory storage medium of claim 2, wherein the acquired information includes (1) user context information, (2) known cyber-attack paths, and (3) pattern of life event data that provides an intrinsic understanding of normal behaviors for the selected computing device or a user of the selected computing device (0073: establishing pattern of life event data to provide an intrinsic understanding of normal behaviors). Fellows does not explicitly detail gathering user context or known attack paths for simulations. However, Marsenic teaches analyzing user context information, such as job titles and organizational hierarch to map and determine key cyber-attack paths within a network (0005, 0059).
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to combine the behavioral pattern of life data of Fellows with the user context and attack path mapping of Marsenic to yield the predictable result of a simulation engine that accurately models both machine and human vulnerabilities.
Regarding claim 4, Fellows, as modified above, further discloses the non-transitory storage medium of claim 3, wherein the pattern of life event data includes (i) traffic pattern, and (ii) log that maintains a record of incoming and outgoing network traffic including blocked connections and communication attempts and access logs that maintain successful logins and unauthorized access attempts from unexpected locations could indicate external communication (0073 and 0092: tracking traffic patterns, packet volume and storing comprehensive logs for network traffic to build a pattern of life). Fellows lacks or does not expressly disclose logs of login attempts. However, Humphrey teaches tracking access logs, including successful logins and login failures (0238). It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to combine the specific access log tracking of Humphrey into the pattern of life data store of Fellows to provide the AI models with complete picture of network authentication events.
Regarding claims 5-7, Fellows lacks or does not expressly disclose an external exposure score. However, Marsenic teaches wherein the mitigation remediation suggestion module is further configured to assign an external exposure score to each analyzed computing device to prioritize a prescribed number of the computing devices with a greatest external exposure (calculating an “ingress probability” (external exposure score) to prioritize devices, 0118-0127. Evaluates the status of software updates (“patch level of the user devices”) and settings (evaluating if a “Service Port” is running a “non-standard port” or has “cloud-storage permissions”, 0016-0127);
wherein the mitigation remediation suggestion module is further configured to conduct analytics on functionality of the prescribed number of computing devices with the greatest external exposure score, the functionality includes an analysis of one or more settings of the prescribed number of computing devices, a status of software updates, a presence of software modules unnecessary for an intended operability of each of the prescribed number of computing devices; wherein the mitigation remediation suggestion module is further configured to (i) access a threat technique data store including threat technique data associated with threat landscape data gathered by the cybersecurity system and (ii) determine if any mitigation suggestions aligns with the stored threat technique data and factor any alignment into a first recommendation message output by the mitigation remediation suggestion module (Fellows teaches an AI model “trained on characteristics and attributes of known potential cyber threats” (the threat technique data store), 0071. Marsenic teaches “remediation suggester module” generates a report suggesting “how to perform the intelligent prioritization of remediation action” (the first recommendation message), 0005 and 0076). It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to combine the vulnerability scoring and setting analytics of Marsenic with the known threat database of Fellows to intelligently generate and output prioritized mitigation recommendations.
Regarding claim 8, Fellows, as modified above, further discloses the non-transitory storage medium of claim 2, wherein the second orchestrator module comprises a misconfiguration remediation suggestion module configured to establish communications with and acquire information from the one or more components, the acquired information includes detected misconfigurations of the one or more components provided from a cloud service provider along with cloud resource information that provides additional context associated with the one or more components (0158: identifying errant virtual resources and spinning them down. Utilizing historical “IaaS data on virtual resource usage” (cloud resource info) to identify “errant virtual resources” (misconfigurations) and disabling or spinning down those misconfigured cloud resources. Fellows lacks or does not expressly disclose a cloud provider. However, Humphrey teaches establishing communications with a cloud service provider (SaaS operator) via APIs to acquire third party event data, identify breaches/misconfigurations, and modify remote user permissions (0157-0159). It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to combine the cloud permission remediation of Humphrey with the restoration engine of Fellows to yield a system capable of acquiring and correcting cloud resource misconfigurations directly from a cloud service provider.
Regarding claim 9, Fellows lacks or does not expressly disclose threat landscape data. However, Humphrey teaches the misconfiguration remediation suggestion module is further configured to establish communications with the cybersecurity appliance to obtain information associated with threat landscape data and to factor the information into a second recommendation message output by the misconfiguration remediation suggestion module, the second recommendation message includes a listing of steps to perform correct a misconfiguration or increase network security (0279 and 0282: triggering investigations based on external threat landscape data: “An operator configures the cyber security appliance to have access to their third-party threat intelligence systems). Marsenic teaches the remediation suggester module analyzes the attack model and suggests “how to perform the intelligent prioritization of remediation action in at least one of a report and an autonomous remediation action” (providing the steps/priorities to correct the identified misconfigurations), 0005 and 0076.
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the claimed invention, to combine the external threat intelligence gathering of Humphrey into the remediation suggester of Marsenic to ensure that the recommended remediation steps are accurately factored against the current global threat landscape.
As per claims 10-16 and 17-20, this is a system and method version of the claimed storage medium discussed above in claims 1-9 wherein all claimed limitations have also been addressed and/or cited as set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2024/0385818 to Silverstein teaches the remediation action can include flagging the one or more functions that have source code execution variability scores that exceed the threshold values for review by a software developer. In other embodiments, the remediation action can include automatically replacing a portion of the one of the one or more functions with a suitable alternative that has a lower variability score than the portion. In exemplary embodiments, automatically replacing a portion of the one of the one or more functions with a suitable alternative is performed by providing the one or more functions to a large language model and requesting that the large language model provide a suitable alternative to the source code that would have a more consistent execution time that the provided function.
US 20023/0208869 to BISHT et al teaches an autonomous decision engine (ADE) module coupled to the SSE module. In an example, the ADE module is configured for a remediation process. In an example, the remediation process comprises an autonomous decision engine comprising a sense process, plan process, and an act process (collectively the “AI processes” or “AI decision processes”), and is configured to make a decision from the flow of data to remediate and take appropriate action based upon the what signal is received from the client device, and processed through a behavior analytics engine.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AUBREY H WYSZYNSKI whose telephone number is (571)272-8155. The examiner can normally be reached M-F 9-5.
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, ALI SHAYANFAR can be reached at 571-270-1050. 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.
/AUBREY H WYSZYNSKI/Primary Examiner, Art Unit 2434
