Prosecution Insights
Last updated: April 19, 2026
Application No. 17/456,741

Systems and Methods for Using an Identity Agent to Authenticate a User

Non-Final OA §103§112
Filed
Nov 29, 2021
Examiner
NOEL, LYDIA LOUIS-FILS
Art Unit
2437
Tech Center
2400 — Computer Networks
Assignee
Cisco Technology Inc.
OA Round
5 (Non-Final)
70%
Grant Probability
Favorable
5-6
OA Rounds
3y 1m
To Grant
91%
With Interview

Examiner Intelligence

Grants 70% — above average
70%
Career Allow Rate
66 granted / 94 resolved
+12.2% vs TC avg
Strong +21% interview lift
Without
With
+20.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
36 currently pending
Career history
130
Total Applications
across all art units

Statute-Specific Performance

§101
5.8%
-34.2% vs TC avg
§103
60.8%
+20.8% vs TC avg
§102
10.0%
-30.0% vs TC avg
§112
18.8%
-21.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 94 resolved cases

Office Action

§103 §112
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 . This Office Action is in response to Amendment filed on 09/26/2025. In the instant Amendment, claims 1, 8 and 15 have been amended; and claims 1, 8, and 15 are independent claims. Claims 1-20 have been examined and are pending. 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/26/2015 has been entered. Response to Arguments Applicants’ arguments with respect to claims 1, 8 and 15 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(d): (d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph: Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Claims 6, 13, and 20 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. claim 6 depends from claim 1 and recite " wherein the identity agent captures the security information associated with the device after receiving the request for the association of the security posture and the credential from the first browser." which is already explicitly recited in claim 1 as such, claim 6 does not further limit the subject matter of the claim from which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. 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 (i.e., changing from AIA to pre-AIA ) 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, 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-3, 5, 7-10, 12, 14-17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dani et al. (U.S 20210021629 A1; Hereinafter “Dani”) in view of Otranen et el. (U.S 20110202989 A1; Hereinafter “Otranen”) and Cockerill et al. (US 20210258304 A1; Hereinafter “Cockerill”). As per claims 1, 8, 15, Dani teaches a device (device 125) comprising one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the device to perform operations comprising (Dani: fig. 1 & 2, and para[33-34], “The processing unit 202 may control one or more of the memory unit 204, the I/O unit 206, and the communication unit 208 of the computing environment 200,”): capturing, by the identity agent (security infrastructure 140), security information (system vulnerability) associated with the device (device 125) (Dani: fig. 1, para[22-26], [51], [70-72], “The security infrastructure 140 may either be on the server 105 and/or on the endpoint device 125…Security infrastructure 140 may include at least a security profile generation unit 234, attack path generation unit 236, threat detection unit (not shown), and a scan history unit (not shown).”, “system vulnerability may be an aggregate of applications used by the computing device for which system exploitability is computed…For example, the system vulnerability may be obtained using: system vulnerability=0.5?(OS is EOL)+0.2?(is OS vulnerable)+0.2?(are some 1st level apps vulnerable e. g. browser, pdf reader, java)+0.1?(are some 2nd level apps vulnerable e. g. WinSCP, WinZip, etc.)”); generating, by the identity agent, and independent of the credential, a security posture (system exploitability information) using the security information associated with the device (Dani: para[51-54], [85-86], “the security profile generation unit 234 may determine system exploitability information of the computing device. System exploitability information, in some embodiments, indicates one or more of: the vulnerability associated with the computing device, an exposure window associated with the computing device, and a protection window associated with the computing device…the vulnerability is based on factors/data/information relating to vulnerability and patching (e.g., applying security patches or other system patches) associated with the computing device….a hardware specification of the computing device, whether the operating system of the computing device is up to date, a list of shared directories on the computing device, whether the computing device has the latest patches, whether the computing device has the latest services enabled, one or more connectivity types associated with the computing device, and types of security solutions associated with the computing device..”), wherein the security posture represents a level of susceptibility of the device to cyber-attacks (Dani: para [56], [85-86], “System exploitability information, in some embodiments, indicates one or more of: the vulnerability associated with the computing device, an exposure window associated with the computing device, and a protection window associated with the computing device….The system exploitability value included in RP 2 may be 70, for example while the system criticality associated with RP 4 may be 80, for example. Applying the steps for attack path prediction outlined above results in the attack path indicated by the dotted arrow between endpoint device 425a and file server 405c. A similar rationale may be applied to determining the attack path between endpoint device 425e and certificates store 425k”); generating, by the identity agent, an association of the security posture (system exploitability information) and the credential (user information) (Dani: para[55-56], [84], [87], “the security profile generation unit 234 may determine a risk profile for the computing device based on the user information, the system exploitability information, and the system criticality information…the risk profile is determined based on combining the user information, the system exploitability information, and the system criticality information.” Para[84], “the security profile generation unit 234 may determine user information indicating one or more user attributes associated with a vulnerability of a computing device…the one or more user attributes associated with the vulnerability of the computing device comprises:…application and system credentials of the user, sensitive user credentials such as internet information services (IIS) application pool, user credentials stored in plain-text on the computing device.., and automatic logon configurations associated with the user.”,). Dani does not explicitly teach receiving, by an identity agent installed on the device, a credential associated with a user of the device; storing, by the identity agent, the credential on the device; receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser; and communicating, by the identity agent, the association of the security posture and the credential to the first browse. However, in the related art, Otranen teaches receiving, by an identity agent (DE 109 fig. 2, para[0044]) installed on the device, a credential associated with a user of the device (UE 101) (Otranen: fig. 1-2, para[25], “In an on-boarding process 202, a subject 204 may submit claims 206 to establish an identity 208 with the service provider, e.g., service provider system 110. A process 210 of identity proofing may be performed to verify claims 206. Process 210 of identity proofing may provide a set of attributes 212 associated with identity 208 of subject 204”); storing, by the identity agent, the credential on the device (Otranen: para[0056], “Attributes 212 may be stored, for example, in user information database 140. Attributes 212 may be provided to process 214 for matching specific attributes and providing further input, for example, to a process 260 for identity assurance and authentication confidence or, for example, to a process 280 for role-based attribute based access control (RABAC) 280, as seen in FIG.”); receiving, by the identity agent, a request for the association of the security posture and the credential from a first browser (Otranen: para[0028-0029], “the interface DE 109 can be implemented as an SSO authentication enabler to advantageously share authentication session information between different client applications (e.g., client applications 111 and/or browser 113) of the UE 101…. when the interface DE 109 receives an authentication request from one of client applications 111, such as client application 111b, the DE 109 determines whether an authentication process has already been performed for the client applications 111”); and communicating, by the identity agent, the association of the security posture and the credential to the first browser ( Otranen: para[0028-0029], “If the DE 109 determines that the authentication context exists (and for example, is not outdated), the authentication context is retrieved from, for example, the cache and/or authentication database 117 and is returned to the client application 111b. Therefore, the interface DE 109 implements single sign-in functionality by caching and/or storing the authentication context and retrieving it for requesting client applications”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]). Dani in view of Otranen does not explicitly teach determining, whether to authenticate the user to the device using the security posture and the credential; authenticating the user to the device; granting the user access to the device; and wherein the identity agent captures the security information associated with the security posture of the device after receiving the request for the association of the security posture and the credential from the first browser. However, in the related art, Cockerill teaches determining, whether to authenticate the user to the device using the security posture (device factors) and the credential (user factors) (Cockerill: fig. 1, para[69], para[84-87], “the access request is generated by application 1013, which is executing on mobile device 149.”, [88-93], “access to a service provided by service provider 170 is conditioned on a successful evaluation of various risk-based factors. Mechanisms that may be used to authenticate a device, user, and/or application by evaluation server 150 include one or more of the following: requiring that an SSL client certificate be supplied for each access request by mobile device 149, evaluating authentication factors provided from network connection establishment (e.g., Wi-Fi, VPN, cellular, etc.) by mobile device 149…. factors used in a security evaluation by evaluation server 150 to allow or deny access to a service are now described below… 1. Various device factors associated with mobile device 149 include determining whether the device is compromised, such as whether an operating system is compromised, whether the device is up-to-date, such as whether a vulnerable operating system version is in use. Further factors include determining a presence of malware, or determining whether the device has a secure configuration…. 2. Various user factors may be used in the security evaluation. These factors may include biometric factors such as a fingerprint,..”, ) authenticating the user to the device; granting the user access to the device (Cockerill: para [128-129], “if the device is determined to be configured correctly, or passes a threshold of configuration correctness (even though not fully correctly configured), the client application on the device informs the service provider that the device is correctly configured…The service provider permits the device to access the service”). wherein the identity agent captures the security information associated with the security posture of the device after receiving the request, for the association of the security posture and the credential from the first browser (Cockerill: para[72-75], “The access request is transmitted to evaluation server 150, which performs a security evaluation of a configuration of mobile device 149 based on various factors,….Evaluation server 150 performs a security evaluation of risk factors associated with mobile device 149. If the evaluation determines that the configuration is not secure, server 150 blocks access by mobile device 149 to the service….the security evaluation is based on data received from the mobile device 149…this data is received from component 104, or from another software component such as component 106 that is on mobile device 149. The data sent to evaluation server 150 is obtained from the mobile device using this software component.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modified the modified Dani to determine whether to authenticate a user and grant access using the device security posture and user credentials as taught by Cockerill, it will improve security by preventing access from vulnerable devices, and ensure that authentication decisions are based on a current and accurate device security state (Cockerill: para[10]). As per claims 2, 9, and 16, Dani in view of Otranen and Cockerill teaches the independent claims 1, 8 and 15. Otranen teaches wherein: the credential indicates that the user is successfully logged into an operating system of the device (Otranen: para[0023], “if the authentication is successful (e.g., the user credentials are valid), the authentication server 107 generates and returns a valid authentication context to the DE 109. In one example, the success of the authentication is determined by the authentication server 107 by comparing the received user credentials with user credentials stored in a database (not shown) associated with the authentication server 107. However, it is contemplated that other authentication schemes and protocols can be used to authenticate the client applications 111 and/or user(s) of the client applications.”); and the credential is one of the following: a single sign-on token; a passwordless credential; or a single sign-on credential (Otranen: para[0020-0022], “the term "authentication context" can include: 1) information regarding initial identification mechanisms of a user, client, customer, etc.; (2) information regarding authentication mechanism or method (e.g., passwords, one time password, a cookie, a limited use key, a secret key, a consumer key, an access token, etc.); (3) information regarding storage and protection of credential (e.g., password rules, smart carts, etc.); and the like”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]). As per claims 3, 10, and 17, Dani in view of Otranen and Cockerill teaches the independent claims 1, 8 and 15. Dani teaches wherein the security posture information is associated with one or more of the following: a patch level of one or more operating systems associated with the device; a patch level of one or more applications installed on the device; a presence of one or more security applications associated with the device; and a presence of one or more security controls associated with the device (Dani: para[69], [85] “the vulnerability is based on factors/data/information relating to vulnerability and patching (e.g., applying security patches or other system patches) associated with the computing device. The factors/data/information relating to vulnerability and patching include on one or more of: a hardware specification of the computing device, whether the operating system of the computing device is up to date, a list of shared directories on the computing device, whether the computing device has the latest patches, whether the computing device has the latest services enabled, one or more connectivity types associated with the computing device, and types of security solutions associated with the computing device.”. As per claims 5, 12 and 19, Dani in view of Otranen and Cockerill teaches the independent claims 1, 8 and 15. Cockerill teaches wherein the security posture is a conceptual diagram that illustrates potential risk items identified by the identity agent, the potential risk items comprising one or more from the following list of potential risk items: unpatched software; a password issue; phishing; ransomware; a denial-of-service attack; a misconfiguration; and an encryption issue. (Cockerill: para[78-81], “the security evaluation determines that a risk configuration of mobile device 149 passes a security threshold. If the threshold is passed, server 150 sends a communication to service provider 170 and/or identity provider 172 regarding the passed security threshold. This communication may include data obtained from mobile device 149 and used in the security evaluation above.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modified the modified Dani to determine whether to authenticate a user and grant access using the device security posture and user credentials as taught by Cockerill, it will improve security by preventing access from vulnerable devices, and ensure that authentication decisions are based on a current and accurate device security state (Cockerill: para[10]). As per claims 7 and 14, Dani in view of Otranen and Cockerill teaches the independent claims 1, 8 and 15. Otranen teaches wherein: the credential is generated by the user or an authentication service (Otranen: para[23] “if the authentication is successful (e.g., the user credentials are valid), the authentication server 107 generates and returns a valid authentication context to the DE 109”); and the request is associated with an application that is federated behind the authentication service (Otranen: fig. 4, para[54] “the authentication request can include information associated to the client application 111a, a user of the client application, an application server that the client application 111a desires to access, etc.”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Dani with the process discussed in Otranen, it will enable sharing of authentication information between different client applications and reduces the use of computing, network and power resources of the device (Otranen: para[30]). Claims 4, 11, and 18, are rejected under 35 U.S.C. 103 as being unpatentable over Dani et al. (U.S 20210021629 A1; Hereinafter “Dani”) in view of Otranen et el. (U.S 20110202989 A1; Hereinafter “Otranen”), Cockerill et al. (U.S 20210258304 A1; Hereinafter “Cockerill”), and Tulshibagwale et al. (U.S 20220191200 A1; Hereinafter “Tulshibagwale”). As per claims 4, 11, and 18, Dani in view of Otranen and Cockerill teaches the independent claims 1, 8 and 15. Dani in view of Otranen and Cockerill does not teach wherein the identity agent receives the credential from a login client installed on the device or from a second browser installed on the device. However, in the related art, Tulshibagwale teaches wherein the identity agent receives the credential from a login client installed on the device or from a second browser installed on the device (Tulshibagwale: fig. 4, para[0028],[0030-0031] “That is, the application service 130 requests the authenticator 170 to authenticate the user 12 so that the user 12 may access a resource associated with the application service 130. The application service 130 may send the authentication request 132 to the remote system 140 in response to a selection or indication from the user 12… As discussed in more detail below, the authenticator 170 may receive the authentication credentials 20 in response to prompting the user 12 via, for example, a display of the user device 10, to provide the authentication credentials 20”). Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Dani with Tulshibagwale, it enable secure authentication information and prevent privacy and security concerns (Tulshibagwale [21]. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. JP 2004259020 A - To provide an authentication system or the like capable of limiting connection of an information terminal device 20 as is infected with computer virus, even if the individual authentication of a user is successful . Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00. 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, Alexander Lagor can be reached on (571)-270-5143. 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. /L.L.N./Examiner, Art Unit 2437 /BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Read full office action

Prosecution Timeline

Nov 29, 2021
Application Filed
Nov 02, 2023
Non-Final Rejection — §103, §112
Feb 08, 2024
Applicant Interview (Telephonic)
Feb 08, 2024
Response Filed
Feb 08, 2024
Examiner Interview Summary
Apr 15, 2024
Final Rejection — §103, §112
Jul 18, 2024
Request for Continued Examination
Jul 24, 2024
Response after Non-Final Action
Nov 16, 2024
Non-Final Rejection — §103, §112
Feb 21, 2025
Applicant Interview (Telephonic)
Feb 21, 2025
Response Filed
Feb 21, 2025
Examiner Interview Summary
Jun 02, 2025
Final Rejection — §103, §112
Sep 08, 2025
Examiner Interview Summary
Sep 08, 2025
Applicant Interview (Telephonic)
Sep 26, 2025
Request for Continued Examination
Oct 07, 2025
Response after Non-Final Action
Jan 08, 2026
Non-Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12587846
DEVICE, METHOD AND COMPUTER READABLE MEDIUM FOR RESISTING DOWNGRADE ATTACKS
2y 5m to grant Granted Mar 24, 2026
Patent 12563090
RESILIENT HIGH-BANDWIDTH STATE-TRANSITION COMPUTER
2y 5m to grant Granted Feb 24, 2026
Patent 12520133
THIRD PARTY CONTROL OF A USER EQUIPMENT
2y 5m to grant Granted Jan 06, 2026
Patent 12520140
CREDENTIALED WIRELESS FOB TO CONTROL POWER TOOL DEVICES
2y 5m to grant Granted Jan 06, 2026
Patent 12500748
FORWARDING DEVICE, KEY MANAGEMENT SERVER DEVICE, COMMUNICATION SYSTEM, FORWARDING METHOD, AND COMPUTER PROGRAM PRODUCT
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
70%
Grant Probability
91%
With Interview (+20.7%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 94 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month