Office Action Predictor
Last updated: April 16, 2026
Application No. 18/705,062

SYSTEM AND METHODS FOR ROUTING INTERNET PROTOCOL, IP, TRAFFIC

Non-Final OA §102§103
Filed
Apr 26, 2024
Examiner
JOHNSON, AMY COHEN
Art Unit
2400
Tech Center
2400 — Computer Networks
Assignee
Vodafone Ip Licensing Limited
OA Round
1 (Non-Final)
57%
Grant Probability
Moderate
1-2
OA Rounds
2y 6m
To Grant
59%
With Interview

Examiner Intelligence

Grants 57% of resolved cases
57%
Career Allow Rate
282 granted / 497 resolved
-1.3% vs TC avg
Minimal +2% lift
Without
With
+2.5%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
356 currently pending
Career history
853
Total Applications
across all art units

Statute-Specific Performance

§101
3.8%
-36.2% vs TC avg
§103
55.6%
+15.6% vs TC avg
§102
21.3%
-18.7% vs TC avg
§112
11.5%
-28.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 497 resolved cases

Office Action

§102 §103
DETAILED ACTION The present application is being examined under the AIA first to file provisions. This action is responsive to communication filed 4/26/2024, claims 1 – 15 are pending for examination. This action is non-final. Information Disclosure Statement The Information Disclosure Statement dated 4/26/2024 is herein reviewed by the Examiner. The aforementioned IDS has incorrect Patent Publication numbers for the two US cited PG PUB references. Examiner indicates that the corrected inventors and publication numbers are, respectively: Sullenberger et al. (US 2019/0372936 A1) and Xiong et al. (US 2020/0351254 A1). Allowable Subject Matter Claim 12 is not found to be taught or suggested by the prior art of record and therefore comprises allowable subject matter which if rewritten into independent form to comprise all subject matter of respective parent claims would be in condition for allowance. However, as respective parent claims are rejected herein, claim 12 is herein objected to. Dependent claim 13 inherits all objections of respective parent claim 12. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1, 3 – 8, 11, 14, and 15 are rejected under 35 U.S.C. §102(a)(1) as being anticipated by Sullenberger et al. (US 2019/0372936 A1), hereinafter “Sullenberger”. Regarding claim 1, Sullenberger teaches a system for routing internet protocol, IP, traffic (Sullenberger ¶ 0014-0018, 0040, 0047), the system comprising: one or more consumer networks (e.g., Wide Area Network (WAN)), each consumer network comprising a gateway (Virtual Private Network (VPN) Gateway) and one or more private networks (e.g. VPNs, LANs, LAN subnets, etc.…), wherein each of the one or more private networks serves one or more endpoints (client devices connected to LANs communicate in end-to-end fashion Sullenberger ¶ 0038-0040); and a remote network comprising a router for each of the one or more private networks in each of the one or more consumer networks (e.g., method 200 is described in the context of encryption tunneling of traffic between a source VPN gateway that serves a source subnet (e.g., any of VPN gateways 102A that serve any of LANs 104A ) that originates the traffic and a destination VPN gateway that serves a destination subnet (e.g., any of VPN gateways 102B that serve any of LANs 104B) to which the traffic is destined Sullenberger ¶ 0047, effectively, each respective VPN gateway functions as a router for its associated VPN; wherein “LANs 106A may be segmented such that each LAN represents a respective LAN subnet (also referred to simply a “local network subnet,” a “local subnet,” or simply a “subnet”) identified by a respective IP address prefix (referred to as a “subnet identifier”). VPN gateways 102A provide LANs 106A with access to WANs 104 through the VPN gateways. Similarly, VPN gateways 102B serve/support LANs 106B(1) and 106B(2) (collectively referred to as LANs 106B) coupled to the VPN gateways as shown in FIG. 1. LANs 106B may be segmented such that each LAN represents a respective LAN subnet identified by a respective IP address prefix.” Sullenberger ¶ 0040), wherein each router in the remote network has a unique identifier (e.g., subnet identifier) and is configured to establish a tunnel between the router and the gateway of the corresponding consumer network, so that each tunnel corresponds to a private network of the one or more private networks in the one or more consumer networks (encrypting traffic between VPNs (e.g., tunnel-based communications) Sullenberger ¶ 0047; “source subnet identifier” of respective VPNs and VPN gateways Sullenberger ¶ 0047, 0056-0059) , wherein the gateway of each consumer network is configured to: receive upstream IP traffic (VPN gateway receives traffic from its respective source subnet Sullenberger ¶ 0047; further “VPN gateway receives a clear-text IP packet originated from a source subnet among the source subnets supported by the source VPN gateway and destined for a destination subnet supported by the destination VPN gateway” Sullenberger ¶ 0050); determine from which private network in the consumer network the upstream IP traffic originates (“encryption tunneling of traffic between a source VPN gateway that serves a source subnet (e.g., any of VPN gateways 102A that serve any of LANs 104A) that originates the traffic and a destination VPN gateway that serves a destination subnet (e.g., any of VPN gateways 102B that serve any of LANs 104B) to which the traffic is destined” Sullenberger ¶ 0047); and send the upstream IP traffic to the remote network via the tunnel corresponding to the private network from which the upstream IP traffic originates (tunneling from the source VPN gateway to the destination VPN gateway associated with the destination IP address Sullenberger ¶ 0049-0051). Regarding claim 3, Sullenberger teaches the system of claim 1, wherein the remote network further comprises a destination server, and wherein each router is configured to communicate IP traffic with the destination server (destination within a subnet is an IP-addressed node Sullenberger ¶ 0050-0051, 0040). Regarding claim 4, Sullenberger teaches a method performed by the gateway of a consumer network of the one or more consumer networks, in the system of claim 1, wherein the consumer network comprises a plurality of private networks, wherein a private routing table is used within the consumer network the method comprising: receiving a plurality of requests to establish a tunnel, so that each router can establish the tunnel between the router and the gateway of the consumer network; and/or sending upstream IP traffic to the remote network via the tunnel corresponding to the private network from which the upstream IP traffic originates (tunneling from the source VPN gateway to the destination VPN gateway associated with the destination IP address Sullenberger ¶ 0049-0051; wherein a secure database comprises the source and destination IP addresses for respective subnets Sullenberger ¶ 0051-0053). Regarding claim 5, Sullenberger teaches the method of claim 4, further comprising: receiving upstream IP traffic from the first endpoint (VPN gateway receives traffic from its respective source subnet Sullenberger ¶ 0047; further “VPN gateway receives a clear-text IP packet originated from a source subnet among the source subnets supported by the source VPN gateway and destined for a destination subnet supported by the destination VPN gateway” Sullenberger ¶ 0050); and determining that the upstream IP traffic is received via the first private network (“encryption tunneling of traffic between a source VPN gateway that serves a source subnet (e.g., any of VPN gateways 102A that serve any of LANs 104A) that originates the traffic and a destination VPN gateway that serves a destination subnet (e.g., any of VPN gateways 102B that serve any of LANs 104B) to which the traffic is destined” Sullenberger ¶ 0047). Regarding claim 6, Sullenberger teaches the method of claim 4, further comprising: receiving, at the gateway of the consumer network via one or more tunnels, downstream IP traffic destined for one or more endpoints served by the one or more private networks (receiving a message to send traffic to a destination VPN, at a current VPN gateway Sullenberger ¶ 0050-0056; wherein IP traffic is send between endpoints of respective VPNs Sullenberger ¶ 0040); sending the downstream IP traffic from the gateway of the consumer network via the corresponding private network of the consumer network (receiving an encrypted tunnel packet at the destination VPN Sullenberger ¶ 0072-0073; encrypting based upon the respective tunnel and sending the encrypted data packet Sullenberger ¶ 0074-00). Regarding claim 7, Sullenberger teaches the method of claims 4, wherein each of the one or more private networks of the consumer network has a unique network identifier (e.g., subnet identifier, VPN subnet identifier Sullenberger ¶ 0040, 0041), and wherein the private network to which IP traffic relates is determined based on a unique network identifier associated with the IP traffic (e.g., based on upon the destination subnet identifier Sullenberger ¶ 0041-0043). Regarding claim 8, Sullenberger teaches a method of managing internet protocol, IP, traffic between the one or more consumer networks and the remote network in the system of claim 1, the method comprising: for each router, establishing the tunnel between the router and the gateway of the corresponding consumer network (encrypting traffic between VPNs (e.g., tunnel-based communications) Sullenberger ¶ 0047; “source subnet identifier” of respective VPNs and VPN gateways Sullenberger ¶ 0047, 0056-0059); and/or receiving, at one or more of the routers, upstream IP traffic from one or more of the endpoints served by the private network corresponding to the router via the corresponding tunnel. Regarding claim 11, Sullenberger teaches the method of claims 8, wherein the remote network further comprises a destination server, the method further comprising: at each router where upstream IP traffic is received, sending translated upstream IP traffic to the destination server (receiving an encrypted tunnel packet at the destination VPN Sullenberger ¶ 0072-0073; encrypting (e.g., translating) based upon the respective tunnel and sending the encrypted data packet Sullenberger ¶ 0074-00). Regarding claim 14, Sullenberger teaches the method of claim 8, wherein: the gateway of one or more of the consumer networks is a virtual gateway (Sullenberger ¶ 0095-0096, 0039); the remote network further comprises a gateway and the gateway of the remote network is a virtual gateway; each router is a virtual router; each router is a virtual router implemented in a separate virtualized container; and/or the remote network further comprises a destination server and the destination server is a virtual destination server. Regarding claim 15, Sullenberger teaches a computer program comprising instructions that, when executed by a processor, cause the processor to perform the method of claim 8 (see above regarding claim 8, see Sullenberger ¶ 0083-0084 regarding “a computer program comprising instructions that, when executed by a processor, cause the processor to perform”). Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 2, 9, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sullenberger in view of Liguori et al. (US 2021/0089239 A1), hereinafter “Liguori”. Regarding claim 2, where Sullenberger teaches the system of claim 1, wherein a range of one or more IP addresses is allocated to each router, and wherein each router is configured to perform network address translation, NAT, on the IP traffic so that an IP address of each of the one or more endpoints served by the corresponding private network is translated to an IP address within the range of IP addresses allocated to the router, wherein each range of IP addresses allocated to each router is non- overlapping with the ranges of IP addresses allocated to the other routers. However, Liguori teaches wherein a range of one or more IP addresses is allocated to each router, and wherein each router is configured to perform network address translation, NAT, on the IP traffic (virtual/hardware network instances perform ‘address translation’ Liguori ¶ 0036-0037 of IP traffic Liguori ¶ 0053) so that an IP address of each of the one or more endpoints served by the corresponding private network is translated to an IP address within the range of IP addresses allocated to the router, wherein each range of IP addresses allocated to each router is non-overlapping with the ranges of IP addresses allocated to the other routers (“re-assignment of the network addresses (e.g., assigning addresses from respective non-overlapping IP address ranges at the different premises), and/or implementing a bi-directional network address translation (NAT) algorithm… VCS may provide more detailed guidance (e.g., suggesting new non-overlapping ranges of IP addresses, instructions for establishing a virtual router or hub for NAT, etc.) to the client to make the needed configuration changes (element 1613)” Liguori ¶ 0135). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take the teachings of Liguori related to having unique address ranges for subnets and further performing translation at different subnets and apply them to the teachings of Sullenberger for the purpose of yielding the predictable result of providing application isolation and security among different computing instances. One would be motivated as such as this allows for separate networks to have their own private security, and therefore may be specifically based on the users of that network. Regarding claim 9, where Sullenberger teaches the method of claim 8, Sullenberger is not found to teach for each router, allocating a range of one or more IP addresses, wherein each range of IP addresses allocated to each router is non-overlapping with the ranges of IP addresses allocated to the other routers; and at each router where upstream IP traffic is received, performing network address translation, NAT, on the received upstream IP traffic, so that a source IP address of upstream IP traffic is translated to an IP address within the allocated range of the router. However, in analogous art, Liguori teaches for each router [of a subnetwork], allocating a range of one or more IP addresses, wherein each range of IP addresses allocated to each router is non-overlapping with the ranges of IP addresses allocated to the other routers (“re-assignment of the network addresses (e.g., assigning addresses from respective non-overlapping IP address ranges at the different premises), and/or implementing a bi-directional network address translation (NAT) algorithm… VCS may provide more detailed guidance (e.g., suggesting new non-overlapping ranges of IP addresses, instructions for establishing a virtual router or hub for NAT, etc.) to the client to make the needed configuration changes (element 1613)” Liguori ¶ 0135); and at each router where upstream IP traffic is received, performing network address translation, NAT, on the received upstream IP traffic, so that a source IP address of upstream IP traffic is translated to an IP address within the allocated range of the router (virtual/hardware network instances perform ‘address translation’ Liguori ¶ 0036-0037 of IP traffic Liguori ¶ 0053). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take the teachings of Liguori related to having unique address ranges for subnets and further performing translation at different subnets and apply them to the teachings of Sullenberger for the purpose of yielding the predictable result of providing application isolation and security among different computing instances. One would be motivated as such as this allows for separate networks to have their own private security, and therefore may be specifically based on the users of that network. Regarding claim 10, where Sullenberger teaches the method of claim 8, further comprising: receiving, at one or more of the routers of the remote network, downstream IP traffic destined for one or more of the one or more endpoints served by the corresponding private network (VPN gateway receives traffic from its respective source subnet Sullenberger ¶ 0047; further “VPN gateway receives a clear-text IP packet originated from a source subnet among the source subnets supported by the source VPN gateway and destined for a destination subnet supported by the destination VPN gateway” Sullenberger ¶ 0050) and sending translated downstream IP traffic to a gateway of a corresponding consumer network via the corresponding tunnel (receiving an encrypted tunnel packet at the destination VPN Sullenberger ¶ 0072-0073; encrypting (e.g., translating) based upon the respective tunnel and sending the encrypted data packet Sullenberger ¶ 0074-00), Sullenberger is not found to teach at each router where downstream IP traffic is received, performing network address translation, NAT, on the received downstream IP traffic and at each router where downstream IP traffic is received, sending translated downstream IP traffic to the gateway of the corresponding consumer network via the corresponding tunnel. However, in analogous art, Liguori teaches at each router where downstream IP traffic is received, performing network address translation, NAT, on the received downstream IP traffic and at each router where downstream IP traffic is received (“re-assignment of the network addresses (e.g., assigning addresses from respective non-overlapping IP address ranges at the different premises), and/or implementing a bi-directional network address translation (NAT) algorithm… VCS may provide more detailed guidance (e.g., suggesting new non-overlapping ranges of IP addresses, instructions for establishing a virtual router or hub for NAT, etc.) to the client to make the needed configuration changes (element 1613)” Liguori ¶ 0135; virtual/hardware network instances perform ‘address translation’ Liguori ¶ 0036-0037 of IP traffic Liguori ¶ 0053). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take the teachings of Liguori related to having unique address ranges for subnets and further performing translation at different subnets and apply them to the teachings of Sullenberger for the purpose of yielding the predictable result of providing application isolation and security among different computing instances. One would be motivated as such as this allows for separate networks to have their own private security, and therefore may be specifically based on the users of that network. Conclusion Cheng et al. (US 2017/0353351 A1) directed network IP traffic directing through separate VPCs based on public/private addresses and Haramaty et al. (US 2021/0176190 A1) directed to providing redundant connectivity to remote customer sites are prior art references found pertinent to Applicant’s claimed invention but were not used in making the rejections presented herein. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIHAD KAMAL BOUSTANY whose telephone number is (571)270-0251. The examiner can normally be reached M-F: 8:30 AM - 5:00 PM. 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, Glenton Burgess can be reached at (571) 272-3949. 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. /J.K.B/ Examiner, Art Unit 2454 /GLENTON B BURGESS/ Supervisory Patent Examiner, Art Unit 2454
Read full office action

Prosecution Timeline

Apr 26, 2024
Application Filed
Sep 24, 2025
Non-Final Rejection — §102, §103
Mar 27, 2026
Response Filed

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12381794
METHOD AND SYSTEM FOR PERFORMING AD HOC DIAGNOSTICS, MAINTENANCE, PROGRAMMING, AND TESTS OF INTERNET OF THINGS DEVICES
2y 5m to grant Granted Aug 05, 2025
Patent 12381816
POLICY PLANE INTEGRATION ACROSS MULTIPLE DOMAINS
2y 5m to grant Granted Aug 05, 2025
Patent 12363582
METHOD FOR MANAGING QOS, RELAY TERMINAL, PCF NETWORK ELEMENT, SMF NETWORK ELEMENT, AND REMOTE TERMINAL
2y 5m to grant Granted Jul 15, 2025
Patent 12363588
DATA TRANSMISSION METHOD AND APPARATUS, COMPUTER READABLE MEDIUM, AND ELECTRONIC DEVICE
2y 5m to grant Granted Jul 15, 2025
Patent 12363337
CODING AND DECODING OF VIDEO CODING MODES
2y 5m to grant Granted Jul 15, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
57%
Grant Probability
59%
With Interview (+2.5%)
2y 6m
Median Time to Grant
Low
PTA Risk
Based on 497 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month