DETAILED ACTION
This action is in response to communication filed on 4/30/2025.
Claims 1-20 are pending.
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 6/5/2025, 8/22/2025, 2/20/2026, 5/12/2026 are 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 § 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, 10, and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 12 recite testing or validating the first instance of the service proxy “for proper operation,” and claim 1 further recites acting “in response to confirming proper operation.” The claims do not set out what conditions, tests, or results constitute “proper operation.” The specification gives examples, such as the instance executing and responding to a request for the application, but those examples are not in the claims. A person of ordinary skill in the art would not be informed, with reasonable certainty, of the scope of “proper operation.” See MPEP § 2173.05(g). Claims 2–11 and 13–20 are rejected for the same reason insofar as they depend from claims 1 and 12.
Claim 10 recites “wherein configuring the service proxy includes providing the configuration information through a user interface….” Claim 1, from which claim 10 depends, does not recite “configuring the service proxy.” Claim 1 recites “providing configuration information for a service proxy.” There is no antecedent basis for “configuring the service proxy.” See MPEP § 2173.05(e).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 12,316,608. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are directed to the same process of launching a sandbox instance of a service proxy that already has validated configuration for other applications, loading new application configuration into that instance, testing the instance, and then loading the new configuration into a second, production instance of the service proxy on a cloud platform.
Instant claim 1 is a computer program product reciting that process. Parent claims 1 and 12 already recite that process, including loading validated configuration for other applications into the sandbox instance and promoting the new configuration to a second instance executing on a cloud computing platform coupled to a public network. Instant claim 1 differs only by omitting “zero trust network access,” the fully qualified domain name, the digitally signed certificate, and the specific test conditions of parent claim 1, and by expressly requiring that the second instance have the validated configuration for the other applications. Those differences are obvious. A person of ordinary skill would retain the already-validated configurations on the production instance after promotion, and would not regard generic “access” as patentably distinct from the patented zero trust network access embodiment.
Instant claim 12 recites the same process as a method using a “cloud based data plane” and validation “in response to a request for the application.” Parent claim 1 already requires testing that the sandbox instance correctly responds to a request for the application, and already deploys the configuration to a second instance on the cloud platform coupled to a public network. The “cloud based data plane” is an obvious restatement of that production service-proxy plane.
Instant claims 2–11 and 13–20 recite edge proxy, load balancer, ZTNA application, tunnel, reverse proxy, key material, different tenant, requesting configuration, threat-management-facility user interface, FQDN, certificate, ZTNA appliance, and cloud enterprise facility. Each of those limitations is recited in, or is an obvious variant of, parent claims 2–11 and 13–20.
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 of this title, 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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jones et al. (US 2019/019616) in view of Chanak et al. (US 2020/0195614).
Regarding claim 1, Jones discloses a computer program product comprising computer executable code embodied in one or more computing devices that, when executing on one or more computing devices, causes the one or more computing devices to perform the steps of:
providing configuration information for a service proxy to provide access to an application executing on a customer premises (Jones’s CDN server is the service proxy. The origin behind the firewall is the application on customer premises. The desired test configuration is the provided configuration information; [0022]: “when CDN servers need to contact the content provider origin (e.g., a test origin site), they send their messages to a connector application run behind the firewall”, [0100]: “The user will register two inputs, their test origin and desired test configuration”);
launching a first instance of the service proxy in a sandbox environment (Jones teaches standing up / using a CDN server instance in a sandbox/staging environment, isolated from production traffic; [0039]: “To set up a test environment, the user accesses the UI 202 to obtain a unique sandbox identifier”, [0077] “the CDN server 220 determines whether it is capable of serving a sandbox request, e.g., is it in the staging network”);
loading the configuration information for the application into the first instance of the service proxy (Jones teaches exercising the sandbox CDN server, with the test configuration applied, by issuing a request for the application, and applying the loaded configuration to that request; [0076] “If the request is a sandbox request, the CDN Server 220 obtains and loads the test configuration”);
testing the first instance of the service proxy loaded with the configuration information for proper operation in the sandbox environment (Jones teaches exercising the sandbox CDN server, with the test configuration applied, by issuing a request for the application, and applying the loaded configuration to that request; [0040] “a test client 210 (e.g. a web browser) issues a request for content (e.g., an HTTP ‘Get’) to a test hostname”, [0043] “it obtains and applies a test configuration from repository 222, using the sandbox identifier as a key. It obtains and applies the test configuration rather than matching on the hostname in the HTTP ‘Get’ request and applying a production configuration, which would otherwise occur”); and
in response to confirming proper operation of the first instance of the service proxy in the sandbox environment, when loaded with the configuration information for the application, loading the configuration information for the application into a second instance of the service proxy (Jones teaches that after the test configuration is in the repository and used on the sandbox/staging path, configurations are distributed to CDN servers, including production servers that already load production configuration for live traffic. Staging is expressly for incremental rollout into the production network; [0043] “The CDN server may be a server in a production network in the CDN that is handling actual live production traffic”, [0076] “if the request is a production request, the CDN server 220 obtains and loads the production configuration”, [0115] “Once the test configuration is defined and stored in the CDN’s repository 222, they must be deployed to CDN servers”).
However, the prior art does not explicitly disclose the following:
the first instance of the service proxy loaded with validated configuration information for one or more other applications;
the second instance executing on a cloud computing platform and the second instance having the validated configuration information for the one or more other applications.
Chanak in the field of the same endeavor discloses techniques for the multi-tenant cloud service-proxy used to reach private applications on customer premises. In particular, Chanak teaches the following:
the first instance of the service proxy loaded with validated configuration information for one or more other applications (Chanak teaches a multi-tenant security cloud whose nodes stitch a user on the public Internet to private applications on the enterprise (customer premises) through lightweight connectors and secure tunnels. Those cloud nodes are the service proxy / data plane; [0055] “the private applications 608 are available on an enterprise’s network, but not available remotely except conventionally via VPN access”, [0059]: “The lightweight connectors 712 sit in front of the applications. The lightweight connectors 712 become the path to the file shares and applications 706, 708 behind it, and connect only to the security cloud 602. The lightweight connectors 712 can be lightweight, ephemeral binary, such as deployed as a virtual machine, to establish a connection between the file shares and applications 706, 708 and the security cloud 602, such as via the closest cloud node 102”); and
the second instance executing on a cloud computing platform and the second instance having the validated configuration information for the one or more other applications (Chanak teaches the security cloud is multi-tenant and policy for many customers’ private application is pushed onto the same cloud nodes. Those nodes therefore already hold configuration for other applications; [0060] “Policy is established and pushed by policy engines in the central authority 710, such as via a distributed cluster of multi-tenant policy engines that provide a single interface for all policy creation. Also, no data of any kind transits the policy engines. The cloud nodes 102 in the security cloud stitch connections together, between the users 702 and the file shares and applications 706, 708, without processing traffic of any kind. When the user 702 requests an application in the file shares and applications 706, 708, the policy engine delivers connection information to the application 704 and app-side cloud nodes 102 which includes the location of a single cloud nodes 102 to provision the client/app connection”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Chanak. One would have been motivated to apply Jones’s sandbox-validate-then-promote method to Chanak’s multi-tenant cloud nodes for the reason Jones itself gives: keep the shared production plane stable when a new application configuration is added ([0002], [0045]). The result is predictable: a sandbox instance of the Chanak cloud service proxy is launched, loaded with the new application configuration, tested, and then the configuration is loaded onto the live multi-tenant cloud instances.
Regarding claim 2, Jones-Chanak discloses the computer program product of claim 1, wherein the service proxy includes an edge proxy positioned on an edge of the cloud computing platform coupled to a public network (Chanak teaches cloud nodes at the edge of the cloud platform, coupled to the public internet, that proxy access to the on-premises application; [0059] “connect only to the security cloud 602. The lightweight connectors 712 can be lightweight, ephemeral binary, such as deployed as a virtual machine, to establish a connection between the file shares and applications 706, 708 and the security cloud 602, such as via the closest cloud node 102”).
Regarding claim 3, Jones-Chanak discloses the computer program product of claim 2, wherein the second instance of the service proxy is coupled to the public network through a network load balancer (Chanak teaches that public internet traffic is steered to one of a geographically distributed set of cloud nodes, the second instance of the service proxy. That steering function is the network load balancer; [0032] “Also, the cloud system 100 enables multiple enforcement points, centralized provisioning and logging, automatic traffic routing to a nearest cloud node 102, geographical distribution of the cloud nodes 102, policy shadowing of users which is dynamically available at the cloud nodes, etc”).
Regarding claim 4, Jones-Chanak discloses the computer program product of claim 1, wherein the application includes a zero trust network access application hosted on the customer premises (Chanak teaches a private application on the enterprise (customer premises) accessed through the cloud and an on premises connector, i.ei., a ZTNA application; [0055] “The private applications 608 include applications dealing with financial data, personal data, medical data, intellectual property, records, etc., that is the private applications 608 are available on an enterprise's network, but not available remotely except conventionally via VPN access”, [0059] “the lightweight connectors 712 sit in front of the applications. The lightweight connectors 712 become the path to the file shares and applications 706, 708 behind it, and connect only to the security cloud 602”).
Regarding claim 5, Jones-Chanak discloses the computer program product of claim 4, wherein the second instance of the service proxy executing on the cloud computing platform is coupled to the zero trust network access application hosted on the customer premises through a secure tunnel between the cloud computing platform and the customer premises (Chanak’s cloud node (second instance of the service proxy) reaches the private application on the enterprise through a connector over a secure tunnel; [0059] “the lightweight connectors 712 sit in front of the applications. The lightweight connectors 712 become the path to the file shares and applications 706, 708 behind it, and connect only to the security cloud 602. The lightweight connectors 712 can be lightweight, ephemeral binary, such as deployed as a virtual machine, to establish a connection between the file shares and applications 706, 708 and the security cloud 602, such as via the closest cloud node 102”).
Regarding claim 6, Jones-Chanak discloses the computer program product of claim 4, wherein the second instance of the service proxy is coupled to the zero trust network access application through a reverse proxy server executing on the cloud computing platform (Chanak places a VPN/proxy device in the cloud system. The client hits that cloud device and the cloud device is couple through the private/enterprise application; [0044] “Instead of the client 410 creating a secure connection through the firewall 412, the client 410 connects securely to a VPN device 420 located in the cloud system 100 through a secure connection 422. Note, the cloud system 100 can include a plurality of VPN devices 420. The VPN architecture 400 dynamically routes traffic between the client 410 and the Internet 104, the SaaS/public cloud systems 402, and securely with the enterprise 404. For secure access to the enterprise 404, the VPN architecture 400 includes dynamically creating connections through secure tunnels between three entities: the VPN device 420, the cloud, and an on-premises redirection proxy 430”).
Regarding claim 7, Jones-Chanak discloses the computer program product of claim 1, wherein the configuration information for the application includes key material to authenticate a user for access to the application (Jones teaches the configuration provided for the sandbox/application includes an access toke (JWT) and an associated public key used to authenticate the requester before the proxy applies the configuration and serves the application; [0095] “To be able to validate a JWT a given CDN server 220 must have the public key for the sandbox with which the JWT is associated. One way to do this is for the UI 202 or associated components to create a mapping of sandbox identifier to public key (“public key record”), which the CDN server 220 can retrieve on-demand. Hence, to process a JWT, a CDN server 220 would load the public key record, validate the JWT, and then load the test configuration identified by the sandbox identifier in the JWT. Local caching of the public key record and/or test configuration can be utilized”).
Regarding claim 8, Jones-Chanak discloses the computer program product of claim 1, wherein the one or more other applications include at least one application hosted by a different tenant of the cloud computing platform (Chanak’s security cloud is multi-tenant and serves private applications of multiple customers on the same cloud platform. Applications of those other customers are applications hosted by a different tenant; [0054] “Further, an advantage of the security cloud 602 is multi-tenant, enabling zero-hour detection of threats, and the like”, [0060] “Policy is established and pushed by policy engines in the central authority 710, such as via a distributed cluster of multi-tenant policy engines that provide a single interface for all policy creation”).
Regarding claim 9, Jones-Chanak discloses the computer program product of claim 1, wherein testing the first instance of the service proxy for proper operation includes requesting the configuration information for the application from the first instance of the service proxy (Jones teaches as part of testing the sandbox CDN server, that server requests and retrieves the application’s test configuration and applies it to the test request; [0062] “The sandbox_id is used as the basis for a key to look up the proper test configuration in the repository 222. Using this information, the CDN server 220 retrieves and caches the test configuration”).
Regarding claim 10, Jones-Chanak discloses the computer program product of claim 1, wherein configuring the service proxy includes providing the configuration information through a user interface of a threat management facility that hosts a control plane for managing zero trust network access to the application (Jones teaches providing the configuration information through a user interface; [0038] “The user has access to a CDN user interface (UI) 202 from which the user (e.g., a developer working for the content provider) can download a connector application 208 for installation on their workstation or other computer of their choosing, and from which the user can provision the test environment”, [0039] “After obtaining the token, the user creates and associates a test configuration for the CDN (e.g., a file with metadata, as described earlier) with the sandbox identifier”).
Regarding claim 11, Jones-Chanak discloses the computer program product of claim 1, wherein the customer premises includes a cloud enterprise facility (Chanak teaches the public-cloud location of the application resource is a cloud enterprise facility used as the customer premises; [0072] “wherein the resources are located in one of a public cloud and an enterprise network”).
Regarding claim 12, Jones discloses a method comprising:
launching a first instance of a service proxy in a sandbox environment (Jones [0039] “To set up a test environment, the user accesses the UI 202 to obtain a unique sandbox identifier”, [0077] “the CDN server 220 determines whether it is capable of serving a sandbox request, e.g., is it in the staging network and capable of serving staging traffic”),
updating the first instance with configuration information for the service proxy to provide access to an application (Jones [0076] “If the request is a sandbox request, the CDN Server 220 obtains and loads the test configuration”);
validating the first instance of the service proxy, as updated with the configuration information, in the sandbox environment for proper operation in response to a request for the application (Jones [0040] “During a test, a client test tool, referred to as a test client 210 (e.g. a web browser) issues a request for content (e.g., an HTTP ‘Get’) to a test hostname”, [0043] “The CDN server 220 receives the content request and recognizes the presence of the sandbox identifier. In response to the presence of the token and/or other factors) it obtains and applies a test configuration from repository 222”); and
in response to validating the first instance of the service proxy, loading the configuration information for the application into a second instance of the service proxy, the second instance of the service proxy having the previously validated configuration(Jones production CDN server is the second instance and the production configuration is the previously validated configuration; [0076] “if the request is a production request, the CDN server 220 obtains and loads the production configuration”, [0115] “Once the test configuration is defined and stored in the CDN's repository 222, they must be deployed to CDN servers”).
However, the prior art does not explicitly disclose the following:
the first instance of the service proxy having a previously validated configuration for accessing resources through a cloud based data plane;
to provide access to an application through the cloud based data plane; and
the second instance of the service proxy executing in the cloud based data plane on a cloud computing platform coupled to a public network.
Chanak in the field of the same endeavor discloses techniques for the multi-tenant cloud service-proxy used to reach private applications on customer premises. In particular, Chanak teaches the following:
the first instance of the service proxy having a previously validated configuration for accessing resources through a cloud based data plane (Chanak puts that path on cloud nodes 102 inside security cloud 602 /cloud system 100, which sit on the internet and stich the user to the application; [0031] “The cloud system 100 includes one or more cloud nodes (CN) 102 communicatively coupled to the Internet 104”, [0060] “The cloud nodes 102 in the security cloud stitch connections together, between the users 702 and the file shares and applications 706, 708”);
to provide access to an application through the cloud based data plane (Chanak puts that path on cloud nodes 102 inside security cloud 602 /cloud system 100, which sit on the internet and stich the user to the application; [0031] “The cloud system 100 includes one or more cloud nodes (CN) 102 communicatively coupled to the Internet 104”, [0060] “The cloud nodes 102 in the security cloud stitch connections together, between the users 702 and the file shares and applications 706, 708”); and
the second instance of the service proxy executing in the cloud based data plane on a cloud computing platform coupled to a public network (Chanak [0060] “Policy is established and pushed by policy engines in the central authority 710, such as via a distributed cluster of multi-tenant policy engines that provide a single interface for all policy creation. Also, no data of any kind transits the policy engines. The cloud nodes 102 in the security cloud stitch connections together, between the users 702 and the file shares and applications 706, 708, without processing traffic of any kind. When the user 702 requests an application in the file shares and applications 706, 708, the policy engine delivers connection information to the application 704 and app-side cloud nodes 102 which includes the location of a single cloud nodes 102 to provision the client/app connection”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Chanak. One would have been motivated to apply Jones’s sandbox-validate-then-promote method to Chanak’s multi-tenant cloud nodes for the reason Jones itself gives: keep the shared production plane stable when a new application configuration is added ([0002], [0045]). The result is predictable: a sandbox instance of the Chanak cloud service proxy is launched, loaded with the new application configuration, tested, and then the configuration is loaded onto the live multi-tenant cloud instances.
Regarding claim 13, Jones-Chanak discloses the method of claim 12, wherein the configuration information includes a fully qualified domain name for the application (Jone’s test configuration is used with a hostname that identifies the application under test. A hostname in the form used by Jones (e.g., dev.xyz.com) is a fully qualified domain name for the application; [0062] “Conventionally, the CDN server 220 would examine the hostname in the test client's HTTP Get request (i.e., dev.xyz.com) and look up this hostname in an index to find a matching configuration file to apply”).
Regarding claim 14, Jones-Chanak discloses the method of claim 12, wherein the configuration information includes a fully qualified domain name (Jones teaches configuration information that includes a fully qualified domain name used to reach the application through the connectors; [0040] “During a test, a client test tool, referred to as a test client 210 (e.g. a web browser) issues a request for content (e.g., an HTTP ‘Get’) to a test hostname”) .
The prior art does not explicitly disclose a fully qualified domain name for a zero trust network access appliance that provides access to the application.
Chanak in the field of the same endeavor discloses techniques for the multi-tenant cloud service-proxy used to reach private applications on customer premises. In particular, Chanak teaches the following:
a fully qualified domain name for a zero trust network access appliance that provides access to the application (Chanak’s lightweight connector is the applicant that provides access to the application; [0059] “the lightweight connectors 712 sit in front of the applications. The lightweight connectors 712 become the path to the file shares and applications 706, 708 behind it, and connect only to the security cloud 602”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine Jones’s hostname in configuration with Chanak’s connector yields an FQDN in the configuration for that appliance. One would have been motivated to include the appliance FQDN in that configuration so the could data plane can reach the correct connector.
Regarding claim 15, Jones-Chanak discloses the method of claim 12, wherein the configuration information includes a digital certificate for the application (Chanak [0072] “wherein the one or more cloud nodes create the secure tunnels based on a combination of a client-side certificate and a server-side certificate”).
Regarding claim 16, Jones-Chanak discloses the method of claim 12, wherein the configuration information includes key material for authenticating the application (Jones associates a public key with the test configuration and loads that public key record with the configuration so the proxy can authenticate the request for the application; [0039] “After obtaining the token, the user creates and associates a test configuration for the CDN (e.g., a file with metadata, as described earlier) with the sandbox identifier”).
Regarding claim 19, Jones-Chanak discloses the method of claim 12, wherein the second instance of the service proxy is coupled to a zero trust network access appliance hosted with the application on a customer premises (Chanak teaches a lightweight connector hosted with the private application on the enterprise and coupled to the cloud node (second instance of the service proxy); [0059] “the lightweight connectors 712 sit in front of the applications. The lightweight connectors 712 become the path to the file shares and applications 706, 708 behind it, and connect only to the security cloud 602. The lightweight connectors 712 can be lightweight, ephemeral binary, such as deployed as a virtual machine, to establish a connection between the file shares and applications 706, 708 and the security cloud 602, such as via the closest cloud node 102”).
Regarding claim(s) 17, 18, and 20, do(es) not teach or further define over the limitation in claim(s) 4, 2, and 11 respectively. Therefore claim(s) 17, 18, and 20 is/are rejected for the same rationale of rejection as set forth in claim(s) 4, 2, and 11 respectively.
Conclusion
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights