DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1-20
The following claim(s) is/are amended: 1, 10, 19
The following claim(s) is/are cancelled: -
The following claim(s) is/are new: -
Claim(s) 1-20 is/are rejected.
Response to Arguments
Applicant’s arguments filed in the amendment filed 3/12/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - 35 USC § 103
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.
Claims 1-3, 5-8, 10-12, and 14-17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Parla (US Pub. 2018/0309658) in view of Agarwal (US Pub. 2014/0157358) and further in view of Jeganathan (US Pub. 2018/0351864).
With respect to Claim 1, Parla teaches a method for establishing a Secure Sockets Layer (SSL) Virtual Private Network (VPN) tunnel route, the method comprising: receiving a connection request from a client associated with a fully qualified domain name (FQDN) to use a SSLVPN tunnel service; (A SSLVPN will be taught later. paras. 21-22, 35; client sends a DNS request for docs.example.com. docs.example.com is a FQDN. The request may be made outside of the VPN tunnel. Although Parla discloses the tunnel being set up first, it would have been obvious to one of ordinary skill prior to the effective filing date to have the request precede the tunnelling in order to perform tunneling consistent with policy, session characteristics and the client configuration. See also Agarwal, para. 122; policy for establishing a SSL VPN session, which means the session is only established after the configuration data is received. Para. 138; session characteristics for the connection based on client-specific policy.)
constructing a client configuration file based on the data associated with the client; (para. 21; Tunnelling policy – always tunnel except for host names *.example.com - is sent to client. Paras. 33-34; policy that tunnelling is not performed by default and only specific FQDNs are tunneled. To the extent that configuration file may suggest more than just addressing or routing data, see Agarwal, para. 138; session characteristics for the connection based on client-specific policy.)
resolving the FQDN associated with the client to at least one internet protocol (IP) address; (paras. 14, 20, 22, 35; DNS server translates FQDN into IP address 1.2.3.4)
storing the resolved IP address in the configuration file; and communicating the configuration file to the client to instruct the client regarding how to establish an SSL VPN tunnel route for the at least one resolved IP address. (Establishing will be taught later. paras. 23-26, 35-39; the client receives the IP address and uses the previously stored policy to control the routing and tunnelling of the connection based upon the policy. The client then connects to the requested resources using or not using a tunnel based on the policy configuration.)
But Parla does not explicitly teach SSL VPN.
Agarwal, however, does teach a Secure Sockets Layer (SSL) Virtual Private Network (VPN) tunnel (paras. 88, 94-97; SSL VPN tunneling.)
wherein the connection request include at least one protocol followed by the client; (paras. 96-97; clientless sessions may use the protocols available to the client’s browser or application. para. 122; session policy establishes session characteristics that include encoding schemes or specific communication protocols to be used.)
referencing a data storage for data associated with the client; (paras. 120-122, 137-138; when client uses SSL VPN to connect to a server the system will look up session policy that is based on the client in order to identify rules for the connection. Session policy may establish different session characteristics for one client rather than another.)
in the configuration file before establishing an SSL VPN tunnel; establish an SSL VPN tunnel route; enabling the client to establish one or more SSL VPN tunnel routes based on the configuration file. (Parla establishes a tunnel earlier for other reasons, and then uses the established tunnel to reach the IP address when the policy is to communicate through a tunnel. Therefore, Parla does not anticipate establishing a tunnel, rather than using an existing tunnel, based on a configuration file. However, Agarwal teaches policy for establishing a VPN session, see para. 122; Session policy may be any type and form for establishing a session, including rules for establishing a SSL VPN session.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Parla with the SSL VPN in order to improve security and interoperability by using a known encryption protocol to secure a connection. (Agarwal, para. 70)
But modified Parla does not explicitly teach an internal route directive.
Jeganathan, however, does teach and an internal route that specifies an internal route directive. (para. 241-244; internal processing path that includes determinations of services to be applied or the next hop may be based on parameters that define the flow processing.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Parla with the internal route directive in order to apply services or filtering to the flow. (Jeganathan, para. 241)
With respect to Claim 2, modified Parla teaches the method of claim 1 and Parla also teaches further comprising: detecting a change in the resolution of the FQDN; notifying a configuration service of the detected change in the FQDN resolution; (para. 31; updating of policy. Also FQDNs may need to be re-resolved after a period of time to stay up to date.)
And Agarwal also teaches and disconnecting the client associated with the FQDN from the SSL VPN tunnel service. (para. 103; session poisoning. It would have been obvious to one of ordinary skill prior to the effective filing date to poison the session in order to effectuate the new session with the updated policy.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 3, modified Parla teaches the method of claim 2 and Parla also teaches further comprising receiving a second request from the client after disconnecting the client from the SSL VPN tunnel service, and using at least one parameter from the configuration file to re-establish an SSL VPN tunnel service connection with the client. (Duplication of parts is not a patentable act, see MPEP 2144. Regardless, Examiner will re-cite Parla, paras. 23-26, 35-39; the client receives the IP address and uses the previously stored policy to control the routing and tunnelling of the connection based upon the policy. The client then connects to the requested resources using or not using a tunnel based on the policy configuration.)
With respect to Claim 5, modified Parla teaches the method of claim 1 and Parla also teaches wherein the configuration file includes a plurality of resolved IP addresses so that the client can configure an SSL VPN tunnel route for each of the at least one resolved IP addresses. (paras. 5, 20, 31, 58-59; tunneling to a plurality of addresses and resolving a plurality of addresses.)
With respect to Claim 6, modified Parla teaches the method of claim 1 and Parla also teaches wherein the FQDN has a time-to-live value, and the method further includes re-establishing a connection with the client using the client configuration file based on expiration of the time-to-live value. (para. 31; FQDNs have to be re-resolved after a predetermined amount of time, which is a time-to-live value. Examiner asserts that “re-resolved” implies re-establishing a connection, but to the extent it does not it would have been obvious to one of ordinary skill prior to the effective filing date to require re-establishing during the re-resolving because the updated policy may be to change the tunnelling status of the connection. Duplication of parts is not a patentable act, see MPEP 2144.)
With respect to Claim 7, modified Parla teaches the method of claim 1 and Parla also teaches wherein the FQDN is a public domain, a private domain, or a wildcard value. (paras. 16, 20-22; wildcard names. See also Agarwal, para. 23; public and private networks.)
With respect to Claim 8, modified Parla teaches the method of claim 1 and Parla also teaches wherein a file system in user space generates the configuration file dynamically in response to receiving the request from the client. (A file system will be taught later. paras. 14, 22-26; automatic and dynamic routing is performed by applying policy in response to request from client for resources. Para. 21; server responds with split tunnelling policy.)
And Agarwal also teaches a file system in the user space (para. 35; CIFS for file delivery)
The same motivation to combine as the independent claim applies here.
With respect to Claim 10, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Agarwal also teaches one or more processors executing instructions stored on memory to provide: (paras. 58-59; processor and memory)
And from a file system (para. 35; CIFS for file delivery)
The same motivation to combine as Claim 1 applies here.
With respect to Claims 11-12, 14-17, they are substantially similar to Claims 2-3, 5-8, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 19, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Parla also teaches a computer program product for establishing a Secure Sockets Layer (SSL) Virtual Private Network (VPN) tunnel route, the computer program product comprising computer executable code embodied in one or more non-transitory computer readable media that, when executing on one or more processors, performs the steps of: (para. 63; non-transitory computer readable media with instructions for execution by a processor)
With respect to Claim 20, it is substantially similar to Claim 2 and is rejected in the same manner, the same art and reasoning applying.
Claims 4 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Parla (US Pub. 2018/0309658) in view of Agarwal (US Pub. 2014/0157358), in view of Jeganathan (US Pub. 2018/0351864), and further in view of Harris (US Pub. 2018/0332064).
With respect to Claim 4, modified Parla teaches the method of claim 1 but does not explicitly teach a single threaded process that is separate from a main processing thread.
Harris, however, does teach further comprising requesting an FQDN service to resolve the FQDN to the at least one IP address using a single threaded process that is separate from a main processing thread. (paras. 102-103, 110-111; portion of application may run its own single thread separate from the main thread to process queries.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Parla with the single threaded process in order to allow for each query to be resolved in its own single thread to allow for parallel processing.
With respect to Claim 13, it is substantially similar to Claim 4 and is rejected in the same manner, the same art and reasoning applying.
Claims 9 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Parla (US Pub. 2018/0309658) in view of Agarwal (US Pub. 2014/0157358), in view of Jeganathan (US Pub. 2018/0351864), and further in view of Rykowski (US Pub. 2018/0349152).
With respect to Claim 9, modified Parla teaches the method of claim 1 but does not explicitly teach wherein the connection request includes a network allowed in the SSL VPN tunnel.
Rykowski, however, does teach wherein the connection request includes a network allowed in the SSL VPN tunnel. (para. 92; VPN settings include allowed networks.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Parla with the allowed networks in order to restrict the VPN tunnel to secure networks.
With respect to Claim 18, it is substantially similar to Claim 9 and is rejected in the same manner, the same art and reasoning applying.
Remarks
Applicant amends Claim 1 to include storing the IP address in a configuration file before establishing the VPN tunnel and then establishing the VPN tunnel based on the configuration file. Applicant argues at Remarks, pgs. 1-3 that establishing a VPN tunnel based on configuration data makes the claims nonobvious. Specifically, Applicant argues that “Parla discloses the provisioning of split tunneling ‘after the VPN tunnel was established.’” Applicant appears to agree, or at least not dispute, that Agarwal discloses establishing a SSL VPN session pursuant to policy, i.e. receiving a configuration before the tunnel is provisioned or established. But, Applicant argues, there is no motivation to shift from Parla’s post-establishment configuration to Agarwal’s pre-establishment configuration because that would be a change in the principle of operation of Parla.
Examiner disagrees because this is not a principle of operation change. Applicant identifies the principle of operation that is changing as one in which a VPN server “responds with a message which includes the split tunnelling policy” to one in which “an intermediary may determine, responsive to an encoding policy, an encoding scheme from a plurality of encoding schemes.” Assuming arguendo this is an appropriate description of the modification to be made, Applicant presents no evidence that this is a principle of operation. The cited In re Ratti case which Applicant relies upon for the principle of operation argument (see MPEP 2143.01(VI) and Remarks, pg. 2) discusses a claim element that required resiliency and a primary rejecting reference that required rigidity. The court reversed on the logic that the “suggested combination of references would require a substantial reconstruction and redesign of the elements.” Specifically, the Court noted that “[t]he problems which were solved by appellant’s invention existed in this art at the time of his invention despite the [primary reference’s] disclosures.” It further noted that working with the materials in the rejecting reference would create problems – “It is common knowledge that resilient deformable materials such as either natural or synthetic rubber are incompressible…[c]onsidering the incompressible nature of the rubber in the sealing element disclosed in [the reference]…it seems clear to us that [the reference’s] seal cannot function in the manner of appellant’s seal.”
The instant situation is in stark contrast. All of the instant specification, the Parla reference and the Agarwal reference disclose the same technique of tunnelling. Neither the specification nor the references suggest that a principle of operation of tunnels is that they must be established before configuration parameters are received. Applicant does not point to anywhere in the instant Specification which identifies such an issue and provides a technical teaching for overcoming it. Therefore there is no record evidence that Parla is “a substantial reconstruction” away from reaching the claims – at most it is a timing distinction as to when the tunnel is established. Rather than this being a substantial reconstruction, the Specification appears to rely upon the conventional knowledge and skill in the art to enable the use of a configuration file to establish a VPN tunnel. And contra to Ratti, is this not a situation where the specification is designed to solve exactly the disparity presented by the argument – The instant invention addresses the problem that “[e]xisting SSL VPN implementations, however, does not support fully qualified domain name (FQDN) hosts in networks” (Spec, para. 4) and the solution is designed to “support FQDN hosts with SSL VPN tunneling.” (para. 5) The timing of the establishment of the tunnel vis-à-vis configuration was not in the original claims and was only added in response to Examiner citing Parla and seeking to modify it with Agarwal. With respect to Agarwal, it expressly identifies that the same element Parla uses – a VPN tunnel – can be established pursuant to policy configurations.
Therefore, the better reading of the record is that a person of ordinary skill in the art knew prior to filing that tunnels could be established pursuant to policy (Agarwal) or modified by policy when already in use (Parla). The fact that Parla proceeded according to the latter known technique rather than the former merely means Parla is nonanticipatory, not that a change in principle of operation has taken place. The modification being discussed is using the same thing (a tunnel) in a slightly different way (an established static setup via configuration files rather than a dynamic modification), according to known techniques. If that constituted a principle of operation change virtually all modifications would be principle of operation changes and 103 would be written out of the statutory scheme.
Applicant appears to acknowledge that Examiner would cite Agarwal to teach the amended limitations. Applicant does not dispute the Agarwal teaching itself, and only argues that there is no motivation to establish a tunnel with a policy because it is a change in principle of operation. The motivation argument is unpersuasive for the reasons above, so Examiner cites Agarwal and maintains the rejection.
Examiner further opines for the record to compact prosecution. Applicant’s principle of operation argument does not cite to the instant specification disclosures or extrinsic evidence and only cites to Agarwal for a description of what the modification is. Applicant’s argument centers entirely around disclosures in Parla, which makes it a poor fit for a principle of operation complaint that logically commends itself to external evidence. Examiner thinks Applicant’s evidentiary complaint truly sounds in a “teaches away” rationale for nonobviousness (MPEP 2145) rather than “principle of operation,” (2143.01) because the thrust of Applicant’s citations is that Parla proceeds differently and it was important to Parla have a preestablished tunnel. See Remarks, pg. 2; “The Office Action alleges it would have been obvious to ‘have the request precede the tunneling in order to not set up the tunnel if the request did not call for it.’ However, this is contrary to the core teaching of Parla[].” Examiner sua sponte raises teaches away and expressly considers it for the record.
Parla does not teach away because the nature of the teaching is highly relevant and the totality of the prior art must be considered. (MPEP 2145(X)(D)) Examiner acknowledges that Parla proceeds in an unconventional manner – the utility expressed in Parla is the dynamic nature of the usage of the tunnel, and consequently to evidence the utility in the system’s “dynamic” nature Parla establishes a tunnel and then makes modifications around the usage of the tunnel. See, e.g., Parla, para. 44. That is contrary to the conventional act described in Agarwal and expressed in the claims of getting configuration data first and using that to establish the connection. Examiner even ultimately agrees with what Examiner views as the thrust of Applicant’s citations – Examiner agrees that a person of ordinary skill would think that Parla finds pre-establishing the tunnel to be important to Parla’s invention. But what Parla thinks about Parla’s invention simply isn’t the focus of the question of a motivation to make a modification. The question is what would a person of ordinary skill in the art be motivated to create after the entirety of the teachings. Parla never suggests that one could not (i.e. one was not enabled to or it would not work to) set configuration policy prior to establishing the tunnel, and a person of ordinary skill reading Parla would recognize that Parla is disclosing the additional robustness of dynamic modification. Applicant correctly recognizes that Parla never considers the establishing based on a configuration file. Consequently, Parla never teaches away from it. Conversely, Agarwal proceeds entirely in keeping with the claims vis-à-vis establishing a tunnel based on configuration policy. A person of ordinary skill after reading both references would recognize that one could use a configuration file to establish a SSL VPN tunnel because that is precisely what Agarwal does. That act does not become nonobvious merely because a reference which teaches an unrelated or tangentially-related feature (FQDN with tunnels) establishes a tunnel in a different manner.
All claims remain rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights