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 May 20, 2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 20, 2026 was filed after the mailing date of the Final Office Action on February 6, 2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed May 20, 2026 have been fully considered but they are not persuasive.
In page 1 of the remarks, claims 7, 9, 10, 17, and 20 under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which Applicant regards as the invention. Applicant has amended the claims to traverse the rejections under 112(b), such as removing all mentions of “false data” and relative terms “false” and “real” in the claims, with claim 9 now reciting data of the production system and data in a ‘recovered production system’. As a result of the amendments made to the claims 1, 7, 9-11, 17, and 20, Examiner withdraws the rejections under 112(b) for the aforementioned claims.
In pages 2-8 of the remarks, claims 1-20 are rejected under 112(a) as failing to comply with the written description requirements. Applicant states that the claims require “(i) recovering a same infected snapshot as a recovered production system into each of a plurality of working environments, (ii) executing different scenarios in each environment via different agents, (iii) collecting outputs from each environment, and (iv) analyzing differences between those outputs to derive insights”, and that the claims do not “merely recite a desired result, but instead recite a specific technical process for achieving that result”. Applicant argues that the Office Action (“OA”) indicates that the above requirements are not defined sufficiently in the Specification on how to provoke behavior of the malware, and the Applicant amended the independent claims to recite "to observe behavior of the malware," which is directly supported by the disclosure describing monitoring and observing malware behavior. Applicant states that the OA is incorrect to characterize the claims as lacking written description support merely because the disclosure does not provide source code or a particular comparison algorithm, with the Applicant stating the Specification identifies the source of the insights, their technical content, and their technical application back into a production environment. Furthermore, claims 7, 9-10, 17, and 20 have been amended to overcome the rejections over the terms “false data”, “fake data”, “real data”, and similar terms to overcome the indefiniteness rejections under 112(b) and the written description rejections under 112(a). As a result, Applicant requests that the claims 1-20 have their respective 112(a) rejections withdrawn in light of the amendments made to the claim language.
Examiner states that upon review of the Specification, in particular, paragraphs [0015], [0030], [0039]-[0040], and [0115] with respect to the amendments of the claims, including the independent claims having support for “wherein each of the recovered production systems in the plurality of working environments starts from an identical state” in [0015], “wherein the scenarios are different in each of the recovered production systems” in [0039], “comparing the outputs across the plurality of working environments to identify variations in malware-triggered behavior attributable to the different scenarios” in [0049], and with amendments made to the claims 1, 7, 9-11, 17, and 20, Examiner withdraws the rejections under 112(a) for the aforementioned claims.
In pages 9-12 of the remarks, claims 1-20 are rejected under 103 as being unpatentable over Gupta (US 10,885,191) in view of Huang (US 2020/0210575). Claim 1 has been amended to overcome the rejections of Gupta and Huang, as Gupta is fundamentally directed to execution of malware within a simulated environment corresponding to a target device, does not suggest recovering a same infected backup into a plurality of sandbox working environments that each begin from an identical initial state, and does not suggest executing different scenarios in different recovered production systems generated from the same infected backup, with amended claim 1 requires recovering the infected backup into a plurality of working environments "wherein each of the recovered production systems in the plurality of working environments starts from an identical state." Furthermore, OA relies on Huang for the "learning engine" limitation, but Huang is directed to adversarial malware detection using machine learning and perturbation analysis of feature vectors. Most importantly, Huang’s machine-learning analysis operates on feature representations and perturbation vectors associated with malware classification, does not disclose the claimed forensic experimentation framework in which malware behavior is provoked through execution of different operational scenarios within multiple recovered production systems. Claims 7, 9-10, 17, and 20 were amended to remove the “false data”, “fake data”, “real data”, and similar terms, and Applicant states that Gupta does not disclose the presently claimed emulation of production-environment communications in a recovered production system generated from the same infected backup, nor suggests the presently claimed structured data implementation directed to malware interaction with production-like data characteristics. As a result of the amendments made to the aforementioned claims, Applicant suggests withdrawal of the rejections under 35 U.S.C. 103 for claims 1-20 over Gupta in view of Huang.
Examiner disagrees with the Applicant regarding the statement that Gupta in view of Huang. To reiterate the statement that Gupta observes malware execution across multiple recovered production systems beginning from the same infected backup and subjected to different scenarios, it is described in Gupta’s [Col. 9, lines 3-19], where information that is included as the artefacts of a snapshot can include a variety of information, but the files of a file system used by the first device, which can include applications and data, which is equivalent to the recovered production system, and in conjunction with [Col. 3, lines 42-47] in which a sandbox or other simulation environment contains access to the data from the snapshot after detecting malware, corresponding to a recovered production system generated from the same infected backup, and consequentially, each recovered production system starts from the same state. Furthermore, in [Col. 12, lines 25-27] of Gupta, "FIG. 7 is a flow diagram illustrating one embodiment of a computer-implemented method 700 for using environment context information to detonate malware", which shows an order that must be followed by the software agent in an environment in order to engage or provoke behavior from the malware, corresponding to sequence of predetermined actions, and as there are multiple simulated environments performed to analyze the malware, corresponds to an agent present in each of the recovered production systems. While Huang does not suggest recovering infected backups into multiple working environments, executing different malware scenarios, or comparing outputs from different sandbox environments, the aforementioned passages of Gupta described above suggests these limitations present above, even when amended in the present application.
Furthermore, in claims 7, and 9-10, although amended to clear up the language that was rejected for written description and indefiniteness in the previous OA dated February 6, 2026, recites similar subject matter prior to the amendments made in the present application. Claim 7 now recites “[…] by emulating communications corresponding to communications of the production environment” is described by Gupta in section [Col. 9, lines 55-65], malware execution module 415 allows malware to execute when it detects artefacts of a simulated first device, where malware believes it is on the first device, effectively communicating with a simulated malware host system, corresponds to an emulated communication link, and at least one of the working environments. Claims 9 and 10 are amended to remove all mentions of “false data”, “fake data”, “real data”, and other similar terms, but in claim 10 in particular, the amendment of “[…] wherein the data provided in each of the scenarios is different from the data of the production system” is still taught in the prior art of Gupta, as stated in section [Col. 3, lines 59-62] where artefacts from different systems in introduced into the simulated environments to induce the malware into one or more processes of the malware, and executing in the simulated environment, corresponding to artefacts corresponding to data provided in the scenarios being different from the data in the production system, as described in the amended claims. As a result of the rejections above, claims 1-20 remain rejected under 103 over Gupta in view of Huang.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 10885191 B1) in view of Huang et al. (US 20200210575 A1), hereinafter Huang.
Regarding claim 1, Gupta discloses ‘a method, comprising: receiving an infected backup of a production system at a forensic engine, the infected backup including a malware’ ([Col. 3, lines 39-47] A snapshot includes artefacts that malware looks for, and can include a variety of information, and according to [Col. 9, lines 1-19], including the files in a file system, BIOS version, storage information, and in conjunction, corresponds to the infected backup of the Applicant. [Col. 7, lines 12-16] Simulation module 210 in Fig. 2 simulates the first device in a controlled environment, and the artefacts are used to simulate the first device, with the simulation module corresponding to the forensic engine of the Applicant.);
‘recovering the infected backup as a recovered production system to each of a plurality of working environments provided by a forensic infrastructure, wherein each of the recovered production systems is generated from the same infected backup and includes applications, data, and a[n] engine, wherein each of the recovered production systems in the plurality of working environments starts from an identical state’ ([Col. 3, lines 47-59] Fig. 1, software agent 150 may send a snapshot to a predetermined computer system remote to the targeted machine, with a sandbox simulating the environment of a targeted machine, with the malware included. When a software agent sends a snapshot to a predetermined computer system, it is performed after detecting malware, as stated by [Col. 3, lines 47-50] of Gupta. [Col. 6, lines 66-Col. 7, lines 3] Fig. 2, malware detonation module 145-a can include a simulation module 210, and as shown in Fig. 1, each of the devices and servers contain a malware detonation module, corresponding to a plurality of working environments. As stated in [Col. 9, lines 55-57], the simulation module 210 contains a malware execution module 415 to allow malware to execute within the simulated environment. [Col. 12, lines 27-29] Fig. 1 and Fig. 7, malware detonation modules 145-1-3 can perform the method 700, which can be interpreted as the three devices and at least a second device 170 and server 110 working and simulating the first device 105. [Col. 9, lines 3-19] Information that is included as the artefacts of a snapshot can include a variety of information, but the files of a file system used by the first device, which can include applications and data, which is equivalent to the recovered production system, and in conjunction with [Col. 3, lines 42-47] in which a sandbox or other simulation environment contains access to the data from the snapshot after detecting malware, corresponding to a recovered production system generated from the same infected backup, and consequentially, each recovered production system starts from the same state. [Col. 4, lines 16-21] Analysis system of the simulated environment creates signatures of malware based on analysis, which corresponds to an engine.);
‘executing an agent in each of the recovered production systems, wherein the agents are each configured to execute a scenario in a corresponding recovered production system, wherein the scenarios are different in each of the recovered production systems, wherein each scenario comprises a sequence of actions on the corresponding recovered production system to observe behavior of the malware, the actions including file operations, process executions, and communications associated with execution of each scenario’ ([Col. 4, lines 9-13] Sandbox learns about attributes regarding how the malware runs and accesses different resources on a computer, including the registries and processes, to which malware running corresponds to operational characteristics, and the attributes of the malware being learned corresponds to insights of the Applicant. [Col. 10, lines 21-25] A database includes malware attributes from the simulated environment from other simulated environments or malware attributes discovered, corresponding to outputs of each of the working environments individually and collectively of the Applicant, and each of the scenarios is different from one another. [Col. 12, lines 25-27] "FIG. 7 is a flow diagram illustrating one embodiment of a computer-implemented method 700 for using environment context information to detonate malware", which shows an order that must be followed by the software agent in an environment in order to engage or provoke behavior from the malware, corresponding to sequence of predetermined actions, and as there are multiple simulated environments performed to analyze the malware, corresponds to an agent present in each of the recovered production systems.);
‘collecting outputs generated by the engine in each of the working environments, the outputs comprising information about file access patterns, and process activity logs’ ([Col. 10, lines 21-25] A database includes malware attributes from the simulated environment from other simulated environments or malware attributes discovered, corresponding to outputs of each of the working environments individually and collectively of the Applicant, and each of the scenarios is distinct from one another. [Col. 10, lines 2-8] Malware attributes include a destination within a simulated environment of malware, corresponding to telemetry logs, a sequence of tasks performed, corresponding to file access patterns, tasks performed by malware, corresponding to process activity logs of the Applicant, respectively.);
‘analyzing differences between the outputs generated from each of the working environments by comparing the outputs across the plurality of working environments to identify variations in malware-triggered behavior attributable to the different scenarios to derive insights regarding operational characteristics of the malware, wherein the insights include operational characteristics of the malware, including how the malware spreads, trigger conditions, or communication patterns’ ([Col. 4, lines 9-13] Sandbox learns about attributes regarding how the malware runs and accesses different resources on a computer, including the registries and processes, to which malware running corresponds to generating insights regarding operational characteristics of the malware. [Col. 10, lines 21-25] A database includes malware attributes from the simulated environment from other simulated environments or malware attributes discovered, corresponding to outputs generated from each of the working environments individually and collectively, and each of the scenarios is different from one another, which also corresponds to analyzing differences between the collected information from the plurality of working environments when a malware attribute identification module 505 in Fig. 5 can use attributes to analyze devices and figure out how the malware attributes were discovered through different ways in other simulated environments, as stated in [Col. 10, lines 19-25]. In [Col. 6, lines 45-63] of Gupta, the database 120 is described as containing the malware signatures 160 which represent one or more attributes of the malware. Furthermore, [Col. 5, lines 30-35] describes that the malware can be triggered in a second device 170 because a simulated environment in the second device that presents the artefacts of the first device 105 to track the malware into thinking it is operating on the first device, which tracks malware’s trigger conditions as well in the simulated environment.);
‘and implementing at least one of the insights in a production system to detect, or prevent the malware’ ([Col. 12, lines 25-27] Fig. 7, method 700 is configured to detonate malware in a simulated environment, and use the attributes to then perform block 730, performing a security action in a first device after the method 700 is performed. Performing a security action to detonate malware corresponds to preventing malware.).
Gupta does not appear to disclose, but Huang teaches the limitations of ‘production system including… learning engine’ ([0022] Adversarial malware detector 100 contains a learning engine 110 as part of the detector. When combining the learning engine of Huang in combination with the other aspects of the production system in Gupta, it teaches the limitation of a production system containing a learning engine, as stated by the Applicant.);
‘outputs comprising… network activity’ ([0020] Features of a program, that can potentially be malware according to Huang, can include URL calls, corresponding to network behavior of the Applicant.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Gupta and Huang before them, to include Huang’s ‘production system including… learning engine’ and ‘outputs comprising… network behavior’ in Gupta’s system performing ‘a method, comprising: receiving an infected backup of a production system at a forensic engine, the infected backup including a malware’. One would have been motivated to make such a combination to enhance security by utilizing a machine learning engine to learn features to output a likelihood to determine that a program is benign, as taught by Huang [0022], and to understand behavior of malware’s network behavior to understand its patterns and how it avoids detection, as taught by Huang [0016].
Gupta does not appear to disclose, but Huang teaches the limitation of “collect, from the learning engine, scenario-specific information indicative of malware behavior” ([0021] Fig. 1, machine learning engine 110 classifies a program 102 as either benign 124 or malware 126 based on a feature representation 112 that takes into account features of a program that were extracted by feature extractor 108.)
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “collect, from the learning engine, scenario-specific information indicative of malware behavior” in a method for receiving an infected backup and recovering the backup to a plurality of sandbox working environments and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to observe features to classify the program, such as behaviors, actions, function and API calls, data accesses, URL calls, and other such features of a program to observe if a program is classified as malware (Huang [0020]).
Regarding claim 2, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein at least one of the scenarios is a predetermined set of actions performed by an agent’ ([Col. 12, lines 33-37] Fig. 7, block 705, a first device may be monitored using a software agent, with the steps in Fig. 7 corresponding to a predetermined set of actions of the Applicant.).
Regarding claim 3, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein at least one of the scenarios is a rule-based scenario or a rule-based artificial intelligence scenario or a machine learning model scenario performed by an agent’ ([Col. 12, lines 25-27] Fig. 7 shows an order that must be followed by the software agent in order to remove and learn about the malware, which corresponds to a rule-based scenario of the Applicant.).
Regarding claim 4, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein the each of the working environments are executed in a sandbox’ ([Col. 3, lines 56-59] Sandbox simulates the environment from a first device, or a targeted device, to detect and present information of the malware and learn characteristics about the malware, as stated in [Col. 7, lines 22-24]).
Regarding claim 5, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein at least some of the working environments allow communication between the malware and a malware host system’ ([Col. 7, lines 21-28] Snapshots of the targeted device performing on a remote device allow for malware to be run in a sandbox environment of a remote device, which corresponds to a malware host system of the Applicant.).
Regarding claim 6, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein the infected backup is a most recent point-in-time of the production system’ ([Col. 7, lines 21] The snapshot obtained and run in the remote device is the most recent point-in-time copy of the production system, as stated by the Applicant and the prior art.).
Regarding claim 7, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein at least one of the working environments is configured with an emulated communication link that allows the malware to communicate with a simulated malware host system, by emulating communications corresponding to communications of the production environment’ ([Col. 8, lines 27-35] Fig. 4, acquisition module 405, inside a simulation module 210, itself inside a malware detonation module 145, can obtain artefacts from a first device to a second device. Second device can simulate using a controlled environment to simulate a first device, corresponding to a simulated malware host system of the Applicant. In section [Col. 9, lines 55-65], malware execution module 415 allows malware to execute when it detects artefacts of a simulated first device, where malware believes it is on the first device, effectively communicating with a simulated malware host system, corresponds to an emulated communication link, and at least one of the working environments.).
Regarding claim 8, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘further comprising detecting the malware in the production system or in an existing backup of the production system’ ([Col. 3, lines 47-50] A software agent detecting malware on a target machine corresponds to detecting malware in a production system of the Applicant.).
Regarding claim 9, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘wherein the data in the recovered production system comprises data having a structure, file naming, and metadata that correspond to the structure, file naming, and metadata of data of the production system, such that the malware interacts with the data in the recovered production system as if it were the data of the production system’ ([Col. 10, line 59-Col. 11, line 8] Artefacts can comprise files and directories of a file system, corresponding to structure and naming of real data, as files can contain names as well. Metadata of the file system is also included, corresponding to metadata. Artefacts correspond to data in the recovered production system.).
Regarding claim 10, Gupta in view of Huang teaches the method of claim 1 as recited above. Gupta also discloses the limitation of ‘further comprising providing each of the scenarios with data structured with naming and metadata patterns expected by the malware based on the recovered production system, wherein the data provided in each of the scenarios is different from the data of the production system’ ([Col. 3, lines 59-62] Malware detects the artefacts to induce one or more processes of the malware, believing to be executed on a targeted machine, that being a first device 105 of Fig. 1. The artefacts correspond to the data of the recovered production system to the malware.).
Regarding claim 11, Gupta in view of Huang teaches similar limitations present in independent claim 1 above. Gupta also discloses a non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations ([Col. 2, lines 28-35] A non-transitory storage medium includes instructions to be executed by one or more processors, to perform the method of the prior art of Gupta.)
monitoring each working environment to collect scenario-specific information indicative of malware behavior ([Col. 4, lines 9-22] Sandbox can learn attributes of the malware, and a sandbox runs a simulated environment of the first device, which learns attributes of malware by monitoring said malware. Attributes of malware correspond to collecting scenario-specific information indicative of malware behavior.);
Regarding claim 12, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 2 above.
Regarding claim 13, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 3 above.
Regarding claim 14, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 4 above.
Regarding claim 15, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 5 above.
Regarding claim 16, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 6 above.
Regarding claim 17, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 7 above.
Regarding claim 18, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 8 above.
Regarding claim 19, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses the limitation of ‘further comprising generating the infected backup from the production system when the malware is detected’ ([Col. 3, lines 47-50] Generating of an infected snapshot occurs after the detection of malware in a production system, with the infected snapshot corresponding to the infected backup of the Applicant.).
Regarding claim 20, Gupta in view of Huang teaches the non-transitory storage medium of claim 11 as recited above. Gupta also discloses similar limitations present in claim 9 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Summerlin et al. (US 20210365556 A1, "AUTOMATED MALWARE MONITORING AND DATA EXTRACTION")
Langton et al. (US 20160292419 A1, "MULTI-FILE MALWARE ANALYSIS")
Quinlan et al. (US 9740862 A1, "Identifying Malware Based On A Relationship Between A Downloader File And A Downloaded File")
Bell et al. (US 20240070034 A1, "Method For Performing Backup Of Data Stored In Persistent Storage Associated With Source System, Involves Causing Captured Current Execution Information To Be Stored With Backup Data From Backup Of Stored Data")
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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 on Monday thru Friday 7AM-7PM ET. 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.
/T.M./Examiner, Art Unit 2496 /JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights