Detailed Action
This office action is in response to applicant’s response to Requirement for Election/Restriction. Claims 1-17 and 21 are pending. Claims 18-20 are cancelled.
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 .
Election/Restrictions
Applicant's election with traverse in the reply filed on 07/01/20026 is acknowledged. The traversal is found persuasive. Accordingly, the restriction requirement as between Species I and Species II is hereby withdrawn. Claims 1-17 and 21 are pending and have been examined on the merits herein.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) (1-3 & 9-12 & 21) and (13-14 & 17) is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by YANG US 11930015 B2.
YANG demonstrates, in regard to claim number: 1. (Original) A method (YANG column 1 lines 18-21 “More particularly, some embodiments of the present disclosure provide systems and methods for authenticating users of a data processing platform”) for managing access to enterprise resources(YANG column 2 lines 15-19 “In some platforms, platform authentication systems are implemented as an application server and services that act as a service provider that manages access to applications that are provided by the platform”), the method comprising: receiving a request from a user to access an enterprise resource(YANG column 11 lines 8-11 “As such, in some implementations, when the authentication system 104 receives a request from a client device to establish an access session to perform one or more actions on the data of the data processing platform 102”); determining an assurance level of the enterprise resource(YANG column 11 lines 8-14 “As such, in some implementations, when the authentication system 104 receives a request from a client device to establish an access session…In some examples, the IdP then performs first or second level authentication as desired”, column 6 lines 50-56 “This may occur when, for example, a user is logged in already, but makes a request “in-session” to perform an action for which they do not have the required privileges. In such cases, they may need to perform some further authentication in order to elevate their current login session to one that permits the requested actions.”, column 8 lines 31-34 “In certain examples, upon receiving an access request for a particular data resource, the authentication system 104 accesses a separately stored policy object associated with the particular data resource.”, columns 10-11 lines 66-7 “an external customer organization may require two factor authentication for all or just some of its users and possibly for all or some actions on all or some data. The user manager and thereafter when a user of the organization sends a login request to the authentication system, the authentication system identifies the user as requiring diversion to the user manager for enhanced login workflow before deciding on whether to allow or deny the request of the login session, in some examples.” YANG provides for an assurance level in that the IdP performs second level authentication to further assure authenticity on a requirement basis, or policy object (assurance level), that is retrieved in association with the resource.); determining, based on the assurance level of the enterprise resource, whether the user has an approved authenticator to access the enterprise resource and whether to allow access to the enterprise resource (YANG column 6 lines 49-56 “In some embodiments, embodiments relate to establishing access sessions within an existing login session. This may occur when, for example, a user is logged in already, but makes a request “in-session” to perform an action for which they do not have the required privileges. In such cases, they may need to perform some further authentication in order to elevate their current login session to one that permits the requested actions.”, column 7 lines 4-10 “(14) Some embodiments involve actions performed at or in association with an authentication system 104 (see FIG. 1) which controls whether or not to permit login or access sessions for users to enable one or more actions on one or more data resources based on a predetermined login workflow and, if so, may, in some embodiments, restrict which resources can be accessed”)based, at least in part, on whether the user has an approved authenticator (YANG column 6 lines 39-43 “A login session includes a session between a client and another system, e.g., a data processing platform server, in which a user may perform one or more actions on data of the data processing platform following authentication of login credentials.” The approved authenticator is mapped to the authenticated login credential), wherein the user is allowed to perform authentication using the approved authenticator if the user has the approved authenticator to access the enterprise resource(YANG column 2 lines 32-36 “External identity providers (IdPs) validate credentials for a user and provide user identifiers and permissions such as user group information and other attributes to the authentication system of the platform.”, column 6 lines 39-43 “A login session includes a session between a client and another system, e.g., a data processing platform server, in which a user may perform one or more actions on data of the data processing platform following authentication of login credentials.”), and the user is denied access to the enterprise resource if the user does not have the approved authenticator(YANG column 7 lines 4-11 “Some embodiments involve actions performed at or in association with an authentication system 104 (see FIG. 1) which controls whether or not to permit login or access sessions for users to enable one or more actions on one or more data resources based on a predetermined login workflow and, if so, may, in some embodiments, restrict which resources can be accessed and/or which actions can be taken on resources, based on the context of a login request.”).
YANG demonstrates, in regard to claim number: 2. (Original) The method of claim 1, further comprising: if the user is authenticated using the approved authenticator: granting the user access to the enterprise resource(YANG column 11, lines 12-36 “In some examples, the IdP then performs first or second level authentication as desired and when the authentication is correct, sends the user ID IdP1 120, associated group member information 124, realm information identifying which realm the IdP is in and sends the information to the authentication system as a follow up to the initial request. As such, the authentication system 104 receives from the external identity provider 122 of the first realm the user identity provider identifier 120 as associated with the initial request. The authentication system 104 grants permission to perform the one or more actions on the data of the data processing platform based at least in part on the received user identity provider identifier 120. For example, the authentication system grants permission to perform the one or more actions on the data of the data processing platform by determining if the received user identity provider identifier 120 matches either of the first user identity provider identifier or the second user identity provider identifier that is mapped to the unique user platform identifier in the multi-realm single user database 112. If there is a match, the authentication system 104 uses the unique user platform ID within the data processing platform as a unique user identifier for granting permissions to resources of the data processing platform during the access session.”); or if the user is not authenticated using the approved authenticator: denying the user access to the enterprise resource(YANG column 7 lines 4-10 “Some embodiments involve actions performed at or in association with an authentication system 104 (see FIG. 1) which controls whether or not to permit login or access sessions for users to enable one or more actions on one or more data resources based on a predetermined login workflow and, if so, may, in some embodiments, restrict which resources can be accessed”).
YANG demonstrates, in regard to claim number: 3. (Original) The method of claim 1, wherein the assurance level is high (YANG column 6 lines 49-56 “In some embodiments, embodiments relate to establishing access sessions within an existing login session. This may occur when, for example, a user is logged in already, but makes a request “in-session” to perform an action for which they do not have the required privileges. In such cases, they may need to perform some further authentication in order to elevate their current login session to one that permits the requested actions.” YANG provides for a high assurance level in that requested actions have associated hierarchical permission requirements associated to hierarchical user authentication identifiers that represent the level of authentication, or assurance. See further YANG column 11 lines 12-25 “In some examples, the IdP then performs first or second level authentication as desired and when the authentication is correct, sends the user ID IdP1 120, associated group member information 124… to the authentication system as a follow up to the initial request. As such, the authentication system 104 receives from the external identity provider 122 of the first realm the user identity provider identifier 120 as associated with the initial request. The authentication system 104 grants permission to perform the one or more actions on the data of the data processing platform based at least in part on the received user identity provider identifier 120.”), where YANG demonstrates evaluation on whether an authentication is at a high enough position within the hierarchy to permit a particular action by a particular user, providing a high assurance level by the second level authentication.), and the approved authenticator includes identity verification by an identity verification service(YANG column 2 lines 4-7 “It is also known for platform provider organizations to outsource at least part of their one-factor authentication service or other multi-factor service to external services called Identity Providers (IdP).”, column 2 lines 37-45 “For example, an identity provider is a source for user and group information and attributes. An external identity provider gives applications the ability to validate users or services as they login and understand information about these users. As one example, security assertion markup language (SAML) is an XML based data format used to exchange authentication and authorization data between a service provider in the platform, such as an authentication system, and an identity provider.”).
YANG demonstrates, in regard to claim number: 9. (Original) The method of claim 1, wherein the assurance level is low (YANG column 6 lines 49-56 “In some embodiments, embodiments relate to establishing access sessions within an existing login session. This may occur when, for example, a user is logged in already, but makes a request “in-session” to perform an action for which they do not have the required privileges. In such cases, they may need to perform some further authentication in order to elevate their current login session to one that permits the requested actions.” YANG provides for a low assurance level in that requested actions have associated hierarchical user authentication identifiers (YANG column 11 lines 12-25 “In some examples, the IdP then performs first or second level authentication as desired and when the authentication is correct, sends the user ID IdP1 120, associated group member information 124… to the authentication system as a follow up to the initial request. As such, the authentication system 104 receives from the external identity provider 122 of the first realm the user identity provider identifier 120 as associated with the initial request. The authentication system 104 grants permission to perform the one or more actions on the data of the data processing platform based at least in part on the received user identity provider identifier 120.”), which YANG demonstrates to be evaluated on whether the authentication is at a high enough position within the hierarchy to permit a particular action by a particular user, providing a low assurance level by the first level authentication that is insufficient for actions requiring a second level authentication.), and the approved authenticator is a registered authenticator (YANG column 14 lines 16-21 “As illustrated, the user provider identifier has been registered for each external identity provider as listed in a table. A linking table includes data or other linking mechanism that links other user IDs registered for other external identity providers for the same user.”).
YANG demonstrates, in regard to claim number: 10. (Original) The method of claim 1, wherein the enterprise resource provides access to register an authenticator (YANG column 6 lines 38-45 “Example embodiments relate to establishing access sessions, for example login sessions. A login session includes a session between a client and another system, e.g., a data processing platform server, in which a user may perform one or more actions on data of the data processing platform following authentication of login credentials. Actions may vary from reading, authoring, editing, transforming, merging, or executing one or more data resources.”, column 9 lines 8-14 “For example, in one example, the authentication system 104 provides user interfaces to a user of the client device 118… that allow the user to register policies associated with data resources stored in the resource database 116.”, columns 9-10 lines 62-5 “In one example… the authentication system 104 stores in the multi-realm single user database 112, a unique user platform identifier (UUPID) that is mapped to a first identity provider identifier 120 (e.g., an IdP ID is registered with IdP 122) that is associated with an external identity provider 122 of a first realm and is associated with another external identity provider 130 of a second realm that was registered with the authentication system 104 by the different identity provider but for the same user.” In the example that a user registers an identity provider identifier, YANG provides for wherein the enterprise resource provides access to register an authenticator.).
YANG demonstrates, in regard to claim number: 11. (Original) The method of claim 1, wherein the enterprise resource provides access to change a password associated with the user(YANG column 1 lines 51-63 “When providing access to cloud-based computing services and data resources, such as a data processing platform for performing said one or more tasks, an authentication service may be provided that typically provides a basic login workflow… some external organizations may wish to enable a login session for their data resources using a simple one-factor authentication method, e.g., username and password.”, column 6 lines 38-45 “Example embodiments relate to establishing access sessions, for example login sessions. A login session includes a session between a client and another system, e.g., a data processing platform server, in which a user may perform one or more actions on data of the data processing platform following authentication of login credentials. Actions may vary from reading, authoring, editing, transforming, merging, or executing one or more data resources.” In the example that a user logs in to edit their password, YANG provides for wherein the enterprise resource provides access to change a password associated with the user.).
YANG demonstrates, in regard to claim number: 12. (Original) The method of claim 1, wherein determining the assurance level of the enterprise resource includes: determining an authorization level of the user (YANG column 6 lines 49-56 “In some embodiments, embodiments relate to establishing access sessions within an existing login session. This may occur when, for example, a user is logged in already, but makes a request “in-session” to perform an action for which they do not have the required privileges. In such cases, they may need to perform some further authentication in order to elevate their current login session to one that permits the requested actions.” YANG provides for an authorization level in that requested actions have associated hierarchical permission requirements mapped to hierarchical user authentication identifiers (YANG column 11 lines 12-25 “In some examples, the IdP then performs first or second level authentication as desired and when the authentication is correct, sends the user ID IdP1 120, associated group member information 124… to the authentication system as a follow up to the initial request. As such, the authentication system 104 receives from the external identity provider 122 of the first realm the user identity provider identifier 120 as associated with the initial request. The authentication system 104 grants permission to perform the one or more actions on the data of the data processing platform based at least in part on the received user identity provider identifier 120.”), which YANG demonstrates to be evaluated on whether it is at a high enough position within the hierarchy to permit a particular action by a particular user.); and selecting the assurance level from a plurality of assigned assurance levels based on the authorization level of the user(YANG column 11 lines 8-18 “As such, in some implementations, when the authentication system 104 receives a request from a client device to establish an access session to perform one or more actions on the data of the data processing platform 102, the request is redirected to the appropriate external identity provider. In some examples, the IdP then performs first or second level authentication as desired and when the authentication is correct, sends the user ID IdP1 120, associated group member information 124, realm information identifying which realm the IdP is in and sends the information to the authentication system as a follow up to the initial request.” In the example that a second level of authentication is required based on the user’s first authentication challenge, YANG provides for wherein the assurance level is selected from a plurality of assigned assurance levels based on the authorization level of the user.).
YANG demonstrates, in regard to claim number: 21. (New) The method of claim 1, wherein the enterprise resource includes an application(YANG column 1 lines 33-37 “A data resource may, for example, be a data analysis application, a data transformation application, a report generating application, a machine learning process, a spreadsheet or a database, or part of a spreadsheet or part of a database, e.g. records.”, column 8 lines 7-12 “If one or more login challenges sent to the client device 118 are all successfully responded to, the authentication system 104 is configured to establish a login or access session for the user of the client device 118 to perform actions on data resources on any one or more of the applications 109-111 and the resource database 116.”).
Claims 13-14 & 17 recite substantially similar limitations as claims 1, 3, and 9 in the form of a system such as demonstrated by YANG (ABSTRACT “A system and method for authenticating users of a data processing platform stores a mapping of a unique user platform identifier to multiple user identity provider identifiers associated with multiple realms for a same user.”). Thus, claims 13-14 & 17 are rejected under similar rationale as claims 1, 3, and 9.
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.
Claim(s) (4-8) (15-16) is/are rejected under 35 U.S.C. 103 as being unpatentable over YANG in view of ROBELL; James Frederick (US 20230281604 A1), hereafter ROBELL.
Regarding claim 4, YANG provides teaching for wherein the approved authenticator is a registered verified authenticator (YANG column 14 lines 16-21 “As illustrated, the user provider identifier has been registered for each external identity provider as listed in a table. A linking table includes data or other linking mechanism that links other user IDs registered for other external identity providers for the same user.”) and other previously demonstrated limitations. However, based on the examiner’s present interpretation, YANG does not appear to explicitly teach the following limitations for which ROBELL is relied upon to demonstrate:
wherein the assurance level is medium (ROBELL [0017] “Furthermore, the aforementioned identity documents have varying levels of security, trustworthiness, and identity assurance and add complexity to the current ID ecosystem 100.” While YANG is used to demonstrate both a high and low assurance level, ROBELL demonstrates higher resolution within the range of assurance with the “varying levels” of identity assurance, providing for a medium assurance level.).
Since both YANG and ROBELL are from the same field of endeavor as both are directed to identity authentication-based access control, which is within the same field of endeavor as the claimed invention, it would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify and combine the teachings of YANG and ROBELL by incorporating the teachings of ROBELL into YANG for improving the resolution of measurement for authenticity based access functions as claimed. The motivation to combine is to improve security of authenticity-based access controls (YANG [AB], ROBELL [AB]). This motivation is equally applicable to rejections hereafter.
YANG-ROBELL demonstrates, in regard to claim number: 5. (Original) The method of claim 4, further comprising: receiving authenticator information associated with an authenticator(YANG column 10 lines 5-11 “Once an identity provider authenticates a particular user, the corresponding user ID (USERID_IdP1) along with associated permissions such as group member information 124 and other attributes 126 including data representing a realm from which the IdP is in, is sent to the authentication system 104 through the network 113.”); authenticating the user using identity verification; and registering the authenticator as the registered verified authenticator(YANG columns 9-10 lines 64-5 “the authentication system 104 stores in the multi-realm single user database 112, a unique user platform identifier (UUPID) that is mapped to a first identity provider identifier 120 (e.g., an IdP ID is registered with IdP 122) that is associated with an external identity provider 122 of a first realm and is associated with another external identity provider 130 of a second realm that was registered with the authentication system 104 by the different identity provider but for the same user.).
YANG-ROBELL demonstrates, in regard to claim number: 6. (Original) The method of claim 5, wherein authenticating the user using identity verification includes: receiving user information associated with the user(YANG column 1 lines 60-63 “For example, some external organizations may wish to enable a login session for their data resources using a simple one-factor authentication method, e.g., username and password.”); receiving document information associated with an identification document of the user(ROBELL [0024] “In some implementations, the server(s) 320 receive ID info (e.g., ID info 513 in FIG. 5) as inputs (e.g., inputs 401 in FIG. 4) via a front-end NFT ID portal (e.g., mobile app and/or website, not shown by FIGS. 2 and 3). The ID info may include, for example, physical or electronic ID documents and/or other info such as contact info, authentication credentials, biometric data, and/or the like.”); comparing the user information to the document information(ROBELL [0003] “Identity verification services are often used by businesses and/or government agencies to ensure that information provided by users is associated with the identity of a real person. The identity of the real person may be verified using identity information indicated by physical identity documents”); and if the user information matches the document information: authenticating the user(ROBELL [0049] “In some implementations, the authentication engine 412 may verify the ID info/inputs 401 against authoritative sources (e.g., credit bureaus, government database(s), corporate database(s), and/or the like). Additionally or alternatively, the authentication engine 412 authenticates a user's 310, 360 identity using authentication or authorization credentials, biometric data, and/or knowledge-based authentication (KBA) data.”).
YANG-ROBELL demonstrates, in regard to claim number: 7. (Original) The method of claim 6, wherein the document information includes a name of the user(ROBELL [0042] “Additionally or alternatively, the inputs 401 may include user-supplied/provided PII such as, for example, name,”), an employee number of the user(ROBELL [0004] “individuals may be issued numerous forms of identity cards such as… company (e.g., employer) ID cards, and/or the like. “, [0221] “Many physical identity documents take the form of an identity card (or “photo ID”), which… typically include a person's photograph, the bearer's name… and/or sex, an identification number (e.g., a unique national, state/provincial, or local identification number), card number…and/or other information.” In the example of an employer ID card containing an identification number, ROBELL provides for wherein the document information includes an employee number of the user.), an image of the user(ROBELL [0048] “In addition to or alternatively to identity documents, other data may be provided as inputs 401 such as, for example, user generated text, images, video, audio content, and/or other like data. In some implementations, biometric analysis and/or processing may be incorporated into the NFT ID generation process”), and a signed hash (ROBELL [0038] “In addition to this basic function of storing the keys, the wallet 310 also offers the functionality of encrypting and/or digitally signing info or electronic documents. Signing can for example result in executing a smart contract, a cryptocurrency transaction, identification process, legally signing a document, and/or the like.”, [0048] “The biometric inputs 401 may include… behavioral biometrics (or “behaviometrics”) (e.g., typing rhythm, gait, signature, behavioral profile features, voice features, and/or the like)… In these implementations, the NFT ID engine 350 accepts one or more biometrics as inputs 401, which are then combined together (and/or with other inputs 401) and hashed. This hash will then become part of a smart contract 411 (e.g., as generated and/or operated by the smart contracts engine 410) to generate NFT IDs 402”, [0234] “Examples of cryptographic mechanisms that can be used for integrity protection include digital signatures, message authentication codes (MAC), and secure hashes.” In the example of a hash that is secure by a user’s signature, ROBELL provides for a signed hash) of the name, the employee number, and the image(ROBELL [0048] “In these implementations, the NFT ID engine 350 accepts one or more biometrics as inputs 401, which are then combined together (and/or with other inputs 401) and hashed.”).
YANG-ROBELL demonstrates, in regard to claim number: 8. (Original) The method of claim 7, further comprising: validating the identification document based on the signed hash(ROBELL [0048] “This hash will then become part of a smart contract 411 (e.g., as generated and/or operated by the smart contracts engine 410) to generate NFT IDs 402 where use of biometrics is/are desired (e.g., identify-proofed NFT IDs 402, NGO/commercial NFT IDs 402, and/or social NFT IDs 402).”, [0222] “Examples of the authentication and/or authorization techniques include using… hash-based message authentication codes (HMAC), Kerberos protocol, OpenID, WebID, and/or other authentication and/or authorization techniques.”, [0072] “In some implementations, the minted NFT ID 402 can include identity authentication verification, and/or validation mechanisms, which are also specified in the corresponding smart contract 411 that governs the NFT ID 402. Here, the corresponding smart contract 411 is written to include the necessary logic for authenticating, verifying, and/or validating the NFT ID 402 owner's identity…” In the example that a NFT ID generated by a smart contract using a hash, such as disclosed in [0048], when the NFT ID is used for verification or authentication ROBELL provides for wherein the identification document is validated based on the signed).
Claims 15-16 recite substantially similar limitations as claims 4-5, in the form of a system such as demonstrated by YANG-ROBELL (ROBELL [0011] “FIG. 6 illustrates an example computing system suitable for practicing various aspects of the present disclosure.”). Thus, claims 15-16 are rejected under similar rationale as claims 4-5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure:
Dasarakothapalli; Arjun Prasad US 12719856 B1 disclose techniques for cross-service auditable transitive identity propagation. A first application seeking to access a resource managed or provided by a second application receives a first access token generated by an identity provider. The first application performs one or more token exchanges, using the first access token, to obtain a second access token generated by an identity service. The second access token includes identity information associated with a user in a directory associated with the identity service. The first application provides the second access token to the second application as part of a request to access the resource. The second application utilizes the user identity information from the second token to perform fine-grained access control and can include user identity information in logs or events enabling auditing. [AB]
Dorofeev; Dmitrii US 20250126105 A1 discloses a unified authentication server is configured to obtain credentials for accessing third-party applications for generating user data reports. In response to a user of a mobile device logging into a portal associated with a third-party server via a web browser of the mobile device, the server may intercept a web cookie provided by a third-party server via a client application executed by the mobile device. The web cookie includes session authentication credentials. The server may receive the web cookie from the client application, establish a session with the third-party server on behalf of the user using the session authentication credentials of the web cookie. The server may scrape user data associated with the user from the third-party server and generate a user data report by aggregating the scraped user data for display by the client application within an interface of the mobile device. [AB]
WADHWA; Jatin US 20240176855 A1 discloses a method for integrated authentication and monitoring, executed by an electronic device, the method comprising: authenticating user credentials of a user using an identity broker, wherein the identity broker identifies an identity provider associated with the user credentials; generating detailed logs related to events associated with the authenticating; analyzing the generated logs; and generating an alarm based on the analyzing of the generated logs. [AB]
Pellizzer; Guido US 11991287 B2 disclose a method for a user to access resources within a secure network without inputting a username or password is presented and claimed where the method comprises inputting, by the user, login credentials into an authentication service and obtaining from the authentication service at least one secret code; inputting the at least one secret code into an OTCP to initialize the OTCP; generating within the OTCP a one-time code (OTC) utilizing the at least one secret code but not including the user's login credentials or username; supplying, by the user, the OTC to a secure web portal wherein the secure web portal confirms authenticity of the OTC with the authentication service; and the secure web portal supplying access to the user of the secure web portal resources upon receipt of authentication of the user. [AB]
Zeller; Daniel US 20220150249 A1 discloses an authentication system facilitates efficient generation of authentication integrations with third-party identity providers for client systems. The authentication system provides one or more interfaces configured to receive requests to make authentication integrations available for a third-party identity provider. The requests to make authentication integrations available include integration information for the relevant identity provider. Based on the request to make authentication integrations available, the authentication system generates an identity provider profile for the identity provider that can be used to generate authentication integrations with the identity provider for one or more client systems. Once the identity provider profile is generated, the authentication system uses the identity provider profile to generate authentication integrations for one or more client systems that request authentication through the third-party identity provider. In doing so, the authentication system provides an efficient process for providing authentication integrations with identity providers requested by client systems. [AB]
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kamryn Gillespie whose telephone number is 703-756-5498. The examiner can normally be reached on Monday through Thursday from 9am to 6pm.
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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.J.G./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights