DETAILED ACTION
This Action is in response to the Amendment for Application Number 18788688 received on 5/04/2026.
Claims 1-17, and 21-23 are presented for examination.
Claims 18-20 have been cancelled.
The effective filing date for this application is 4/08/2024.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 23 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 23 recites the limitations, “wherein a first NAT method is associated with a first DIA path and a second NAT method is associated with a second DIA path, and wherein the selected NAT method corresponds to the selected available DIA path.” The scope of these limitations is unclear in relation to the limitations of claim 1. Claim 23 generically describes "a first NAT method" and "a second NAT method", but these elements have no functional relationship with the limitations of claim 1, as there is no recited functional interconnection. The scope is unclear as to whether or not these recited “first” and “second” NAT methods have any relevance to the claimed selecting of the NAT method of claim 1. For examination purposes, the limitations of claim 23 will be interpreted to functionally relate to the selection process of claim 21.
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.
Claim(s) 1, 3-5, 7-8, 10-12, 15, 17-19, and 21-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Cisco SD-WAN (Cisco SD-WAN: Enabling Direct Internet Access, August 2020 – See IDS submitted 7/19/2024, Cite No. 1).
Regarding claim 1, Cisco SD-WAN disclosed a method for managing traffic in a software-defined wide area network (SD-WAN) controller, comprising:
receiving a policy at an edge network device in an SD-WAN from an SD-WAN controller, the policy specifying a network address translation method (NAT method) for direct Internet access action (DIA action), and includes one or more configurations for selection of the NAT method (Cisco SD-WAN, p6, “deploy Direct Internet Access within the Cisco SD-WAN”, “SD-WAN controllers are set up and deployed”; p12, “deploying centralized data policies or a NAT DIA route to leak Internet traffic from the service-side VPN (VPNs 0-511,513-65530)) into the Internet transport VPN (VPN 0) which allows traffic to exit directly to the Internet through the NAT-enabled interface in VPN 0”; See also Section: Network Address Translation, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels”; p14, “WAN edge devices learn the policy and then execute them in memory. As a result, all configurations are backed up in vManage configuration database”; See the rest of p14, specifying the policy in use, routing traffic to a specific DIA interface by setting a path preference by using a traffic policy within the centralized policy. Such policies are configured on the vSmart controller and set two actions – VPN NAT and local-TLOC color”; p15, “One of the three types of NAT routes include NAT DIA route” in which, “you can direct local Internet traffic to exit directly to the Internet cloud from the service-side VPN, through the next hop transport VPN, VPN 0”; p 32 “Deploy the Device Template”, “vManage attaches the configurations based on the feature templates and pushes the configuration to the devices”; Cisco SD-WAN therefore disclosed an edge network device receiving a policy (deploy) in an SD-WAN from an SD-WAN controller, the policy including a NAT-DIA policy allowing the edge network device to select the NAT method for particular traffic to route such traffic directly to the Internet; See also p25-26 Internet traffic flow using DIA route or data policy and Figure 27 Path preference for Internet traffic);
receiving, at the edge network device, data traffic, wherein the data traffic is matched with the one or more configurations in the policy to identify the NAT method that supports the data traffic received (Cisco SD-WAN, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels”; p14, “WAN edge devices learn the policy and then execute them in memory.”; p16 “Option 1: “DIA using NAT DIA Route” and “Option 2 DIA using Centralized Policy” involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and “Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. Only traffic destined for the public network passes from the service-side VPN to VPN 0”; See Figure 12; the WAN edge device executing the policy for such traffic amounts to following the policy for the traffic received; See also p25-26 Internet traffic flow using DIA route or data policy and Figure 27 Path preference for Internet traffic);
selecting the NAT method based on the data traffic matching a respective configuration of the one or more configurations in the policy (p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels”; p14, “WAN edge devices learn the policy and then execute them in memory.”; p16 “Option 1: “DIA using NAT DIA Route” and “Option 2 DIA using Centralized Policy” involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and “Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. Only traffic destined for the public network passes from the service-side VPN to VPN 0”; See Figure 12);
selecting an available DIA path that corresponds to the respective configuration (Cisco SD-WAN, p17, Cisco SD-WAN disclosed the ability to configure “System Tracker to track the status of the transport interface that connects to the Internet, which is useful when NAT is enabled on a transport interface in VPN 0 to allow data traffic from the router to exit directly to the Internet. With tracking enabled, the router periodically probes the path to the Internet and when the path is functioning, the router utilizes the NAT route to the Internet);
selecting an IP address that is consistent with the NAT method specified by the policy to apply to the data traffic (Cisco SD-WAN, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet.”); and
routing the data traffic along the available DIA path based on the one or more configurations and the IP address applied during the NAT method in accordance with the policy (Cisco SD-WAN, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet”; p17 System Tracker - With tracking enabled, the router periodically probes the path to the Internet and when the path is functioning, the router utilizes the NAT route to the Internet ).
Claim 8 recites a network device comprising one or more memories having computer-readable instructions stored therein; and one or more processors configured to execute the computer-readable instructions to perform limitations that are substantially similar to the limitations of claim 1.
Claim 15 recites a non-transitory computer-readable storage medium comprising computer-readable instructions, which when executed by one or more processors of a network appliance, cause the network appliance to perform limitations that are substantially similar to the limitations of claim 1.
Cisco SD-WAN disclosed a network device comprising processor and memory/non-transitory computer readable medium storing instructions (Cisco SD-WAN, p6, Cisco SD-WAN disclosed the implementation including Cisco ISR 4331, ISR4351, and vEdge1000 routers, all of which are hardware routers that include memory/medium and processors).
Claims 8 and 15 are therefore rejected under the same rationale applied above.
Regarding claims 3, 10, and 17, Cisco SD-WAN disclosed the method, device, and medium of claims 1, 8, and 15, wherein the NAT method is selected based on an indication in the policy and the available DIA path (Cisco SD-WAN, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels”; p14, “WAN edge devices learn the policy and then execute them in memory.”; p16 “Option 1: “DIA using NAT DIA Route” and “Option 2 DIA using Centralized Policy” involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and “Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. Only traffic destined for the public network passes from the service-side VPN to VPN 0”; See Figure 12; p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet”; p17 System Tracker - With tracking enabled, the router periodically probes the path to the Internet and when the path is functioning, the router utilizes the NAT route to the Internet) for an application type associated with an application (p8, Cisco SD-WAN disclosed filtering “for application type traffic such as internet traffic, such that “Internet traffic uses the directly connected Internet transport for direct Internet access, while the rest of the Internal traffic exits via the MPLS or INET tunnel to the destination”; While mapped, it is noted that the limitation “for an application type associated with an application” merely describes what the selection is “for”, and therefore amounts to a limitation of intended use which does not further limit the claim).
Regarding claims 4, and 11, Cisco SD-WAN disclosed the method, device, and medium of claims 1, 8, and 15, wherein: the policy is configured by an administrator of the SD-WAN at a central management platform, the policy specifying the NAT method for the DIA action; and the policy is pushed from the central management platform to the SD-WAN controller to disseminate the policy to one or more edge network devices in the SD-WAN (Cisco SD-WAN, p14, “Centralized policies are built using vManage, and then stored in its database. They are then sent via NETCONF to the vSmart
controller to become a part of vSmart configurations. The vSmart controller then uses OMP to send the policy parameters as updates in the routing protocol to all of the WAN edge devices. WAN edge devices learn the policy and then execute them in memory. As a result, all configurations are backed up in vManage configuration database.”; See p30-55+ which provides a guide for administrator to configure/deploy policies using vManagem, For example, p42 provides Cisco SD-WAN Directed Internet Access Fongiruation for configuring centralized data policies, which are then provisioned on a vSMART controller and pushed to WAN Edge routers).
Regarding claims 5, and 12, Cisco SD-WAN disclosed the method, device, and medium of claims 1, 8, and 15, wherein each NAT method is associated with one or more WAN interfaces of an SD-WAN network topology (Cisco SD-WAN, p13, “For DIA, as shown above in the figure, NAT overload can be configured on the physical Internet transport interfaces connecting to the Internet Service Provider’s network; See page 15 NAT DIA Route and How NAT DIA Routes Work – enabling NAT on “Internet facing interface”; See also p20, NAT enabled interface; See also p24-25, Fig. 25 NAT enabled interfaces, and at the very bottom of p26 “two or more NAT interfaces).
Regarding claim 7, Cisco SD-WAN disclosed the method of claim 1, further comprising: determining from the data traffic received from one or more edge network devices in the SD-WAN that the data traffic originated from a first edge network device associated with specific source IP addresses; and assigning one or more IP addresses to the data traffic based on the first edge network device the data traffic originated from (Cisco SD-WAN, p15-16, Figs 11-12, Cisco SD-WAN disclosed traffic is routed to a NAT-enabled WAN transport VPN (VPN 0) from the service-side VPN (VPN 2) based on the destination prefix in the NAT DIA route. Then, the source IP address of the packet is translated to the interface IP address using NAT and forwarded to the destination prefix; Traffic received at VPN0 is determined to be received from VPN2 which is associated with specific source IP addresses of the internet traffic on the LAN side, and the source IP address is translated according to NAT).
Regarding claim 21, Cisco SD-WAN disclosed the method of claim 1, wherein the one or more configurations specify a plurality of NAT methods, and wherein selecting the NAT method comprises selecting one NAT method from the plurality of NAT methods based on the data traffic matching the respective configuration (Cisco SD-WAN, p 44, Cisco SD-WAN disclosed the centralized data policy configured to filter traffic based on a prefix list such as a source data prefix list, to which all traffic entering is filtered based on the source data prefix configured within the policy match statement, and routed to the transport-side interface, VPN 0 as one example, to which groups of interest may include a VPN list, to which the VPN list can be specified on page 50; Page 45 shows the ability to add data prefixes; Cisco SD-WAN, p13, “For DIA, as shown above in the figure, NAT overload can be configured on the physical Internet transport interfaces connecting to the Internet Service Provider’s network; See page 15 NAT DIA Route and How NAT DIA Routes Work – enabling NAT on “Internet facing interface”; See also p20, NAT enabled interface; See also p24-25, Fig. 25 NAT enabled interfaces, and at the very bottom of p26 “two or more NAT interfaces”; p18 shows Single router dual internet design models in which allow for Internet failover to a secondary Internet link in the event of primary Internet link failure; See also Figure 31, “Path preference for internet traffic” and the rest of p29 explaining path preference and availability; Cisco SD-WAN therefore provides the ability to configure source data prefixes to comprise multiple NAT methods based on DIA path preference and an availability of the DIA path preference).
Regarding claim 22, Cisco SD-WAN disclosed the method of claim 1, wherein selecting the IP address comprises selecting, based on the selected NAT method, an IP address from a NAT pool or a WAN interface IP address associated with the selected NAT method (Cisco SD-WAN, p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels”; p14, “WAN edge devices learn the policy and then execute them in memory.”; p16 “Option 1: “DIA using NAT DIA Route” and “Option 2 DIA using Centralized Policy” involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and “Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. Only traffic destined for the public network passes from the service-side VPN to VPN 0”; See Figure 12; p13, “The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet”; p17 System Tracker - With tracking enabled, the router periodically probes the path to the Internet and when the path is functioning, the router utilizes the NAT route to the Internet).
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, 6, 9, 13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cisco SD-WAN (Cisco SD-WAN: Enabling Direct Internet Access, August 2020 – From IDS submitted 7/19/2024, Cite No. 1) in view of Yang et al. (US 20220377043).
Regarding claims 2, 9, and 16, Cisco SD-WAN disclosed the method, device, and medium of claims 1, 8, and 15, including receiving, at the edge network device, the data traffic associated with a source data prefix, wherein the data traffic is matched with an source data prefix supported by the policy associated with the NAT method; selecting the NAT method based on the source data prefix matching the respective configuration of the one or more configurations in the policy; and selecting the IP address that is consistent with the NAT method associated with the source data prefix as specified by the policy (Cisco SD-WAN, p 44, Cisco SD-WAN disclosed the centralized data policy configured to filter traffic based on a prefix list such as a source data prefix list, to which all traffic entering is filtered based on the source data prefix configured within the policy match statement, and routed to the transport-side interface, VPN 0 as one example, to which groups of interest may include a VPN list, to which the VPN list can be specified on page 50; Page 45 shows the ability to add data prefixes; See p13, with respect to NAT, the source IP address of internal traffic destined for the Internet is translated to the interface IP address).
While Cisco SD-WAN disclosed filtering according to source data prefix, Cisco SD-WAN did not explicitly disclose filtering according to application type, as claimed.
However, Applicant’s Specification recites the determining of Application type according to “predefined criteria” (Applicant’s Spec, [0049], and Applicant’s Figure 3 disclosed a specific detail as to what “predefined criteria” includes. Applicant’s Figure 3 recites, “Policy classifies Application O365 traffic, selects NAT Pool Method based on chosen WAN 1 or 2 Link”. As “O365” is the source data prefix related to Microsoft 365 traffic, it is evident that Applicant intends the use of “source data prefixes” as “predefined criteria” in order to match data traffic to an application type supported by the policy.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed, to utilize Cisco SD-WAN’s explicitly disclosed filtering according to source data prefix, in order to be able to filter traffic by application type thereby allowing Cisco SD-WAN thereby achieving Cisco SD-WAN’s suggestion of being able to filter employee traffic such that Internet traffic uses the directly connected Internet transport for direct Internet access, while the rest of the Internal traffic exits via the MPLS or INET tunnel to the destination (Cisco SD-WAN, p8).
Regardless, in an analogous art, Yang disclosed wherein the selection of the NAT method includes:
receiving, at the edge network device, the data traffic associated with an application, wherein the data traffic is matched with an application type supported by the policy associated with the NAT method (Yang, [0095]-[0096], Yang disclosed for User initiated UL traffic, matching the traffic towards a specific service APN, creating a UL PDR (Packet Detection Rule) with application ID to match the traffic from the UE towards a specific network instance dedicated to the service APN);
selecting the NAT method based on the application type matching the respective configuration of the one or more configurations in the policy (Yang, [0068], Yang disclosed NAT policies with different granularity; [0097]-[0099] replacing source IP address to the NAT IP address is a selection of the NAT method based on the application type matching the respective configuration); and
selecting the IP address that is consistent with the NAT method associated with the application type as specified by the policy (Yang, [0097]-[0099] replacing source IP address to the NAT IP address).
One of ordinary skill in the art would have been motivated to combine the teachings of Cisco SD-WAN and Yang as they both relate to utilization of NAT methods for routing of particular traffic, and as such, they are within similar environments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the utilization of application type as the means for making NAT routing decisions according to policy, as disclosed by Yang, within the teachings of Cisco SD-WAN in order to benefit of allowing the network operator to support NAT policies with different granularity (Yang, [0068]), thereby making the system more desirable to use by its customers.
Regarding claims 6, and 13, Cisco SD-WAN disclosed the method, device, and medium of claims 1, 8, and 15, including wherein the policy includes criteria for matching one or more applications (Cisco SD-WAN, p8, “As shown in the figure, branch (remote-site} employees are allowed direct access to the Internet for cloud-based applications and user web access. This is achieved by configuring the WAN edge routers as an Internet exit point. Designated employee Internet traffic uses the directly connected Internet transport for direct Internet access, while the rest of the Internal traffic exits via the MPLS or INET tunnel to the destination.”; Cisco SD-WAN therefore disclosed filtering according to criteria for matching one or more applications, i.e. cloud-based applications; See also p44, in which Cisco SD-WAN), and
comprises multiple NAT methods for an traffic associated with a source data prefix based on a DIA path preference and an availability of the DIA path preference (Cisco SD-WAN, p 44, Cisco SD-WAN disclosed the centralized data policy configured to filter traffic based on a prefix list such as a source data prefix list, to which all traffic entering is filtered based on the source data prefix configured within the policy match statement, and routed to the transport-side interface, VPN 0 as one example, to which groups of interest may include a VPN list, to which the VPN list can be specified on page 50; Page 45 shows the ability to add data prefixes; Cisco SD-WAN, p13, “For DIA, as shown above in the figure, NAT overload can be configured on the physical Internet transport interfaces connecting to the Internet Service Provider’s network; See page 15 NAT DIA Route and How NAT DIA Routes Work – enabling NAT on “Internet facing interface”; See also p20, NAT enabled interface; See also p24-25, Fig. 25 NAT enabled interfaces, and at the very bottom of p26 “two or more NAT interfaces”; p18 shows Single router dual internet design models in which allow for Internet failover to a secondary Internet link in the event of primary Internet link failure; See also Figure 31, “Path preference for internet traffic” and the rest of p29 explaining path preference and availability; Cisco SD-WAN therefore provides the ability to configure source data prefixes to comprise multiple NAT methods based on DIA path preference and an availability of the DIA path preference).
While Cisco SD-WAN disclosed the limitations with respect to source data prefix, Cisco SD-WAN did not explicitly disclose the limitations with respect to application type, as claimed.
However, Applicant’s Specification recites the determining of Application type according to “predefined criteria” (Applicant’s Spec, [0049], and Applicant’s Figure 3 disclosed a specific detail as to what “predefined criteria” includes. Applicant’s Figure 3 recites, “Policy classifies Application O365 traffic, selects NAT Pool Method based on chosen WAN 1 or 2 Link”. As “O365” is the source data prefix related to Microsoft 365 traffic, it is evident that Applicant intends the use of “source data prefixes” as “predefined criteria” in order to match data traffic to an application type supported by the policy.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed, to utilize Cisco SD-WAN’s explicitly disclosed matching according to source data prefix, in order to be able to match traffic by application type thereby allowing Cisco SD-WAN thereby achieving Cisco SD-WAN’s suggestion of being able to filter employee traffic such that Internet traffic uses the directly connected Internet transport for direct Internet access, while the rest of the Internal traffic exits via the MPLS or INET tunnel to the destination (Cisco SD-WAN, p8).
Regardless, in an analogous art, Yang disclosed matching according to application type to utilize NAT methods (Yang, [0095]-[0096], Yang disclosed for User initiated UL traffic, matching the traffic towards a specific service APN, creating a UL PDR (Packet Detection Rule) with application ID to match the traffic from the UE towards a specific network instance dedicated to the service APN, [0068], Yang disclosed NAT policies with different granularity; [0097]-[0099] replacing source IP address to the NAT IP address is a selection of the NAT method based on the application type matching the respective configuration, [0097]-[0099] replacing source IP address to the NAT IP address).
One of ordinary skill in the art would have been motivated to combine the teachings of Cisco SD-WAN and Yang as they both relate to utilization of NAT methods for routing of particular traffic, and as such, they are within similar environments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the utilization of application type as the means for making NAT routing decisions according to policy, as disclosed by Yang, within the teachings of Cisco SD-WAN in order to benefit of allowing the network operator to support NAT policies with different granularity (Yang, [0068]), thereby making the system more desirable to use by its customers.
.
Allowable Subject Matter
Pending correction to the formal issues above, claim 23 is 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.
Regarding claim 23, Cisco SD-WAN disclosed the method of claim 1, but did not explicitly disclose wherein a first NAT method is associated with a first DIA path and a second NAT method is associated with a second DIA path, and wherein the selected NAT method corresponds to the selected available DIA path, in the instance that such “first” and “second” NAT methods functionally interrelate with the selection process of claim 1.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Claim14 is 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. Regarding claim 14, Cisco SD-WAN disclosed the network device of claim 8, but did not explicitly disclose further comprising: determining from the data traffic received from one or more edge network devices in the SD-WAN that the data traffic originated from a first edge network device associated with specific source IP addresses; and assigning one or more IP addresses to the data traffic based on the first edge network device the data traffic originated from.
Response to Arguments
Applicant's arguments filed 5/04/2026 have been fully considered but they are not persuasive.
Applicant asserts, "At most, Cisco SD-WAN describes a deployment in which NAT is enabled on an interface used for DIA traffic. Cisco SD-WAN's disclosure that traffic may exit through a NAT-enabled interface does not disclose that a policy specifies a NAT method or that the policy includes one or more configurations for selection of the NAT method. The claim does not merely require that NAT be available or enabled somewhere in the forwarding path. Rather, the claim requires that the policy itself specify a NAT method for DIA action and include configurations for selecting that NAT method. "
Examiner respectfully disagrees.
First, it is noted that the limitation in question recites that the policy "includes one or more configurations for selection of the NAT method". Therefore, under the broadest reasonable interpretation of the claim, the limitation reasonably includes one configuration for selection of the NAT method, and therefore does not require plural configurations for selecting the NAT method as asserted.
Page 14 of Cisco SD-WAN explicitly recites centralized policies configured on the vSmart controller and set two actions - VPN NAT and local-TLOC color, and the policies are sent to WAN edge devices that learn the policy and then execute them. Additionally on page 14, Cisco SD-WAN describes the policy in use, routing traffic to a specific DIA interface by setting a path preference by using a traffic policy within the centralized policy. Page 15 of Cisco SD-WAN describes the NAT routes, "One of the three types of NAT routes include NAT DIA route" in which, "you can direct local Internet traffic to exit directly to the Internet cloud from the service-side VPN, through the next hop transport VPN, VPN 0". Page 32 of Cisco SD-WAN disclosed "Deploy the Device Template", in which "vManage attaches the configurations based on the feature templates and pushes the configuration to the devices". It is evident that the edge device receives policies (via templates), and executes the policy, routing traffic according to the policy, in which the policies include a NAT method(s) for DIA, allowing the edge network device to select the NAT method to handle particular traffic to route such traffic directly to the Internet; See also p25-26 Internet traffic flow using DIA route or data policy and Figure 27 Path preference for Internet traffic).
With respect to the limitation, "wherein the data traffic is matched with the one or more configurations in the policy to identify a NAT method that supports the data traffic received", Applicant asserts, "Cisco SD-WAN may disclose that traffic is matched to policy conditions to determine whether the traffic should be routed through a DIA path. It may also disclose that Internet-bound traffic exiting through a DIA interface is subject to NAT. But matching traffic for purposes of routing or forwarding is not the same as matching traffic with configurations in a policy to identify a NAT method that supports the data traffic."
Examiner respectfully disagrees.
While the claim recites a "NAT method", the claim is silent as to the requirements as to what makes up a NAT method. Applicant's specification does not appear to provide an explicit definition of what is required by a "NAT method". At best, Applicant's specification recites that a "NAT method" is "for handling data traffic (Applicant's Specification, [0008]) and "supports received data traffic" and "is linked to one or more WAN interfaces" (Applicant's Specification, [0065]). While the recited "method" may be labeled as a "NAT" method, such does not appear to require any particular functionality. In the broadest reasonable interpretation of the claim, any method that has some association with NAT reasonably amounts to a "NAT method", as claimed. As such, it is evident that Applicant intends the limitation to cover broad embodiments, such as the embodiments described in Applicant's argument. Page 15 of Cisco SD-WAN explicitly details the configuration of a NAT DIA route for directing local Internet traffic to exit directly to the Internet cloud, which reasonably amounts to a NAT method for DIA. Such requires matching the traffic according to the policy to select this NAT method for routing the traffic accordingly.
With respect to the limitation, "selecting the NAT method based on the data traffic matching a respective configuration of the one or more configurations in the policy", Applicant asserts, "Cisco SD-WAN disclosure may show that traffic matching a policy can be redirected to an Internet transport path, and that NAT may be used when traffic exits that path. But claim 1 requires something different: the matched policy configuration is used to select the NAT method. The Office Action has not identified a Cisco SD-WAN disclosure in which multiple NAT methods are represented in policy configurations and a particular NAT method is selected based on the traffic matching one of those configurations." Applicant additionally asserts, "To the extent the rejection treats a selected DIA path or NAT-enabled interface as the claimed "NAT method," that interpretation improperly reads "NAT method" out of the claim. Claim 1 separately recites selecting an available DIA path and selecting a NAT method. Thus, the NAT-method selection cannot be satisfied merely by pointing to the separate selection or use of a DIA path."
Examiner respectfully disagrees.
As noted above, the limitation in question recites "one or more configurations". Under the broadest reasonable interpretation of the claim, the limitation includes the embodiment that only requires one configuration. Additionally, claim 1 does not involve selection of a NAT method from "multiple NAT methods", as Applicant asserts. Claim 1 is silent with respect to multiple NAT methods. Cisco SD-WAN, at p13, recites "The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels"; p14, "WAN edge devices learn the policy and then execute them in memory."; p16 "Option 1: "DIA using NAT DIA Route" and "Option 2 DIA using Centralized Policy" involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and "Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. Only traffic destined for the public network passes from the service-side VPN to VPN 0"; See Figure 12. Applicant's argument, "Claim 1 separately recites selecting an available DIA path and selecting a NAT method. Thus, the NAT-method selection cannot be satisfied merely by pointing to the separate selection or use of a DIA path." appears conclusory as it does not provide rationale as to why selecting the NAT method cannot include selecting the available DIA path, as is disclosed by Cisco SD-WAN.
With respect to the limitation, "selecting an IP address that is consistent with the NAT method specified by the policy to apply to the data traffic", Applicant asserts, "The Office Action appears to rely on Cisco SD-WAN's disclosure that the source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. That disclosure describes ordinary NAT translation. It does not disclose selecting an IP address that is consistent with the NAT method specified by the policy. Translating a packet's source address to an interface address is not the same as selecting an IP address in accordance with a policy-specified NAT method."
Examiner respectfully disagrees.
Cisco SD-WAN, at p13, recites, "The source IP address of internal traffic destined for the Internet is translated to the interface IP address and exits directly to the Internet. The rest of the traffic remains within the overlay network and travels between two routers on the secure IPsec tunnels"; p14, "WAN edge devices learn the policy and then execute them in memory."; p16 "Option 1: "DIA using NAT DIA Route" and "Option 2 DIA using Centralized Policy" involving the configuration enabling NAT within the Internet transport interface on the WAN Edge router, and "Based on the policy configuration used in this deployment scenario, the Internet traffic is redirected from the source VPN to the transport VPN (VPN 0). All other traffic remains in VPN 1 and travels directly through the IPSec data plane tunnel to the destination WAN edge router. The traffic never passes through VPN 0, therefore, it is never touched by NAT. In Cisco SD-WAN, the translation of the IP address is consistent with the NAT method because the translation only occurs upon following the policy in deciding that the traffic should be directed towards the associated interface, and therefore translated accordingly. Whether or not ordinary NAT translation is utilizes, such still requires the translation to occur based on the decision from the policy to take that particular route.
With respect to the limitation, "routing the data traffic along the available DIA path based on the one or more configurations and the IP address applied during the NAT method in accordance with the policy", Applicant asserts, "Even if Cisco SD-WAN discloses routing traffic along an available DIA path, the rejection does not show routing "based on" both the policy configurations and "the IP address applied during the NAT method," as claimed."
Examiner respectfully disagrees.
As noted above, the limitation in question recites "one or more configurations". Under the broadest reasonable interpretation of the claim, the limitation includes the embodiment that only requires one configuration. Additionally as noted above, while the claim recites a "NAT method", the claim is silent as to the requirements as to what makes up a NAT method. Applicant's specification does not appear to provide an explicit definition of what is required by a "NAT method". At best, Applicant's specification recites that a "NAT method" is "for handling data traffic (Applicant's Specification, [0008]) and "supports received data traffic" and "is linked to one or more WAN interfaces" (Applicant's Specification, [0065]). While the recited "method" may be labeled as a "NAT" method, such does not appear to require any particular functionality. In the broadest reasonable interpretation of the claim, any method that has some association with NAT reasonably amounts to a "NAT method", as claimed. In Cisco SD-WAN, the translation of the IP address is consistent with the NAT method because the translation only occurs upon following the policy/configuration in deciding that the traffic should be directed towards the associated interface.
The rejections are therefore respectfully maintained.
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 JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached at 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2409
Prosecution Insights