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 . The present Non-Final office action is responsive to communication received 1/16/2026.
Claims 1, 5, and 9 have been amended.
Claims 1-17 are pending.
Response to Arguments
Applicant's arguments filed 1/16/2026 have been fully considered but they are not persuasive.
Applicant argues : “With respect to the rejection of Claim 1, Dotan is concerned with the same problem of allowing programs to run after installation, but Dotan operates in a different manner. Dotan intercepts file creations (e.g., the creation of a file containing an executable) and determines if the program that is creating the file is authorized to create files having executables (e.g., an installer that has a flag set for creating files). In Dotan, when this file is created and the trust value is set (e.g., in the Process Trust Table), the new object (e.g., the program being installed) is set to have the trust value (see Dotan FIG. 4). This trust value is inherited by the program being installed, but what happens when a program such as a browser is installed. If the browser inherits the trust value of the installer, then it to is able to install a program (which could contain a virus) and that program will also inherit the trust value of the browser, which is not wanted. There is no disclosure in Dotan of an approved installer, only a program (which can be an installer) that is given a trust value. In such, at the time such installer creates a new program, that program is given (inherits) the same trust value, e.g., if the installer is trusted, then the program being installed is trusted). In applicant's system, an approved installer that creates a file containing a program will result in that file being added to the whitelist by way of scanning the installation file to determine which programs are going to be added and adding such to the whitelist. On the contrary, if using an unapproved installer, the programs will be installed but not put in the whitelist, requiring manual administration as in the past.
The examiner respectfully answers that reference Teal discloses establishing a trust status for an installer, the trust status can be interpreted to read on the approval status for an installer. Teal (column 19 and 20, lines 60-67 and lines 1-4) discusses allowing trust objects associated with scripts or installer objects to establish trust status for introduction of code into a system. This trust status can be seen as approving and “installer”. The establishing of this status helps differentiate between the approved “installers” and un-approved “installers”. The trusted objects are also the ones which are allowed to introduce code into a system.
Applicant argues : "The office action introduces a patent to Teal. Teal adds a flag to certain entries in the whitelist indicating that the associated program is trusted to make changes (e.g., trusted to add an executable to the filesystem). This flag is set for a trusted installer, but not set for untrusted applications such as a browser, so that, when a browser creates a file that is executable, that file is not automatically added to a whitelist. Therefore, with Teal, if a trusted installer installs a program, the file creation of that program is intercepted and being that the flag is set for the program (e.g., the installer) that is creating the file (e.g., the executable), then the program is added to the whitelist, resulting in that program being enabled to run. Applicant's system is different, in that applicant's system does not require the "trusted to make changes" flag in the whitelist along with the added administration required to administer this flag. Instead, applicant's system parses the installation program to find all programs/executables that are to be installed by the installer and adds each to the whitelist, not requiring this flag."
The examiner respectfully answers that reference Dotan discloses the classifying of a program as trusted which allows the program to be installed after an analysis is done. This intercepting and analyzing can be interpreted to be the parsing of a program in order to determine the trustworthiness. Reference Teal discloses the adding of a reference from a whitelist.
Claim interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In claim 1:
when the installer is approved and system for computer security determines that an installation is being performed on the protected device, the system for computer security analyzes an installation file that controls the installation being performed on the protected device and, for each program being installed by the installation, the system for computer security adds an entry to a whitelist that allows execution of the program that is being installed and for each program being deleted by the installation, the system for computer security removes any previous entry from the whitelist;
Dependent claims also recite these functional languages.
In claim 5:
When the installer is approved and when the system for computer security determines that an installation is being performed on the protected device, the system for computer security adds a reference to an installation file that controls the installation being performed on the protected device to a whitelist; the system for computer security detects the reference to the installation file in the whitelist and parses the installation file to determine if the program was installed by the installation.
Dependent claims also recite these functional languages.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-17 are rejected under 35 U.S.C. 103 as being unpatentable over Dotan et al. (US 20050223239) in view of Teal et al. (US 8950007).
Regarding claim 1,
Dotan teaches a system for computer security running on a processor of a protected device having a processor, the system comprising:
[A computer in the present specification is a machine containing a processor and memory, and where the processor is able to execute instructions selected among a given set of instructions. (Dotan et al ., paragraph 3)]
analyzes an installation file that controls the installation being performed on the protected device and determines which program is to be installed by the installer;
[when the OS envelope intercepts a new program, it checks to see whether the program includes the certificate and, if so, it classifies the program as trusted and allows the program to install, run, and use all available resources. (Dotan et al., paragraph 93, trusted program being allowed to be installed)]
[If the client control program determines that the program is trusted, it instructs the OS envelope to install the program on the user computer. (Dotan et al., paragraph 97, wherein the installer is the OS)]
for each program being installed by the installation, the system for computer security adds an entry to a whitelist that allows execution of the program that is being installed
[it has been determined that the program can be installed and run on the user's computer, the client server upload a version of the file to the user's computer, Step 1070, and adds it to the whitelist, i.e., enabling it to run in a trusted mode. (Dotan et al., paragraph 111)]
and after the installation is complete, all of the programs that were installed by the installation are referenced in the whitelist and are allowed to execute.
[If the file is listed on the whitelist, the OS envelope allows the file to be installed on the computer 1020 in a trusted mode. That is, the file may perform anything it needs on the computer and interact with the OS and the network 820. (Dotan et al., paragraph 108, the file is allowed to perform anything such as execute)]
[The Whitelist is a list of programs and files that have been designated as trusted. (Dotan et al., paragraph 108)]
[allow the file to run on the requesting computer, e.g., by adding the file to the whitelist (Dotan et al., paragraph 113)]
Dotan fails to explicitly disclose to determine when an installer is approved and when the installer is approved and when the system for computer security determines that an installation is being performed by the installer on the protected device, and for each program being deleted by the installation, the system for computer security removes any previous entry from the whitelist.
However in an analogous art Teal discloses,
determining when an installer is approved;
[allows trust objects associated with scripts or installer objects (e.g., .msi Windows installer files) to establish trust status for introduction of code into a computational system and for corresponding extensions to an operant whitelist to allow subsequent execution of code so introduced. FIG. 7 then illustrates propagation, via a process tracking cache, of trust attributes from a whitelist entry corresponding to a script or installer object to execution processes and/or threads through successive software component invocations, e.g., via call, spawn, fork/exec and/or interprocess communication mechanisms (Teal et al., column 19 and 20, lines 60-67 and lines 1-4)]
when the installer is approved and the system for computer security determines that an installation is being performed by the installer on the protected device, the system for computer security analyzes an installation file that controls the installation being performed on the protected device and determines which program is to be installed by the installer;
[However, whitelist 605 and the trust objects maintained by process tracking cache 652 also cover scripts and installer packages (e.g., .msi Windows installer files) (Teal et al., column 20 lines 8-11)]
[individual scripts and installer packages, when appropriate (whether based on source, administrator approval or other security policy considerations), may be whitelisted with protection attributes that signify (and convey) trust to make changes (T) (Teal et al., column 20, lines 19-23,the whitelisting of installer packages controls installation of components included in the package, therefore determines which components included in the package are to be installed)]
for each program being deleted by the installer, the system for computer security removes any previous entry from the whitelist
[responsive to execution of a first code instance that seeks to remove an executable sixth code instance from the computational system, checking the whitelist entry that corresponds to the first code instance and, based thereon, removing from the whitelist an allow-type entry corresponding to the sixth code instance only if the whitelist entry that corresponds to the first code instance includes a trust-changes-type protection attribute. (Teal et al., column 6, lines 47-54)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to determine when an installer is approved and when the installer is approved and the system for computer security determines that an installation is being performed by the installer on the protected device, and for each program being deleted by the installation, the system for computer security removes any previous entry from the whitelist, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claim 5,
Dotan teaches a system for computer security running on a processor of a protected device that has a processor, the system comprising:
the system for computer security adds a reference to an installation file that controls the installation being performed
[when the OS envelope intercepts a new program, it checks to see whether the program includes the certificate and, if so, it classifies the program as trusted and allows the program to install, run, and use all available resources. (Dotan et al., paragraph 93, the classifying being interpreted as adding a reference)]
after the installation is complete, when a program attempts to run on the protected device,
[The Whitelist is a list of programs and files that have been designated as trusted. If the file is listed on the whitelist, the OS envelope allows the file to be installed on the computer 1020 in a trusted mode. That is, the file may perform anything it needs on the computer and interact with the OS and the network 820. (Dotan et al., paragraph 108)]
the system for computer security parsed the installation file from the whitelist and parses the installation file to determine if the program was installed by the installation and if the program was installed by the installation, the program is allowed to run.
[when the OS envelope intercepts a new program, it checks to see whether the program includes the certificate and, if so, it classifies the program as trusted and allows the program to install, run, and use all available resources. (Dotan et al., paragraph 93)]
[envelope 930 intercepts a new program, it performs an analysis to determine whether the program is trusted and should be allowed to run on the computer (Dotan et al., paragraph 96)]
Dotan fails to explicitly disclose determine when an installer is approved and when the system for computer security determines that an installation is being performed on the protected device, the system for computer security adds a reference to an installation file that controls the installation being performed on the protected device to a whitelist;
However in an analogous art Teal discloses to determine when an installer is approved;
[allows trust objects associated with scripts or installer objects (e.g., .msi Windows installer files) to establish trust status for introduction of code into a computational system and for corresponding extensions to an operant whitelist to allow subsequent execution of code so introduced. (Teal et al., column 19, lines 60-64)]
when the system for computer security determines that an installation is being performed on the protected device, the system for computer security adds a reference to an installation file that controls the installation being performed on the protected device to a whitelist;
[individual scripts and installer packages, when appropriate (whether based on source, administrator approval or other security policy considerations), may be whitelisted with protection attributes that signify (and convey) trust to make changes (T) (Teal et al., column 20, lines 19-23)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to determine when an installer is approved ad when the system for computer security determines that an installation is being performed on the protected device, the system for computer security adds a reference to an installation file that controls the installation being performed on the protected device to a whitelist, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claim 9,
Dotan teaches A method of synchronizing a whitelist with an installation on a protected device, the method comprising:
detecting an installation by the installer using an installation file;
[server 800 has a client control program installed thereon (Dotan et al., paragraph 97)]
Parsing the installation file, determining which programs are to be installed;
[when the OS envelope intercepts a new program, it checks to see whether the program includes the certificate and, if so, it classifies the program as trusted and allows the program to install, run, and use all available resources. (Dotan et al., paragraph 93)]
[envelope 930 intercepts a new program, it performs an analysis to determine whether the program is trusted and should be allowed to run on the computer (Dotan et al., paragraph 96)]
Dotan fails to explicitly disclose to determine, adding the programs that are being installed by the installer to the whitelist and updating an entry in the whitelist for a program that is being modified by the installer and removing programs that are being deleted by the installer from the whitelist.
However in an analogous art Teal discloses determine when an installer is approved;
[allows trust objects associated with scripts or installer objects (e.g., .msi Windows installer files) to establish trust status for introduction of code into a computational system and for corresponding extensions to an operant whitelist to allow subsequent execution of code so introduced. (Teal et al., column 19, lines 60-64)]
adding the programs that are being installed by the installer to the whitelist [individual scripts and installer packages, when appropriate (whether based on source, administrator approval or other security policy considerations), may be whitelisted with protection attributes that signify (and convey) trust to make changes (T) (Teal et al., column 20, lines 19-23)]
and updating an entry in the whitelist for a program that is being modified by the installer.
[responsive to execution of a first code instance that seeks to remove an executable sixth code instance from the computational system, checking the whitelist entry that corresponds to the first code instance and, based thereon, removing from the whitelist an allow-type entry corresponding to the sixth code instance only if the whitelist entry that corresponds to the first code instance includes a trust-changes-type protection attribute. (Teal et al., column 6, lines 47-54)]
removing programs that are being deleted by the installer from the whitelist;
[responsive to execution of a first code instance that seeks to remove an executable sixth code instance from the computational system, checking the whitelist entry that corresponds to the first code instance and, based thereon, removing from the whitelist an allow-type entry corresponding to the sixth code instance only if the whitelist entry that corresponds to the first code instance includes a trust-changes-type protection attribute. (Teal et al., column 6, lines 47-54)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to determine when an installer is approved. When the installer is approved, adding programs that are being installed by the installer to the whitelist and when the installer is approved, updating an entry in the whitelist for a program that is being modified by the installer and removing programs that are being deleted by the installation from the whitelist, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claims 2, 6, and 15,
Dotan in view of Teal discloses the system for computer security of claim 1, the system for computer security of claim 5, and the method of claim 9, wherein the programs are executables.
[We call "object" any file, passive code, document, script, macro, process, registry key or other system object that needs to be protected by the present invention, or that contains Code that can be interpreted by the OS or any Process. An object containing Code is preferably protected, since it may be executed, and may therefore be used for hostile purposes. (Dotan et al .,paragraph 48)]
Regarding claims 3, 7, and 16,
Dotan in view of Teal discloses the system for computer security of claim 1, the system for computer security of claim 5, and the method of claim 9, wherein the programs are scripts.
[We call "object" any file, passive code, document, script, macro, process, registry key or other system object that needs to be protected by the present invention, or that contains Code that can be interpreted by the OS or any Process. An object containing Code is preferably protected, since it may be executed, and may therefore be used for hostile purposes. (Dotan et al .,paragraph 48)]
Regarding claims 4, 8, and 17,
Dotan in view of Teal discloses the system for computer security of claim 1, the system for computer security of claim 5, and the method of claim 9, wherein the programs are macros.
[We call "object" any file, passive code, document, script, macro, process, registry key or other system object that needs to be protected by the present invention, or that contains Code that can be interpreted by the OS or any Process. An object containing Code is preferably protected, since it may be executed, and may therefore be used for hostile purposes. (Dotan et al .,paragraph 48)]
Regarding claim 10,
Dotan in view of Teal discloses the method of claim 9, wherein the detecting of the installation is performed by finding a signature for a well-known installer in the installation file.
[the whitelist identifies individual ones of the code instances and trust attributes therefor by correspondence with respective files in a file system. In some embodiments, relative to the first code instance, the whitelist encodes: a size of a first file in a file-system from which the first code instance is loaded into memory and executed; a name of the first file; a hash, a digital signature, authentication code, checksum, fingerprint or other cryptographic digest that verifies integrity of the first file; and a trust-changes protection attribute. (Teal et al., column 4, lines 40-54)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to wherein the detecting of the installation is performed by finding a signature for a well-known installer in the installation file, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claim 11,
Dotan in view of Teal discloses the method of claim 9,
wherein the detecting of the installation is performed by reading a certificate of a signed executable that performs the installation with respect to a process privilege of the signed executable to recognize when the signed executable that performs the installation has authorization to modify a filesystem of the protected device.
[By defining a Digital Signature as a Trusted Digital Signature, the original digital signature from the file is copied out by the security software, and optionally its authenticity is verified by navigating the root certificate chain (Teal et al., column 34, lines 6-14)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to wherein the detecting of the installation is performed by reading a certificate of a signed executable that performs the installation with respect to a process privilege of the signed executable to recognize when the signed executable that performs the installation has authorization to modify a filesystem of the protected device, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claim 12,
Dotan in view of Teal discloses the method of claim 9,
wherein the detecting of the installation is performed by analyzing metadata of files that the installation places in a storage of the protected device to correlate the files to previously installed files.
[if the Trusted User wishes to upgrade Adobe Reader on a whitelist system the source and chain of the source of the upgrade and the signature on the installation must be verified and must match the existing Adobe Reader, i.e. the source must be Adobe.com and/or a root certificate on the upgrade must match the certificate on the original installation (Teal et al., column 35, lines 30-45)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to wherein the detecting of the installation is performed by analyzing metadata of files that the installation places in a storage of the protected device to correlate the files to previously installed files, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)]
Regarding claim 13,
Dotan in view of Teal discloses the method of claim 9, wherein the detecting of the installation is performed by manually classifying each possible installer by a researcher.
[From there the process may proceed automatically 1114 or manually 1116. Using manual operation, 1116, a professional Information Technology technician can approve, disapprove, or modify the indicated changes to the black- and whitelists. (Dotan et al., paragraph 123)]
Regarding claim 14,
Dotan in view of Teal discloses the method of claim 9,
wherein the detecting of the installation is performed by providing a custom signing certificate that indicates which programs are approved.
[if the Trusted User wishes to upgrade Adobe Reader on a whitelist system the source and chain of the source of the upgrade and the signature on the installation must be verified and must match the existing Adobe Reader, i.e. the source must be Adobe.com and/or a root certificate on the upgrade must match the certificate on the original installation (Teal et al., column 35, lines 30-45)]
Dotan and Teal are considered to be analogous to the claimed invention because they are in the same field of analyzation of installation scripts. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Dotan to incorporate the teachings of Teal et al. to include to wherein the detecting of the installation is performed by providing a custom signing certificate that indicates which programs are approved, in order to impede and prevent unauthorized software loading on a computer and providing immediate zero hour protection. (Teal et al., column 10, lines 56-67)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
Allen et al. (US 20100115269) discloses an improved checking to determine whether or not an authentication certificate for a software application being loaded onto a device has been revoke.
Vijayvargiya et al. (US 20230041397) discloses checking reputation of executable files in an endpoint device using an integrity verification on a file being scanned to determine whether the file has been altered since being installed in the device.
.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. THIS ACTION IS MADE FINAL. 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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL ELAHIAN whose telephone number is (703) 756-1284. The examiner can normally be reached on Monday – Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at telephone number 571-270-1138. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/D.E./DANIEL ELAHIAN, Examiner, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 3/6/2026