Office Action 5: Notice of Allowance (2024-08-27)

CLAIMS:
17164650 CLAIMS LISTING

The following is a listing of claims in the application:

1\. (Previously Presented) A method for detection of cyber threats embedded in cloud applications, comprising: detecting code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment; filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application; performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and detecting a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.
2\. (Original) The method of claim 1, further comprising; reporting each identified potential cyber threat.
3\. (Original) The method of claim 1, further comprising: comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities.
4\. (Previously Presented) The method of claim 1, wherein the non-unique portion of the code includes at least one of: an operating system (OS) package data feature and a third-party code library data feature.
5\. (Previously Presented) The method of claim 1, wherein identifying the mismatch between the unique portion of the code and its verified version stored in the code repository further comprises: comparing hash values of the unique portion of the code to hash values of its verified version.
6\. (Previously Presented) The method of claim 1 wherein the code includes any one of: binary code, executable code, and high-level programming language code.
7\. (Original) The method of claim 1, wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.
8\. (Previously Presented) The method of claim 1, further comprising: creating a resource artifact hash for a resource artifact included in the code, wherein the resource artifact hash is a low-file-size representation of the resource artifact; and comparing the resource artifact hash with at least one repository hash, wherein each of the at least one repository hash is a low-file-size representation of an artifact included in a repository.
9\. (Previously Presented) The method of claim 8, further comprising: determining an artifact status of the resource artifact, wherein the artifact status of the resource artifact is a descriptor indicating a status of the resource artifact; and determining an artifact source of the resource artifact, wherein each artifact source is at least a version of a software package, wherein the at least a version of the software package, when executed, generates the resource artifact.
10\. (Previously Presented) The method of claim 9, further comprising: determining if the resource artifact contains at least one vulnerability based on the artifact status and the artifact source.
11\. (Previously Presented) A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process for detection of cyber threats embedded in cloud applications, the process comprising: detecting code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment; filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application; performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and detecting a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.
12\. (Previously Presented) A system for detection of cyber threats embedded in cloud applications, comprising: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: detect code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment; filter the detected code to remove a portion of the code that is non-unique for the at least one cloud application; perform a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and detect a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.
13\. (Original) The system of claim 12, wherein the system is further configured to; report each identified potential cyber threat.
14\. (Previously Presented) The system of claim 12, wherein the system is further configured to: compare the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities.
15\. (Previously Presented) The system of claim 12, wherein the non-unique portion includes at least one of: an operating system (OS) package data feature and a third-party code library data feature.
16\. (Previously Presented) The system of claim 12, wherein the system is further configured to: compare hash values of the unique portion of the code to hash values of its verified version.
17\. (Previously Presented) The system of claim 12, wherein the code includes any one of: binary code, executable code, and high-level programming language code.
18\. (Original) The system of claim 12, wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.
19\. (Previously Presented) The system of claim 18, wherein the system is further configured to: create a resource artifact hash for a resource artifact included in the code, wherein the resource artifact hash is a low-file-size representation of the resource artifact; and compare the resource artifact hash with at least one repository hash, wherein each of the at least one repository hash is a low-file-size representation of an artifact included in a repository.
20\. (Previously Presented) The system of claim 19, wherein the system is further configured to: determine an artifact status of the resource artifact, wherein the artifact status of the resource artifact is a descriptor indicating a status of the resource artifact; and determine an artifact source of the resource artifact, wherein each artifact source is at least a version of a software package, wherein the at least a version of the software package, when executed, generates the resource artifact.
21\. (Original) The system of claim 20, wherein the system is further configured to: determine if the resource artifact contains vulnerabilities based on the artifact status and the artifact source.

OFFICE 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 .
1.	Claims 1-21 have been examined.
Allowable Subject Matter
2.	Claims 1-21 are allowed.
The following is an examiner’s statement of reasons for allowance:
For independent claims 1 and 11-12, the prior art of record, alone or in combination, fails to teach the following limitations in conjunction with the rest of the claimed limitations:
filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee.  Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
3.	The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Borate et al. (U.S. Patent 11755420) teaches malware detection and a repository of verified clean version snapshots (note Abstract and Fig. 6).
Maya et al. (U.S. Patent Application Publication 2022/0311794) teaches monitoring a software development pipeline including identifying build dependencies of other code and libraries, then scanning the code or particular subsets of the source code (note paragraphs [0713]-[0714]).
Jarrett et al. (U.S. Patent Application Publication 2011/0225128) teaches identifying corrupted files using a clean file repository (note paragraphs [0080]-[0082]).
4.

APPLICANT REBUTTAL: REMARKS
Claims 1-21 are pending in the application and stand rejected under 35 U.S.C. §103.
Rejections of Claims Under 35 U.S.C. §103
Claims 1-6 and 11-17 stand rejected under 35 U.S.C. §103 as allegedly being unpatentable over U.S. Patent No. 10,235,527 of Dalessio et al. (hereinafter “Dalessio”), in view of U.S. Patent Publication No. 2020/0065074 of Duan et al. (hereinafter “Duan”) in further view of U.S. Publication Patent No. 2012/0090025 of Milner et al. (hereinafter “Milner”).  This ground of rejection is traversed for the following reasons.
At the outset, it should be noted that it is understood that each rejection for obviousness is based on a combination of references.  Any argument below citing a single reference is so presented for purposes of clarity only and should
not
be considered as arguing the reference individually.  Any discussion should be considered as arguing the combination of references.  To this end, note that it will be explained why the references do
not
teach all of the elements of the claim for which they are cited, thus showing that the combination as a whole is
invalid
for lack of all of the claim elements and also therefore the cited references can
not
properly be used as a basis for a proper rejection.  It will also be explained why there is a
lack
of motivation to make the combination, and so again the alleged combination does
not
support a proper rejection.
Claim 1 requires (emphasis added):
A method for detection of cyber threats embedded in cloud applications, comprising:
detecting code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment;
filtering the detected code to remove a portion of the code that is non-unique
for the at least one cloud application;
performing a static analysis on each unique portion of the code to identify a mismatch
between any unique portion of the code and its corresponding verified version
stored in a code repository
; and
detecting a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.
The Office Action points to Dalessio as teaching performing a static analysis on each unique portion of the code to identify a mismatch, citing Dalessio, column 11, lines 7-12.  However, there is
nothing
in Dalessio that suggests isolating unique code portions, as is the upshot of the claim’s filtering element.  Thus, Dalessio is
not
identifying a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.  Furthermore, as will be shown hereinbelow, Duan does
not
teach or suggest the filtering step.
First, Dalessio is comparing the whole application package,
not
a unique portion thereof as called for in the claim.  Thus, if there is a change, it might be in a non-unique portion.  Therefore, while it is true that the change might be in a unique portion, nevertheless Dalessio does
not
know or care if that is the case,
nor
does it so determine.  Thus, Dalessio is
not
performing the step as particularly called for in the claim
nor
is it suggesting to do so.
Second, Dalessio is only comparing the current version of the application package to the prior version of itself at the time of the prior scan.  There is
no
teaching or suggestion that such prior version is a verified version
stored in a code repository
.  It is quite possible that the prior version already had a mismatch with respect to a verified version itself.
Note that the claim element is
not
merely find a mismatch between one thing and another.  Rather, it is quite specific in requiring to find a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.  Dalessio does
not
teach or suggest the claim element when all of the words are taken together properly.
Thus, Dalessio does
not
teach or suggest this claim element, which is
lacking
from the combination as a whole.
The Office Action attempts to compensate for these
failings
of Dalssio by citing Milner.  However, Milner, like Dalessio, does
not
teach that any analysis is performed on each unique code portion of the code.  There is
no
filtering of detected code to remove a portion of the code that is non-unique
so as to produce unique portions in Milner, and, as a result, of course it can
not
teach or suggest that any analysis is performed on each unique code portion of the code.  In fact, the
opposite
is true.  Milner teaches to compare the entirety of the code.  This can be seen from the fact that Milner teaches to hash over the whole version of the software package,
not
merely various unique portions thereof.  See, e.g., Milner, paragraphs 32-34.  There is simply
nothing
in Milner that suggests isolating unique code portions, as is the upshot of the claim’s filtering element.  Thus, Milner, like Dalessio, is
not
identifying a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.
Furthermore, the operations performed in Milner are actually performed in the code repository itself, e.g., by security tool 118.  These operations are performed, for example, when determining whether to admit a new software package into the code repository.  See Milner, at least paragraphs 28-37 and FIG. 1, where it is clear that security tool 118, which performs the various security operations on software packages. is within software repository 104.
Thus, Milner does
not
teach or suggest that for which it is cited and it suffers from at least the same defects as does Dalessio, and hence Milner can
not
modify Dalessio to create the claim elements for which Dalessio and Milner are cited.  As such, the claim elements for which Dalessio and Milner are cited are
lacking
from the proposed combination as a whole.
Turning to Duan, it is cited as teaching the claim element of
filtering the detected code to remove a portion of the code that is non-unique
for the at least one cloud application.  In particular, paragraphs 35 and 49 of Duan are cited.  However, these paragraphs do
not
teach to remove any
portion of code
as called for in the claim.  Rather, paragraph 35 appears to be teaching that certain portions of code are
not
considered for matching purposes as keeping such function bodies, common strings, and functions would slow down the system or dilute matching
results
.  Paragraph 49 of Duan relates to filtering search
results
,
not
actually
removing a portion of the code that is non-unique
as is called for in the claim.  In this regard, note that paragraph 49 starts with (emphasis added):
In some cases, server 110 may apply matching rules to improve
results
and / or filter out false positive.
The rest of paragraph 49 gives examples of doing this.  Note that the search
results
which are filtered in paragraph 49 are produced in paragraph 48 of Duan, and at least these paragraphs must be taken together.
Thus, Duan does
not
teach or suggest that for which it is cited by the Office Action, and hence it can
not
modify Dalesssio or Milner to introduce thereto the features for which Duan is cited by the Office Action, even it, arguendo, Dalessio and Milner taught that for which they are cited by the Office Action, which Applicants have shown hereinabove they do
not
.
Thus, the Office Action’s proposed combination does
not
have any of the elements of claim 1, and, as such, independent claim 1 is allowable over the proposed combination under 35 U.S.C. §103.
As to the alleged motivation for combining the references, any such motivation is
irrelevant
at least because the references do
not
teach any of the claim features.  Thus, even assuming that a person having ordinary skill in the art would be motivated to combine the references, such a combination would
not
result in all of the claim features.  Accordingly, the claimed invention would
not
be obvious to a person having ordinary skill in the art.
Also, Applicants note that there is
no
real motivation provided to make the entire combination in toto, and furthermore, there is
no
showing by the Office Action that the proposed overall combination would solve the problem recognized by Applicants.  Also, there is
no
showing made by the Office Action as to how to combine the references to construct Applicants’ invention as claimed.  There is also
no
showing that the art has recognized the problem solved by Applicants or that one looking at the cited references would recognize such a problem and combine the references in a manner that would solve the problem.  In fact, the opposite would appear to be true, as each reference appears to believe that it has solved all the problems of the art to which it is relevant.
MPEP §2143, citing KSR, states that "[t]he key to supporting any rejection under 35 U.S.C. 103 is the clear articulation of the reason(s) why the claimed invention would have been obvious."  The Supreme Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be "made explicit" (emphasis added, see also KSR IntI Co. v. Teleflex Inc., 82 USPQ2d 1385, 1395-97 (2007)).  Thus, the provisions of MPEP §2143 require a clear articulation of reasons to support obviousness rejections under 35 U.S.C. § 103.
For at least the reasons discussed above, it is respectfully submitted that independent claim 1 is patentably distinguishable over the cited combination under 35 U.S.C. §103.  Because claims 2-5 depend from independent claim 1, they incorporate the elements of independent claim 1 and are likewise patentably distinguishable over the combination.  Withdrawal of this rejection is respectfully requested.
Independent claims 11 and 12 are rejected for substantially similar reasons as is claim 1.  Accordingly, the above arguments are therefore essentially repeated, mutatis mutandis, and applied to claims 11 and 12.  Thus, claims 11 and 12, as well as claims 13-17 which depend from claim 12, are likewise allowable.
Withdrawal of these rejections is respectfully requested.
Claims 5 and 16 are also allowable on their own merits.  As explained above, Milner teaches to hash the entirety of the code,
not
just the unique portions of the code as called for in the claims.
Rejection of Claims Under 35 U.S.C. §103
Claims 7-10 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Dalessio, Duan, and Milner, and further in view of Baierlein et al. (U.S. Patent Application Publication 2020/0371782; hereafter “Baierlein”).
Given that all of these rejections of dependent claims are based on the combination of Dalessio, Duan, and Milner, these claims are allowable at least for the same reasons given hereinabove with regard to the respective independent claim from which they depend as none of the additional references are cited as curing the above-described deficiencies of Dalessio, Duan, and Milner.
Also, there is no motivation to make the combination.
Accordingly, withdrawal of these rejections under 35 U.S.C. §103 is respectfully requested.
CONCLUSION


CITED REFERENCE SUMMARIES: Ref US11755420B2: Claims:
A computer-implemented method, comprising: receiving a request to restore a device that is potentially malware affected, the device associated with a plurality of backup snapshots that capture states of the device at different times; retrieving a first backup snapshot of the device; determining that a first file stored in the first backup snapshot is malware affected; checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify a clean version of the first file, wherein checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify the clean version of the first file comprises: identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot; and checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file; determining that a second file stored in the first backup snapshot is clean; and restoring data in the device, the restored data comprising the clean version of the first file restored from a previous backup snapshot and the second file restored from the first backup snapshot.
receiving a request to restore a device that is potentially malware affected, the device associated with a plurality of backup snapshots that capture states of the device at different times;
retrieving a first backup snapshot of the device;
determining that a first file stored in the first backup snapshot is malware affected;
checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify a clean version of the first file, wherein checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify the clean version of the first file comprises: identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot; and checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file;
identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot; and
comparing data stored in the first backup snapshot to data stored in the previous backup snapshot,
identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot,
associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and
based on the association, identifying the previous version of the first file stored in the previous backup snapshot; and
checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file;
determining that a second file stored in the first backup snapshot is clean; and
restoring data in the device, the restored data comprising the clean version of the first file restored from a previous backup snapshot and the second file restored from the first backup snapshot.
The computer-implemented method of claim 1 , wherein determining that the first file stored in the first backup snapshot is malware affected comprises: identifying a file type for the first file; comparing a bit distribution of the first file stored in the first backup snapshot to a predetermined threshold bit distribution, the predetermine threshold bit distribution associated with the file type; and determining that the first file stored in the first backup snapshot is malware affected when the bit distribution is greater than the predetermined threshold bit distribution.
identifying a file type for the first file;
comparing a bit distribution of the first file stored in the first backup snapshot to a predetermined threshold bit distribution, the predetermine threshold bit distribution associated with the file type; and
determining that the first file stored in the first backup snapshot is malware affected when the bit distribution is greater than the predetermined threshold bit distribution.
The computer-implemented method of claim 2 , further comprising checking one or more corresponding versions of a second file captured in one or more previous backup snapshots to identify a clean version of the second file, wherein identifying the clean version of the second file comprises: comparing a bit distribution of a version of the second file stored in a previous backup snapshot to the predetermined threshold bit distribution; and identifying the version of the second file is clean when the bit distribution is less than or equal to the predetermined threshold bit distribution.
comparing a bit distribution of a version of the second file stored in a previous backup snapshot to the predetermined threshold bit distribution; and
identifying the version of the second file is clean when the bit distribution is less than or equal to the predetermined threshold bit distribution.
The computer-implemented method of claim 2 , wherein identifying the file type for the first file comprises: accessing metadata describing the first file, the metadata being stored in the first backup snapshot; and identifying the file type of the first file based on the metadata.
accessing metadata describing the first file, the metadata being stored in the first backup snapshot; and
identifying the file type of the first file based on the metadata.
The computer-implemented method of claim 2 , wherein identifying the file type for the file comprises: accessing a subset of data stored within the first file; and identifying the file type based on the subset of data.
accessing a subset of data stored within the first file; and
identifying the file type based on the subset of data.
The computer-implemented method of claim 2 , wherein comparing the bit distribution of the first file stored in the first backup snapshot to the predetermined threshold bit distribution comprises determining an entropy of the bit distribution of the first file.
The computer-implemented method of claim 1 , wherein a malware affected file is encrypted by ransomware or infected by malware.
The computer-implemented method of claim 1 , wherein the first backup snapshot is a most recent backup snapshot.
The computer-implemented method of claim 1 , further comprising checking one or more corresponding versions of a second file captured in one or more previous backup snapshots to identify a clean version of the second file, wherein identifying the clean version of the second file comprises: identifying a previous version of the second file stored in a previous backup snapshot by: comparing metadata of the second file stored in the first backup snapshot to metadata of a possible previous version of the second file stored in the previous backup snapshot; and based on the metadata of the second file stored in the first backup snapshot substantially matching the metadata of the possible previous version of the second file, identifying the possible previous version of the second file as the previous version of the second file; and checking the identified previous version of the second file to identify whether the identified previous version of the second file is the clean version of the second file.
identifying a previous version of the second file stored in a previous backup snapshot by: comparing metadata of the second file stored in the first backup snapshot to metadata of a possible previous version of the second file stored in the previous backup snapshot; and based on the metadata of the second file stored in the first backup snapshot substantially matching the metadata of the possible previous version of the second file, identifying the possible previous version of the second file as the previous version of the second file; and
comparing metadata of the second file stored in the first backup snapshot to metadata of a possible previous version of the second file stored in the previous backup snapshot; and
based on the metadata of the second file stored in the first backup snapshot substantially matching the metadata of the possible previous version of the second file, identifying the possible previous version of the second file as the previous version of the second file; and
checking the identified previous version of the second file to identify whether the identified previous version of the second file is the clean version of the second file.
The computer-implemented method of claim 1 , further comprising checking one or more corresponding versions of a second file captured in one or more previous backup snapshots to identify a clean version of the second file, wherein identifying the clean version of the second file comprises: scanning a version of the second file stored in a previous backup snapshot for one or more viruses; and based on the scan, identifying whether the version of the second file is a clean version.
scanning a version of the second file stored in a previous backup snapshot for one or more viruses; and
based on the scan, identifying whether the version of the second file is a clean version.
A system comprising: a data store configured to store a plurality of backup snapshots that capture states of a device at different times; a data management server configured to: receive a request to restore the device that is potentially malware affected; retrieve a first backup snapshot of the device; determine that a first file stored in the first backup snapshot is malware affected; check one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify a clean version of the first file, wherein checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify the clean version of the first file comprises: identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot, and checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file; determine that a second file stored in the first backup snapshot is clean; and restore data in the device, the restored data comprising the clean version of the first file restored from a previous backup snapshot and the second file restored from the first backup snapshot.
a data store configured to store a plurality of backup snapshots that capture states of a device at different times;
a data management server configured to: receive a request to restore the device that is potentially malware affected; retrieve a first backup snapshot of the device; determine that a first file stored in the first backup snapshot is malware affected; check one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify a clean version of the first file, wherein checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify the clean version of the first file comprises: identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot, and checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file; determine that a second file stored in the first backup snapshot is clean; and restore data in the device, the restored data comprising the clean version of the first file restored from a previous backup snapshot and the second file restored from the first backup snapshot.
receive a request to restore the device that is potentially malware affected;
retrieve a first backup snapshot of the device;
determine that a first file stored in the first backup snapshot is malware affected;
check one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify a clean version of the first file, wherein checking one or more corresponding versions of the first file captured in one or more previous backup snapshots to identify the clean version of the first file comprises: identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot, and checking the identified previous version of the first file to identify whether the identified previous version of the first file is the clean version of the first file;
identifying a previous version of the first file stored in a previous backup snapshot by: comparing data stored in the first backup snapshot to data stored in the previous backup snapshot, identifying an amount of deleted data based on the comparison, the deleted data being stored within the previous backup snapshot, associating the deleted data stored within the previous backup snapshot with the first file based in part on metadata of the first file, and based on the association, identifying the previous version of the first file stored in the previous backup snapshot, and
based on the association, identifying the previous version of the first file stored in the previous backup snapshot, and
determine that a second file stored in the first backup snapshot is clean; and
restore data in the device, the restored data comprising the clean version of the first file restored from a previous backup snapshot and the second file restored from the first backup snapshot.
The system of claim 11 , wherein the data management server determines that the first file in the first backup snapshot is malware affected by being further configured to: identify a file type for the first file; compare a bit distribution of the first file stored in the first backup snapshot to a predetermined threshold bit distribution, the predetermine threshold bit distribution associated with the file type; and determine that the first file stored in the first backup snapshot is malware affected when the bit distribution is greater than the predetermined threshold bit distribution.
identify a file type for the first file;
compare a bit distribution of the first file stored in the first backup snapshot to a predetermined threshold bit distribution, the predetermine threshold bit distribution associated with the file type; and
determine that the first file stored in the first backup snapshot is malware affected when the bit distribution is greater than the predetermined threshold bit distribution.
The system of claim 12 , wherein the data management server is further configured to check one or more corresponding versions of a second file captured in one or more previous backup snapshots to identify a clean version of the second file, wherein identifying the clean version of the second file comprises: compare a bit distribution of a version of the second file stored in a previous backup snapshot to the predetermined threshold bit distribution; and identify the version of the second file is clean when the bit distribution is less than or equal to the predetermined threshold bit distribution.
compare a bit distribution of a version of the second file stored in a previous backup snapshot to the predetermined threshold bit distribution; and
identify the version of the second file is clean when the bit distribution is less than or equal to the predetermined threshold bit distribution.
The system of claim 12 , wherein that data management server identifies the file type for the first file by being further configured to: access metadata describing the first file, the metadata being stored in the first backup snapshot; and identify the file type of the first file based on the metadata.
access metadata describing the first file, the metadata being stored in the first backup snapshot; and
identify the file type of the first file based on the metadata.
The system of claim 12 , wherein that data management server identifies the file type for the first file by being further configured to: access a subset of data stored within the first file; and identify the file type based on the subset of data.
access a subset of data stored within the first file; and
identify the file type based on the subset of data.
The system of claim 11 , wherein the data management server is further configured to check one or more corresponding versions of a second file captured in one or more previous backup snapshots to identify a clean version of the second file, wherein identifying the clean version of the second file comprises: identify a previous version of the second file stored in a previous backup snapshot by being configured to: compare metadata of the second file stored in the first backup snapshot to metadata of a possible previous version of the second file stored in the previous backup snapshot; and based on the metadata of the second file stored in the first backup snapshot substantially matching the metadata of the possible previous version of the second fi
[Truncated to input limit]