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 .
Status of Claims
The following is a Final Office Action in response to applicant’s filing on October 31, 2025. Claims 1, 17 and 19 were amended. Claim 7 was canceled. Claims 1-6, and 8-20 are pending, of which claims 1, 17, and 19 are in independent form.
Response to Amendment
Applicant’s amendment and argument regarding the independent claims 1, 17, and 19 obviates the rejection under 35 U.S.C. § 112(a), therefore the 112(a) rejection is withdrawn. However, claims 1, 17, and 19 are rejected under 35 U.S.C. § 112(a) based on the new amendment.
Applicant’s amendment and argument regarding the independent claims 1, 17, and 19 obviates the rejection under 35 U.S.C. § 112(b), therefore the 112(b) rejection is withdrawn. However, claims 1, 17, and 19 are rejected under 35 U.S.C. § 112(b) based on the new amendment.
Response to Arguments
Applicant’s argument filed 10/31/2025 have been fully considered but they are not persuasive.
On pages 10-12 of remarks, Applicant argues that “Jaman does not teach or suggest "identifying ... a single malware program identity ... based at least in part on one or more quantities of associations ... satisfying one or more thresholds," as recited in amended independent claim 1.”.
The Examiner disagrees with Applicant and has a different view of prior art teachings and claim interpretation. Regarding the cited limitation “identifying by the data management system” Jaman discloses a system comprising a quarantine engine, malware scanner and detonation engine that collectively analyze files and malware signatures…see paragraphs [0006], [0008], and 0031]. Further, in paragraph [0037], Jaman discloses “where the application opening the file (or the file itself, if it is an executable file) can be monitored for aberrant behavior… attempts to open files outside of this sandbox can then be detected as evidence of aberrant behavior”. An “aberrant behavior” is equated to detected “anomaly”. Therefore, Jaman explicitly discloses detecting aberrant behavior.
Further, Jaman discloses “while that application is monitored for symptoms of malware such as code injection or memory corruption. Similarly, executable files can be executed while monitoring for unauthorized accesses or modification of system files”, see paragraph [0045]. Therefore, Jaman discloses multiple forms of aberrant behavior.
Furthermore, Jaman discloses “malware scanner 312 compares each file to be transferred to the malware signatures stored in signature database 316. Each such signature represents the unique characteristics of a piece of previously identified malware. Thus, if a file being scanned matches one of the signatures in signature database 316, then the corresponding piece of malware is present in the file being scanned.”. See paragraph [0035]. Under BRI, these signatures represent candidate malware program identities potentially associated with suspicious features. Jaman discloses the malware determination and a signature generation upon detecting aberrant behavior “a signature for the detected malware is generated and added to signature data store. In some embodiments, simple, hash-based malware signatures are added. In other embodiments, the signature is specific to the detected malicious behavior”. See paragraphs [0036], [0038], and [0046].
Regrading the cited limitation “based at least in part on one or more quantities of associations between the suspicious features within the set of suspicious features and the at least two candidate malware program identities…”, the examiner asserts that under BRI, “quantities of associations” include a signature match or detected aberrant behaviors. Jaman discloses comparing file against malware signatures using pattern matching rules, where a match constitutes an association. See paragraphs [0035]-[0036], and [0042].
Lastly, Jaman discloses “Another signature might indicate that a fillable form with a field value larger than a prespecified threshold (e.g., 1 MB) contains malware”. Thus, Jaman discloses, decisions maybe malware detected or not detected during signature matching.
Therefore, Jaman discloses detecting anomalous file behavior using a quarantine, scanning, and detonation system and identifying a malware program identity by associating observed suspicious features with one or more malware signatures based on signature matching and threshold detection outcomes.
As to the dependent claims 2-6, 8-16, 18 and 20, these claims remain rejected by virtue of dependency to their independent claims (see Remarks: Page 22).
Therefore, the examiner maintains the rejection under 35 USC § 103.
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-6, and 8-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.
Claim 1 recites “one or more quantities of associations”; there is no disclosure as to what the quantities of associations are between the suspicious features, (i.e., a malware identity associated with the target object and the backup data may be identified (e.g., by a malware identifier, such as the malware identifier 225 of FIG. 2 ) the malware based on an anomaly associated with the target object being detected in the extracted features, where the malware identity may be determined based on the augmented features., see paragraph [0065]). It is noted that the disclosure does not describe any quantities representing associations between suspicious features. Further, the specification fails to disclose as to what constitutes a “quantity of associations” and how associations between features and malware identities are quantified.
Accordingly, the claim fails to satisfy the written description and enablement requirements of 112(a).
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). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. 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).
Accordingly, independent claims 17 and 19 are similarly rejected. Claims 2-6, 8-16 and 18 and 20 which are dependent to claims 1, 17, and 19 are similarly rejected.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 17, and 19 recite the limitation “one or more “quantities” of association” renders the claim indefinite because the claim does not specify what the quantities are, and how they are calculated, or what constitutes an association. As a result, it is unclear whether the claimed quantities refer to scores or other metrices, and the claim provides no objective boundary for determining their scope.
Accordingly, claims 2-6, 8-16 and 18 and 20 which are dependent to claims 1, 17, and 19 are similarly 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over CHACKO (US 2020/0201827 A1), hereinafter CHACKO in view of Jaman (US 2017/0262632 A1), hereinafter Jaman and further in view of Barash et al. (US 2010/0332593 A1), hereinafter Barash.
In regards to claim 1, CHACKO discloses a method, comprising:
extracting, by a data management system (CHACKO, Para. 0056, all the data management and file system can be invoked as a single system, to realize a converged universal file system and data management or universal data management can be implemented as a standalone system), a plurality of features from backup data stored in the data management system for a target object (CHACKO, Para. 0055, Backup server then translate all storage metadata, extract data from the backup format, and re-integrate data and metadata separately, in the format NFS and CIFS clients can access, while backup metadata is translated to the form of other metadata controllers, which can be accessed by the on-premise gateway, in a way it can serve files over NAS protocols. As metadata and user data are separately stored, data of different forms can be integrated and served over NAS protocols as a universal file system),
the backup data reflecting the target object at a point-in-time (CHACKO, Para. 0071, then additional metadata such as time and day of the backup, backup type, which needs to be translated to same form as a browser uploaded file);
CHACKO does not explicitly disclose identifying, by the data management system, a set of suspicious features included in the plurality of features based at least in part on a comparison of the plurality of features to a plurality of malware signatures associated with a plurality of malware program identities;
associating, by the data management system, based at least in part on the identifying, suspicious features from among the set of suspicious features with one or more respective malware program identities from among the plurality of malware program identities, the set of suspicious features being associated with at least two candidate malware program identities from among the plurality of malware identities; identifying, by the data management system, as a result of detecting the anomaly and from among the at least two candidate malware program identities associated with the set of suspicious features, a single malware program identity associated with the anomaly based at least in part on one or more quantities of associations between the suspicious features within the set of suspicious features and the at least two candidate malware program identities satisfying one or more thresholds;
However, Jaman teaches identifying, by the data management system (Jaman, Para. 0006), (0008), and (0031-0032), a set of suspicious features included in the plurality of features based at least in part on a comparison of the plurality of features to a plurality of malware signatures associated with a plurality of malware program identities (Jaman, Para. 0042, files are scanned at a higher semantic level to analyze suspicious patterns of system calls or library calls. In still other embodiments, files are compared to templates for the declared file types. For example, one signature may indicate that any image file with a large header portion but a zero-length content portion contains malware) and (Jaman, Paras. 0035-0036);
associating, by the data management system, based at least in part on the identifying, suspicious features from among the set of suspicious features with one or more respective malware program identities from among the plurality of malware identities (Jaman, Para. 0037, the term “aberrant behavior” refers to any behavior by the application in question that is outside of the usual behavior and indicated the presence of malware in the file), (Jaman, Para. 0036) and (Jaman, Para. 0042), the set of suspicious features being associated with at least two candidate malware program identities from among the plurality of malware identities (Jaman, Para. 0037, any attempts to open files outside of this sandbox can then be detected as evidence of aberrant behavior. Where executable files are loaded, they can be run themselves, and any attempted changes to system files can be detected as evidence of aberrant behavior. Similarly, if monitoring the code portion of the in-memory footprint of the application indicated that code has been injected into the application, this may also serve as evidence that malware is present.); identifying, by the data management system, as a result of detecting the anomaly (Jaman, Para. 0036, files are made immediately available to applications 304 once they have passed malware scanner 312. In such embodiments, if detonation engine 314 detects malware in the transferred files, the detected malware will already be present on computer 206, and must be cleaned) and from among the at least two candidate malware program identities associated with the set of suspicious features (Jaman, Para. 0037, the term “aberrant behavior” refers to any behavior by the application in question that is outside of the usual behavior and indicated the presence of malware in the file), a single malware program identity associated with the anomaly based at least in part on one or more quantities of associations between the suspicious features within the set of suspicious features and the at least two candidate malware program identities satisfying one or more thresholds (Jaman, Para. 0042, for example, one signature may indicate that any image file with a large header portion but a zero-length content portion contains malware. Another signature might indicate that a fillable form with a field value larger than a prespecified threshold (e.g., 1 MB) contains malware);
CHACKO and Jaman are both considered to be analogous to the claim invention because they are in the same field of detecting anomaly based on the features extracted from the backup data. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified CHACKO to incorporate the teachings of Jaman to identifying, by the data management system (Jaman, Para. 0006), (0008), and (0031-0032), a set of suspicious features included in the plurality of features based at least in part on a comparison of the plurality of features to a plurality of malware signatures associated with a plurality of malware program identities (Jaman, Para. 0042), and (Jaman, Paras. 0035-0036); associating, by the data management system, based at least in part on the identifying, suspicious features from among the set of suspicious features with one or more respective malware program identities from among the plurality of malware identities (Jaman, Para. 0037), the set of suspicious features being associated with at least two candidate malware program identities from among the plurality of malware identities (Jaman, Para. 0037) and Jaman, Para. 0036) and (Jaman, Para. 0042); identifying, by the data management system, as a result of detecting the anomaly (Jaman, Para. 0036) and from among the at least two candidate malware program identities associated with the set of suspicious features (Jaman, Para. 0037), a single malware program identity associated with the anomaly based at least in part on one or more quantities of associations between the suspicious features within the set of suspicious features and the at least two candidate malware program identities satisfying one or more thresholds (Jaman, Para. 0042). Doing so would aid to determine that the data file is permitted by a transfer policy to be transferred to the computer, presenting the data file to a user for selection, receiving, from the user, selection of the data file, comparing the data file against a plurality of malware signatures, determining that the data file does not match any of the plurality of malware signatures, transferring the file to a detonation engine, detonating the file in a controlled environment while monitoring for aberrant behavior, and detecting no aberrant behavior when the file is detonated and, in response, making the data file available to the computer (Jaman, Para. 0007).
CHACKO and Jaman do not explicitly disclose detecting, by the data management system, an anomaly associated with the target object based at least in part on the plurality of features extracted from the backup data for the target object;
and indicating, by the data management system via a user interface, the single malware program identity.
However, Barash teaches detecting, by the data management system, an anomaly associated with the target object based at least in part on the plurality of features extracted from the backup data for the target object (Barash, Para. 0037, If the message data contains risk file information, VirusAdmin can download the risk file from the risk file storage and let AppHunter system analyze the risk file. If AppHunter identifies the risk file as a virus file, then VirusAdmin can add its file signatures into the virus database. In such case, it can also send the suspicious file information into the AppHunter queue to let AppHunter further analyze the suspicious file in a test computer); identifying, by the data management system, as a result of detecting the anomaly and based at least in part on the plurality of features extracted from the backup data (Barash, Para. 0037, If the message data contains risk file information, VirusAdmin can download the risk file from the risk file storage and let AppHunter system analyze the risk file. If AppHunter identifies the risk file as a virus file, then VirusAdmin can add its file signatures into the virus database. In such case, it can also send the suspicious file information into the AppHunter queue to let AppHunter further analyze the suspicious file in a test computer), a malware identity associated with the anomaly (Barash, Para. 0041, If the URL is identified by the detection rules, it can be added into the phishing/malware data database); and indicating, by the data management system via a user interface, the identified malware program identity (Barash, Para. 0060, If the URL matches an entry in the local phishing/malware data file, the client software can redirect the user to a warning page to temporarily block access to, or a download from, that URL. After accessing or downloading a new web page, the client software can use its own detection rules to identify any new suspicious phishing/malware URL. If the client software finds any suspicious or newly identified phishing/malware URL, it can check to see whether a phishing/malware reporting queue in the cloud is full or not). CHACKO, Jaman and Barash are all considered to be analogous to the claim invention because they are in the same field of detecting anomaly based on the features extracted from the backup data. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified CHACKO and Jaman to incorporate the teachings of Barash to include detecting, by the data management system, an anomaly associated with the target object based at least in part on the plurality of features extracted from the backup data for the target object (Barash, Para. 0037); identifying, by the data management system, as a result of detecting the anomaly and based at least in part on the plurality of features extracted from the backup data (Barash, Para. 0037), a malware identity associated with the anomaly (Barash, Para. 0041); and indicating, by the data management system via a user interface, the identified malware program identity (Barash, Para. 0060). Doing so would aid the client computers to only communicate with applications running on a virtual machine provided by the cloud (e.g., virtual server) by way of one or more data structures effectively forming a data abstraction layer. In such case, the virtual server is protected from malicious attacks from client computers (Barash, Para. 0025).
In regards to claim 2, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, further comprising: comparing the plurality of features with plurality of malware signatures, wherein the plurality of malware signatures is in a malware signature repository, wherein malware signatures of the plurality of malware signatures correspond to respective malware program identities (CHACKO, Para. 0087, If any of the file change meets the ransomware attack signatures, a real time are alert is generated and IT staff is engaged for manual verification and to match data validity parameters such as a subset of a file modification being a normal pattern).
In regards to claim 3, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 2, wherein: the plurality of features are compared with the plurality of malware signatures before an anomaly detection procedure is performed, wherein the anomaly is detected via the anomaly detection procedure (Barash, Para. 0057, the virus table can be a table listing the names or signatures of known virus files. If so, the process returns to detecting (212) suspicious files. If the suspicious file is not present in the virus table, the process determines (216) whether the suspicious file is present in a cloud database for a risk table. The risk table can be a table listing the names or signatures of known suspicious files. If the suspicious file is present in the risk table, then the process returns to detecting (212) suspicious files as another client or cloud application has apparently already reported the suspicious file). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified CHACKO and Jaman to incorporate the teachings of Barash to include wherein: the plurality of features are compared with the plurality of malware signatures before an anomaly detection procedure is performed, wherein the anomaly is detected via the anomaly detection procedure (Barash, Para. 0057). Doing so would aid the client computers to only communicate with applications running on a virtual machine provided by the cloud (e.g., virtual server) by way of one or more data structures effectively forming a data abstraction layer. In such case, the virtual server is protected from malicious attacks from client computers (Barash, Para. 0025).
In regards to claim 4, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 2, wherein: respective features of the plurality of features are compared with the plurality of malware signatures as the respective features are extracted from the backup data (CHACKO, Para. 0087, Security control plane do real time ransomware attack signature monitoring as well. Hence, ransomware attack is detected as part of a new backup epoch update or through pro-active monitoring process. When every new data is fails to match the ransomware attack signatures, it will meet the data qualification. Data qualification parameters can be set as frequency of data changes, amount of data changes etc.).
In regards to claim 5, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein the set of suspicious features is identified based at least in part on correlating the suspicious features of the set of suspicious features with one or more malware signatures of plurality of malware signatures, wherein the plurality of malware signatures is in a malware signature repository (Barash, Para. 0057, the virus table can be a table listing the names or signatures of known virus files. If so, the process returns to detecting (212) suspicious files. If the suspicious file is not present in the virus table, the process determines (216) whether the suspicious file is present in a cloud database for a risk table. The risk table can be a table listing the names or signatures of known suspicious files. If the suspicious file is present in the risk table, then the process returns to detecting (212) suspicious files as another client or cloud application has apparently already reported the suspicious file). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified CHACKO and Jaman to incorporate the teachings of Barash to include identifying, based at least in part on the extracting, one or more suspicious features from among the plurality of features based at least in part on correlating the one or more suspicious features with one or more malware signatures of a plurality of malware signatures in a malware signature repository (Barash, Para. 0057). Doing so would aid the client computers to only communicate with applications running on a virtual machine provided by the cloud (e.g., virtual server) by way of one or more data structures effectively forming a data abstraction layer. In such case, the virtual server is protected from malicious attacks from client computers (Barash, Para. 0025).
In regards to claim 6, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 5, wherein identifying the set of suspicious features comprises: identifying that a feature included in the plurality of features comprises a filename, a file extension, a content, a hash result, or any combination thereof (CHACKO, Para. 0071, Metadata can be very minimal such as file name, size and source IP or user name), that corresponds to a malware signature of the plurality of malware signatures (CHACKO, Para. 0087, If any of the file change meets the ransomware attack signatures, a real time are alert is generated and IT staff is engaged for manual verification and to match data validity parameters such as a subset of a file modification being a normal pattern); and designating the feature as a suspicious feature based at least in part on identifying that the filename, the file extension, the content, the hash result, or any combination thereof, of the feature corresponds to the malware signature (CHACKO, Para. 0120, this is useful to prevent data from cyber-attacks such as ransomware. User will enter data classification policies to indicate critical data sets. One data classification policy can be a list of strings contained in the file name to indicate critical file).
In regards to claim 8, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein associating the set of suspicious features with the one or more respective malware program identities comprises:
associating a suspicious feature of the set of suspicious features with a respective malware identity of the plurality of malware program identities based at least in part on the suspicious feature comprising a filename, a file extension, a content, or any combination thereof, that corresponds to a signature of the respective malware identity (CHACKO, Para. 0041, ransomware can rename files. This also equates to drastic data changes of the original file name. Ransomware can do data exfiltration, which equates to huge data transfer across network. All this infection signatures can be used to detect any ransomware attack pattern).
In regards to claim 10, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein identifying the malware program identity associated with the anomaly comprises: inputting the set of suspicious features to a machine learning model that outputs a hypothesized malware identity based at least in part on the set of suspicious features (CHACKO, Para. 0108, Metadata controller node, running Machine Learning and AI based anomaly detection, behavioral data collection to detect if any unwanted network data activity is taking place), the single malware program identity associated with the anomaly being identified based at least in part on the hypothesized malware identity (CHACKO, Para. 0108, to secure Vault, flagging the event as a potential attempts through cyber-attacks or Ransomware activity).
In regards to claim 11, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein identifying the single malware program identity associated with the anomaly comprises: determining respective quantities of the set of suspicious features, the respective quantities corresponding to respective malware program identities of the plurality of malware program identities (CHACKO, Para. 0083, when secondary metadata control plays the role as a security control point, it will monitor all systems, having data resources, for any anomalies, corrupted files, malicious activities, virus checking, configuration file hardening and related security monitoring services can be performed… All components in the UFS module, can get a gold copy of configuration files, security configuration for OS attributes, management data such as various services enabled for each UFS module and various identity verification services can be performed), wherein the Single malware program identity is identified as being associated with the anomaly based at least in part on the Single malware program identity corresponding to a largest respective quantity of the respective quantities (CHACKO, Para. 0087, another salient feature of the invention is the way it prevents ransomware impacted data sets with the known gold copy of the data).
In regards to claim 12, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein the single malware program identity is identified based at least in part on a type of the anomaly (CHACKO, Para. 0087, New data sets then subjected to ransomware anomaly detection. Each file object is examined for the change against the previous file object. If any of the file change meets the ransomware attack signatures).
In regards to claim 13, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 11, further comprising: identifying, based at least in part on identifying the single malware program identity (CHACKO, Para. 0040, this is a system that's installed in a PC which has system programs that can navigate file systems, looking up file changes, compare file change against normal changes or abnormal changes such as ransomware activity), a set of suspicious features of the one or more suspicious features that are associated with the identified malware program identity; and providing, for inspection via the user interface, one or more files associated with the set of suspicious features, the one or more files being detected as ransom note candidates, as malware-encrypted file candidates, or both (CHACKO, Para. 0120, this is useful to prevent data from cyber-attacks such as ransomware … user will enter data classification policies to indicate critical data sets. One data classification policy can be a list of strings contained in the file name to indicate critical file. If the filename contains this string, its classified as critical. It will be provided additional data services. Data administrator does not know how to differentiate ransomware attacks. So user can enter policies by which data changes can be qualified as good changes as opposed to changes due to network worms).
In regards to claim 14, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, further comprising: identifying, based at least in part on identifying the identified malware program identity, a first set of files in the backup data as ransom note candidates (CHACKO, Para. 0040, this is a system that's installed in a PC which has system programs that can navigate file systems, looking up file changes, compare file change against normal changes or abnormal changes such as ransomware activity), a second set of files in the backup data as malware-encrypted file candidates, or both (CHACKO, Para. 0041, ransomware can encrypt a file. This equates to full file change. It can remove the contents. This equates to drastic file changes. Ransomware can rename files. This also equates to drastic data changes of the original file name. Ransomware can do data exfiltration, which equates to huge data transfer across network. All this infection signatures can be used to detect any ransomware attack pattern); and providing, for inspection via the user interface, the first set of files, the second set of files, or both (CHACKO, Para. 0084, Security profile of a user or data silo can be configured through a GUI (Graphical User Interface). For example, security profile of a data silo can be to Security controller has security configuration data and a security engine. Security Engine process all the security events data received at security controller through security lanes and determines if there is any anomaly).
In regards to claim 15, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, further comprising: storing, prior to extracting the plurality of features from the backup data, the backup data in the data management system (CHACKO, Para. 0053, 651 is a system of storage that stores all metadata and some form of backup data).
In regards to claim 16, the combination of CHACKO and Jaman in view of Barash teaches the method of claim 1, wherein detecting the anomaly associated with the target object comprises: comparing the plurality of features extracted from the backup data with a second plurality of features previously extracted from second backup data that reflects the target object at a second point-in-time (CHACKO, Para. 0087, new data sets then subjected to ransomware anomaly detection. Each file object is examined for the change against the previous file object. If any of the file change meets the ransomware attack signatures, a real time are alert is generated and IT staff is engaged for manual verification and to match data validity parameters such as a subset of a file modification being a normal pattern. If verification fails, with no ransomware attacks, new data is updated to old known copy).
In regards to claim 17, the apparatus of claim 17 is similarly analyzed and rejected as the system claim 1.
In regards to claim 18, the apparatus of claim 18 is similarly analyzed and rejected as the system claim 2.
In regards to claim 19, the non-transitory, computer-readable medium of claim 19 is similarly analyzed and rejected as the system claim 1 and apparatus of claim 17.
In regards to claim 20, the non-transitory, computer-readable medium of claim 20 is similarly analyzed and rejected as the system claim 2 and apparatus of claim 18.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over CHACKO (US 2020/0201827 A1), hereinafter CHACKO in view of Jaman (US 2017/0262632 A1), hereinafter Jaman and in view of Barash et al. (US 20100332593 A1), hereinafter Barash and further in view of MESTHA et al. (US 2020/0097651 A1), hereinafter MESTHA.
In regards to claim 9, the combination of CHACKO and Jaman in view of Barash does not explicitly teach the method of claim 1, further comprising: obtaining a plurality of augmented features for the target object based at least in part on the associating, the plurality of augmented features comprising a first portion of the plurality of features that excludes the set of suspicious features and a second portion of the plurality of features that includes the set of suspicious features, wherein detecting the anomaly associated with the target object comprises detecting one or more anomalous characteristics of the plurality of augmented features.
However, MESTHA teaches obtaining a plurality of augmented features for the target object based at least in part on the associating (MESTHA, Para. 0057, The pre-processing element 552 may then generate data samples that are provided to a MMMD feature extraction unit 560 and a dynamic anomaly forecasting and situation awareness element 570 (e.g., to generate early warnings). The feature extraction unit 560 might include, for example, feature engineering 562 and feature augmenting 564, and provide feature vectors to the anomaly detection and correction element 580), the plurality of augmented features comprising a first portion of the plurality of features that excludes the one or more suspicious features and a second portion of the plurality of features that includes the one or more suspicious features (MESTHA, Para. 0056, dynamic system identification 534, and/or feature augmenting elements of a feature discovery element 530 that in turn provides feature vectors to an anomaly decision modeling system 540. The anomaly decision modeling system 540 may include normal data 542 and abnormal data 544 that are used, along with the received feature vectors, by decision boundary computations 546 to output feature boundaries to an anomaly detection and correction element 580 in the real-time portion 550 of the architecture 500), wherein detecting the anomaly associated with the target object comprises detecting one or more anomalous characteristics of the plurality of augmented features (MESTHA, Para. 0057, feature augmenting 564, and provide feature vectors to the anomaly detection and correction element 580). CHACKO, Jaman and Barash and MESTHA are all considered to be analogous to the claim invention because they are in the same field of detecting anomaly based on the features extracted from the backup data. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified CHACKO, Jaman and Barash to incorporate the teachings of MESTHA to include obtaining a plurality of augmented features for the target object based at least in part on the associating (MESTHA, Para. 0057), the plurality of augmented features comprising a first portion of the plurality of features that excludes the one or more suspicious features and a second portion of the plurality of features that includes the one or more suspicious features (MESTHA, Para. 0056), wherein detecting the anomaly associated with the target object comprises detecting one or more anomalous characteristics of the plurality of augmented features (MESTHA, Para. 0057). Doing so would aid provide for detecting when a perturbation event has happened or is about to happen (i.e., forecasting) and then neutralizing the effects of the likely perturbation in real-time. One or more embodiments provide for neutralizing the effects of abnormalities in the operation of the device so that the device may be capable of “self-defense” in the presence of faults or cyber-attacks for continued operation, ensuring patient safety (MESTHA, Para. 0023).
Conclusion
THIS ACTION IS MADE FINAL. 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 GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496