DETAILED ACTION
This office action is in response to the application filed on 09/25/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 .
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 09/25/2026 has been entered.
Response to Arguments
Applicant's arguments filed on 09/25/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
Applicant respectfully submits that the cited combination does not disclose or suggest using the duration for which an application instance continuously remained in a particular state immediately prior to a request as a basis for determining whether to grant the particular instance of access. Yang measures background running duration for purposes of wakelock management, while Mallozzi determines whether access to a requested resource should be permitted. Neither Mallozzi nor Yang discloses or suggests that Yang's background running duration should be used in Mallozzi's access determination. Applicant therefore respectfully submits that the proposed combination relies on reasoning that is not supported by the cited disclosures.
The Advisory Action states that "Yang teaches that tracking the duration for which an application has continuously remained in a particular state (e.g., background) is a meaningful metric for evaluating application behavior." The Office further reasons that incorporating Yang's duration-tracking technique into Mallozzi would yield "enhanced security analysis that considers how long an application has been in a state before requesting access," and that one of ordinary skill in the art would have recognized that such a modification "would enhance its ability to detect suspicious access patterns (e.g., an application that has been running in the background for an unusually long period before requesting access to a sensitive resource)."
Applicant respectfully submits that this reasoning attributes to Yang a use and
significance for its "background running duration" that Yang does not disclose or suggest.
Yang does not disclose that its "background running duration" is a metric for determining whether a request for access to a resource is suspicious. Nor does Yang disclose that an application remaining in the background for an unusually long period before requesting access to a sensitive resource indicates suspicious activity. Rather, Yang explains that the "background12
running duration" is evaluated as part of a "preset filter criterion" used in determining whether a wakelock should be forcibly released. Yang further explains that this prevents an application program and a service called by the application program from "inappropriately holding a wakelock for a long time, thereby reducing energy consumption of a terminal and reducing system resources." Yang [0049].
Thus, the Office's stated rationale - using the duration for which an application has remained in a state to provide "enhanced security analysis" and to detect "suspicious access patterns" - does not come from Yang's disclosure. Yang associates its duration determination with whether a wakelock is being inappropriately held for a long time, not with whether a subsequent request to access a protected resource is suspicious or should be granted or denied.
Mallozzi does not supply the missing connection. Mallozzi may use historical access- request information to identify suspicious activity and may determine whether permission to access a resource should be granted or denied. However, Mallozzi does not disclose or suggest that the duration for which an application continuously remained in a particular state immediately prior to the time of a request is indicative of suspicious activity, or should be used in determining whether to grant the particular instance of access.
Accordingly, the fact that Mallozzi concerns permission management and Yang
separately measures "background running duration" does not, without more, provide a reason for using Yang's duration specifically in Mallozzi's permission determination in the manner recited in claim 1. The rejection must provide an articulated reason for making that particular modification; the claimed use of the duration cannot itself supply the reason for combining the references in that manner.
The Office also states that, under KSR, the references need not address the identical technical problem and that the proposed combination represents application of a known technique to a known system to obtain a predictable result. Applicant does not dispute these general principles. The issue, however, is not whether Yang and Mallozzi are analogous art, whether Yang may be considered in combination with Mallozzi, or whether Yang must be bodily incorporated into Mallozzi. Rather, the issue is whether the cited disclosures provide a reason for using Yang's "background running duration" specifically in determining whether to grant a particular instance of resource access. For the reasons discussed above, they do not.
Similarly, the Office's reliance on In re Keller does not resolve this deficiency.
Applicant's position does not require bodily incorporation of Yang's wakelock-control system13
into Mallozzi. Applicant's position is that the cited teachings, considered together, do not disclose or suggest why Yang's "background running duration," which Yang uses for wakelock control, would have been used as recited in claim 1 - i.e., "based at least in part on ... the duration for which the application instance continuously remained in the particular state immediately prior to the time of the request, ... determining whether to grant the particular instance of access."
Accordingly, Applicant respectfully submits that the Office has not provided sufficient reasoning, supported by the disclosures of Mallozzi and Yang, for modifying Mallozzi based on Yang in the manner recited in claim 1.
(Applicant’s response filed on 09/25/2026, page 12-14).
Examiner’s Response:
The Examiner respectfully disagrees. The applicant seems to be taking the teachings of Mallozzi and Yang in pure isolation which is not how a combination is made. The question whether it would be apparent to one having ordinary skill in the art having the teachings of Mallozzi and Yang to make an obvious combination of the teachings of the arts. With this concept in mind it is apparent that one having ordinary skill in the art would be motivated to combine the teaching of tracking the duration for which an application was running in a state (i.e., background or foreground) with the method of Mallozzi for determining whether an application should be granted or denied access based on historical access information identify suspicious activity. One clear motivation being that if an application has stayed in a state for an extended duration of time or for too short of a time it could be a sign of suspicious activity. There are a plurality of malicious attacks that operate based on running in a background state for an extended period of time to collect critical information along with attacks that rapidly attack through a system which would cause an application to be active for a suspiciously short period of time. As such the combination of Mallozzi with Yang is apparent and appropriate.
Applicant's arguments with respect to amended claim 1, 8, and 14 have been fully considered but are moot in view of the new ground(s) of rejection.
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 in further of Lekkalapudi (US 10,038,761 B1), hereinafter Lekka.
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, […] (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 […] (Mallozzi ¶ 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; and
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. (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.)
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.
Mallozzi in view of Yang does not appear to explicitly teach but in related art:
(iii) and one or more particular past states of the application instance at one or more times prior to the request; […] and (iv) a sequential pattern of application states comprising at least the particular state and the one or more particular past states in an order in which the application instance transitioned through the application states prior to the request; (Lekka Col. 8 Ln. 10-67 teaches, As previously explained, run-time application context may include information such as user privileges and the current state of the web application. Application usage patterns, caused by a user operating the application, may be structured navigation patterns. Structured navigation patterns may be patterns where a user would go through a sequence of application states in order to perform a particular task in a goal directed manner. Such structured navigation patterns may therefore be systematic and reproducible. Use case-based probabilities may be used to determine a likeliness of possible future states of the web application for usage patterns that are systematic and reproducible. In one or more embodiments of the technology, the predictions made by the methods of Steps 302 and 304 may consider run-time application context. The run-time application context, obtained, for example, from the subscription configuration repository and/or from the state module map-ping repository, may be used to determine whether a predicted state may be accessible by the web application, given the current run-time application context. )
the sequential pattern of application states comprising at least the particular state and the one or more particular past states in the order in which the application instance transitioned through the application states prior to the request; (Lekka Col. 8 Ln. 10-67 teaches, As previously explained, run-time application context may include information such as user privileges and the current state of the web application. Application usage patterns, caused by a user operating the application, may be structured navigation patterns. Structured navigation patterns may be patterns where a user would go through a sequence of application states in order to perform a particular task in a goal directed manner. Such structured navigation patterns may therefore be systematic and reproducible. Use case-based probabilities may be used to determine a likeliness of possible future states of the web application for usage patterns that are systematic and reproducible. In one or more embodiments of the technology, the predictions made by the methods of Steps 302 and 304 may consider run-time application context. The run-time application context, obtained, for example, from the subscription configuration repository and/or from the state module map-ping repository, may be used to determine whether a predicted state may be accessible by the web application, given the current run-time application context. )
the sequential pattern of application states comprising the particular state and the one or more particular past states in the order in which the application instance transitioned through the application states prior to the request; (Lekka Col. 8 Ln. 10-67 teaches, As previously explained, run-time application context may include information such as user privileges and the current state of the web application. Application usage patterns, caused by a user operating the application, may be structured navigation patterns. Structured navigation patterns may be patterns where a user would go through a sequence of application states in order to perform a particular task in a goal directed manner. Such structured navigation patterns may therefore be systematic and reproducible. Use case-based probabilities may be used to determine a likeliness of possible future states of the web application for usage patterns that are systematic and reproducible. In one or more embodiments of the technology, the predictions made by the methods of Steps 302 and 304 may consider run-time application context. The run-time application context, obtained, for example, from the subscription configuration repository and/or from the state module map-ping repository, may be used to determine whether a predicted state may be accessible by the web application, given the current run-time application context. )
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 in view of Yang with Lekka, to modify the system permissions management of Mallozzi with the tracking the duration of a state of Yang. The motivation to do so, Lekka Col. 58 Ln. 62, to predict the future state of the web application, based on a current state of a web application, and/or based on current and/or past user activity that may have caused the transition of the web application through various states.
Regarding Claim(s) 2, 9, and 15 Mallozzi-Yang-Lekka teaches:
The computer-implemented method of Claim 1, (Mallozzi-Yang-Lekka 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 Mallozzi-Yang-Lekka teaches:
The computer-implemented method of Claim 1, (Mallozzi-Yang-Lekka teaches the parent claim above.) wherein the sequential pattern of application states 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 Mallozzi-Yang-Lekka teaches:
The computer-implemented method of Claim 1, (Mallozzi-Yang-Lekka teaches the parent claim above.) wherein the sequential pattern of application states 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 Mallozzi-Yang-Lekka teaches:
The computer-implemented method of Claim 1, further comprising: (Mallozzi-Yang-Lekka 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 Mallozzi-Yang-Lekka 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 Mallozzi-Yang-Lekka teaches:
The computer-implemented method of Claim 1, (Mallozzi-Yang-Lekka 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.).)
Mallozzi-Yang-Lekka 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 Mallozzi-Yang-Lekka 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, Carstens ¶ 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
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
