DETAILED ACTION
This office action is in response to the application filed on 06/10/2026. Claim(s) 1-20 is/are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 6, 8-11, 13-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over by Mallozzi (US 2016/0191534 A1), hereinafter Mallozzi in view of Yang (US 2018/0321733 A1), hereinafter Yang.
Regarding Claim(s) 1, 8, and 14 Mallozzi teaches:
A computer-implemented method comprising: (Mallozzi ¶ 4-5 and 36-38 teaches, a method is performed at an electronic device (e.g., a mobile device) with one or more processors and memory storing instructions for execution by the one or more processors.)
accessing a request made by an application instance on a device for a particular instance of access to an audio, image, location, sensitive data, or network access resource of the device; (Mallozzi ¶ 93-94 and 97 teaches, a permission module for managing permissions for applications to access resources (e.g., audio input device, location detection device, image/video capture device, and/or respective modules in the memory) of the client device, which includes: a permission table for storing permissions and conditions for applications to access resources) wherein the request is made to an application security management interface that controls access to the resource based on one or more stored rules; (Mallozzi ¶ 97 teaches, permission module determines whether a number of access requests sent by an application satisfy a threshold, and accordingly denies permission to the application and/or provides an alert to the user. permission module is configured to ask (e.g., by displaying a GUI, FIG. 4A) a user of the client device for permission for an application (e.g., a client application module) to access a resource of the client device. permission module manages user-specified conditions under which to grant or deny permission (e.g., permitted locations, permitted users, one-time permissions, location resolution, etc.), and uses the conditions to grant or deny permission accordingly. (i.e., stored rules))
determining metadata associated with the request, wherein the metadata indicates (i) a particular state of a plurality of candidate states of the application instance at a time of the request, […] (iii) and one or more particular past states of the application instance at one or more times prior to the request; (Mallozzi ¶ 112-114, Furthermore, permissions may be limited to a particular resolution (“Location Resolution” for location-tracking resources), and/or to a foreground or background process (“Foreground/Background”). (i.e., state) a records table (e.g., stored in memory of client device, FIG. 3) which stores records of access requests sent by an application. (i.e., historical information about access requests) These records can be used for producing access requests statistics (e.g., as shown in the GUI, FIG. 4B). As shown, entries of the records table include an identifying index number corresponding to a particular access request (“Request Index #”), the application requesting access to device resources (“Application ID”), the resource to which access was requested (“Resource”), the date and time at which the request was sent, (or alternatively, when permission was granted/denied) (“Date/Time of Request”), the user of the requesting application (e.g., the user logged in) when the access request was sent (“Requesting User”), the location from which the access request was sent (“Location of Request”), and whether access was granted or denied (“Result of Request”). Although not shown, additional details regarding the result of the access request may be included in the records table (e.g., permitted duration, permitted location, etc.).)based at least in part on the particular state, the one or more particular past states, and at least one rule of the one or more stored rules, determining whether to grant the particular instance of access, wherein the at least one rule is satisfied based at least in part on a particular pattern comprising the particular state and the one or more particular past states; (Mallorzzi ¶ 108 teaches, based on the access request statistics, the application for managing permissions (e.g., permission module, FIG. 3) is also able to deny suspicious applications access to resources, provide alerts to users when suspicious activity is detected, and/or present permission recommendations to users. ¶ 107 teaches, he number of access requests received on the date of viewing the statistics (“Number of Access Requests Today”), and the total number of access requests received since the permission was created (“Total Number of Access Requests”).)
logging the request and the metadata to a resource access log;
denying at least one instance of access to the resource based at least in part on a pattern that is satisfied based at least in part on the resource access log. (Mallorzzi ¶ 95 teaches, a records table for storing records of access requests sent by applications, user inputs received in response to access requests, and context information for the client device at times when the access requests are made and/or the user inputs are received. ¶ 97 teaches, based on stored records (e.g., in records table), permission module presents statistics regarding multiple access requests, and/or presents recommendations to the user of conditions under which to grant or deny permissions for applications to access device resources.)
Mallozzi does not appear to explicitly teach but in related art:
request, (ii) a duration for which the application instance continuously remained in the particular state immediately prior to the time of the request, (Yang ¶ 7 teaches, the preset filter criterion includes preset duration, a preset application scenario list, and a blacklist, and determining whether the first application program meets a preset filter criterion includes collecting statistics on background running duration of the first application program, and determining whether the background running duration of the first application program exceeds the preset duration, (i.e., the duration must be tracked for it to know if at that moment it exceeds the preset duration) determining an application scenario of the first application program according to an interface called by the first application program, and comparing the application scenario of the first application program with the preset application scenario list, comparing the first application program with the blacklist, and determining that the first application program whose background running duration exceeds the preset duration and whose application scenario is neither saved in the preset application scenario list nor saved in the blacklist does not meet the preset filter criterion.)
at the time of the request, the duration for which the application instance continuously remained in the particular state immediately prior to the time of the request, (Yang ¶ 7 teaches, the preset filter criterion includes preset duration, a preset application scenario list, and a blacklist, and determining whether the first application program meets a preset filter criterion includes collecting statistics on background running duration of the first application program, and determining whether the background running duration of the first application program exceeds the preset duration, (i.e., the duration must be tracked for it to know if at that moment it exceeds the preset duration) determining an application scenario of the first application program according to an interface called by the first application program, and comparing the application scenario of the first application program with the preset application scenario list, comparing the first application program with the blacklist, and determining that the first application program whose background running duration exceeds the preset duration and whose application scenario is neither saved in the preset application scenario list nor saved in the blacklist does not meet the preset filter criterion.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Mallozzi with Yang, to modify the system permissions management of Mallozzi with the tracking the duration of a state of Yang. The motivation to do so, Yang ¶ 30, this prevents a first application program that runs in the background and that does not meet a preset filter criterion and a service called by the first application program from inappropriately holding a wakelock for a long time.
Regarding Claim(s) 2, 9, and 15 Mallozi in view of Yang teaches:
The computer-implemented method of Claim 1, (Mallozi in view of Yang teaches the parent claim above.) wherein the particular state is a background state, and wherein the plurality of candidate states comprise one or more foreground states and one or more background states. (Mallozzi ¶ 112-114 teaches, permissions may be limited to a particular resolution (“Location Resolution” for location-tracking resources), and/or to a foreground or background process (“Foreground/Background”). the GPS device may only be accessed when the Application 01 is running as a foreground process (e.g., an interactive mapping application that displays a current location of the client device) and not as a background process.)
Regarding Claim(s) 3, 10, and 16 Mallozi in view of Yang teaches:
The computer-implemented method of Claim 1, (Mallozi in view of Yang teaches the parent claim above.) wherein the pattern is based at least in part on a frequency by which access to the audio, image, location, sensitive data, or network access resource is requested. (Mallozzi ¶ 95 teaches, a records table for storing records of access requests sent by applications, user inputs received in response to access requests, and context information for the client device at times when the access requests are made and/or the user inputs are received. ¶ 97 teaches, based on stored records (e.g., in records table), permission module presents statistics regarding multiple access requests, and/or presents recommendations to the user of conditions under which to grant or deny permissions for applications to access device resources.)
Regarding Claim(s) 4, 11, and 17 Mallozi in view of Yang teaches:
The computer-implemented method of Claim 1, (Mallozi in view of Yang teaches the parent claim above.) wherein the pattern is based at least in part on how long the application instance remains in the particular state after access to the audio, image, location, sensitive data, or network access resource has been granted. (Mallozzi ¶ 106 teaches, includes the date and time at which the permission was created (“Permission Created On”), whether access was granted (“Access Granted”), the resource to which access was granted (“Resource”), a permitted duration of access (“Permitted Duration”), (i.e., how long application is in a state) a permitted location of access (“Permitted Location”), a permitted user (“Permitted User”), and whether access is granted for a foreground or background process (“Foreground/Background”) (i.e., state). ¶ 108 teaches, conjunction with access request statistics of corresponding applications, the user is able to identify potentially malicious applications that are operating outside the permitted and defined boundaries of access. The user is also able to identify which applications are most resource-intensive in accessing device resources, and also which device resources are accessed by applications the most. Furthermore, based on the access request statistics, the application for managing permissions (e.g., permission module, FIG. 3) is also able to deny suspicious applications access to resources, provide alerts to users when suspicious activity is detected, and/or present permission recommendations to users.)
Regarding Claim(s) 6, 13, and 19 Mallozi in view of Yang teaches:
The computer-implemented method of Claim 1, further comprising: Mallozi in view of Yang teaches the parent claim above.) receiving a binary object from an application instance; (Mallozzi ¶ 112 teaches, Permissions define the authorization or lack of authorization of applications)
wherein accessing the request comprises extracting a request identifier from the binary object, and wherein determining the metadata associated with the request comprises extracting an application state identifier from the binary object. (Each entry of the permission table identifies the application for which a respective permission is defined (“Application ID”), the resource to which access is granted or denied (“Resource”), whether access to the resource is granted or denied (“Permission”), and the date and time at which the permission was defined (“Date/Time of Permission”). Optionally, the permission table 344 may specify conditions under which permission is granted or denied. For example, access may be permitted only for a specified duration (“Duration”), at a specific location (“Location”), and/or for a specific user (“User”). Furthermore, permissions may be limited to a particular resolution (“Location Resolution” for location-tracking resources), and/or to a foreground or background process (“Foreground/Background”). (i.e., state identifier))
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mallozi in view of Yang as taught by claim(s) 1 and 14 in further view of Carstens (US 2016/0267738 A1), hereinafter Carstens.
Regarding Claim(s) 7 and 20 Mallozi in view of Yang teaches:
The computer-implemented method of Claim 1, (Mallozi in view of Yang teaches the parent claim above.)
and checking the one or more particular past states based at least in part on determining that the first condition is not satisfied. (Mallozzi ¶ 112-114, Furthermore, permissions may be limited to a particular resolution (“Location Resolution” for location-tracking resources), and/or to a foreground or background process (“Foreground/Background”). (i.e., state) a records table (e.g., stored in memory of client device, FIG. 3) which stores records of access requests sent by an application. (i.e., historical information about access requests) These records can be used for producing access requests statistics (e.g., as shown in the GUI, FIG. 4B). As shown, entries of the records table include an identifying index number corresponding to a particular access request (“Request Index #”), the application requesting access to device resources (“Application ID”), the resource to which access was requested (“Resource”), the date and time at which the request was sent, (or alternatively, when permission was granted/denied) (“Date/Time of Request”), the user of the requesting application (e.g., the user logged in) when the access request was sent (“Requesting User”), the location from which the access request was sent (“Location of Request”), and whether access was granted or denied (“Result of Request”). Although not shown, additional details regarding the result of the access request may be included in the records table (e.g., permitted duration, permitted location, etc.).)
Mallozi in view of Yang does not appear to explicitly teach but in related art:
wherein the one or more stored rules fast-track access to the resource without checking the one or more particular past states if a first condition is satisfied, the computer-implemented method further comprising: (Carstens ¶ 167 teaches, depending on the presence of the respective access authorization parameters in the access authorization information—the following can be checked, wherein the order of the checks can be arbitrary and they can already be terminated in the event of a condition not being met, or the process can jump to step , in order to save time and/or power (i.e., fast-track depending on a condition.))
determining that the first condition is not satisfied; (Carstens ¶ 167 teaches, depending on the presence of the respective access authorization parameters in the access authorization information—the following can be checked, wherein the order of the checks can be arbitrary and they can already be terminated in the event of a condition not being met, or the process can jump to step 404, in order to save time and/or power)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Mallozi in view of Yang with Carstens, to modify the system permissions management of Mallozzi with the tracking duration of Yang with the skipping of an authentication step if a condition is met of Carstens. The motivation to do so, Casrstens ¶ 16, in order to save time and/or power.
Allowable Subject Matter
Claim(s) 5 is/are allowed, as it includes subject matter previously deemed as allowable.
Claim(s) 12, and 18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2025/0193019 A1 - MONITORING USER SPACE PROCESSES USING HEARTBEAT MESSAGES AUTHENTICATED BASED ON INTEGRITY MEASUREMENTS
US 2021/0194930 A1 - SYSTEMS, METHODS, AND DEVICES FOR LOGGING ACTIVITY OF A SECURITY PLATFORM
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights