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 .
Specification
The specification filed on June 16, 2026 is accepted.
Drawings
The drawings filed on June 16, 2026 are accepted.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/11/2026 was filed after the mailing date of the application no. 19/239319. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No.12367281. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of instant application are effectively subset of the claims of the U.S. Patent No.12367281, the later claims is/are obvious over, or anticipated by the earlier claims. In re Longi, 759 F.2d at 896,225 USPQ at 651 (affirming a holding obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ELI LILLY AND COMPANY VBARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ONPETITION FOR REHEARING EN BANC(DECIDED: May 30, 2001).
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, 4, 6, 12, 14, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hartnett et al (hereinafter Hartnett) (US 20190012460) in view of Fortier (US 20120317645).
Regarding claim 1, 9 and 17 Hartnett teaches a method, comprising: (Hartnett on [0004] teaches method for detecting anomalies);
A non-transitory computer-readable storage medium comprising stored instructions that, when executed by a computing system, cause the computing system to perform operations including: (Hartnett on [0005] teaches a non-transitory computer-readable storage medium stores instructions that when executed by a processor causes the processor to execute method);
A computing system comprising: one or more processors; and one or more non-transitory computer-readable storage media comprising stored instructions that, when executed by the one or more processors, cause the computing system to perform operations including: (Hartnett on [0005-0006] teaches a computer system includes a processor and a non-transitory computer-readable storage medium that stores instructions for executing the method);
statically analyzing an image file corresponding to an application to identify a software package included in the image file (Hartnett on [0014] teaches detects anomalous files based on their static characteristics and thus need not execute the files to perform the detection. In other words, the protection application processes “static” files rather than running applications. See on [0026] teaches performing a static analysis of the files. See on [0022-0024] teaches the file may be image and file may be executed or installed on device i.e., software-based file);
determining that the software package includes a vulnerability (Hartnett on [0022] teaches determine whether a given file is potentially malicious, the protection application 136 selects a model to generate an anomaly score for the given file that represents a measure of dissimilarity between the given file and known clean files. Files that are highly anomalous relative to the clean files (e.g., have an anomaly score exceeding a predefined threshold) are identified as being potentially malicious. See on [0030-0032] teaches the file classifier 144 compares the anomaly scores against one or more threshold scores to classify the files. In one embodiment, the file classifier 144 classifies a file as malicious responsive to determining that an anomaly score for the file is greater than a threshold score);
classifying the vulnerability with a risk level, Hartnett on [0030-0032] teaches the file classifier 144 compares the anomaly scores against one or more threshold scores to classify the files. In one embodiment, the file classifier 144 classifies a file as malicious responsive to determining that an anomaly score for the file is greater than a threshold score. See on [0034] teaches risk severity level proportional to the anomaly score of the malicious file. See on [claim 5] teaches classifying the file as anomalous, the notification indicating risk severity level proportional to the anomaly score);
and performing, based on the risk level, an action to mitigate the vulnerability (Hartnett on [0022] teaches generating the anomaly score using the model, the protection application 136 may access the security server 105 via the network 110 to perform a check against a whitelist or blacklist prior to classifying the file as being malicious or clean and taking appropriate remedial action. See on [0034] teaches The remediation module 150 remediates files that are classified as malicious by the file classifier 144. In particular, the remediation module 150 may perform remediation by removing a malicious file from the client 120, quarantining the malicious file on the client 120, or providing a notification to a user of the client 120 indicating that the malicious file is suspected to be associated with malware. The notification may also include information about the malicious file such as a file source or risk severity level proportional to the anomaly score of the malicious file. In one embodiment, the remediation module 150 provides a user of the client 120 with an option to remove a suspected malicious file).
Although Hartnett teaches classifying the vulnerability but fails to teach wherein the classifying is based on whether the vulnerability is loaded into memory of a compute instance allocated for the application, however Fortier from analogous art teaches
wherein the classifying is based on whether the vulnerability is loaded into memory of a compute instance allocated for the application (Fortier Fig 3 block 320, 340 and text on [0038-0040] teaches the system performs dynamic analysis on the identified application. The dynamic analysis accesses one or more application binary modules loaded in memory and determines what actions are performed by the binary code stored in the module. The actions may include some actions that are not considered harmful or interesting, such as performing internal calculations, and other actions that are potentially harmful, such as accessing data, sending information over the Internet or other network, accessing device hardware, and so forth. Dynamic analysis may identify application behavior not identified during static analysis. Further teaches the system determines a threat level to assign to the application based on the dynamic analysis and detected behavior of the application. The threat level may include a numerical or visual score or another indication of how much the user should worry about installing the application. The threat level may include a list of categories of or actual behavior performed by the application, as detected during static analysis).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Fortier into the teaching of Hartnett by classifying based on whether the vulnerability is loaded into memory of a compute instance. One would be motivated to do so in order to identify potential threat associated with application statically and dynamically based on associated threat level (Fortier [0001-0003]).
Regarding claim 2, 10 and 18 the combination of Hartnett and Fortier teaches all the limitations of claims 1, 9 and 17 respectively, Hartnett further teaches wherein statically analyzing the image file comprises: analyzing at least one or more of a header section, a code segment, or a data segment of the image file to identify the software package included in of the image file (Hartnett on [0024 and 0026] teaches analyzing the file including header section and data section of the file).
Regarding claim 3 and 11 the combination of Hartnett and Fortier teaches all the limitations of claims 1 and 9 respectively, Fortier further teaches wherein the risk level is selected from a plurality of risk categories (Fortier on [0020] teaches the system determines a score that indicates the threat assessment level. The score may be numeric, a series of stars for a rating, a stoplight (e.g., red=bad, yellow=caution, green=okay), or any other indication to the user).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Fortier into the teaching of Hartnett by classifying based on whether the vulnerability is loaded into memory of a compute instance. One would be motivated to do so in order to identify potential threat associated with application statically and dynamically based on associated threat level (Fortier [0001-0003]).
Regarding claim 4, 12 and 19 the combination of Hartnett and Fortier teaches all the limitations of claims 3, 11 and 17 respectively, Fortier further teaches wherein the risk level is a first level responsive to the vulnerability not being loaded into memory and a second level, higher than the first level, responsive to the vulnerability being loaded into memory (Fortier on [0020] teaches the system may determine the application's threat level in stages. For example, at a first installation request, the system 100 may perform static analysis (i.e., vulnerability not loaded in memory) to avoid running the unknown application and report to the user a threat assessment level based on static analysis. Then, upon running the application, the system may perform dynamic analysis (i.e., vulnerability loaded in memory),the system determines a score that indicates the threat assessment level. The score may be numeric, a series of stars for a rating, a stoplight (e.g., red=bad, yellow=caution, green=okay), or any other indication to the user).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Fortier into the teaching of Hartnett by classifying based on whether the vulnerability is loaded into memory of a compute instance. One would be motivated to do so in order to identify potential threat associated with application statically and dynamically based on associated threat level (Fortier [0001-0003]).
Regarding claim 5 and 13 the combination of Hartnett and Fortier teaches all the limitations of claims 1 and 9 respectively, Hartnett further teaches wherein the compute instance comprises at least one of: a server; a virtual machine executing on the server; a computing node in a cloud-based environment; or an Internet-of-Things (IoT) device (Hartnett on [0018] teaches Each client 120 comprises one or more computing devices capable of processing data as well as transmitting and receiving data via a network 110. For example, a client 120 may be a desktop computer, a laptop computer, a mobile phone, a tablet computing device, an Internet of Things (IoT) device, or any other device having computing and data communication capabilities).
Regarding claim 6 and 14 the combination of Hartnett and Fortier teaches all the limitations of claims 1 and 9 respectively, Hartnett further teaches wherein performing the action to mitigate the malicious code comprises: providing a notification to a user; stopping at least one of the computing process or the compute instance; suspending at least one of the computing process or the compute instance; or restarting at least one of the computing process or the compute instance (Hartnett on [0022] teaches generating the anomaly score using the model, the protection application 136 may access the security server 105 via the network 110 to perform a check against a whitelist or blacklist prior to classifying the file as being malicious or clean and taking appropriate remedial action. See on [0034] teaches The remediation module 150 remediates files that are classified as malicious by the file classifier 144. In particular, the remediation module 150 may perform remediation by removing a malicious file from the client 120, quarantining the malicious file on the client 120, or providing a notification to a user of the client 120 indicating that the malicious file is suspected to be associated with malware. The notification may also include information about the malicious file such as a file source or risk severity level proportional to the anomaly score of the malicious file. In one embodiment, the remediation module 150 provides a user of the client 120 with an option to remove a suspected malicious file).
Regarding claim 7, 15 and 20 the combination of Hartnett and Fortier teaches all the limitations of claims 1, 9 and 17 respectively, Hartnett further teaches wherein determining that the software package includes the vulnerability comprises comparing the software package to a blacklist of software packages known to include vulnerabilities (Hartnett on [0016] teaches the security server 105 includes a database of information about known malware (e.g., a blacklist), clean files (e.g., a whitelist), or both. Further, the security server 105 may lookup files in whitelists or blacklists of the database and provide results of the lookup to clients 120. See on [0022] teaches , the protection application 136 may access the security server 105 via the network 110 to perform a check against a whitelist or blacklist prior to classifying the file as being malicious or clean and taking appropriate remedial action, if necessary. See on [0032-0034] teaches the file classifier 144 provides the file to the security server 105 for comparison against a cloud blacklist of known malware files. The file classifier 144 classifies the file as malicious responsive to receiving an indication that the file is on the cloud blacklist and classifies the file as clean if it is not on the blacklist).
Regarding claim 8 and 16 the combination of Hartnett and Fortier teaches all the limitations of claims 1 and 9 respectively, Fortier further teaches wherein the method further comprises a data miner: reading contents of the memory of the compute instance; and determining that the package is loaded into the memory of the compute instance (Fortier on [0038 and 0047] teaches the system performs dynamic analysis on the identified application. The dynamic analysis accesses one or more application binary modules loaded in memory and determines what actions are performed by the binary code stored in the module).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Fortier into the teaching of Hartnett by classifying based on whether the vulnerability is loaded into memory of a compute instance. One would be motivated to do so in order to identify potential threat associated with application statically and dynamically based on associated threat level (Fortier [0001-0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Huang et al (US 20200210575) is directed towards a scoring system of how dangerous an application is based on behavioral inspection of the application. Upon detecting installation of an application or first execution of the application, the application safety system performs static analysis before the new application is executed by the operating system. Static analysis can identify many types of behavior of an application, and the system can alert the user to whether the application saves and modifies files, connects to the Internet, uses email, or performs other actions.
Zhang (US 20180114018) is directed towards systems and methods for malware detection and classification based on semantic analysis of memory dumps of malware are provided, a malware detector running within a computer system causes a sample file to be executed within a target process that is monitored by a process monitor of the malware detector. One or more memory dumps associated with the sample file are captured by the process monitor.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights