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 .
Status of Claims
The amendment filed 03/28/2023 has been entered. Claims 1, 8 and 15 are recited in independent form. Claims 1-20 remain pending in the application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/13/2023, 11/14/2024, 03/31/2025, 11/11/2025 and 12/11/12025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
The disclosure is objected to because of the following informalities: “The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed”. Appropriate correction is required.
Claim Objections
Claim 1, 6, 8, 13, 15 and 19 are objected to because of the following informalities:
In regards to Claims 1, 8 and 15, the applicant recites the limitation “an active VPNI peer is absent from the third VPN server”, that should read “the active VPNI peer”, this is a typographical error as “active VPNI peer” was already previously recited. Appropriate correction is required.
In regards to Claims 6, 13 and 19, the applicant recites the limitation “VPN system” that should read “VPNI system” as this is a typographical error. 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 10 and 18 of U.S. Patent No. 12, 218,822 in view of U.S Pub. No. 20230006972 issued to Kolaitis and further in view of U.S No. 11310146 issued to Kaciulis.
Instant Application
U.S Patent
U.S Application No. 16, 934, 376
U.S Patent No. 12, 218,822
Claim 1:
A virtual private network infrastructure (VPNI) system operating a hierarchical-context area network as a VPNI network,
wherein the hierarchical-context area network includes a hierarchy of context areas, the VPNI system comprising:
a first virtual private network (VPN) server;
a second VPN server; and
a third VPN server, wherein:
the hierarchical-context area network includes: a first VPNI context area network (CAN) for a first VPNI context area, wherein the first VPNI CAN is a level-one VPNI CAN, wherein the first VPNI CAN includes a first control-plane VPNI CAN;
a second VPNI CAN for a second VPNI context area, wherein the second VPNI CAN is a level-two VPNI CAN, wherein the second VPNI CAN includes:
a data-plane VPNI CAN; and
a second control-plane VPNI CAN;
a third VPNI CAN for a third VPNI context area, wherein the third VPNI CAN is a level-one VPNI CAN, wherein the third VPNI CAN is allocated a shared IP address, and wherein the third VPNI CAN includes a third control-plane VPNI CAN;
the first VPN server is allocated a first private IP address;
the second VPN server is allocated a second private IP address;
the third VPN server is allocated a third private IP address;
the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN;
the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN;
the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN, wherein, to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN:
the first VPN server sends, to the second VPN server, via the first control-plane VPNI CAN, peering request data, addressed to the shared IP address;
the third VPN server receives, from the second VPN server, via the second control-plane VPNI CAN, the peering request data, wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server;
the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data; and
the first VPN server receives, from the second VPN server, via the first control-plane VPNI.
Claim 1:
A virtual private network infrastructure (VPNI) system operating a hierarchical-context area network as a VPNI network, the VPNI system comprising:
a first virtual private network (VPN) server;
a second VPN server, wherein the second VPN server is associated with a first IP address; and
a third VPN server, wherein the third VPN server is associated with a second IP address, and wherein:
the hierarchical-context area network includes:
a first VPNI context area network (CAN), wherein the first VPNI CAN is a level-one context area network;
a second VPNI CAN, wherein the second VPNI CAN is a level-two context area network; and
a third VPNI CAN, wherein the third VPNI CAN is a level-one context area network, wherein the third VPNI CAN is allocated a shared IP address;
the first VPN server: obtains, from an end user device, via a VPN tunnel between the first VPN server and the end user device, a first protocol data unit addressed to an external device;
identifies the second VPN server in the third VPNI CAN as a current point of egress for transmitting the first protocol data unit to the external device, wherein the second VPN server is associated with the shared IP address; the second VPN server as the current point of egress:
obtains the first protocol data unit, from the first VPN server, via the second VPNI CAN;
identifies available data transport pathways for transporting the first protocol data unit through the hierarchical-context area network, wherein the available data transport pathways include:
a first available data transport pathway that includes the second VPN server as the current point of egress for transporting the first protocol data unit through the hierarchical-context area network; and
a second available data transport pathway that includes the third VPN server as the current point of egress for transporting the first protocol data unit through the hierarchical-context area network;
pseudo-randomly identifies an available data transport pathway from the available data transport pathways as a current data transport pathway; and
in response to a determination that the current data transport pathway is the first available data transport pathway, sends, to the external device, via the Internet, the first protocol data unit; or
in response to a determination that the current available data transport pathway is the second available data transport pathway:
sends, to the third VPN server, via the third VPNI CAN, the first protocol data unit, such that the third VPN server sends, to the external device, via the Internet, the first protocol data unit.
Claims 8 and 15 recites similar limitations to claim 1.
Claims 10 and 18 recites similar limitations to claim 1.
As to claim 1, U.S Patent No. 12, 218,822 does not discloses the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN; the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN; the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN, wherein, to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: the first VPN server sends, to the second VPN server, via the first control-plane VPNI CAN, peering request data, addressed to the shared IP address; the third VPN server receives, from the second VPN server, via the second control-plane VPNI CAN, the peering request data, wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server; the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data; and the first VPN server receives, from the second VPN server, via the first control-plane VPNI.
However, Kolaitis discloses wherein: the hierarchical-context area network includes: a first VPNI context area network (CAN) for a first VPNI context area, wherein the first VPNI CAN is a level-one VPNI CAN, wherein the first VPNI CAN includes a first control-plane VPNI CAN; (Par. (0068-0071)), (Figure 5 labels 120, VPN with control plane)), (Par. (0028)))
a second VPNI CAN for a second VPNI context area, wherein the second VPNI CAN is a level-two VPNI CAN, wherein the second VPNI CAN includes: (Par. (0068-0071); secondary VPN server)), (Par. (0028)),
a data-plane VPNI CAN; and (Figure 5 labels 120; secondary VPN with data plane and encryption device))
a second control-plane VPNI CAN; a third VPNI CAN for a third VPNI context area, wherein the third VPNI CAN is a level-one VPNI CAN, wherein the third VPNI CAN is allocated a shared IP address, and wherein the third VPNI CAN includes a third control-plane VPNI CAN; (Par. (0068-0071);), (Figure 5 label 120;))
the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN; (Par. (0068-0071))), (Par. (0028))
the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN; (Par. (0068-0071);)), (Par. 0028))
in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN, wherein, to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: (Par. (0068-0071))
the first VPN server sends, to the second VPN server, via the first control-plane VPNI CAN, peering request data, addressed to the shared IP address; (Par. (0068-0071)))
the third VPN server receives, from the second VPN server, via the second control-plane VPNI CAN, the peering request data, (Par. (0068-0071) and Claim 1))
the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data; and (Par. (0068-0071) and Claim 1)
the first VPN server receives, from the second VPN server, via the first control-plane VPNI CAN, the peering response data. (Par. (0068-0071)))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12, 218,822 to incorporate the teaching of Kolaitis to utilize the above feature because of the analogous concept of VPN servers in a network, with the motivation of safeguarding users transmitting data using VPN and virtual tunneling though IP address and packets and securely protects privacy browsing internet and from malicious users by authentication of VPN servers in various locations. (Kolaitis Par. (0004-0010))
U.S Patent No. 12, 218,822 and Kolaitis do not explicitly teach the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server;
However Kaciulis teaches the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, (Col. 27 lines 40-67)))
wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server; (Col. 27 lines 40-67)))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified U.S Patent No. 12, 218,822 and Kolaitis to incorporate the teaching of Kaciulis to utilize the above feature because of the analogous concept of VPN servers in a network, with the motivation of increasing security through the use of VPN and making network performance highly effective through various uses of IP address and permitting access through recognized users in the region based on the traffic. (Kaciulis Col. 2 lines 39-65))
In regards to Claims 8 and 15, claims 8 and 15 recites similar limitations and the teachings of U.S Patent No. 12, 218,822, Kolaitis and Kaciulis address all the limitations discussed above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter
In regards to Claim 1, claim 1 is rejected under U.S.C. 101 because the claims are directed to non-statutory subject matter. Claim 1 is directed to “a virtual private network infrastructure (VPNI) system” and recites “a virtual private network infrastructure (VPNI) system operating a hierarchical-context area network as a VPNI network”. This is a system claim that recites no hardware elements such as hardware processor, memory or storage device Examiner respectfully suggests that the claim be amended to incorporate hardware elements to make the claim statutory under 35 USC 101.
In regards to Claims 2-7, claims 2-7 are also rejected under 35 U.S.C 101 being directed to non-statutory subject matter for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-5, 8, 11-12, 15 and 17-18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Funka et al. (U.S Pub. No. 20240187380, hereinafter referred to as “Funka”) and Kolaitis et al. (U.S Pub. No. 20230006972, hereinafter referred to as “Kolaitis”) further in view of Kaciulis et al. (U.S No. 11310146, hereinafter referred to as “Kaciulis”)
In regards to Claim 1, Funka teaches a virtual private network infrastructure (VPNI) system operating a hierarchical-context area network as a VPNI network, wherein the hierarchical-context area network includes a hierarchy of context areas, the VPNI system comprising: (Figure 1 labels 100, 120; VPN network with plurality of VPN)), (Par. (0011); hierarchical-context area network as a VPNI network (default VPN with other respective VPN servers)
a first virtual private network (VPN) server; (Figure 1 label 120; VPN Server 1))
a second VPN server; and (Figure 1 label 120; VPN Server 2))
a third VPN server, (Figure 1 label 120; VPN Server 3))
the first VPN server is allocated a first private IP address; (Par. (0029-0032, 0040-0043); entry and exit IP addresses for multiple VPN servers), (Figure 3 labels VPN connection 1-3))
the second VPN server is allocated a second private IP address; (Par. (0029-0032, 0040-0043); entry and exit IP addresses for multiple VPN servers), (Figure 3 labels VPN connection 1-3))
the third VPN server is allocated a third private IP address; (Par. (0029-0032, 0040-0043); entry and exit IP addresses for multiple VPN servers), (Figure 3 labels VPN connection 1-3))
Funka does not explicitly teach wherein: the hierarchical-context area network includes: a first VPNI context area network (CAN) for a first VPNI context area, wherein the first VPNI CAN is a level-one VPNI CAN, wherein the first VPNI CAN includes a first control-plane VPNI CAN; a second VPNI CAN for a second VPNI context area, wherein the second VPNI CAN is a level-two VPNI CAN, wherein the second VPNI CAN includes: a data-plane VPNI CAN; and a second control-plane VPNI CAN; a third VPNI CAN for a third VPNI context area, wherein the third VPNI CAN is a level-one VPNI CAN, wherein the third VPNI CAN is allocated a shared IP address, and wherein the third VPNI CAN includes a third control-plane VPNI CAN; the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN; the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN; the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN, wherein, to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: the first VPN server sends, to the second VPN server, via the first control-plane VPNI CAN, peering request data, addressed to the shared IP address; the third VPN server receives, from the second VPN server, via the second control-plane VPNI CAN, the peering request data, wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server; the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data; and the first VPN server receives, from the second VPN server, via the first control-plane VPNI CAN, the peering response data.
Wherein Kolaitis teaches wherein: the hierarchical-context area network includes: a first VPNI context area network (CAN) for a first VPNI context area, wherein the first VPNI CAN is a level-one VPNI CAN, wherein the first VPNI CAN includes a first control-plane VPNI CAN; (Par. (0068-0071); primary, secondary and plurality of VPN servers), (Figure 5 labels 120, VPN with control plane)), (Par. (0028); CAN network))
a second VPNI CAN for a second VPNI context area, wherein the second VPNI CAN is a level-two VPNI CAN, wherein the second VPNI CAN includes: (Par. (0068-0071); secondary VPN server)), (Par. (0028); CAN network)),
a data-plane VPNI CAN; and (Figure 5 labels 120; secondary VPN with data plane and encryption device))
a second control-plane VPNI CAN; a third VPNI CAN for a third VPNI context area, wherein the third VPNI CAN is a level-one VPNI CAN, wherein the third VPNI CAN is allocated a shared IP address, and wherein the third VPNI CAN includes a third control-plane VPNI CAN; (Par. (0068-0071); primary secondary and plurality of VPN servers transmitting IP addresses), (Figure 5 label 120; third VPN server with control plane))
the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN; (Par. (0068-0071); established connection between primary and secondary VPN servers)), (Par. (0028); CAN network)),
the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN; (Par. (0068-0071); established connection between second and third VPN servers)), ((Par. (0028); CAN network)),
in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN, wherein, to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: (Par. (0068-0071) and Claim 1; connection between first VPN and third VPN servers with established connection))
the first VPN server sends, to the second VPN server, via the first control-plane VPNI CAN, peering request data, addressed to the shared IP address; (Par. (0068-0071) and Claim 1; connection between first VPN and third VPN servers and sending IP address of first VPN server to third VPN server))
the third VPN server receives, from the second VPN server, via the second control-plane VPNI CAN, the peering request data, (Par. (0068-0071) and Claim 1; connection between second VPN and third VPN servers and sending IP address of second VPN server to third VPN server))
the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data; and (Par. (0068-0071) and Claim 1; connection between second VPN and third VPN servers and forwarding requested data to VPN server 2))
the first VPN server receives, from the second VPN server, via the first control-plane VPNI CAN, the peering response data. (Par. (0068-0071); primary or first VPN receives data of secondary VPN server))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Funka to incorporate the teaching of Kolaitis to utilize the above feature because of the analogous concept of VPN servers in a network, with the motivation of safeguarding users transmitting data using VPN and virtual tunneling though IP address and packets and securely protects privacy browsing internet and from malicious users by authentication of VPN servers in various locations. (Kolaitis Par. (0004-0010))
Funka and Kolaitis do not explicitly teach the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server;
Wherein Kaciulis teaches the first VPN server determines that peer data that indicates an active VPNI peer allocated the shared IP address is absent from the first VPN server, and, (Col. 27 lines 40-67); matching first and third exit VPN to determine before request that first exit VPN does not include traffic data and targeted IP address))
wherein, prior to receiving the peering request data, peer data that identifies the first VPN server as an active VPNI peer is absent from the third VPN server; (Col. 27 lines 40-67); absent from the third server (before request identifying in third exit VPN that it does not include and is different than first and second data of exit VPN))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Funka and Kolaitis to incorporate the teaching of Kaciulis to utilize the above feature because of the analogous concept of VPN servers in a network, with the motivation of increasing security through the use of VPN and making network performance highly effective through various uses of IP address and permitting access through recognized users in the region based on the traffic. (Kaciulis Col. 2 lines 39-65))
In regards to Claim 4, the combination of Funka, Kolaitis and Kaciulis teach the system of claim 1, Kolaitis further teaches wherein to exchange the third routing data: the first VPN server obtains a first portion of the third routing data from the third VPN server; and the third VPN server obtains a second portion of the third routing data from the first VPN server. (Par. (0068-0071); first VPN accepts data from 3rd VPN server and third VPN server receives data with IP address from first))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Funka and Kaciulis to incorporate the teaching of Kolaitis for the reasons discussed in independent claim 1 stated above.
In regards to Claim 5, the combination of Funka, Kolaitis and Kaciulis teach the system of claim 1, Kolaitis further teaches wherein: the second VPN server receives, from the third VPN server, via the second control-plane VPNI CAN, first announcement data that indicates that the third VPN server is allocated the shared IP address; and (Par. (0068-0071); secondary VPN server receives data from third VPN server with IP address))
the first VPN server receives, from the second VPN server, via the first control-plane VPNI CAN, second announcement data that indicates that the second VPN server is a next hop for the shared IP address. (Par. (0068-0071); first VPN server receives data from second VPN server with corresponding IP address))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Funka and Kaciulis to incorporate the teaching of Kolaitis for the reasons discussed in independent claim 1 stated above.
In regards to Claims 8 and 11-12, claims 8 and 11-12 are method claims that recites similar limitations to claims 1 and 4-5 and the teachings of Funka, Kolaitis and Kaciulis address all the limitations discussed in claims 1 and 4-5 and are thereby rejected under the same grounds.
In regards to Claims 15 and 17-18, claims 15 and 17-18 are non-transitory computer-readable storage medium claims that recites similar limitations to claims 1 and 4-5 and the teachings of Funka, Kolaitis and Kaciulis address all the limitations discussed in claims 1 and 4-5 and are thereby rejected under the same grounds.
Claims 3 and 10, is/are rejected under 35 U.S.C. 103 as being unpatentable over Funka et al. (U.S Pub. No. 20240187380, hereinafter referred to as “Funka”), Kolaitis et al. (U.S Pub. No. 20230006972, hereinafter referred to as “Kolaitis”) and Kaciulis et al. (U.S No. 11310146, hereinafter referred to as “Kaciulis”) further in view of Hunt et al. (U.S Pub. No. 20190081930, hereinafter referred to as “Hunt”)
In regards to Claim 3, the combination of Funka, Kolaitis and Kaciulis do not explicitly teach wherein: in response to an egress reconfiguration request, the first VPN server obtains the peer data that indicates the active VPNI peer allocated the shared IP address.
Wherein Hunt teaches wherein: in response to an egress reconfiguration request, the first VPN server obtains the peer data that indicates the active VPNI peer allocated the shared IP address. (Par. (0037); egress node with changing of reconfiguration path and traveling packet through changed IP addresses))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Funka, Kolaitis and Kaciulis to incorporate the teaching of Hunt to utilize the above feature because of the analogous concept of VPN servers in a network, with the motivation of creating a higher level of security for users on VPN network and servers by using egress reconfiguration to allow nodes to identify changes and paths and route packets without concern of risk. (Hunt Par. (0004-0007))
In regards to Claims 10, claims 10 is a method claim that recites similar limitations to claim 3 and the teachings of Funka, Kolaitis, Kaciulis and Hunt address all the limitations discussed in claim 3 and are thereby rejected under the same grounds.
Allowable Subject Matter
Claims 2, 6-7, 9, 13-14, 16 and 19-20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following statement of reasons for the indication of allowable subject matter: Dependent claims 2 and 6-7 and their respective dependent claims, are allowable over the prior art of record including Funka, Kolaitis, and Kaciulis and the remaining references cited by the Examiner, since the prior art, taken individually or in combination fails to particularly disclose, fairly suggest or render obvious;
wherein: prior to establishing the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: first border gateway protocol (BGP) routing data indicating that the second VPN server is a next-hop for the shared IP address is available at the first VPN server; and second BGP routing data indicating that the third VPN server is allocated the shared IP address is available at the second VPN server; to send the peering request data the first VPN server: includes, in the peering request data, a first public cryptographic key of the first VPN server and the first private IP address; and sends the peering request data in accordance with the first BGP routing data; to send the peering response data, the third VPN server: addresses the peering response data to the first private IP address; and includes, in the peering response data, a third public cryptographic key of the third VPN server and the third private IP address; to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN: the first VPN server establishes, with the third VPN server, via the second control-plane VPNI CAN, a third BGP session between the first VPN server and the third VPN server; and the first VPN server exchanges, with the third VPN server, using the third BGP session, third routing data that includes third layer two VPN routing prefixes, as specified in claims 2, 9 and 16.
wherein: the first VPN server obtains first peering data, wherein, to obtain the first peering data the first VPN server: sends, to a hierarchical-context area network management device of the VPN system, a first request for peering data; and receives, from the hierarchical-context area network management device, responsive to the first request for peering data, the first peering data that includes the second private IP address; the second VPN server obtains second peering data, wherein to obtain the second peering data the second VPN server: sends, to the hierarchical-context area network management device, a second request for peering data; and receives, from the hierarchical-context area network management device, responsive to the second request for peering data, the second peering data that includes the first private IP address and the third private IP address; and the third VPN server obtains third peering data, wherein to obtain the third peering data the third VPN server: sends, to the hierarchical-context area network management device, a third request for peering data; and receives, from the hierarchical-context area network management device, responsive to the third request for peering data, the third peering data that
includes the second private IP address, as specified in claims 6, 13 and 19.
wherein: to establish the active peer relationship between the first VPN server and the second VPN server in the first VPNI CAN: the first VPN server and the second VPN server establish an active peer relationship in the first data-plane VPNI CAN, wherein to establish the active peer relationship in the first data-plane VPNI CAN the first VPN server and the second VPN server: establish, via the Internet, a first encrypted layered tunneling protocol VPN tunnel between the first VPN server and the second VPN server; establish, via the first encrypted layered tunneling protocol VPN tunnel, a first BGP session between the first VPN server and the second VPN server; and exchange, via the first BGP session, first routing data, that includes first layer two VPN routing prefixes, between the first VPN server and the second VPN server, wherein to exchange the first routing data: the first VPN server obtains a first portion of the first routing data from the second VPN server; and the second VPN server obtains a second portion of the first routing data from the first VPN server; and the first VPN server and the second VPN server establish an active peer relationship in the first control-plane VPNI CAN, wherein to establish the active peer relationship in the first control-plane VPNI CAN the first VPN server and the second VPN server: establish, via the first data-plane VPNI CAN, a third BGP session between the first VPN server and the second VPN server; and exchange, via the third BGP session, first layer three network prefix data, between the first VPN server and the second VPN server, wherein to exchange the first layer three network prefix data: the first VPN server obtains a first portion of the first layer three network prefix data from the second VPN server; and the second VPN server obtains a second portion of the first layer three network prefix data from the first VPN server; and to establish the active peer relationship between the second VPN server and the third VPN server in the second VPNI CAN: the second VPN server and the third VPN server establish an active peer relationship in the second data-plane VPNI CAN, wherein to establish the active peer relationship in the second data-plane VPNI CAN the second VPN server and the third VPN server: establish, via the Internet, a second encrypted layered tunneling protocol VPN tunnel between the second VPN server and the third VPN server; establish, via the second encrypted layered tunneling protocol VPN tunnel, a second BGP session between the second VPN server and the third VPN server; and exchange, via the second BGP session, second routing data, that includes second layer two VPN routing prefixes, between the second VPN server and the third VPN server, wherein to exchange the second routing data: the second VPN server obtains a first portion of the second routing data from the third VPN server; and the third VPN server obtains a second portion of the second routing data from the second VPN server; and the second VPN server and the third VPN server establish an active peer relationship in the second control-plane VPNI CAN, wherein to establish the active peer relationship in the second control-plane VPNI CAN the second VPN server and the third VPN server: establish, via the second data-plane VPNI CAN, a fourth BGP session between the second VPN server and the third VPN server; and exchange, via the fourth BGP session, second layer three network prefix data, between the second VPN server and the third VPN server, wherein to exchange the second layer three network prefix data: the first VPN server obtains a second portion of the second layer three network prefix data from the third VPN server; and the third VPN server obtains a second portion of the second layer three network prefix data from the second VPN server, as specified in claims 7, 14 and 20.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Be'ery; Tal Arieh (U.S Pub. No. 20180262498) “SYSTEM TO FILTER IMPOSSIBLE USER TRAVEL INDICATORS”. Considered this reference because it addressed shared IP addresses in a VPN network.
Ermagan; Vina (U.S Pub. No. 20170026417) “SYSTEMS, METHODS, AND DEVICES FOR SMART MAPPING AND VPN POLICY ENFORCEMENT”. Considered this application because it relates to hierarchy of VPN servers and levels of access.
Kluger; Yoav (U.S Pub. No. 20110194404) “SYSTEM AND METHOD FOR FAST PROTECTION OF DUAL-HOMED VIRTUAL PRIVATE LAN SERVICE (VPLS) SPOKES”. Considered this application because it addressed VPN networks and servers broadcasting IP address and information for verification.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN A HUSSEIN whose telephone number is (571)272-3554. The examiner can normally be reached on 7:30am-5pm.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.A.H./ Examiner, Art Unit 2497
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497