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 .
Response to Amendment
The amendment filed 12/29/2025 has been accepted and entered. Accordingly, claims 1, 3, 5, 12, 14, and 16 have been amended.
Claims 1-7, 11-18, and 20 are pending in this application.
The amendments have cured the 112a rejection of the previous Office Action, therefore that particular 112a rejection has been withdrawn.
Response to Arguments
Applicant’s arguments, filed 12/29/2025, with respect to the rejections of claims 1, 4, 6-7, 11-12, 15, 17-18, and 20 under 35 U.S.C. 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-7, 11-17, and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
According to the specification of the instant application at ¶0026, the first wireless connection is disclosed as being between the device and network server, and at ¶0029, the second wireless connection is disclosed as being between the device and the endpoint device. The amendments to claims 1 and 12 seem to have the opposite language, which has caused some confusion in interpreting the claim. Examiner is unsure if there may have been a mistake made by applicant while amending the claim, or if there was a deliberate reason for this switch. Due to this, examiner is interpreting the first and second wireless connections as they are disclosed in the specification, as in the first wireless connection is between device and network server and the second wireless connection is between the device and endpoint device.
Also, according to the specification of the instant application at ¶0033, it is disclosed that the first tunnel is established via the second wireless connection. The amended claim language at line 11 has changed this from being the second wireless connection to first wireless connection. This would be inconsistent with the disclosure, as the first wireless connection is between a device and a server and the first tunnel is established between a device and endpoint device. Appropriate correction is needed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 4-7, 11-12, 15-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Beesley et al. (US 2018/0048588 A1), hereinafter referred to as Beesley, in view of Branch (US 2020/0336409 A1), hereinafter referred to as Branch, and further in view of Eisenberg et al. (US 2003/0188001 A1), hereinafter referred to as Eisenberg, and further in view of Chitrapu (US 2018/0359658 A1), hereinafter referred to as Chitrapu.
Re. Claim 1, Beesley teaches:
A method comprising: obtaining, from a device, a request for a configuration file at a network server, (¶0047 At step 503, a request is sent to the VPN instantiation server for client configuration information [i.e. request for client configuration information (configuration file) sent to VPN instantiation server (network server)] usable to instantiate a VPN connection with a VPN endpoint server.)
the request including: user device addressing information to establish a first wireless connection between the device and a user device, (¶0034 The wireless network address of wireless VPN client 202 and the private network address of VPN instantiation server 214 may be included in FIG. 2 with client configuration information 218. & ¶0047 At step 503, a request is sent to the VPN instantiation server for client configuration information usable to instantiate a VPN connection with a VPN endpoint server. [i.e. request is for requesting client configuration information which includes address of wireless VPN client (user device), connection being between VPN client (user device) and VPN endpoint server (device); the first wireless connection being interpreted as what the spec has disclosed as the second wireless connection, which is between the device and user device])
the user device being selected by a user of the device; (¶0034 certain portions of client configuration information 218 may be pre-programmed in a memory card included with wireless VPN client 202, such as in a single-inline memory module (SIMM) card that registers wireless VPN client 202 with wireless network 204. [i.e. client configuration information is pre-programmed in memory through use of a SIMM card, which would be installed by a user of the device, therefore the device is selected by the user of the device through installation of a specific SIMM card])
after establishment of a second wireless connection over a wireless network between a device and a network server, (Fig. 2 & ¶0035 wireless VPN client 202 [i.e. a device] may make an initial connection with VPN instantiation server 214 [i.e. a network server])
providing a configuration file to the device from the network server, (Fig. 2 & ¶0050 The VPN client device may automatically connect to the VPN instantiation server to obtain client configuration information [i.e. configuration file from network server])
the configuration file configured to: direct the device to establish a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless network (Fig. 2 & ¶0035 Additionally, client configuration information 218 may include a private network address for VPN endpoint server 206… The client configuration information 218 [i.e. a configuration file] may accordingly include an authentication key usable to establish security tunnel 210 [i.e. configuration information/file 218 contains information for the device in order for it to establish a first security tunnel 210, shown in Fig. 2 as the first layer of a two tunnel scenario; The second wireless connection being the tunnel 210 or combination of tunnels 210 and 212 operating directly between the wireless VPN client 202 and the VPN endpoint server 206 shown in Fig. 2, the first wireless connection being interpreted as the wireless connection between the device and user device which is described in the specification of the application as second wireless connection])
the user device defined in the configuration file; (¶0035 server configuration information 220 may include the authentication key [i.e. a key in a configuration file/message being used to verify identity of user device; this being interpreted as a user device being defined by said key] usable to establish security tunnel 210)
and direct the device to establish a second tunnel within the first tunnel (fig. 2 & ¶0037 After receiving client configuration information 218 at wireless VPN client 202 and server configuration information 220 at VPN endpoint server 206, security tunnel 210 may first be instantiated between wireless VPN client 202 [i.e. the user device] and VPN endpoint server 206 [i.e. the device] using the authentication key provided previously. Security tunnel 210 may represent a network encapsulation protocol to provide an enhanced level of security to individual network packets, such as Internet-protocol security (IPSEC). Once security tunnel 210 is established, layer 2 tunnel 212 [i.e. second tunnel] may be established within security tunnel 210 using the tunnel identifier provided previously. Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided.)
and facilitating (fig. 2 & ¶0037 security tunnel 210 may first be instantiated between wireless VPN client 202 and VPN endpoint server 206 [i.e. first tunnel between the device and user device] …Once layer 2 tunnel 212 is operational, a session in the VPN connection providing layer 2 services, such as MEF services, between wireless VPN client 202 [i.e. the user device] at the first location and MAN 208 at the second location may be established via VPN endpoint server 206 [i.e. the second tunnel 212 is providing direct point-to-point communication between the user device and the device] using the session identifier provided previously)
Yet, Beesley fails to teach: a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless network directly between the device and a user device, and direct the device to establish a second tunnel within the first tunnel between the device and the user device; and facilitating direct communications between the device and the user device.
However, in the analogous art, Branch teaches such limitations:
a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless network directly between the device and a user device. (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0026 The VPN connection can be referred to as a VPN tunnel & ¶0026 Each one of the client devices 110A-N is a computing device (e.g., laptop, workstation, smartphone, palm top, mobile phone, tablets, gaming system, set-top box, etc.) [i.e. wireless operating devices within local area network] & ¶0034 At operation 4, the server 120 transmits, to the first client device 110A and through the first VPN connection, a second public network address of the second client device. At operation 5, the server 120 transmits, to the second client device 110B and through the second VPN connection, a first public network address of the first client device 110A. The transmission of the first public network address [i.e. part of a configuration message] and the second public network address causes the first client device 110A to determine an optimal route from the first client device 110A to the second client device 110B for the traffic in the VPN. For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 [i.e. a VPN tunnel between the two devices within a wireless local network as shown in Fig. 1] without going through the server 120.)
and direct the device to establish a second tunnel within the first tunnel between the device and the user device; (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0034 The transmission of the first public network address and the second public network address causes the first client device 110A to determine an optimal route from the first client device 110A to the second client device 110B for the traffic in the VPN. For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 [i.e. tunnel directly between device and user device])
and facilitating direct communications between the device and the user device. (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0034 For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 without going through the server 120 [i.e. tunnel with direct communication without intermediate between device and user device])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley’s invention of automated instantiation of wireless virtual private networks to include Branch’s teaching of a first tunnel established over a wireless network directly between the device and a user device, because it enables the device to determine an optimal route for VPN traffic between two devices without sending data through the VPN server. (see Branch ¶0023-¶0024)
Yet, the combined references fail to teach: the first tunnel and the second tunnel being established between the device and the user device without the user device receiving information from the network server regarding establishment of the first tunnel and the second tunnel;
However, in the analogous art, Eisenberg teaches such a limitation:
the first tunnel and the second tunnel being established between the device and the user device without the user device being pre-provisioned from the network server regarding establishment of the first tunnel and the second tunnel; (¶0144 tunnels may be created and maintained between TPs on servers 790, 795 and the TP 775 for desktop 770 through firewall 705. Additionally, tunnels may be created and maintained between TPs on servers 790, 795 and a TP 760 and/or TP 750 [i.e. first and second tunnel established between a device and user device] & ¶0147 for any configuration a TP install can take place on each endpoint and/or external server of a configuration to support tunneling without the requirement of a separate system gateway/proxy or user registration process. [i.e. tunnels being established without a gateway/proxy/server reads on the user device not being pre-provisioned from a network server regarding establishment of the tunnels])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley and Branch’s invention of automated instantiation of wireless virtual private networks to include Eisenberg’s teaching of the first and second tunnel being established without the user device receiving information, because it would allow the device to support tunneling without a requirement that a separate system server be used in the process to establish the tunnels, which lowers system overhead. (see Eisenberg ¶0147)
Yet, the combined references do not explicitly teach: and quality of service for the first wireless connection selected by the user of the device;
However, in the analogous art, Chitrapu teaches:
and quality of service for the first wireless connection selected by the user of the device; (¶0039 the user requests a communications service and selects a desired QoE at 500)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, and Eisenberg’s invention of automated instantiation of wireless virtual private networks to include Chitrapu’s teaching of quality of service for the wireless connection being selected by the user of the device, because it would enable dynamic QoS control through user control of QoE or parameters for network service. (see Chitrapu ¶0004)
Re. Claim 4, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
wherein the wireless network includes one or more cellular networks. (¶0031 It is noted that wireless network 204 may be a cellular network, such as LTE)
Re. Claim 5, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
wherein the configuration file includes authentication credentials for the device. (¶0036 The server configuration information 220 may include specific configuration information for VPN endpoint server 206, which is an individual server instance used to provide the VPN connection to wireless VPN client 202. Accordingly, server configuration information 220 may include the authentication key [i.e. authentication credentials for device in order to instantiate security tunnel 210] usable to establish security tunnel 210,)
Re. Claim 6, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
wherein the first tunnel is an internet protocol security (IPsec) tunnel, (Fig. 2 & ¶0037 Security tunnel 210 may represent a network encapsulation protocol to provide an enhanced level of security to individual network packets, such as Internet-protocol security (IPSEC).)
and the second tunnel is a layer 2 tunneling protocol (L2TP) tunnel, (Fig. 2 & ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided.)
the second tunnel configured to provide transparency between the device and the user device. (Fig. 2 & ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided. [i.e. Layer 2 tunnel 212 being depicted in Fig.2 as a transparent due to no intermediate nodes between the two devices being connected by the tunnel])
Re. Claim 7, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
wherein the first layer is an internet layer of an internet protocol suite, (Fig. 2 [depicts Security tunnel 210 as a first layer tunnel, implied by tunnel 212 within it being a layer 2 tunnel] & ¶0004 the security tunnel may be an Internet-protocol security tunnel.)
and the second layer is a link layer of the internet protocol suite. (¶0037 ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), [i.e. L2TP –operates at the link layer, otherwise known as Layer 2])
Re. Claim 11, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
wherein the communications between the device and the user device include internet protocol (IP) traffic and non-IP traffic. (¶0026 Network 100 may communicate information or “traffic” over transmission media 112… In particular embodiments, traffic may be communicated via a suitable communications protocol, including, without limitation, the Internet Protocol (IP). Additionally, the traffic communicated via network 100 may be structured in any appropriate manner including, but not limited to, being structured in frames, packets, or an unstructured bit stream. [i.e. unstructured bit stream is inherently non-(IP) traffic because it does not use IP header or follow IP protocol convention])
Re. Claim 12, Beesley teaches:
A system comprising: one or more computer-readable storage media configured to store instructions; (¶0044 In various embodiments, VPN instantiation server 214 may accordingly include, or have certain access to, processor 402, memory 411, and network interface 421. Processor 402 may represent one or more individual processing units and may execute program instructions, interpret data, process data stored by memory 412 or VPN instantiation server 214.)
And one or more processors communicatively coupled to the one or more computer-readable storage media and configured to, in response to execution of the instructions, cause the system to perform operations, (¶0044 In various embodiments, VPN instantiation server 214 may accordingly include, or have certain access to, processor 402, memory 411, and network interface 421. Processor 402 may represent one or more individual processing units and may execute program instructions, interpret data, process data stored by memory 412 or VPN instantiation server 214.)
the operations comprising: obtaining, from a device, a request for a configuration file at a network server, (¶0047 At step 503, a request is sent to the VPN instantiation server for client configuration information [i.e. request for client configuration information (configuration file) sent to VPN instantiation server (network server)] usable to instantiate a VPN connection with a VPN endpoint server.)
The request including: user device addressing information to establish a first wireless connection between the device and a user device, (¶0034 The wireless network address of wireless VPN client 202 and the private network address of VPN instantiation server 214 may be included in FIG. 2 with client configuration information 218. & ¶0047 At step 503, a request is sent to the VPN instantiation server for client configuration information usable to instantiate a VPN connection with a VPN endpoint server. [i.e. request is for requesting client configuration information which includes address of wireless VPN client (user device)])
the user device being selected by a user of the device; (¶0034 certain portions of client configuration information 218 may be pre-programmed in a memory card included with wireless VPN client 202, such as in a single-inline memory module (SIMM) card that registers wireless VPN client 202 with wireless network 204. [i.e. client configuration information is pre-programmed in memory through use of a SIMM card, which would be installed by a user of the device, therefore the device is selected by the user of the device through installation of a specific SIMM card])
after establishment of a second wireless connection over a wireless network between a device and a network server, (Fig. 2 & ¶0035 wireless VPN client 202 [i.e. a device] may make an initial connection with VPN instantiation server 214 [i.e. establishment of wireless connection between a device and a network server])
providing a configuration file to the device from the network server, (Fig. 2 & ¶0050 The VPN client device may automatically connect to the VPN instantiation server to obtain client configuration information [i.e. configuration file from network server])
the configuration file configured to: direct the device to establish a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless (Fig. 2 & ¶0036 The server configuration information 220 may include specific configuration information for VPN endpoint server 206, which is an individual server instance used to provide the VPN connection to wireless VPN client 202. Accordingly, server configuration information 220 may include the authentication key usable to establish security tunnel 210 [i.e. configuration information/file 220 contains information for the device in order for it to establish a first security tunnel 210, shown in Fig. 2 as the first layer of a nested tunnel scenario; The second wireless connection being the tunnel 210 or combination of tunnels 210 and 212 operating directly between the wireless VPN client 202 and the VPN endpoint server 206 shown in Fig. 2, first wireless connection being interpreted as the wireless connection between the device and user device which is described in the specification of the application as second wireless connection])
the user device defined in the configuration file; (¶0035 server configuration information 220 may include the authentication key [i.e. a key in a configuration file/message being used to verify identity of user device; this being interpreted as a user device being defined by said key] usable to establish security tunnel 210)
and direct the device to establish a second tunnel within the first tunnel (fig. 2 & ¶0037 After receiving client configuration information 218 at wireless VPN client 202 and server configuration information 220 at VPN endpoint server 206, security tunnel 210 may first be instantiated between wireless VPN client 202 and VPN endpoint server 206 using the authentication key provided previously. Security tunnel 210 may represent a network encapsulation protocol to provide an enhanced level of security to individual network packets, such as Internet-protocol security (IPSEC). Once security tunnel 210 is established, layer 2 tunnel 212 may be established within security tunnel 210 using the tunnel identifier provided previously. Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided.)
and facilitating direct communications (fig. 2 & ¶0037 security tunnel 210 may first be instantiated between wireless VPN client 202 and VPN endpoint server 206 [i.e. first tunnel between the device and user device] …Once layer 2 tunnel 212 is operational, a session in the VPN connection providing layer 2 services, such as MEF services, between wireless VPN client 202 at the first location and MAN 208 at the second location may be established via VPN endpoint server 206 [i.e. the second tunnel 212 is providing direct point-to-point communication between the user device and the device] using the session identifier provided previously)
Yet, Beesley fails to teach: a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless network directly between the device and a user device, and direct the device to establish a second tunnel within the first tunnel between the device and the user device; and facilitating direct communications between the device and the user device.
However, in the analogous art, Branch (US 2020/0336409 A1) teaches such limitations:
a first tunnel via a first layer of an internet protocol suite via the first wireless connection over the wireless network directly between the device and a user device. (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0026 The VPN connection can be referred to as a VPN tunnel & ¶0026 Each one of the client devices 110A-N is a computing device (e.g., laptop, workstation, smartphone, palm top, mobile phone, tablets, gaming system, set-top box, etc.) [i.e. wireless operating devices within local area network] & ¶0034 At operation 4, the server 120 transmits, to the first client device 110A and through the first VPN connection, a second public network address of the second client device. At operation 5, the server 120 transmits, to the second client device 110B and through the second VPN connection, a first public network address of the first client device 110A. The transmission of the first public network address [i.e. part of a configuration message] and the second public network address causes the first client device 110A to determine an optimal route from the first client device 110A to the second client device 110B for the traffic in the VPN. For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 [i.e. a VPN tunnel between the two devices within a wireless local network as shown in Fig. 1] without going through the server 120.)
and direct the device to establish a second tunnel within the first tunnel between the device and the user device; (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0034 The transmission of the first public network address and the second public network address causes the first client device 110A to determine an optimal route from the first client device 110A to the second client device 110B for the traffic in the VPN. For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 [i.e. tunnel directly between device and user device])
and facilitating direct communications between the device and the user device. (Fig. 1 (third VPN connection [i.e. a tunnel directly between a device and user device]) & ¶0034 For example, the first client device 110A and the second client device 110B may establish a third VPN connection (operation 6) to transmit the traffic directly within the local network 103 without going through the server 120 [i.e. tunnel with direct communication without intermediate between device and user device])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley’s invention of automated instantiation of wireless virtual private networks to include Branch’s teaching of a first tunnel established over a wireless network directly between the device and a user device, because it enables the device to determine an optimal route for VPN traffic between two devices without sending data through the VPN server. (see Branch ¶0023-¶0024)
Yet, the combined references fail to teach: the first tunnel and the second tunnel being established between the device and the user device without the user device receiving information from the network server regarding establishment of the first tunnel and the second tunnel;
However, in the analogous art, Eisenberg teaches such a limitation:
the first tunnel and the second tunnel being established between the device and the user device without the user device receiving information from the network server regarding establishment of the first tunnel and the second tunnel; (¶0144 tunnels may be created and maintained between TPs on servers 790, 795 and the TP 775 for desktop 770 through firewall 705. Additionally, tunnels may be created and maintained between TPs on servers 790, 795 and a TP 760 and/or TP 750 [i.e. first and second tunnel established between a device and user device] & ¶0147 for any configuration a TP install can take place on each endpoint and/or external server of a configuration to support tunneling without the requirement of a separate system gateway/proxy or user registration process. [i.e. tunnels being established without a gateway/proxy/server reads on the user device not receiving information from a network server regarding establishment of the tunnels])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley and Branch’s invention of automated instantiation of wireless virtual private networks to include Eisenberg’s teaching of the first and second tunnel being established without the user device receiving information, because it would allow the device to support tunneling without a requirement that a separate system server be used in the process to establish the tunnels, which lowers system overhead. (see Eisenberg ¶0147)
Yet, the combined references do not explicitly teach: and quality of service for the first wireless connection selected by the user of the device;
However, in the analogous art, Chitrapu teaches:
and quality of service for the first wireless connection selected by the user of the device; (¶0039 the user requests a communications service and selects a desired QoE at 500)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, and Eisenberg’s invention of automated instantiation of wireless virtual private networks to include Chitrapu’s teaching of quality of service for the wireless connection being selected by the user of the device, because it would enable dynamic QoS control through user control of QoE or parameters for network service. (see Chitrapu ¶0004)
Re. Claim 15, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
wherein the wireless network includes one or more cellular networks. (¶0031 It is noted that wireless network 204 may be a cellular network, such as LTE)
Re. Claim 16, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
wherein the configuration file includes authentication credentials for the device, (¶0036 The server configuration information 220 may include specific configuration information for VPN endpoint server 206, which is an individual server instance used to provide the VPN connection to wireless VPN client 202. Accordingly, server configuration information 220 may include the authentication key [i.e. authentication credentials for device in order to instantiate security tunnel 210] usable to establish security tunnel 210,)
Re. Claim 17, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
wherein the first tunnel is an internet protocol security (IPsec) tunnel, (Fig. 2 & ¶0037 Security tunnel 210 may represent a network encapsulation protocol to provide an enhanced level of security to individual network packets, such as Internet-protocol security (IPSEC).)
and the second tunnel is a layer 2 tunneling protocol (L2TP) tunnel, (Fig. 2 & ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided.)
the second tunnel configured to provide transparency between the device and the user device. (Fig. 2 & ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), which enables MEF services, such as multiprotocol layer 2 traffic over IP networks, to be provided. [i.e. Layer 2 tunnel 212 being depicted in Fig.2 as a transparent due to no intermediate nodes between the two devices being connected by the tunnel])
Re. Claim 18, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
wherein the first layer is an internet layer of an internet protocol suite, (Fig. 2 [depicts Security tunnel 210 as a first layer tunnel, implied by tunnel 212 within it being a layer 2 tunnel] & ¶0004 the security tunnel may be an Internet-protocol security tunnel.)
and the second layer is a link layer of the internet protocol suite. (¶0037 ¶0037 Layer 2 tunnel may also represent a network encapsulation protocol that operates on individual packets to provide layer 2 services, such as layer 2 tunneling protocol version 3 (L2TPv3, Internet Engineering Task Force, IETF), [i.e. L2TP –operates at the link layer, otherwise known as Layer 2])
Re. Claim 20, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
wherein the communications between the device and the user device include internet protocol (IP) traffic and non-IP traffic. (¶0026 Network 100 may communicate information or “traffic” over transmission media 112… In particular embodiments, traffic may be communicated via a suitable communications protocol, including, without limitation, the Internet Protocol (IP). Additionally, the traffic communicated via network 100 may be structured in any appropriate manner including, but not limited to, being structured in frames, packets, or an unstructured bit stream. [i.e. unstructured bit stream is inherently non-(IP) traffic because it does not use IP header or follow IP protocol convention])
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Beesley combined with Branch, Eisenberg, Chitrapu, and further in view of Gupta et al. (US 2023/0261963 A1), hereinafter referred to as Gupta.
Re. Claim 2, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Yet, the combined references fail to teach: wherein the device utilizes a network address translation (NAT) protocol for directing network traffic.
However, in the analogous art, Gupta teaches such a limitation:
wherein the device utilizes a network address translation (NAT) protocol for directing network traffic. (¶0031 If the edge network devices 142 use private colors and need NAT to communicate to other private colors, the carrier setting in the configuration can dictate whether the edge network devices 142 use private or public IP addresses. Using this setting, two private colors can establish a session when one or both are using NAT)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, Eisenberg, and Chitrapu’s Invention of Automated instantiation of wireless virtual private networks to include Gupta’s teaching of the device utilizing a NAT protocol for directing network traffic, because it would enable communications with devices located behind the NAT. (see Gupta ¶0022)
Re. Claim 13, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Yet, the combined references fail to teach: wherein the device utilizes a network address translation (NAT) protocol for directing network traffic.
However, in the analogous art, Gupta teaches such a limitation:
wherein the device utilizes a network address translation (NAT) protocol for directing network traffic. (¶0031 If the edge network devices 142 use private colors and need NAT to communicate to other private colors, the carrier setting in the configuration can dictate whether the edge network devices 142 use private or public IP addresses. Using this setting, two private colors can establish a session when one or both are using NAT)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, Eisenberg, and Chitrapu’s Invention of Automated instantiation of wireless virtual private networks to include Gupta’s teaching of the device utilizing a NAT protocol for directing network traffic, because it would enable communications with devices located behind the NAT. (see Gupta ¶0022)
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Beesley combined with Branch, Eisenberg, Chitrapu, and further in view of Gui (English translation of CN 112788782 B), hereinafter referred to as Gui.
Re. Claim 3, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 1.
Beesley further teaches:
the configuration parameters configured to facilitate the first wireless connection between the device and the user device. (¶0036 Accordingly, server configuration information 220 may include the authentication key usable to establish security tunnel 210, the tunnel identifier usable to establish layer 2 tunnel 212, and the session identifier usable to establish a session in layer 2 tunnel 212, among other information. Additionally, server configuration information 220 may include the private network address for VPN endpoint server 206)
Yet the combined references fail to teach: further comprising: determining, by the network server, one or more configuration parameters to be included in the configuration file based on the request.
However, in the analogous art, Gui teaches such limitations:
further comprising: determining, by the network server, one or more configuration parameters to be included in the configuration file based on the request, (Gui: ¶0050 The response message of the network management server to the IPSec configuration information request includes at least: the planned Internet backhaul IP, virtual IP address pool, [i.e. server determines configuration parameters of endpoint/user device addressing to be included in the configuration based on the request] IPSec tunnel traffic selector, authentication method, pre-shared key or digital certificate;)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, Eisenberg, and Chitrapu’s Invention of Automated instantiation of wireless virtual private networks to include Gui’s teaching of a request for configuration information being sent by the device to the network server, because it allows the system to obtain information necessary for configuring server before establishing an IPSEC security tunnel. (see Gui ¶0046)
Re. Claim 14, Beesley combined with Branch, Eisenberg, and Chitrapu teaches claim 12.
Beesley further teaches:
the configuration parameters configured to facilitate the first wireless connection between the device and the user device. (¶0036 Accordingly, server configuration information 220 may include the authentication key usable to establish security tunnel 210, the tunnel identifier usable to establish layer 2 tunnel 212, and the session identifier usable to establish a session in layer 2 tunnel 212, among other information. Additionally, server configuration information 220 may include the private network address for VPN endpoint server 206)
Yet the combined references fail to teach: wherein the operations further comprise: determining, by the network server, one or more configuration parameters to be included in the configuration file based on the request
However, in the analogous art, Gui teaches such limitations:
wherein the operations further comprise: determining, by the network server, one or more configuration parameters to be included in the configuration file based on the request, (Gui: ¶0050 The response message of the network management server to the IPSec configuration information request includes at least: the planned Internet backhaul IP, virtual IP address pool, [i.e. endpoint/user device addressing] IPSec tunnel traffic selector, authentication method, pre-shared key or digital certificate;)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beesley, Branch, Eisenberg, and Chitrapu’s Invention of Automated instantiation of wireless virtual private networks to include Gui’s teaching of a request for configuration information being sent by the device to the network server, because it allows the system to obtain information necessary for configuring server before establishing an IPSEC security tunnel. (see Gui ¶0046)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY A MILLER whose telephone number is (571)272-4423. The examiner can normally be reached Mon-Fri 8 to 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, Rebecca Song can be reached at 571-270-3667. 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.
/G.A.M./Examiner, Art Unit 2417
/REBECCA E SONG/Supervisory Patent Examiner, Art Unit 2417
Prosecution Insights