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
Response to Arguments
Applicant’s arguments filed April 23, 2026 have been fully considered. After further consideration, a new ground(s) of rejection is presented due to Applicant’s amended claim language.
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 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.
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 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.
MPEP 2112 Section III.
Where applicant claims a composition in terms of a function, property or characteristic and the composition of the prior art is the same as that of the claim but the function is not explicitly disclosed by the reference, the examiner may make a rejection under both 35 U.S.C. 102 and 103, expressed as a 102/ 103 rejection. "There is nothing inconsistent in concurrent rejections for obviousness under 35 U.S.C. 103 and for anticipation under 35 U.S.C. 102." In re Best, 562 F.2d 1252, 1255 n.4, 195 USPQ 430, 433 n.4 (CCPA 1977). This same rationale should also apply to product, apparatus, and process claims claimed in terms of function, property or characteristic. Therefore, a 35 U.S.C. 102/ 103 rejection is appropriate for these types of claims as well as for composition claims.
Claims 1, 2, 5, 9 – 12, 15 – 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hassanzadeh (US Pub. No. 2020/0137104 A1) in view of McGrew (US Pub. No. 2024/0333765 A1) in view of Microsoft (US Pub. No. 2024/0419835 A1) in view of Allen (US Pub. No. 2019/0332784 A1).
Per claim 1, Hassanzadeh (US Pub. No. 2020/0137104 A1) suggests a system, comprising: a processor configured to (see Hassanzadeh para 0143 - 0146): receive (reads on "the Agirem service 210 provides remediation options", see Hassanzadeh para 0050. Hassanzadeh discloses that a downstream component of its platform takes the AgiHack-generated attack graph as input for further processing) a graph of a network that includes (reads on a graph that is representative of an enterprise network, see Hassanzadeh para 0005) one or more vulnerabilities and/or one or more risk findings (reads on an attack graph representing all possible impacts and vulnerabilities, network/system configurations and possible impacts on a respective target, see Hassanzadeh para 0008 and 0049 – 0051);
contextualize (reads on identifies critical assets and critical paths and provides context about which elements are more important, see Hassanzadeh para 0005, 0050, 0051 and 0064 and reads on "predicts the impact of asset vulnerabilities on the critical processes and adversary capabilities along kill chain/attack paths and identifies the likelihood of attack paths to access critical assets and prioritizes the assets (e.g., based on shortest, easiest, stealthiest)", see Hassanzadeh para 0050. Hassanzadeh's AgiRem service maps vulnerabilities to criticality/attack-path context)) the graph of the network (reads on a graph that is representative of an enterprise network, see Hassanzadeh para 0005); and a memory coupled to the processor and configured to provide the processor with instructions (see Hassanzadeh para 0143 - 0146). The prior art of record is silent on explicitly stating generate one or more prompts and input the contextualized graph to a Large-Language Model (LLM), comprising to: add the one or more prompts and a guardrail to the contextualized graph, wherein the one or more prompts are a set of questions that guide the LLM to generate an appropriate response to the graph, and wherein the guardrail is used for obfuscating private information; and generate an output that summarizes the contextualized graph using the LLM.
[0005] In some implementations, actions include providing, by a security platform, graph data defining a graph that is representative of an enterprise network, the graph comprising nodes and edges between nodes, a set of nodes representing respective assets within the enterprise network, each edge representing at least a portion of one or more lateral movement paths between assets in the enterprise network, determining, for each asset, a criticality of the respective asset to operation of a process, determining a lateral movement path between a first node represented by a first asset and a second node represented by second asset within the graph, determining a path value representative of a criticality in preventing an attack through the lateral movement path, and providing an indication of the path value representative of the criticality in preventing an attack through the lateral movement path.
[0048] In the example of FIG. 2, the AgiHack service 208 includes an attack graph (AG) generator 226, an AG database 228, and an analytics module 230. In general, the AgiHack service 208 constructs AGs and evaluates hacking exploitation complexity. In some examples, the AgiHack service 208 understand attack options, leveraging the vulnerabilities to determine how a hacker would move inside the network and identify targets for potential exploitation. The AgiHack service 208 proactively explores adversarial options and creates AGs representing possible attack paths from the adversary's perspective. The AgiHack service 208 provides both active and passive vulnerability scanning capabilities to comply with constraints, and identifies device and service vulnerabilities, configuration problems, and aggregate risks through automatic assessment.
[0049] In further detail, the AgiHack service 208 provides rule-based processing of data provided from the AgiDis service 214 to explore all attack paths an adversary can take from any asset to move laterally towards any target (e.g., running critical operations). In some examples, multiple AGs are provided, each AG corresponding to a respective target within the enterprise network. Further, the AgiHack service 208 identifies possible impacts on the targets. In some examples, the AG generator 226 uses data from the asset/vulnerabilities knowledge base 236 of the AgiDis service 214, and generates an AG. In some examples, the AG graphically depicts, for a respective target, all possible impacts that may be caused by a vulnerability or network/system configuration, as well as all attack paths from anywhere in the network to the respective target. In some examples, the analytics module 230 processes an AG to identify and extract information regarding critical nodes, paths for every source-destination pair (e.g., shortest, hardest, stealthiest), most critical paths, and critical vulnerabilities, among other features of the AG. If remediations are applied within the enterprise network, the AgiHack service 208 updates the AG.
[0050] In the example of FIG. 2, the AgiRem service 210 includes a graph explorer 232 and a summarizer 234. In general, the AgiRem service 210 provides remediation options to avoid predicted impacts. For example, the AgiRem service 210 provides options to reduce lateral movement of hackers within the network and to reduce the attack surface. The AgiRem service 210 predicts the impact of asset vulnerabilities on the critical processes and adversary capabilities along kill chain/attack paths and identifies the likelihood of attack paths to access critical assets and prioritizes the assets (e.g., based on shortest, easiest, stealthiest). The AgiRem service 210 identifies remediation actions by exploring attack graph and paths.
[0051] In further detail, for a given AG (e.g., representing all vulnerabilities, network/system configurations, and possible impacts on a respective target) generated by the AgiHack service 208, the AgiRem service 210 provides a list of efficient and effective remediation recommendations using data from the vulnerability analytics module 236 of the AgiInt service 212. In some examples, the graph explorer 232 analyzes each feature (e.g., nodes, edges between nodes, properties) to identify any condition (e.g., network/system configuration and vulnerabilities) that can lead to cyber impacts. Such conditions can be referred to as issues. For each issue, the AgiRem service 210 retrieves remediation recommendations and courses of action (CoA) from the AgiInt service 212, and/or a security knowledge base (not shown). In some examples, the graph explorer 232 provides feedback to the analytics module 230 for re-calculating critical nodes/assets/paths based on remediation options. In some examples, the summarizer engine 234 is provided as a natural language processing (NLP) tool that extracts concise and salient text from large/unstructured threat intelligence feeds. In this manner, the AgiSec platform can convey information to enable users (e.g., security teams) to understand immediate remediation actions corresponding to each issue.
[0064] As introduced above, implementations of the present disclosure provide for prioritization of actions for remediation of cyber attacks based on lateral movements of a malicious user within a network. More particularly, and as described in further detail herein, implementations of the present disclosure consider the ability of malicious users to access supporting CIs from the network through lateral movements and estimate which attack path should be handled first in order to prevent a comprised CI. In some implementations, a relative importance and complexity of an attack path are determined and cyber actions to block accessing a CI are prioritized. In this manner, cyber actions are efficiently implemented to prevent damage and reduce the attack surface and internals of the network, gradually increasing the entire network cyber resilience.
[0143] Implementations and all of the functional operations described in this specification may be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations may be realized as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “computing system” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question (e.g., code) that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) that is generated to encode information for transmission to suitable receiver apparatus.
[0144] A computer program (also known as a program, software, software application, script, or code) may be written in any appropriate form of programming language, including compiled or interpreted languages, and it may be deployed in any appropriate form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
[0145] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry (e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit)).
[0146] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any appropriate kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. Elements of a computer can include a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data (e.g., magnetic, magneto optical disks, or optical disks). However, a computer need not have such devices. Moreover, a computer may be embedded in another device (e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver). Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.
PNG
media_image1.png
596
998
media_image1.png
Greyscale
McGrew (US Pub. No. 2024/0333765 A1) is relied upon to teach contextualize the (reads on the combination of taking the full graph and extracting relevant portions/subgraph and converting to understandable attack vectors, see McGrew para 0073 – 0075 and 0081. The Examiner construes extracting the subgraph and converting to attack vectors to be the same as Applicant’s contextualizing because they both perform the same function of taking the full graph and compresses/linearizes into meaningful security info/identifying critical elements) graph of the network (reads on the ontology graph that represents various relations between entities, see McGrew para 0073); generate one or more prompts (reads on the use of the prompt generator, see McGrew para 0078 – 0081) and input (read on the subgraph/attack vectors are input to the prompt generator, see McGrew para 0075 and 0078) the contextualized graph (reads on the combination of taking the full graph and extracting relevant portions/subgraph and converting to understandable attack vectors, see McGrew para 0073 – 0075 and 0081. The Examiner construes extracting the subgraph and converting to attack vectors to be the same as Applicant’s contextualizing because they both perform the same function of taking the full graph and compresses/linearizes into meaningful security info/identifying critical elements) to a Large-Language Model (LLM) (reads on the prompt generator uses a GPT model, see McGrew para 0111), comprising to: add the one or more prompts and a guardrail to the contextualized graph (reads on "Using the attack vectors 224, a policy and configuration generator 226 then generates a policy 228 for the prompt generator 230. Policy 228 directs the prompt generator 230 regarding the substance (e.g., the attack vectors 224) and style of the summary 232 to be created by the prompt generator 230. Policy 228 can include a comprehensive list of known attack vectors relevant to the system or software in consideration", see McGrew para 0078. McGrew para 0078 discloses exactly the composite input to the prompt generator 230 that reads on the recitation: (i) attack vectors 224 (the contextualized-graph content), (ii) policy 228 (the guardrail, under the rule/policy-layer BRI), and (iii) the prompt-generation instructions that direct the prompt generator's substance and style. The composite is "added" to the contextualized graph content at the input stage of the LLM pipeline in the plain BRI sense of "add ... to the contextualized graph"); and generate an output that summarizes (reads on the summary that is the output of the prompt generator, see McGrew Figure 2 blocks 230 and 232) the contextualized graph (reads on the combination of taking the full graph and extracting relevant portions/subgraph and converting to understandable attack vectors, see McGrew para 0073 – 0075 and 0081. The Examiner construes extracting the subgraph and converting to attack vectors to be the same as Applicant’s contextualizing because they both perform the same function of taking the full graph and compresses/linearizes into meaningful security info/identifying critical elements) using the LLM (reads on the prompt generator uses a GPT model, see McGrew para 0111).
[0073] FIG. 2 shows an example of an ontology summary system 200 that generates prompts summarizing the security incident giving rise to a threat alert. The ontology summary system 200 has an ontology generator 208 that receives various inputs, including, e.g., a threat alerts 202, a third-party ontologies 204, an additional inputs 206 Based on these inputs, the ontology generator 208 creates an ontology graph 210 that represents various relations between entities of computational instructions that have been executed by a computer/processor. These entities can include files, executable binary, processes, domain names, IP addresses, etc.
[0074] The ontology summary system 200 also has a query generator 214 that creates a query 216 based on values from a telemetry graph database 212, which stores graphs/patterns that represent respective malicious behaviors. The query 216 includes a query graph that is compared to various portions of the ontology graph 210 by the query processor 218. This comparison can be based on the topology (e.g., the spatial relations) and content (e.g., values of the vertices/nodes and relations expressed by the edges). When a match is found, the portion of the ontology graph 210 that matches the query graph is returned as subgraph 220.
[0075] The remainder of the ontology summary system 200 provides a summary 232 of subgraph 220 and then validates the summary and displays it in a graphical user interface (GUI) 236. First, the attack vector generator 222 converts the subgraph 220 of detected malware identified during penetration testing into a plurality of attack vectors 224. An attack vector is a specific route or method that malicious actors could employ to exploit vulnerabilities within a system, network, application, or device. It serves as a meticulously mapped-out pathway that outlines the sequence of steps an attacker might follow to compromise the intended target. The attack vectors with assist in the identification of potential weaknesses that necessitate mitigation to fortify the defenses of a system. These attack vectors encompass a wide array of techniques that can be categorized into various classes. Network-based attacks, for instance, revolve around leveraging vulnerabilities present in network protocols, services, or devices. Examples of these encompass activities such as network sniffing, distributed denial of service (DDOS) attacks, and the execution of Man-in-the-Middle (MitM) attacks that intercept communications.
[0078] Using the attack vectors 224, a policy and configuration generator 226 then generates a policy 228 for the prompt generator 230. Policy 228 directs the prompt generator 230 regarding the substance (e.g., the attack vectors 224) and style of the summary 232 to be created by the prompt generator 230. Policy 228 can include a comprehensive list of known attack vectors relevant to the system or software in consideration. This list could contain vulnerabilities, exploits, malware, and social engineering tactics. For each attack vector identified, policy 228 outlines which specific security measures and configurations are necessary to mitigate or prevent any associated attacks. These measures could encompass updated configurations for network appliances in the wireless network, security controls, wireless network configurations, and network access controls.
[0079] Additionally, the generated policy 228 could include mappings between attack vectors and corresponding security measures to ensure that appropriate steps are taken for each type of attack vector. The mapping could include configurations that are identified as being most effective against specific attack vectors, and malware that has previously penetrated the security system, allowing for the ability to take proactive steps to protect the network and the associated systems and data from malicious actions and attackers. In some examples, the prompt can identify a plurality of relationships between wireless appliances or nodes within the network. For example, the prompt can express more complex relationships between three or more nodes, thereby making broader connections that can help security analysts more quickly comprehend the information expressed by subgraph 220. Thus, security analysts can more quickly assess the a threat alert stimulated by identified penetration of the network system by malware.
[0081] Additionally, the summary 232 can be displayed in the GUI 236. The GUI 236 can include both the text of the summary 232 and a visual representation of the subgraph 220. The subgraph 220 provides ground truth, and the summary 232 provides a more easily comprehended mechanism for understanding the subgraph 220. According to certain non-limiting examples, a user can select a portion of the text of the summary 232, and in response, the GUI 236 highlights a corresponding portion of the subgraph associated with the selected text. Thus, starting from the text of the summary, a security analyst can quickly find the relevant features in the subgraph 220 that correspond to portions of the text of the summary. Then referring to the corresponding region of the subgraph 220, the security analyst can verify that, for the relevant features, the relations expressed in the text are consistent with the corresponding region of the subgraph 220, thereby confirming a correct understanding of the threat.
[0111] FIG. 4A illustrates a block diagram for an example of a transformer neural network architecture, in accordance with certain embodiments. As discussed above, the prompt generator 230 in FIG. 2 can use a transformer architecture 400, such as a Generative Pre-trained Transformer (GPT) model. Additionally or alternatively, the prompt generator 230 can include a Bidirectional Encoder Representations from Transformers (BERT) model. According to certain non-limiting examples, the transformer architecture 400 is illustrated in FIG. 4A through FIG. 4C as including inputs 402, an input embedding block 404, positional encodings 406, an encoder 408 (e.g., encode blocks 410a, 410b, and 410c), a decoder 412 (e.g., decode blocks 414a, 414b, and 414c), a linear block 416, a softmax block 418, and output probabilities 420.
PNG
media_image2.png
1234
824
media_image2.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the threat analysis teachings of the prior art of record by integrating the threat analysis teachings of McGrew to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known LLM/GPT technique of McGrew would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the ability to use the LLM/GPT technology of McGrew to summarize the security graphs of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems, resulting in an improved system that achieves better analyst comprehension of security threats – due to this being a common goal of all cited art. The motivation to combine the references is applied to all claims below this heading.
Microsoft (US Pub. No. 2024/0419835 A1) is relied upon to teach
wherein the one or more prompts are (reads on "a graph query specifies context data that should be obtained by graph traversal and a LLM prompt (e.g., a generative prompt). The graph query triggers a knowledge graph traversal to obtain the context data that is then used by an LLM to answer a question or query posed in the LLM prompt", see Microsoft para 0014). Microsoft discloses that the LLM prompt is a question posed to the LLM to be answered from graph) a set of questions (reads on "graph traversal may be used to answer other questions without having to perform an additional traversal. Other relevant questions that can be executed over the exact same graph traversal include, for example, "Who is the most prolific author?" and "What is the number one topic the author has worked on?", see Microsoft para 0055; inner example questions preserved verbatim with source curly quotes). Microsoft discloses a set of contemplated questions over the same graph traversal which is the "set of questions" recitation) that guide the LLM to generate an appropriate response to the graph (reads on "The LLM prompt ends with the question to be answered. The LLM prompt may have a variable number of arguments, but effectively includes a command/question (e.g., who are the nephews of Donald Duck) and context to the prompt (e.g., table with three headers: anchor name, relationship, and other name)", see Microsoft para 0041. Microsoft discloses that the prompt "ends with the question to be answered" and includes a "command/question" plus context, the question-form structure that guides the LLM's output).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the prior art’s LLM-based graph-summarization pipeline by incorporating Microsoft's question-form LLM-prompt structuring so that the system's prompt generator poses an explicit question to the LLM when producing a summary from graph-derived context data. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2143(C) and 2143(0), support this conclusion because the proposed combination applies a known technique to a known device ready for improvement, and uses a known technique to improve a similar LLM-prompt device in the same way, to yield predictable results. Microsoft expressly teaches that knowledge-graph queries incorporate LLM prompts structured around a question to be answered using graph-derived context data. For example, Microsoft states: para 0014: "a graph query specifies context data that should be obtained by graph traversal and a LLM prompt (e.g., a generative prompt). The graph query triggers a knowledge graph traversal to obtain the context data that is then used by an LLM to answer a question or query posed in the LLM prompt." Microsoft further states: para 0041: "The LLM prompt ends with the question to be answered." Microsoft also expressly discloses: para 0041: "the LLM prompt may have a variable number of arguments, but effectively includes a command/question (e.g., who are the nephews of Donald Duck) and context to the prompt." Microsoft further contemplates that this question-based prompt structuring is a domain-general architectural principle, not one confined to any particular subject-matter graph. In particular, Microsoft states: para 0019: "Example embodiments add support for new keywords used to interact with an LLM such that capabilities of the LLM can be included directly in the graph query." Microsoft also explains: para 0062: "the query API component 312 makes a call ... to the generative AI system 214 with the LLM prompt and the context data. The invocation can also be through a procedure, method, or function call or IPC for an LLM operating on a same machine/server as the graph query system 210." By defining the LLM prompt generically as context data plus a terminal question, Microsoft supports embodiments where the same question-form prompt architecture is applied across any enterprise knowledge graph, including security-related knowledge graphs, without requiring a different physical LLM-invocation mechanism. McGrew expressly teaches a graph-summarization pipeline in which a prompt generator is directed by an upstream policy governing what the generated summary should contain and how it should be styled. For example, McGrew states: para 0078: "a policy and configuration generator 226 then generates a policy 228 for the prompt generator 230. Policy 228 directs the prompt generator 230 regarding the substance (e.g., the attack vectors 224) and style of the summary 232 to be created by the prompt generator 230."Most directly, McGrew recites: para 0080: "The summary validator 234 checks the summary 232 to determine whether the summary is consistent with the subgraph 220, thereby ensuring that important aspects of the subgraph were not lost or misinterpreted in the translation from the subgraph 220 to the summary 232."
Accordingly, it would have been obvious to one of ordinary skill in the art to have applied Microsoft's known question-ending LLM-prompt structure to the policy-directed prompt generator disclosed in McGrew, so that the question posed to the LLM by McGrew's prompt generator 230 is the terminal element of the prompt following the context data drawn from subgraph 220, in the same manner Microsoft discloses for its own graph-derived context tables. A person of ordinary skill in the art would have recognized that McGrew already provides the policy-driven back-end for determining what substantive content (attack vectors) and style the summary should have, while Microsoft provides a known and express front-end mechanism for terminating any such LLM prompt with an explicit question to be answered. This would have been particularly suitable in McGrew's expressly contemplated implementation in which the prompt generator already receives structured "substance" and "style" policy inputs, because Microsoft's question-form termination naturally supplies the final question element needed to direct the LLM toward the policy-specified summary content without requiring any change to McGrew's underlying attack-vector extraction or summary-validation architecture. The combination would have yielded the predictable result of a more specific, question-anchored security-graph summary in the same LLM-prompt-engineering context addressed by both references, without changing the basic operation of either reference. The motivation to combine arises from the shared field addressed by both references, LLM-prompt architectures operating over knowledge graphs, and from Microsoft's express, domain-general teaching that an LLM prompt should end with the question to be answered, which would have predictably improved the specificity of McGrew's policy-directed summary output. McGrew is expressly concerned with generating a policy-consistent, validated summary of a security subgraph, while Microsoft is expressly concerned with structuring any LLM prompt, including prompts drawing on an enterprise knowledge graph, around a terminal question to be answered from graph-derived context. Thus, a person of ordinary skill in the art would have had reason to combine the references under MPEP 2143(C) (applying a known technique to improve similar devices in the same way) and 2143(D) (applying a known technique to a known device ready for improvement to yield predictable results).
Allen (US Pub. No. 2019/0332784 A1) is relied upon to teach
wherein the guardrail is used for obfuscating (reads on "presenting obfuscation options in the user interface for masking the sensitive content within at least a selected portion among the user content. Responsive to a user selection of at least one of the obfuscation options, the method includes replacing associated user content with obfuscated content that maintains a data scheme", see Allen para 0004. Allen discloses obfuscation options for masking sensitive content and replacing that content with obfuscated content – a rule/policy-layer obfuscation operation on user content passing through the pipeline) private information (reads on Allen's "sensitive content" terminology at para 0004. Under BRI, "sensitive content" is coextensive with "private information" in the LLM/graph-obfuscation art; Allen's obfuscation-of-sensitive-content rule, when applied to the graph content passing through the McGrew/Microsoft LLM pipeline)
[0004] Systems, methods, and software for data obfuscation frameworks for user applications are provided herein. An exemplary method includes providing user content to a classification service configured to process the user content to classify portions of the user content as comprising sensitive content, and receiving from the classification service indications of the user content that contains the sensitive content. The method includes presenting graphical indications in a user interface to the user application that annotate the user content as containing the sensitive content, and presenting obfuscation options in the user interface for masking the sensitive content within at least a selected portion among the user content. Responsive to a user selection of at least one of the obfuscation options, the method includes replacing associated user content with obfuscated content that maintains a data scheme of the associated user content.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the data processing teachings of the prior art of record by integrating the data obfuscation before data processing teaching of Allen to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR, also see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that both Allen and the prior art of record operate in the data security domain and applying the known technique of Allen would have yielded predictable results and resulted in an improved system by addressing the well-known risk of sending sensitive data in the clear. It would have been recognized that applying the ability to obfuscate content that maintains a data scheme to the exemplary assets names, IPs, etc. of the graph structure of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such obfuscation features into similar systems, resulting in an improved system that uses all available known in the art techniques to apply privacy protection to cybersecurity graph processing. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests tenant proprietary data is obfuscated in the graph prior to inputting the graph into the LLM (reads on obfuscation options for masking sensitive content, see Allen para 0004).
Per claim 5, the prior art of record further suggests wherein an alert explanation is included in the output that summarizes the contextualized graph using the LLM (reads on the summary helps analysts understand and assess threat alerts, see McGrew para 0072, and Hassanzadeh para 0051).
Per claim 9, the prior art of record further suggests wherein contextualizing the graph of the network further comprises: compressing the graph (reads on the graph being compressed to a subgraph and further processing/contextualizing the subgraph by converting it into meaningful attack vectors, see McGrew Figure 2 blocks 210 and 220).
Per claim 10, the prior art of record further suggests wherein the processor is further configured to: ground information in context input to the LLM based on a predetermined set of Common Vulnerabilities and Exposures (CVEs) (reads on the threat intelligence knowledge base, that include the exemplary CVE, CAPEC, CWE, Maglan Plexus, iDefense API and vendor-specific databases, see Hassanzadeh para 0047 – 0049).
Claim 11 is analyzed with respect to claim 1.
Claim 12 is analyzed with respect to claim 2.
Claim 15 is analyzed with respect to claim 5.
Claim 16 is analyzed with respect to claim 1.
Claim 17 is analyzed with respect to claim 2.
Claim 20 is analyzed with respect to claim 5.
Claims 3, 4, 13, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hassanzadeh in view of McGrew in view of Microsoft in view of Allen in view of Karabey (US Pub. No. 2023/0224324 A1).
Per claims 3 – 4, the prior art of record suggests the system of claim 1 and explanations are included in the output that summarizes the contextualized graph using the LLM (read on the combination of critical assets and critical paths and provides context about which elements are more important, see Hassanzadeh para 0005, 0050, 0051 and 0064 and the summary includes attack vector information which is reasonably scoped as an attack path explanation, see McGrew Figure 2 block 230 and para 0078 – 0080). The prior art of record is silent on explicitly stating an attack path and critical path explanation.
Karabey (US Pub. No. 2023/0224324 A1) suggests
attack path and critical path explanation (reads on the output includes tactics which are high-level natural language descriptions of behaviors that a threat actor is trying to accomplish and techniques which are detailed descriptions and techniques which are detailed descriptions that represent how the threat actor achieves the tactic, see Karabey para 0022 – 0023 and Figure 1 blocks 114, 116 and 118).
[0004] A method can include receiving, at a compute device, a natural language description of activity on a computer network. The method can include executing, based on the natural language description, a natural language processing (NLP) model to provide a tactic and technique of a cyber attack associated with the natural language description. The method can further include determining, based on the provided tactic and technique, a response to mitigate the cyber attack and implementing the determined response on the computer network.
[0014] Automating the mapping in an AI/NLP driven manner reduces human effort, time to identification of the tactic and technique, and also reduces opportunity for human error. Mapping to tactic and technique in an automated manner also improves post-compromise detection of adversaries by highlighting the steps an attacker may have taken or could take next in a timely fashion. These automated, timely, and accurate mappings of incident description to tactic and technique will also help reduce enterprise risk by helping identify how an attacker got in and how are they laterally traversing the network. The automated mappings will also provide a common ground for sharing timely and accurate threat intel across organizations and reducing time to react to a cyber attack event. The reduced time to react to a cyber attack event increases the chances that the cyber attack will be mitigated and reduces the amount of damage done to a network for a given attack.
[0022] The tactic 222, 224, 226 are high-level descriptions of behaviors that a threat actor (one attempting to carry out a cyber attack) is trying to accomplish. The tactic 222, 224, 226 represents the “why” of a technique 228, 230, 232 in a same column as the tactic 222, 224, 226. For example, initial access is a tactic a threat actor will try to perform to gain access to the network 122.
[0023] Techniques 228, 230, 232 are detailed descriptions that represent how the threat actor achieves the tactic 222, 224, 226. Drive-by compromise, exploit public-facing application, external remote services, hardware additions, phishing, replication through removable media, supply chain compromise, trusted relationship, and valid accounts are all techniques 228, 230, 232 for the tactic of initial access.
[0073] Although a few embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the order shown, or sequential order, to achieve desirable results. Other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Other embodiments may, be within the scope of the following claims.
PNG
media_image3.png
674
981
media_image3.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the attack path teachings of the prior art of record by integrating the attack/critical path explanation teaching of Karabey to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR, also see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that both Karabey and the prior art of record operate in the data security domain helping analysts understand complex attack path information in cybersecurity contexts. It would have been recognized that applying the attack/critical path explanations in the form of natural language processed tactic and technique descriptions would have yielded predictable results because the prior art of record already generates attack paths and already summarizes attack vectors providing the “how” and applying the teachings of Karabey provides “what” content to include (attack/critical paths and tactics/techniques), resulting in an improved system that uses all available known in the art techniques to address analyst comprehension concerns. The motivation to combine the references is applied to all claims below this heading.
Claim 13 is analyzed with respect to claim 3.
Claim 14 is analyzed with respect to claim 4.
Claim 18 is analyzed with respect to claim 3.
Claim 19 is analyzed with respect to claim 4.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable Hassanzadeh in view of McGrew in view of Microsoft in view of Allen in view of Binyamini (US Pub. No. 2025/0315519 A1).
Per claim 8, the prior art of record suggests the system of claim 1. The prior art of record is silent on explicitly stating, wherein the graph is stored in a JavaScript Object Notation (JSON) format for input and/or output.
Binyamini (US Pub. No. 2025/0315519 A1) is relied upon to teach
the graph is stored in a JavaScript Object Notation (JSON) format for input and/or output (reads on the attack flow graph may be generated in JSON format, see Binyamini para 0050).
[0050] Upon generating the subgraph, the attack flow graph generation module 230 generates an attack flow graph based on the generated subgraph, the cyber-attack report 201 and an attack flow schema 255. The attack flow schema 255 is a structured framework or blueprint that outlines how data or information is to be organized and represented, and defines the structure and rules for valid data, including element types, attributes, and relationships. In the present implementation, the attack flow schema 255 defines the entry point on how the attack is initiated, conditions, operators, attack actions and outcomes. Based on the attack flow schema 255, properties for each of node of the graph is updated using the cyber-attack report 201 to generate the attack flow graph. For example, based on the schema, relevant properties are added to each node. The properties include, but are not limited to, unique identifier (ID) for each stage in the attack flow, purpose for referencing each stage, description explaining the process at each stage, relationship between the IDs, and tools used in the attack. Such information is added while generating the attack flow graph by referring to the attack flow schema 255 and using the generated subgraph, the cyber-attack report 201. The generated attack flow graph is stored in an attack flow graph database 260. The attack flow graph database 260 (attack flow knowledgebase) storing a plurality of attack flow graphs may be used by the experts or systems for various purpose including, but are not limited to, threat modeling incident response, vulnerability assessment, risk management, policy development, etc. In one embodiment, the attack flow graph is a structured graph and generated in JSON format. However, the attack flow graph may be generated in any other know formats.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the attack graph teachings of the prior art of record by integrating the attack graph generating format teachings of Binyamini to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR, also see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known attack graph generating format of Binyamini would have yielded predictable results and resulted in an improved system. It would have been recognized that formatting the attack graphs of the prior art of record in the well-known JSON format as taught by Binyamini would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such formatting features into similar systems, resulting in an improved system that uses all available known in the art formatting techniques to facilitate transportation of the graphs. The motivation to combine the references is applied to all claims below this heading.
Conclusion
Applicant’s amendment necessitates the new ground(s) of rejection presented in this action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is ((571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights