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 .
Detailed action
1. Status of Claims:
Claims 1-20 are pending in this Office Action.
Priority
2. The examiner acknowledges that this present application claims benefit of priority to a Russian Application No. 2024131946 filed on October 24, 2024, and which is incorporated by reference herein.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
3. Claims 1-4, 6, 10-13, 15, and 19-20 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by US 8,959,638 issued to Sallam.
As per claim 1, Sallam teaches a method for blocking malicious activity of legitimate drivers (Sallam: Fig. 3 - blocking suspicious attempt), comprises: collecting information about protected objects and information about drivers loaded in an operating system (OS) of a computer system (Sallam: Col. 7, ll. (25-31) - electronic device that includes memory, one or more applications or drivers, may include an operating system while the operating system may be configured to provide access to system resources of electronic device to applications or drivers.); detecting at least one legitimate driver using information about the drivers loaded into the OS and malicious activity detection rules (Sallam: Col. 9, ll. (3-8) - a suspicious behavior identified on electronic device may be synthesized into a rule for protection server to proactively protect other electronic devices. Such a rule may be determined, for example, based on the number of times that a suspicious driver has been reported); intercepting an Import Address Table (IAT) call and/or an input/output control (IOCTL) system call made by at least one legitimate driver (Sallam: Col. 61, ll. (61-63) - import address tables may contain lists of pointers to functions for one or more other drivers, for the driver to call); determining if the intercepted call is directed to a protected object and triggers a malicious activity detection rule that requires blocking of the intercepted call; and blocking the intercepted call from detected legitimate drivers directed to the protected object based on the triggered malicious activity detection rule (Sallam: Col. 66, ll. (6-22) - Below-0/S security agent 1520 may trap an attempted read of an import address table 1537, and deny any attempts not originating from the driver itself such as NTFS.SYS, the third party from which the address table was imported, or the operating system 1512. In still yet another further example, a function call for accessing a part of a driver may be hooked, allowing malware to gain access to various parts of the electronic device 1501. Below-0/S security agent 1520 may defend against such attacks by protecting the memory in which such function calls reside, trapping attempted writes to add malicious hooks to the system functions. Similarly, below-0/S security agent 1520 may protect the code section of a function against malware that may directly access the code section to inject malicious code. For example, below-0/S security agent 1520 may trap attempted writes to the code of a function housed in Code Section 2, to prevent the addition of injected code).
As per claim 2, Sallam teaches the method of claim 1, wherein the protected object is at least one of: OS kernel memory, namely loaded drivers, physical memory, processes, file objects, and/or registry objects (Sallam: Col. 21, ll. (7-9) - operating system memory may include kernel memory).
As per claim 3, Sallam teaches the method of claim 1, wherein the information about protected objects comprises at least one of: page table for the "SYSTEM" process, file object path mask, path mask to registry objects, process ID, information about the base address of the process, and/or information about the amount of memory allocated to the process (Sallam: Col. 12, ll. (43-45) - security agent may be configured to request that SVMM 216 secure such allocated memory against unauthorized read and write operations).
As per claim 4, Sallam teaches the method of claim 1, wherein the information about the loaded drivers comprises at least one of: driver name, the path to the driver, driver load address, driver PE header fields, driver version, and/or the path to the driver symbol file (Sallam: Fig. 16 - defines different types of drivers for example socket driver, file system driver (driver name)).
As per claim 6, Sallam teaches the method of claim 1, wherein intercepting an IAT call includes: replacing the address of the analyzed function from the malicious activity detection rule with the address of the interceptor function (Sallam: Col. 63, ll. 67 to Col 64, ll. 7 - a below-O/S security agent may be configured to protect the memory space in which the IAT 1722 resides, intercepting write requests and denying such trapped attempts to write to the IAT 1722 unless the writer is verified. Such a verification may include, for example, the operating system loader loading the IAT 1722. A below-O/S security agent may also be configured to trap the execution of any attempted function for writing, changing (replacing), or setting the IAT).
As per claim 10, the claim resembles claim 1 and is rejected under the same rationale.
As per claim 11, the claim resembles claim 2 and is rejected under the same rationale.
As per claim 12, the claim resembles claim 3 and is rejected under the same rationale.
As per claim 13, the claim resembles claim 4 and is rejected under the same rationale.
As per claim 15, the claim resembles claim 6 and is rejected under the same rationale.
As per claim 19, the claim resembles claim 1 and is rejected under the same rationale while Sallam also teaches a non-transitory computer readable medium storing thereon computer executable instructions (Sallam: Claim 20 - a non-transitory computer readable medium; and computer-executable instructions carried on the non-transitory computer readable medium).
As per claim 20, the claim resembles claim 2 and is rejected under the same rationale.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
4. Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 8,959,638 issued to Sallam in view of US 9,781,144 issued to Otvagin et al. (Otvagin).
As per claim 5, Sallam teaches the method of claim 1 however does not explicitly teach wherein the malicious activity detection rules are stored in a rules database included in the OS's system registry.
Otvagin however explicitly teaches wherein the malicious activity detection rules are stored in a rules database included in the OS's system registry (Otvagin: Col. 9, ll. (40-46) - various activities of the object (e.g., file) may be recorded, such as opening of the file, reading of the file, writing of data to an operating system registry, and then those activities may be analyzed, e.g., by the correlation engine, using correlation rules (and indicators) indicating maliciousness to render a decision of malicious
(or not)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Sallam in view of Otvagin to teach wherein the malicious activity detection rules are stored in a rules database included in the OS's system registry. One would be motivated to do so as various activities of the object (e.g., file) may be recorded, such as opening of the file, reading of the file, writing of data to an operating system registry, and then those activities may be analyzed, e.g., by the correlation engine, using correlation rules (and indicators) indicating maliciousness to render a decision of malicious (or not) (Otvagin: Col. 9, ll. (40-46)).
As per claim 14, the claim resembles claim 5 and is rejected under the same rationale.
4. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US 8,959,638 issued to Sallam in view of CN100461197C issued to Yu et al. (Yu).
As per claim 7, Sallam teaches the method of claim 1 however does not explicitly teach wherein intercepting an IOCTL system call includes splicing to the entry point of the detected legitimate driver.
Yu however explicitly teaches wherein intercepting an IOCTL system call includes splicing to the entry point of the detected legitimate driver (Yu: claim 1 - File monitoring is installed in the operating system as a driver. The system communicates with the driver through the DeviceIoControl WINDOWS API to obtain all operations on the file, and then determines whether the operation is performed by malicious code based on the process ID and the steps to determine whether a program is malicious include: Step (1): Modify the first code byte of each API that needs to be intercepted to 0xCC, and save the original code byte (splicing to the entry point based on ¶ 0047 of the specification of the application)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Sallam in view of Yu to teach intercepting an IOCTL system call includes splicing to the entry point of the detected legitimate driver. One would be motivated to do so as File monitoring is installed in the operating system as a driver. The system communicates with the driver through the DeviceIoControl WINDOWS API to obtain all operations on the file, and then determines whether the operation is performed by malicious code based on the process ID and the steps to determine whether a program is malicious include: Modify the first code byte of each API that needs to be intercepted to 0xCC, and save the original code byte (Yu: claim 1).
As per claim 16, the claim resembles claim 7 and is rejected under the same rationale.
5. Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 8,959,638 issued to Sallam in view of US 8,230,509 issued to Gassoway.
As per claim 8, Sallam teaches the method of claim 1 however does not explicitly teach wherein intercepting an IOCTL system call includes: intercepting OS registry operations in the context of the "SYSTEM" process, detecting an operation with the RegNtPostQueryKeyName type, extracting the key from the registry path of the detected operation, retrieving a device object based on the extracted key, and/or accessing incoming IOCTL calls by intercepting the Driverinit function.
Gassoway however explicitly teaches wherein intercepting an IOCTL system call includes: intercepting OS registry operations in the context of the "SYSTEM" process, detecting an operation with the RegNtPostQueryKeyName type, extracting the key from the registry path of the detected operation, retrieving a device object based on the extracted key, and/or accessing incoming IOCTL calls by intercepting the Driverinit function (Gassoway: Col. 2, ll. (59-65) - a registry object may include a registry key or a registry value within a computer system and a rule's path may include a regular expression that defines the specific object (e.g., directory, file, registry key, registry value, or other object) that the rule applies to (retrieving a device object based on the extracted key)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Sallam in view of Gassoway to teach wherein intercepting an IOCTL system call includes: intercepting OS registry operations in the context of the "SYSTEM" process, detecting an operation with the RegNtPostQueryKeyName type, extracting the key from the registry path of the detected operation, retrieving a device object based on the extracted key, and/or accessing incoming IOCTL calls by intercepting the Driverinit function. One would be motivated to do so as a registry object may include a registry key or a registry value within a computer system and a rule's path may include a regular expression that defines the specific object (e.g., registry key) (retrieving a device object based on the extracted key) (Gassoway: Col. 2, ll. (59-65)).
As per claim 9, Sallam teaches the method of claim 1 however does not explicitly teach wherein intercepting an IOCTL system call includes, retrieving an object of a legitimate driver by iterating over the services in the system registry and comparing the path to the legitimate driver with the ImagePath value of the said services.
Gassoway however explicitly teaches wherein intercepting an IOCTL system call includes, retrieving an object of a legitimate driver by iterating over the services in the system registry and comparing the path to the legitimate driver with the ImagePath value of the said services (Gassoway: Col. 7, ll. (9-15) - a rule's path may include a regular expression that defines the specific object (e.g., directory, file, registry key, registry value, or other object) (ImagePath) that the rule applies to. For example, if path 207 of rule 200 specified "C:\programfiles\objl.doc", then rule 200 applies to the object within computer system 100 to which that path pointed (object: obj1.doc, in directory: programfiles, on the C drive)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Sallam in view of Gassoway to teach wherein intercepting an IOCTL system call includes, retrieving an object of a legitimate driver by iterating over the services in the system registry and comparing the path to the legitimate driver with the ImagePath value of the said services. One would be motivated to do so as a rule's path may include a regular expression that defines the specific object (e.g., directory, file, registry key, registry value, or other object) (ImagePath) that the rule applies to. For example, if path 207 of rule 200 specified "C:\programfiles\objl.doc", then rule 200 applies to the object within computer system 100 to which that path pointed (object: obj1.doc, in directory: programfiles, on the C drive) (Gassoway: Col. 7, ll. (9-15)).
As per claim 17, the claim resembles claim 8 and is rejected under the same rationale.
As per claim 18, the claim resembles claim 9 and is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SM AZIZUR RAHMAN whose telephone number is (571) 270-7360. The examiner can normally be reached on M-F Telework;
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SM A RAHMAN/Primary Examiner, Art Unit 2434
Prosecution Insights