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 6/9/2026.
Claims 1-5 and 9 have been amended.
Claims 1-17 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/9/2026 has been entered. This Action is made Non-FINAL.
Response to Arguments
Applicant's arguments filed 6/9/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). This is difference than the applicant’s “…before the installation is performed, the system for computer security parses an installation file that controls the installation being performed on the protected device and determines which programs are to be installed by the installer…” There is no such parsing performed by Dotan (nor teal) as Dotan operates by intercepting file creations performed by the installer as the files are being installed, not before the files are installed.
The examiner respectfully answers that reference Dotan [0097] discloses the intercepting and performing an analysis on a new program to determine whether or not it is trusted enough to be installed. The paragraph goes on to disclose that if the determination that the program is trusted has been made, then the instruction to the OS to allow the installation is made. This shows that the installation does not occur until the new program is intercepted and analyzed. The verification that the program can be trusted must occur first before the allowing of installation can take place. The interception and analysis done on the program can been interpreted to be the parsing and analyzing of the installation file (in this case the new program).
Claim objection
Claim 5 is objected to because of the following informalities:
The claim limitation in claim 5 states “the system for computer security adds a reference to to a whitelist on the protected device” , however it should be written as “the system for computer security adds a reference to a whitelist on the protected device”. The extra word “to” must be removed.
Appropriate correction is required.
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)]
the system for computer security intercepts an installation by an installer before the installer runs
[Whenever the OS 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 on an unlimited, trusted, mode. If the results of the analysis show the program to be trusted, the OS envelope allows the program to install in a trusted mode. On the other hand, if the analysis is inconclusive, the OS envelope sends the analysis to the server 800 via the network 820, so that the client control program can perform an integrity test to verify whether the program is trusted and should be allowed to install and run on the user computer. If the client control program determines that the program is trusted, it instructs the OS envelope to install the program on the user compute (Dotan et al., paragraph 97)]
Before the installation is performed, the system for computer security parses 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 the installer is approved and and when the system for computer security determines that an installation is being performed by the installer on the protected device, before the installation is performed, and for each of the programs 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, before the installation is performed, the system for computer security parses 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 of the programs 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:
Intercepting an installation by a installer that is about to install an application defined by an installation file;
[Whenever the OS 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 on an unlimited, trusted, mode. If the results of the analysis show the program to be trusted, the OS envelope allows the program to install in a trusted mode. On the other hand, if the analysis is inconclusive, the OS envelope sends the analysis to the server 800 via the network 820, so that the client control program can perform an integrity test to verify whether the program is trusted and should be allowed to install and run on the user computer. If the client control program determines that the program is trusted, it instructs the OS envelope to install the program on the user compute (Dotan et al., paragraph 97)]
the system for computer security parses the installation and for each program that will be installed by the installer,
[Whenever the OS 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 on an unlimited, trusted, mode. If the results of the analysis show the program to be trusted, the OS envelope allows the program to install in a trusted mode. On the other hand, if the analysis is inconclusive, the OS envelope sends the analysis to the server 800 via the network 820, so that the client control program can perform an integrity test to verify whether the program is trusted and should be allowed to install and run on the user computer. If the client control program determines that the program is trusted, it instructs the OS envelope to install the program on the user compute (Dotan et al., paragraph 97)]
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)]
When the system for computer security finds the program in the whitelist, 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 on the protected device;
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)]
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 on the protected device;
[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 when the installer is approved and which programs are being modified, and which are being deleted; 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 the 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)]
Determining which programs are being modified and which programs are to be deleted;
[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)]
[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)]
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 the installer is approved and which programs are being modified, and which are being deleted; 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, 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 comprise an executable.
[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 comprise a script.
[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 comprise a macro.
[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.
Kim et al. (US 20230086654) discloses an installation file analysis module that decompiles and statically analyzes the installation file. As a result it identifies the type of a permission for data obtained/collected by the application or program corresponding to the installation file.
Kelly et al., (US 20130333039) discloses a programmable device for which an application is to be installed analyzes permissions requested by the application and other application information to assist the user in deciding whether to allow installation of the application. The analysis may either block or allow the installation, or may provide a calculated risk level to the user and request a decision. Application information such as trustworthiness of the application source in addition to whitelists and blacklists may be employed as part of the analysis.
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 6/24/2026
Prosecution Insights