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 3/2/2026 has been entered.
Information Disclosure Statement
The 7/28/2025 and 6/22/2026 IDS documents have been considered by the examiner.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 101:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that the argued claim “features are not merely results-oriented but identify a particular and concrete technical solution to a known problem in cybersecurity operations: the inefficient and often inaccurate reconciliation of overlapping vulnerability data across disparate Application Security tools. The recited use of hash functions for deduplication and the merging of records based on predicted risks generated from historical analysis constitutes an integrated technical improvement to the functioning of a computer system, namely in how it manages, deduplicates, and correlates complex security datasets across multiple domains.” Applicant further argues that “the claim does not simply "apply machine learning models or statistical methods." Instead, the claim ties those models to specific operations: namely, generating predicted risks from historical data, and using those predicted risks to guide the merging of overlapping security vulnerability records. This interaction between a predictive model and a deduplication module introduces a technical improvement not found in the prior art nor reducible to a mental process.” In response, it is first noted that the broadest reasonable interpretation for the claim at its level of generality is that of a mental process with using a machine learning model as a form of adding the words “apply it” to the judicial exception. The limitation of “apply machine learning models” is a statement of purpose of using machine learning to achieve a result. It does not specify any particular neural network arrangement, training algorithm, or other such example technical details concerning machine learning. Additionally, “apply” need not be interpreted as feeding inputs into a machine learning model to obtain an output prediction.
It is also noted that the machine learning model limitation recites “apply machine learning models or statistical methods to predict potential security risks and trends.” As such, the broadest reasonable interpretation need not even consider merely using the machine learning model as a tool to perform the abstract idea. The predicted potential security risks can be obtained entirely using “statistical methods,” which would fall under the interpretation of a mental process (e.g., an analyst using statistics formulas).
Applicant further argues that “Examiner's statement that the claims "do not specify any particular machine or algorithms" overlooks that hash functions and risk-based merging inherently require algorithmic implementation and cannot be performed mentally or manually in any practical sense.” In response, it is noted that inherent algorithmic implementation also follows in the case of merely adding the words “apply it” such as in the trivial case of “do it on a computer.” According to MPEP 2106.05(f), this is not sufficient for integration into a practical application. As discussed above, the claim language concerns steps performed at a level of generality where the claim steps may reasonably be interpreted as being drawn to mental processes.
Applicant additionally points to [0022]-[0025], [0045]-[0047], [0050], [0055], and [0089] of the instant specification concerning the algorithmic details of the instant application. MPEP 2106.04(a)(2) states that “[i]n evaluating whether a claim that requires a computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. For instance, examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process.” In Symantec Corp., 838 F.3d at 1316-18, 120 USPQ2d at 1360, the Federal Circuit relied upon the specification when explaining that the claimed electronic post office, which recited limitations describing how the system would receive, screen and distribute email on a computer network, was analogous to how a person decides whether to read or dispose of a particular piece of mail and that “with the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.” In FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed. Cir. 2016), a system and method of detecting fraud and/or misuse in a computer environment, in which information regarding accesses of a patient’s personal health information was analyzed according to one of several rules (i.e., related to accesses in excess of a specific volume, accesses during a pre-determined time interval, or accesses by a specific user) to determine if the activity indicates improper access. 839 F.3d. at 1092, 120 USPQ2d at 1294. The court determined that these claims were directed to a mental process of detecting misuse, and that the claimed rules here were “the same questions (though perhaps phrased with different words) that humans in analogous situations detecting fraud have asked for decades, if not centuries.” 839 F.3d. at 1094-95, 120 USPQ2d at 1296. In the instant case, the claim limitations are likewise drawn to steps performable by a human: i.e., aggregating and collating data, applying models to calculate an output value, merging records, communicating information, and basic access control.
Where Applicant argues that the claim “represents a clear technological improvement over conventional, manual, and fragmented security workflows,” it is noted that the argued improvement likewise applies to actions performed by a human analyst and is addressing a problem that transcends computing (i.e., normalizing, analyzing, and summarizing security information).
Regarding claims rejected under 35 USC 103:
Applicant’s arguments against the Huffsmith-Levin combination have been considered but are moot because the new ground of rejection, in view of Shakarian (US 2022/0078203 A1), does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding claims rejected under 35 USC 112(a):
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that the specification has support for the claim limitations reciting “wherein the predicted risks are used to refine identification of overlapping vulnerability records” and “merging of records is performed based on predicted risks generated by the historical data analysis module.” Applicant points to [0045], [0046], [0051], and [0089] of the specification, and writes that these “disclosures clearly support an architecture in which machine learning-derived risk predictions are computed and used in subsequent system operations on vulnerability records. A person of ordinary skill in the art would understand that, in such a system, merging overlapping records based on their associated risk scores (e.g., keeping the higher-risk version, flagging urgent items, or collapsing lower-risk duplicates) is a natural, explicit consequence of the architecture as a whole. The claimed functionality, wherein merging of overlapping vulnerability records is guided by predicted potential security risks, is fully supported by the disclosure's integrated treatment of predictive analytics and deduplication processes, as illustrated in the cited paragraphs. There is no requirement for the specification to repeat the precise claim language. Instead, it is sufficient that the concept is "clearly present to a person of skill in the art," which it unquestionably is in this case.”
In response, it is noted that [0062]-[0064] and [0089] are the only portions of the instant specification which discuss performing the deduplication, and none of them addresses merging the records “wherein the predicted risks are used to refine identification of overlapping vulnerability records” and “merging of records is performed based on predicted risks generated by the historical data analysis module.” Instead, [0089] states that “Deduplicate Vulnerabilities 442 might employ hash functions to eliminate redundancy in vulnerability records,” but this merely concerns using the hash functions rather than predicted risks. It does not specify hashing the predicted risks.
While [0089] does state that “Forecasting Analysis 446 may employ machine learning algorithms to statistically model future security risks based on historical data,” this is not tied to the deduplication process.
Although Applicant appears to be arguing that the vulnerability records are associated with the predicted risks, and that the system as a whole concerns vulnerability records and predicted risks generated by the machine learning algorithms, there is no actual statement describing the deduplication being “wherein the predicted risks are used to refine identification of overlapping vulnerability records” and “merging of records is performed based on predicted risks generated by the historical data analysis module.” At best, it can be said that the deduplication concerns records that have an association with the predicted risks. However, this is not considered to be sufficient support.
Regarding claim interpretation under 35 USC 112(f):
Applicant’s arguments concerning “a deduplication module” are considered to be persuasive. Applicant's arguments concerning the remaining argued modules have been fully considered but they are not persuasive.
Applicant argues that “modules are not mere black boxes defined only by function. Rather, as evidenced throughout the specification, each module is described with specific roles, operations, and interconnections within a broader system architecture.” For a term to be considered a substitute for “means,” and lack sufficient structure for performing the function, it must serve as a generic placeholder and thus not limit the scope of the claim to any specific manner or structure for performing the claimed function. It is important to remember that there are no absolutes in the determination of terms used as a substitute for “means” that serve as generic placeholders. The examiner must carefully consider the term in light of the specification and the commonly accepted meaning in the technological art. Every application will turn on its own facts.
In this case, the “data aggregation module” is a module that aggregates data, where the claim merely specifies the data aggregated rather than the algorithm of doing so by the module. As such, it has been interpreted under 35 USC 112(f). Likewise, the “historical data analysis module” is a module that merely analyzes collected data with no particular algorithm beyond general assertions of the data being analyzed a desired outcome. The “integration module” is merely described as being configured to perform a desired outcome rather than performing any particular algorithm. The “role-based access system module” is likewise interpreted.
In contrast, the deduplication module is described as performing a particular algorithm. It limits the scope of the claim to a specific manner or structure for performing the claimed function.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “data aggregation module,” “historic data analysis module,” “integration module,” “role-based access system module,” and “visualization module” in claims 1-7.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For instance, FIG. 2 and [0035] of the instant specification concerning system 200, its modules, and functionality (e.g., [0038], [0062], [0043], [0045], [0051], and [0054] of the specification).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 8 is objected to because of the following informalities: it recites “identifying overlapping… and sources, ;” which appears to be a typographical error leaving both a comma and semicolon together. Appropriate correction is required.
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 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. Each of independent claims 1, 8, and 15 recite “wherein the predicted risks are used to refine identification of overlapping vulnerability records” and “merging of records is performed based on predicted risks generated by the historical data analysis module,” which is considered to be new matter. With respect to deduplication, the instant specification states that “[d]ata collection can be initiated… data can then be analyzed for deduplication and impact fine-tuning, after which forecasting analysis can be run” in [0063] and that “Deduplicate Vulnerabilities 442 might employ hash functions to eliminate redundancy in vulnerability records” in [0089].
With respect to identification of overlapping vulnerability records, the instant specification discloses that “Security Detection Tool 322 could perform tasks such as analyzing security data from multiple sources, identifying overlaps or discrepancies in assessments, and providing a unified view of the security landscape” in [0072]. In [0089], the instant specification states that “Deduplicate Vulnerabilities 442 might employ hash functions to eliminate redundancy in vulnerability records.” Likewise, [0062] of the instant specification concerns “automat[ing] the collection and deduplication of data from various Application Security tools, thus reducing redundancy and human error, a shortcoming in previous technologies.”
The instant specification does not disclose using predicted risks to refine identification of overlapping vulnerability records.
The dependent claims do not rectify the identified deficiencies, and are likewise rejected with their respective parent claims.
Dependent claim 3 further recites “merging the identified overlapping vulnerability records into a single vulnerability record based on a predicted risk score associated with each vulnerability record,” which is considered to be new matter because the instant specification does not describe merging vulnerability records based on a predicted risk score associated with each vulnerability record. As with its parent independent claim above, claim 3 further 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 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 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because they are drawn to a “computer-readable medium” which may be interpreted as a signal per se. A signal per se is not considered to be patent eligible subject matter.
The instant specification does not limit “computer-readable” medium against being interpreted as a signal per se. To point, [0103] of the instant specification merely discusses examples of computer-readable mediums without a specific definition.
The dependent claims do not rectify this deficiency and are therefore likewise rejected.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Note that the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation (refer to MPEP 2106.04(a)(2)).
Example independent claim 8 recites the following abstract idea limitations: A method for automated management and evaluation of microservice security in a software development environment, comprising: receiving security data from multiple Application Security tools (obtaining information as part of a mental process—e.g., an analyst obtaining written information via pen and paper; the application security tools are not positively recited as transmitting the information), including base image analysis, source code analysis, third-party dependencies analysis, and API security analysis (merely further specifying the subject matter of the received information—e.g., what information is written; performing the analyses is not positively recited); transforming the received security data into a standardized format (transcribing information as part of a mental process—e.g., the analyst rewriting information from one format into another based on pre-existing instructions); analyzing transformed security data based on collected historical security data by applying machine learning models or statistical methods to predict potential security risks and trends, wherein the predicted risks are used to refine identification of overlapping vulnerability records (evaluation and following an algorithm as part of a mental process—e.g., the analyst obtaining different information and feeding it through a pre-existing statistical method to obtain an output); identifying overlapping vulnerability records based on vulnerability names, severity levels, and sources (observation and evaluation as part of a mental process—e.g., the analyst looking for doubles of certain information); merging identified overlapping vulnerability records into a single vulnerability record (transcribing information as part of a mental process—e.g., the analyst rewriting a more concise record) wherein the identifying employs one or more hash functions to eliminate redundancy in vulnerability records (evaluation as part of a mental process—e.g., the analyst performs a checksum calculation or comparison), and merging of records is performed based on the predicted potential security risks (evaluation as part of a mental process—e.g., the analyst merges records according to reviewing certain information); updating an internal database with the merged vulnerability record (recording information as part of a mental process—e.g., the analyst recording and storing the concise record in a file cabinet in lieu of storing multiples of the same information); generating visual representations summarizing microservice security history, vulnerabilities, risk scores, and forecasted trends (charting information as part of a mental process—e.g., the analyst arranging a written report summarizing their analysis).
With respect to step 2A, this judicial exception is not integrated into a practical application because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the claim generally concerns obtaining and aggregating different security data, normalization, analysis (e.g., via models and/or statistical methods), and outputting a visual report. This is performable as a mental process by a human analyst, and the claim does not recite any particular machine for performing the mental process (i.e., beyond a generic computerization). The claimed invention is drawn to a problem which is not rooted in computers because it concerns improvements to normalizing, analyzing, and summarizing security information as discussed above. As such, it is addressing a problem that transcends computing. Since the claimed invention is not rooted in computers, it therefore does not improve the functioning of a computer or any other technology or technical field so as to integrate the judicial exception into a practical application.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the claim merely recites “automated management and evaluation” which is performable by any base level computer (e.g., processor, memory, and instructions).
Independent claim 15 is substantially similar to independent claim 8 above, but further recites a “computer-readable medium comprising instructions… executed by a processor” to perform its steps. With respect to steps 2A and 2B, adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, a processor, memory, and instructions are base level components of any computer for performing the abstract idea. As such, claim 15 is rejected under the same analysis as claim 8 above.
Dependent claim 9 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising extracting key information from the received security data, including vulnerability names, components, severity levels, sources, and descriptions, during the transformation into a standardized format (transcribing information as part of a mental process—e.g., the analyst rewriting specific fields of information from one format into another based on pre-existing instructions).
Dependent claim 10 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising utilizing the collected historical security data to generate risk scores, trend reports, and predictive models for potential security risks and trends (evaluation and judgement as part of a mental process—e.g., the analyst evaluating the historical security data and (i) judging whether it indicates a low or high risk, (ii) judging whether the historical security data has any trends or is indicative of any trends, and (iii) judging which models to choose, or which model parameters to change; the generation is recited at a very high level of generality).
Dependent claim 11 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising establishing connections with existing development tools, retrieving relevant information (sending and receiving information as part of certain methods of organizing human activity—e.g., the analyst communicating with a development team), and enriching the security data by incorporating contextual insights (modifying information as part of a mental process—e.g., the analyst annotating or otherwise modifying received information based on their contextual knowledge).
Dependent claim 12 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising controlling access to the security data and the multiple Application Security tools based on predefined user roles and responsibilities (controlling access as part of certain methods of organizing human activity—e.g., the analyst’s organization only allowing senior analysts to access sensitive certain data).
Dependent claim 13 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising generating visual representations, including graphs, charts, and reports, summarizing the microservice security history, vulnerabilities, risk scores, and forecasted trends (charting information as part of a mental process—e.g., the analyst arranging a written report summarizing their analysis).
Dependent claim 14 merely further recites the abstract idea, and is therefore likewise rejected under the same analysis. Specifically, it recites the following abstract idea limitation: further comprising providing the generated visual representations, risk scores, and trend reports to one or more users for risk management (sharing information as part of certain methods of organizing human activity—e.g., the analyst providing their written report to their organization to act on its findings).
Dependent claims 16-20 are substantially similar to claims 9-13 above, and are therefore likewise rejected.
Independent claim 1 recites the following abstract idea limitations which are substantially similar to those addressed in the rejections of claims 8-20 above (e.g., independent claim 8; dependent claims 11-12).
Independent claim 1 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the judicial exception: “a data aggregation module operatively coupled to” receive the security data; “a deduplication module operatively coupled to the data aggregation module, configured to” perform the deduplication; “a historical data analysis module operatively coupled to the data aggregation module, configured to” analyze the collected historical security data and generate risk scores and trend reports; “an integration module operatively coupled to existing development tools, configured to” establish connections, retrieve relevant information, and enrich security data; and “a role-based access system module configured to” control access.
With respect to step 2A, this judicial exception is not integrated into a practical application because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the claim generally concerns obtaining and aggregating different security data, normalization, analysis (e.g., via models and/or statistical methods) and reporting, annotation, and access control. This is performable as a mental process by a human analyst (with access control as a certain method of organizing human activity), and the claim does not recite any particular machine for performing the mental process (i.e., beyond a generic computerization). While the claim recites a data aggregation module, deduplication module, historical data analysis module, integration module, and role-based access system module, these may all be performed by the same generic computer comprised of a base processor, memory, and instructions. The claimed invention is drawn to a problem which is not rooted in computers because it concerns improvements to normalizing, analyzing and reporting, and controlling access to information as discussed above. As such, it is addressing a problem that transcends computing. Since the claimed invention is not rooted in computers, it therefore does not improve the functioning of a computer or any other technology or technical field so as to integrate the judicial exception into a practical application.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the claim recites a data aggregation module, deduplication module, historical data analysis module, integration module, and role-based access system module which may all be performed by the same generic computer comprised of a base processor, memory, and instructions.
Dependent claims 2-7 are substantially similar to elements of claims 9-14 above, and are therefore likewise rejected.
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) 8-11 and 14-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith (US 2020/0097662 A1) in view of Shakarian (US 2022/0078203 A1).
Regarding claim 8, Hufsmith discloses: A method for automated management and evaluation of microservice security (e.g., [0040]-[0045] of Hufsmith concerning microservices as part of security for distributed applications) in a software development environment (e.g., [0158] of Hufsmith concerning microservice security during development), comprising:
receiving security data from multiple Application Security tools (e.g., multitude of different scanners in the abstract and FIG. 1 of Hufsmith), including base image analysis (e.g., [0069] and [0157] of Hufsmith concerning base image scans), source code analysis (e.g., [0073] of Hufsmith concerning source code scans), third-party dependencies analysis (e.g., [0062], [0140], and [0188] of Hufsmith concerning analysis of dependencies and libraries used; [0160] and [0186] of Hufsmith concerning parsing Dockerfile commands), and API security analysis (e.g., [0083] and [0092] of Hufsmith concerning API security analysis);
Refer to at least the abstract and [0002] of Hufsmith with respect to receiving and combining security metrics.
transforming the received security data into a standardized format;
Refer to at least [0081] and [0085] of Hufsmith with respect to normalization of data between formats and translating to a unified format.
analyzing transformed security data based on collected historical security data by applying machine learning models or statistical methods (e.g., [0076] and [0095] of Hufsmith concerning classification models) to predict potential security risks and trends;
Refer to at least [0034] and [0106] of Hufsmith with respect to obtaining historical information as part of generating a threat score.
identifying overlapping vulnerability records based on vulnerability names, severity levels, and sources (i.e., CVE and/or CWE having names, severity, and sources as part of the standards—e.g., [0008] and [0028] of Hufsmith concerning utilization of CVE and/or CWE); merging identified overlapping vulnerability records into a single vulnerability record wherein the identifying employs one or more hash functions to eliminate redundancy in vulnerability records (e.g., [0122] of Hufsmith concerning deduplication using hash functions),; updating an internal database with the merged vulnerability record (e.g., [0086], [0097], and [0107] of Hufsmith with respect to a database for storing, e.g., vulnerability metrics);
Refer to at least [0088], [0114], [0122], and [0130] of Hufsmith with respect to identifying instances of the same vulnerability, grouping, and deduplicating the instances as part of analysis.
generating visual representations summarizing (i.e., combined threat score in Hufsmith) microservice security history (e.g., [0135] of Hufsmith concerning version history, score history, and other contextual information), vulnerabilities (e.g., [0120] and [0129] of Hufsmith concerning CVE and/or CWE properties), risk scores (e.g., [0146] of Hufsmith concerning a score evaluator), and forecasted trends (e.g., [0135] and [0139] of Hufsmith concerning trends in scores).
Refer to at least FIG. 3B-C, FIG. 6, and [0210] of Hufsmith with respect to visual representations having combined threat scores.
Huffsmith discloses deduplication (e.g., [0088] and [0114] of Hufsmith), but does not specify: wherein the predicted risks are used to refine identification of overlapping vulnerability records; and merging of records is performed based on the predicted potential security risks. However, Hufsmith in view of Shakarian discloses: wherein the predicted risks are used to refine identification of overlapping vulnerability records; and merging of records is performed based on the predicted potential security risk.
Refer to at least [0063]-[0068] with respect to “predictive threat data specifying vulnerabilities 414 anticipated to be targeted in a cybersecurity attack are retrieved. Vulnerabilities 414 may be identified by a machine learning model trained on historical attack data and exemplary technology stacks (ETSs) that enable the prediction of future attacks” and “the merging of the predicted vulnerabilities with the augmented metadata to produce a threat map 432 that maps predicted threats to the affected/vulnerable hardware and/or software configurations.”
The teachings of Shakarian likewise concern aggregating vulnerability data, and merging collected data. As such, they are considered to be combinable and in the same field of endeavor.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Huffsmith to include deduplicating vulnerability information based on identified risk for at least the purpose of preventing loss of critical information as false negatives (e.g., if a particular security situation is very important, then all relevant data is likewise very important).
Regarding claim 9, Hufsmith-Shakarian discloses: The method of claim 8, further comprising extracting key information from the received security data, including vulnerability names, components, severity levels, sources, and descriptions, during the transformation into a standardized format.
Refer to at least [0080]-[0085] of Hufsmith with respect to translating scanner data from respective scanners into the unified format.
Refer to at least [0008] and [0028] of Hufsmith concerning CVE/CWE scanners, which implement metrics based on obtained CVE/CWE format data. These formats include vulnerability names, components, severity levels, sources, and descriptions.
Regarding claim 10, it is rejected for substantially the same reasons as claim 8 above (i.e., the citations to generating a combined threat score from the collected metrics; [0076] and [0095] concerning training a classifier).
Regarding claim 11, Hufsmith-Shakarian discloses: The method of claim 8, further comprising establishing connections with existing development tools, retrieving relevant information, and enriching the security data by incorporating contextual insights.
Refer to at least [0158]-[0163] and [0181]-[0182] of Hufsmith with respect to an IDE plugin to provide security information and annotations.
Regarding claim 14, Hufsmith-Shakarian discloses: The method of claim 8, further comprising providing the generated visual representations, risk scores, and trend reports to one or more users for risk management.
Refer to at least [0181]-[0183] of Hufsmith with respect to mitigation strategy and a combined threat score as part of a graphical display to a user.
Regarding independent claim 15, it is substantially similar to independent claim 8 above, and is therefore likewise rejected.
Regarding claims 16-18, they are substantially similar to claims 9-11 above, and are therefore likewise rejected.
Claim(s) 12-13 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith-Shakarian as applied to claims 8-11 and 14-18 above, and further in view of Pearcy (US 2013/0061169 A1).
Regarding claim 12, Hufsmith-Shakarian does not disclose: further comprising controlling access to the security data and the multiple Application security tools based on predefined user roles and responsibilities. However, Hufsmith-Shakarian in view of Pearcy discloses: further comprising controlling access to the security data and the multiple Application security tools based on predefined user roles and responsibilities.
Refer to at least [0042] of Pearcy with respect to access control for granting access to security information or tools. Different users may be associated with different permission levels.
The teachings of Hufsmith-Shakarian and Pearcy both concern security information and GUIs for displaying said security information. As such, they are considered to be within the same field of endeavor and combinable.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Hufsmith-Shakarian to further implement access control for scanner information for at least the purpose of improving security for sensitive information as discussed in the cited portion of Pearcy (e.g., preventing exfiltration by low level employees).
Regarding claim 13, Hufsmith-Shakarian-Pearcy discloses: The method of claim 8, further comprising generating visual representations, including graphs, charts, and reports, summarizing the microservice security history, vulnerabilities, risk scores, and forecasted trends.
Refer to at least FIG. 3B-C, FIG. 6, and [0210] of Hufsmith with respect to visual representations having combined threat scores.
Refer to at least FIG. 3A-B of Pearcy with respect to visualizations of security information including charts and graphs.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Hufsmith-Shakarian-Pearcy to further implement additional ways of displaying security information to a user for at least the purpose of managing a user’s cognitive load as in [0192] of Hufsmith (e.g., chart and graph format being quicker to understand than looking through dozens or hundreds of entries).
Regarding claims 19-20, they are substantially similar to claims 12-13 above, and are therefore likewise rejected.
Claim(s) 1-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hufsmith (US 2020/0097662 A1) in view of Pearcy (US 2013/0061169 A1) and Shakarian (US 2022/0078203 A1).
Regarding claim 1, Hufsmith discloses: A centralized system for automated management and evaluation of microservice security (e.g., [0040]-[0045] of Hufsmith concerning microservices as part of security for distributed applications) in a software development environment (e.g., [0158] of Hufsmith concerning microservice security during development), comprising:
a data aggregation module operatively coupled to receive security data from multiple Application Security tools (e.g., multitude of different scanners in the abstract and FIG. 1 of Hufsmith), wherein the received security data includes base image analysis (e.g., [0069] and [0157] of Hufsmith concerning base image scans), source code analysis (e.g., [0073] of Hufsmith concerning source code scans), third-party dependencies analysis (e.g., [0062], [0140], and [0188] of Hufsmith concerning analysis of dependencies and libraries used; [0160] and [0186] of Hufsmith concerning parsing Dockerfile commands), and API security analysis (e.g., [0083] and [0092] of Hufsmith concerning API security analysis), and transform collected data into a standardized format;
Refer to at least the abstract and [0002] of Hufsmith with respect to receiving and combining security metrics.
Refer to at least [0081] and [0085] of Hufsmith with respect to normalization of data between formats and translating to a unified format.
a historical data analysis module operatively coupled to the data aggregation module, configured to analyze transformed security data based on collected historical security data, apply machine learning models or statistical methods (e.g., [0076] and [0095] of Hufsmith concerning classification models) to predict potential security risks and trends, and generate risk scores and trend reports;
Refer to at least [0034] and [0106] of Hufsmith with respect to obtaining historical information as part of generating a threat score.
a deduplication module operatively coupled to the data aggregation module, configured to identify overlapping vulnerability records based on vulnerability names, severity levels, and sources (i.e., CVE and/or CWE having names, severity, and sources as part of the standards—e.g., [0008] and [0028] of Hufsmith concerning utilization of CVE and/or CWE), merge identified records into a single vulnerability record, and update an internal database with the merged record(e.g., [0086], [0097], and [0107] of Hufsmith with respect to a database for storing, e.g., vulnerability metrics), wherein the deduplication module employs one or more hash functions to eliminate redundancy in vulnerability records (e.g., [0122] of Hufsmith concerning deduplication using hash functions),
Refer to at least [0088], [0114], [0122], and [0130] of Hufsmith with respect to identifying instances of the same vulnerability, grouping, and deduplicating the instances as part of analysis.
an integration module operatively coupled to existing development tools, configured to establish connections, retrieve relevant information, and enrich the security data with contextual insights;
Refer to at least [0158]-[0163] and [0181]-[0182] of Hufsmith with respect to an IDE plugin to provide security information and annotations.
Hufsmith does not disclose: a role-based access system module configured to control access to the security data and tools based on predefined user roles and responsibilities, and grant permissions and access levels accordingly; wherein the predicted risks are used to refine identification of overlapping vulnerability records; merging of records is performed based on predicted risks generated by the historical data analysis module. However, Hufsmith in view of Pearcy discloses: a role-based access system module configured to control access to the security data and tools based on predefined user roles and responsibilities, and grant permissions and access levels accordingly.
Refer to at least [0042] of Pearcy with respect to access control for granting access to security information or tools. Different users may be associated with different permission levels.
The teachings of Hufsmith and Pearcy both concern security information and GUIs for displaying said security information. As such, they are considered to be within the same field of endeavor and combinable.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Hufsmith to further implement access control for scanner information for at least the purpose of improving security for sensitive information as discussed in the cited portion of Pearcy (e.g., preventing exfiltration by low level employees).
Huffsmith-Pearcy discloses deduplication (e.g., [0088] and [0114] of Hufsmith), but does not specify: wherein the predicted risks are used to refine identification of overlapping vulnerability records; merging of records is performed based on predicted risks generated by the historical data analysis module. However, Hufsmith-Pearcy in view of Shakarian discloses: wherein the predicted risks are used to refine identification of overlapping vulnerability records; merging of records is performed based on predicted risks generated by the historical data analysis module.
Refer to at least [0063]-[0068] with respect to “predictive threat data specifying vulnerabilities 414 anticipated to be targeted in a cybersecurity attack are retrieved. Vulnerabilities 414 may be identified by a machine learning model trained on historical attack data and exemplary technology stacks (ETSs) that enable the prediction of future attacks” and “the merging of the predicted vulnerabilities with the augmented metadata to produce a threat map 432 that maps predicted threats to the affected/vulnerable hardware and/or software configurations.”
The teachings of Shakarian likewise concern aggregating vulnerability data, and merging collected data. As such, they are considered to be combinable and in the same field of endeavor.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Huffsmith-Pearcy to include deduplicating vulnerability information based on identified risk for at least the purpose of preventing loss of critical information as false negatives (e.g., if a particular security situation is very important, then all relevant data is likewise very important).
Regarding claims 2 and 7, they are substantially similar to claims 9 and 13 discussed above, and are therefore likewise rejected.
Regarding claims 3 and 6, they are rejected for substantially the same reasons as claim 1 above (i.e., the citations).
Regarding claim 4, it is substantially similar to claim 10 discussed above, and is therefore likewise rejected.
Regarding claim 5, it is substantially similar to claim 11 discussed above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights