DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed 04/14/2026 has been entered. Claims 1-2, 4, 8-9, 11, 13, 15-17 and 19 has been amended. No Claims have been newly added. No Claims has been/remains canceled. Claims 1-20 remain pending in the application.
Applicant amendments to the Specifications have overcome the objections previously set forth in the Non-Final Office Action mailed on 01/15/2026. The objection has been withdrawn in view of the amended Specifications.
Applicant arguments towards to Claims have overcome the objections previously set forth in the Non-Final Office Action mailed on 01/15/2026. The objection has been withdrawn in view of the claims.
Applicant addition of the Terminal Disclaimer have overcome the Double Patenting rejection previously set forth in the Non-Final Office Action mailed on 01/15/2026. The rejection has been withdrawn in view of the Terminal Disclaimer.
Applicant amendments to the Claims have overcome the 35 U.S.C 101 rejection previously set forth in the Non-Final Office Action mailed on 01/15/2026. The rejection has been withdrawn in view of the amended Claims.
Response to Arguments
Regarding Applicant’s arguments, on page 20-31 of the remark filed on 04/14/2026, on the limitations of independent claim 1: “hierarchal-context area network, 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, 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.”, arguments are not persuasive.
Applicant argues on Page 23 that the cited references fail to teach a hierarchal-context area network. Applicant’s interpretation of the reference has been noted; however, examiner respectfully disagrees. Funka teaches on Par. (0011) hierarchical-context area network as a VPNI network with levels of a default VPN with other respective VPN servers.
Applicant argues on Page 23 that the cited references fail to teach the first VPN server is allocated a first private IP address; the second VPN server is allocated a second private IP address. Applicant’s interpretation of the reference has been noted; however, examiner respectfully disagrees. Funka teaches on Figure 1 label 120 a first second and third VPN server and on Par. (0029-0032 and 0040-0043) a first VPN server with each IP address designated for that VPN server with exit and entry IP addresses. Kolaitis then discloses on Par. (0068-0071) a primary and secondary VPN server and on Figure 5 label 120 a control plane and Par. (0028) describing a CAN network. Examiner equates the level-one VPNI CAN as a primary VPN server and level-two as a secondary VPN server in CAN network.
Applicant argues on page 24 that the cited references fail to teach 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 second VPNI [context area network]," as recited by revised independent claim 1. The Office appears to have improperly given no weight to "level-two” and a data-plane VPNI CAN. Applicant’s interpretation of the reference has been noted; however, examiner respectfully disagrees. Kolaitis teaches on Par. (0068-0071) and Figure 5 label 120 a VPN server with a control plane and second VPN server with a level two VPNi being associated with the primary and secondary levels of VPN server. Kolaitis further teaches son Par. (0028) a CAN network.
Applicant further argues on page 25 that the cited references fail to teach 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. Examiner states on Par. (0068-0071) and Figure 5 label 120 a third VPNi server with a control plane and transmitting of IP addresses. Kolaitis teaches on Par. (0028-0029) the sharing of network resources and IP addresses between VPN servers.
Applicant further argues on page 25 that the cited references fail to teach the first VPN server and the second VPN server are active VPNI peers in the first VPNI CAN. Examiner states that Kolaitis teaches on Par. (0068-0071) an active or established connection between primary and secondary VPN servers and on Par. (0028) being a CAN network.
Applicant further argues on page 26 that the cited references fail to teach the second VPN server and the third VPN server are active VPNI peers in the second VPNI CAN, Examiner states that Kolaitis teaches on Par. (0068-0071) an active or established connection between secondary and a third VPN server and on Par. (0028) being a CAN network.
Applicant further argues on page 26 that the cited references fail to 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, in response, establishes an active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN. Examiner states that Kaciulis teaches on Col. 27 lines 40-67a matching of a first and third exit VPN to determine that the exit VPN does not include traffic data and targeted IP addresses. Kaciulis teaches a shared IP address on Col. 9 lines 25-50 describing IP addresses being assigned and only within the group of VPN servers can the same private IP address be used. Kaciulis teaches on Par. (0068-0071) a connection between first VPN server and third VPN server as active established connections.
Applicant further argues on page 26 last paragraph and 27 first paragraph that the cited references fail to 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. Examiner states that Kaciulis teach on Par. (0068-0071)the matching is between the first and third exit VPN prior to receiving a request identifies that the active VPN server and IP address is absent or not includes based off matching.
Applicant further argues on page 27 that the cited references fail to teach 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. Examiner states Kolaitis teaches on Par. (0068-0071) and Claim 1 a connection between first VPN and third VPN servers with established active connection and sending IP addresses from fist VPN server to third VPN server.
Applicant further argues on page 28 that the cited references fail to teach sending Ip address of a second VPN server to a third VPN server. Examiner states Kolaitis on Par. (0068-0071) a first VPN and third VPN servers with established active connection and sending IP addresses from fist VPN server to third VPN server.
Applicant further argues on page 28 that the cited references fail to 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. Examiner states that Kolaitisteaches on Par. (0068-0071) the matching is between the first and third exit VPN prior to receiving a request identifies that the active VPN server and IP address is absent or not includes based off matching.
Applicant further argues on page 29 that the cited references fail to teach to establish the active peer relationship between the first VPN server and the third VPN server in the data-plane VPNI CAN:... the third VPN server sends, to the second VPN server, via the second control-plane VPNI CAN, peering response data. Examiner states Kolaitis teach on Par. (0068-0071) and Claim 1 a connection between second VPN and third VPN servers and forwarding requested data to VPN server 2 and receiving response or forwarded data associated with request. Applicant argues on page 29 the basis for “requested data”. Examiner states that the data forwarded and received after request for data is performed by Kolaitis on Par. (0068-0071) is response data or data received as a response to request sent.
Applicant argues on page 29 that the Office has ignored the recited logical sequence of claim elements. Applicant’s interpretation of the reference has been noted; however, examiner respectfully disagrees. Funka, Kolaitis and Kaciulis teach the recited steps in order and are analogous because of the concept of VPI networks and transfer of data. Therefore, the rejection is maintained.
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, 5, 8, 12, 15 and 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 comprising at least one hardware processor and a non-transitory computer-readable storage medium storing executable instructions that, when executed by the at least one hardware processor, cause the VPNI system to perform operations including 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), (Par. (0012-0013); processor, computer readable medium and memory)
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 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 12, claims 8 and 12 are method claims that recites similar limitations to claims 1 and 5 and the teachings of Funka, Kolaitis and Kaciulis address all the limitations discussed in claims 1 and 5 and are thereby rejected under the same grounds.
In regards to Claims 15 and 18, claims 15 and 18 are non-transitory computer-readable storage medium claims that recites similar limitations to claims 1 and 5 and the teachings of Funka, Kolaitis and Kaciulis address all the limitations discussed in claims 1 and 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, 4 6-7, 9, 11, 13-14, 16, 17 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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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-y.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
Prosecution Insights