Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The present Office Action is responsive to communications received 8/18/2026. Applicant's submission filed on 12/22/2025 has been entered. Claims 1-20 are pending.
Response to Arguments
Regarding the prior art rejection, Applicant’s arguments are persuasive.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-9, 12-15, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11874934 to Rao et al., hereinafter Rao, in view of US 20200351297 to Seiver et al., hereinafter Seiver.
Regarding claim 1, Rao discloses
A method comprising:
collecting, by a processor of a user device of a user (fig. 2), vulnerability-related metrics of a plurality of applications hosted by the user device (10:15-19, 24:45-62, 26:21-45, Fig. 6, 604: user device hosts system 100 including ML that obtains security threats or vulnerabilities associated with the computing components such as hardware and software applications);
identifying, by the processor of the user device, a plurality of weighting values, wherein each weighting value of the plurality of weighting values corresponds to a vulnerability-related metric of the vulnerability-related metrics; determining, by the processor of the user device, based on the vulnerability-related metrics of the plurality of applications hosted by the user device and the plurality of weighting values, a first risk level of the user device (29:23-31: “compute a weighted average or a weighted sum of each threat value corresponding to a security vulnerability description to generate the respective computing aspect impact levels”);
responsive to determining that the first risk level satisfies a criterion, performing, by the processor of the user device, a security-based action associated with the user device (31:21-61:if impact level exceeds a threshold, “update the graphical layout to only include a graphical representation of each high-impact computing aspects … to enable a user to quickly identify which computing aspects of a given software application are most impacted by one or more security vulnerabilities”, 32:5-10: determine mitigated-computing-aspect impact levels for each computing aspect” );
Rao does not disclose but in an analogous art, Seiver teaches determining vulnerability of network devices (Abstract), and assigning weights to vulnerabilities scores to obtain a vulnerability priority score as a weighted sum of vulnerabilities scores ([0312]). Seiver discloses
receiving, by the processor of the user device (Fig. 9A, [0172]) , a plurality of adjusted weighting values associated with the vulnerability-related metrics, wherein each adjusted weighting value of the plurality of adjusted weighting values is an adjusted value of a corresponding weighting value of the plurality of weighting values ([0212]: determine metric measuring a degree to which the network device is running exploitable software, [0214] metric measuring numbers of shared account; [0218]: assign weight to metrics, determine overall value [0312]; modify weights applied to particular metrics [0327])); and
in response to a triggering event comprising at least one of detecting user activity on the user device ([0326]: user applies queries or filters to refine accounts, use other aspects associated with metrics) or receiving a request for an updated risk level ([0326]: manipulate time slider to specify times to apply the filter, Fig. 9A: input to configure display of the risk on the user interface), determining, by the processer of the user device, based on the vulnerability-related metrics of the plurality of applications hosted by the user device ([0303][0304]: metrics for applications hosted in the device) and the plurality of adjusted weighting values, the updated risk level of the user device ([0327]:determine risk value using updated weighed metrics), wherein each vulnerability-related metric of the vulnerability-related metrics is weighted by the corresponding adjusted weighting value ([0327]).
Therefore, it would have been obvious to a skilled artisan before the effective filing date of the instant application to apply adjusted weighted values to vulnerability metrics of Rao as taught by Seiver and obtain an updated risk level in response to a triggering event comprising user activities or receiving a request, and based on updated weight values as claimed because it would allow to keep up-to-date the vulnerability level of a system and optimize remediation, allowing the user to create “metrics that are specific to the user's networks, enabling the metrics to be updated” and configurable according to needs of the user” (Seiver [0289]).
Regarding claim 2, Rao in view of Seiver discloses the method of claim 1, wherein determining the first risk level of the user device comprises: determining a risk score by calculating an average of the vulnerability-related metrics, each vulnerability-related metric weighted by a corresponding weighting value of the plurality of weighting values; and determining the first risk level of the user device based on the risk score (Rao 29:23-31: “compute a weighted average or a weighted sum of each threat value corresponding to a security vulnerability description to generate the respective computing aspect impact levels).
Regarding claim 5, Rao in view of Seiver discloses the method of claim 1, wherein the vulnerability-related metrics comprise at least one of: identified current vulnerabilities associated with the user device, a current location of the user device, network activity associated with the user device, or one or more websites accessed on the user device (Rao 10:15-19, 24:45-62, 26:21-45, Fig. 6, 604: user device hosts system 100 including ML that obtains security threats or vulnerabilities associated with the computing components such as hardware and software applications).
Regarding claim 6, Rao in view of Seiver discloses the method of claim 1, wherein the security-based action comprises at least one of: sending a first notification to the user of the user device, sending a second notification to an application running on the user device, or sending a third notification to a second user device connected to the user device (Rao 31:21-61:if impact level exceeds a threshold, “update the graphical layout to only include a graphical representation of each high-impact computing aspects … to enable a user to quickly identify which computing aspects of a given software application are most impacted by one or more security vulnerabilities).
Regarding claim 7, Rao in view of Seiver discloses the method of claim 1, wherein the first risk level of the user device is determined in response to a second triggering event (Rao 18:3-25: the second triggering event being the use of a firewall, that causes the threat value to be mitigated lower).
Regarding claims 8, 14, the claims recite substantially the same content as claim 1, and are rejected as set forth for claim 1.
Regarding claims 9, 15, the claims recite substantially the same content as claim 2, and are rejected as set forth for claim 2.
Regarding claims 12, 18, the claims recite substantially the same content as claim 5, and are rejected as set forth for claim 5.
Regarding claims 13, 19, the claims recite substantially the same content as claim 6, and are rejected as set forth for claim 6.
Regarding claim 20, the claim recites substantially the same content as claim 7, and are rejected as set forth for claim 7.
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rao in view of Seiver, as applied to claims 1, 8 and 14, and further, in view of US 20200285752 to Wyatt et al., hereinafter, Wyatt.
Regarding claim 3, Rao in view of Seiver discloses the method of claim 1. Rao in view of Seiver does not, but Wyatt in an analogous art, teaches: sending a request to a second user device ([0109]: send request to access a service to service provider); receiving, from the second user device, a second request requesting a risk level of the user device ([0109]: forward request to evaluation server); providing, to the second user device, at least one of the first risk level of the user device ([0113]: send message to service provider regarding the security threshold) or the updated risk level of the user device; and receiving, from the second user device, a notification of whether the request has been granted or denied in view of the at least one of the first risk level of the user device ([0114][0116]: obtain from service provider a token encoding a risk level, the risk level to configure the service) or the updated risk level of the user device.
Therefore, it would have been obvious to a skilled artisan before the effective filing date of the instant application to provide a risk level to the device as taught by Wyatt because it would allow controlling the safe access of mobile applications to service providers and would “keep users or administrators continuously aware of security status, recent security-related events, and potential security threats without requiring them to repeatedly seek out security-related information” (Wyatt, [0035]).
Regarding claims 10, 16, the claims recite substantially the same content as claim 3, and are rejected as set forth for claim 3.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rao in view of Seiver, as applied to claims 1, 8 and 14, and further, in view of US 20190028492 to Coleman et al., hereinafter, Coleman and US 12149530 to Lind et al., hereinafter Lind.
Regarding claim 4, Rao in view of Seiver discloses the method of claim 1, but does not teach: receiving, from a second user device, a request to access the user device, wherein the request comprises a second risk level of the second user device; and responsive to determining that the second risk level of the second user device satisfies a second criterion, denying the request from the second user device to access the user device.
However, Coleman in an analogous art, discloses:
receiving, from a second user device, a request to access the user device, wherein the request comprises a second risk level of the second user device; (In [0041], a first user device that can receive inputs from a first user; a second user device that can receive inputs from a second user; a third user device; and at least one server. The at least one server can: receive communications corresponding to a plurality user inputs provided to the first user device and the second user device; generate a second risk prediction for the second user with the machine-learning algorithm, second risk predictions are based on features generated from the received communications; determine inclusion of the first risk prediction in a first cohort associated with a first risk level and a second risk prediction in a second cohort associated with a second risk level.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of Rao/Seiver with the teachings of Coleman to include receiving, from a second user device, a request to access the user device, wherein the request comprises a second risk level of the second user device, as taught by Coleman because it allows the recipient cohort communications to include information associated the second risk level. (Coleman [0042]).
Rao in view of Seiver combined to Coleman does not but Lind disclose:
responsive to determining that the second risk level of the second user device satisfies a second criterion, denying the request from the second user device to access the user device. (4:25-39, as part of authenticating an access request received from a client device using authentication credentials of the enrolled client device 130, the authentication system 110 receives or otherwise obtains device metadata corresponding to the client device requesting access. The authentication system 110 compares the device metadata for the client device requesting access to stored device metadata for the enrolled client device 130. Based on the comparison, the authentication system 110 may detect device metadata anomalies for device metadata values of the same type from the current device metadata and the stored device metadata. Based on detection of device metadata anomalies, the authentication system 110 determines a risk level for the client device and uses the risk level to determine whether to authorize or deny the access request.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Rao/Seiver/Coleman to include: responsive to determining that the second risk level of the second user device satisfies a second criterion, denying the request from the second user device to access the user device, as taught by Lind because it allows metadata, which includes risk level of client device, to be included when making access request. (Lind 9:44-62).
Regarding claims 11, 17, the claims recite substantially the same content as claim 4, and are rejected as set forth for claim 4.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CATHERINE B THIAW whose telephone number is (571)270-1138. The examiner can normally be reached Monday-Thursday 7am-5pm with Flex.
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.
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.
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 9/30/2026
