DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Arguments
Applicant's arguments with filed 08/05/2026 have been fully considered as follows:
On pg. 11-12, applicant argues:
“As amended, Claims 1, 10, and 19 now expressly recite that "the threat analysis
comprising: determining, based on a predefined set of criteria, a similarity between the new file and other files stored in the data lake; and at least one of: analysis of the new file using an artificial intelligence or machine learning (AI/ML) model, heuristic analysis, or binary-level analysis of the new file." Claim 5 further recites that "the threat analysis further comprises at least one of: analyzing the new file at a binary-level using the AI/ML model; comparing a hash of the new file against a first database of known file identifiers stored in the cloud-based platform; comparing attributes of the new file against a second database of known security threats stored in the cloud-based platform; applying heuristic analysis to the new file to determine whether characteristics of the new file exhibit behavior patterns associated with known malware, the behavior patterns being stored in the cloud-based platform; or performing signature-based detection on the new file to determine whether the new file matches a previously identified threat signature stored in the cloud-based platform." These are concrete techniques directly and explicitly disclosed in the specification. See at least paragraphs [0019], [0045], [0047], and [0048]. These specific techniques collectively satisfy the requirement of disclosing "species sufficient to support a claim to the functionally-defined genus." Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010). The amended claims also recite that the security agent is configured to perform only file- appearance monitoring on the resource-constrained device (i.e., the security agent is configured to monitor for the new files on the resource-constrained device without executing threat analysis), thereby offloading computationally intensive threat analysis to the cloud-based platform to preserve the device's primary operational function. This limitation is directly supported by paragraphs [0004], [0018], [0020], [0026]-[0029]. Accordingly, the § 112(a) rejection should be withdrawn as to Claims 1-20. Regarding Claims 3 and 12, the amended claims now recite that the recommendation is generated based on a classification assigned to the new file. Supported by paragraphs [0045- 0046], [0049], and [0062]. The § 112(a) rejection as to Claims 3 and 12 should therefore be withdrawn.”
Examiner respectfully disagrees. The applicant appears to suggest that claims 1, 10, and 19 now meet the written description requirement of 35 U.S.C. § 112(a) because the claims now recite: “…the threat analysis comprising: determining, based on a predefined set of criteria, a similarity between the new file and other files stored in the data lake; and at least one of: analysis of the new file using an artificial intelligence or machine learning (AI/ML) model, heuristic analysis, or binary-level analysis of the new file.”, offering ¶19, 45, 47, and 48 as fulfilling the written description requirement of the now amended portion of claims 1, 10, and 19.
Paragraph 19 discloses that the system ingests executable or executable-like files into a private cloud-based data lake and uses AI/ML-based binary analysis to provide continuous and retroactive threat detection and response.
Paragraph 45 discloses that the server analyzes the new file, compares its identifier against known file identifiers, and determines whether it poses a potential threat.
Paragraph 47 discloses that the server analyzes the file using AI/ML, threat databases, heuristics, or signature-based detection to determine whether it matches known malicious behavior or signatures.
Paragraph 48 discloses that the server scans its database of files and uses predefined criteria and unique identifiers to determine similarity between the new file and other files.
As elaborated in MPEP 2161.01(I), “For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).”
Regarding: “analysis of the new file using an artificial intelligence or machine learning (AI/ML) model”
Particularly problematic is whether the applicant demonstrated possession of an AI/ML model that is capable of a binary analysis to provide the claimed threat-analysis functionality. No specific definition was provided as what the applicant means with “AI/ML”, and a person having ordinary skill in the art of cybersecurity will recognize a multitude of different classes of algorithms that meet the definition of AI/ML model. Examples include regression models, decision trees, random forests, gradient-boosting models, SVMs, k-NN, Naive Bayes, clustering models, PCA, isolation forests, and neural network architectures such as MLPs, CNNs, RNNs, LSTMs, and transformers, but this is a non-exhaustive list and merely there to illustrate the breadth of the term “AI/ML model”. The specification fails to disclose a single example of a particular AI/ML model that the applicant envisioned for the purpose of providing the claimed threat-analysis functionality.
However, even if the applicant were to mention a particular algorithm, the applicant would also need to demonstrate possession of a modified model that would be capable of the claimed threat-analysis functionality. Coming back to MPEP 2161.01, it is stated that “The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005).”. Here the level of detail needs to at the minimum reflect modifying a generic machine learning model to suit the needs of the invention, namely the functional language of the claimed threat-analysis functionality. It is further cautioned that “[i]t is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015)”.
Finally, the AI/ML model is disclosed in such generic terms that it resembles at best a black box in which input is fed into it (e.g. a new file), and some result of the analysis is output without illuminating a person having ordinary skill in the art how one arrives the output analysis using a generic file and an undisclosed algorithm.
Regarding: “analysis of the new file using … heuristic analysis”
The same written description concern extends to the claimed “heuristic analysis.” As with the AI/ML limitation, no definition is provided for what the applicant intends by “heuristic analysis,” and the term is capable of encompassing a broad range of techniques, including static rule sets, threshold-based scoring, behavior-pattern matching, or anomaly-based heuristics. The specification does not identify which of these approaches, if any, the applicant envisioned, nor does it disclose any rule set, scoring methodology, or decision logic underlying the heuristic determination.
Even under the standard discussed above, disclosing that the system “may apply heuristic analysis” to detect malware-like behavior is not sufficient. As with an unmodified AI/ML model, merely invoking a generic heuristic technique does not show that the applicant possessed a heuristic scheme adapted to the claimed threat-analysis functionality, particularly where the specification does not explain what behavior is evaluated, how it is evaluated, or how a determination is reached. The same reasoning from Vasudevan applies with equal force: it is not enough that a skilled artisan could design heuristic rules to achieve the claimed result, because the specification itself must explain how the applicant intended to achieve that result.
Here too, the heuristic analysis is described only in functional, outcome-based terms, without disclosing the underlying rules or logic that would allow a person of ordinary skill to understand how the claimed determination is actually made.
Regarding “analysis of the new file using … binary-level analysis of the new file”
Finally, a similar deficiency applies to the claimed “binary-level analysis.” While this term suggests examination of the file at the level of its underlying machine code, bytes, or compiled structure, the specification does not disclose what is analyzed at the binary level, what features or characteristics are extracted, or how such analysis is used to reach a threat determination.
Consistent with the analysis above, generically referencing analysis “at the binary level” does not, by itself, demonstrate possession of a specific binary-level analysis technique suited to the claimed threat-analysis functionality. The specification provides no indication of the parsing approach, feature set, or analytical method involved, leaving a skilled artisan with only the stated outcome rather than an understanding of how that outcome is achieved.
As with the AI/ML and heuristic limitations, the binary-level analysis is disclosed only as a labeled function rather than as a described technique, and the same concern regarding an unexplained black-box process applies equally here.
Regarding claim 5 and its dependence on the same unsupported terms
Claim 5 does not cure the deficiencies identified above, as it largely restates the same underspecified terms in combination. The limitation “analyzing the new file at a binary-level using the AI/ML model” combines two terms already found to lack sufficient disclosure, without providing any additional detail as to how binary-level features are extracted or how such features are then processed by an AI/ML model. Similarly, “applying heuristic analysis… to determine whether characteristics of the new file exhibit behavior patterns associated with known malware” adds only that the “behavior patterns” are “stored in the cloud-based platform,” which identifies a storage location but does not disclose what the behavior patterns are, how they are derived, or how a comparison against them is performed.
The limitation “comparing attributes of the new file against a second database of known security threats” raises a related concern, as “attributes” is undefined and could encompass a wide range of file characteristics; the specification does not identify which attributes are relied upon or how they are compared.
By contrast, “comparing a hash of the new file against a first database of known file identifiers” and “performing signature-based detection… to determine whether the new file matches a previously identified threat signature” reflect well-known and routine techniques in the art, and the Examiner does not raise the same written description concern as to these alternatives standing alone. However, it is unclear from the specification how hash comparison relates to, or is integrated with, the AI/ML, heuristic, or binary-level analysis discussed elsewhere in the claim. The specification does not explain whether a hash match is a threshold step, a standalone determination, or an input that informs the AI/ML, heuristic, or binary-level analysis, and no disclosure ties these techniques together into a described process. Absent such disclosure, a person of ordinary skill in the art is left to speculate as to how the routine hash-comparison technique relates to the remaining, more generically described alternatives recited in the claim.
V. Regarding claims 3 and 12 in that the recommendation is generated based on a classification assigned to the new file. Supported by paragraphs [0045- 0046], [0049], and [0062]. The § 112(a) rejection as to Claims 3 and 12 should therefore be withdrawn.”
While aspects of the previous rejection of 35 U.S.C. 112(a) may have been made moot with the amendment, new issues arise from these amendments and are addressed below.
On pg. 12 applicant argues further:
“The Examiner rejects Claims 5-6 and 14-15 under 35 U.S.C. §112(b) for the terms "unreasonably suspicious" and 'facilitated by the cloud-based platform." Applicant has amended both terms with support found in at least paragraphs [0060], [0082], and [0084]. The § 112(b) rejection of Claims 5-6 and 14-15 is moot and should be withdrawn.”
The previous rejection of claims 5-6 and 14-15 under 35 U.S.C. § 112(b) are hereby withdrawn because the applicant removed the terms “unreasonably suspicious” and “facilitated by the cloud-based platform”.
On pg. 13 applicant argues:
“No human can mentally determine a similarity between an executable file and a corpus of executable files ingested from a plurality of devices into a cloud- resident data lake, perform binary-level AI/ML analysis of the executable files against the data lake, nor mentally generate a probabilistic score of a likelihood of maliciousness from that analysis, all while ensuring no impact on the resource-constrained device's primary operational functions.”
The Examiner respectfully disagrees. The 2019 Revised Patent Subject Matter Eligibility Guidance, as well as MPEP § 2106.04(a)(2), make clear that a claim recites a mental process if it covers performance of the limitation in the mind, or by a human using a pen and paper, even if the claim recites that the process is performed by a computer. The relevant inquiry is not whether a human could physically process the same volume of data (e.g., an entire cloud-resident data lake), but whether the underlying steps, such as comparing characteristics for similarity, evaluating characteristics against known indicators, and forming a conclusion (e.g., a likelihood determination), are steps that can be performed through observation, evaluation, judgment, or opinion.
Sheer scale or volume does not, by itself, remove a claim from the mental-process category. See MPEP § 2106.04(a)(2)(III) (mere automation of a mental process using generic computer components does not integrate a judicial exception into a practical application). Determining “similarity” based on a “predefined set of criteria” and generating a “score indicating a likelihood of maliciousness” are, at their core, evaluative and comparative steps of the type routinely characterized as mental processes, notwithstanding that they are performed here using a computer and a large dataset. The recitation of a “cloud-based platform,” “data lake,” and “AI/ML model” reflects the environment and generic tools used to perform the underlying evaluative steps, rather than a specific improvement to how the comparison or scoring itself is technically achieved.
Accordingly, the mere fact that the claimed operations are performed at greater scale, or on a “cloud-resident data lake,” does not, without more, remove the underlying similarity determination and likelihood scoring from the mental process category.
On pg. 14, applicant argues further:
“The amended claim addresses this problem through a specific combination of structural and functional elements: (1) a security agent configured to only monitor for new files, without executing any threat analysis on the resource- constrained device, thereby preserving the device's computational resources for its primary operational functions; (2) transmission of new files to a cloud-based platform comprising a data lake of executable files ingested from a plurality of devices, enabling continuous and retroactive threat detection across the organization's computing environment; (3) remote threat analysis at the cloud-based platform using at least one of an AI/ML model, heuristic analysis, or binary- level analysis; (4) generation of a score indicating a likelihood of maliciousness based on the threat analysis; and (5) detection of a potential compromise based on that score. Critically, performing all threat analysis remotely (as expressly recited in the amended claim) is what prevents any impact on the primary operational functions of the resource-constrained device (see at least paragraphs [0004], [0018], [0020], [0026]-[0029]). This is not a claim that merely uses a computer as a tool; it is an architectural improvement that creates a capability that did not previously exist-security coverage for an entire class of devices that categorically could not be protected bridging "the gap in security for devices that were previously unable to support such measures" (para. 0028). This improvement to a specific class of computing devices is analogous to the improvements found patent-eligible in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335 (Fed. Cir. 2016) (specific improvement to computer capabilities), and BASCOM Global Internet Servs. v. AT&T Mobility LLC, 827 F.3d 1341, 1350-52 (Fed. Cir. 2016) (specific technical implementation improving upon prior art architecture eligible even where the underlying function could be described abstractly).”
The Examiner respectfully disagrees. Offloading data collection at a resource-limited endpoint and performing analysis at a remote, more capable server is a well-understood, routine, and conventional computer arrangement, not a technical improvement to the computer or network itself. See MPEP § 2106.05(d); TLI Communications LLC v. AV Automotive, L.L.C., 823 F.3d 607, 611-12 (Fed. Cir. 2016) (claims reciting a server that receives, classifies, and stores data transmitted from a mobile device were not patent-eligible because they merely used generic computer components in their ordinary capacity to carry out an abstract idea). Here, the claimed division of labor—monitor locally, transmit, analyze remotely, score, detect—reflects a client-server allocation of tasks based on relative computing capacity, which is itself an abstract, result-oriented concept rather than a specific technical solution to a technical problem. See Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1354 (Fed. Cir. 2016) (collecting, analyzing, and displaying information, even in a networked environment, is abstract absent a specific technical means of improvement).
Applicant’s reliance on Enfish and BASCOM is distinguishable. In Enfish, the claims were directed to a specific, technically described improvement to how data itself was structured and stored in memory (a self-referential table), not merely to relocating a generic analysis step from one generic computer to another. 822 F.3d at 1339. In BASCOM, the Federal Circuit found the claims eligible because they recited a specific, technically detailed arrangement of filtering elements at a particular network location (an ISP server) that provided a customizable technical solution over the prior art’s architecture. 827 F.3d at 1350-52. By contrast, the claims here recite only the functional results of monitoring, transmitting, analyzing, scoring, and detecting, without reciting how the monitoring is limited to preserve resources, how the remote analysis is technically distinguished from conventional server-side malware scanning, or any specific technical modification to the underlying hardware, network protocol, or data structure that departs from conventional client-server security architectures.
Moreover, the “capability that did not previously exist” that Applicant identifies—extending security coverage to devices that could not otherwise run security software—is itself the abstract idea’s benefit, not evidence of a technical improvement to the computer or network. An improved outcome achieved by relocating an existing function to a location with more resources, without a technical explanation of a new or improved technical mechanism, does not integrate the exception into a practical application. See MPEP § 2106.05(a).
Accordingly, the Examiner maintains that the additional elements, considered individually and in combination, amount to no more than implementing the abstract idea using generic computer components in their ordinary, conventional client-server capacities, and the rejection under 35 U.S.C. § 101 is maintained.
Applicant’s arguments, see pg. 15-17, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. § 102/103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly discovered prior art.
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-8, 10-17, and 19-22 are rejected under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. The claims contain 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 had possession of the claimed invention at the time the application was filed.
Claims 1, 10, and 19 recite “analysis of the new file using an artificial intelligence or machine learning (AI/ML) model” and “generating a score indicating a likelihood of maliciousness of the new file based on the threat analysis.” The specification does not reasonably convey to one of ordinary skill in the art that the inventor had possession of the full scope of these limitations. The claims recite the functionality at a high level of breadth without limiting the analysis to a particular model, feature set, rule set, threshold, scoring technique, or decision process. As explained in MPEP § 2161.01, written description concerns may arise where claim language is generic or functional. The critical inquiry is whether the specification reasonably conveys that the inventor possessed the claimed subject matter as broadly claimed. It is not enough that one of ordinary skill in the art could later design software capable of performing the claimed function.
1. AI/ML analysis
The specification refers generally to AI/ML-supported analysis, but does not identify a particular AI/ML model or disclose the input representation, extracted features, training process, inference logic, thresholds, or other decision criteria used to perform the claimed threat analysis.
The term “AI/ML model” encompasses numerous materially different techniques, including regression models, decision trees, random forests, support vector machines, clustering techniques, and neural-network architectures. The specification does not identify which type of model is used or how such a model is adapted to provide the claimed threat-analysis functionality, thus the applicant failed to meet the burden of demonstrating possession of any particular AI/ML model and how a person having ordinary skill in the art would have configured such a model to perform the analysis required by the claim. Accordingly, the AI/ML model is disclosed essentially as a functional black box in which a file is provided as input and a threat-analysis result is produced without explaining how that result is reached.
2. Heuristic analysis
The same concern applies to the claimed “heuristic analysis.” The specification does not identify the heuristic rules, scoring methodology, thresholds, behavior characteristics, or decision logic used to determine whether a file is malicious.
Merely stating that heuristic analysis may be used to detect malware-like behavior does not reasonably convey possession of the claimed functionality where the specification does not explain what behavior is evaluated, how it is evaluated, or how a threat determination is reached.
3. Binary-level analysis
A similar deficiency applies to the claimed “binary-level analysis.” Although the specification indicates that files may be analyzed at the binary level, it does not disclose what portions or characteristics of the binary are examined, what features are extracted, or how those features are used to determine whether the file presents a threat.
Thus, the specification identifies binary-level analysis as a category of analysis without describing a particular algorithm used to achieve the claimed intended result.
4. Maliciousness score
Claims 1, 10, and 19 further recite “generating a score indicating a likelihood of maliciousness of the new file based on the threat analysis.”
Although the specification generally refers to generating a score or likelihood of maliciousness, it does not disclose how the results of the threat analysis are converted into that score. No scoring methodology, weighting, threshold, mathematical relationship, or decision process is described that relates the underlying analysis to the claimed likelihood-of-maliciousness score.
The specification therefore recites the desired result without sufficiently describing how that result is achieved.
Claims 5 and 14 do not cure the deficiencies identified above. These claims further recite, among other alternatives, “analyzing the new file at a binary-level using the AI/ML model,” “comparing attributes of the new file against a second database of known security threats,” and “applying heuristic analysis to the new file to determine whether characteristics of the new file exhibit behavior patterns associated with known malware.”
The specification does not disclose which binary-level features are processed by the AI/ML model, what file “attributes” are relied upon, or what heuristic rules or behavior-pattern comparison logic are used. By contrast, the Examiner does not raise the same written-description concern with respect to hash comparison and signature-based detection standing alone, as those alternatives reflect comparatively definite and conventional comparison techniques. However, those disclosures do not cure the lack of description for the separately claimed AI/ML, heuristic, attribute-based, and binary-level analysis techniques.
Claims 3, 12, and 22 further recite assigning a classification to the new file based on the score, generating an incident response recommendation based on that classification, and transmitting the recommendation to a provider of the resource-constrained device.
Although the specification generally refers to classifications, analysis results, detected compromises, and recommendations, it does not disclose the rules, thresholds, mappings, or decision logic by which the maliciousness score results in a particular classification or by which that classification results in a particular incident response recommendation.
Thus, the specification describes the desired functional relationship between the score, classification, and recommendation without explaining how that relationship is implemented. As explained in MPEP § 2161.01, it is not sufficient that one of ordinary skill in the art could write software to perform the claimed function; the specification itself must reasonably convey possession of that claimed functionality.
Claims 2, 4, 6-8, 11, 13, 15-17, 20, and 21 incorporate the subject matter of parent claims 1, 10, and 19 and do not overcome the written-description deficiencies identified above. Accordingly, claims 1-8, 10-17, and 19-22 are rejected under 35 U.S.C. § 112(a) as failing to comply with the written description requirement.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 10, and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant, regards as the invention.
Claim 1 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “determining, based on a predefined set of criteria, a similarity between the new file and other files stored in the data lake” recites “other files stored in the data lake,” but it is unclear what constitutes the claimed “other files.” The claim does not clearly identify whether “other files” refers to all executable files stored in the data lake, previously analyzed files, known malicious files, a selected subset of files, or some other category of files stored in the data lake. Therefore, the scope of claim 1 is unclear.
Claim 10 recites a limitation corresponding to claim 1 requiring determination of a similarity between the new file and “other files stored in the data lake.” For the same reasons discussed above with respect to claim 1, it is unclear what constitutes the claimed “other files” against which the new file is compared. Therefore, the scope of claim 10 is unclear.
Claim 19 recites a limitation corresponding to claim 1 requiring determination of a similarity between the new file and “other files stored in the data lake.” For the same reasons discussed above with respect to claim 1, it is unclear what constitutes the claimed “other files” against which the new file is compared. Therefore, the scope of claim 19 is unclear.
Claims 2-8 depend directly or indirectly from claim 1 and therefore inherit the indefiniteness of claim 1. Claims 11-17 depend directly or indirectly from claim 10 and therefore inherit the indefiniteness of claim 10. Claims 20-22 depend directly or indirectly from claim 19 and therefore inherit the indefiniteness of claim 19.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8, 10-17, and 19-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1, 10 and 19:
Applying Step 1 of the Subject Matter Eligibility Test (SMET), does the claim as a whole fall within one of the four statutory categories of invention? Yes.
Under Step 2A of the SMET, also known at this stage as the Alice/Mayo Test, Prong One, is the claim as a whole directed to a law of nature, a natural phenomenon, or an abstract idea? Yes.
The abstract steps of monitoring for appearance of new files, identifying a new file based on the monitoring, determining a similarity between the new file and other files, analyzing the new file for threats, generating a score indicating a likelihood of maliciousness, and detecting a potential compromise based on the score amount to observation, evaluation, judgment, and opinion, which fall within the mental process grouping. See MPEP § 2106.04(a)(2)(C).
It should be noted that a person can, either with or without a physical aid, observe whether a file is new, identify the file as previously unseen, compare characteristics according to predefined criteria, evaluate information against known indicators, and reach a conclusion as to whether the file is potentially malicious or whether a device may be compromised. While the claims recite computers and other computer components, the courts have found that a claim requiring a computer may still recite a mental process. CyberSource, 654 F.3d at 1368 n.1, 99 USPQ2d at 1692 n.1.
Applicant argues that a human cannot mentally determine similarity between an executable file and a corpus of executable files stored in a cloud-resident data lake, perform AI/ML or binary-level analysis, or generate a probabilistic maliciousness score at the claimed scale. The Examiner respectfully disagrees. The relevant inquiry is not whether a human could physically process the same volume of data, but whether the underlying steps are acts of observation, evaluation, judgment, or opinion. The volume of information processed, or the automation of those steps using computer components, does not by itself remove the underlying process from the mental-process grouping. FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed. Cir. 2016). The patentee in FairWarning claimed a system and method of detecting fraud and/or misuse in a computer environment in which information was analyzed according to rules to determine whether activity indicated improper access. The court determined that the claims were directed to a mental process of detecting misuse. See also TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48, gathering and analyzing information using conventional techniques and displaying the result.
Applying Step 2A, Prong Two, does the claim recite additional elements that integrate the judicial exception into a practical application? No.
The claim recites the additional elements of:
a computer-implemented method;
a security agent;
a resource-constrained device;
transmitting the new file to a cloud-based platform;
a data lake storing executable files;
remote threat analysis at the cloud-based platform;
a non-transitory computer-readable storage medium-computer-readable medium; and
one or more hardware processors.
A claim reciting a judicial exception is not directed to the judicial exception if the additional elements integrate the exception into a practical application, such as by improving the functioning of a computer or another technology or technical field. However, the additional elements recited here do not provide such an improvement.
Applicant argues that performing threat analysis remotely preserves the computational resources of the resource-constrained device and therefore provides a technical improvement. The Examiner respectfully disagrees. Offloading lightweight monitoring or data collection at a resource-limited endpoint and performing computationally intensive analysis at a more capable remote server represents a conventional client-server allocation of processing tasks based on relative computing capacity. The claims do not recite a specific improvement to the underlying hardware, network protocol, data structure, or malware-analysis technique itself. Rather, the claims recite the functional results of monitoring, transmitting, analyzing, scoring, and detecting using generic computer components in their ordinary capacities.
Thus, the judicial exception is not integrated into a practical application.
Applying Step 2B, do the additional elements amount to an inventive concept? No.
Simply appending well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is insufficient. See Alice Corp., 573 U.S. at 225. The security agent, resource-constrained device, processor, storage medium, cloud-based platform, network transmission, and remote processing components are generic computer components carrying out their ordinary functions. Considered individually and as an ordered combination, the additional elements do not amount to significantly more than the judicial exception. The claims use generic client-server components to monitor or collect information at an endpoint, transmit information to a remote system, analyze the information, generate a result, and act upon that result. No inventive concept that meaningfully transforms the abstract idea into patent-eligible subject matter is recited.
Because claim 1 fails Step 2B, the claim as a whole is found ineligible for being drawn to an abstract idea and therefore is non-statutory under 35 U.S.C. § 101.
The same analysis applies to claims 10 and 19 because they contain substantially the same subject matter. Claim 10 recites additional generic computer components, including a non-transitory computer-readable storage medium and one or more hardware processors, which do not change the foregoing analysis. Likewise, claim 19 recites a non-transitory computer-readable medium storing a program, which also does not change the analysis.
Regarding claim 2:
The dependent claim merely recites the additional step of scanning, via the security agent, the resource-constrained device for all previously unseen files during off-peak hours of the resource-constrained device, wherein the off-peak hours comprise time periods with low utilization of the resource-constrained device, which does not alter the analysis as applied to parent claim 1.
The additional limitation merely schedules the timing of the data-gathering activity based on resource utilization. Performing a scan during low-utilization periods is a routine computer scheduling operation and does not provide an improvement to the underlying computer or technology.
Regarding claim 3:
The dependent claim additionally recites assigning, by the cloud-based platform, a classification to the new file based on the score; generating, in response to the detecting the potential compromise, an incident response recommendation based on the classification; in response to detecting the potential compromise in the device; and transmitting the incident response recommendation to a provider of the resource-constrained device. These additional limitations do not alter the analysis as applied to parent claim 1. Assigning a classification based on evaluated information and generating a recommendation based on the classification constitute further evaluation and judgment. Transmitting the recommendation merely communicates the result of the analysis and constitutes routine post-solution activity.
Regarding claim 4:
The dependent claim additionally recites disabling, by the cloud-based platform, the security agent on the resource-constrained device during predetermined high-utilization periods.
This limitation does not alter the analysis as applied to parent claim 1. Enabling, disabling, or scheduling operation of a generic software component according to utilization conditions represents routine computer control functionality and does not provide an improvement to the underlying computer or technology.
Regarding claim 5:
The dependent claim further recites threat-analysis alternatives including binary-level AI/ML analysis, hash comparison, attribute comparison, heuristic analysis, and signature-based detection.
These additional limitations do not alter the analysis as applied to parent claim 1. They further specify ways in which information regarding the file is analyzed, compared, and evaluated to reach a conclusion regarding a potential threat. The use of generic databases, AI/ML, heuristics, hashing, or signature comparison does not recite a specific improvement to the functioning of the computer itself.
Regarding claim 6:
The dependent claim further specifies deployment and management of the security agent on the resource-constrained device by the cloud-based platform.
This limitation does not alter the analysis as applied to parent claim 1. Deployment and management of software on a remotely connected endpoint through a cloud platform constitute generic networked computer operations and do not provide a specific technological improvement.
Regarding claim 7:
The dependent claim further recites that the potential compromise comprises an unknown attack or a security threat to the resource-constrained device that does not match any previously identified threat signatures. The limitation merely further characterizes the type of result produced by the abstract analysis and adds no additional element that integrates the judicial exception into a practical application or amounts to significantly more.
Regarding claim 8:
The dependent claim further recites that identifying the new file includes generating a hash of the new file to serve as a unique identifier for the new file based on content or metadata of the new file.
Generating a hash or identifier for electronic data is a routine computer operation used for identifying, labeling, or comparing data. The limitation does not alter the finding of ineligibility of parent claim 1 and does not recite an improvement to the underlying computer or hashing technology.
Regarding claim 11:
Claim 11 substantially corresponds to the additional limitation of claim 2 in system form. The recitation of hardware processors configured to perform scanning during low-utilization or off-peak periods does not alter the analysis applied to parent claim 10. The limitation merely schedules a routine computer operation based on resource utilization.
Regarding claim 12:
Claim 12 substantially corresponds to the additional limitations of claim 3 in system form. Assigning a classification based on the score, generating an incident response recommendation based on the classification, and transmitting the recommendation constitute further evaluation of information and communication of the resulting conclusion. These limitations do not alter the analysis applied to parent claim 10.
Regarding claim 13:
Claim 13 substantially corresponds to the additional limitation of claim 4 in system form. Disabling the security agent during predetermined high-utilization periods represents routine control or scheduling of a software component and does not alter the analysis applied to parent claim 10.
Regarding claim 14:
Claim 14 substantially corresponds to the additional threat-analysis limitations of claim 5 in system form. The additional limitations further specify techniques for analyzing and comparing information concerning the new file but do not recite a specific improvement to computer functionality or another technology. Accordingly, the same ground of rejection applies to claim 14.
Regarding claim 15:
Claim 15 substantially corresponds to the additional limitation of claim 6 in system form. Deployment and management of the security agent through the cloud-based platform merely specify generic networked software management and do not alter the eligibility analysis applied to parent claim 10.
Regarding claim 16:
Claim 16 substantially corresponds to the additional limitation of claim 7 in system form. The limitation further characterizes the detected compromise as an unknown attack or security threat not matching previously identified threat signatures and does not add a technological element sufficient to alter the analysis applied to parent claim 10.
Regarding claim 17:
Claim 17 substantially corresponds to the additional limitation of claim 8 in system form. Generating a hash to serve as a unique file identifier based on content or metadata represents a routine computer operation and does not alter the finding of ineligibility of parent claim 10.
Regarding claim 20:
Claim 20 substantially corresponds to the additional limitation of claim 8 in computer-readable-medium form. Generating a hash of the new file to serve as a unique identifier based on content or metadata represents a routine computer function and does not alter the eligibility analysis applied to parent claim 19.
Regarding claim 21:
Claim 21 substantially corresponds to the additional limitation of claim 6 in computer-readable-medium form. The additional recitation concerning deployment and management of the security agent on the resource-constrained device through the cloud-based platform merely specifies generic remote software deployment and management and does not alter the analysis applied to parent claim 19.
Regarding claim 22:
Claim 22 substantially corresponds to the additional limitations of claim 3 in computer-readable-medium form. Assigning a classification based on the score, generating an incident response recommendation based on the classification, and transmitting the recommendation constitute further evaluation of information and communication of the resulting conclusion. These limitations do not provide a specific technological improvement and therefore do not alter the eligibility analysis applied to parent claim 19.
Accordingly, claims 1-8, 10-17, and 19-22 are rejected under 35 U.S.C. § 101 as being directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5, 7-8, 10, 16-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Oberheide et al, (U.S. Pub. No. 2009/004,4024 A1, hereinafter Oberheide) in view of Burnham et al, (U.S. Pub. No. 2015/004,7034 A1, hereinafter Burnham), and in further view of El-Moussa et al, (U.S. Pub. No. 2017/035,1860 A1, hereinafter El-Moussa).
Regarding claim 1, Oberheide in view of Burnham and further in view of El-Moussa teaches:
Oberheide teaches:
A computer-implemented method of detecting security threats on resource-constrained devices, comprising: (see Oberheide, [¶¶0004-0005]: “Instead of running complex analysis software on every end host, this disclosure contemplates that each end host run a lightweight agent to acquire files and data entering a system and send that information to an `in-cloud` network service for analysis by multiple heterogeneous detection engines in parallel. A system is provided for detecting, analyzing and quarantining malicious and unwanted files in a network environment.”);
(Oberheide teaches a lightweight endpoint architecture that sends files to an in-cloud service for malicious-file analysis.)
monitoring, continuously by [[via]] a security agent, a resource-constrained device for an appearance of new files, (see Oberheide, [¶¶0022-0023]: “Each participating host system runs a piece of software called the host agent that inspects each file entering or accessed on a computer system. When a user receives a new file (e.g., via file-copy, installation, or download), the host agent automatically detects the file and tracks metadata about the file. The host agent can hook or otherwise trap invocations of those system calls to determine when new files are created or existing files are modified.”);
(Oberheide teaches an automatically operating host agent that inspects file activity and hooks or traps file-creation and file-write events to detect new files as they appear.)
identifying, via the security agent, a new file based on the monitoring; (see Oberheide, [¶¶0022-0023, 0032]: “Each participating host system runs a piece of software called the host agent that inspects each file entering or accessed on a computer system. When a user receives a new file (e.g., via file-copy, installation, or download), the host agent automatically detects the file and tracks metadata about the file. The host agent can hook or otherwise trap invocations of those system calls to determine when new files are created or existing files are modified. Files identified by the host agent are sent, along with any metadata, to the network service for analysis.”);
(Oberheide teaches that the host agent monitors file-entry and file-creation events and based on that monitoring, identifies newly introduced files.)
performing, at the cloud-based platform and remotely from the resource-constrained device, threat analysis of the new file, the threat analysis comprising: (see Oberheide,
[¶¶0016, 0041]: “The file analysis component 14 of the network service 13 receives candidate files and analyzes them to identify unwanted files. Each detector is an automated process that takes a file or communication and the metadata and context associated with that file as input and attempts to determine if the file or communication is malicious or unwanted.”);
(Oberheide teaches substantive malicious-file analysis at the remote network service.)
and at least one of: analysis of the new file using an artificial intelligence or machine learning (AI/ML) model, heuristic analysis, or binary-level analysis of the new file: (see Oberheide, [¶0041]: “This process can involve local signatures or heuristics stored in the detector or can involve interaction with other remote systems through the network.”);
(Oberheide expressly teaches heuristic analysis, which satisfies one of the recited alternatives.)
generating a score indicating a likelihood of maliciousness of the new file based on the threat analysis; (see Oberheide, [¶0050]: “A more complex approach is to compute a reputation for each file or communication. The reputation assigned by the result aggregator 26 can include several components. The first is a score that indicates how malicious or unwanted a file or communication is. The score might be a floating-point number or integer. When a detector returns a result that result can be aggregated into the reputation in several ways: (1) it can modify the reputation score, (2) it can contribute information to the report about how and why the score was modified, or (3) it can modify the instructions on how to process or handle the file or communication.”);
(Oberheide expressly generates a score indicating how malicious or unwanted the analyzed file is based on detector results.)
and detecting, based on the score analyzing, a potential compromise in the resource-constrained device, wherein the potential compromise indicates that the new file is potentially malicious. (see Oberheide, [¶¶0049-0050, 0073]: “However, if an executable was flagged as unknown by all the detection engines but was downloaded using a peer-to-peer client using a peer-to-peer network protocol then it might be marked as potentially malicious and warrant further inspection by an administrator. A more complex approach is to compute a reputation for each file or communication. The reputation assigned by the result aggregator 26 can include several components. The first is a score that indicates how malicious or unwanted a file or communication is. The resulting evaluation: (1) will modify the object's reputation score, (2) may contribute information to the report about how and why the score was modified, and (3) may modify the instructions on how to process or handle the object.”);
(Oberheide teaches using a maliciousness reputation evaluation and score to identify an executable as potentially malicious, corresponding to detection of a potential compromise associated with the new file.)
Oberheide in view of Burnham does not teach the following limitation taught by Burnham:
transmitting the new file to a cloud-based platform, wherein the new file is stored in a data lake at the cloud-based platform to provide retroactive threat detection, the data lake comprising a collection of executable files ingested from a plurality of devices within a computing environment of the resource-constrained device; (see Burnham, [¶¶0039]: “The central analysis server 136 may include a collection engine 244 that collects incoming executable content data 204 received over one or more internal networks 128 from collection agents 107 and stores the incoming executable content data 204 in storage 220 in any appropriate manner (e.g., in one or more databases).”);
(Burnham teaches centralized storage of executable-content copies received from multiple collection agents on different enterprise hosts, corresponding to the recited data-lake collection. In the proposed combination, Oberheide provides retrospective threat detection using previously analyzed file information when new threat intelligence becomes available.)
determining, based on a predefined set of criteria, a similarity between the new file and other files stored in the data lake; (see Burnham, [¶¶0054-0055]: “Method 360 may begin by receiving 364 incoming executable content data 204 at the central analysis server 136. Method 360 may proceed by extracting 368 characteristics from the executable content, such as by accessing the stored executable content data 204 in incoming data information 224 and subjecting the executable content to any appropriate pattern recognition logic operable to extract user-specified segments from the executable content. The analysis engine 252 may analyze the extracted characteristics 228 and look for one or more similarities among the extracted characteristics 228.”);
(Burnham teaches receiving incoming executable content, extracting defined characteristics from the stored content, and determining similarities among those characteristics.)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date, to modify Oberheide's system for detecting and analyzing malicious files that are sent from a host agent to a network service for analysis by applying the known technique of also storing a copy of the executable files received by the network service and comparing those as taught by Burnham for the predictable result of comparing an incoming file with an already stored file to establish commonalities indicating as to whether a file is malicious or not.
El-Moussa teaches the following limitation not taught by the combination of Oberheide in view of Burnham:
wherein the resource-constrained device lacks computational resources sufficient to execute threat analysis locally, and wherein the security agent is configured to only monitor for the new files without executing threat analysis on the resource-constrained device to preserve the computational resources of the resource-constrained device for its primary operational functions; (see El-Moussa, [¶¶0005-0007, 0031]: “Some computer systems are resource constrained such that the execution of malware detection and/or removal tasks at normal runtime can be expected to cause a noticeable and unacceptable reduction in the performance of the system. The execution of routine malware detection tasks can interfere with the normal services, facilities or functions of such computer systems. For example, a resource constrained client device can send files to a server computer system for the server to undertake a malware scan of the files. In one embodiment the agent 210 is a lightweight agent that is capable of executing on the client 208 with low resource consumption. Such operations are necessarily lightweight operations that do not burden the client 208 and certainly burden the client 208 less than a full and regular anti-malware scan.”);
(El-Moussa teaches a resource-constrained client, preservation of normal device functions, a lightweight low-resource agent, and remote server-side malware scanning. In the proposed combination, Oberheide provides monitoring specifically for newly introduced files.)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date, to modify Oberheide’s system for detecting and analyzing malicious files that are sent from a host agent to a network service for analysis by applying the known technique of performing malware analysis remotely from a resource-constrained client at a server, as taught by El-Moussa, for the predictable result of reducing the computational burden on the resource-constrained device and preserving its resources for its normal operational functions.
Regarding claim 5:
Oberheide teaches:
(Currently Amended) wherein the threat analysis further comprises at least one of: analyzing the new file at a binary-level using the AI/ML model; comparing a hash of the new file against a first database of known file identifiers stored in the cloud-based platform; comparing attributes of the new file against a second database of known security threats stored in the cloud-based platform; applying heuristic analysis to the new file to determine whether characteristics of the new file exhibit behavior patterns associated with known malware, the behavior patterns being stored in the cloud-based platform; or performing signature-based detection on the new file to determine whether the new file matches a previously identified threat signature stored in the cloud-based platform. (see Oberheide, [¶¶0036-0037]: “One of the simplest methods of generating such a UID is a cryptographic hash of a file, such as MD5 or SHA-1. The network service can check a cache for the UID of previously analyzed files to see if a given file has already been analyzed.”);
(Oberheide teaches generating a hash-based identifier for a file and comparing that identifier against stored identifiers for previously analyzed files. Because the limitation recites “at least one of,” disclosure of this alternative is sufficient.)
Claim 14 recites substantially the same limitations as claim 5 in System form. Accordingly, claim 14 is rejected for the same reasons set forth above with respect to claim 5.
Regarding claim 7:
Oberheide teaches:
(Currently Amended) wherein the potential compromise [[is]] comprises an unknown attack-or a security threat to the resource-constrained device that does not match any previously identified threat signatures. (see Oberheide, [¶¶0004, 0043]: “0-day threats and other obfuscated attacks can frequently evade a single engine. When a new file that could not be labeled by an antivirus detector was found, and the behavioral fingerprint of that file matched one of the previously analyzed and known malicious files, then the new file could be marked as potentially malicious.”);
(Oberheide teaches detecting threats that evade prior antivirus identification and identifying a new file as potentially malicious through behavioral fingerprint analysis even when the file could not be labeled by the antivirus detector.)
Claim 16 recites substantially the same limitations as claim 7 in System form. Accordingly, claim 16 is rejected for the same reasons set forth above with respect to claim 7.
Regarding claim 8:
Burnham teaches:
wherein the identifying the new file includes generating a hash of the new file to serve as a unique identifier for the new file based on content or metadata of the new file. (see Burnham, [¶0016]: “For instance, each collection agent (e.g., deployed at infrastructure hosts) and/or network monitor (e.g., deployed at network edges, subnet divisions, etc.) may, in addition to copying and/or tagging received executable content, execute (e.g., via a processor) any appropriate hash function on the executable content to obtain a hash value that uniquely identifies the executable content.”);
(Burnham teaches generating a hash from the executable content that uniquely identifies the executable content. Because the limitation recites “content or metadata,” the content-based alternative is sufficient.)
It would have been obvious to a person of ordinary skill in the art to incorporate Burnham’s hash-based identification of executable content into Oberheide’s new file monitoring and remote malware analysis system. Burnham teaches generating a hash value that uniquely identifies executable content, while Oberheide teaches detecting newly introduced files and forwarding them for remote analysis. A person of ordinary skill would have been motivated to use such a hash as a compact and reliable identifier for newly detected files to facilitate identification, comparison, and tracking of files within the centralized threat-analysis system. The combination would have predictably improved efficient identification of newly encountered files without changing the basic operation of Oberheide’s system.
Claim 17 recites substantially the same limitations as claim 8 in System form. Accordingly, claim 17 is rejected for the same reasons set forth above with respect to claim 8.
Claim 20 recites substantially the same limitations as claim 8 in computer-readable-medium form. Accordingly, claim 20 is rejected for the same reasons set forth above with respect to claim 8.
Regarding claim 10:
Oberheide in view of Burnham and further in view of El-Moussa:
A system for detecting security threats on resource-constrained devices, the system comprising: a non-transient computer-readable storage medium having executable instructions embodied thereon; and one or more hardware processors configured to execute the instructions to: (see Oberheide, [¶0014]: “The system is comprised of three major components: a host agent 12 and a network service 13 offering a file analysis component 14 and a file usage component 16. Each component may be embodied as computer executable instructions in a computer readable medium and residing on a computing device in the network environment.”);
(Oberheide teaches a computer-implemented security system having computer-executable instructions embodied on a computer-readable medium and residing on computing devices.)
Claim 10 recites substantially the same limitations as claim 1 in System form. Accordingly, claim 10 is rejected for the same reasons set forth above with respect to claim 1.
Regarding claim 19:
Oberheide in view of Burnham and further in view of El-Moussa:
A non-transitory computer-readable medium storing a program, which when executed by a computer, configures the computer to: (see Oberheide, [¶0014]: “The system is comprised of three major components: a host agent 12 and a network service 13 offering a file analysis component 14 and a file usage component 16. Each component may be embodied as computer executable instructions in a computer readable medium and residing on a computing device in the network environment.”);
(Oberheide teaches computer-executable instructions embodied in a computer-readable medium and residing on a computing device.)
Claim 19 recites substantially the same limitations as claim 1 in computer-readable-medium form. Accordingly, claim 19 is rejected for the same reasons set forth above with respect to claim 1.
Claims 2 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Oberheide et al, (U.S. Pub. No. 2009/004,4024 A1, hereinafter Oberheide) in view of Burnham et al, (U.S. Pub. No. 2015/004,7034 A1, hereinafter Burnham), in further view of El-Moussa et al, (U.S. Pub. No. 2017/035,1860 A1, hereinafter El-Moussa), and in further view of Guo et al, (U.S. Pub. No. 2014/009,0062 A1, hereinafter Guo).
Regarding claim 2:
Guo teaches:
(Currently Amended) further comprising: scanning, via the security agent, the resource-constrained device for all previously unseen files during off-peak hours of the resource-constrained device, wherein the off-peak hours comprise time periods with low utilization of the resource-constrained device. (see Guo, [¶¶0065, 0067]: “Generally, the system status can include a busy status and an idle status according to occupancy of system resources during operation of the program modules in the system. For example, when current occupancy of system resources is greater than predetermined occupancy, the system status at this time can be defined as a busy status, and when the current occupancy of system resources is less than the predetermined occupancy, the system status at this time can be defined as an idle status. When the system status is idle, if the current virus scanning has begun, continue the current virus scanning, and if the current virus scanning does not begin, acquire a scanning progress of previous virus scanning, begin the current virus scanning according to the scanning progress, and record a scanning progress of the current virus scanning.”);
(Guo teaches initiating or continuing scanning when system-resource occupancy is below a predetermined level, corresponding to the recited low-utilization off-peak hours. In the proposed combination, Oberheide provides security-agent monitoring and identification of newly introduced or previously unseen files.)
It would have been obvious to a person of ordinary skill in the art to incorporate Guo’s low-utilization scanning approach into Oberheide’s new-file monitoring system. Guo teaches determining whether a system is busy or idle based on system-resource occupancy and beginning or continuing scanning when the system is idle. A person of ordinary skill would have been motivated to perform Oberheide’s file monitoring and discovery operations during such low-utilization periods to reduce interference with the device’s normal operations, particularly in view of El-Moussa’s teaching that resource-constrained devices should minimize local computational burden. The combination would have predictably reduced resource contention while allowing security scanning to occur during periods of lower device utilization.
Claim 11 recites substantially the same limitations as claim 2 in System form. Accordingly, claim 11 is rejected for the same reasons set forth above with respect to claim 2.
Claims 3, 12, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Oberheide et al, (U.S. Pub. No. 2009/004,4024 A1, hereinafter Oberheide) in view of Burnham et al, (U.S. Pub. No. 2015/004,7034 A1, hereinafter Burnham), in further view of El-Moussa et al, (U.S. Pub. No. 2017/035,1860 A1, hereinafter El-Moussa), and in further view of Sundaram et al, (U.S. Pub. No. 2021/040,9438 A1, hereinafter Sundaram).
Regarding claim 3:
Sundaram teaches:
(Currently Amended) further comprising: assigning, by the cloud-based platform, a classification to the new file based on the score: generating, in response to the detecting the potential compromise, an incident response recommendation based on the classification; (see Sundaram, [¶¶0020, 0023]: “Each functional use cases can be tagged with additional details, for example, whether software component supports safe mode execution, recommended actions against level (for example, High/Medium/Low) of vulnerability, etc. In accordance with an exemplary embodiment, for example, the actions to be taken can differ from one functional use case to other, and the differences can be also based on severity of vulnerability. In accordance with an exemplary embodiment, in step 240, the vulnerability monitoring process reads each of the catalog for the affected functional use case and fetches (retrieves) default actions for matching severity level and enforce the action.”);
(Sundaram teaches severity classifications such as High/Medium/Low and selecting corresponding actions for the matching severity level. In the proposed combination, Oberheide provides the maliciousness score, which is used to determine Sundaram’s severity classification and corresponding incident-response recommendation.)
in response to detecting the potential compromise in the device; (see Sundaram, [¶0022]: “In accordance with an exemplary embodiment, in step 230, the device 120, 130 a, 130 b, 130 c, 130 d, 130 e is checked to determine if the published vulnerability component is present in the device software catalog, the process continues to step 240, where a precautionary action to safeguard devices against vulnerability is performed.”);
(Sundaram teaches performing precautionary security action after determining that the vulnerability is present in the device.)
and transmitting the incident response recommendation to a provider of the resource-constrained device. (see Sundaram, [¶0028]: “In accordance with an exemplary embodiment, a system and method of automated notification of the vulnerability impact analysis report to a service provider or a manufacturer of a device 120, 130 a, 130 b, 130 c, 130 d, 130 e is disclosed. In accordance with an exemplary embodiment, collate the following details or summary can be collated and reported to the service provider or the manufacturer of the device. For example, vulnerability details and severity and version affected and expected version, list of associated device functional use cases got blocked as precautionary action, and device and software build details.”):
(Sundaram teaches reporting vulnerability severity and resulting precautionary action information to the service provider or manufacturer of the affected device.)
It would have been obvious to a person of ordinary skill in the art to incorporate Sundaram’s severity-based response framework into the centralized threat-analysis system of Oberheide, Burnham, and El-Moussa. Oberheide already provides a maliciousness score for a detected file, while Sundaram teaches using severity levels such as High/Medium/Low to select corresponding security actions and report the vulnerability and resulting precautionary action to a service provider or device manufacturer. A person of ordinary skill would have been motivated to use Oberheide’s maliciousness score to determine the appropriate severity classification, select a corresponding incident-response recommendation, and provide that recommendation to the provider responsible for the affected device. The combination would have predictably improved the system’s ability to turn a detected threat into an appropriate response and communicate that response to the party responsible for the device.
Claim 12 recites substantially the same limitations as claim 3 in System form. Accordingly, claim 12 is rejected for the same reasons set forth above with respect to claim 3.
Claim 22 recites substantially the same limitations as claim 3 in computer-readable-medium form. Accordingly, claim 22 is rejected for the same reasons set forth above with respect to claim 3.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Oberheide et al, (U.S. Pub. No. 2009/004,4024 A1, hereinafter Oberheide) in view of Burnham et al, (U.S. Pub. No. 2015/004,7034 A1, hereinafter Burnham), in further view of El-Moussa et al, (U.S. Pub. No. 2017/035,1860 A1, hereinafter El-Moussa), in further view of Guo et al, (U.S. Pub. No. 2014/009,0062 A1, hereinafter Guo), and in further view of Ali-Ahmed et al, (U.S. Pub. No. 2012/023,3700 A1, hereinafter Ali-Ahmed).
Regarding claim 4:
Guo in view of Ali-Ahmed teaches:
(Currently Amended) further comprising disabling, by the cloud-based platform, the security agent on the resource-constrained device during predetermined high-utilization periods. (see Guo, [¶¶0065-0066]: “Generally, the system status can include a busy status and an idle status according to occupancy of system resources during operation of the program modules in the system. For example, when current occupancy of system resources is greater than predetermined occupancy, the system status at this time can be defined as a busy status, and when the current occupancy of system resources is less than the predetermined occupancy, the system status at this time can be defined as an idle status. Step 102: When the system status is busy, if the current virus scanning does not begin, wait for the current virus scanning, and if current virus scanning has begun, reduce the speed of the current virus scanning, and when system statuses detected within a first predetermined time are all busy, stop the current virus scanning, and record a scanning progress of the current virus scanning.”);
(Guo teaches stopping security scanning when system-resource usage remains high for a predetermined period. Ali-Ahmad teaches centralized management of the endpoint thin client’s deployment, update, run-time, and operation. In the proposed combination, Guo’s high utilization stopping condition would be applied through Ali-Ahmad’s managed endpoint agent architecture so that the security agent is suspended or disabled during predetermined high-utilization periods.)
It would have been obvious to a person of ordinary skill in the art to apply Guo’s utilization-responsive stopping technique to the lightweight, remotely managed security-agent architecture of Oberheide, El-Moussa, and Ali-Ahmad. Guo teaches stopping security processing when device-resource occupancy remains high for a predetermined period, while Ali-Ahmad teaches managing the deployment, update, run-time, operation, and output of an endpoint thin client. El-Moussa further teaches minimizing security-processing burden on resource-constrained clients to preserve their normal functions. A person of ordinary skill would therefore have been motivated to configure the remotely managed endpoint agent to be suspended or disabled when Guo’s predetermined high-utilization condition is satisfied, thereby reducing the use of limited device resources during periods of heavy utilization.
Claim 13 recites substantially the same limitations as claim 4 in System form. Accordingly, claim 13 is rejected for the same reasons set forth above with respect to claim 4.
Claims 6, 15, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Oberheide et al, (U.S. Pub. No. 2009/004,4024 A1, hereinafter Oberheide) in view of Burnham et al, (U.S. Pub. No. 2015/004,7034 A1, hereinafter Burnham), in further view of El-Moussa et al, (U.S. Pub. No. 2017/035,1860 A1, hereinafter El-Moussa), and in further view of Ali-Ahmed et al, (U.S. Pub. No. 2012/023,3700 A1, hereinafter Ali-Ahmed).
Regarding claim 6:
Ali-Ahmed teaches:
wherein the security agent is deployed installed directly on the resource-constrained device by the cloud-based platform, and wherein the security agent is managed and operated and facilitated by the cloud-based platform. (see Ali-Ahmed, [¶¶0016, 0020, 0040-0042]: “The disclosed principles may be employed to provide a system for managing the deployment, update and run-time of such a thin-client on the endpoint device, as a conduit for the endpoint security assessment, as well as a system for automating and managing the lifecycle (i.e., operation and output) of a network-based endpoint device security assessment or scan via a thin-client. The web server 115 delivers the agent scanner client 140 artifacts (e.g., binary code) across the open network 110 to the endpoint device 125 via the web browser 155 running on the endpoint device 125. Scanner Engine compares versions and confirms version to Agent plug-in or uploads Agent DLL to Agent plug-in. In case of upload: Agent plug-in checks signatures on Agent DLL and saves it to disk. Agent plug-in loads Agent DLL from disk, and calls it.”);
(Ali-Ahmad teaches remotely delivering and installing agent software on an endpoint device and managing the deployment, update, run-time, operation, and output of the thin-client.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Oberheide, Burnham, and El-Moussa to incorporate Ali-Ahmad’s remotely deployed and centrally managed thin-client architecture. Ali-Ahmad teaches delivering agent software to an endpoint device and managing its deployment, update, run-time, operation, and output. A person of ordinary skill in the art would have been motivated to use this centralized deployment and management approach to simplify administration of the lightweight security agent while maintaining remote threat analysis. The combination would have predictably provided centralized installation, management, and operation of the endpoint security agent.
Claim 15 recites substantially the same limitations as claim 6 in System form. Accordingly, claim 15 is rejected for the same reasons set forth above with respect to claim 6.
Claim 21 recites substantially the same limitations as claim 6 in computer-readable-medium form. Accordingly, claim 21 is rejected for the same reasons set forth above with respect to claim 6.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-3726. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/ARHAM NMN AHMED/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights