DETAILED ACTION
This Action is in consideration of the Applicant’s response on March 25, 2026. Claims 1, 7, 9, 11, and 13 – 16 are amended by the Applicant. Claims 1 – 17, where Claims 1 and 9 are in independent form, are presented for examination.
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 .
Response to Arguments
Applicant’s arguments filed March 25, 2026 have been fully considered but they are not persuasive. Applicant argued:
a) Regarding Claims 1 and 9, the combination of Rellinger and Hunter do not disclose of a deletion request received by the VSS.
b) Regarding Claims 1 and 9, the combination of Rellinger and Hunter do not disclose of the VSS including a COM API hook to intercept the request.
c) Regarding Claims 1 and 9, the combination of Rellinger and Hunter do not disclose of an OS kernel receiving a second deletion request and includes an IRP filter to disallow it.
The Office respectfully disagrees with Applicant’s assertions.
1. With regards to a), both Rellinger [Col. 6, lines 34-37] and Hunter [Pg. 5] both disclose of receiving deletion requests.
2. With regards to b), Hunter further discloses that VSS is implemented in COM technology and one of the methods to prevent shadow copy deletion includes COM object filters [Pgs. 2 and 13].
3. With regards to c), both Rellinger [Fig. 5; Col. 6, lines 22-34] and Hunter [Pg. 13] further disclose of using an IRP filter in the kernel to block any potentially malicious request.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1 – 17 are rejected under 35 U.S.C. 103 as being rejected by U.S. Patent 10,606,766 (hereinafter “Rellinger”), in view of “Stomping Shadow Copies – A Second Look Into Deletion Methods” (hereinafter “Hunter”).
4. Regarding Claim 1, Rellinger discloses of a computer-implemented method for protecting a computer system from ransomware [Figs. 1 and 5], the computer system including a processor and memory to execute a shadow-copy process that invokes system calls to an operating-system kernel [Figs. 5 and 7; Col. 13, lines 50-62], the system calls to write shadow copies of files in the memory to secondary storage [Fig. 5], the method comprising:
receiving, at the shadow-copy process, a first request to delete at least one of the shadow copies in the secondary storage [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy]; wherein the shadow-copy process includes [Fig. 5; Col. 12, lines 9-55];
receiving, at the operating-system kernel, a second request to delete at least one of the shadow copies in the secondary storage [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; request to delete a previously created shadow copy], wherein the operating-system kernel includes an Input/Output Request Packet (IRP) filter to disallow the second request directed from a user layer to the operating-system kernel [Fig. 5; Col. 6, lines 22-34]; and
blocking the first request and the second request [Fig. 5; Col. 12, lines 9-55; both requests can be blocked based on shadow copy access policy].
Rellinger discloses of VSS filters. However, Rellinger does not specifically disclose that the shadow copy process is a Component Object Model (COM) interface.
Hunter discloses of methods for detecting unauthorized manipulations of shadow copies through various deletion methods used by ransomware [Pg. 7]. Hunter further discloses that deletion requests to VSS services can be from COM objects and that malware detection can be based on COM monitoring [Pg. 2, 8, 12-13]. Additionally, Hunter discloses that the kernel level filter can be an IRP filter [Pg. 13]. It would have been obvious to one skilled in the art before the effective date of the current invention to incorporate the teachings of Hunter with Rellinger since both systems detect modifications to shadow copies. The combination with Hunter would enable the Rellinger system to also monitor COM objects to determine if certain requests are authorized. The motivation to do so is to perform the detection process at different layers to improve detection of malware [Hunter; Pgs. 13-14].
5. Regarding Claim 2, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Rellinger further discloses that the shadow-copy process blocks the first request [Col. 8, lines 39-55].
6. Regarding Claim 3, Rellinger, in view of Hunter, discloses the limitations of Claim 2. Rellinger further discloses that the kernel blocks the second request [Fig. 5].
7. Regarding Claim 4, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Hunter further discloses that the at least one of the first request and the second request comprises at least one of a Volume Snapshot Service (VSS) shadow-copy delete request and an overwrite request [Pg. 8, 12-13].
8. Regarding Claim 5, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Rellinger further discloses that the shadow-copy process maintains a record of the shadow copies in secondary storage [Col. 3, lines 31-45].
9. Regarding Claim 6, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Rellinger further discloses that the shadow-copy process comprises a hook to intercept the first request [Col. 8, lines 39-55].
10. Regarding Claim 7, Rellinger, in view of Hunter, discloses the limitations of Claim 6. Hunter further discloses that the shadow-copy process passes the first request to a shadow-copy delete routine, the shadow-copy delete routine includes the hook to intercept the first request, and the hook maintains a record of the shadow copies of the files written to secondary storage [Pgs. 8, 12-13].
11. Regarding Claim 8, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Rellinger further discloses that the shadow-copy process comprises a snapshot service [Col. 3, lines 14-24].
12. Regarding Claim 9, Rellinger discloses of a computer system for preventing ransomware from deleting shadow copies [Figs. 1 and 7], the system comprising:
a user layer executing user-level processes, the user-level processes including a snapshot service to save the shadow copies and ignore first shadow-copy-deletion requests to delete the shadow copies [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy], wherein the snapshot service includes [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55]; and
a kernel layer executing operating-system-level processes, the kernel layer including a filter to ignore second shadow-copy-deletion requests to delete the shadow copies [Fig. 5; Col. 12, lines 9-55; request for a previously created shadow copy blocked by kernel level filter], wherein the filter comprises an Input/Output Request Packet (IRP) filter to disallow the second shadow-copy-deletion requests directed from a user layer to the operating-system kernel [Fig. 5; Col. 6, lines 22-34].
Rellinger discloses of VSS filters. However, Rellinger does not specifically disclose that the shadow copy process is a Component Object Model (COM) interface.
Hunter discloses of methods for detecting unauthorized manipulations of shadow copies through various deletion methods used by ransomware [Pg. 7]. Hunter further discloses that deletion requests to VSS services can be from COM objects and that malware detection can be based on COM monitoring [Pg. 2, 8, 12-13]. Additionally, Hunter discloses that the kernel level filter can be an IRP filter [Pg. 13]. It would have been obvious to one skilled in the art before the effective date of the current invention to incorporate the teachings of Hunter with Rellinger since both systems detect modifications to shadow copies. The combination with Hunter would enable the Rellinger system to also monitor COM objects to determine if certain requests are authorized. The motivation to do so is to perform the detection process at different layers to improve detection of malware [Hunter; Pgs. 13-14].
13. Regarding Claim 10, Rellinger, in view of Hunter, discloses the limitations of Claim 9. Rellinger further discloses that the snapshot service including a hook to intercept the first shadow-copy-deletion requests [Rellinger; Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy].
14. Regarding Claim 11, Rellinger, in view of Hunter, discloses the limitations of Claim 9. Rellinger further discloses that the hook is to ignore the intercepted first shadow-copy deletion requests [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy].
15. Regarding Claim 12, Rellinger, in view of Hunter, discloses the limitations of Claim 11. The combination of Rellinger and Hunter further discloses that the hook is to maintain a record of the shadow copies saved in the kernel layer [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy].
16. Regarding Claim 13, Rellinger, in view of Hunter, discloses the limitations of Claim 9. Rellinger further discloses that the second shadow-copy-deletion requests bypass the snapshot service [Fig. 5; Col. 6, lines 34-37, Col. 12, lines 9-55; VSS request received to delete a previously created shadow copy].
17. Regarding Claim 14, Rellinger, in view of Hunter, discloses the limitations of Claim 13. Hunter further discloses that the second shadow-copy-deletion requests comprise a direct-drive-access command [Pg. 10].
18. Regarding Claim 15, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Rellinger further discloses that the operating-system kernel includes a filter to ignore the second requests [Fig. 5; Col. 12, lines 9-55; request for a previously created shadow copy blocked by kernel level filter].
19. Regarding Claim 16, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Hunter further discloses that the first request is issued using at least one command-line instruction via an administrative process vssadmin exe, a code or script via a utility process wmic.exe, or a COM API [Pgs. 8, 12-13].
20. Regarding Claim 17, Rellinger, in view of Hunter, discloses the limitations of Claim 1. Hunter further discloses that the second request comprises a direct-device-access command [Pg. 10].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAE K KIM whose telephone number is (571)270-1979. The examiner can normally be reached M-F 9:30-5:30.
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 Ortiz-Criado can be reached at 5712727642. 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.
/TAE K KIM/Primary Examiner, Art Unit 2496
Prosecution Insights