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 communication is in response to the amendments filed on 04/28/2026. Claims 1-20 are currently pending.
Response to Amendment
The previous 112(b) rejections have been withdrawn in response to applicant’s amendments.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot in view of the rejections made below in response to the applicant’s amendments.
Claim Rejections - 35 USC § 112
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 9, and 15 recite the limitation of:
“generating, at the first browsing tab of the second web application a unique
identifier…”). However, it is noted that the specification as originally filed by the applicant does not contain “generating, at the first browsing tab of the second web application a unique identifier…”). At best, paragraphs 35 and 87 disclose “based on the received request, a unique identifier is generated. The unique identifier is generated to be assigned to a session for loading the first web application in a new browsing tab. From 204, method 200 proceeds to 204.”. This constitutes lack of written description. Other claims are rejected due to dependency on one of the independent claims 1, 9, and 15.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 9, and 15 recite the limitation of:
“generating, at the first browsing tab of the second web application a unique
identifier…”). It is not clear in the specification as originally filed that the unique identifier is generated at the first browsing tab of the second web application as claimed. This renders the claims indefinite. Other claims are rejected under 112(b) due to dependency on one of the independent claims 1, 9, and 15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 7-9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over WO 2018183322 to FIGUEROA et al (hereinafter FIGUEROA) in view of US PGPUb. No. 20140108667 to Reddy et al. (hereinafter Reddy).
Regarding claim 1, FIGUEROA discloses a computer-implemented method (¶004, “certain embodiments are directed to a method of maintaining user sessions across multiple web applications. The method includes receiving, by a first web application running on a first server, a cross-application request from a client application running on a client device. The cross-application request indicates a user action to access a second web application, which runs on a second server…”), comprising:
receiving a request associated with a user to load a first web application in an embedding context of a second web application, wherein the user is authenticated into the second web application at a first identity provider (¶0002, “… Application A in Domain A may serve a webpage that includes an HTML (Hyper Text Markup Language) iframe element (inline frame). The iframe, which appears within a webpage downloaded from Application A, renders content downloaded from Application B, which is hosted in Domain B. The iframe's content allows the browser to access a cookie from Domain B (e.g., using JavaScript or some other client-side script) and thus to access session information relating to the browser's session with Application B. Thus, for example, if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0045, “At 510, a first web application 132, running on a first server 130, receives a cross-application request 160 from a client application 112 running on a client device 110. The cross-application request 160 indicates a user action to access a second web application 142, which runs on a second server 140. For example, the client application 112 is a web browser or web-enabled application or app, which sends the cross-application request 160 in response to the user 114 operating a control. In an example, the user 114 has already been authenticated by this point, and a session 150 has been established between the client application 112 and the first web application 132.”), (¶0029, wherein the first web application that authenticates the user and create the session data that include the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality is interpreted as the claimed identity provider);
based on the received request, generating a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab (¶0029, “…Assuming that authentication succeeds, meaning that the identity of the user 114 is verified, the first web application 132 creates session data 168 for session 150 (see also FIG. 1). The session data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval. The session timeout interval defines an interval of time that the session 150 remains open when the user 114 is inactive. Example session timeout intervals are 20 minutes, one hour, etc., and may be reset to starting values as long as the user 114 remains active. At this time, the first web application 132 may also create a session key (SK) 168a, e.g., a random or pseudo-random number that uniquely identifies the session data 168…”);
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user (¶0030-0034, FIG. 4, “the first web application 132 sends the session key 168a back to the client application 112, e.g., in response to the login request issued at 410. At 416, the client application 112 stores the session key 168a in the client device 110, such as in local memory, in cache, in a transient cookie, or on disk. Activities 410 - 416 establish session 150. As shown generally by operations 418, session 150 may proceed over time, with the client application 112 performing various actions and the first web application 132 providing responses in the usual manner, within the context of the session 150. At some point during the session 150, the user 114 may operate a user control in an attempt to access data or functionality provided by a different web application, such as the second web application 142. For example, the user 114 operates the hamburger icon 222 (FIG. 2) and selects "App2" from the displayed list 226…in response to the user operation, the client application 112 sends a cross-application request 160 to the first web application 132. In an example, the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416…”), see ¶0028-¶0029 for authentication.
; and
refreshing the first web application into the embedded context of the second web application comprising: searching for the existing session for the user at the first web application and reusing the existing session for rendering the first web application when the existing session is associated with the generated identified at the first web application (¶0017-¶0018, “…The first server 130 stores session data 168 pertaining to the session 150. Such session data 168 may include, for example, a user ID (identifier) of the user 114, privileges of the user 114 to perform various activities, a token for accessing restricted information, and a session timeout interval…The first web application 132 receives the session request 166, tests the SUP 162 against the value it sent to the client application 112, and, assuming that the SUP 162 checks out as valid and that any other security requirements are met, replies to the session request 166 with a response that includes the session data 168. The second web application 142 then uses the session data 168 to engage with the client application 112 in a session 150a, which is a continuation of the session 150. Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session. Rather, the second web application 114 uses the results of the prior authentication, e.g., performed when the user 114 logged on to the first web application 132.”), (¶0020-¶0023, “…At some point during the session 150, the user 114 may operate a cursor 224 to select the control 222 (e.g., a hamburger icon). Upon selecting the control 222, the browser displays a list 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 ("App 2"), a third web application ("App 3"), a fourth web application ("App 4"), and a "Platform" application, e.g., an application that unifies the other applications in a common framework. The user 114 may use the cursor 224 to select one of the listed items, with the effect of the selection being to initiate a cross-application request. For instance, and continuing with the example of FIG. 1, the user 114 may select "App 2" to initiate the cross-application request 160.”), (¶0040-¶0043, “At 442, the second web application 142 receives the session data 168 and session key 168a from the first web application 132 and proceeds to use the session data 168 and session key 168a for maintaining the session 150a with the client application 112. For example, the second web application 142 has access to its own in-memory data store, such as Redis, and stores session data 168 in the data store under the session key 168a, e.g., in the same manner as described at 422 above by the first web application 132…the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”).
However, FIGUEROA does not explicitly disclose the following limitations:
wherein the request is received at a first browsing tab of the second web application,
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application,
Wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded.
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab
Reddy discloses wherein the request is received at a first browsing tab of the second web application (¶0044-¶0045, “With reference to FIG. 4, a request flow diagram 400 is depicted that further illustrates communication between first tab (labeled `Browser Tab1`) 306 (of browser window 304 of browser 302) and web server application 320A executing on web server 320, according to an embodiment of the present disclosure. As is depicted, a login request `/login.htm` generated by browser 302 (for first tab 306) is communicated to web server application 320A, which communicates the login request to URL filter 111…”), see also ¶0012, ¶0013, and ¶0014.
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application (¶0051-¶0052, “…Accordingly, a different session cookie is generated for each tab of a same browser window, and each session cookie provides the unique session ID, corresponding to the rewritten URL, that can be utilized by the client browser when generating subsequent requests from a corresponding tab of the client browser window to the information handling system.”), (¶0032, “assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again….”),
wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded (¶0032, “Session cookies store session identifiers (IDs) that are generated by a web server and sent back to a browser in response to a request. When the browser sends a session ID back to a web server with a next request, the web server correlates the request to the active session using the ID. By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again…”).
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab (¶0032, “… By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again.”), (¶0051, “…According to the present disclosure, each tab of a single browser window is assigned a unique identifier. Various embodiments provide a method, an information handling system and a computer program product that creates different sessions for each tab of a client browser window…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to include new browsing tab of web application with different embedding context from the first browsing tab to load web application as disclosed by Reddy and be motivated in doing so in order to have a single browsing window for multiple tabs and applications which simplifies window management.
Regarding claim 9, FIGUEROA discloses a non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform one or more operations (claim 14, “A computer program product including a set of non-transitory, computer- readable media having instructions which, when executed by control circuitry of a first server, cause the control circuitry to perform a method for maintaining user sessions across multiple web applications”), comprising:
receiving a request associated with a user to load a first web application in an embedding context of a second web application, wherein the user is authenticated into the second web application at a first identity provider (¶0002, “… Application A in Domain A may serve a webpage that includes an HTML (Hyper Text Markup Language) iframe element (inline frame). The iframe, which appears within a webpage downloaded from Application A, renders content downloaded from Application B, which is hosted in Domain B. The iframe's content allows the browser to access a cookie from Domain B (e.g., using JavaScript or some other client-side script) and thus to access session information relating to the browser's session with Application B. Thus, for example, if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0045, “At 510, a first web application 132, running on a first server 130, receives a cross-application request 160 from a client application 112 running on a client device 110. The cross-application request 160 indicates a user action to access a second web application 142, which runs on a second server 140. For example, the client application 112 is a web browser or web-enabled application or app, which sends the cross-application request 160 in response to the user 114 operating a control. In an example, the user 114 has already been authenticated by this point, and a session 150 has been established between the client application 112 and the first web application 132.”), (¶0029, wherein the first web application that authenticates the user and create the session data that include the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality is interpreted as the claimed identity provider);
based on the received request, generating a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab (¶0029, “…Assuming that authentication succeeds, meaning that the identity of the user 114 is verified, the first web application 132 creates session data 168 for session 150 (see also FIG. 1). The session data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval. The session timeout interval defines an interval of time that the session 150 remains open when the user 114 is inactive. Example session timeout intervals are 20 minutes, one hour, etc., and may be reset to starting values as long as the user 114 remains active. At this time, the first web application 132 may also create a session key (SK) 168a, e.g., a random or pseudo-random number that uniquely identifies the session data 168…”);
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user (¶0030-0034, FIG. 4, “the first web application 132 sends the session key 168a back to the client application 112, e.g., in response to the login request issued at 410. At 416, the client application 112 stores the session key 168a in the client device 110, such as in local memory, in cache, in a transient cookie, or on disk. Activities 410 - 416 establish session 150. As shown generally by operations 418, session 150 may proceed over time, with the client application 112 performing various actions and the first web application 132 providing responses in the usual manner, within the context of the session 150. At some point during the session 150, the user 114 may operate a user control in an attempt to access data or functionality provided by a different web application, such as the second web application 142. For example, the user 114 operates the hamburger icon 222 (FIG. 2) and selects "App2" from the displayed list 226…in response to the user operation, the client application 112 sends a cross-application request 160 to the first web application 132. In an example, the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416…”), see ¶0028-¶0029 for authentication.
; and
refreshing the first web application into the embedded context of the second web application comprising: searching for the existing session for the user at the first web application and reusing the existing session for rendering the first web application when the existing session is associated with the generated identified at the first web application (¶0017-¶0018, “…The first server 130 stores session data 168 pertaining to the session 150. Such session data 168 may include, for example, a user ID (identifier) of the user 114, privileges of the user 114 to perform various activities, a token for accessing restricted information, and a session timeout interval…The first web application 132 receives the session request 166, tests the SUP 162 against the value it sent to the client application 112, and, assuming that the SUP 162 checks out as valid and that any other security requirements are met, replies to the session request 166 with a response that includes the session data 168. The second web application 142 then uses the session data 168 to engage with the client application 112 in a session 150a, which is a continuation of the session 150. Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session. Rather, the second web application 114 uses the results of the prior authentication, e.g., performed when the user 114 logged on to the first web application 132.”), (¶0020-¶0023, “…At some point during the session 150, the user 114 may operate a cursor 224 to select the control 222 (e.g., a hamburger icon). Upon selecting the control 222, the browser displays a list 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 ("App 2"), a third web application ("App 3"), a fourth web application ("App 4"), and a "Platform" application, e.g., an application that unifies the other applications in a common framework. The user 114 may use the cursor 224 to select one of the listed items, with the effect of the selection being to initiate a cross-application request. For instance, and continuing with the example of FIG. 1, the user 114 may select "App 2" to initiate the cross-application request 160.”), (¶0040-¶0043, “At 442, the second web application 142 receives the session data 168 and session key 168a from the first web application 132 and proceeds to use the session data 168 and session key 168a for maintaining the session 150a with the client application 112. For example, the second web application 142 has access to its own in-memory data store, such as Redis, and stores session data 168 in the data store under the session key 168a, e.g., in the same manner as described at 422 above by the first web application 132…the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”).
However, FIGUEROA does not explicitly disclose the following limitations:
wherein the request is received at a first browsing tab of the second web application,
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application,
Wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded.
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab
Reddy discloses wherein the request is received at a first browsing tab of the second web application (¶0044-¶0045, “With reference to FIG. 4, a request flow diagram 400 is depicted that further illustrates communication between first tab (labeled `Browser Tab1`) 306 (of browser window 304 of browser 302) and web server application 320A executing on web server 320, according to an embodiment of the present disclosure. As is depicted, a login request `/login.htm` generated by browser 302 (for first tab 306) is communicated to web server application 320A, which communicates the login request to URL filter 111…”), see also ¶0012, ¶0013, and ¶0014.
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application (¶0051-¶0052, “…Accordingly, a different session cookie is generated for each tab of a same browser window, and each session cookie provides the unique session ID, corresponding to the rewritten URL, that can be utilized by the client browser when generating subsequent requests from a corresponding tab of the client browser window to the information handling system.”), (¶0032, “assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again….”),
wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded (¶0032, “Session cookies store session identifiers (IDs) that are generated by a web server and sent back to a browser in response to a request. When the browser sends a session ID back to a web server with a next request, the web server correlates the request to the active session using the ID. By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again…”).
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab (¶0032, “… By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again.”), (¶0051, “…According to the present disclosure, each tab of a single browser window is assigned a unique identifier. Various embodiments provide a method, an information handling system and a computer program product that creates different sessions for each tab of a client browser window…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to include new browsing tab of web application with different embedding context from the first browsing tab to load web application as disclosed by Reddy and be motivated in doing so in order to have a single browsing window for multiple tabs and applications which simplifies window management.
Regarding claim 15, FIGUEROA discloses a computer-implemented system, comprising: one or more computers (¶0015-¶0016, “Suitable examples of the client device 110 include a desktop computer, laptop computer, workstation, smart phone, smart tablet, personal data assistant (PDA), set top box, or game console…”); and
one or more computer memory devices interoperably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations (¶0025, “the server 130 includes one or more network interfaces 310, a set of processors 320, and memory 330. The set of processors 320 include one or more processing chips and/or assemblies. The memory 330 includes both volatile memory, such as RAM (Random Access Memory), and non-volatile memory, such as one or more ROMs (Read-Only Memories), disk drives, solid state drives, and the like. The set of processors 320 and the memory 330 together form control circuitry, which is constructed and arranged to carry out various server-based methods and functions as described herein…”), (claim 14, “A computer program product including a set of non-transitory, computer- readable media having instructions which, when executed by control circuitry of a first server, cause the control circuitry to perform a method for maintaining user sessions across multiple web applications…”), comprising:
receiving a request associated with a user to load a first web application in an embedding context of a second web application, wherein the user is authenticated into the second web application at a first identity provider (¶0002, “… Application A in Domain A may serve a webpage that includes an HTML (Hyper Text Markup Language) iframe element (inline frame). The iframe, which appears within a webpage downloaded from Application A, renders content downloaded from Application B, which is hosted in Domain B. The iframe's content allows the browser to access a cookie from Domain B (e.g., using JavaScript or some other client-side script) and thus to access session information relating to the browser's session with Application B. Thus, for example, if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0045, “At 510, a first web application 132, running on a first server 130, receives a cross-application request 160 from a client application 112 running on a client device 110. The cross-application request 160 indicates a user action to access a second web application 142, which runs on a second server 140. For example, the client application 112 is a web browser or web-enabled application or app, which sends the cross-application request 160 in response to the user 114 operating a control. In an example, the user 114 has already been authenticated by this point, and a session 150 has been established between the client application 112 and the first web application 132.”), (¶0029, wherein the first web application that authenticates the user and create the session data that include the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality is interpreted as the claimed identity provider);
based on the received request, generating a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab (¶0029, “…Assuming that authentication succeeds, meaning that the identity of the user 114 is verified, the first web application 132 creates session data 168 for session 150 (see also FIG. 1). The session data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval. The session timeout interval defines an interval of time that the session 150 remains open when the user 114 is inactive. Example session timeout intervals are 20 minutes, one hour, etc., and may be reset to starting values as long as the user 114 remains active. At this time, the first web application 132 may also create a session key (SK) 168a, e.g., a random or pseudo-random number that uniquely identifies the session data 168…”);
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user (¶0030-0034, FIG. 4, “the first web application 132 sends the session key 168a back to the client application 112, e.g., in response to the login request issued at 410. At 416, the client application 112 stores the session key 168a in the client device 110, such as in local memory, in cache, in a transient cookie, or on disk. Activities 410 - 416 establish session 150. As shown generally by operations 418, session 150 may proceed over time, with the client application 112 performing various actions and the first web application 132 providing responses in the usual manner, within the context of the session 150. At some point during the session 150, the user 114 may operate a user control in an attempt to access data or functionality provided by a different web application, such as the second web application 142. For example, the user 114 operates the hamburger icon 222 (FIG. 2) and selects "App2" from the displayed list 226…in response to the user operation, the client application 112 sends a cross-application request 160 to the first web application 132. In an example, the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416…”), see ¶0028-¶0029 for authentication.
; and
refreshing the first web application into the embedded context of the second web application comprising: searching for the existing session for the user at the first web application and reusing the existing session for rendering the first web application when the existing session is associated with the generated identified at the first web application (¶0017-¶0018, “…The first server 130 stores session data 168 pertaining to the session 150. Such session data 168 may include, for example, a user ID (identifier) of the user 114, privileges of the user 114 to perform various activities, a token for accessing restricted information, and a session timeout interval…The first web application 132 receives the session request 166, tests the SUP 162 against the value it sent to the client application 112, and, assuming that the SUP 162 checks out as valid and that any other security requirements are met, replies to the session request 166 with a response that includes the session data 168. The second web application 142 then uses the session data 168 to engage with the client application 112 in a session 150a, which is a continuation of the session 150. Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session. Rather, the second web application 114 uses the results of the prior authentication, e.g., performed when the user 114 logged on to the first web application 132.”), (¶0020-¶0023, “…At some point during the session 150, the user 114 may operate a cursor 224 to select the control 222 (e.g., a hamburger icon). Upon selecting the control 222, the browser displays a list 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 ("App 2"), a third web application ("App 3"), a fourth web application ("App 4"), and a "Platform" application, e.g., an application that unifies the other applications in a common framework. The user 114 may use the cursor 224 to select one of the listed items, with the effect of the selection being to initiate a cross-application request. For instance, and continuing with the example of FIG. 1, the user 114 may select "App 2" to initiate the cross-application request 160.”), (¶0040-¶0043, “At 442, the second web application 142 receives the session data 168 and session key 168a from the first web application 132 and proceeds to use the session data 168 and session key 168a for maintaining the session 150a with the client application 112. For example, the second web application 142 has access to its own in-memory data store, such as Redis, and stores session data 168 in the data store under the session key 168a, e.g., in the same manner as described at 422 above by the first web application 132…the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”).
However, FIGUEROA does not explicitly disclose the following limitations:
wherein the request is received at a first browsing tab of the second web application,
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application,
Wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded.
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab
Reddy discloses wherein the request is received at a first browsing tab of the second web application (¶0044-¶0045, “With reference to FIG. 4, a request flow diagram 400 is depicted that further illustrates communication between first tab (labeled `Browser Tab1`) 306 (of browser window 304 of browser 302) and web server application 320A executing on web server 320, according to an embodiment of the present disclosure. As is depicted, a login request `/login.htm` generated by browser 302 (for first tab 306) is communicated to web server application 320A, which communicates the login request to URL filter 111…”), see also ¶0012, ¶0013, and ¶0014.
generating, at the first browsing tab of the second web application, a unique identifier to be assigned to an existing session for loading the first web application in a new browsing tab of the second web application (¶0051-¶0052, “…Accordingly, a different session cookie is generated for each tab of a same browser window, and each session cookie provides the unique session ID, corresponding to the rewritten URL, that can be utilized by the client browser when generating subsequent requests from a corresponding tab of the client browser window to the information handling system.”), (¶0032, “assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again….”),
wherein the new browsing tab of the second web application has the embedding context for loading the first web application that is different from a context of the first browsing tab where the second web application is loaded (¶0032, “Session cookies store session identifiers (IDs) that are generated by a web server and sent back to a browser in response to a request. When the browser sends a session ID back to a web server with a next request, the web server correlates the request to the active session using the ID. By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again…”).
triggering to load the first web application into the new browsing tab by using the unique identifier to authenticate the user at the first web application when loaded at the new browsing tab from the first browsing tab (¶0032, “… By default, all browsers share session state between multiple tabs of a same browser window. In this case, when a user logs into a particular website using a first tab and then opens an internal link of the same website in a new second tab, the user is not required to log in to the website again. For example, assume a user opens Google.TM. using a client browser and logs into google.com. When the user opens a new tab in the same browser and enters gmail.com, the user will be automatically logged in and redirected to Google.TM. mail without being required to enter a user login again.”), (¶0051, “…According to the present disclosure, each tab of a single browser window is assigned a unique identifier. Various embodiments provide a method, an information handling system and a computer program product that creates different sessions for each tab of a client browser window…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of FIGUEROA to include new browsing tab of web application with different embedding context from the first browsing tab to load web application as disclosed by Reddy and be motivated in doing so in order to have a single browsing window for multiple tabs and applications which simplifies window management.
Regarding claim 7, FIGUEROA in view of Reddy discloses the method of claim 1.
FIGUEROA further discloses wherein the first web application is associated with a plurality of application instances (¶0022-¶0023, “At some point during the session 150, the user 114 may operate a cursor 224 to select the control 222 (e.g., a hamburger icon). Upon selecting the control 222, the browser displays a list 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 ("App 2"), a third web application ("App 3"), a fourth web application ("App 4"), and a "Platform" application, e.g., an application that unifies the other applications in a common framework…”), wherein generating the unique identifier is performed by a first instance of the first web application (¶0029, “the first web application 132 creates session data 168 for session 150 (see also FIG. 1). The session data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval…At this time, the first web application 132 may also create a session key (SK) 168a, e.g., a random or pseudo-random number that uniquely identifies the session data 168. In a particular example, the first web application 132 stores the session data 168 in the Redis data store (part of 334) at a location defined by the session key 168a”).
Regarding claim 8, FIGUEROA in view of Reddy discloses the method of claim 7. wherein generating the current session for the user is performed at a second instance of the first web application different from the first instance (¶0014, “…After validating the single-use password, the technique further includes the first web application providing the session data to the second web application, thus enabling the second web application to participate in the session previously established between the first web application and the client application…”), (¶0033-¶0036, “One should appreciate that the cross-application request 160 is directed to the first web application 132, where the session 150 is currently active, rather than to the second web application 142, where the desired data or functionality that the user selected is actually provided…. The access request 164 includes the SUP 162 and may also identify the first web application 132 as the current session participant.”), (¶0047-¶0049, “… the first web application 132 sends session data 168 to the second web application 142 in response to receiving the session request 166. The session data 168 (i) pertains to the session 150 previously established between the client application 112 and the first web application 132 and (ii) enables the second web application 142 to participate in the session 150 with the client application 112, e.g., as the session 150a.”).
Claims 2, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over WO 2018183322 to FIGUEROA et al (hereinafter FIGUEROA) in view of US PGPUb. No. 20140108667 to Reddy et al. (hereinafter Reddy) and further in view of US. PGPub. No. 20030084165 to Kjellberg et al. (hereinafter Kjellberg).
Regarding claim 2, FIGUEROA in view of Reddy discloses the method of claim 1 wherein triggering to load the first web application comprises:
determining whether there is an existing session for the user at the first web application (¶0017, “the user 114 operates the client application 112 on the device 110. The client application 112 participates in a session 150 with the first web application 132. For example, the client application 112 is a web browser that renders web pages downloaded from the first web application 132. Alternatively, the client application 112 may be any web-enabled application or app, which interacts with web application 132 and exchanges data therewith…”);
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
Kjellberg discloses in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
(¶0038, “…Each user is assigned a unique user identifier (UI) and each session is assigned a unique session identifier (USI). A single UI can be assigned to only one USI. Therefore, a user can be synchronized with an ongoing session using either the UI or the USI…”), (¶0041, FIG. 3, “If the connect request does not have a USI associated with it, the connect request is sent to the authorization guard for authentication (step 740). For example, the user could enter a user name and password, or some other information that uniquely identifies a user. Once authenticated, the session manager uses the UI to locate an ongoing session (step 745). The UI is used to re-connect to an ongoing session primarily when the user changes client devices, and thus the USI is not readily available, or if the client device does not support the USI.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of FIGUEROA and Reddy include assigning the unique identifier to the ongoing session if it the session is not associated with the identifier as disclosed by Kjellberg and be motivated in doing so in order to have a user remains authenticated and connected to a session while migrating between provisioning applications, protocols and/or client devices which enables seamless user experience and secure user profiles-Kjellberg abstract in parts.
Regarding claim 10, FIGUEROA in view of Reddy discloses the non-transitory, computer-readable medium of claim 9, wherein triggering to load the first web application comprises:
determining whether there is an existing session for the user at the first web application (¶0017, “the user 114 operates the client application 112 on the device 110. The client application 112 participates in a session 150 with the first web application 132. For example, the client application 112 is a web browser that renders web pages downloaded from the first web application 132. Alternatively, the client application 112 may be any web-enabled application or app, which interacts with web application 132 and exchanges data therewith…”);
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
Kjellberg discloses in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
(¶0038, “…Each user is assigned a unique user identifier (UI) and each session is assigned a unique session identifier (USI). A single UI can be assigned to only one USI. Therefore, a user can be synchronized with an ongoing session using either the UI or the USI…”), (¶0041, FIG. 3, “If the connect request does not have a USI associated with it, the connect request is sent to the authorization guard for authentication (step 740). For example, the user could enter a user name and password, or some other information that uniquely identifies a user. Once authenticated, the session manager uses the UI to locate an ongoing session (step 745). The UI is used to re-connect to an ongoing session primarily when the user changes client devices, and thus the USI is not readily available, or if the client device does not support the USI.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of FIGUEROA and Reddy include assigning the unique identifier to the ongoing session if it the session is not associated with the identifier as disclosed by Kjellberg and be motivated in doing so in order to have a user remains authenticated and connected to a session while migrating between provisioning applications, protocols and/or client devices which enables seamless user experience and secure user profiles-Kjellberg abstract in parts.
Regarding claim 16, FIGUEROA in view of Reddy discloses the system of claim 15, wherein triggering to load the first web application comprises:
determining whether there is an existing session for the user at the first web application (¶0017, “the user 114 operates the client application 112 on the device 110. The client application 112 participates in a session 150 with the first web application 132. For example, the client application 112 is a web browser that renders web pages downloaded from the first web application 132. Alternatively, the client application 112 may be any web-enabled application or app, which interacts with web application 132 and exchanges data therewith…”);
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
Kjellberg discloses in response to determining that the existing session is a current session and is not associated with the unique identifier, assigning the current session with the unique identifier
(¶0038, “…Each user is assigned a unique user identifier (UI) and each session is assigned a unique session identifier (USI). A single UI can be assigned to only one USI. Therefore, a user can be synchronized with an ongoing session using either the UI or the USI…”), (¶0041, FIG. 3, “If the connect request does not have a USI associated with it, the connect request is sent to the authorization guard for authentication (step 740). For example, the user could enter a user name and password, or some other information that uniquely identifies a user. Once authenticated, the session manager uses the UI to locate an ongoing session (step 745). The UI is used to re-connect to an ongoing session primarily when the user changes client devices, and thus the USI is not readily available, or if the client device does not support the USI.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of FIGUEROA and Reddy include assigning the unique identifier to the ongoing session if it the session is not associated with the identifier as disclosed by Kjellberg and be motivated in doing so in order to have a user remains authenticated and connected to a session while migrating between provisioning applications, protocols and/or client devices which enables seamless user experience and secure user profiles-Kjellberg abstract in parts.
Claims 3, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over WO 2018183322 to FIGUEROA et al (hereinafter FIGUEROA) in view of US PGPUb. No. 20140108667 to Reddy et al. (hereinafter Reddy) and further in view of US. PGPub. No. 20180075231 to SUBRAMANIAN et al. (hereinafter SUBRAMANIAN).
Regarding claim 3, FIGUEROA in view of Reddy discloses the method of claim 1. wherein triggering to load the first web application comprises:
FIGUEROA further discloses wherein triggering to load the first web application comprises:
assigning the current session with the unique identifier (¶0018, “…Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session…”), (¶0033, “… the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416. One should appreciate that the cross-application request 160 is directed to the first web application 132, where the session 150 is currently active, rather than to the second web application 142, where the desired data or functionality that the user selected is actually provided.”).
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credential;
SUBRAMANIAN discloses in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credentials (¶0184, “…ID/password recovery 1020 is used to recover a user's ID and/or password. First time login flow 1022 is implemented when a user logs in for the first time (i.e., an SSO session does not yet exist). Authentication manager 1024 issues authentication tokens upon successful authentication. HTTP cookie manager 1026 saves the authentication token in an SSO cookie. Event manager 1028 publishes events related to SSO functionality.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA and Reddy to include generating session cookies comprising user credentials as disclosed by SUBRAMANIAN and be motivated in doing so in order to validate the cookie instead of validating the credentials, thus enhancing the security of the user credentials.
Regarding claim 11, FIGUEROA in view of Reddy discloses the non-transitory, computer-readable medium of claim 9.
FIGUEROA further discloses wherein triggering to load the first web application comprises:
assigning the current session with the unique identifier (¶0018, “…Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session…”), (¶0033, “… the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416. One should appreciate that the cross-application request 160 is directed to the first web application 132, where the session 150 is currently active, rather than to the second web application 142, where the desired data or functionality that the user selected is actually provided.”).
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credential;
SUBRAMANIAN discloses in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credentials (¶0184, “…ID/password recovery 1020 is used to recover a user's ID and/or password. First time login flow 1022 is implemented when a user logs in for the first time (i.e., an SSO session does not yet exist). Authentication manager 1024 issues authentication tokens upon successful authentication. HTTP cookie manager 1026 saves the authentication token in an SSO cookie. Event manager 1028 publishes events related to SSO functionality.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA and Reddy to include generating session cookies comprising user credentials as disclosed by SUBRAMANIAN and be motivated in doing so in order to validate the cookie instead of validating the credentials, thus enhancing the security of the user credentials.
Regarding claim 17, FIGUEROA in view of Reddy discloses the system of claim 15.
FIGUEROA further discloses wherein triggering to load the first web application comprises:
assigning the current session with the unique identifier (¶0018, “…Thus, the web application 142 uses the session data 168 as its current session data with the client application 112, such that there is no need to reauthenticate the user 114 or to establish a new session…”), (¶0033, “… the cross-application request 160 includes the session key 168a, i.e., the same session key that the client application 112 received and stored at 416. One should appreciate that the cross-application request 160 is directed to the first web application 132, where the session 150 is currently active, rather than to the second web application 142, where the desired data or functionality that the user selected is actually provided.”).
However, FIGUEROA in view of Reddy does not explicitly disclose the following limitation:
in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credential;
SUBRAMANIAN discloses in response to determining that there is no existing session for the user at the first web application, generating the current session for the user at the first web application, and generating session cookies comprising user credentials (¶0184, “…ID/password recovery 1020 is used to recover a user's ID and/or password. First time login flow 1022 is implemented when a user logs in for the first time (i.e., an SSO session does not yet exist). Authentication manager 1024 issues authentication tokens upon successful authentication. HTTP cookie manager 1026 saves the authentication token in an SSO cookie. Event manager 1028 publishes events related to SSO functionality.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA and Reddy to include generating session cookies comprising user credentials as disclosed by SUBRAMANIAN and be motivated in doing so in order to validate the cookie instead of validating the credentials, thus enhancing the security of the user credentials.
Claims 4-6, 12-14, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over WO 2018183322 to FIGUEROA et al. (hereinafter FIGUEROA) in view of US PGPUb. No. 20140108667 to Reddy et al. (hereinafter Reddy) and further in view of US. PGPub. No. 20180075231 to SUBRAMANIAN et al. (hereinafter SUBRAMANIAN) and further in view of Pat. No. 11722481 to Lopez et al. (hereinafter Lopez).
Regarding claim 4, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN discloses the method of claim 3.
However, FIGUEROA in view of Reddy and SUBRAMANIAN does not explicitly disclose the following limitation:
wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider.
Lopez discloses wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider (¶0006, “…The request for authentication may be, e.g., the user accessing a particular web page or Uniform Resource Locator (URL), such as a login page. The first identity provider application may be associated with a first set of functions, e.g., those associated with a first authentication protocol. The first identity provider application may send, to a second identity provider application, an indication of the request. The second identity provider application may be associated with a second set of functions, e.g., those associated with a second authentication protocol different from the first authentication protocol. The first identity provider application may create, e.g., in a storage device, a session associated with the request. That session may comprise session data, such as information identifying a user, a device used by the user. The session data may be identified by a unique string or other identifier. The second identity provider application may retrieve, using such an identifier, the session associated with the request. The second identity provider application may receive, from the user, authentication credentials, such as a username and password. The second identity provider application may authenticate the user based on the authentication credentials, e.g., using one or more of the second set of functions…”), (¶0050, FIG. 4, “…an authentication request by a user may indicate that a user will provide Kerberos-compliant authentication credentials, the first identity provider 302a may provide OAuth-based authentication, and the second identity provider 302b may provide Kerberos-based authentication, such that the second identity provider 302b should handle the authentication requested by the user. The indication of the second identity provider 302b may be a redirect to a URL associated with the second identity provider 302b…”), (¶0055, “based on the received authentication data, one or more functions, and/or one or more authentication protocols, the second identity provider 302b may authenticate a user of the user device 301…”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, and SUBRAMANIAN to include authenticating a user to a web page at a second identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
NOTE: The examiner noted that the above motivation equally applicable to claims 5-6, 12-14, and 18-20 respectively.
Regarding claim 12, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN discloses the non-transitory, computer-readable medium of claim 11.
However, FIGUEROA in view of Reddy and SUBRAMANIAN does not explicitly disclose the following limitation:
wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider.
Lopez discloses wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider (¶0006, “…The request for authentication may be, e.g., the user accessing a particular web page or Uniform Resource Locator (URL), such as a login page. The first identity provider application may be associated with a first set of functions, e.g., those associated with a first authentication protocol. The first identity provider application may send, to a second identity provider application, an indication of the request. The second identity provider application may be associated with a second set of functions, e.g., those associated with a second authentication protocol different from the first authentication protocol. The first identity provider application may create, e.g., in a storage device, a session associated with the request. That session may comprise session data, such as information identifying a user, a device used by the user. The session data may be identified by a unique string or other identifier. The second identity provider application may retrieve, using such an identifier, the session associated with the request. The second identity provider application may receive, from the user, authentication credentials, such as a username and password. The second identity provider application may authenticate the user based on the authentication credentials, e.g., using one or more of the second set of functions…”), (¶0050, FIG. 4, “…an authentication request by a user may indicate that a user will provide Kerberos-compliant authentication credentials, the first identity provider 302a may provide OAuth-based authentication, and the second identity provider 302b may provide Kerberos-based authentication, such that the second identity provider 302b should handle the authentication requested by the user. The indication of the second identity provider 302b may be a redirect to a URL associated with the second identity provider 302b…”), (¶0055, “based on the received authentication data, one or more functions, and/or one or more authentication protocols, the second identity provider 302b may authenticate a user of the user device 301…”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, and SUBRAMANIAN to include authenticating a user to a web page at a second identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
Regarding claim 18, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN discloses the system of claim 17.
However, FIGUEROA in view of Reddy and SUBRAMANIAN does not explicitly disclose the following limitation:
wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider.
Lopez discloses wherein in response to determining that there is no existing session for the user, triggering authentication of the user for the first web application at a second identity provider (¶0006, “…The request for authentication may be, e.g., the user accessing a particular web page or Uniform Resource Locator (URL), such as a login page. The first identity provider application may be associated with a first set of functions, e.g., those associated with a first authentication protocol. The first identity provider application may send, to a second identity provider application, an indication of the request. The second identity provider application may be associated with a second set of functions, e.g., those associated with a second authentication protocol different from the first authentication protocol. The first identity provider application may create, e.g., in a storage device, a session associated with the request. That session may comprise session data, such as information identifying a user, a device used by the user. The session data may be identified by a unique string or other identifier. The second identity provider application may retrieve, using such an identifier, the session associated with the request. The second identity provider application may receive, from the user, authentication credentials, such as a username and password. The second identity provider application may authenticate the user based on the authentication credentials, e.g., using one or more of the second set of functions…”), (¶0050, FIG. 4, “…an authentication request by a user may indicate that a user will provide Kerberos-compliant authentication credentials, the first identity provider 302a may provide OAuth-based authentication, and the second identity provider 302b may provide Kerberos-based authentication, such that the second identity provider 302b should handle the authentication requested by the user. The indication of the second identity provider 302b may be a redirect to a URL associated with the second identity provider 302b…”), (¶0055, “based on the received authentication data, one or more functions, and/or one or more authentication protocols, the second identity provider 302b may authenticate a user of the user device 301…”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, and SUBRAMANIAN to include authenticating a user to a web page at a second identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
Regarding claim 5, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the method of claim 4.
Lopez further discloses wherein the first identity provider and the second identity provider are not identical (¶0043, “…. Different identity providers may use one or more different functions. For example, the first identity provider 302a may use a first version of the OAuth authentication protocol that is associated with one or more first functions, and the second identity provider 302b may use a different version of the OAuth authentication protocol associated with one or more second functions, and there may be some similarity between the one or more first functions and the one or more second functions…”), (¶0039, “…Though only a single user device (the user device 301), two identity providers (the first identity provider 302a and the second identity provider 302b), and a single storage device (the storage device 303) are shown in FIG. 3, any number of such elements may be implemented. For example, five different identity providers may be implemented. One or more of the elements shown in FIG. 3 may be one or more computing devices and/or may be applications executing on one or more computing devices…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using different identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
Regarding claim 13, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the non-transitory, computer-readable medium of claim 12.
Lopez further discloses wherein the first identity provider and the second identity provider are not identical (¶0043, “…. Different identity providers may use one or more different functions. For example, the first identity provider 302a may use a first version of the OAuth authentication protocol that is associated with one or more first functions, and the second identity provider 302b may use a different version of the OAuth authentication protocol associated with one or more second functions, and there may be some similarity between the one or more first functions and the one or more second functions…”), (¶0039, “…Though only a single user device (the user device 301), two identity providers (the first identity provider 302a and the second identity provider 302b), and a single storage device (the storage device 303) are shown in FIG. 3, any number of such elements may be implemented. For example, five different identity providers may be implemented. One or more of the elements shown in FIG. 3 may be one or more computing devices and/or may be applications executing on one or more computing devices…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using different identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
Regarding claim 19, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the system of claim 18.
Lopez further discloses wherein the first identity provider and the second identity provider are not identical (¶0043, “…. Different identity providers may use one or more different functions. For example, the first identity provider 302a may use a first version of the OAuth authentication protocol that is associated with one or more first functions, and the second identity provider 302b may use a different version of the OAuth authentication protocol associated with one or more second functions, and there may be some similarity between the one or more first functions and the one or more second functions…”), (¶0039, “…Though only a single user device (the user device 301), two identity providers (the first identity provider 302a and the second identity provider 302b), and a single storage device (the storage device 303) are shown in FIG. 3, any number of such elements may be implemented. For example, five different identity providers may be implemented. One or more of the elements shown in FIG. 3 may be one or more computing devices and/or may be applications executing on one or more computing devices…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using different identity provider as disclosed by Lopez and be motivated in doing so in order to improve user experience by supporting preferred login methods and increases system resilience.
Regarding claim 6, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the method of claim 4.
FIGUEROA further discloses wherein, when the authentication of the user is triggered at the first identity provider, an established session for the user when the user was authenticated for the second web application is reused for authenticating the user for the first web application (¶0002, “…if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0043, “the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”). see also ¶0018-¶0020, and
Lopez further discloses wherein the second identity provider is identical to the first identity provider (¶0065, “…the first identity provider 302a and the second identity provider 302b may be the same or similar, such that authentication steps (such as providing the authentication data in step 408) may appear to be communicating with the same or a similar device.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using identical identity provider as disclosed by Lopez and be motivated in doing so in order to boost user experience via Single Sign- On (SSO) and reduces password fatigue.
Regarding claim 14, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the non-transitory, computer-readable medium of claim 12.
FIGUEROA further discloses wherein, when the authentication of the user is triggered at the first identity provider, an established session for the user when the user was authenticated for the second web application is reused for authenticating the user for the first web application (¶0002, “…if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0043, “the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”). see also ¶0018-¶0020, and
Lopez further discloses wherein the second identity provider is identical to the first identity provider (¶0065, “…the first identity provider 302a and the second identity provider 302b may be the same or similar, such that authentication steps (such as providing the authentication data in step 408) may appear to be communicating with the same or a similar device.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the computer-readable medium of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using identical identity provider as disclosed by Lopez and be motivated in doing so in order to boost user experience via Single Sign- On (SSO) and reduces password fatigue.
Regarding claim 20, FIGUEROA in view of Reddy and further in view of SUBRAMANIAN and further in view of Lopez discloses the system of claim 18.
FIGUEROA further discloses wherein, when the authentication of the user is triggered at the first identity provider, an established session for the user when the user was authenticated for the second web application is reused for authenticating the user for the first web application (¶0002, “…if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains”), (¶0043, “the session 150a proceeds between the client application 112 and the second web application 142. For example, the client application 112 issues requests to the second web application 142, and the second web application 142 provides responses to the client application 112. The second web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with the first web application 132.”). see also ¶0018-¶0020, and
Lopez further discloses wherein the second identity provider is identical to the first identity provider (¶0065, “…the first identity provider 302a and the second identity provider 302b may be the same or similar, such that authentication steps (such as providing the authentication data in step 408) may appear to be communicating with the same or a similar device.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of FIGUEROA, Reddy, SUBRAMANIAN, and Lopez to include authenticating a user to a web page using identical identity provider as disclosed by Lopez and be motivated in doing so in order to boost user experience via Single Sign- On (SSO) and reduces password fatigue.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20250106195.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights