DETAILED ACTION
This Action is for Application Number 18788688 received on 7/19/2024.
Claims 1-20 are presented for examination.
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 § 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 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, 11, and 18, 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, 12, and 19, 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).
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, 16, and 20 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, 13, and 20 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.
Conclusion
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 on 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