Prosecution Insights
Last updated: October 27, 2026
Application No. 18/911,165

ARTIFICAL INTELLIGENCE-ENABLED CYBERSECURITY THREAT ANALYSIS

Non-Final OA §103
Filed
Oct 09, 2024
Examiner
CAREY, FORREST L
Art Unit
2491
Tech Center
2400 — Computer Networks
Assignee
Disney Enterprises Inc.
OA Round
3 (Non-Final)
57%
Grant Probability
Moderate
3-4
OA Rounds
1y 7m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 57% of resolved cases
57%
Career Allowance Rate
154 granted / 272 resolved
-1.4% vs TC avg
Strong +55% interview lift
Without
With
+55.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
13 currently pending
Career history
304
Total Applications
across all art units

Statute-Specific Performance

§101
9.7%
-30.3% vs TC avg
§103
59.5%
+19.5% vs TC avg
§102
15.1%
-24.9% vs TC avg
§112
12.3%
-27.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 272 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 filed on 8/17/2026 has been entered. Status of Claims Claims 1-20 are pending. Examiner Remarks The previous Schwarzbauer reference, EP 3971751, has been replaced with the corresponding USPGPUB 2022/0156383, to simplify citation. As the USPGPUB contains the same subject matter as the former document, it is being treated in a corresponding way. Paragraph citations have been updated, below, to reflect differences in paragraph notation, and arguments directed at the former document will be fully addressed. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1-7, 10-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bu et al (PGPUB 2025/0291933), and further in view of Arbel et al (US 12,095,807) and Schwarzbauer et al (PGPUB 2022/0156383). Regarding Claims 1, 11, and 18: Bu teaches a computer-implemented method for performing automated vulnerability assessment ([abstract] method includes receiving an identifier associated with a security deficiency, wherein the security deficiency is associated with a computer system; receiving, from the generative machine learning model, a set of outputs including a first output identifying a first remediation strategy), one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform steps ([0011] system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method), and a system comprising: one or more memories storing instructions ([0011] system and/or device having non-transitory computer-readable media storing computer-executable instructions); and one or more processors for executing the instructions to perform steps ([0073] one or more central processing units (“CPUs”) 604 operate in conjunction with a chipset 606; the CPUs 604 can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computing device 600), the computer-implemented method and steps comprising: receiving a designation associated with a Common Vulnerabilities and Exposures (CVE) ([0059] as depicted in FIG. 4, at operation 402, an example system (e.g., the XDR system 104 of FIG. 4) receives the security deficiency identifier; the security deficiency identifier may be an identifier of a security deficiency (e.g., a security vulnerability and/or exposure) associated with the monitoring event; an example of a security deficiency identifier is a CVE identifier); retrieving one or more attributes describing the CVE ([0060] at operation 404, the system retrieves text data associated with the security deficiency identifier; examples text data associated with a security deficiency identifier include advisories, solutions, remediation scripts, remediation tools, product notifications, threat intelligence reports, and/or the like); aggregating, by one or more distributed data acquisition operations ([0031] XDR system 104 includes a prompt layer 112 that generates a prompt based on text data (e.g., guidance data) associated with a security deficiency identifier (e.g., CVE identifier) from one or more vulnerability databases 120 (e.g., a CVE database, an advisory database, a solution database, a guidance database, and/or the like), i.e. “distributed data acquisition”; the prompt layer 112 may receive text data from the vulnerability databases 120 and generate a text prompt for inputting to the generative machine learning model based on the text data), CVE data associated with the CVE, wherein the one or more distributed data acquisition operations electronically capture data from a plurality of networked information sources in parallel ([0031] XDR system 104 includes a prompt layer 112 that generates a prompt based on text data (e.g., guidance data) associated with a security deficiency identifier (e.g., CVE identifier) from one or more vulnerability databases 120 (e.g., a CVE database, an advisory database, a solution database, a guidance database, and/or the like), i.e. “distributed data acquisition”; the prompt layer 112 may receive text data from the vulnerability databases 120 and generate a text prompt for inputting to the generative machine learning model based on the text data; EXAMINER’S NOTE: retrieving data from multiple databases can be seen as “electronically captur[ing] data from a plurality of networked information sources in parallel; [0060] the system retrieves text data associated with the security deficiency identifier; examples text data associated with a security deficiency identifier include advisories, solutions, remediation scripts, remediation tools, product notifications, threat intelligence reports, and/or the like; such text data may provide additional details about a security deficiency, such as a description of the deficiency, the potential impact of the security deficiency, the systems, components, products, and/or software versions affected by the security deficiency, severity ratings associated with the deficiency, mitigating solutions (e.g., software patch deployments) for containing the effects of the security deficiency, remediation strategies (e.g., remediation scripts and/or tools, such as executable files, scripts, utilities, and/or patches) for eliminating the effect of the deficiency (e.g., to fix the deficiency), and/or the like); generating a prompt data structure based on the designation, the one or more attributes, and the CVE data ([0061] the system determines a text prompt based on the text data; the text prompt may include at least a portion of the retrieved text data, an instruction segment that describes that the generative machine learning model should perform a remediation strategy detection task (e.g., a software patch deployment detection task), and one or more output constraints for the output of the machine learning model; the output constraints may specify a required structure, format, and/or content associated with the output texts generated based on the text prompt); transmitting the prompt data structure to a second machine learning model that generates a vulnerability assessment associated with the CVE based on the prompt data structure ([0062]-[0063] the system provides the text prompt to a generative machine learning model; the system receives, in response to the text prompt, a generative output text from the generative machine learning model; the generative output text may be the output of processing the text prompt by the generative machine learning model; the generative output text may describe a remediation strategy (e.g., a software patch deployment) described by the text prompt); generating one or more CVE reports based on the vulnerability assessment ([0066], [0069] if the system determines that the generative output satisfies the output constraint satisfies an output constraint associated with the text prompt (operation 412—Yes), the system proceeds to operation 416 to determine a remediation strategy based on the text data; in some cases, the system provides the text prompt to the generative machine learning model N times to generate N output texts, the system proceeds to operation 416 if any of the N output texts satisfy the output constraint(s); the system may, for example, determine the remediation strategy by combining (e.g., aggregating, performing a voting-based selection based on, and/or the like) the subset of the N output texts satisfy the output constraint(s); the system identifies the output text having the highest score and displays the remediation strategy described by that output text; the system may designate the remediation strategy described by the top-scored output text as the most recommended remediation strategy); and performing an automated remediation action based on the one or more CVE reports ([0049] in some cases, in addition to providing the remediation strategy to the user system 122, the remediation layer 118 may automatically execute operations corresponding to the remediation strategy; for example, the remediation layer 118 may automatically install a software patch, rewrite code data associated with a software, and/or upgrade a software to a latest and/or a secure version). Bu does not explicitly teach generating, via a first machine learning model, a first prompt data structure. However, Arbel teaches the concept of generating, via a first machine learning model, a first prompt data structure ([col 7 line 19-25] the generative remediator 128 is configured to generate a prompt for an LLM; in some embodiments, the prompt is generated based on a representation schema of the security database 126, a finding (e.g., a result of a cybersecurity inspection, such as detection of a cybersecurity object), a predefined action, a combination thereof, and the like; [col 9 line 48-51] the finding 330 is a security finding, a lateral movement finding, a CVE finding…; [col 12 line 15-23] the generative remediator is configured to generate a prompt for a large language model (LLM), configured to generate a remediation action; in some embodiments, a first LLM is utilized to generate the prompt, and a second LLM is utilized to generate the remediation action). 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 prompt-generating machine learning model teachings of Arbel with the automated vulnerability assessment teachings of Bu; the successful output of a large language model frequently depends on the level of description provided in the guiding prompt. Using a first LLM to develop an accurate and detailed prompt can improve efficiency and reliability by controlling the format and necessary information provided in the prompt and avoiding user error due to misinterpretation, forgetting details, misspelling, etc. Neither Bu nor Arbel explicitly teaches determining whether a plurality of stored prior CVE reports includes a prior CVE report associated with the CVE, wherein each of the plurality of stored prior CVE reports was generated from a vulnerability assessment of a previously analyzed CVE; based on a determination that the plurality of stored prior CVE reports does not include a prior CVE report associated with the CVE: [performing steps]; identifying, based on organizational data, one or more computer products that are both designated as having a particular importance or impact to an organization and identified in the vulnerability assessment as potentially being affected by the CVE; generating one or more CVE reports based on the vulnerability assessment, wherein at least one of the one or more CVE reports identifies the one or more computer products. However, Schwarzbauer teaches the concept of determining whether a plurality of stored prior CVE reports does not include a prior CVE report associated with a CVE, wherein each of the plurality of stored prior CVE reports was generated from a vulnerability assessment of a previously analyzed CVE ([abstract] technology is disclosed to perform real-time and online identification and prioritization of vulnerabilities of components of software applications; [0204] FIG. 8a described the process of updating the unified vulnerability repository 157 with new and updated vulnerability report data from external, public vulnerability databases; various public vulnerability databases are available for public usage, most of them also providing APIs to access and query structured vulnerability report data; example vulnerability data bases include the Common Vulnerability and Exposures database (CVE), managed by the MITRE corporation; [0205] the process starts with step 800, when an update for the unified vulnerability repository 147 is desired; [0206] following step 801 fetches vulnerability data from external vulnerability databases, e.g., using APIs provided by those databases; step 801 may either fetch vulnerability data from one or multiple public vulnerability databases 150; further, step 801 may either fetch all vulnerability data that is available on a vulnerability database or may it only fetch these vulnerability data or vulnerability reports that were created or updated since the last update (EXAMINER’S NOTE: Schwarzbauer distinguishes between vulnerability data and reports); [0207] afterwards, step 802 may analyze the fetched vulnerability data and create a new vulnerability report 148 for each unknown vulnerability in imported vulnerability data (EXAMINER’S NOTE: new report for each unknown vulnerability, i.e. no previously existing report); imported vulnerability data is typically structured in individual vulnerability reports, similar to vulnerability reports described in FIG. 7a; in most cases, such imported reports also contain an identifier, which uniquely identifies a vulnerability report within the scope of a public vulnerability database); based on a determination that the plurality of stored prior CVE reports does not include a prior CVE report associated with a CVE: [performing steps] ([0217] step 802 may analyze the fetched vulnerability data and create a new vulnerability report 148 for each unknown vulnerability in imported vulnerability data); identifying, based on organizational data, one or more computer products that are both designated as having a particular importance or impact to an organization and identified in the vulnerability assessment as potentially being affected by the CVE ([0243] FIG. 10a provides the flow chart of a process that analyzes library loading evidence data 240 provided by in-process agents 110 or OS agents 114 to identify entities of a monitored environment that are affected by known vulnerabilities; [0245] following step 1001 analyze data of a currently processed library loading evidence data record 240 to determine library identification data, e.g., consisting of a vendor name, a product name, and a version; library identity evidence entries 247 stored in library the library identity evidence data set 245 of the currently processed library loading evidence data record 240 may be used to determine the library identification data; [0246] subsequent step 1002 queries the unified vulnerability repository 147 for vulnerability reports 148 containing a library entry 706 in their affected library list 705 that matches the library identification data determined in step 1001; [0260] following step 1023 may then analyze existence, number, and frequency of observed calls to a vulnerable API of the currently processed library to calculate an API usage priority score 744; in general, a higher number and higher frequency of observed vulnerable API calls may lead to a higher API usage priority score; [0262] step 1024 may then analyze the topological connections of the entity on which the vulnerability was observed to external entities and to entities storing sensitive data to determine a topology exposure priority score 745; EXAMINER’S NOTE: determination of priority scores for individual products/libraries can be seen as designating the importance or impact of a product/library to an organization; [0302] following step 1301 fetches all currently open vulnerability issues 159, subsequent step 1302 may then calculate a combined vulnerability score for the fetched vulnerability issues; afterwards, step 1303 may be executed which sorts the vulnerability issues 159 by the combined vulnerability score; step 1304 may then present the priority sorted vulnerabilities to a user of the monitoring system); generating one or more CVE reports based on the vulnerability assessment, wherein at least one of the one or more CVE reports identifies the one or more computer products ([0334] coming now to FIG. 15 which provides a screenshot of an exemplary user interface that may be used to present the details of a selected identified vulnerability; [0339] a vulnerable libraries section 1505 may list the vulnerable libraries that were loaded by the affected entity, e.g., by vendor name, product name and version; [0340] further an affected entity section 1507 may identify those topology entities that are most affected by the selected vulnerability; the here displayed affected entity section e.g., lists 24 services that are provided by processes (represented as the 3 vulnerable process groups mentioned in the affected entities detail section 1503) running on 3 host computing systems). 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 creation of a new prioritized vulnerability report teachings of Schwarzbauer with the automated vulnerability assessment teachings of Bu in view of Arbel, with the benefit of improving efficiency and accuracy, saving storage space, and reducing waste, overhead, and processing time by limiting creation of new vulnerability reports to vulnerabilities for which a report does not already exist, thereby avoiding redundancy, and providing the benefits listed above, as well as to rank vulnerabilities according to a priority score, allowing time and resources to be directed at the most critical vulnerabilities of a monitored organization. Regarding Claims 2 and 12: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Bu teaches wherein the one or more attributes describing the CVE include at least one of a vendor name, a product name, a vulnerability name, or a textual description associated with the CVE ([0025] a CVE entry may include a description of a security vulnerability or exposure, vendors affected by the vulnerability or exposure, the type and/or category of the vulnerability or exposure (e.g., a common weakness enumeration (CWE) for the vulnerability or exposure), the severity of the vulnerability or exposure, and/or the like). Regarding Claims 3 and 13: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Arbel teaches wherein the one or more attributes describing the CVE include at least one of a Common Vulnerability Scoring System (CVSS) score, one or more CVSS factors, one or more known attack vectors, or one or more privileges required to exploit the CVE (col 11 line 32-40, a finding is a security finding, a lateral movement finding, a privilege escalation finding, a vulnerability, an exposure, a misconfiguration, a malware, an attack path, various combinations thereof, and the like). The rationale to combine Bu and Arbel is the same as provided for claims 1 and 11 due to the overlapping subject matter between claims 1 and 3, 11 and 13. Regarding Claims 4 and 14: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Bu teaches wherein the second machine learning models include a large language model (LLM) ([0039] generative machine learning model, such as a large language model); and Arbel teaches wherein each of the first and second machine learning models include a large language model (LLM) ([col 12 line 15-23] the generative remediator is configured to generate a prompt for a large language model (LLM), configured to generate a remediation action; in some embodiments, a first LLM is utilized to generate the prompt, and a second LLM is utilized to generate the remediation action). The rationale to combine Bu and Arbel is the same as provided for claims 1 and 11 due to the overlapping subject matter between claims 1 and 4, 11 and 14. Regarding Claims 5 and 15: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Arbel teaches the method further comprising retrieving one or more items of organizational data associated with an enterprise computing environment, wherein the organizational data includes a list of one or more software applications or computer products included in the enterprise computing environment ([col 10 line 54-col 11 line 3] a computing environment is inspected for a cybersecurity object; in an embodiment, inspecting a computing environment for a cybersecurity object includes detecting a plurality of resources deployed in a computing environment; entity discovery includes querying an application programming interface (API) of a computing environment, such as a cloud computing environment, to determine what resources, workloads, and the like, are deployed therein; according to an embodiment, a cloud API is accessed to determine what virtual machines, software containers, serverless functions, microservices, buckets, storage, software repositories, and the like, are deployed in the computing environment). The rationale to combine Bu and Arbel is the same as provided for claims 1 and 11 due to the overlapping subject matter between claims 1 and 5, 11 and 15. Regarding Claims 6 and 16: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Bu teaches wherein the automated remediation action includes one or more of initiating an automated vulnerability scan of one or more computing devices included in an enterprise computing environment, automatically isolating or blocking one or more computing devices or software applications, automatically applying software patches to one or more computing devices or software applications ([0049] the remediation layer 118 may automatically install a software patch), automatically reverting one or more computing devices or software applications to an earlier software version, or automatically transmitting an alert to one or more members of a software security team. Regarding Claims 7 and 17: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the one or more non-transitory computer-readable media of claim 11. In addition, Bu teaches the method, further comprising: receiving one or more additional designations associated with one or more additional CVEs ([0025] event mapping layer 110 may be configured to retrieve monitoring event(s) from the event repository 108 and map the retrieved monitoring event(s) to security deficiency identifier(s) (EXAMINER’S NOTE: plural identifiers); for example, the event mapping layer 110 may be configured to retrieve a monitoring event stored on the event repository 108, determine a security deficiency (e.g., security vulnerability and/or exposure) associated with the retrieved event, and map the security deficiency to a deficiency identifier; an example of a security deficiency identifier is an identifier associated with a security deficiency library, such as a Common Vulnerabilities and Exposures (CVE) identifier); and generating one or more CVE reports based on at least the designation and the one or more additional designations ([0066], [0069] as above; EXAMINER’S NOTE: the BRI of claim 7 would apply to a singular method executed several times at varying intervals). Regarding Claim 10: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1. In addition, Bu teaches the method, further comprising: determining that a database of previously generated CVE reports includes one or more previously generated CVE reports associated with the CVE ([0013] system may perform the following operations: (i) identifying a deficiency identifier (e.g., a Common Vulnerabilities and Exposures (CVE) identifier) associated with the security deficiency, (ii) retrieving one or more texts (e.g., advisories, solutions, remediation scripts, remediation tools, product notifications, threat intelligence reports, and/or the like.) that correspond to the deficiency identifier (e.g., by querying one or more databases such as a CVE database)); retrieving the one or more previously generated CVE reports ([0013] retrieving one or more texts (e.g., advisories, solutions, remediation scripts, remediation tools, product notifications, threat intelligence reports, and/or the like.) that correspond to the deficiency identifier (e.g., by querying one or more databases such as a CVE database)); and generating one or more CVE reports based on the previously generated CVE reports ([0066], [0069] if the system determines that the generative output satisfies the output constraint satisfies an output constraint associated with the text prompt (operation 412—Yes), the system proceeds to operation 416 to determine a remediation strategy based on the text data; in some cases, the system provides the text prompt to the generative machine learning model N times to generate N output texts, the system proceeds to operation 416 if any of the N output texts satisfy the output constraint(s); the system may, for example, determine the remediation strategy by combining (e.g., aggregating, performing a voting-based selection based on, and/or the like) the subset of the N output texts satisfy the output constraint(s); the system identifies the output text having the highest score and displays the remediation strategy described by that output text; the system may designate the remediation strategy described by the top-scored output text as the most recommended remediation strategy). Claim(s) 8, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bu in view of Arbel and Schwarzbauer, and further in view of McGee et al (WO 2016/210236). Regarding Claims 8 and 19: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the system of claim 18. Neither Bu nor Arbel nor Schwarzbauer explicitly teaches the method, further comprising selecting a subset of the aggregated CVE data based on a list of preferred information sources or a list of non-preferred information sources. However, McGee teaches the concept of selecting a subset of aggregated CVE data based on a list of preferred information sources or a list of non-preferred information sources ([page 8 line 15-page 9 line 26] controller 112 searches database 114 to identify pertinent entries describing a relevant security vulnerability for the class; there may be hundreds of thousands, or even millions of entries within database 114 describing a variety of product lines and security vulnerabilities; controller 112 may therefore scan through the entries of database 114 in search of entries that match keywords for the class and a relevant security vulnerability; entries that describe the relevant security vulnerability may be identified based on any suitable correlating information within one or more of their fields, such as CVE ID; controller 112 identifies an authoritative entry in database 114 (e.g., an entry that describes a test performed upon the class(es) for detecting the relevant security vulnerability such as an entry describing the results of a test performed by a test group); the authoritative entry may for example be flagged at the database as being received from a trusted/authoritative source, or may be flagged as an authoritative source based on user preferences, credentials and/or access privileges). 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 preferred information source teachings of McGee with the automated vulnerability assessment teachings of Bu in view of Arbel and Schwarzbauer, in order to improve accuracy and reliability of the final report by avoiding unreliable sources of information through the use of known, preferred authoritative sources. Claim(s) 9, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bu in view of Arbel and Schwarzbauer, and further in view of Cameron et al (PGPUB 2025/0036777). Regarding Claims 9 and 20: Bu in view of Arbel and Schwarzbauer teaches the computer-implemented method of claim 1 and the system of claim 18. Neither Bu nor Arbel nor Schwarzbauer explicitly teaches the method, further comprising summarizing the aggregated CVE data based at least on a predetermined token limit associated with the second machine learning model. However, Cameron teaches the concept of summarizing aggregated CVE data based at least on a predetermined token limit associated with a machine learning model ([0023] a large language model (LLM) is used to generate an exploit for one or more vulnerabilities, for example based on information obtained from one or more third-party security entities, such as common vulnerabilities and exposures (CVE) data; [0039] components used to determine platform-specific end-to-end security vulnerabilities and a graphical layout for displaying the platform-specific end-to-end security vulnerabilities via a Graphical User Interface (GUI); in various implementations, system 100 can provide a software security label 106; the software security label 106 can display information in a graphical layout that is related to end-to-end software security of a platform-specific software application; [0080] current AI technology may not be sufficient to create an attack without breaking the task down into smaller pieces; LLMs typically have a maximum token limit, which can restrict the length of generated output; the token limit can vary depending upon the specific LLM, available resources, configuration settings, etc.; [0119] the system can use the identified exploitation paths to attempt to carry out the synthesized exploit against the identified exposed systems; the system can, at act 640, log the results of the exploit attempts; the logs can indicate, for example, parameters that were used during an attempt, whether or not an attempt was successful, the time taken to carry out an exploit, and/or other information relevant to the exploit; at act 645, the system can update a data store based on the log results; as described herein, the log results can be used as part of a RAG step when synthesizing exploits, identifying exploitation paths, etc.; at act 650, the system can generate a security label that can be displayed to a user; the security label can include information indicative of the results of executing the synthesized exploit); and Arbel teaches wherein the machine learning model is a second machine learning model ([col 12 line 15-23] first LLM and second LLM). 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 token limit teachings of Cameron with the automated vulnerability assessment teachings of Bu in view of Arbel and Schwarzbauer; LLMs typically use a token limit to keep the input prompts from exceeding various model limitations, such as compute time, energy use, and memory capacity. A person of ordinary skill in the art, when using LLMs, would therefore consider ways in which to account for the token limit during use, such as dividing the task into multiple tasks which come in under the limit, thereby permitting the completion of complicated prompts without the need for upgrading the model, purchasing expensive memory, monopolizing compute time, etc. The rationale to combine Bu and Arbel is the same as provided for claims 1 and 18 due to the overlapping subject matter between claims 1 and 9, 18 and 20. Response to Arguments Applicant's arguments filed 8/17/2026 have been fully considered but they are not persuasive. Regarding the rejection of claims under 35 USC 103: Examiner’s response to applicant’s arguments, page 10 paragraph 2: Examiner disagrees. Schwarzbauer distinguishes between vulnerability data and vulnerability reports (e.g. PGPUB, [0206]). A CVE vulnerability report can be seen as a report of a vulnerability assessment performed over vulnerability data, regardless of whether it was performed by the system of Schwarzbauer or the entity which provided the vulnerability report to the CVE database. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “previously generated from machine-learning vulnerability assessments”, “the claimed system’s previously generated assessment reports”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims recite determination whether a plurality of stored prior CVE reports includes a prior CVE report associated with the CVE, wherein each of the plurality of stored prior CVE reports was generated from a vulnerability assessment of a previously analyzed CVE. Note that there is no recitation of a location of storage (which could thus be the CVE database), generation via a machine-learning model, nor the originator of the vulnerability assessment. Therefore, Schwarzbauer, which explicitly recites generating “new” vulnerability reports for “unknown” vulnerabilities in imported vulnerability data (e.g. [0217]) can be seen as making a determination whether a prior CVE report exists and generating a new report as a result. Examiner’s response to applicant’s arguments, page 10 paragraph 3: Examiner disagrees. Upon further consideration, the system of Schwarzbauer does teach determining the importance/impact of particular software libraries/products/components. Schwarzbauer teaches building a list of libraries and entities currently in use in a monitored environment (e.g. [0243], [0245]), cross referencing the list with vulnerabilities (e.g. [0246]), and then evaluating the libraries and entities subject to the determined vulnerabilities to determine e.g. frequency of use, exposure to external entities, and storage of sensitive data, to determine a priority score (i.e. measure of impact or importance) (e.g. [0260], [0262], [0302]). A report is then generated listing the vulnerabilities and the affected libraries/entities (e.g. [0334], [0339], [0340]). Therefore, Schwarzbaur does teach “identifying, based on organizational data, one or more computer products that are both designated as having a particular importance or impact to an organization and identified in the vulnerability assessment as potentially being affected by the CVE” and “generating one or more CVE reports based on the vulnerability assessment, wherein at least one of the one or more CVE reports identifies the one or more computer products”. Applicant’s arguments with regard to independent claims 11 and 18 are similar to those regarding claim 1 and are therefore responded to in a similar way. Applicant further argues that the dependent claims are allowable due to depending on an allowable independent claim. However, as shown above, the independent claims are not allowable. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F. 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, William Korzuch can be reached at (571) 272-7589. 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. /FORREST L CAREY/Examiner, Art Unit 2491 /WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

Oct 09, 2024
Application Filed
Dec 30, 2025
Non-Final Rejection mailed — §103
Mar 26, 2026
Response Filed
Jun 18, 2026
Final Rejection mailed — §103
Aug 17, 2026
Response after Non-Final Action
Sep 09, 2026
Request for Continued Examination
Sep 15, 2026
Response after Non-Final Action
Oct 02, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12762254
DETECTION OF OVER-PRIVILEGED ACCESS PERMISSIONS
5y 4m to grant Granted Oct 13, 2026
Patent 12711250
INFORMATION PROCESSING SYSTEM, INFORMATION PROCESSING APPARATUS, METHOD OF CONTROLLING THE SAME, AND STORAGE MEDIUM
3y 7m to grant Granted Aug 18, 2026
Patent 12696083
Securing Media Stream Communications
4y 5m to grant Granted Jul 28, 2026
Patent 12683928
Hybrid web application firewall
4y 1m to grant Granted Jul 14, 2026
Patent 12647791
METHOD AND DEVICE FOR AUTHENTICATING A PRIMARY STATION
3y 4m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
57%
Grant Probability
99%
With Interview (+55.3%)
3y 8m (~1y 7m remaining)
Median Time to Grant
High
PTA Risk
Based on 272 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month