DETAILED 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 .
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.
Claim(s) 1 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over YAMAMOTO et al., US-20160224791-A1 (hereinafter “YAMAMOTO ‘791”) in view of STOPEL et al., US-20210192058-A1 (hereinafter “STOPEL ‘058”).
Per claim 1 (independent):
YAMAMOTO ‘791 discloses: An automatic system updating apparatus (FIG. 1, [0057], a process testing apparatus 100), comprising:
a storage, being configured to store an allowlist (FIG. 1, [0070], An install list 104 (an allowlist) is a list of executable files installed on a computer (or computer system) not infected with malware); and
a processor, being electrically connected to the storage, and being configured to perform operations comprising:
determining whether at least one pending event intercepted from a file system belongs to a system update event based on a plurality of update rules;
obtaining at least one executable file corresponding to the at least one pending event in response to the at least one pending event belonging to the system update event, wherein the at least one executable file is not included in the allowlist; and
adding the at least one executable file to the allowlist based on a security setting
(FIG. 8, [0141], the template memory extraction processing (S120) – by the template memory extracting unit 120 in the process testing apparatus 100 of FIG. 1; [0143], In S121, based on the executable file information 103 (corresponding to the at least one executable file) and the install list 104 (the allowlist), the install unit 121 determines whether or not the target executable file (the at least one executable file) has been installed on the template system (including a file system, as recited in [0071], “The computer (or computer system) not infected with malware will hereinafter be referred to as a "template system"”, and [0157], “The executable file can be installed on the template system by controlling an OS (guest OS) of a virtual machine functioning as the template system”, in other words, the executable file is installed into a filesystem of a guest operating system running on the template system). That is, the install unit 121 determines whether or not it is necessary to install the target executable file on the template system; [0145], If information that is identical to the executable file information 103 (as shown in FIG. 6, the executable file information 103 provides a plurality of update rules, including a file path, a version, and a messaging digest) is not included in the install list 104 (i.e., the at least one executable file is not included in the allowlist), the install unit 121 determines that the target executable file has not been installed on the template system; [0148], If the target executable file has not been installed on the template system, that is, if it is necessary to install the target executable file on the template system; it is noted that as shown in FIG. 8, transition from S121 to S122 requires satisfaction of “install required” condition. This indicates that the executable file is not installed directly into the file system, but instead remains pending while an intercepted event is evaluated until a comparison result of the executable file information is obtained by looking into the conditions of the executable file information, including a file path, a version, and a messaging digest – based on a plurality of update rules. Furthermore, when a new guest OS is installed via a virtual machine, programs newly installed on the guest OS system can be regarded as a system update event; [0151], In S123, the install unit 121 performs a virus test on the executable file (based on a security setting); [0154], If it is determined that the executable file is not infected with a virus, the processing proceeds to S124; [0155], In S124, the install unit 121 installs the executable file obtained in S122 on the template system; [0159], In S125, the install unit 121 updates the install list 104 by adding or overwriting with information on the executable file installed in S124 – adding the at least one executable file to the allowlist based on the security setting).
YAMAMOTO ‘791 does not disclose but STOPEL ‘058 discloses: generating at least one executable file corresponding to the at least one pending event in response to the at least one pending event belonging to the system update event (FIG. 6, [0076], a method for profiling container images and enforcing secured execution of the respective APP containers; [0077], At S610, an event indicating that a container image should be scanned is received (in response to the at least one pending event belonging to the system update event); [0079], At optional S630, the contents of the container image are extracted (generating at least one executable file corresponding to the at least one pending event ); [0052], the detector container 315 is configured to parse the entry-point script to identify spawned process(es) designated therein. Then, the executable file of each such spawned process is searched in the container image 301-C, that is, extracting the contents of the container image yields executable files corresponding to one or more processes spawned from the container. The detector container 315 is configured to create a unique signature for each executable file ... Each generated signature is saved with the security profile of the container image 301-C together with the name of the respective spawned process; [0080], At S640, the contents of the container image are analyzed to generate a new security profile ... the security profile is generated to include at least a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable processes, or a combination thereof; [0082], At S660, the method transitions to an enforcement mode, upon receiving an event indicative of instantiation, running, or both, of a new APP container).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 with the security profiling of an executable file extracted from a spawned process of a container image by using characteristics such as signatures of executable processes as taught by STOPEL ‘058 because it would provide a solution that would secure the execution of software containers [0016]-[0018]. Additionally, STOPEL ‘058 is analogous to the claimed invention because it teaches profiling container images and enforcing secured execution of the respective APP containers [0076].
Per claim 10 (dependent on claim 1):
YAMAMOTO ‘791 in view of STOPEL ‘058 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
YAMAMOTO ‘791 discloses: The automatic system updating apparatus of claim 1, wherein the update rules comprise at least one of a process update rule, a system service update rule, a command line update rule, and a package file update rule or a combination thereof (FIG. 8, [0145], If information that is identical to the executable file information 103 (as shown in FIG. 6, the executable file information provides a plurality of update rules, including a file path, a version, and a messaging digest – a process update rule, a system service update rule, a command line update rule, and a package file update rule or a combination thereof) is not included in the install list 104, the install unit 121 determines that the target executable file has not been installed on the template system).
Claim(s) 2-3 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell, US-20090165131-A1 (hereinafter “Treadwell ‘131”) and Cheng et al., US-20240346131-A1 (hereinafter “Cheng ‘131”).
Per claim 2 (dependent on claim 1):
YAMAMOTO ‘791 in view of STOPEL ‘058 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
YAMAMOTO ‘791 in view of STOPEL ‘058 does not disclose but Treadwell ‘131 discloses: The automatic system updating apparatus of claim 1, wherein the security setting corresponds to one of a plurality of security levels, and each of the security levels corresponds to allow or prohibit an execution of a file (FIG. 3, [0025], preventing malicious code execution (through the security setting) ... in block 301, execution of a file may be requested ... In block 304 the file may be scanned for a risk and a risk score (a plurality of security levels) assigned to the file based on the scanning. In block 305 it may be determined if the file has a low risk score (a security level) and if so, in block 306 the file may be allowed to execute. If the file does not have a low score it may be determined in block 307 whether the file has a medium risk score (a security level) and if so, then in block 308 a prompt may be generated asking whether to allow execution of the file – allow or prohibit an execution of a file).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 with the allowance or prohibition of an execution of a file based on a risk score for preventing malicious code execution as taught by Treadwell ‘131 because malicious software detection can be performed effectively and flexibly without reliance on signature [0020]. Additionally, Treadwell ‘131 is analogous to the claimed invention because it teaches preventing malicious code execution, includes detecting a request for execution of a file [ABSTRACT].
YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 does not disclose but Cheng ‘131 discloses: the security setting corresponds to an allowlist update judgment (FIG. 8, [0069], the installation 200 is any of a new installation, a de-installation, or an installation of an update; [0071], If the installation is approved 204, the installation is allowed 208. The computer security system software 17 (executing the security setting) loads 250 the install file 52 and parses 252 the install file 52 to determine what programs (e.g., executables 56, scripts, macros, etc.) are being installed (for an allowlist update judgement); [0072], If the object is being added 264, the object (e.g., program) is added 268 to the whitelist 19 – the allowlist).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 with the addition of a program to the whitelist in response to determining what programs are being installed via the computer security system software as taught by Cheng ‘131 because the system would improve accuracy by reducing the addition of suspicious programs to the whitelist while assuring that all required programs are properly added to the whitelist, thereby improving end-user satisfaction [0007]. Additionally, Cheng ‘131 is analogous to the claimed invention because it teaches the computer security system software 17 includes whitelisting during installation [0032].
Per claim 3 (dependent on claim 2):
YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 and Cheng ‘131 discloses the elements detailed in the rejection of claim 2 above, incorporated herein by reference.
YAMAMOTO ‘791 in view of Treadwell ‘131 and Cheng ‘131 does not disclose but STOPEL ‘058 discloses: the at least one executable file generated by the at least one pending event (FIG. 6, [0079], At optional S630, the contents of the container image are extracted; [0052], the detector container 315 is configured to parse the entry-point script to identify spawned process(es) designated therein. Then, the executable file of each such spawned process is searched in the container image 301-C. The detector container 315 is configured to create a unique signature for each executable file (the at least one executable file generated by the at least one pending event) ... Each generated signature is saved with the security profile of the container image 301-C together with the name of the respective spawned process; [0082], At S660, the method transitions to an enforcement mode, upon receiving an event indicative of instantiation, running, or both, of a new APP container).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of Treadwell ‘131 and Cheng ‘131 with the security profiling of an executable file extracted from a spawned process of a container image by using characteristics such as signatures of executable processes as taught by STOPEL ‘058 because it would provide a solution that would secure the execution of software containers [0016]-[0018].
YAMAMOTO ‘791 in view of STOPEL ‘058 and Cheng ‘131 does not disclose but Treadwell ‘131 discloses: The automatic system updating apparatus of claim 2, wherein when the security setting corresponds to a first security level of the security levels, the processor further performs the following operations:
allowing or prohibiting the execution of the at least one executable file
(FIG. 3, [0025], preventing malicious code execution (through the security setting) ... in block 301, execution of a file may be requested ... In block 304 the file may be scanned for a risk and a risk score (a first security level of the security levels) assigned to the file based on the scanning. In block 305 it may be determined if the file has a low risk score and if so, in block 306 the file may be allowed to execute. If the file does not have a low score it may be determined in block 307 whether the file has a medium risk score and if so, then in block 308 a prompt may be generated asking whether to allow execution of the file – allowing or prohibiting the execution of the at least one executable file).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 and Cheng ‘131 with the allowance or prohibition an execution of a file based on a risk score for preventing malicious code execution as taught by Treadwell ‘131 because malicious software detection can be performed effectively and flexibly without reliance on signature [0020].
YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 does not disclose but Cheng ‘131 discloses: adding the at least one executable file to the allowlist (FIG. 8, [0069], the installation 200 is any of a new installation, a de-installation, or an installation of an update; [0071], If the installation is approved 204, the installation is allowed 208. The computer security system software 17 loads 250 the install file 52 and parses 252 the install file 52 to determine what programs (e.g., executables, scripts, macros, etc.) are being installed; [0072], If the object is being added 264, the object (e.g., program) is added 268 to the whitelist 19 – adding the at least one executable file to the allowlist).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 with the addition of a program to the whitelist in response to determining what programs are being installed via the computer security system software as taught by Cheng ‘131 because the system would improve accuracy by reducing the addition of suspicious programs to the whitelist while assuring that all required programs are properly added to the whitelist, thereby improving end-user satisfaction [0007].
Per claim 5 (dependent on claim 2):
YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 and Cheng ‘131 discloses the elements detailed in the rejection of claim 2 above, incorporated herein by reference.
YAMAMOTO ‘791 in view of Treadwell ‘131 and Cheng ‘131 does not disclose but STOPEL ‘058 discloses: the at least one executable file generated by the at least one pending event (FIG. 6, [0079], At optional S630, the contents of the container image are extracted; [0052], the detector container 315 is configured to parse the entry-point script to identify spawned process(es) designated therein. Then, the executable file of each such spawned process is searched in the container image 301-C. The detector container 315 is configured to create a unique signature for each executable file (the at least one executable file generated by the at least one pending event) ... Each generated signature is saved with the security profile of the container image 301-C together with the name of the respective spawned process; [0082], At S660, the method transitions to an enforcement mode, upon receiving an event indicative of instantiation, running, or both, of a new APP container).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of Treadwell ‘131 and Cheng ‘131 with the security profiling of an executable file extracted from a spawned process of a container image by using characteristics such as signatures of executable processes as taught by STOPEL ‘058 because it would provide a solution that would secure the execution of software containers [0016]-[0018].
YAMAMOTO ‘791 in view of STOPEL ‘058 and Cheng ‘131 does not disclose but Treadwell ‘131 discloses: The automatic system updating apparatus of claim 2, wherein when the security setting corresponds to a third security level of the security levels, the processor further performs the following operations:
allowing or prohibiting the execution of the at least one executable file
(FIG. 3, [0025], preventing malicious code execution (through the security setting) ... in block 301, execution of a file may be requested ... In block 304 the file may be scanned for a risk and a risk score (a third security level of the security levels) assigned to the file based on the scanning. In block 305 it may be determined if the file has a low risk score and if so, in block 306 the file may be allowed to execute. If the file does not have a low score it may be determined in block 307 whether the file has a medium risk score and if so, then in block 308 a prompt may be generated asking whether to allow execution of the file – allowing or prohibiting the execution of the at least one executable file).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 and Cheng ‘131 with the allowance or prohibition an execution of a file based on a risk score for preventing malicious code execution as taught by Treadwell ‘131 because malicious software detection can be performed effectively and flexibly without reliance on signature [0020].
YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 does not disclose but Cheng ‘131 discloses: not adding the at least one executable file to the allowlist (FIG. 8, [0069], the installation 200 is any of a new installation, a de-installation, or an installation of an update; [0071], If the installation is approved 204, the installation is allowed 208. The computer security system software 17 loads 250 the install file 52 and parses 252 the install file 52 to determine what programs (e.g., executables, scripts, macros, etc.) are being installed; [0072], If the object is being added 264, the object (e.g., program) is added 268 to the whitelist 19 – not adding the at least one executable file to the allowlist; according to [0032], a program is added to a whitelist only if the computer security system 17 determines that the program is malware-free).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 and Treadwell ‘131 with the addition of a program to the whitelist in response to determining what programs are being installed via the computer security system software as taught by Cheng ‘131 because the system would improve accuracy by reducing the addition of suspicious programs to the whitelist while assuring that all required programs are properly added to the whitelist, thereby improving end-user satisfaction [0007].
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over YAMAMOTO ‘791 in view of STOPEL ‘058 and VERMA et al., US-20240303062-A1 (hereinafter “VERMA ‘062”).
Per claim 6 (dependent on claim 1):
YAMAMOTO ‘791 in view of STOPEL ‘058 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
YAMAMOTO ‘791 in view of STOPEL ‘058 does not disclose but VERMA ‘062 discloses: The automatic system updating apparatus of claim 1, wherein the processor is further configured to perform the following operations:
obtaining a plurality of historical system update events from the file system; and
extracting a historical behavior characteristics from each of the historical system update events to generate the update rules
(FIG. 4A, [0057], The policy service 307 will provide other factors on which the rollout service 301 can determine an optimal deployment policy (generate the update rules). For example, as noted above, different updates may have different associated levels of risk. The policy database 308 (in which a plurality of historical system update events from the file system are obtained) can include historical data of past rollouts in the cloud service and policy statements or rules set by an administrator (extracting a historical behavior characteristics from each of the historical system update events) ... If the level of risk is high, the policy service 307 will signal to the rollout service to implement a more gradual rollout with smaller initial segments of the userbase (generate the update rules) ... Based on the historical data and policy statements in the database 308, the policy service 307 may also signal the rollout service 301 as to how much time should be waited to detect for regressions between stages of a rollout (generate the update rules)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 with the roll out of updates to a system based on the historical data and policy statements in the database as taught by VERMA ‘062 because the system would safely deploy changes to a cloud service to identify, quantify and, sometimes, mitigate regressions that occur [0023]. Additionally, VERMA ‘062 is analogous to the claimed invention because it teaches a rollout service that deploys a series of updates to a cloud service while minimizing an impact of a regression [ABSTRACT].
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over YAMAMOTO ‘791 in view of STOPEL ‘058 and Chhetri et al., US-20230325501-A1 (hereinafter “Chhetri ‘501”).
Per claim 9 (dependent on claim 1):
YAMAMOTO ‘791 in view of STOPEL ‘058 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
YAMAMOTO ‘791 discloses: The automatic system updating apparatus of claim 1, wherein the processor is further configured to perform the following operations:
calculating a file fingerprint corresponding to each of the at least one executable file based on the at least one executable file
([0128], The executable file information 103 includes a name, a path, a version, a message digest, and so on of the target executable file (see FIG. 5). Note that the memory image extracting unit 112 calculates the message digest (calculating a file fingerprint corresponding to each of the at least one executable file) by computing a hash function such as MDS, SHA1, or SHA256; FIG. 8, [0145], If information that is identical to the executable file information 103 (including a file fingerprint) is not included in the install list 104).
YAMAMOTO ‘791 in view of STOPEL ‘058 does not disclose but Chhetri ‘501 discloses: adding the file fingerprint corresponding to each of the at least one executable file to the allowlist (FIG. 1, [0065], an update to a whitelist (the allowlist) of files (e.g., corresponding to non-malicious files) such as in the case that the file is deemed to be benign. In some embodiments, malicious file detector 170 sends a hash or signature corresponding to the file (the file fingerprint corresponding to each of the at least one executable file) in connection with the indication that the file is malicious or benign. The security entity or endpoint may compute a hash or signature for a file and perform a lookup against a mapping of hashes/signatures to indications of whether files are malicious/benign (e.g., query a whitelist and/or a blacklist – a match cannot be identified unless the signature of the executable file has been added to the whitelist, that is, adding the file fingerprint ... to the allowlist).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified YAMAMOTO ‘791 in view of STOPEL ‘058 with the addition of file hash/signatures to a whitelist for indicating that a file is malicious or benign as taught by Chhetri ‘501 because the system would improve detection of malicious files. Additionally, Chhetri ‘501 is analogous to the claimed invention because it teaches security platform 140 can provide a variety of services, including performing static and dynamic analysis on malware samples, providing a list of signatures of known-malicious files to data appliances [0046].
Allowable Subject Matter
Claim(s) 11-20 is/are allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 11, the prior art of record (YAMAMOTO ‘791 in view of STOPEL ‘058) does not disclose: “mounting and scanning an environment repairing image file generated from executing an update execution file or command corresponding to the at least one pending event; and
adding a plurality of mapping executable files extracted from the environment repairing image file to the allowlist, wherein the mapping executable files are not included in the allowlist” in the recited context.
The claimed subject matter can be reasonably construed as requiring that, in response to a pending event and in accordance with a given command, “an environment repairing image file” is generated and mounted to a file system, and that a plurality of executable files to be spawned via the mounted image file are added to an allowlist. While YAMAMOTO ‘791 teaches adding executable files to an installation list, it fails to disclose or suggest generating, mounting, and scanning the image file associated with environment repair or system recovery as an execution environment for spawning executable files. STOPEL ‘058 discloses profiling executable files to be executed from an image file; however, it does not teach or suggest that the image file is associated with system repair or environment recovery, nor does it disclose or suggest “adding a plurality of executable files to an allowlist.”
Dependent claims 12-20 are allowed in view of their respective dependence from claims.
Claim(s) 4 and 7-8 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499