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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/28/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim(s) 4-5 and 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak et al., US- 20220029965-A1 (hereinafter “Chanak ‘965”) in view of KUPPANNAN et al., US-20210051178-A1 (hereinafter “KUPPANNAN ‘178”).
Per claim 4 (independent):
Chanak ‘965 discloses: A computer program product comprising computer executable code embodied in non -transitory computer readable media that, when executing on one or more computing devices, causes the one or more computing devices to perform the steps of:
storing authentication components and authorization components for a data plane of a cloud-based zero trust network access service on a cloud platform;
storing a connector for zero trust network access on a customer premises;
coupling the connector to a threat management facility
(FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application (for zero trust network access) utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (a cloud-based zero trust network access service on a cloud platform) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B; one or more computing devices) that are remote and an on-premises connector 400 (storing a connector) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (on a customer premises) that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling authenticated traffic back to the enterprise is a key differentiator for ZTNA – by storing authentication components and authorization components for a data plane; [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share, not to the entire network ... deliver secure access by decoupling applications 402, 404 from the network, instead of providing access with a connector 400, in front of the applications 402, 404, an application on the user device 300, a central authority 152 (a threat management facility) to push policy, and the cloud-based system 100 to stitch the applications 402, 404 and the software connectors 400 together, on a per-user, per-application basis – coupling the connector to the threat management facility; FIG. 2, [0048], The central authority 152 hosts all customer (tenant) policy and configuration settings (storing authentication components and authorization components for a data plane) ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the data plane) for event logging);
the configuration information identifying an application on the customer premises to offer as a zero trust network access service;
coupling the connector through a secure tunnel to the cloud platform;
coupling the connector to the application on the customer premises; and
(FIG. 6, [0064], a Zero Trust Network Access (ZTNA; offer as a zero trust network access service) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (the cloud platform) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (the connector) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (the customer premises) that includes enterprise file shares and applications 404 (coupling the connector to the application on the customer premises) ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling (a secure tunnel; [0041] identifies IPSec as an example of a tunneling protocol) authenticated traffic back to the enterprise is a key differentiator for ZTNA (coupling the connector through a secure tunnel to the cloud platform); it is noted that the connector 400 is required to maintain at least one configuration information indicating which applications on the enterprise network 410, in this case, the applications 404, are to be connected to provide a ZTNA service; [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share, not to the entire network ... deliver secure access by decoupling applications 402, 404 from the network, instead of providing access with a connector 400, in front of the applications 402, 404, an application on the user device 300, a central authority 152 to push policy, and the cloud-based system 100 to stitch the applications 402, 404 and the software connectors 400 together, on a per-user, per-application basis);
managing zero trust network access to the application by a user through the data plane by authorizing and authenticating the user for the application with the authentication components and authorization components executing on the cloud platform (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100 (managing zero trust network access). For ZTNA, the cloud-based system 100 (the cloud platform) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B; a user) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404 (the application); [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share (managing zero trust network access to the application by a user), not to the entire network; FIG. 2, [0048], The central authority 152 hosts all customer (tenant) policy and configuration settings (authorizing and authenticating the user for the application with the authentication components and authorization components executing on the cloud platform, that is, the cloud-based security system 100) ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (through the data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (through the data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (through the data plane) for event logging).
Chanak ‘965 does not disclose but KUPPANNAN ‘178 discloses: receiving configuration information for the connector from the threat management facility (FIG. 2, [0044], The policy agent 218 (the connector) running on each, of the resources 211a, 211b, and 211c receives the respective security policy (receiving configuration information) specific to the respective resource 211a, 211b, and 211c from the policy controller 207 (from the threat management facility). In this example, the policy agents 218 on the resources 211a, 211b, and 211c convert the security policies received from the policy controller 207 into a format that can be used to configure host-based firewalls ... The policy agent 218 then applies the rules of the host-based firewall policy on the host-based firewall by calling either an appropriate operating system (OS) specific application programming interface (API) or a command depending on the operating system on which the host-based firewall policy is being applied).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Chanak ‘965 with the policy agent receiving a respective security policy specific to each respective resource for applying the rules on the host-based firewall as taught by KUPPANNAN ‘178 because it would automatically manage security policies at multiple resources by detecting, identifying, automatically correcting, and notifying modifications made to the security policies at the resources [0003]. Additionally, KUPPANNAN ‘178 is analogous to the claimed invention because it teaches a policy management engine receives and deploys a security policy configured for each resource with one or more configuration parameters [ABSTRACT].
Per claim 5 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 discloses: The computer program product of claim 4, wherein the application includes one or more of a productivity application, a database application, and a financial application ([0079], The private applications 402, 404 (the application) include applications dealing with financial data, personal data, medical data, intellectual property, records, etc.).
Per claim 9 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 discloses: The computer program product of claim 4, wherein the connector includes a data plane client for secure communications with the data plane of the cloud-based zero trust network access service (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100. For ZTNA, the cloud-based system 100 (the cloud-based zero trust network access service) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (the connector) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling authenticated traffic back to the enterprise is a key differentiator for ZTNA; it is noted that the connector 400 is required to establish secure communications with the data plane (see [0042]) that performs ZTNA-based access control to the applications 404 via a data plane client, which is implicit in the connector’s operation, because the connector 400 is positioned at the front end of the enterprise network 410; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the data plane of the cloud-based zero trust network access service) for tenant access to provide global policy and configuration ... further include connectiv-ity to an Identity Provider (IDP) 122 (the data plane of the cloud-based zero trust network access service) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the data plane of the cloud-based zero trust network access service) for event logging).
Per claim 10 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 discloses: The computer program product of claim 4, wherein the connector includes a cloud agent for secure communications with the threat management facility (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100. For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (the connector) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404; [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share, not to the entire network ... deliver secure access by decoupling applications 402, 404 from the network, instead of providing access with a connector 400, in front of the applications 402, 404, an application on the user device 300, a central authority 152 (the threat management facility) to push policy, and the cloud-based system 100 to stitch the applications 402, 404 and the software connectors 400 together, on a per-user, per-application basis; FIG. 2, [0048], The central authority 152 hosts all customer (tenant) policy and configuration settings ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.; it is noted that the connector 400 is required to establish secure communications with the threat management facility in order to support an authentication process for access control to the applications 404 via a cloud agent, which is implicit in the connector’s operation).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak ‘965 in view of KUPPANNAN ‘178 and Hardt, US-12314430-B1(hereinafter “Hardt ‘430”).
Per claim 6 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 in view of KUPPANNAN ‘178 does not disclose but Hardt ‘430 discloses: The computer program product of claim 4, wherein the authentication components include at least one Open Authorization 2.0 proxy ([Col. 19], ll.10-22, for providing a secure, scalable, and user-friendly architecture that preserves user privacy and provides data security:
The system platform serves as an abstraction layer or “proxy” (proxy) for user interactions with applications, developers and providers;
In some embodiments, a point of entry is OpenID Connect (OIDC)—a trusted identity layer on top of the OAuth 2.0 protocol (Open Authorization 2.0), which allows computing clients to verify the identity of an end-user based on the authentication (the authentication components) performed by an authorization server; FIG. 1, [Col. 15], ll.35-56, a typical sequence involved in a user logging into an application with an OpenID Connect login provider (Open Authorization 2.0 proxy) ...:
...
The browser sends the OIDC request to the login provider;
The login provider authenticates the user in any suitable manner).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Chanak ‘965 in view of KUPPANNAN ‘178 with the user login with an OpenID Connect login provider serving as a proxy based on the OAuth 2.0 protocol as taught by Hardt ‘430 because security of user data (and hence user privacy) is enhanced over conventional architectures and systems because of the separation/isolation [Col. 12]. Additionally, Hardt ‘430 is analogous to the claimed invention because it teaches protecting a user's private data and information regarding their browsing and other on-line activities [ABSTRACT].
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak ‘965 in view of KUPPANNAN ‘178 and Agaon, US- 20220083602-A1(hereinafter “Agaon ‘602”).
Per claim 7 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 in view of KUPPANNAN ‘178 does not disclose but Agaon ‘602 discloses: The computer program product of claim 4, wherein the authorization components include at least one Open Policy Agent ([0015], implementing an open policy agent bridge for entitlements determination relating to market data. According to an embodiment of the present invention, Open Policy Agent (OPA; Open Policy Agent) may be implemented as a policy engine to make decisions and determinations concerning fine-grained access control for an object, application, etc. (the authorization components) ... This setup allows users to offload authorization decisions form server applications to OPA).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Chanak ‘965 in view of KUPPANNAN ‘178 with the authorization of access control for an object, application, etc. via the OPA as taught by Agaon ‘602 because this setup allows users to offload authorization decisions form server applications to OPA [0015]. Additionally, Agaon ‘602 is analogous to the claimed invention because it teaches Open Policy Agent (OPA) may be implemented as a policy engine to make decisions and determinations concerning fine-grained access control for an application [ABSTRACT].
Claim(s) 11, 13, 15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara et al., US-20250023915-A1(hereinafter “Koikara ‘915”).
Per claim 11 (dependent on claim 4):
Chanak ‘965 in view of KUPPANNAN ‘178 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
Chanak ‘965 discloses: The computer program product of claim 4, further comprising code that performs the step of executing the connector for zero trust network access on the customer premises (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (executing the connector for zero trust network access) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (on the customer premises) that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint (performs the step of executing the connector). This on-demand dial-out capability and tunneling authenticated traffic back to the enterprise is a key differentiator for ZTNA).
Chanak ‘965 in view of KUPPANNAN ‘178 does not disclose but Koikara ‘915 discloses: executing the connector on a firewall on the customer premises ([0012], The method may also include establishing, by the endpoint client-based proxy, a transport layer security (TLS) connection between the endpoint clientbased proxy and a zero-trust network access (ZTNA) gateway (the connector) and determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; [0014], example configurations, a protected private service (e.g., an external service with respect to an enterprise network; the customer premises) refers to an application that is behind an enterprise gateway. The gateway refers to a firewall (a firewall) or any other proxy capable of authenticating users.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Chanak ‘965 in view of KUPPANNAN ‘178 with the authentication of users via a firewall operated by a ZTNA gateway as taught by Koikara ‘915 because private service can be protected more effectively by operating a ZTAN gateway through a firewall. Additionally, Koikara ‘915 is analogous to the claimed invention because it teaches techniques and architecture for eliminating double encryption in zero-trust network access authenticated sessions [0011].
Per claim 13 (independent):
Chanak ‘965 discloses: A method comprising:
executing a connector for zero trust network access on a customer premises;
coupling the connector to a threat management facility for the customer premises;
coupling the connector to a cloud-based data plane for the zero trust network access service;
(FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application (for zero trust network access) utilizing the cloudbased system 100. For ZTNA, the cloud-based (cloud-based) system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (executing a connector for zero trust network access) that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (on a customer premises) that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling authenticated traffic back to the enterprise is a key differentiator for ZTNA; [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share, not to the entire network ... deliver secure access by decoupling applications 402, 404 from the network, instead of providing access with a connector 400, in front of the applications 402, 404, an application on the user device 300, a central authority 152 (a threat management facility) to push policy, and the cloud-based system 100 to stitch the applications 402, 404 and the software connectors 400 together, on a per-user, per-application basis – coupling the connector to the threat management facility; FIG. 1, [0042], The cloud-based system 100 (as illustrated in FIG. 6, the cloud-based data plane within the system 100 are coupled to the connector 400 to facilitate access to the applications 404 for the ZTNA service) can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging);
managing zero trust network access to the application by a user through the cloud-based data plane by authenticating the user for the application with an authentication component configured through the threat management facility and executing in the cloud-based data plane (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100 (managing zero trust network access). For ZTNA, the cloud-based system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B; a user) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404 (the application); [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share (managing zero trust network access to the application by a user), not to the entire network; FIG. 2, [0048], The central authority 152 (the threat management facility) hosts all customer (tenant) policy and configuration settings (authenticating the user for the application with an authentication component) ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging).
Except for the limitation “on a firewall,” which is addressed separately below, the remaining limitations are rejected for the same reasons discussed in the rejection of claim 4.
Chanak ‘965 in view of KUPPANNAN ‘178 does not disclose but Koikara ‘915 discloses: executing a connector for zero trust network access on a firewall of a customer premises ([0012], The method may also include establishing, by the endpoint client-based proxy, a transport layer security (TLS) connection between the endpoint clientbased proxy and a zero-trust network access (ZTNA) gateway (a connector) and determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; [0014], example configurations, a protected private service (e.g., an external service with respect to an enterprise network; a customer premises) refers to an application that is behind an enterprise gateway. The gateway refers to a firewall (a firewall) or any other proxy capable of authenticating users.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Chanak ‘965 in view of KUPPANNAN ‘178 with the authentication of users via a firewall operated by a ZTNA gateway as taught by Koikara ‘915 because private service can be protected more effectively by operating a ZTAN gateway through a firewall.
Per claim 15 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Chanak ‘965 discloses: The method of claim 13, further comprising managing zero trust network access to the application by authorizing the user according with an authorization component configured through the threat management facility and executing in the cloud-based data plane (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloud-based system 100 (managing zero trust network access). For ZTNA, the cloud-based (cloud-based) system 100 can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B; the user) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404 (the application); [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share (managing zero trust network access to the application), not to the entire network; FIG. 2, [0048], The central authority 152 (the threat management facility) hosts all customer (tenant) policy and configuration settings (authorizing the user according with an authorization component configured through the threat management facility) ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging).
Per claim 17 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Chanak ‘965 discloses: The method of claim 13, wherein the cloud-based data plane executes on a cloud platform remote from the customer premises (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (a cloud platform) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (the customer premises, which is remote from the cloud platform, i.e., the cloud-based system 100 – see FIG. 6) that includes enterprise file shares and applications 404; FIG. 1, [0042], The cloud-based (cloud-based) system 100 can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging).
Per claim 18 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Chanak ‘965 discloses: The method of claim 13, wherein the threat management facility executes on a cloud platform remote from the customer premises (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (a cloud platform) can dynamically create a connection through a secure tunnel between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (the customer premises, which is remote from the cloud platform, i.e., the cloud-based system 100 – see FIG. 6) that includes enterprise file shares and applications 404; [0065], The paradigm of virtual private access systems and methods is to give users network access to get to an application and/or file share, not to the entire network ... deliver secure access by decoupling applications 402, 404 from the network, instead of providing access with a connector 400, in front of the applications 402, 404, an application on the user device 300, a central authority 152 (the threat management facility; as described in [0043], the central authority 152 is configured to “provide centralized policy, real-time threat updates, etc.”, thereby executing on the cloud platform, i.e., the cloud-based system 100) to push policy, and the cloud-based system 100 to stitch the applications 402, 404 and the software connectors 400 together, on a per-user, per-application basis).
Per claim 19 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Chanak ‘965 discloses: The method of claim 13, wherein coupling the connector to the cloud-based data plane includes coupling the connector through a secure tunnel to a cloud platform for the cloud-based data plane using one or more secure tunnel components of the cloud platform (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (the cloud platform) can dynamically create a connection through a secure tunnel (through a secure tunnel) between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 (the connector) – coupling the connector through a secure tunnel to a cloud platform – that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling (using one or more secure tunnel components of the cloud platform) authenticated traffic back to the enterprise is a key differentiator for ZTNA; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging; it is noted that the connector 400 is coupled to the cloud-based system 100, and subsequently, is further coupled to the cloud-based data plane (see [0042]) that performs ZTNA-based access control to the applications 404 before the users access the enterprise network 410).
Per claim 20 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Chanak ‘965 discloses: The method of claim 13, further comprising storing tunnel components, authentication components, and authorization components for the cloud-based data plane on a cloud platform remote from the customer premises (FIG. 6, [0064], a Zero Trust Network Access (ZTNA) application utilizing the cloudbased system 100. For ZTNA, the cloud-based system 100 (a cloud platform) can dynamically create a connection through a secure tunnel (tunnel components) between an endpoint (e.g., users 102A, 102B) that are remote and an on-premises connector 400 that is either located in cloud file shares and applications 402 and/or in an enterprise network 410 (the customer premises, which is remote from the cloud platform, i.e., the cloud-based system 100 – see FIG. 6) that includes enterprise file shares and applications 404 ... The connector 400 inside the enterprise (on-premises) "dials out" and connects to the cloud-based system 100 as if too were an endpoint. This on-demand dial-out capability and tunneling (storing the tunnel components) authenticated traffic back to the enterprise is a key differentiator for ZTNA; FIG. 1, [0042], The cloud-based system 100 can also include a management system 120 (the cloud-based data plane) for tenant access to provide global policy and configuration ... further include connectivity to an Identity Provider (IDP) 122 (the cloud-based data plane) for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 (the cloud-based data plane) for event logging; FIG. 2, [0048], The central authority 152 hosts all customer (tenant) policy and configuration settings (storing authentication components, and authorization components for the cloud-based data plane) ... for software and database updates and threat intelligence; [0049], The policy can be tenant-specific and can include access privileges for users, websites and/or content that is disallowed, restricted domains, DLP dictionaries, etc.).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 and Hardt ‘430.
Per claim 14 (dependent on claim 13):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 6 and the claim(s) is/are rejected for the reasons detailed with respect to claim 6.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 and Agaon ‘602.
Per claim 16 (dependent on claim 15):
Chanak ‘965 in view of KUPPANNAN ‘178 and Koikara ‘915 discloses the elements detailed in the rejection of claim 15 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 7 and the claim(s) is/are rejected for the reasons detailed with respect to claim 7.
Allowable Subject Matter
Claim(s) 1-3 is/are allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 1, the prior art of record (Chanak ‘965 in view of Li et al., US-20140280809-A1 (hereinafter “Li ‘809”)) does not disclose: “a threat management facility configured to:
...
remotely manage the network component on the customer premises through a secure connection, and
...
a connector, wherein:
the connector is deployed as a binary executing on the network component,
the threat management facility associates the connector with the network component,
the threat management facility provides management of the connector to the user through the web based user interface of the threat management facility,
the connector is configured to communicate with the data plane through a secure tunnel created using the tunnel components of the cloud platform” in the recited context.
Rather, Chanak ‘965 discloses that a zero trust network access (ZTNA) system in which a cloud-based system dynamically establishes secure, on-demand tunnels between remote endpoints and on-premises connectors. The connector is positioned within an enterprise environment and initiates outbound connections to the cloud-based system without requiring modifications to an existing firewall. The cloud-based system orchestrates authenticated traffic through the secure tunnel back to the enterprise on a per-user and per-application basis. Access is controlled by centralized policy provided by a central authority, such that only authorized applications are visible to a user. The central authority (threat management facility) in this reference is not directed to “remotely managing a network component,” but is instead limited to pushing policy. Moreover, it fails to clearly describe how the connector is associated with “the network component and the data plane.”
To this, Li ‘809 adds a remote management system for a network switch (network component) in which features and network properties of the switch are configured and controlled remotely through a firewall security system (threat management facility) acting as a gateway or controller. Remote management is performed via a command line interface (CLI), a graphical user interface (GUI), or both. The GUI provides a graphical interface allowing users to configure and manage the switch through visual elements. In one implementation the GUI is web-based and accessed via HTTP or HTTPS to remotely manage the switch. This prior art expressly teaches “remotely manage the network component” via the firewall security system; however, the prior art does not disclose a “connector”. As a result, it fails to address any relationship between such a connector and other entities, such as a “threat management facility” or “a data plane.”
Dependent claims 2-3 are allowed in view of their respective dependence from claims.
Claim(s) 8 and 12 is/are 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights