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 12/22/2025 has been entered. Claims 1-20 are pending.
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 11516222 to Srinivasan et al., hereinafter Srinivasan, and in further view of US 20200042723 to Krishnamoorthy et al, hereinafter Krishnamoorthy.
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, Srinivasan teaches determining vulnerability of software packages within a user’s computing environment (6:30-53), and assigning weights to vulnerabilities scores to obtain a vulnerability priority score as a weighted sum of vulnerabilities scores (14:25-44). Srinivasan discloses
receiving, by the processor of the user device, a plurality of adjusted weighting values associated with the vulnerability-related metrics; and in response to a triggering event comprising at least one of detecting user activity on the user device, determining, by the processer of the user device, based on the plurality of adjusted weighting values, an updated risk level of the user device (15:41-59, Fig. 2: periodically receive data from different sources such as the device activity data, the threat intelligence data … the device activity data include user activities such as logins, file system operations (15:60-57, 16:1-2), login patterns, combination of user credentials … correlated with attempts to exploit an vulnerability (i.e triggering event comprising at least detecting user activity on the user device) using the threat intelligence service (17:5-22; 32:63-67); a threat score is computed and provided to the weighting function as a temporal modifier with the effect of increasing the vulnerability priority score relative to the baseline priority score indicated by the vulnerability description (i.e. updated risk level based on adjusted weighting values) (33:1-11); the temporal score “may be determined, in turn, by various subscores which serve as inputs to a weighting function defined by the VSS vulnerability metric as illustrated in FIGS. 6A-6C and FIG. 7” ((14:40-45), disclosing: “a plurality of adjusted weighting values associated with the vulnerability-related metrics”.
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 Srinivasan and obtain an updated risk level in response to a triggering event comprising user activities and based on updated weight values as claimed because it would allow to keep up-to-date the vulnerability level of a system (Srinivasan 12:48-58) and optimize remediation (12:59-67, 13:1-15). Rao in view of Srinivasan does not teach a triggering event comprising receiving a request for an updated risk level.
In an analogous art, Krishnamoorthy discloses assessing a risk level of identity fraud, by collecting user authentication activities and device attributes ([0014]. Krishnamoorthy discloses:
in response to a triggering event comprising at least one of the detecting user activity on the user device ([0021][0031]: upon receiving a user authentication request, determine a new risk score for the user based on attributes associated with user activities or associated with the device), or receiving a request for an updated risk level (Fig. 10: dashboard for administrator to view updated risk level described in Fig. 9), determining, by the processer of the user device, based on the plurality of adjusted weighting values, an updated risk level of the user device ([0041], Fig. 9, 920: update risk score by calculating sum of weighted attributes). It would have been obvious to a skilled artisan before the effective filing date of the instant application to provide an updated risk level in response to detecting user activity or receiving a request as taught by Krishnamoorthy because it would provide a friendly user interface (dashboard) for displaying risk level that take into account changes to user or device attributes (Krishnamoorthy [0055]).
Regarding claim 2, Rao in view of Srinivasan and Krishnamoorthy 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 Srinivasan and Krishnamoorthy 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 Srinivasan and Krishnamoorthy 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 Srinivasan and Krishnamoorthy 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 Srinivasan and Krishnamoorthy, 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 Srinivasan and Krishnamoorthy discloses the method of claim 1. Rao in view of Srinivasan 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 Srinivasan and Krishnamoorthy, 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 Srinivasan and Krishnamoorthy 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/Srinivasan/ Krishnamoorthy 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/Srinivasan/Krishnamoorthy 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/Srinivasan/Krishnamoorthy/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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Govindasamy et al 20230169179 discloses receiving metrics identifying vulnerabilities in an application; assigning weights to the metrics using collected information; and generating a predictive score for the vulnerabilities using a machine learning model.
Somasundaram et al 20190238584 discloses identifying vulnerability in a device, calculating vulnerability score by assigning weights to impact metric and exploitability metric.
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.
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.
CATHERINE B. THIAW
Supervisory Patent Examiner
Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 5/14/2026
Prosecution Insights