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 .
Priority
The instant application is a continuation of US SN 18/170,924 filed on 17 February 2023 and US SN 16/898,374 filed on 10 June 2020. Therefore, the effective filing date for the claims is 10 June 2020.
Information Disclosure Statement
The Information Disclosure Statement filed on 07 February 2025 complies with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Oath/Declaration
A proper Oath/Declaration was filed on 07 February 2025.
Drawings
No issues have been found with the drawings filed on 07 February 2025.
Specification
No issues have been found with the specification filed on 07 February 2025.
Claim Objections
Claims 1, 8, 9, 16, and 17 are objected to because of the following informalities:
Regarding claim 1, line 2—“a first private IP address” should be rewritten to state --a first private Internet Protocol (IP) address-- in order to have the abbreviation written out the first time it is mentioned in the claim.
Claims 9 and 17 include similar limitations and are similarly analyzed.
Regarding claim 8, line 1—“the first and second private IP addresses” should be rewritten to state --the first private IP address and the second private IP address-- in order to show clear antecedence to the limitations in claim 1.
Claim 16 includes similar limitations and is similarly analyzed.
Appropriate correction is required.
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 and 9 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 8 and 16 of U.S. Patent No. 12,250,199.
Although the claims at issue are not identical, they are not patentably distinct from each other because they are different definitions or descriptions of the same subject matter varying in breadth.
For example, note the following relationship between the instant application claims and the patented claims:
Application claim 1 corresponds to the patent claim 8:
Instant Application
US Patent No. 12,250,199
1. A method implemented by a Virtual Private Network (VPN) service, comprising:
Claim 1: A method implemented by a virtual private network (VPN) concentrator, comprising:
assigning a first private IP address for a VPN concentrator and a second private IP address for a user device;
Claim 1: establishing the VPN tunnel, wherein a first private IP address of the VPN concentrator and a second private IP address of the user device constitute endpoints of the VPN tunnel,
modifying packets originating from the user device, wherein modifying the packets comprises:
translating the second private IP address to a unique private IP address managed by the VPN concentrator; and
Claim 1: performing a substitution of the second private IP address with the third private IP address in a header of the outbound packet, wherein the substitution is performed based on the entry, to replace the source address of the outbound packet;
translating the unique private IP address to a public IP address of the VPN concentrator;
Claim 1: performing network address translation (NAT) on the outbound packet to replace the third private IP address with a third public IP address of the VPN concentrator as the source address in the header of the outbound packet prior to transmitting the outbound packet to the target;
registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator;
Claim 1: generating an entry in a peer hashtable, wherein the entry maps a combination of a unique identifier associated with the user device, the second private IP address, and the first public IP address to the third private IP address,
modifying inbound packets received from a network external to the VPN service, wherein modifying the inbound packets comprises: translating the public IP address to the unique private IP address using the VPN session data stored in the peer hashtable; and
Claim 8: performing NAT on an inbound packet received from the target to replace the third public IP address with the third private IP address; identifying the second private IP address based on a lookup using the third public IP address in the peer hashtable; and substituting the third private IP address with the second private IP address in a header of the inbound packet; and transmitting the inbound packet to the first private IP address
translating the unique private IP address to the second private IP address associated with the user device; and
Claim 8: performing NAT on an inbound packet received from the target to replace the third public IP address with the third private IP address; identifying the second private IP address based on a lookup using the third public IP address in the peer hashtable; and substituting the third private IP address with the second private IP address in a header of the inbound packet; and transmitting the inbound packet to the first private IP address
sending the modified inbound packets to the user device.
Claim 8: transmitting the inbound packet to the first private IP address
Application claim 9 corresponds to the patent claim 16.
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 7 and 15 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.
Regarding claim 7, lines 2-3—“wherein the VPN concentrator contains no other information about the user device throughout a session associated with a VPN tunnel”, this limitation creates an issue with the scope of the subject matter covered by the claim. In this case, it is unclear as to what “no other information” is referring. Claim 1, lines 10-12 states “registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator”. The “unique private IP address” replaced the “second private IP address” assigned to the user device, and therefore, would be considered “information about the user device”. This creates an unclear indication of scope for claim 7. The examiner suggests amending the claim to clearly indicate what data is maintained by the VPN concentrator. For examination purposes, the examiner will interpret the claim language to mean that no other user device information other than the unique private key and the public key are contained within the VPN concentrator.
Claim 15 includes similar language and is similarly analyzed.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 3, 8, 9, 11, 16, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Goldschlag et al. (US 2020/0162431 A1) in view of Markuze et al. (US 2019/0158605 A1) and further in view of Raphel et al. (US 8,259,571 B1).
Regarding claim 1, Goldschlag teaches a method implemented by a Virtual Private Network (VPN) service, comprising:
assigning a first private IP address for a VPN concentrator, e.g., an ARS server with a client gateway, wherein the gateway includes a client VPN concentrator and a service VPN concentrator (Fig. 2, el. 100; Fig. 3, el. 100a-c, 180, 130a-b, 140a-c), and a second private IP address for a user device, e.g., a client device (Fig. 2, el. 300A; Fig. 3, el. 300);
the client VPN concentrator assigns a unique IP address to each VPN tunnel or stream through the client VPN concentrator (Para. 54);
the client VPN concentrator (130b) receives, from client (310), encrypted outer tunnel packets from one or more applications (e.g. 316a), wherein the outer tunnel packets each include a source IP address that corresponds to client device (300) and a destination IP address that is a virtual IP address that corresponds to ARS (100b) (Fig. 3, el. 310; Para. 70);
if the desired VPN tunnel as not been previously established, the client VPN endpoint requests the IP address to send the connection request to, either from a public or private DNS (168) or other directory service and makes the VPN tunnel connection to that address, and the client VPN endpoint opens one or more VPN tunnels between the client (310) and one or more client VPN concentrators (at the ARS) and routes encrypted packets to and from the client, and it provides an ARS-only local client IP address for each VPN connection for the purposes of routing packets to/from the client device (Para. 86);
if access to the requested service is controlled by the one or more policy elements, the client, at step (3140) obtains, from public DNS (168), virtual IP address information corresponding to a connection provided by VPN concentrator (e.g. 130a), or more generally to the ARS (100) (Fig. 6A, el. 3140; Para. 134);
modifying packets originating from the user device, e.g., using NAT, the system rewrites endpoint addresses to ARS local addresses in order to hide the endpoint architecture details (Para. 60);
the client gateway (180b) of the first ARS receives encrypted packets addressed to the requested service connected to the second ARS and routes the encrypted packets to the requested service by changing the destination address of the packets to the local service address (i.e. to a local IP address associated with service VPN concentrator (140c) of the second ARS), and ARS 100b routes the packets to ARS (100c), where they are received by service VPN concentrator (140c) of the second ARS, where the service VPN concentrator changes the destination address of the packets to the IP address of the requested service and delivers them to the requested service (Para. 64);
the router/filter component then readdresses the packet with the local IP address of the specified endpoint ID and then routes the readdressed packet to the local IP address (Para. 65);
the client gateway (180) looks up a local service IP address corresponding to the endpoint ID of the service and changes the destination IP address of each inner tunnel packet, without decrypting it, to the local service IP address to which the packet was addressed by the client (310); i.e., the client gateway changes the destination address to a local IP address associated with the service VPN concentrator that is connected to service (200) (Para. 70);
…; and
…;
registering VPN session data for the user device, including…an identifier associated with the user device, in a peer…table maintained by the VPN concentrator, e.g., the client gateway component publishes the local service IP addresses to a local directory service, with components on the current and clustered ARSs, where the client gateway component shares a local IP address associated with client device (300) applications (e.g. 316a) and local service IP address associated with enterprise service (200) with the one or more router/filter components (120a and 120c) (Para. 55);
a routing/NAT table (150) which is a directory that stores routing and IP mapping information including: IP address:port corresponding to client devices (310a, 310b) and enterprise services; service connection IDs (i.e. identification of service VPN concentrator or service network interface to which each service is connected and optionally a publisher-specific encryption key or an indication of a location of a key associated with one or more services); application connection IDs (i.e. identification of client VPN concentrator to which each client device VPN endpoint (315a, 315b) is connected) and the identification of client VPN tunnel and individual stream (in the case of multiplexed tunnels of connections) over which data to and from each application is tunneled (Para. 68);
the ARS records information encoded in packet wrappers to a directory service and uses the information for internal routing of packets between applications and services, where the client VPN concentrator or gateway component of the ARS, records one or more of the IP:port, application ID, connection ID, session ID information extracted from packets received from the client device to a directory service and associates the information with a local IP address (Para. 113);
modifying inbound packets received from a network…, wherein modifying the inbound packets comprises: translating the…IP address to the unique private IP address using the VPN session data stored in the peer…table, e.g., Service VPN concentrator (140b) receives outer tunnel packets, encapsulated with VPN encryption, from Service (200), and the Service VPN concentrator removes the VPN encapsulation to expose inner tunnel encrypted packets, each encapsulated in a wrapper that includes an application ID associated with a particular application, and the Service VPN concentrator looks up a local client IP address corresponding to the application ID and changes the destination IP address of each inner tunnel packet, without decrypting it, to the local client IP address (i.e. to a local IP address corresponding to the client VPN concentrator and, optionally, a particular multiplexed stream corresponding to the particular application) (Para. 71);
when a gateway component of the ARS first receives a packet destined for a particular endpoint ID, the gateway looks up the endpoint ID in a local destination database that includes sessions indexed by session ID and/or endpoint ID, wherein the lookup returns the local service IP address assigned to the VPN concentrator associated with the endpoint ID, and the packet is routed to that address in accordance with policy (Para. 72);
the ARS records information encoded in packet wrappers to a directory service and uses the information for internal routing of packets between applications and services, wherein the client VPN concentrator or gateway component of the ARS, records one or more of the IP:port, application ID, connection ID, session ID information extracted from packets received from the client device to a directory service and associates the information with a local IP address, and the service VPN concentrator, or a stitcher component of the ARS extracts and records one or more of IP:port, service ID, connection ID, session ID data from packets received from the service, associated with a local IP address corresponding to the connection ID, to a directory service (Para. 113); and
translating the unique private IP address to the second private IP address associated with the user device, e.g., the client VPN concentrator receives the encrypted inner tunnel packets and changes the destination IP address of each packet, without decrypting it, to an IP address associated with a corresponding particular application (e.g. 316a), and the client VPN concentrator (130b) applies outer tunnel encapsulation to each packet by encrypting it using a VPN connection encryption key and sends the packet to VPN endpoint (315) (Para. 71); and
sending the modified inbound packets to the user device, e.g., the client VPN concentrator receives the encrypted inner tunnel packets and changes the destination IP address of each packet, without decrypting it, to an IP address associated with a corresponding particular application (e.g. 316a), and the client VPN concentrator (130b) applies outer tunnel encapsulation to each packet by encrypting it using a VPN connection encryption key and sends the packet to VPN endpoint (315) (Para. 71).
Goldschlag does not clearly teach wherein modifying the packets comprises: translating the second private IP address to a unique private IP address managed by the VPN concentrator; and
translating the unique private IP address to a public IP address of the VPN concentrator;
registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator;
modifying inbound packets received from a network external to the VPN service; and
wherein modifying the inbound packets comprises:
translating the public IP address to the unique private IP address using the VPN session data stored in the peer hashtable.
Markuze teaches assigning a first private IP address for a VPN concentrator, e.g., an ingress gateway 1770 and an egress gateway 1702 included in a virtual network 1700 (Fig. 17, el. 1700, 1770, 1702), wherein the gateways are part of Managed Forwarding Nodes (MFNs) (Para. 232), and a second private IP address for a user device, e.g., a mobile device (Fig. 2, el. 140);
at 1310, the process determines whether both the source and destination IP addresses in the received data message's header are public IP addresses, and if so, the process (at 1315) drops the data message (Fig. 13, el. 1310; Para. 196);
modifying packets originating from the user device, wherein modifying the packets comprises: translating the second private IP address to a unique private IP address managed by the VPN concentrator, e.g., the TM engine 1705 maps the source IP and port addresses of data messages entering the virtual network to new source IP and port addresses, when these data messages are destined to (i.e., have destination IP addresses for) SaaS provider datacenters 1620 (Figs. 17, 18, el. 1705; Para. 233);
when the source and destination MFN CFEs belong to the same public cloud, the source and destination IP addresses can be private IP addresses (Fig. 7; Para. 160);
the ingress NAT engine 1712 next translates (1) the source IP address of the data message 1800 to a unique private or public (internal or external) IP address of 198.15.4.33 (Figs. 17, 18, el. 1712; Para. 241); and
translating the unique private IP address to a public IP address of the VPN concentrator, e.g., the egress NAT engine 1710 changes the source IP address to an external IP address 198.15.7.125, which in some embodiments is the public IP address of the egress gateway(s) of the virtual network, wherein this public IP address in some embodiments is also an IP address of the public cloud datacenter in which the ingress and egress gateways 1770 and 1702 operate (Figs. 17, 18, el. 1710; Para. 242);
registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer…table maintained by the VPN concentrator, e.g., based on this tenant ID, the tenant mapping engine 1705 then maps the source IP and port addresses to source IP and port address pair of 15.1.1.13 and 253, wherein in some embodiments, the TM engine 1705 performs this mapping in a stateless manner or the TM engine performs this mapping in a stateful manner (Para. 240);
the NAT engine 1712 is a stateful element that performs its mapping by reference to a connection storage that stores connection records that reflect its prior SNAT mappings, and the TM and NAT engines 1705, 1710 and 1712 are configured in some embodiments by the controller cluster 160 (e.g., are provided with tables for describing the mapping to use for different tenants and different ranges of network address space) (Para. 238);
the ingress process 900 starts by initially identifying (at 905) the tenant routing context based on the identifier of the IPsec tunnel (e.g., 806 or 1206) in the received data message, and the IPsec gateways or other MFN modules store the tenant IDs for the IPsec tunnel IDs in mapping tables, and whenever a data message is received along a particular IPsec tunnel, the IPsec gateway extracts the IPsec tunnel ID, which this gateway or another MFN module then uses to identify the associated tenant ID by reference to its mapping table, and by identifying the tenant ID, the process identifies the tenant routing table or the tenant portion of the VRF namespace to use (Para. 176);
modifying inbound packets received from a network external to the VPN service, wherein modifying the inbound packets comprises: translating the public IP address to the unique private IP address using the VPN session data stored in the peer…table, e.g., the NAT engine 1710 (now acting as an ingress NAT engine) performs a DNAT (destination NAT) operation on the data message 1900, wherein this operation changes the external destination IP address 198.15.7.125 to a destination IP address 198.15.4.33 that is used by the virtual network to forward the data message 1900 through the public cloud routing fabric and between the virtual network components, wherein, the IP address 198.15.4.33 can be a public or private IP address (Fig. 19; Para. 246);
at 1525, the process performs a reverse NAT operation that translates the destination IP/port addresses of the data message to new destination IP/port addresses that the virtual network associates with a particular tenant, where this NAT operation also produces the tenant ID (e.g., retrieves the tenant ID from a mapping table that associates tenant IDs with translated destination IPs, or retrieves the tenant ID from the same mapping table that is used to obtain the new destination IP/port addresses), and in some embodiments, the process 1500 uses a connection record that the process 1400 created when it performed (at 1430) its SNAT operation to perform (at 1525) its reverse NAT operation, wherein this connection record contains the mapping between the internal and external IP/port addresses that are used by the SNAT and DNAT operations (Para. 209); and
translating the unique private IP address to the second private IP address associated with the user device, e.g., the NAT engine 1712 (now acting as an egress NAT engine) receives the message 1900 after the NAT engine 1710 has translated its destination IP address, and the NAT engine 1712 then performs a second DNAT operation on this message 1900, which replaces its destination IP and port addresses to 15.1.1.13 and 253, and these addresses are the addresses recognized by the TM engine 1705, and the TM engine 1705 replaces these addresses to the destination IP and port addresses of 10.1.1.13 and 4432, associates the data message 1900 with the tenant ID 15, and provides the message 1900 with this tenant ID to the IPsec gateway 1805 for forwarding to the tenant gateway 1810 (Fig. 19; Para. 247); and
sending the modified inbound packets to the user device, e.g., the TM engine 1705 replaces these addresses to the destination IP and port addresses of 10.1.1.13 and 4432, associates the data message 1900 with the tenant ID 15, and provides the message 1900 with this tenant ID to the IPsec gateway 1805 for forwarding to the tenant gateway 1810 (Fig. 19; Para. 247).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldschlag to include wherein modifying the packets comprises: translating the second private IP address to a unique private IP address managed by the VPN concentrator; and translating the unique private IP address to a public IP address of the VPN concentrator; registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer table maintained by the VPN concentrator; modifying inbound packets received from a network external to the VPN service; and wherein modifying the inbound packets comprises: translating the public IP address to the unique private IP address using the VPN session data stored in the peer table, using the known methods of translating the source IP address to an internal IP address and then to a public IP address when from the client and translating the destination IP address to an internal IP address and then to the client’s IP address when from the service, as taught by Markuze, in combination with the VPN NAT system of Goldschlag, for the purpose of optimizing the routing of the entity’s data messages to their destinations for best end-to-end performance, reliability and security, while trying to minimize the routing of this traffic through the Internet (Markuze-Para. 68).
Goldschlag in view of Markuze does not clearly teach registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator; and
wherein modifying the inbound packets comprises: translating the public IP address to the unique private IP address using the VPN session data stored in the peer hashtable.
Raphel teaches registering VPN session data for the user device, including the unique…IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator, e.g., establishing a VPN tunnel between the edge router/client and the processing node, wherein the tunnel is overlaid onto the Internet (Col. 4, lines 49-58; Col. 6, lines 39-50);
a lookup table maps the tunnel ID, source IP, and source port into a new source IP and source port (Col. 9, lines 7-27);
socket binding module 720 processes packets to extract information such as their source IP, destination IP, edge router IP, source port, and destination port, where the extracted information is used by the socket binding module 720 to construct a tuple that is stored as a CCB, such as the CCB 715, and to search the connection table 710 to find a corresponding tuple, and the corresponding tuple that includes information that can be used to address flows between the PN and one or more destinations (Col. 12, lines 50-58);
creating a hash value from the tuple to lookup the connection table 710 (Col. 13, lines 43-46);
using the tunnel ID as an index to the hash table to lookup a connection data structure where the tunnel IP, client IP, and server IP are recorded (Col. 13, lines 60-67); and
wherein modifying the inbound packets comprises: translating the…IP address to the…IP address using the VPN session data stored in the peer hashtable, e.g., the NAT 740 translates the addresses bound by the socket binding module 720 to convert between addresses and ports used within the PN and those used to communicate with destination devices. In some implementations, the network address translation may be performed using an IP address owned by the PN (e.g., VIP NAT), or may use the public IP of an edge router (e.g., tenant IP NAT) (Col. 14, lines 1-7);
the reverse flow can be directed to the correct tunnel by looking up the table of NATed entries (Col. 14, lines 19-20);
mapping the private source IP address into a public IP address (Col. 9, lines 7-27; Col. 9, line 61-Col. 10, line 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldschlag in view of Markuze to include registering VPN session data for the user device, including the unique private IP address and an identifier associated with the user device, in a peer hashtable maintained by the VPN concentrator; and wherein modifying the inbound packets comprises: translating the public IP address to the unique private IP address using the VPN session data stored in the peer hashtable, using the known method of utilizing a hash table for looking-up mapping information and translating IP addresses based on the mapping information, as taught by Raphel, in combination with the VPN communication system of Goldschlag in view of Markuze, for the purpose of reducing addressing ambiguity, (Raphel-Col. 1, lines 57-60), and providing a more efficient, accurate, and secure method of identifying and utilizing IP address mapping information.
Regarding claim 3, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1.
Goldschlag does not clearly teach wherein the second private IP address is shared across multiple simultaneous VPN tunnels.
Markuze further teaches wherein the second private IP address is shared across multiple simultaneous VPN tunnels, e.g., corporate datacenter 134, branch office 130a, mobile device 140 (Figs. 1A, 2), wherein the virtual network 100 connects mobile devices 140 and the branch office 130a to the same MFN 150 and mobile devices 140 are each connected to the same MFN 150 (Figs. 1A, Fig. 2; Para. 79); performing IP translation on data message flows so that external devices can differentiate different devices within different private networks that use the same internal IP addresses (Para. 215).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldschlag to include wherein the second private IP address is shared across multiple simultaneous VPN tunnels, using the known method of performing IP translation on data message flows so that external devices can differentiate different devices within different private networks that use the same internal IP addresses, wherein multiple mobile devices may be connected to the same MFN over the virtual network, as taught by Markuze, in combination with the VPN NAT system of Goldschlag, using the same motivation as in claim 29.
Also note: Raphel discloses separate sources may have the same private IP addresses and send a message to the same private IP address of the PN (Col. 7, lines 15-47; Col. 8, lines 48-57), wherein each of two devices have a tunnel to the PN and include the same source private IP address (Fig. 2, el. 202-1, 202-2).
Regarding claim 4, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1, further comprising: receiving, at the VPN concentrator, a request to establish a VPN tunnel from the user device, wherein the request includes a cryptographic identifier, e.g., validating, by the client VPN concentrator component 130a of the ARS, the client device, user, and application in accordance with policy using an IdP (Goldschlag-Para. 53);
successful authentication requires that the requesting user, device, and application are known to the local IdP and are allowed, by policy, to access the ARS, where a user identity corresponding to the requesting user must match a user identity known by the local IdP, and a device identifier, e.g. device UUID, must match a known device identity, and a certificate associated with the requesting application must match a copy of a certificate stored by the IdP and known by the IdP to have previously been associated with the application, and the local IdP also checks user, device, and/or application access rights to ARS (100b) (Goldschlag-Para. 54);
the process starts, at step (3205), when client VPN concentrator (e.g. 130a) receives a VPN connection request from a client, and the client VPN concentrator determines, at step (3210) whether the user and/or device is known to the ARS on the basis of information provided by the client (Goldschlag-Fig. 6B, el. 3205, 3210; Para. 140);
at step (3230) the client VPN concentrator determines whether the application is known to the ARS, for example by querying the policy to determine if the application is on a list of applications approved for access to the AR, and in some configurations the application, for example a web browser application, is associated with a certificate and the client VPN concentrator determines whether the certificate matches a certificate that was previously known by the system to be associated with the application, and in a particular configuration, the local IdP stores a copy of a certificate associated with each web browser application that is allowed to access the ARS and step (3230) includes determining whether a certificate presented by an application requesting access to the ARS matches a stored copy of a certificate that was previously associated with the browser (Goldschlag-Fig. 6B, el. 3230; Para. 141);
forwarding the cryptographic identifier to an authentication platform for verification, e.g., validating, by the client VPN concentrator component 130a of the ARS, the client device, user, and application in accordance with policy using an IdP (Goldschlag-Para. 53);
successful authentication requires that the requesting user, device, and application are known to the local IdP and are allowed, by policy, to access the ARS, where a user identity corresponding to the requesting user must match a user identity known by the local IdP, and a device identifier, e.g. device UUID, must match a known device identity, and a certificate associated with the requesting application must match a copy of a certificate stored by the IdP and known by the IdP to have previously been associated with the application, and the local IdP also checks user, device, and/or application access rights to ARS (100b) (Goldschlag-Para. 54);
the process starts, at step (3205), when client VPN concentrator (e.g. 130a) receives a VPN connection request from a client, and the client VPN concentrator determines, at step (3210) whether the user and/or device is known to the ARS on the basis of information provided by the client (Goldschlag-Fig. 6B, el. 3205, 3210; Para. 140);
at step (3230) the client VPN concentrator determines whether the application is known to the ARS, for example by querying the policy to determine if the application is on a list of applications approved for access to the AR, and in some configurations the application, for example a web browser application, is associated with a certificate and the client VPN concentrator determines whether the certificate matches a certificate that was previously known by the system to be associated with the application, and in a particular configuration, the local IdP stores a copy of a certificate associated with each web browser application that is allowed to access the ARS and step (3230) includes determining whether a certificate presented by an application requesting access to the ARS matches a stored copy of a certificate that was previously associated with the browser (Goldschlag-Fig. 6B, el. 3230; Para. 141); and
authorizing access and initiating the VPN tunnel establishment upon successful verification, e.g., validating, by the client VPN concentrator component 130a of the ARS, the client device, user, and application in accordance with policy using an IdP (Goldschlag-Para. 53);
successful authentication requires that the requesting user, device, and application are known to the local IdP and are allowed, by policy, to access the ARS, where a user identity corresponding to the requesting user must match a user identity known by the local IdP, and a device identifier, e.g. device UUID, must match a known device identity, and a certificate associated with the requesting application must match a copy of a certificate stored by the IdP and known by the IdP to have previously been associated with the application, and the local IdP also checks user, device, and/or application access rights to ARS (100b) (Goldschlag-Para. 54);
the process starts, at step (3205), when client VPN concentrator (e.g. 130a) receives a VPN connection request from a client, and the client VPN concentrator determines, at step (3210) whether the user and/or device is known to the ARS on the basis of information provided by the client (Goldschlag-Fig. 6B, el. 3205, 3210; Para. 140);
at step (3230) the client VPN concentrator determines whether the application is known to the ARS, for example by querying the policy to determine if the application is on a list of applications approved for access to the AR, and in some configurations the application, for example a web browser application, is associated with a certificate and the client VPN concentrator determines whether the certificate matches a certificate that was previously known by the system to be associated with the application, and in a particular configuration, the local IdP stores a copy of a certificate associated with each web browser application that is allowed to access the ARS and step (3230) includes determining whether a certificate presented by an application requesting access to the ARS matches a stored copy of a certificate that was previously associated with the browser (Goldschlag-Fig. 6B, el. 3230; Para. 141).
Regarding claim 8, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1, wherein the first and second private IP addresses are within a same private network, e.g., the client VPN concentrator (130b) receives, from client (310), encrypted outer tunnel packets from one or more applications (e.g. 316a), wherein the outer tunnel packets each include a source IP address that corresponds to client device (300) and a destination IP address that is a virtual IP address that corresponds to ARS (100b) (Goldschlag-Fig. 3, el. 310; Para. 70);
if the desired VPN tunnel as not been previously established, the client VPN endpoint requests the IP address to send the connection request to, either from a public or private DNS (168) or other directory service and makes the VPN tunnel connection to that address, and the client VPN endpoint opens one or more VPN tunnels between the client (310) and one or more client VPN concentrators (at the ARS) and routes encrypted packets to and from the client, and it provides an ARS-only local client IP address for each VPN connection for the purposes of routing packets to/from the client device (Goldschlag-Para. 86).
Also note Markuze further discloses the TM engine 1705 maps the source IP and port addresses of data messages entering the virtual network to new source IP and port addresses, when these data messages are destined to (i.e., have destination IP addresses for) SaaS provider datacenters 1620 (Figs. 17, 18, el. 1705; Para. 233), and when the source and destination MFN CFEs belong to the same public cloud, the source and destination IP addresses can be private IP addresses (Fig. 7; Para. 160), and the ingress NAT engine 1712 next translates (1) the source IP address of the data message 1800 to a unique private or public (internal or external) IP address of 198.15.4.33 (Figs. 17, 18, el. 1712; Para. 241).
Regarding claim 9, the claim is analyzed with respect to claim 1. Goldschlag in view of Markuze in view of Raphel further teaches a system that implements by a Virtual Private Network (VPN) service, the system comprising: a memory, e.g., a machine readable medium such as a storage medium (Goldschlag-Para. 153); and a processor, e.g., one or more ASICs, DSPs, PLDs, FPGAs, processors, or microprocessors (Goldschlag-Para. 151), the processor configured to execute instructions stored in the memory, e.g., program code to perform the necessary tasks may be stored in the storage medium (Goldschlag-Para. 153), to: perform the steps.
Regarding claim 11, the claim is analyzed with respect to claim 3.
Regarding claim 12, the claim is analyzed with respect to claim 4.
Regarding claim 16, the claim is analyzed with respect to claim 8.
Regarding claim 17, the claim is analyzed with respect to claims 1, 8, 9, and 16.
Regarding claim 18, the claim is analyzed with respect to claim 4.
Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Goldschlag in view of Markuze in view of Raphel and further in view of Stademann et al. (US 2008/0285569 A1).
Regarding claim 2, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1.
Goldschlag in view of Markuze in view of Raphel further teaches …the peer hashtable…, creating a hash value from the tuple to lookup the connection table 710 (Raphel-Col. 13, lines 43-46);
using the tunnel ID as an index to the hash table to lookup a connection data structure where the tunnel IP, client IP, and server IP are recorded (Raphel-Col. 13, lines 60-67).
Goldschlag in view of Markuze in view of Raphel does not clearly teach dynamically updating the peer hashtable to remove entries associated with closed sessions.
Stademann teaches dynamically updating the peer…table to remove entries associated with closed sessions, e.g., after termination of a session, the ESN deactivates the logical session interface and the corresponding table entries are deleted (Para. 53).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Goldschlag in view of Markuze in view of Raphel to include dynamically updating the peer hashtable to remove entries associated with closed sessions, using the known method of deleting corresponding table entries after termination of a session, as taught by Stademann, in combination with the VPN system of Goldschlag in view of Markuze in view of Raphel, for the purpose of reducing the space required for the table, thereby freeing memory for other data.
Regarding claim 10, the claim is analyzed with respect to claim 2.
Claims 5-7, 13-15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Goldschlag in view of Markuze in view of Raphel and further in view of Cheline et al. (US 2003/0041091 A1).
Regarding claim 5, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1.
Goldschlag in view of Markuze in view of Raphel further teaches wherein registering the VPN session data comprises: creating a record in the peer hashtable with a…key associated with the user device as a key field; and storing the second private IP address and the unique private IP address as associated values with the key field, e.g., a routing/NAT table (150) which is a directory that stores routing and IP mapping information including: IP address:port corresponding to client devices (310a, 310b) and enterprise services; service connection IDs (i.e. identification of service VPN concentrator or service network interface to which each service is connected and optionally a publisher-specific encryption key or an indication of a location of a key associated with one or more services); application connection IDs (i.e. identification of client VPN concentrator to which each client device VPN endpoint (315a, 315b) is connected) and the identification of client VPN tunnel and individual stream (in the case of multiplexed tunnels of connections) over which data to and from each application is tunneled (Goldschlag-Para. 68);
the ARS records information encoded in packet wrappers to a directory service and uses the information for internal routing of packets between applications and services, where the client VPN concentrator or gateway component of the ARS, records one or more of the IP:port, application ID, connection ID, session ID information extracted from packets received from the client device to a directory service and associates the information with a local IP address (Goldschlag-Para. 113);
creating a hash value from the tuple to lookup the connection table 710 (Raphel-Col. 13, lines 43-46);
using the tunnel ID as an index to the hash table to lookup a connection data structure where the tunnel IP, client IP, and server IP are recorded (Raphel-Col. 13, lines 60-67).
Goldschlag in view of Markuze in view of Raphel does not clearly teach wherein registering the VPN session data comprises: creating a record in the peer hashtable with a public key associated with the user device as a key field.
Cheline teaches wherein registering the VPN…data comprises: …a public key associated with the user device as a key field, e.g., a public and private key are created simultaneously using an algorithm by the certificate authority (CA) 150 (FIG. 1), where the private key is given only to the requesting party and the public key is made publicly available (as part of a Digital Certificate) in a directory that all parties can access (Para. 61).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Goldschlag in view of Markuze in view of Raphel to include wherein registering the VPN session data comprises: creating a record in the peer hashtable with a public key associated with the user device as a key field, using the known method of creating a public key for a user device, as taught by Cheline, in combination with the VPN system of Goldschlag in view of Markuze in view of Raphel, for the purpose of enhancing the security of the communicated data.
Regarding claim 6, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1.
Goldschlag further teaches further comprising: establishing a shared secret between the user device…using a key-agreement protocol; and deriving session keys for encrypting subsequent communications using the shared secret, e.g., the ARS supports end-to-end data encryption including the provisioning of client devices to apply a second level of encryption to the packets that are tunneled through the encrypted VPN connections, where the ARS facilities a dynamic negotiation of a session encryption key between a client device endpoint and an enterprise service, and the client device uses the negotiated encryption key to apply the second level of encryption to the communications (Para. 76)2
Goldschlag in view of Markuze in view of Raphel does not explicitly teach establishing a shared secret between the user device and the VPN concentrator using a key-agreement protocol; and deriving session keys for encrypting subsequent communications using the shared secret.
Cheline teaches establishing a shared secret between the user device and the VPN concentrator using a key-agreement protocol; and deriving session keys for encrypting subsequent communications using the shared secret, e.g., the session key used to encrypt traffic between devices is generated using a Diffie-Hellman cryptographic technique that enables sending and receiving parties to exchange public keys in a manner that derives a shared, secret key at both ends, where using a common number agreed by both sides, both sides use a different random number, which is their individual private key, as a power to raise the common number, where the results become their private keys and are sent to each other, where the receiving party raises the received number to their own private keys, and the results are the same on both sides, and the Diffie-Hellman technique generates the session key on the modem device using a public exposed value from the VPN Concentrator and a unique private value on the modem, and the Diffie-Hellman algorithm generates the identical session key on the VPN Concentrator device using a public exposed value from the modem and a unique private value on the VPN Concentrator (Para. 82);
the session key can now be used with a block cipher such as DES or 3DES to encrypt information between the devices (Para. 83).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Goldschlag in view of Markuze in view of Raphel to include establishing a shared secret between the user device and the VPN concentrator using a key-agreement protocol; and deriving session keys for encrypting subsequent communications using the shared secret, using the known method of generating a session key for encryption of data communicated between the VPN concentrator and the modem device, where the key is generated using a shared common number and a shared private key, as taught by Cheline, in combination with the VPN system of Goldschlag in view of Markuze in view of Raphel, for the purpose of enhancing the security of the communicated data by preventing the generation of a key without having the requisite seeds.
Regarding claim 7, Goldschlag in view of Markuze in view of Raphel teaches the method of claim 1.
Goldschlag further teaches wherein the identifier comprises a…key generated…; and wherein the VPN concentrator contains no other information about the user device throughout a session associated with a VPN tunnel, e.g., a routing/NAT table (150) which is a directory that stores routing and IP mapping information including: IP address:port corresponding to client devices (310a, 310b) and enterprise services; service connection IDs (i.e. identification of service VPN concentrator or service network interface to which each service is connected and optionally a publisher-specific encryption key or an indication of a location of a key associated with one or more services); application connection IDs (i.e. identification of client VPN concentrator to which each client device VPN endpoint (315a, 315b) is connected) and the identification of client VPN tunnel and individual stream (in the case of multiplexed tunnels of connections) over which data to and from each application is tunneled (Para. 68);
a local DNS (160), which is a directory that includes local client domain names and IP addresses and local service domain names and IP addresses and optionally, publisher-specific encryption keys or locations of keys associated with local service domain names (Para. 69);
the ARS records information encoded in packet wrappers to a directory service and uses the information for internal routing of packets between applications and services, where the client VPN concentrator or gateway component of the ARS, records one or more of the IP:port, application ID, connection ID, session ID information extracted from packets received from the client device to a directory service and associates the information with a local IP address (Para. 113).
Goldschlag in view of Markuze in view of Raphel does not clearly teach wherein the identifier comprises a public key generated during initial user registration.
Cheline teaches wherein the identifier comprises a public key generated during initial user registration, e.g., FIGS. 3A-D are flow charts of a method 300 for automatically configuring a VPN, and a VPN system administrator, such as a corporate IT administrator, requests (step 302) an administration interface from the service provider, and the administrator then selects (step 316) the users that he would like to add to the VPN system (Para. 60);
a public and private key are created simultaneously using an algorithm by the certificate authority (CA) 150 (FIG. 1), where the private key is given only to the requesting party and the public key is made publicly available (as part of a Digital Certificate) in a directory that all parties can access (Para. 61).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Goldschlag in view of Markuze in view of Raphel to include wherein the identifier comprises a public key generated during initial user registration, using the known method of adding a user to the VPN system and creating a public key, as taught by Cheline, in combination with the VPN system of Goldschlag in view of Markuze in view of Raphel, for the purpose of enhancing the security of the communicated data.
Regarding claim 13, the claim is analyzed with respect to claim 5.
Regarding claim 14, the claim is analyzed with respect to claim 6.
Regarding claim 15, the claim is analyzed with respect to claim 7.
Regarding claim 19, the claim is analyzed with respect to claim 5.
Regarding claim 20, the claim is analyzed with respect to claim 6.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ng et al. (US 2016/0234039 A1)—Ng discloses transmitting a data packet to a VPN concentrator through a first aggregated VPN connection comprising two or more VPN tunnels. The packet has a header and a payload section. The header contains a destination address field set to be the address of a network interface of VPN concentrator and a source address field set to be the address of a network interface of mobile phone. The data packet is then encapsulated in second encapsulating packet by the VPN concentrator. The header of the second encapsulating packet contains a destination address field set to be the address of a network interface of a gateway and a source address field set to be the address of a network interface of the VPN concentrator (Para. 40).
Vu (US 2006/0230446 A1)—Vu discloses a first node can request an initial SSL VPN session with a second node by transmitting to the second node the public SSL key of the first node (Para. 42).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
28 July 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights