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 .
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 08/31/2026 has been entered.
Response to Amendment
This office action is responsive to amendment filed on 08/31/2026. The Examiner has acknowledged claims 21, 33 and 40 have been amended. Claims 1-20, 28 and 32 Previously canceled. New claim 42 has been added. Claims 21-27, 29-31 and 33-42 have been presented for examination and are rejected.
Response to Arguments
Applicant's argument, filed on 08/31/2026 has been entered and carefully considered.
Applicant's arguments filed on August 31st, 2026, with respect rejected to claims 21-27, 29-31 and 33-42 under 35 U.S.C. 102 have been considered, but are moot in view of the new ground of rejection necessitated by Applicant's amendment.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 21-23, 24-26, 29-30, 33-37 and 40-41 are rejected under 35 U.S.C. 103 as being unpatentable over Mohinder et al. (US 20170351862 hereinafter Mohinder) in view of Uola (US 20140006598 hereinafter Uola).
With respect to claims 21, 33 and 40, Mohinder teaches a system comprising:
a processing system (Mohinder, see FIG. 2 and para. [0061]; and
memory coupled to the processing system, the memory comprising computer executable instructions that, when executed, perform operations (Mohinder, see FIG. 2 and paras. [0061-0062]) comprising:
receiving a request to perform an action on a file for an application installed on a computing device (Mohinder, see para. [0023] The trusted file set is a subset of the files in the global whitelist that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata (i.e., equivalent to a request to perform an action on a file on an installed application) such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set);
accessing a policy applied to the computing device, wherein the policy describes actions that are permitted to be performed by the computing device (Mohinder, see FIG. 1 and paras. [0055-0056] an enterprise security policy may allow an application to be installed from application repository 160 only if it has a valid certificate issued by certificate authority 192 and is provided in an authorized list of applications for secured enterprise 100. In this case, an installer program for the authorized application (i.e., permitted)may be marked as an updater or trusted updater. [0056] Application repository 160 may represent a Windows or Apple “app store” or update service, a Unix-like repository or ports collection, or other network service providing users 120 the ability to interactively or automatically download and install applications on client devices 110);
determining, based on the policy and using origin information for the application that is stored as metadata associated with the file (Mohinder, see para. [0023] the trusted file set is a subset of the files in the global whitelist (i.e., policy) that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set. Para. [0029] a certificate(i.e., equivalent to origin information of the application) may include verification tokens for a plurality of executable objects that are controlled by the parent trusted updater…the web browser may be authorized by enterprise security policies, but the chat program may not. Thus, a properly functioning client device will install A (including allowing process A and any child process to modify files in process A's whitelist)…),
whether an origin of the application is trusted for the computing device (Mohinder, see FIG. 1 and para. [0055] an enterprise security policy may allow an application to be installed from application repository 160 if it has a valid certificate (i.e., application source origin from a certificate) issued by certificate authority 192 and is provided in an authorized list of applications for secured enterprise 100. Para.[0056] further discloses Application repository 160 may represent a Windows or Apple “app store” or update service, a Unix-like repository or ports collection, or other network service providing users 120 the ability to interactively or automatically download and install applications on client devices 110), and
processing the action based on whether the origin of the application is trusted (Mohinder, see FIGS. 2, 7A, 7B and [0099] Trusted installer 700 may be provided by trusted updater 226 of FIG. 2. When files are added to the whitelist for trusted installer 700, system management agent 224 may keep track of files coming from trusted installer 700 and that have the same certificate. This will provide a chain of trust. These files will be allowed to modify).
Mohinder, yet fails to explicitly disclose wherein the origin of the application refers to a deployment source for an application package of the application or a source of trust for the application package, and
wherein the origin information is propagated during installation of the application.
However, Uola discloses wherein the origin of the application refers to a deployment source for an application package of the application or
a source of trust for the application package (Uola, see paras. [0063-0065] The network device 51 may have a repository (e.g., an application store) for hosting one or more applications (e.g., application X 56, application Y 58) on behalf of one or more source entities (e.g., origin entity X, origin entity Y)…FIG. 10, an application installation package may be digitally signed, which may allow the installation manager 52 to determine the source entity (e.g., organization) of a corresponding application (e.g., application X 56, application Y 58)), and
wherein the origin information is propagated during installation of the application (Uola, see para. [0012] a method may include determining one or more respective origins of one or more applications, received from at least one network device, during installation of the applications).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching of Mohinder with the teaching of Uola provide the system for the tracking an application's origin whether as a deployment source (like a managed installer) or a source of trust (like a signed certificate or cloud reputation) is that it automates security allowlisting and reduces administrative overhead without requiring individual file hash rules for every software update.
With respect to claim 22, Mohinder-Uola teaches the system, wherein the origin of the application is determined using origin information for the application(Mohinder, see para. [0023] the trusted file set is a subset of the files in the global whitelist (i.e., policy) that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set. Para. [0029] a certificate(i.e., equivalent to origin information of the application) may include verification tokens for a plurality of executable objects that are controlled by the parent trusted updater).
With respect to claim 23, Mohinder-Uola teaches the system, wherein propagating the origin information comprises:
receiving the origin information from a policy enforcement mechanism (Uola, see para. [0038] each application may be given specific permissions based on their level of trust. These permissions may be enforced by the browser 12 of device 11 using the same-origin policy principle); and
storing an indication of the origin information in a storage location comprising the file (Mohinder, see para. [0055] security administrator 150 may run in installation of the application from application repository 160 (i.e., storage) on a sandbox environment in enterprise security controller 140. Security administrator 150 may use this process to build a list of files required for installing the application. This list may then be distributed as a trusted file set for the secure updater associated with the application).
With respect to claim 24, Mohinder-Uola teaches the system, wherein:
the file is an executable file (Mohinder, see para. [0060] to enforce this policy, the system management agent may be configured to prevent any executable object from modifying system files if it is not a trusted updater or trusted installer); and
the request to perform the action on the file corresponds to a request to execute the application (Mohinder, see para. [0023] The trusted file set is a subset of the files in the global whitelist that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata (i.e., equivalent to a request to perform an action on a file on an installed application) such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set).
With respect to claim 25, Mohinder-Uola teaches the system, wherein the request to perform the action on the file corresponds to a request for the application to access a resource of the computing device (Mohinder, see para. [0023] The trusted file set is a subset of the files in the global whitelist that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata (i.e., equivalent to a request to perform an action on a file on an installed application) such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set).
With respect to claim 26, Mohinder-Uola teaches the system, wherein the request to perform the action on the file corresponds to a request for record information regarding the application (Uola, see FIG. 13 and para. [0082] determining origins of applications is provided. At operation 1300, an apparatus (e.g., communication device 53 (e.g., apparatus 50)) may determine one or more respective origins (e.g., source origin entity X, source origin entity Y) of one or more applications (e.g., application X 56, application Y 58), received from at least one network device (e.g., network device 51), during installation of the application).
With respect to claim 29, Mohinder-Uola teaches the system, wherein processing the action based on whether the origin of the application is trusted comprises:
determining the origin of the application is trusted(Mohinder, see para. [0030] a trust grid may be maintained to cross-reference trusted updaters against whitelisted files and valid certificates. In this example, process A is a trusted updater, and processes B and C appear in its trusted file set);
in response to determining the origin of the application is trusted, determining the action is permitted to be performed on the file (Mohinder, see FIG. 1 and paras. [0055-0056] an enterprise security policy may allow an application to be installed from application repository 160 only if it has a valid certificate issued by certificate authority 192 and is provided in an authorized list of applications for secured enterprise 100. In this case, an installer program for the authorized application (i.e., permitted)may be marked as an updater or trusted updater. [0056] Application repository 160 may represent a Windows or Apple “app store” or update service, a Unix-like repository or ports collection, or other network service providing users 120 the ability to interactively or automatically download and install applications on client devices 110); and
performing the action on the file (Mohinder, see FIGS. 2, 7A, 7B and [0099] Trusted installer 700 may be provided by trusted updater 226 of FIG. 2. When files are added to the whitelist for trusted installer 700, system management agent 224 may keep track of files coming from trusted installer 700 and that have the same certificate. This will provide a chain of trust. These files will be allowed to modify).
With respect to claim 30, Mohinder-Uola teaches the system, wherein processing the action based on whether the origin of the application is trusted comprises:
determining the origin of the application is not trusted; and in response to determining the origin of the application is not trusted, generating a determination that the action is not permitted to be performed on the file (Mohinder, see para. [0030] a trust grid may be maintained to cross-reference trusted updaters against whitelisted files and valid certificates. In this example, process A is a trusted updater, and processes B and C appear in its trusted file set. Processes B and C also are validated by the same certificate that validates process A. Process D is also validated by the certificate, but does not appear in the trusted file set for process A. Thus, if a user or process attempts to launch process D, the security manager and agent may look up process D in its security grid and determine that although process D has a valid certificate, it does not appear in the trusted file set for process A and thus should be blocked from executing).
With respect to claim 34, Mohinder-Uola teaches the method, wherein determining the origin of the application is trusted comprises:
accessing the origin of the application, wherein the origin of the application has been stored in a storage location of the computing device in response to a request to install the application on the computing device(Mohinder, see FIG. 1 and paras. [0055-0056] an enterprise security policy may allow an application to be installed from application repository 160 only if it has a valid certificate issued by certificate authority 192 and is provided in an authorized list of applications for secured enterprise 100. In this case, an installer program for the authorized application (i.e., permitted)may be marked as an updater or trusted updater. [0056] Application repository 160 may represent a Windows or Apple “app store” or update service, a Unix-like repository or ports collection, or other network service providing users 120 the ability to interactively or automatically download and install applications on client devices 110); and
determining the policy specifies the origin of the application is trusted (Mohinder, see para. [0029] a certificate(i.e., equivalent to origin information of the application) may include verification tokens for a plurality of executable objects that are controlled by the parent trusted updater…the web browser may be authorized by enterprise security policies, but the chat program may not. Thus, a properly functioning client device will install A (including allowing process A and any child process to modify files in process A's whitelist)).
With respect to claim 35, Mohinder-Uola teaches the system, wherein the policy specifies:
one or more applications that can be executed by the computing device; and one or more trusted origins (Mohinder, see para. [0056] Application repository 160 may represent a Windows or Apple “app store” or update service, a Unix-like repository or ports collection, or other network service providing users 120 the ability to interactively or automatically download and install applications on client devices 110).
With respect to claim 36, Mohinder-Uola teaches the system, yet fails to explicitly disclose wherein whether the origin of the application is trusted is based on at least one of:
a deployment source for the application; or
a source of trust for the application package (Uola, see paras. [0063-0065] The network device 51 may have a repository (e.g., an application store) for hosting one or more applications (e.g., application X 56, application Y 58) on behalf of one or more source entities (e.g., origin entity X, origin entity Y)…FIG. 10, an application installation package may be digitally signed, which may allow the installation manager 52 to determine the source entity (e.g., organization) of a corresponding application (e.g., application X 56, application Y 58)).
With respect to claim 37, Mohinder-Uola teaches the system, wherein performing the action comprises executing the application on the computing device (Mohinder, see FIG. 1 and paras. [0055-0056] an enterprise security policy may allow an application to be installed from application repository 160 only if it has a valid certificate issued by certificate authority 192 and is provided in an authorized list of applications for secured enterprise 100. In this case, an installer program for the authorized application (i.e., permitted)may be marked as an updater or trusted updater).
With respect to claim 41, Mohinder-Uola teaches the device, determining the origin of the application is not trusted comprises:
obtaining the origin of the application from the metadata (Mohinder, see para. [0023] The trusted file set is a subset of the files in the global whitelist that belong to the same workflow as the trusted updater. The trusted updater is authorized to modify, which in this context can include any or all of creating a file, deleting a file, renaming a file, changing a file's metadata (i.e., equivalent to a request to perform an action on a file on an installed application) such as permissions and attributes, or otherwise operating on a file, any file in its trusted file set); and
determining the origin of the application is not listed as a trusted origin in the policy (Mohinder, see para. [0030] a trust grid may be maintained to cross-reference trusted updaters against whitelisted files and valid certificates. In this example, process A is a trusted updater, and processes B and C appear in its trusted file set. Processes B and C also are validated by the same certificate that validates process A. Process D is also validated by the certificate, but does not appear in the trusted file set for process A. Thus, if a user or process attempts to launch process D, the security manager and agent may look up process D in its security grid and determine that although process D has a valid certificate, it does not appear in the trusted file set for process A and thus should be blocked from executing).
Claims 27 is rejected under 35 U.S.C. 103 as being unpatentable over Mohinder et al. (US 20170351862 hereinafter Mohinder) in view of Uola (US 20140006598 hereinafter Uola) further in view of Takeuchi (JP 2004295504 hereinafter Takeuchi).
With respect to claim 27, Mohinder-Uola teaches the system, yet fails to explicitly disclose wherein the policy is received from an enterprise management service of an enterprise to which the computing device belongs.
However, Takeuchi discloses wherein the policy is received from an enterprise management service of an enterprise to which the computing device belongs (Takeuchi, see paragraphs [0016-0018] security management is performed based on the security table including the resources to be managed and the conditions for setting the status of the computer that permits the access request to the resources).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching of Mohinder-Uola with the teaching of Takeuchi provides the system for receiving policies from an enterprise management service gives an organization centralized control, enhanced security, better compliance, and streamlined IT, ensuring all devices adhere to uniform rules for data protection, application access, and secure configurations, which boosts productivity while mitigating risks like data loss and unauthorized access.
Claims 31 and 42 are rejected under 35 U.S.C. 103 as being unpatentable over Mohinder et al. (US 20170351862 hereinafter Mohinder) in view of Uola (US 20140006598 hereinafter Uola) further in view of Richardson et al. (US 20160321452 hereinafter Richardson).
With respect to claim 31 Mohinder-Uola teaches the system, wherein processing the action based on whether the origin of the application is trusted yet fails to explicitly disclose further comprises:
evaluating at least one rule in the policy that authorizes performance of the action;
determining the at least one rule overrides the determination that the action is not permitted to be performed on the file; and performing the action on the file.
However, Richardson discloses further comprises: evaluating at least one rule in the policy that authorizes performance of the action (Richardson, see paragraph [0104] “…The new application 1013 may be compared to user policy 108 during or after installation. Side-loaded server 150 includes a data repository of user policies 116. User policy 108 of mobile device 149 may be compared to user policies 116. An administrator server (not shown) may provide some policies in user policies 116 (e.g., as regards usage of or installation of applications onto mobile device 149)…”);
determining the at least one rule overrides the determination that the action is not permitted to be performed on the file; and performing the action the file (Richardson, see paragraph [0310] ”…the actions taken above are to set App-State; being “allowed/disallowed” means if “allowed” then permitting installation to proceed, and if disallowed, then either uninstalling the app if it has already been installed, or blocking the app from executing if the app has already been installed. In an embodiment, the signed application installation package contains a directive that the application is only intended for distribution from one or more specific channels, and if the application has been provided via a channel that was not listed, then the application will not be installed”).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching of Mohinder-Uola with the teaching of Richardson to provide the system for the policy-evaluation sequence enables flexible, exception-based access control, where specific authorization rules can grant targeted access without compromising a strict default-deny security baseline.
With respect to claim 42 Mohinder-Uola teaches the system, yet fails to explicitly disclose the operations further comprising:
subsequent to preventing the request from being performed based on determining the origin of the application is not trusted, enabling the request to be performed based on the policy indicating that the application can be executed on the device.
However, Richardson discloses the operations further comprising: subsequent to preventing the request from being performed based on determining the origin of the application is not trusted, enabling the request to be performed based on the policy indicating that the application can be executed on the device. (Richardson, see paragraph [0104] “…the new application 1013 may be compared to user policy 108 during or after installation. Side-loaded server 150 includes a data repository of user policies 116. User policy 108 of mobile device 149 may be compared to user policies 116. …Para. [0310] …the actions taken above are to set App-State; being “allowed/disallowed” means if “allowed” then permitting installation to proceed, and if disallowed, then either uninstalling the app if it has already been installed or blocking the app from executing if the app has already been installed. In an embodiment, the signed application installation package contains a directive that the application is only intended for distribution from one or more specific channels, and if the application has been provided via a channel that was not listed, then the application will not be installed”).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching of Mohinder-Uola with the teaching of Richardson to provide the system for the policy-evaluation sequence enables flexible, exception-based access control, where specific authorization rules can grant targeted access without compromising a strict default-deny security baseline.
Claims 38-39 are rejected under 35 U.S.C. 103 as being unpatentable over Mohinder et al. (US 20170351862 hereinafter Mohinder) in view of Uola (US 20140006598 hereinafter Uola) further in view of Thomas (US 20160337382 hereinafter Thomas).
With respect to claim 38, Mohinder-Uola teaches the system, yet fails to explicitly disclose wherein the metadata being written to a storage location comprising the file as part of installing the application on the computing device.
However, Thomas discloses wherein the metadata being written to a storage location comprising the file as part of installing the application on the computing device (Thomas, see paragraph [0067] the reputation information that is associated with a file may be metadata relating to the file format of the selected file, the originating location of the selected file).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching of Xuan-Richardson-Takeuchi with the teaching of Thomas provide a system for metadata associated with file for tracking the file origin using metadata to assess risk, catching new threats that lack traditional signatures. In doing so, it improve application control, enhances security by proactively identifying and blocking threats, and improving application control.
With respect to claim 39, Mohinder-Uola teaches the system, yet fails to explicitly disclose wherein metadata is written as extended attributes of a data stream of the file.
However, Thomas discloses wherein metadata is written as extended attributes of a data stream of the file (Thomas, see paragraph [0008] The metadata may be used to control the access and security settings of the file and to require that only an approved method of gaining access to the file, or any of the file's contents, is used).
Same motivation as claim 38.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure includes:
PG. Pub US 20140040873 Computer-implemented method for installing and updating software applications on computing platforms, involves updating installed software application based on received installation file when migration signature is included.
Patent No. US 10320790 System for providing access to resource during execution of software product, has computing device for providing credentials to instance of software product to access resource and preventing customer access to resource.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH KASSA whose telephone number is (571)270-0567. The examiner can normally be reached Monday -Friday 9 AM -6 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, Ario Etienne can be reached on 517-272-4001. 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.
09/11/2026
/ELIZABETH KASSA/Examiner, Art Unit 2457
/MOUSTAFA M MEKY/Primary Examiner, Art Unit 2457
Prosecution Insights