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 .
Response to Amendment
This office action is responsive to amendment filed on 03/04/2026. The Examiner has acknowledged claims 21, 33 and 40 have been amended. Claims 1-20 and 32 have been canceled. New claim 41 has been added. Claims 21-31 and 33-41 have been presented for examination and are rejected.
Response to Arguments
Applicant's argument, filed on 03/04/2026 has been entered and carefully considered.
Applicant's arguments filed on March 4th, 2026 with respect rejected to claims 21-40 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-31, 34-37 and 40-41 are rejected under 35 U.S.C. 103 as being unpatentable over Xuan et al. (US 20160344771 hereinafter Xuan) in view of Richardson et al. (US 20160321452 hereinafter Richardson).
With respect to claims 21, 33 and 40, Xuan teaches a system comprising:
a processing system (Xuan, see paragraph [0023]); and
memory coupled to the processing system, the memory comprising computer executable instructions that, when executed, perform operations(Xuan, see paragraph [0054]) comprising:
receiving a request to perform an action on a file for an application installed on a computing device (Xuan, see FIG. 7 and paragraph [0088] the enforcer 153 can intercept a request by the target application to perform an action);
accessing a policy applied to the computing device (Xuan, see FIG. 7 and paragraph [0089] at step 709, the enforcer 153 can then compare the request to the compliance rules 136 that are assigned to the client device 106 (i.e., the client device is requesting for access and the enforcer 153 is comparing request to determine whether the client device compliance rule). A compliance rule 136 can specify whether a component in a client device 106 is permitted to request access to an image library in the client device 106),
wherein the policy describes actions that are permitted to be performed by the computing device (Xuan, see FIG. 7 and paragraphs [0089,0091] a compliance rule 136 can specify whether a component in a client device 106 is permitted to request access to an image library in the client device 106. Paragraph [0091] if the enforcer 153 determines that the target application 146 is permitted to perform the request, the enforcer 153 can forward the request to perform the operation to the operating system 143, as indicated at step 719 );
Xuan, yet fails to explicitly disclose determining, based on the policy, whether an origin of the application is trusted for the computing device, 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
processing the action based on whether the origin of the application is trusted.
However, Richardson discloses determining, based on the policy, whether an origin of the application is trusted for the computing device (Richardson, see Parag. [0042] “…a first application identifier and a first source identifier, each for a first application of the first computing device; determine whether the first source identifier matches a white list of source identifiers (e.g., a list of trusted channel identifiers); and determine whether the first source identifier matches a black list of source identifiers (e.g., a list of untrusted channel identifiers); send the first application identifier and the first source identifier over a network to a second computing device…” Parag. [0607] further discloses “…an origin of the app is identified, and a determination is made (e.g., by side-load server 150) whether the app is still available in the version that is currently being assessed (e.g., when being considered for installation on mobile device 149).”),
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 (Richardson, see paragraphs [0037-0038] “…determining a source of applications or other software obtained over a network (e.g., applications downloaded to a mobile device from an application store such as the Google Play store or the Apple App Store), via a connection to another device… an action may optionally be performed in response to the determination of the source of software (e.g., the handling of an application on the mobile device may be based on whether the source of the application is trusted or untrusted...” Parag. [0066-0067] further discloses “A source may be trusted for various reasons, including, for example, that the source is an authorized Google Play store or Apple App Store… when referring to Android apps, an application is side-loaded if it is installed using an application package in APK format onto an Android device, after downloading the application package from a website other than Google Play…”); and
processing the action based on whether the origin of the application is trusted (Richardson, see Parag. [0614] “…a server can track the origin as to what network(s) device the mobile device was connected to at the time of download, or the specific computing device/network through which the download to the mobile device was made.” Parag. [0616] further discloses “…an indication is put inside the app (e.g., inserted by the developer, such as by a developer server, into or with the code of the application) of an intended channel for delivery. The app should not show up with a different channel ID having been determined after analysis (e.g., by side-load server 150). Otherwise, the app is considered to be from a bad source or untrusted…”).
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 with the teaching of Richardson provide the system for the origin represents the deployment source or source of trust by verifying the updates and software packages are authentic before deployment, preventing unauthorized applications, malicious software, or compromised code from entering the system and supply chain vulnerabilities from being deployed. Also, By validating that an application originates from a trusted repository, developer, or deployment pipeline, the system enforces security standards, safeguarding application integrity and data confidentiality from unauthorized access.
With respect to claim 22, Xuan-Richardson teaches the system, wherein the origin of the application is determined using origin information for the application, the origin information being propagated during installation of the application (Richardson, see paragraph [0237] “…if the App-State of the app on the MCD is ‘unknown,’ which will be the case if the app is not from Google Play or an Amazon store [these are the only app stores currently filling out the value retrieved by the Android getInstallerPackageName( ) method], then an identifier can be sent for the app (e.g., package name or hash of the app) to the server (e.g., side-load server 150), which may have other information about the origin and channel ID of the app (i.e., equivalent to propagating the origin information), and the app identifier is used at the server to determine whether the app should be trusted or not.”).
With respect to claim 23, Xuan-Richardson-Takeuchi teaches the system, wherein propagating the origin information comprises:
receiving the origin information from a policy enforcement mechanism (Richardson, see paragraphs [0093-0094] “The usage or behavior of components of the application on the device that are inconsistent with a user or administrator-designated policy can be identified. In such event, the source and/or the application can be deemed as untrusted…A policy may be defined by behavioral preferences established by a user and/or an administrator, and this policy is enforced on new applications installed on the mobile device. In another example, a policy may apply to a particular identified application.”); and
storing an indication of the origin information in a storage location comprising the file (Richardson, see paragraph [0116] “…these characteristics and behaviors may be compared with known characteristics and behaviors stored either locally on mobile device 149 or stored remotely on the identity server as data associated with component identities (these identities may also be associated with previously-determined sources of the corresponding applications)…”).
With respect to claim 24, Xuan-Richardson teaches the system, wherein:
the file is an executable file (Xuan, see paragraph [0054] the executables in the target application executables file); and
the request to perform the action on the file corresponds to a request to execute the application (Xuan, see paragraph [0056] intercepting a request for process information and returning an object that identifies the target application can facilitate the intended execution of the target application).
With respect to claim 25, Xuan-Richardson 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 (Xuan, see paragraph [0041] the target application manifest file can describe the functionality of the target application as well as the resources and permissions that are used to execute the target application).
With respect to claim 26, Xuan-Richardson teaches the system, wherein the request to perform the action on the file corresponds to a request for record information regarding the application (Richardson, see paragraph [0038] “…an action may optionally be performed in response to the determination of the source of software (e.g., the handling of an application on the mobile device may be based on whether the source of the application is trusted or untrusted; if untrusted, installation of the software can be blocked, or the software can be disabled or removed from the device).”).
With respect to claim 29, Xuan-Richardson 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 (Richardson, see paragraphs [0037-0038] “…determining a source of applications or other software obtained over a network (e.g., applications downloaded to a mobile device from an application store such as the Google Play store or the Apple App Store), via a connection to another device… an action may optionally be performed in response to the determination of the source of software (e.g., the handling of an application on the mobile device may be based on whether the source of the application is trusted or untrusted);
in response to determining the origin of the application is trusted, determining the action is permitted to be performed on the file; and performing the action of the file (Richardson, see paragraphs [0066-0067] “A source may be trusted for various reasons, including, for example, that the source is an authorized Google Play store or Apple App Store. Other examples include a source identified by an administrator of mobile devices (e.g., for a large corporation with thousands of employees) for use by users in downloading new software. In another example, a source may be trusted based on a prior history with that source (e.g., extensive prior downloads without negative incidents)… when referring to Android apps, an application is side-loaded if it is installed using an application package in APK format onto an Android device, after downloading the application package from a website other than Google Play…”).
With respect to claim 30, Xuan-Richardson 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 (Richardson, see paragraph [0038] “…an action may optionally be performed in response to the determination of the source of software (e.g., the handling of an application on the mobile device may be based on whether the source of the application is trusted or untrusted; if untrusted, installation of the software can be blocked, or the software can be disabled or removed from the device). In another example, a software application being newly-installed on a mobile device of a user may be determined to be a fraudulent or tampered version, in which case installation is blocked and an administrator server that manages the device via mobile device management (MDM) is notified that the source of the application is untrusted…”).
With respect to claim 31 Xuan-Richardson teaches the system, wherein processing the action based on whether the origin of the application is trusted 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 of 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.”).
With respect to claim 34, Xuan-Richardson 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 (Richardson, see Parag. [0042] “…a first application identifier and a first source identifier, each for a first application of the first computing device; determine whether the first source identifier matches a white list of source identifiers (e.g., a list of trusted channel identifiers); and determine whether the first source identifier matches a black list of source identifiers (e.g., a list of untrusted channel identifiers); send the first application identifier and the first source identifier over a network to a second computing device…” Parag. [0607] further discloses “…an origin of the app is identified, and a determination is made (e.g., by side-load server 150) whether the app is still available in the version that is currently being assessed (e.g., when being considered for installation on mobile device 149).”); and
determining the policy specifies the origin of the application is trusted Richardson, see paragraphs [0066-0067] “…A source may be trusted for various reasons, including, for example, that the source is an authorized Google Play store or Apple App Store… when referring to Android apps, an application is side-loaded if it is installed using an application package in APK format onto an Android device, after downloading the application package from a website other than Google Play…”).
With respect to claim 35, Xuan-Richardson 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 (Xuan, see FIG. 7 and paragraph [0089]).
With respect to claim 36, Xuan-Richardson 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(Richardson, see paragraphs [0066-0067] “…A source may be trusted for various reasons, including, for example, that the source is an authorized Google Play store or Apple App Store… when referring to Android apps, an application is side-loaded if it is installed using an application package in APK format onto an Android device, after downloading the application package from a website other than Google Play…”).
With respect to claim 37, Xuan-Richardson teaches the system, wherein performing the action comprises executing the application on the computing device (Xuan, see paragraph [0041] the target application manifest file 209 can describe the functionality of the target application 146 as well as the resources and permissions that are used to execute the target application 146).
With respect to claim 41, Xuan-Richardson teaches the device, determining the origin of the application is not trusted comprises:
obtaining the origin of the application from the metadata (Richardson, see paragraph [0150] “Console 1032 provides a display to the user of a variety of information including a list of side-loaded applications detected as potential malware, along with metadata for such applications including signers, permissions, and frameworks.”); and
determining the origin of the application is not listed as a trusted origin in the policy (Richardson, see paragraph [0149] “FIG. 9 shows the display of the mobile device 606, on which a notification 902 is provided from side-load server 150 or administrator server 302 indicating that an application being installed may be from an untrusted source, according to one embodiment. The source of this application has been determined to be an untrusted source based on the various methods…”).
Claims 27 is rejected under 35 U.S.C. 103 as being unpatentable over Xuan et al. (US 20160344771 hereinafter Xuan) in view of Richardson et al. (US 20160321452 hereinafter Richardson) further in view of Takeuchi (JP 2004295504 hereinafter Takeuchi).
With respect to claim 27, Xuan-Richardson 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 Xuan-Richardson 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 28 and 38-39 are rejected under 35 U.S.C. 103 as being unpatentable over Xuan et al. (US 20160344771 hereinafter Xuan) in view of Richardson et al. (US 20160321452 hereinafter Richardson) further in view of Thomas (US 20160337382 hereinafter Thomas).
With respect to claims 28 and 38, Xuan-Richardson teaches the system, yet fails to explicitly disclose wherein the origin of the application is obtained from metadata associated with the file.
However, Thomas discloses wherein the origin of the application is obtained from metadata associated with the file (Thomas, see paragraphs [0008, 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, enhanced security by proactively identifying and blocking threats, improving application control.
With respect to claim 38, Xuan-Richardson teaches the system, yet fails to explicitly disclose wherein the origin of the application is obtained from metadata associated with the file, 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 origin of the application is obtained from metadata associated with the file, 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).
Same motivation as claim 28.
With respect to claim 39, Xuan-Richardson 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 28.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892 Notice of References Cited.
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.
05/16/2026
/ELIZABETH KASSA/Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights