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 .
DETAILED ACTION
Claims 1-6 are elected on 07/30/2026 for examination on 07/30/2026. Claims 7-24 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), and canceled as being drawn to the nonelected groups, there being no allowable generic or linking claim. Election was made without traverse.
Examiner's Instructions for filing Response to this Office Action
When the Applicant submits amendments regarding to the claims in response the Office Action, the Examiner would appreciate Applicant if a clean copy of the claims is provided to facilitate the prosecution which otherwise requires extra time for editing the marked-up claims from OCR.
Please submit two sets of claims:
Set #1 as in a typical filing which includes indicators for the status of claim and all marked amendments to the claims; and
Set #2 as an appendix to the Arguments/Remarks for a clean version of the claims which has all the markups removed for entry by the Examiner.
Examiner’s Notes
The Examiner has considered US 12267317 B2 to Israeli to determine nonstatutory double patenting. It is noted that claim 1 of the US Patent #12267317 B2 is directed to a method of web browser control which is similar to the non-elect species IV (e.g., claim 11) of the instant application.
Claim Rejections - 35 USC § 112
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-6 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 pre-AIA the applicant regards as the invention.
The rejection(s) under 35 U.S.C. 112(b) is/are determined by the following reasons:
Claim 1 recites “the computer user with a predefined identity provider network address” unclearly or lacking sufficient antecedent basis. It is noted that claim 6 defines “a user of the web browser” which is different from a computer user with a predefined identity provider network address. See also claim 3 reciting “the user of the web browser” which is consistent with the definition of a user of the web browser in claim 1.
Claim 6 recites “the user” unclearly or lacking sufficient antecedent basis. It is unclear whether the user means “the user of the web browser” or “the computer user.”
Claims 2-6 are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, because they each depend from the rejected base claim 1.
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 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.
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.
Claims 1-3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Tarkoma (US 10594695 B2; hereinafter “Tarko”) in view of Parla (US 20150200924 A1).
As per claim 1, Tarco teaches a method of web browser control, the method comprising:
configuring a web browser to send to a first computer server a request by a user of the web browser to access a resource at the first computer server (col. 4, lines 65-67: the user requesting service, such as retrieving the content of a Web page by using a Web browser; col. 6, lines 53-63: the user requesting service, such as retrieving the content of a Web page by using a Web browser. It is noted that the service provider 303 or a content server is mapped to the first computer server in the claim; see FIG. 3: SP 303),
wherein the first computer server is configured to:
associate the computer user with a predefined identity provider network address (Tarko, col. 4, lines 54-67 and col. 5, lines 1-11: a user of the device on which the client 300 is running, has established identities both at the Identity Provider 301; the Identity Provider 301 has established an identity federation for the Principal's identities at the IdP and the Service Provider. This means Tarko’s user is associated with a predefined identity provider in the federation), and
redirect the web browser to access the identity provider network address (Tarko, col. 5, lines 50-55: when the client 300 requests a service in step 306 from the Service Provider 303 … the Service Provider 303 may direct the authentication request 307 to the Identity Provider 301, which may forward the authentication request to the Proxy ID Provider 302, or the Service Provider 303 may send the authentication request 307 directly to the Proxy ID Provider 302. It is noted that accessing the identity provider inherently involves accessing the identity provider network address); and
configuring the web browser to send to a second computer server, in response to receiving the identity provider network address from the first computer server, an authentication token and a request to access the identity provider network address (Tarko, col. 5, lines 35-55: sends or forwards the security tokens (GEN_TOKENS) in step 305 to the Proxy Identity Provider 302, which is mapped to the second computer server; see FIG. 3: Proxy-IdP 302),
wherein the second computer server is configured to
determine whether the authentication token is valid (Tarko, col 5, lines 55-67: the Proxy Identity Provider 302 (which is mapped to the second computer server) may check, whether it has received and stored a security token for the client 300 that corresponds to the authentication request 307. For example, the Proxy Identity Provider may check whether a security token with appropriate authentication information; col. 7, lines 22-35: check, whether …the security token for the client corresponds to the authentication request 406 … with appropriate authentication information …[including] an alias identity corresponding to the identity included in the request, a digital signature, or a session key.),
determine, responsive to the authentication token being valid, whether the request to access the identity provider network address is authorized (Tarko, col. 7, lines 39-45: If the Proxy Identity Provider of the entity 400 does not have any security token that corresponds to the authentication request, the client of the entity 400 may have to be authenticated at the Service Provider 402; see also col. 7, lines 48-67: In case an authentication of the client is needed, the Proxy Identity Provider of the entity 400 sends an authentication request … to the Identity Provider 401, which further determines the access authorization), and
send to the identity provider, responsive to the request to access the identity provider network address being authorized, the request to access the identity provider network address (Tarko, col. 7, lines 52-67 and col. 8, lines 1-4: sending to the identity provider a request for access; the Proxy Identity Provider may also request additional security tokens even if earlier security tokens have not been exhausted or expired).
However, Tarko does not explicitly disclose blocking attempts to access the identity provider when the network address as used is not a predefined valid network address of the second computer server. This aspect of the claim is identified as a further difference.
In a related art, Parla teaches:
wherein the identity provider is configured to:
associate the identity provider network address for use with incoming requests from the second computer server (Parla par. 0043-0044: a typical SAML flow and SSO process… the service provider host may be encoded in the domain name of the proxy, where https://<service provider host>.<company domain>/<obfuscated service provider protocol and path> would result in a proxy request to <service provider protocol>://<service provider host>/<service provider path>. For example https://www.serviceapplication.example.com/<path> would map to http[s]://www.serviceapplication.com/<path>.), and
block attempts to access the identity provider network address that are received from a sender network address that is not a predefined valid network address of the second computer server (Parla par. 0023-0026: sends a resource request to proxy 50. Proxy 50 sends the resource request to the service provider at 134; generate the subject locality field to indicate the IP address of the proxy from which requests to the service provider; par. 0024: Independent of SAML/SSO/authentication, service providers may restrict access to the service through IP whitelists/blacklists of the client IP address/network. The proxy IP address would need to be white-listed in this scenario, meaning attempts to access the identity provider network address may be blocked if not white-listed).
Parla and Tarko are analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify Tarko’s system with Parla’s teachings of using IP whitelists/blacklists to determined whether to block attempts to access the identity provider network address coming to the identify provider. For this combination, the motivation would have been to improve the level of security with predetermined list of valid network address of the second computer server (i.e., the proxy server).
As per claim 2, the references as combined above teach the method according to claim 1 wherein the web browser is configured with the authentication token (Tarko, col. 3, lines 49-52, col. 4, lines 64-67, and col. 5, lines 1-12: using a Web browser, from the Service Provider 303, or the client may contact the Identity Provider 301 by sending an authentication request message (INIT_AUTH) [containing] Principal's user ID as a token. The initial authentication of the client 300 at the Identity Provider may be performed by the Identity Provider by requesting any suitable authentication credentials, such as the Principal's user ID and its associated password, which may a one-time password (OTP), a passphrase, or a data entity, such as a software token or a digital certificate, from the client 300).
As per claim 3, the references as combined above teach the method according to claim 1 wherein the second computer server is configured to determine whether the request to access the identity provider network address is authorized by determining whether the user of the web browser is authorized to access the identity provider network address (Parla par. 0023-0026: Independent of SAML/SSO/authentication, service providers may restrict access to the service through IP whitelists/blacklists of the client IP address/network. The proxy IP address would need to be white-listed in this scenario, meaning attempts to access the identity provider network address may be blocked if not white-listed).
As per claim 5, the references as combined above teach the method according to claim 1 wherein the identity provider is configured with the predefined valid network address of the second computer server (Parla, par. 0024: restrict access to the service through IP whitelists/blacklists of the client IP address/network. The proxy IP address would need to be white-listed).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Tarko and Parla and further in view of Kermes (US 20190228144 A1).
As per claim 4, the references of Tarko and Parla as combined above teach the method according to claim 1 but do not explicitly disclose …. This aspect of the claim is identified as a further difference.
In a related art, Kermes teaches:
wherein the second computer server is configured to determine whether the request to access the identity provider network address is authorized by determining whether a tenant associated with the user of the web browser is authorized to access the identity provider network address (Kermes par. 0027, 0032, and 0042: validate the identity of the proxy server 310 and may transmit a ticket (e.g., authorization message) as part of an authorization process 335 to the user device 305. In some cases, for example, in massive multi-tenant database systems (e.g., with thousands or millions of users across the multiple tenants), multiple messages may be sent between many user devices 205 and the application server 215).
Kermes is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Tarko-Parla system with Kermes’s teachings of validating the identity of the proxy server and perform authentication for multi-tenant with thousands or millions of users. For this combination, the motivation would have been to improve the level of user authentication within a tenant-based network environment.
Allowable Subject Matter
Claim 6 is objected to as being dependent upon a rejected base claim but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 6 recites elements of “wherein the second computer server relays communications between the web browser and the identity provider until the user is authenticated by the identity provider and redirected by the identity provider to access the resource to which the user originally requested access at the first computer server.”. These elements and the features thereof in combination with the other limitations in claim 1, are not anticipated by, nor made obvious over the prior art of record.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art additionally discloses certain parts of the claim features (See “PTO-892 Notice of Reference Cited”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DON ZHAO whose telephone number is (571)272.9953. The examiner can normally be reached on Monday to Friday, 7:30 A.M to 5:00 P.M EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl G Colin can be reached on 571.272.3862. The fax phone number for the organization where this application or proceeding is assigned is 571.273.8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800.786.9199 (IN USA OR CANADA) or 571.272.1000.
/Don G Zhao/Primary Examiner, Art Unit 2493 09/23/2026
