DETAILED ACTION
This Office Action is in response to the application 19/227055, filed on 06/03/2025.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined and are pending in this application. Claims 1, 6, and 15 are independent.
Priority/Continuity
This application is a continuation of application 18/296122, filed on 04/05/2023, currently patent US 12,355,753.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 06/03/2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
Claim Objections
Claims 1, 4, 6, 10, 13, 15, and 17 are objected to because of the following informalities:
As to claims 1, 6, and 15, claims cite the term, “SSO” without reciting the full meaning of the acronym “SSO” at least once.
As to claims 4 and 13, claims cite the term, “SDK” without reciting the full meaning of the acronym “SDK” at least once.
As to claims 10 and 17, claims cite the term, “SAML” without reciting the full meaning of the acronym “SAML” at least once.
Appropriate correction(s) is required, most appropriately, for the first occurrence in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 6-14 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
As to claim 6, the claim is directed to one or more “instances of computer-readable media collectively having contents.” One of ordinary skill in the art would consider the “instances of computer-readable media” as a copy of software or a virtual machine, thus the claim is directed to a computer program per se.
As to claims 7-14, the claims are dependent from claim 6, and are rejected for the same reason set forth above for claim 6.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-17 of U.S. Patent No. US 12,355,753. Although, the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are anticipated by the reference claims.
The following claims are presented side by side for comparison. The comparison shows how the broader scoped independent claims 1, 6, and 15 of the instant application are anticipated by the narrower scoped independent claims 1, 5, and 13, along with the dependent claim 17, of the reference patent. While the limitation of instant claim 15, cites token, the dependent claim of the reference captures the scope of the token. The other broader dependent claims 2-5, 7-14, 16-20, of the instant application, are also anticipated, respectively.
Instant Application 19/227,055
Reference Patent US 12,355,753
1. A method in a computing system, the method comprising:
in a mobile application (mobile app):
establishing a hidden webview of the mobile app in a manner that permits the hidden webview to access SSO authentication result credentials for a user;
in the hidden webview of the mobile app:
sending a backend sign out request to sign out of a remote backend resource;
receiving, in response to the backend sign out request, a backend sign out response acknowledging user sign out of the backend resource;
clearing state of any previous remote backend resource session of the hidden webview of the mobile application;
sending, to an SSO service, a session request to begin a session with the SSO service, wherein the session request is based on the SSO authentication result credentials;
receiving, in response to the session request, a session response containing active SSO session state information; and
storing the received active SSO session state information in the hidden webview of the mobile app.
1. A method in a computing system, comprising:
in a mobile application (mobile app):
sending a first request, the first request being to login to an SSO service, the first request including authentication credentials for a user; receiving in response to the first request a first response containing one or more SSO authentication result credentials; causing the received one or more SSO authentication result credentials to be stored in a manner making them accessible only to the mobile app;
establishing the hidden webview of the mobile app in a manner that permits it to access the stored SSO authentication result credentials;
in the hidden webview of the mobile app:
sending a second request with respect to a remote backend resource, the second request being on behalf of the user for whom a distinguished user account was established with the backend resource, wherein the sending is performed in such a way that the active SSO session state information stored in the hidden webview of the mobile app is attached to the second request;
receiving in response to the second request a second response acknowledging user signin at the backend resource; sending a third request, the third request specifying to logout of the remote backend resource;
receiving in response to the third request a third response acknowledging user signout at the backend resource, and clearing state of any previous remote backend resource session within the hidden webview of the mobile app; sending a fourth request, the fourth request being to begin a session with the SSO service, the fourth request including at least a portion of the one or more SSO authentication result credentials; and
receiving in response to the fourth request a fourth response containing the active SSO session state information, in such a way that the received active SSO session state information stored in the hidden webview of the mobile app.
6. One or more instances of computer-readable media collectively having contents executable by a computing system to perform actions, the actions comprising:
in a hidden webview of a mobile application (mobile app):
sending a backend sign in request with respect to a remote backend resource, the backend sign in request being on behalf of a user for whom a distinguished user account was established with the backend resource, wherein the sending is performed in such a way that active SSO session state information stored in the hidden webview of the mobile app is attached to the backend sign in request; and
receiving in response to the backend sign in request a backend sign in response acknowledging user sign in of the backend resource;
in the mobile app, before sending the backend sign in request: establishing the hidden webview of the mobile app in a manner that permits it to access stored SSO authentication result credentials;
sending a backend sign out request, the backend sign out request specifying to logout of the remote backend resource;
receiving in response to the backend sign out request a backend sign out response acknowledging user sign out of the backend resource, and clearing state of any previous remote backend resource session within the hidden webview of the mobile app; obtaining SSO authentication result credentials; sending, to an SSO service, a session request to begin a session with the SSO service using at least a portion of the SSO authentication result credentials; receiving in response to the session request a session response containing the active SSO session state information; and
storing the received active SSO session state information in the hidden webview of the mobile app.
5. One or more instances of computer-readable media collectively having contents executable by a computing system to perform actions, the actions comprising:
in a mobile application (mobile app), in a hidden webview of the mobile app:
sending a first request with respect to a remote backend resource, the first request being on behalf of a user for whom a distinguished user account was established with the backend resource, wherein the sending is performed in such a way that the active SSO session state information stored in the hidden webview of the mobile app is attached to the first request; and
receiving in response to the first request a first response acknowledging user signin at the backend resource;
in the mobile app, before sending the first request: sending a second request, the second request being to login to an SSO service, the second request including authentication credentials for the user;
receiving in response to the second request a second response containing one or more SSO authentication result credentials; causing the received one or more SSO authentication result credentials to be stored in a manner making them accessible only to the mobile app; establishing the hidden webview of the mobile app in a manner that permits it to access the stored SSO authentication result credentials; in the hidden webview of the mobile app, before sending the first request, after receiving the second response; sending a third request, the third request specifying to logout of the remote backend resource; receiving in response to the third request a third response acknowledging user signout at the backend resource, and clearing state of any previous remote backend resource session within the hidden webview of the mobile app; sending a fourth request, the fourth request being to begin a session with the SSO service, the fourth request including at least a portion of the one or more SSO authentication result credentials; and
receiving in response to the fourth request a fourth response containing the active SSO session state information, in such a way that the received active SSO session state information stored in the hidden webview of the mobile app.
15. A method in a computing system, the method comprising:
obtaining an authentication token for a user;
establishing a hidden webview of a mobile application (mobile app) in a manner that permits the hidden webview to access the authentication token;
requesting user sign out of a remote backend resource; based on receiving acknowledgment of user sign out of the backend resource, clearing state of any previous remote backend resource session within the hidden webview of the mobile app; requesting, using the authentication token, to begin a session with an SSO service; receiving, from the SSO service, active SSO session state information; and
storing the received active SSO session state information in the hidden webview of the mobile app.
13. A method in a computing system, comprising:
in a mobile application (mobile app): sending a first request, the first request being to login to an SSO service, the first request including authentication credentials for a user; receiving in response to the first request a first response containing one or more SSO authentication result credentials; causing the received one or more SSO authentication result credentials to be stored in a manner making them accessible only to the mobile app; establishing a hidden webview of the mobile app in a manner that permits it to access the stored SSO authentication result credentials;
in the hidden webview of the mobile app, after receiving the first response: sending a second request, the second request specifying to logout of a remote backend resource; receiving in response to the second request a second response acknowledging user signout at the backend resource, and clearing state of any previous remote backend resource session within the hidden webview of the mobile app; sending a third request, the third request being to begin a session with the SSO service, the third request including at least a portion of the one or more SSO authentication result credentials; and
receiving in response to the third request a third response containing the active SSO session state information, in such a way that the received active SSO session state information stored in the hidden webview of the mobile app.
17. The method of claim 13 the SSO authentication result credentials received in the first response comprise some or all of: an Open ID Connect access token, an Open ID Connect refresh token, and an Open ID Connect ID token.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the Examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the Examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 6-12, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gujarathi et al (“Gujarathi,” US 2023/0014970, published on 01/19/2023), in view of Plummer et al (“Plummer,” US 9,876,859, patented on 01/23/2018).
As to claim 1, Gujarathi teaches a method in a computing system (Gujarathi: abstract, pars 0007-0008, systems, methods, non-transitory computer-readable medium for using a single sign-on (SSO) to access an application), the method comprising: in a mobile application (mobile app):
establishing a hidden webview of the mobile app in a manner that permits the hidden webview to access SSO authentication result credentials for a user; in the hidden webview of the mobile app (Gujarathi: pars 0007-0008, 0010, 0012, 0049, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview [i.e. hidden webview] on the client):
sending a backend sign out request to sign out of a remote backend resource (Gujarathi: pars 0007-0008, 0077, authentication initiator of the client initiate or transmit a request to access resources hosted on the workspace service or the application server. The resources may include components or elements within the workspace (e.g., applications, files, or other resources) [i.e. remote backend resource]. Facilitating single sign-on (SSO) session by leveraging existing sessions);
receiving, in response to the backend sign out request, a backend sign out response acknowledging user sign out of the backend resource;
sending, to an SSO service, a session request to begin a session with the SSO service, wherein the session request is based on the SSO authentication result credentials (Gujarathi: pars 0007-0008, 0010, 0012, for facilitating the SSO session, upon the initial authentication, cookies or other browsing contexts is generated with respect to the workspace application. where client has at least one existing session authenticated and verified by an identity provider (IDP), identifying the user using transmitted user credentials);
receiving, in response to the session request, a session response containing active SSO session state information (Gujarathi: pars 0007-0008, 0010, 0012, upon the successful SSO session establishment using the cookies transmitted by the embedded browser, user can login and access the remote resource); and
storing the received active SSO session state information in the hidden webview of the mobile app (Gujarathi: pars 0007-0008, 0010, 0012, Cookies are stored in association with the respective webviews when establishing a session, and during the subsequent session, the workspace application copies cookies into an embedded browser and made available to the IDP through the embedded browser used to launch the application for accessing the remote resource).
Gujarathi does not explicitly teach the limitation, clearing state of any previous remote backend resource session of the hidden webview of the mobile application.
However, in an analogous art, Plummer teaches the limitation, clearing state of any previous remote backend resource session of the hidden webview of the mobile application (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11, web client module of a client device establish and maintain one or more user sessions, including single sign-on (SSO) session. Where a state of user sessions (i.e., active or inactive/destroyed). When session is terminated, the process performs clearing all state information of the session, so that a new session starts new login, login credentials must be provided).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Plummer with the method/system of Gujarathi to include the limitation(s), clearing state of any previous remote backend resource session of the hidden webview of the mobile application, where one would have been motivated for the benefit of providing a user with a means for clearing state of any previous remote backend resource session, so that a new session with single sign-on (SSO) can be initiated with the necessary credentials associated with the SSO session (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11).
As to claim 2, the combination of Gujarathi and Plummer teaches the method of claim 1,
Gujarathi further teaches wherein establishing the hidden webview includes: sending an SSO sign in request to sign in to the SSO service, the SSO sign in request including authentication credentials for a user; receiving in response to the SSO sign in request an SSO sign in response containing the SSO authentication result credentials; causing the received SSO authentication result credentials to be stored in a manner making them accessible only to the mobile app; and establishing the hidden webview of the mobile app in a manner that permits it to access the stored SSO authentication result credential (Gujarathi: pars 0007-0008, 0010, 0012, 0049, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview on the client. Upon the initial authentication, cookies or other browsing contexts is generated with respect to the workspace application. where client has at least one existing session authenticated and verified by an identity provider (IDP), identifying the user using transmitted user credentials).
As to claim 3, the combination of Gujarathi and Plummer teaches the method of claim 1,
Gujarathi further teaches further comprising: in the hidden webview of the mobile app: sending a backend sign in request with respect to the remote backend resource, the backend sign in request being on behalf of the user for whom a distinguished user account was established with the backend resource, wherein the sending is performed in such a way that the active SSO session state information stored in the hidden webview of the mobile app is attached to the backend sign in request; receiving in response to the backend sign in request a backend sign in response that includes a backend session security token; in the mobile app: sending an operation request with respect to the backend service, the operation request being on behalf of the user, wherein the sending is performed in such a way that the backend session security token is attached to the operation request; and receiving in response to the operation request an operation response acknowledging operation of the backend resource with respect to the user (Gujarathi: pars 0007-0008, 0010, 0012, 0049, 0052, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview on the client. Pars 0052-0053, 0062, uses identity token and user OAuth2 token for accessing recourse with SSO access process).
As to claim 6, Gujarathi teaches one or more instances of computer-readable media collectively having contents executable by a computing system to perform actions (Gujarathi: abstract, pars 0007-0008, systems, methods, non-transitory computer-readable medium for using a single sign-on (SSO) to access an application), the actions comprising:
in a hidden webview of a mobile application (mobile app) (Gujarathi: pars 0007-0008, 0010, 0012, 0049, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview [i.e. hidden webview] on the client):
sending a backend sign in request with respect to a remote backend resource (Gujarathi: pars 0007-0008, 0077, authentication initiator of the client initiate or transmit a request to access resources hosted on the workspace service or the application server. The resources may include components or elements within the workspace (e.g., applications, files, or other resources) [i.e. remote backend resource]), the backend sign in request being on behalf of a user for whom a distinguished user account was established with the backend resource, wherein the sending is performed in such a way that active SSO session state information stored in the hidden webview of the mobile app is attached to the backend sign in request (Gujarathi: pars 0007-0008, 0010, 0012, for facilitating the SSO session, upon the initial authentication, cookies or other browsing contexts is generated with respect to the workspace application. Cookies are stored in association with the respective webviews when establishing a session, and during the subsequent session, the workspace application copies cookies into an embedded browser and made available to the IDP through the embedded browser used to launch the application for accessing the remote resource); and
receiving in response to the backend sign in request a backend sign in response acknowledging user sign in of the backend resource (Gujarathi: pars 0007-0008, 0010, 0012, upon the successful SSO session establishment using the cookies transmitted by the embedded browser, user can login and access the remote resource);
in the mobile app, before sending the backend sign in request: establishing the hidden webview of the mobile app in a manner that permits it to access stored SSO authentication result credentials (Gujarathi: pars 0007-0008, 0010, 0012, 0049, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview [i.e. hidden webview] on the client);
sending a backend sign out request, the backend sign out request specifying to logout of the remote backend resource (Gujarathi: pars 0007-0008, 0077, authentication initiator of the client initiate or transmit a request to access resources hosted on the workspace service or the application server. The resources may include components or elements within the workspace (e.g., applications, files, or other resources) [i.e. remote backend resource. Facilitating single sign-on (SSO) session by leveraging existing sessions]);
receiving in response to the backend sign out request a backend sign out response acknowledging user sign out of the backend resource;
obtaining SSO authentication result credentials;
sending, to an SSO service, a session request to begin a session with the SSO service using at least a portion of the SSO authentication result credentials (Gujarathi: pars 0007-0008, 0010, 0012, for facilitating the SSO session, upon the initial authentication, cookies or other browsing contexts is generated with respect to the workspace application. where client has at least one existing session authenticated and verified by an identity provider (IDP), identifying the user using transmitted user credentials);
receiving in response to the session request a session response containing the active SSO session state information (Gujarathi: pars 0007-0008, 0010, 0012, upon the successful SSO session establishment using the cookies transmitted by the embedded browser, user can login and access the remote resource); and
storing the received active SSO session state information in the hidden webview of the mobile app (Gujarathi: pars 0007-0008, 0010, 0012, Cookies are stored in association with the respective webviews when establishing a session, and during the subsequent session, the workspace application copies cookies into an embedded browser and made available to the IDP through the embedded browser used to launch the application for accessing the remote resource).
Gujarathi does not explicitly teach the limitation, clearing state of any previous remote backend resource session within the hidden webview of the mobile app.
However, in an analogous art, Plummer teaches the limitation, clearing state of any previous remote backend resource session within the hidden webview of the mobile app (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11, web client module of a client device establish and maintain one or more user sessions, including single sign-on (SSO) session. Where a state of user sessions (i.e., active or inactive/destroyed). When session is terminated, the process performs clearing all state information of the session, so that a new session starts new login, login credentials must be provided).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Plummer with the method/system of Gujarathi to include the limitation(s), clearing state of any previous remote backend resource session within the hidden webview of the mobile app, where one would have been motivated for the benefit of providing a user with a means for clearing state of any previous remote backend resource session, so that a new session with single sign-on (SSO) can be initiated with the necessary credentials associated with the SSO session (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11).
As to claim 7, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 6, wherein establishing the hidden webview includes:
Gujarathi further teaches sending an SSO sign in request, the SSO sign in request being to sign in to the SSO service, the SSO sign in request including authentication credentials for the user; receiving in response to the SSO sign in request an SSO sign in response containing SSO authentication result credentials; causing the received SSO authentication result credentials to be stored in a manner making them accessible only to the mobile app; and establishing the hidden webview of the mobile app in a manner that permits it to access the stored SSO authentication result credentials (Gujarathi: pars 0007-0008, 0010, 0012, 0050, Webviews can be windows or an authentication page to users for entering in credentials, including user-name and password. pars 0052-0053, 0062, uses identity token and user OAuth2 token for accessing recourse with SSO access process).
As to claim 8, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 7,
Gujarathi further teaches wherein the SSO sign in request is sent by an SSO webview of the mobile app (Gujarathi: pars 0007-0008, 0010, 0012, 0049, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session, by user entered information).
As to claim 9, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 7,
Gujarathi further teaches wherein the authentication credentials included in the SSO sign in request comprise one or both of: a username and password combination for the user, and biometric information captured from the user (Gujarathi: pars 0007-0008, 0010, 0012, 0050, Webviews can be windows or an authentication page to users for entering in credentials, including user-name and password).
As to claim 10, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 6,
Gujarathi further teaches wherein the backend sign out request is a SAML single logout (Gujarathi: par 0009, uses Security Assertion Markup Language (SAML) for access request to resource).
As to claim 11, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 6,
Gujarathi further teaches wherein the SSO authentication result credentials comprise some or all of: an access token, a refresh token, and an ID token (Gujarathi: pars 0052-0053, 0062, uses identity token and user OAuth2 token for accessing recourse with SSO access process).
As to claim 12, the combination of Gujarathi and Plummer teaches the one or more instances of computer-readable media of claim 6,
Gujarathi further teaches wherein the received backend sign in response contains a backend session security token, the actions further comprising in the mobile app: sending an operation request with respect to the remote backend service, the operation request being on behalf of the user for whom the distinguished user account was established with the backend service, wherein the sending is performed in such a way that the backend session security token is attached to the operation request; and receiving in response to the operation request an operation response acknowledging operation of the backend resource with respect to the user (Gujarathi: pars 0007-0008, 0010, 0012, 0049, 0052, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview on the client. Pars 0052-0053, 0062, uses identity token and user OAuth2 token for accessing recourse with SSO access process).
As to claim 15, Gujarathi teaches a method in a computing system (Gujarathi: abstract, pars 0007-0008, systems, methods, non-transitory computer-readable medium for using a single sign-on (SSO) to access an application), the method comprising:
obtaining an authentication token for a user;
establishing a hidden webview of a mobile application (mobile app) in a manner that permits the hidden webview to access the authentication token Gujarathi: pars 0007-0008, 0010, 0012, 0049, 0052, a client device, having a workspace application, such as, a web application, mobile application, executing on a client, facilitating single sign-on (SSO) session by leveraging existing sessions indicated by information associated with the embedded browser or webview [i.e. hidden webview] on the client. Uses an identity token);
requesting user sign out of a remote backend resource;
based on receiving acknowledgment of user sign out of the backend resource (Gujarathi: pars 0007-0008, 0077, authentication initiator of the client initiate or transmit a request to access resources hosted on the workspace service or the application server. The resources may include components or elements within the workspace (e.g., applications, files, or other resources) [i.e. remote backend resource]. Facilitating single sign-on (SSO) session by leveraging existing sessions);
requesting, using the authentication token, to begin a session with an SSO service; receiving, from the SSO service, active SSO session state information (Gujarathi: pars 0007-0008, 0010, 0012, for facilitating the SSO session, upon the initial authentication, cookies or other browsing contexts is generated with respect to the workspace application. where client has at least one existing session authenticated and verified by an identity provider (IDP), identifying the user using transmitted user credentials); and
storing the received active SSO session state information in the hidden webview of the mobile app (Gujarathi: pars 0007-0008, 0010, 0012, Cookies are stored in association with the respective webviews when establishing a session, and during the subsequent session, the workspace application copies cookies into an embedded browser and made available to the IDP through the embedded browser used to launch the application for accessing the remote resource).
Gujarathi does not explicitly teach the limitation, based on [ ], user sign out, clearing state of any previous remote backend resource session within the hidden webview of the mobile app.
However, in an analogous art, Plummer teaches the limitation, based on [ ], user sign out, clearing state of any previous remote backend resource session within the hidden webview of the mobile app application (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11, web client module of a client device establish and maintain one or more user sessions, including single sign-on (SSO) session. Where a state of user sessions (i.e., active or inactive/destroyed). When session is terminated, the process performs clearing all state information of the session, so that a new session starts new login, login credentials must be provided).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Plummer with the method/system of Gujarathi to include the limitation(s), based on[ ], user sign out, clearing state of any previous remote backend resource session within the hidden webview of the mobile app, where one would have been motivated for the benefit of providing a user with a means for clearing state of any previous remote backend resource session, so that a new session with single sign-on (SSO) can be initiated with the necessary credentials associated with the SSO session (Plummer: col 2, lines 60-67, col 4, lines 19-28, 51-67, col 13, lines 13-11).
As to claim 16-19, the claim limitations ae similar to the claims 8-11, respectively, and are rejected for the same reasons set forth above for claims 16-19.
As to claim 20, the combination of Gujarathi and Plummer teaches the method of claim 15,
Gujarathi further teaches wherein the authentication token is stored in a manner making the authentication token accessible only to the mobile application (Gujarathi: pars 0052-0053, 0062, 0067, user uses identity token and user OAuth2 token from mobile application, for accessing recourse with SSO access process).
Claims 4, 5, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Trimberger (“Trimberger-025,” US 7,747,025, patented on 06/29/2010), in view of Plummer et al (“Plummer,” US 9,876,859, patented on 01/23/2018), and further in view of Kulp et al (“Kulp,” US 2018/0198845, published on 07/12/2018).
As to claim 4, the combination of Gujarathi and Plummer teaches the method of claim 1,
the combination of Gujarathi and Plummer does not explicitly teaches the limitation, wherein the received session response contains a backend session security token, the method further comprising: in the mobile app: invoking a local SDK component associated with the backend resource, passing to the SDK component backend session security token as part of the invocation; and in response to the invocation, outputting content procured by the local SDK component from the backend response using the backend session security token
However, in an analogous art, Kulp teaches the limitation, wherein the received session response contains a backend session security token, the method further comprising: in the mobile app: invoking a local SDK component associated with the backend resource, passing to the SDK component backend session security token as part of the invocation; and in response to the invocation, outputting content procured by the local SDK component from the backend response using the backend session security token (Kulp: pars 0006, 0064, 0074, 0084-0085, a software development kit (SDK) login process is implemented for login process using a single sign on (SSO) from the local computer is that the browser of the local computer only works with a given domain. Where the remote reverse proxy enables the local reverse proxy of the software development kit running on the computer to interact with the one or more microservices remotely deployed. Moreover, the local reverse proxy running in the software development kit is able to route the other requests because the local reverse proxy has access to a session token [i.e., session security token] linking the browser of the computer to the remote reverse proxy in a context of a single user login session).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kulp with the method/system of Gujarathi and Plummer to include the limitation(s), wherein the received session response contains a backend session security token, the method further comprising: in the mobile app: invoking a local SDK component associated with the backend resource, passing to the SDK component backend session security token as part of the invocation; and in response to the invocation, outputting content procured by the local SDK component from the backend response using the backend session security token, where one would have been motivated for a software development kit (SDK) login process is implemented for login process using a single sign on (SSO) from the local computer is that the browser of the local computer only works with a given domain, using the session token [i.e. session security token] linking the browser of the computer to the remote reverse proxy in a context of a single user login session (Kulp: pars 0006, 0064).
As to claim 5, the combination of Gujarathi, Plummer, and Kulp teaches the method of claim 4,
Kulp further teaches wherein the local SDK component uses the backend session security token to obtain a backend SDK token, and wherein the local SDK component uses the backend SDK token to invoke a remote SDK token of the backend resource to generate the outputted content (Kulp: pars 0006, 0064, 0074, 0084-0085, the local reverse proxy having the session token linking the browser of the computer to the remote reverse proxy in a context of a single user login session. Login microservice sends a request to login server to exchange the session token to a bearer token. At login server sends the bearer token to login microservice. In response, login microservice generates a session using the bearer token and sets a session cookie).
As to claims 13 and 14, the scope of the claim limitations is similar to the claims 4 and 5, respectively, and are rejected for the same reasons set forth above for claims 4 and 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Jahangir Kabir whose telephone number is (571) 270-3355. The Examiner can normally be reached on 9:00- 5:00 Mon-Thu.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/JAHANGIR KABIR/ Primary Examiner, Art Unit 2439
