DETAILED ACTION
This Non Final Office Action is in response to Application filed on 06/24/2024. Claims 1-20 filed on 06/24/2024 are being considered on the merits.
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 .
Drawings
The drawings filed on 06/24/2024 are accepted.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “local device is configured to:…” in claim 12.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Structures and functions of the aforementioned limitations are disclosed in e.g. [0032] and illustrated in Figure 6.
Claim Objections
Claim 10 objected to because of the following informalities:
Claim 10 recites “he request to open the web portal”, should be “he request to open a web portal”
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3, 5-7, 9, 12, 14, 16-18 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Grandcolas (US 7137006 B1).
Regarding Claim 1, Grandcolas teaches a computerized method for providing a secure access to a webpage (Grandcolas Abstract “Methods and systems for single sign-on user access to multiple web servers…The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server offering the service indicated by the selector). ”), the method comprising:
obtaining, at an authentication server from a user agent application, a request to open the webpage provided by a web server, together with a username (Grandcolas Col. 1 line 65-67 and Col.2 line 1-2 “…a user is authenticated at a first web server (e.g., by user name and password). The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server (i.e. web server) offering the service indicated by the selector).”, Col. 2 line 18-23 “…the method comprises allowing a user at a computing device to access a first web server (i.e. authentication server) in the federation of web servers via a web browser (i.e. agent application) of the computing device, authenticating the user with user-provided authentication information (i.e. username), including at least a user identification, by the first web server”, Figure 2 50 illustrates request pertaining to bill payment via web browser for a webpage illustrated in Figure 3);
generating a token by the authentication server (Grandcolas Col. 2 line 29-32 “…the first web server creates an authentication token for the user including at least the user identification and with a pre-defined token expiry by the first web server, digitally signing (e.g., by public key encryption) the authentication token by the first web server”);
providing, by the authentication server, the token to the user agent application and to the web server (Grandcolas Col. 2 line 36-38 “…sending the digitally signed authentication token to the web browser of the computing device by the first web server”, Col. 4 line 16-29 “Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentication token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers. A function of an embodiment of an authentication token is to convey the necessary information from a primary (or first) server to a secondary (or second) server to allow the secondary server to skip the sign-on process that would otherwise be necessary and required.”);
sending, by the user agent application, a request to open the webpage together with the token to the web server (Grandcolas Col. 7 line 9-18 “The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets Layer (SSL) session. Further, in the embodiment shown, on receipt of the redirect command, the customer client 10 opens a second browser window, requests a download of the home page at the URL of the web site 42 (or the page designated in the URL), receives the page of the web site 42 from the bank web server 40, and displays the page in the window… The cookie received by the customer client 10 from the brokerage firm web server 30 is sent by the customer client 10 to the bank web server 40.”, where the cookie is the authentication token as disclosed in e.g. Col. 4 line 52-53);
verifying, by the web server, the token obtained from the user agent application against the token obtained from the authentication server (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”); and
opening the webpage by the web server upon successful verification (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 3, Grandcolas teaches the method of claim 1, comprising authenticating the user by the authentication server prior to generating the token (Grandcolas Col. 1 line 65-66 “…a user is authenticated at a first web server (e.g., by user name and password).”, further Col. 2 line 18-23, where after authentication of the user by the first web server, --the token is built/created, as disclosed in e.g. Col. 1 60-67 though Col. 2 line 1-15).
Regarding claim 5, Grandcolas teaches the method of claim 1, comprising operating a web browser by the user agent application (Grandcolas Col.1 line 43-50 “The customer's personal computer 10 having a web browser such as Microsoft Internet Explorer or Netscape Navigator (a client) is in communication with the Internet 20 as well. The customer 5 uses the customer's personal computer and browser 10 to communicate with the web servers 30, 40 via the Internet.”, Col. 2 line 18-21 “…the method comprises allowing a user at a computing device to access a first web server in the federation of web servers via a web browser of the computing device”).
Regarding claim 6, Grandcolas teaches the method of claim 5, comprising providing the webpage to the user through the web browser (Grandcolas Col.1 line 43-50 “The customer's personal computer 10 having a web browser such as Microsoft Internet Explorer or Netscape Navigator (a client) is in communication with the Internet 20 as well. The customer 5 uses the customer's personal computer and browser 10 to communicate with the web servers 30, 40 via the Internet.”, Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 7, Grandcolas teaches the method of claim 6, wherein providing the webpage comprises: sending, by the authentication server to the web browser, a single sign-on (SSO) token (Col. 2 line 36-38 “…sending the digitally signed authentication token to the web browser of the computing device by the first web server”, where the built authentication token is a single sign on token, since it is created based on “single sign-on user access to multiple web servers” as disclosed in Col 1 line 63);
using the SSO token to authenticate the user (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”); and
opening the webpage via the web browser, upon successful verification of the SSO token (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 9, Grandcolas teaches the method of claim 1, wherein the token is valid for a limited period (Grandcolas Col. 2 line 9 and 29-32 “The authentication token comprises an expiration time…the first web server creates an authentication token for the user including at least the user identification and with a pre-defined token expiry by the first web server).
Regarding claim 12, Grandcolas teaches a system for providing a secure access to a webpage (Grandcolas Abstract “Methods and systems for single sign-on user access to multiple web servers…The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server offering the service indicated by the selector). ”), the system comprising:
a web server (Grandcolas server 40 in Figure 1, which is also equivalent to the second server disclosed in e.g. Col. 1 line 65-67 and Col.2 line 1-2);
a local device (Grandcolas Figure 1 Customer Client 10); and
an authentication server (Grandcolas server 30 in Figure 1, which is also equivalent to the first server disclosed in e.g. Col. 1 line 65-67 and Col.2 line 1-2) configured to:
obtain, from local device, a request to open the webpage provided by the web server, together with a username (Grandcolas Col. 1 line 65-67 and Col.2 line 1-2 “…a user is authenticated at a first web server (e.g., by user name and password). The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server (i.e. web server) offering the service indicated by the selector).”, Col. 2 line 18-23 “…the method comprises allowing a user at a computing device to access a first web server (i.e. authentication server) in the federation of web servers via a web browser (i.e. agent application) of the computing device, authenticating the user with user-provided authentication information (i.e. username), including at least a user identification, by the first web server”, Figure 2 50 illustrates request pertaining to bill payment via web browser for a webpage illustrated in Figure 3);
generate a token (Grandcolas Col. 2 line 29-32 “…the first web server creates an authentication token for the user including at least the user identification and with a pre-defined token expiry by the first web server, digitally signing (e.g., by public key encryption) the authentication token by the first web server”); and
provide the token to the local device and to the web server (Grandcolas Col. 2 line 36-38 “…sending the digitally signed authentication token to the web browser of the computing device by the first web server”, Col. 4 line 16-29 “Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentication token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers. A function of an embodiment of an authentication token is to convey the necessary information from a primary (or first) server to a secondary (or second) server to allow the secondary server to skip the sign-on process that would otherwise be necessary and required.”);
wherein the local device is configured to:
send a request to open the webpage together with the token to the web server (Grandcolas Col. 7 line 9-18 “The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets Layer (SSL) session. Further, in the embodiment shown, on receipt of the redirect command, the customer client 10 opens a second browser window, requests a download of the home page at the URL of the web site 42 (or the page designated in the URL), receives the page of the web site 42 from the bank web server 40, and displays the page in the window… The cookie received by the customer client 10 from the brokerage firm web server 30 is sent by the customer client 10 to the bank web server 40.”, where the cookie is the authentication token as disclosed in e.g. Col. 4 line 52-53);
wherein the web server is configured to:
verify the token obtained from the local device against the token obtained from the authentication server (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”); and
open the webpage upon successful verification (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 14, Grandcolas teaches the system of claim 12, wherein the authentication server is configured to authenticate the user prior to generating the token (Grandcolas Col. 1 line 65-66 “…a user is authenticated at a first web server (e.g., by user name and password).”, further Col. 2 line 18-23, where after authentication of the user by the first web server, --the token is built/created, as disclosed in e.g., Col. 1 60-67 though Col. 2 line 1-15).
Regarding claim 16, Grandcolas teaches the system of claim 12, wherein the local device is configured to operate a web browser (Grandcolas Col.1 line 43-50 “The customer's personal computer 10 having a web browser such as Microsoft Internet Explorer or Netscape Navigator (a client) is in communication with the Internet 20 as well. The customer 5 uses the customer's personal computer and browser 10 to communicate with the web servers 30, 40 via the Internet.”, Col. 2 line 18-21 “…the method comprises allowing a user at a computing device to access a first web server in the federation of web servers via a web browser of the computing device”).
Regarding claim 17, Grandcolas teaches the system of claim 16, wherein the local device is configured to provide the webpage to the user through the web browser (Grandcolas Col.1 line 43-50 “The customer's personal computer 10 having a web browser such as Microsoft Internet Explorer or Netscape Navigator (a client) is in communication with the Internet 20 as well. The customer 5 uses the customer's personal computer and browser 10 to communicate with the web servers 30, 40 via the Internet.”, Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 18, Grandcolas teaches the system of claim 17, wherein the authentication server is configured to send a single sign-on (SSO) token to the web browser (Col. 2 line 36-38 “…sending the digitally signed authentication token to the web browser of the computing device by the first web server”, where the built authentication token is a single sign on token, since it is created based on “single sign-on user access to multiple web servers” as disclosed in Col 1 line 63) and
use the SSO token to authenticate the user (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”); and
wherein the local device is configured to open the webpage via the web browser upon successful verification of the SSO token (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Regarding claim 20, Grandcolas teaches the system of claim 1, wherein the token is valid for a limited period (Grandcolas Col. 2 line 9 and 29-32 “The authentication token comprises an expiration time…the first web server creates an authentication token for the user including at least the user identification and with a pre-defined token expiry by the first web server).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 2, 10 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Grandcolas (US 7137006 B1) in view of Bhabbur (US 9985786 B1)
Regarding claim 2, Grandcolas teaches the method of claim 1, comprising [[signing the token by the user agent application using a private key owned by the user agent application prior to providing the token to the web server]], wherein sending, by the user agent application, the token to the web server comprises sending the [[signed]] token, wherein the web server to verify the [[signed]] token obtained from the user agent application against the token obtained from the authentication server [[using a public key corresponding to the private key]] (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”).
Grandcolas does not disclose the signing the token by the user agent application using a private key owned by the user agent application prior to providing the token to the web server.
Bhabbur discloses signing the token by the user agent application using a private key owned by the user agent application prior to providing the token to the web server and verifying the signed token using public key associated with the private key (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 “…upon receiving the request for access, the application server 68 may determine whether the request is associated with a currently authenticated session with the browser 66. In some cases, this may include determining whether an authentication token is appended to the request 74, for instance as a query parameter, and determining that such an appended authentication token corresponds to a valid authenticated session, such as one that is not been expired, and corresponds to a list of authentication tokens that are valid stored in memory of the application server 68. Or in some cases, techniques like those described above by which a value demonstrate in possession of a password may be used in place of sending the actual authentication token, for instance the application server 68 may receive a cryptographic hash value calculated based on an authentication token, or the requested access may be signed by a private key corresponding to the session held by the browser 66, and the application server 68 may verify the signature with the public key corresponding to the session provided to the application server 68 by the authorization server 70 in an earlier authorization. Upon determining that the request for access 74 is associated with an already authenticated session, in some cases, the application server 68 may send the requested resources, such as webpage content, files, application program interface request responses, or the like, back to the application executing client-side, such as the browser 66. In the illustrated example, the application server 68 determines that the request for access 74 is not part of a currently authenticated session. In response, the application server 68 may respond by sending instructions to the browser 66 to display a user interface by which the user 62 may enter various user credentials, such as hypertext markup language instructions, scripting language instructions (e.g. JavaScript or web assembly), and various other resources, like images and styling instructions, back to the browser 66. In some embodiments, those instructions may include user interface inputs having corresponding event handlers configured to send data entered into the user interface inputs by the user 62 back to the application server 68 upon a corresponding event being sent to the event handler by the browser 66. Events may include an on click event, a key entry event, and on touch event, a touch release event, or other input gestures. In some cases, the instructions may include instructions that obtain other types of user credentials, such as a value indicative of a biometric measurement, e.g., one or more features in a facial scan or a fingerprint scan, or a cryptographic hash value or cryptographic signature sent by the client device responsive to the request or by some other third-party biometric authentication service responsive to the request, back to the application server 68.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas to incorporate the teaching of Bhabbur to utilize the above feature, with the motivation of ensuring authentication of a session, as recognized by (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 and throughout).
Regarding claim 10, Grandcolas teaches a computerized method for providing a secure access to a webpage (Grandcolas Abstract “Methods and systems for single sign-on user access to multiple web servers…The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server offering the service indicated by the selector). ”), the method comprising:
obtaining, in a user agent application, a request to open a webpage (Grandcolas Col. 1 line 65-66 “…a user is authenticated at a first web server (e.g., by user name and password).”, Col. 2 line 18-23 “…the method comprises allowing a user at a computing device to access a first web server (i.e. authentication server) in the federation of web servers via a web browser (i.e. agent application) of the computing device, authenticating the user with user-provided authentication information (i.e. username), including at least a user identification, by the first web server”, Figure 2 50 illustrates request pertaining to bill payment via web browser for a webpage illustrated in Figure 3, where the request pertains to the customer request clicking on the hyperlink 102 in Figure 3 as disclosed in Col. 4 line 1-9);
sending, by the user agent application, the request to open the web portal to an authentication server, together with a username (Grandcolas Col. 1 line 65-66 “…a user is authenticated at a first web server (e.g., by user name and password).”, Col. 2 line 18-23 “…the method comprises allowing a user at a computing device to access a first web server (i.e. authentication server) in the federation of web servers via a web browser (i.e. agent application) of the computing device, authenticating the user with user-provided authentication information (i.e. username), including at least a user identification, by the first web server”, Figure 2 50 illustrates request pertaining to bill payment via web browser for a webpage illustrated in Figure 3, where the authentication with the username/password is construed as a request sent to the authentication server to access a bill payment webpage/portal);
generating a token by the authentication server (Grandcolas Col. 2 line 29-32 “…the first web server creates an authentication token for the user including at least the user identification and with a pre-defined token expiry by the first web server, digitally signing (e.g., by public key encryption) the authentication token by the first web server”);
sending, by the authentication server, the token to the user agent application (Grandcolas Col. 2 line 36-38 “…sending the digitally signed authentication token to the web browser of the computing device by the first web server”);
sharing, by the authentication server, the token with a portal server (Grandcolas Col. 4 line 16-29 “Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentication token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers (i.e. portal server). A function of an embodiment of an authentication token is to convey the necessary information from a primary (or first) server to a secondary (or second) server to allow the secondary server to skip the sign-on process that would otherwise be necessary and required.”);
[[signing the token by the user agent application using a private key owned by the user agent application;]]
sending, by the user agent application, the signed token together with an address of the webpage to the portal server (Grandcolas Col. 7 line 9-18 “The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets Layer (SSL) session. Further, in the embodiment shown, on receipt of the redirect command, the customer client 10 opens a second browser window, requests a download of the home page at the URL of the web site 42 (or the page designated in the URL), receives the page of the web site 42 from the bank web server 40, and displays the page in the window… The cookie received by the customer client 10 from the brokerage firm web server 30 is sent by the customer client 10 to the bank web server 40.”, where the cookie is the authentication token as disclosed in e.g. Col. 4 line 52-53, where the token is singed, where the signature is verified as illustrated in Figure 2 56 and 68 and Col. 2 line 41-43 and Col. 5 line 27-29);
verifying, by the portal server, the signed token against the shared token [[using a public key corresponding to the private key]] (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”); and
opening the webpage by the portal server upon successful verification (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
While Grandcolas discloses in e.g. Col. 7 line 34-44 decrypting and verifying signature as further illustrated in Figure 2 68, however Grandcolas does not explicitly disclose private key.
Bhabbur discloses signing the token by the user agent application using a private key owned by the user agent application and verifying the signed token using public key associated with the private key (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 “…upon receiving the request for access, the application server 68 may determine whether the request is associated with a currently authenticated session with the browser 66. In some cases, this may include determining whether an authentication token is appended to the request 74, for instance as a query parameter, and determining that such an appended authentication token corresponds to a valid authenticated session, such as one that is not been expired, and corresponds to a list of authentication tokens that are valid stored in memory of the application server 68. Or in some cases, techniques like those described above by which a value demonstrate in possession of a password may be used in place of sending the actual authentication token, for instance the application server 68 may receive a cryptographic hash value calculated based on an authentication token, or the requested access may be signed by a private key corresponding to the session held by the browser 66, and the application server 68 may verify the signature with the public key corresponding to the session provided to the application server 68 by the authorization server 70 in an earlier authorization. Upon determining that the request for access 74 is associated with an already authenticated session, in some cases, the application server 68 may send the requested resources, such as webpage content, files, application program interface request responses, or the like, back to the application executing client-side, such as the browser 66. In the illustrated example, the application server 68 determines that the request for access 74 is not part of a currently authenticated session. In response, the application server 68 may respond by sending instructions to the browser 66 to display a user interface by which the user 62 may enter various user credentials, such as hypertext markup language instructions, scripting language instructions (e.g. JavaScript or web assembly), and various other resources, like images and styling instructions, back to the browser 66. In some embodiments, those instructions may include user interface inputs having corresponding event handlers configured to send data entered into the user interface inputs by the user 62 back to the application server 68 upon a corresponding event being sent to the event handler by the browser 66. Events may include an on click event, a key entry event, and on touch event, a touch release event, or other input gestures. In some cases, the instructions may include instructions that obtain other types of user credentials, such as a value indicative of a biometric measurement, e.g., one or more features in a facial scan or a fingerprint scan, or a cryptographic hash value or cryptographic signature sent by the client device responsive to the request or by some other third-party biometric authentication service responsive to the request, back to the application server 68.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas to incorporate the teaching of Bhabbur to utilize the above feature, with the motivation of ensuring authentication of a session, as recognized by (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 and throughout).
Regarding claim 13, Grandcolas teaches the system of claim 12, [[wherein the local device is configured to sign the token using a private key owned by the local device prior to providing the token to the web server]], wherein the local device is configured to send the token to the web server by sending the [[signed]] token, wherein the web server is configured to verify the [[signed]] token obtained from the local device against the token obtained from the authentication server [[using a public key corresponding to the private key]] (Grandcolas Col. 7 line 23-36 “The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously exchanged public-private key decryption information. Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, encrypted string that is now decoded) 66.”).
While Grandcolas discloses in e.g. Col. 7 line 34-44 decrypting and verifying signature as further illustrated in Figure 2 68, however Grandcolas does not explicitly disclose private key.
Bhabbur discloses wherein the local device is configured to sign the token using a private key owned by the local device prior to providing the token to the web server and verifying the signed token using public key associated with the private key (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 “…upon receiving the request for access, the application server 68 may determine whether the request is associated with a currently authenticated session with the browser 66. In some cases, this may include determining whether an authentication token is appended to the request 74, for instance as a query parameter, and determining that such an appended authentication token corresponds to a valid authenticated session, such as one that is not been expired, and corresponds to a list of authentication tokens that are valid stored in memory of the application server 68. Or in some cases, techniques like those described above by which a value demonstrate in possession of a password may be used in place of sending the actual authentication token, for instance the application server 68 may receive a cryptographic hash value calculated based on an authentication token, or the requested access may be signed by a private key corresponding to the session held by the browser 66, and the application server 68 may verify the signature with the public key corresponding to the session provided to the application server 68 by the authorization server 70 in an earlier authorization. Upon determining that the request for access 74 is associated with an already authenticated session, in some cases, the application server 68 may send the requested resources, such as webpage content, files, application program interface request responses, or the like, back to the application executing client-side, such as the browser 66. In the illustrated example, the application server 68 determines that the request for access 74 is not part of a currently authenticated session. In response, the application server 68 may respond by sending instructions to the browser 66 to display a user interface by which the user 62 may enter various user credentials, such as hypertext markup language instructions, scripting language instructions (e.g. JavaScript or web assembly), and various other resources, like images and styling instructions, back to the browser 66. In some embodiments, those instructions may include user interface inputs having corresponding event handlers configured to send data entered into the user interface inputs by the user 62 back to the application server 68 upon a corresponding event being sent to the event handler by the browser 66. Events may include an on click event, a key entry event, and on touch event, a touch release event, or other input gestures. In some cases, the instructions may include instructions that obtain other types of user credentials, such as a value indicative of a biometric measurement, e.g., one or more features in a facial scan or a fingerprint scan, or a cryptographic hash value or cryptographic signature sent by the client device responsive to the request or by some other third-party biometric authentication service responsive to the request, back to the application server 68.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas to incorporate the teaching of Bhabbur to utilize the above feature, with the motivation of ensuring authentication of a session, as recognized by (Bhabbur Col. 15 line 25-67 and Col. 16 line 1-8 and throughout).
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Grandcolas (US 7137006 B1) in view of Quek (US 20230291724 A1)
Regarding claim 4, Grandcolas teaches the method of claim 3.
Grandcolas discloses user authentication, Grandcolas does not explicitly disclose the push notification.
Quek discloses wherein authenticating the user by the authentication server comprises: sending, by the authentication server, a push notification to the user via a user device; and obtaining, at the authentication server, a user confirmation from the user device ([00103-104] “…the authentication server 15 determines if the details of the user’s interaction with the push notification match the stored selected authentication verifier.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas to incorporate the teaching of Quek to utilize the above feature, where the push notification is a feature that allow quicker interactions, as recognized by (Quek [0114] and throughout).
Regarding claim 15, claim 15 is similar to claim 4, therefore rejected with the same rationale and motivation applied to claim 4.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Grandcolas (US 7137006 B1) in view of Pogrebinsky (US 20170163564 A1) and Rothschild (US 20240080306 A1)
Regarding claim 8, Grandcolas teaches the method of claim 6, wherein providing the webpage comprises:
sending, from the authentication server to the web browser, a single sign-on (SSO) token (Grandcolas Col. 4 line 16-29 “Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentication token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers. A function of an embodiment of an authentication token is to convey the necessary information from a primary (or first) server to a secondary (or second) server to allow the secondary server to skip the sign-on process that would otherwise be necessary and required.”);
sending, from the web browser to the authentication server, a request for executing the webpage (Grandcolas Col. 4 line 9-18 “the customer 10 requests bill payment 50 by clicking on the "bill payment" hyperlink 102. The brokerage firm web server 30 itself does not handle the process of bill payment, but the server 30 is programmed with the knowledge that the bank web server 40 handles such a process. The hyperlink 102 includes the URL of the bank web site 42. Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentication token 52.” Figure 2 illustrates the process to open a webpage pertaining to the bill payment);
[[sending, from the web browser to the authentication server the SSO token;
authenticating the user, by the authentication server, using the SSO token;]]
sending, from the authentication server to the web browser, a corresponding URL for the required webpage, upon successful verification of the user (Grandcolas Col 1 line 65-67 and Col. 2 line 1-3 “…a user is authenticated at a first web server (e.g., by user name and password). The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server offering the service indicated by the selector).”);
sending from the web browser, a request to open the URL to the web server (Grandcolas Col 1 line 65-67 and Col. 2 line 1-3 “…a user is authenticated at a first web server (e.g., by user name and password). The first web server provides a web page to the user having a service selector (e.g., a hyperlink comprising the URL of a second web server offering the service indicated by the selector).”, Col. 7 line 9-18 “The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets Layer (SSL) session. Further, in the embodiment shown, on receipt of the redirect command, the customer client 10 opens a second browser window, requests a download of the home page at the URL of the web site 42 (or the page designated in the URL), receives the page of the web site 42 from the bank web server 40, and displays the page in the window… The cookie received by the customer client 10 from the brokerage firm web server 30 is sent by the customer client 10 to the bank web server 40.”, where the cookie is the authentication token as disclosed in e.g. Col. 4 line 52-53);
[[forwarding the request to a verification service; verifying the SSO token by the verification service; and]]
opening the webpage by the web server via the web browser, upon successful verification of the SSO token (Grandcolas Figure 2 (66, 68, 74, 76) illustrates cookie/token verifications, and upon successful verification, then (Figure 2 78-80) webpage 110 in Figure 3 is available to the customer client Col. 8 line 23-25 “…the web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the web page 110 of the bank web site 42 that is shown in FIG. 3”).
Grandcolas does not disclose the below limitations.
Pogrebinsky dsicloses sending, from the web browser to the authentication server the SSO token; authenticating the user, by the authentication server, using the SSO token (Pogrebinsky [0019] “The authentication server 160 may transmit a security token (e.g., single sign-on (S SO) token, reduced sign-on (RSO) token) to the user device 120 (e.g., via the communication server 150). The security token is configured to allow the user device 120 to access data associated with one or more computing devices (e.g., cloud system 110, communication server 150, authentication server 160, application server 170) without providing user input for each computing device.”, where the authentication server determines user device is authorized to access data as disclosed in [0018] and accordingly transmit SSO token to the device such that in a subsequent time, the SSO token allows the user device to access data associated with the authentication server 160, where the SSO token is an affirmation that the user is authenticated, where the client device include web browser as disclosed in [0021]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas to incorporate the teaching of Pogrebinsky to utilize the above feature, with the motivation of allowing the user device to access data associated with one or more computing devices without requiring user input, as recognized by (Pogrebinsky [0019] and throughout).
Grandcolas in view of Pogrebinsky does not disclose the below limitation.
Rothschild dsicloses forwarding the request to a verification service; verifying the SSO token by the verification service (Rothschild [0065] “FIG. 4 illustrates a computer network configured for single sign-on authentication and an automated sharing of remote devices by multiple users using a file system, in accordance with an illustrative embodiment. In the example of FIG. 4, a source user device 410 submits an authentication request to a web server 420, which redirects the authentication request to an SSO service 425 for authentication of the source user device 410.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas in view of Pogrebinsky to incorporate the teaching of Rothschild to utilize the above feature, with the motivation of efficiently registering and serving new users, as recognized by (Rothschild [0067] and throughout).
Regarding claim 19, claim 19 is similar to claim 8, therefore rejected with the same rationale and motivation applied to claim 8.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Grandcolas (US 7137006 B1) in view of Bhabbur (US 9985786 B1) and Williams (US 20140282940 A1)
Regarding claim 11, Grandcolas in view of Bhabbur teaches the method of claim 10, wherein sharing, by the authentication server, the token with a portal server comprises:
Grandcolas in view of Bhabbur do not disclose common database. Emphases in italic.
Williams storing, by the authentication server, the token in a database common to the authentication server and to a portal server; and reading, by the portal server, the token from the common database ([0046] “The session token is stored at 218 in a shared database, i.e. a database that can be accessed by the first and second domains.”, [0049] “At 220a, the second domain optionally checks to determine whether the user's session with the first domain is valid. This may be done, for example, by checking the shared database for a session cookie with the first domain.” Further in [0051, 0053] “ At 224, the application server compares the received token to the token stored in the shared database…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Grandcolas in view of Bhabbur to incorporate the teaching of Williams to utilize the above feature, where a retrieving a token from a shared database would save time of retrieving the token by requesting or interacting with other entities.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
GANESAN (US 20070033393 A1) discloses “In accordance with the proposal, when the user wishes to access a web page at the web server, the browser at the user's network device sends a request including the encrypted cookie to the web server. The web server decrypts the encrypted cookie with the private key of the asymmetric crypto-key pair or the symmetric key, and then separates the signature, i.e. the signed user's ID and any applicable other status information, from the remainder of the cookie, i.e. the unsigned user's ID and any applicable other status information. The web server verifies that the signature corresponds to the remainder of the cookie, for example, by hashing the remainder of the cookie, i.e. the unsigned user's ID and any applicable other status information, using the same hash algorithm and hash key as was used to build the signature, and compares the hash result to the signature. If the user is authenticated, e.g. by matching this later hash result generated by the web server to the signature included in the decrypted cookie, the web server uses the unsigned user ID which is included in the decrypted cookie to identify customized information.”
LEE (US 20230093667 A1) dsicloses “A method of providing login information, the method comprising: sending, from a service web page executed on a browser, a login request to an authentication web page executed on the browser; executing, by the authentication web page, a single sign on (SSO) agent in an electronic device; sending, by the authentication web page, a request for authentication information of a user to the SSO agent; generating, by the SSO agent, a random number, and transmitting the random number to the authentication web page; generating an encrypted eigenvalue by encrypting the random number and a timestamp on an authentication web server using a private key, and transmitting the encrypted eigenvalue to the SSO agent; calling, by the SSO agent, an authentication application programming interface (API) server using a user authentication token stored in the electronic device to transmit the encrypted eigenvalue; validating the user authentication token on the authentication API server, and decrypting the encrypted eigenvalue using a public key corresponding to the private key to validate the encrypted eigenvalue; and receiving, by the SSO agent, a result of the validating from the authentication API server, and transmitting the authentication information to the authentication web server.”
Patel (US 20220028160 A1) discloses non-blocking token authentication cache.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/ Primary Examiner, Art Unit 2497