DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 29, 2026has been entered.
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on April 29, 2026. Claims 1, 11, 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.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected, under 35 USC 103(a), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter.
On Pages 10-12 of remarks, Applicant argues that the cited references do not teach or suggest “the single malware program identity corresponding to a first quantity of occurrences of suspicious features of the set of suspicious features, the first quantity being a greatest quantity from among a plurality of quantities of occurrences of suspicious features associated with the at least two candidate malware program identities; .
Applicant’s arguments, with respect to the rejection(s) of claim(s) 1, 17 and 19 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 the article entitled “Statistical Approach towards Malware Classification and Detection” by Ghanaei.
Claims 2-6, 8-16 and 18 and 20 which are dependent to claims 1, 17, and 19 are similarly rejected.
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 “the first quantity being a greatest quantity from among a plurality of quantities of occurrences of suspicious features associated with the at least two candidate malware program identities;”. The specification fails to describe determining a plurality of quantities of occurrences of suspicious features for multiple candidate malware program identities and selecting a malware program identity based on the first quantity being the greatest among such quantities (i.e., the malware identifier may identify, across the augmented features, a quantity of ransom notes and affected files associated with each malware identity, and e malware identifier may select the malware identity that is associated with the greatest quantity of ransom notes and affected files. In some examples, instead of identifying a single malware identity, the malware identify may identity multiple malware identities—e.g., each of the malware identities for which a threshold quantity of suspicious features is identified, see paragraph [0066]). It is noted that the disclosure does not describe more specific quantitative selection such as first quantity being a greatest quantity .
Therefore, the claim fails to satisfy the written description and enablement requirements of 112(a).
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.
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-6, 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 the article entitled “Statistical Approach towards Malware Classification and Detection” by Ghanaei 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 the single malware program identity corresponding to a first quantity of occurrences of suspicious features of the set of suspicious features, the first quantity being a greatest quantity from among a plurality of quantities of occurrences of suspicious features associated with the at least two candidate malware program identities,
However, Ghanaei teaches 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 (Ghanaei, Page. 4, every malware variant is classified into a malware family based on the similarity measurement of its constituent basic blocks in comparison to the critical malicious patterns of different malware families which exist in the dataset. As described earlier, the most critical malicious patterns in every malware family, the authors have relied on the shared basic blocks among different malware variants, which potentially occur in one specific family at most) and (Ghanaei, Page. 4, Every malware variant is classified into a malware family based on the similarity measurement of its constituent basic blocks in comparison to the critical malicious patterns of different malware families which exist in the dataset, it is noted that “the critical malicious patterns” corresponds to the malware signatures);
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 (Ghanaei, Page. 2, the function features for each malware family are defined regardless to the distribution frequency ratio of the number of malware variants that exist in every malware family), the set of suspicious features being associated with at least two candidate malware program identities from among the plurality of malware identities (Ghanaei, Page. 2, Firstly, each basic block is scored based on its distribution frequency ratio in each malware family, and if it did not exist previously, it is ignored. Secondly, the distribution frequency of each basic block based on its occurrence in a number of different malware variants in each malware family is computed; according to both of these attributes for all of the constituent basic blocks of a malware variant, it is classified into a malware family); 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 (Ghanaei, Page. 4, noticing that some new code is also introduced into the corresponding malware family which may match a variant in the unclassified malware samples. The initial dataset is developed with a limited number of malware families, 23, but obviously there are more malware families in the wild, and from time to time a new malware family is introduced by the malware authors. Therefore, there is a high possibility that the unclassified malware variants do not belong to any malware family existing in the dataset. Thus, another module checks if a number of unclassified malware variants share a certain amount of malicious code (critical malicious pattern) together, then groups them together and introduces a new possible malware family into the dataset), a single malware program identity associated with the anomaly based at least in part on the single malware program identity corresponding to a first quantity of occurrences of suspicious features of the set of suspicious features (Ghanaei, Page. 2, each basic block is scored based on its distribution frequency ratio in each malware family, and if it did not exist previously, it is ignored. Secondly, the distribution frequency of each basic block based on its occurrence in a number of different malware variants in each malware family is computed; according to both of these attributes for all of the constituent basic blocks of a malware variant, it is classified into a malware family) and (Ghanaei, Page. 4, Every malware variant is classified into a malware family based on the similarity measurement of its constituent basic blocks in comparison to the critical malicious patterns of different malware families which exist in the dataset), the first quantity being a greatest quantity from among a plurality of quantities of occurrences of suspicious features associated with the at least two candidate malware program identities (Ghanaei, Page. 4, the most critical malicious patterns in every malware family, the authors have relied on the shared basic blocks among different malware variants, which potentially occur in one specific family at most [20]. To do so, TFDi,k and FamClassifieri,k needs to be computed for all the constituent basic blocks of the new malware variant to make it comparable with the critical malicious patterns),
CHACKO and Ghanaei 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 Ghanaei to 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 (Ghanaei, Page. 4); 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 (Ghanaei, Page. 2), the set of suspicious features being associated with at least two candidate malware program identities from among the plurality of malware identities (Ghanaei, Page. 2); 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 (Ghanaei, Page. 4), a single malware program identity associated with the anomaly based at least in part on the single malware program identity corresponding to a first quantity of occurrences of suspicious features of the set of suspicious features (Ghanaei, Page. 2), the first quantity being a greatest quantity from among a plurality of quantities of occurrences of suspicious features associated with the at least two candidate malware program identities (Ghanaei, Page. 4). Doing so would aid to involve more details of the malicious software to be included in the critical malicious pattern to increase the accuracy, such as the strings, the information contained in the import-export tables of the malware, the file type, etc. to potentially improve the accuracy rate (Ghanaei, Page. 6).
CHACKO and Ghanaei 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, Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 occurrences of the suspicious features of the set of suspicious features for each respective malware program identity of the plurality of malware program identities of occurences (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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 Ghanaei 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 the article entitled “Statistical Approach towards Malware Classification and Detection” by Ghanaei 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 Ghanaei 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, Ghanaei 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, Ghanaei 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
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 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
Prosecution Insights