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 .
1. This action is in response to the communication filed on February 6, 2025. Claims 1-13 were originally received for consideration. Per the received preliminary amendment, received on February 6, 2025, no claims have been added or cancelled.
2. Claims 1-13 are currently pending consideration.
Information Disclosure Statement
3. Initialed and dated copies of Applicant’s IDS (form 1449), received on 2/6/2025 and 5/30/2025, are attached to this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
4. Claim(s) 1-6, and 8-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (U.S. Patent Pub. No. US 2018/0131685) in view of Himawan et al. (U.S. Patent Pub. No. US 2016/0036854) further in view of Shetty (U.S. Patent 9,118,657).
Regarding claim 1, Sridhar discloses:
A method for managing access to a local application, located within a computer network, said method comprising:
an authentication phase comprising:
authenticating a user by an Identity As A Service (IDAAS) server located outside said computer network (paragraph 0036: the cloud-based IDP that provides a set of identity and access management functions to target SPs is referred to as an IDAAS which provides user authentication, SSO and authorization enforcement);
in an event of successful authentication, generating an authentication message (paragraph 0150-0154: generating an assertion at the IDP when a user logs into the SP, identifying the SP’s ACS-URL in the generated assertion and digitally signing the generated assertion using an IDP-certificate); that comprises
for said local application, authorization data associated with said user (paragraphs 0009, 0132: SSO is facilitated by SAML which communicates security information (authentication and authorization data) between an entity that provides user identities (IDAAS) and a service provider; Upon verification based on the public key of the identity provider, the assertion proxy can use the verified assertion to either allow or block access to the requested SaaS application);
transmitting said authentication message to a local authentication server, located in said computer network (paragraphs 0136-040: assertation proxy is a local proxy hosted by a CASM on premise for the entity); and
transmitting the authorization data associated with said user for said local application to a reverse proxy managing access by said user to said local application (paragraphs 0156-0159: the decrypted assertion is forwarded to a reverse proxy via the user’s client which strips the reverse proxy-domain and the decrypted assertion can be evaluated at the reverse proxy based one or more security policies (paragraph 0158)).
Sridhar does not explicitly disclose generating an authentication message that comprises a first list of application authorized for said user and when the local application is mentioned in the firs list, transmitting the authorization data. In an analogous art, Himawan discloses providing a list of credentials which can be shared and a list of applications which are authorized to use each of those credentials (paragraph 0016). Furthermore, Himawan discloses a message delineating the credentials required by a communication device and a list of authorized applications associated with each of those credentials (paragraph 0020). Himawan also discloses access control for each application including which application can access certain keys or perform certain operations (paragraph 0027). It would have been obvious to one of ordinary skill in the art to use the list identifying applications authorized to use credentials, as disclosed in Himawan, in the system of Sridhar to ensure that only authorized applications can use certain credentials (Himawan: paragraph 0027).
The combination of Sridhar and Himawan does not explicitly disclose a system explicitly not supporting authentication by identity federation. In an analogous art, Shetty discloses a system wherein a secure single sign-on is extended to a legacy web application that does not support the specific user authentication technique being used such as SAML by using a proxy that intercepts a request by a client computer and forwarding the intercepted request to a single sign-on identity provider (see Abstract, column 4, lines 44-61). It would have been obvious to use the method of Shetty in the system of Sridhar-Himawan to manage access to a legacy application that does not support federated authentication in order to allow single sign-on authentication to applications which do not support SAML or other authentication protocols without modifying the legacy application (Shetty: see Abstract).
Claim 2 is rejected as applied above in rejecting claim 1. Furthermore, Shetty discloses:
The method according to claim 1, further comprising selecting, or indicating, by the user of the local application (column 4, lines 43-53: a user attempts to access the legacy application by clicking on a link).
Claim 3 is rejected as applied above in rejecting claim 2. Furthermore, Shetty discloses:
The method according to claim 2, wherein said selecting the local application is carried out before the authenticating, by entering or selecting a URL of said local application (column 4, lines 43-53: a user attempts to access the legacy application by clicking on a link).
Claim 4 is rejected as applied above in rejecting claim 3. Furthermore, Sridhar discloses:
The method according to claim 3, further comprising, following the selecting the local application,
redirecting said user to the local authentication server, by the reverse proxy (paragraph 0087: redirecting traffic, using a reverse proxy, from an unmanaged device to a network security system for policy enforcement),
redirecting said user to the IDAAS server, by the local authentication server (paragraph 0072: SP redirects the browser to the IDP URL)
in order to perform the authenticating (paragraphs 0072-0073: IPD authenticates the user).
Claim 5 is rejected as applied above in rejecting claim 2. Furthermore, Sridhar discloses:
The method according to claim 2, wherein the selecting the local application is carried out after the authenticating, for by selecting said local application on the IDAAS server (paragraph 0066: an organization uses IDAAS provider as the IDP to perform identity management across the entire portfolio of SaaS application subscriptions).
Claim 6 is rejected as applied above in rejecting claim 5. Furthermore, Sridhar discloses:
The method according to claim 5, further comprising, following the selecting the local application,
redirecting said user to a URL of said local application (paragraph 0040: forward an authentication request to a CASM URL),
redirecting said user to the local authentication server, by the reverse proxy (paragraph 0087: redirecting traffic, using a reverse proxy, from an unmanaged device to a network security system for policy enforcement),
redirecting said user to the IDAAS server, by the local authentication server (paragraph 0072: SP redirects the browser to the IDP URL);
in order to carry out the generating the authentication message (paragraphs 0072-0073: IPD authenticates the user).
Claim 8 is rejected as applied above in rejecting claim 1. Furthermore, Sridhar discloses:
The method according to claim 1, further comprising, prior to the authentication phase, a registration phase comprising configuring the reverse proxy for the local application (paragraph 0064, Fig. 2: before the SSO authentication method can work, the organization on behalf of the user, establishes a trust relationship with the IDP in a separate off-line or out-of-band process).
Claim 9 is rejected as applied above in rejecting claim 8. Furthermore, Himawan discloses:
The method according to claim 8, wherein the registration phase further comprises declaring the first list to the IDAAS server (paragraphs 0016, 0020, 0027: provides a list of credentials and the application that are authorized to use the credentials).
Claim 10 is rejected as applied above in rejecting claim 8. Furthermore, Himawan discloses:
The method according to claim 8, wherein the registration phase further comprises a declaring a second list to the IDAAS server (paragraph 0016: can provide a list of access restrictions associated with each credential).
Claim 11 is rejected as applied above in rejecting claim 1. Furthermore, Sridhar discloses:
The method according to claim 1, wherein the reverse proxy
is dedicated to the local application, or
is shared by the local application and at least one other local application, said reverse proxy executing a URL rewriting mechanism configured to add a URL prefix for said local application (paragraph 0142: at the reverse proxy the URLs are rewritten with rewritten URLs that redirect subsequent traffic from the user’s client during the federated SSO authenticated session through the reverse proxy).
Regarding claim 12, Sridhar discloses:
A computer program comprising computer instructions, which when executed by a computer, implement a method for managing access to a local application, located within a computer network, said method comprising:
an authentication phase comprising
authenticating a user by an Identity As A Service (IDAAS) server located outside said computer network (paragraph 0036: the cloud-based IDP that provides a set of identity and access management functions to target SPs is referred to as an IDAAS which provides user authentication, SSO and authorization enforcement);
in an event of successful authentication, generating an authentication message (paragraph 0150-0154: generating an assertion at the IDP when a user logs into the SP, identifying the SP’s ACS-URL in the generated assertion and digitally signing the generated assertion using an IDP-certificate) that comprises
transmitting said authentication message to a local authentication server, located in said computer network (paragraphs 0136-040: assertation proxy is a local proxy hosted by a CASM on premise for the entity); and
transmitting the authorization data associated with said user for said local application to a reverse proxy managing access by said user to said local application (paragraphs 0156-0159: the decrypted assertion is forwarded to a reverse proxy via the user’s client which strips the reverse proxy-domain and the decrypted assertion can be evaluated at the reverse proxy based one or more security policies (paragraph 0158)).
Sridhar does not explicitly disclose generating an authentication message that comprises a first list of application authorized for said user and when the local application is mentioned in the firs list, transmitting the authorization data. In an analogous art, Himawan discloses providing a list of credentials which can be shared and a list of applications which are authorized to use each of those credentials (paragraph 0016). Furthermore, Himawan discloses a message delineating the credentials required by a communication device and a list of authorized applications associated with each of those credentials (paragraph 0020). Himawan also discloses access control for each application including which application can access certain keys or perform certain operations (paragraph 0027). It would have been obvious to one of ordinary skill in the art to use the list identifying applications authorized to use credentials, as disclosed in Himawan, in the system of Sridhar to ensure that only authorized applications can use certain credentials (Himawan: paragraph 0027).
The combination of Sridhar and Himawan does not explicitly disclose a system explicitly not supporting authentication by identity federation. In an analogous art, Shetty discloses a system wherein a secure single sign-on is extended to a legacy web application that does not support the specific user authentication technique being used such as SAML by using a proxy that intercepts a request by a client computer and forwarding the intercepted request to a single sign-on identity provider (see Abstract, column 4, lines 44-61). It would have been obvious to use the method of Shetty in the system of Sridhar-Himawan to manage access to a legacy application that does not support federated authentication in order to allow single sign-on authentication to applications which do not support SAML or other authentication protocols without modifying the legacy application (Shetty: see Abstract).
Regarding claim 13, Sridhar discloses:
A system that manages access to a local application located within a computer network, said system comprising:
a local authentication server in said computer network (paragraphs 0136-040: assertation proxy is a local proxy hosted by a CASM on premise for the entity),
at least one reverse proxy in said computer network (paragraphs 0156-0159: the decrypted assertion is forwarded to a reverse proxy via the user’s client which strips the reverse proxy-domain and the decrypted assertion can be evaluated at the reverse proxy based one or more security policies (paragraph 0158)); and
an IDAAS server an Identity As A Service (IDAAS) server (paragraph 0036: IDAAS provides user authentication);
configured to implement an authentication phase comprising authenticating a user by said IDAAS server located outside said computer network (paragraph 0036: the cloud-based IDP that provides a set of identity and access management functions to target SPs is referred to as an IDAAS which provides user authentication, SSO and authorization enforcement);
transmitting said authentication message to the local authentication server, located in said computer network (paragraphs 0136-040: assertation proxy is a local proxy hosted by a CASM on premise for the entity); and
transmitting the authorization data associated with said user for said local application to said at least one reverse proxy managing access by said user to said local application (paragraphs 0156-0159: the decrypted assertion is forwarded to a reverse proxy via the user’s client which strips the reverse proxy-domain and the decrypted assertion can be evaluated at the reverse proxy based one or more security policies (paragraph 0158)).
Sridhar does not explicitly disclose generating an authentication message that comprises a first list of application authorized for said user and when the local application is mentioned in the firs list, transmitting the authorization data. In an analogous art, Himawan discloses providing a list of credentials which can be shared and a list of applications which are authorized to use each of those credentials (paragraph 0016). Furthermore, Himawan discloses a message delineating the credentials required by a communication device and a list of authorized applications associated with each of those credentials (paragraph 0020). Himawan also discloses access control for each application including which application can access certain keys or perform certain operations (paragraph 0027). It would have been obvious to one of ordinary skill in the art to use the list identifying applications authorized to use credentials, as disclosed in Himawan, in the system of Sridhar to ensure that only authorized applications can use certain credentials (Himawan: paragraph 0027).
The combination of Sridhar and Himawan does not explicitly disclose a system explicitly not supporting authentication by identity federation. In an analogous art, Shetty discloses a system wherein a secure single sign-on is extended to a legacy web application that does not support the specific user authentication technique being used such as SAML by using a proxy that intercepts a request by a client computer and forwarding the intercepted request to a single sign-on identity provider (see Abstract, column 4, lines 44-61). It would have been obvious to use the method of Shetty in the system of Sridhar-Himawan to manage access to a legacy application that does not support federated authentication in order to allow single sign-on authentication to applications which do not support SAML or other authentication protocols without modifying the legacy application (Shetty: see Abstract).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (U.S. Patent Pub. No. US 2018/0131685) in view of Himawan et al. (U.S. Patent Pub. No. US 2016/0036854) further in view of Shetty (U.S. Patent 9,118,657) in further in view of Ansari et al. (U.S. Patent 2008/0189774).
Claim 7 is rejected as applied above in rejecting claim 1. Furthermore, the combination of Sridhar, Himawan and Shetty do not explicitly disclose an IDAAS server configuration version number; wherein at least one of the data items is used to check synchronization between the IDAAS server and the local authentication server. Himawan discloses wherein the authentication message further comprises data items comprising at least one of a second list of applications associated with domain of the local authentication server (paragraph 0016: can provide a list of access restrictions associated with each credential). However, the combination does not disclose an IDAAS server configuration version number, wherein at least one of the data items is used to check synchronization between the IDAAS server and the local authentication server. In an analogous art, Ansari discloses a configuration manager which determines that the gateway device has the most current version of the configuration information (paragraph 0126) and upon receipt of information concerning the latest configuration information, the configuration manager checks the version of the configuration information received against the configuration information version installed on the gateway device (paragraph 0126). Therefore, it would have been obvious to one of ordinary skill in the art to use the configuration version information of Ansari in the authentication message disclosed by the combination of Sridhar, Himawan, and Shetty to allow the local authentication server to maintain a current configuration version at the IDAAS server when the versions do not match (Ansari: paragraph 0126).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAVEH ABRISHAMKAR whose telephone number is (571)272-3786. The examiner can normally be reached M-F 9-5:30.
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, Jung Kim can be reached at 571-272-3804. 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.
/KAVEH ABRISHAMKAR/
08/20/2026Primary Examiner, Art Unit 2494
Prosecution Insights