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 status: claims 1-17 are pending in this Office Action.
DETAILED ACTION
Response to Arguments
112 Rejection:
The applicant's amendment and remarks filed on 12/17/2025. Therefore the 35 U.S.C. 112b of the previous rejection is withdrawn
Prior Art Reiection:
Applicant's arguments to claims 1 have been fully considered but they are deemed not persuasive. Please see the new mapping in below.
Claim Rejections - 35 USC § 103
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1,148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre- AIA 35 U.S.C. 103(a) are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-17 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur (US20200382414 A1), in view of Caputo (US20150249598).
Regarding to claim 1:
Vasseur teaches A system for providing robust network connectivity, the system comprising a software-defined wide area network (SD-WAN) remote implemented in a first computing device at an edge location of a network, wherein the SD-WAN remote is operative to:
communicate with an SD-WAN base implemented in a second computing device at a client premises over a first overlay tunnel created via a first access network (figs. 1A-1B [0016] customer edge (CE) routers 110 … exchanged among the nodes/devices. See Fig. 6A on T1 [0041] devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120. [0085] traffic 602 is first routed onto tunnel T1 and captured and analyzed. [0013] a device predicts a failure of a first tunnel in a software-defined wide area network (SD-WAN) … The device proactively reroutes the traffic from the first tunnel onto the second tunnel; [0041] number of devices 308 … different SD-WANs. Note: a device 308a is a second computing device);
communicate with the SD-WAN base over a second overlay tunnel created via a second access network, wherein the first overlay tunnel is prioritized over the second overlay tunnel by default (see Fig.6A on T2. Fig. 6 devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120. [0075] predict a failure of tunnel T1, but also assess whether rerouting the traffic 602 sent via tunnel T1 onto the secondary tunnel T2 will satisfy the SLA [0078] the traffic of the primary tunnel T1 as a probability distribution … If there is a lot variability in the traffic 602, this may be a more precise representation of the traffic that will need to be handled by the backup tunnel. [0088] the backup tunnel T2) ;
receive a first outbound communication from the SD-WAN base over the first overlay tunnel (See fig. 6A traffic 602 communicating on T1 tunnel from 308a to 308b. [0041] number of devices 308 … different SD-WANs. See fig. 6 [0074] a plurality of devices 308a-308f are interconnected by links 604 and a tunnel T1 connects a head-end device 308a with a tail-end device 308d. Further, assume that device 308a implements a predictive routing service in the network, either by executing a failure prediction model directly or by communicating with a centralized service that executes the model (via device 308b). [0043] devices 308 may instead provide the telemetry data to supervisory service 310 on a push basic. Note: fig. 6a devices 308a and 308b are SD-WAN base and remote);
direct the first outbound communication to a destination device ([0074] a plurality of devices 308a-308f are interconnected by links 604 and a tunnel T1 connects a head-end device 308a with a tail-end device 308d. Further, assume that device 308a implements a predictive routing service in the network, either by executing a failure prediction model directly or by communicating with a centralized service that executes the model (via device 308b). [0043] devices 308 may instead provide the telemetry data to supervisory service 310 on a push basic. [0041] supervisory service 310 is implemented as a cloud-based service (at the end router CE1-110 – see fig. 1B). note: a local router device 110 (fig.1B) or device 308a (fig.6A) from local network 160 communicating with a centralized service at cloud 150 (fig.1B) or the tail-end router (308d – fig 6B) via a plurality of remote interconnected. So it would have been obvious a remote router direct the communication to a centralized service at cloud 150; a supervisory/cloud-based service 150 (see fig.1b) is a destination device)
receive a first inbound communication from the destination device ([0041] Supervisory service 310 may be in communication with any number of devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120). [0043] supervisory service 310 may send a custom request to one or more of devices 308. [0041] supervisory service 310 is implemented as a cloud-based service (at the end router CE1-110 – see fig. 1B). Note: service 310 or cloud service is the destination device)
after a failover event is determined in association with the first overlay tunnel ([0042] network that can lead to failures in various areas of the network between a head-end and tail-end router (e.g., between routers 110, etc. [0013] a device predicts a failure of a first tunnel in a software-defined wide area network (SD-WAN) … The device proactively reroutes the traffic from the first tunnel onto the second tunnel):
receive a second outbound communication from the SD-WAN base over the second overlay tunnel ([0085] traffic 602 is first routed onto tunnel T1 and captured and analyzed. [0013] a device predicts a failure of a first tunnel in a software-defined wide area network (SD-WAN) … The device proactively reroutes the traffic from the first tunnel onto the second tunnel);
direct the second outbound communication to the destination device ([0013] a device predicts a failure … reroutes the traffic from the first tunnel onto the second tunnel [0075] to make predictive routing decisions … device 308a may perform what-if testing of tunnel T2 [0055 - 0056] local resources available on the device 308, as well as the bandwidth required to send the telemetry for input to a model in the cloud (e.g supervisory service – see [0041] supervisory service 310 is implemented as a cloud-based service) … one failure … reporting these telemetry variables to the cloud for prediction … some of devices 308 perform the inferences locally, while others rely on supervisory service 310 to perform the predictions (see fig. 1). [0029] servers 152-154 (e.g., a network controller/supervisory service located in a data center, etc. See fig. 1b for data center/cloud 150. [0041] supervisory service 310 is implemented as a cloud-based service (at the end router CE1-110 – see fig. 1B) Note: supervisory/cloud-based service is destination device);
wherein the SD-WAN remote is configured to operate on a virtual machine hosted on the first computing device ([0028] SD-WAN techniques allow the WAN functions to be virtualized, essentially forming a virtual connection between local network 160 and data center/cloud 150 on top of the various underlying connection. [0029-0030] node/device 200 … particularly the PE routers 120, CE routers 110, nodes/device 10-20, servers 152-154 … physical network interface 210 may also be used to implement one or more virtual network interfaces. see Fig.6A on T2. Fig. 6 devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120. [0041] number of devices 308 … different SD-WANs . Note: device 308d is the first computing device), and
wherein the first computing device is an edge device in the network (see fig.6A [0041] number of devices 308 … different SD-WANs. Note: device 308d is an edge device in the network)
Vasseur does not explicitly disclose translate a source address of the first outbound communication from a first Internet protocol (IP) address of the SD-WAN base to an IP address of the SD-WAN remote, translate a destination address of the first inbound communication from the IP address of the SD-WAN remote to the first IP address of the SD-WAN base, direct the first inbound communication to the SD-WAN base over the first overlay tunne, translate a source address of the second outbound communication from a second IP address of the SD-WAN base to the IP address of the SD-WAN remote
Caputo teaches translate a source address of the first outbound communication from a first Internet protocol (IP) address of the SD-WAN base to an IP address of the SD-WAN remote (Caputo [0024] router 110 exchanges messages with at least one router on customer network 102. [0048] router 110 receives an outgoing packet from customer network 102. [0049] When router 110 determines that the outgoing packet has the assigned host's IP address, address translation module 330 modifies the source IP address of the first packet to replace with a translated IP address. [0063] Each of the devices and modules in FIG. 1 may be implemented in hardware, software, firmware, or any combination thereof. Note: router on customer network 102 is the SD-WAN base; router 110 is SD-WAN remote)
translate a destination address of the first inbound communication from the IP address of the SD-WAN remote to the first IP address of the SD-WAN base (Caputo, [0051] On the return route, address translation module 330 has to translate the reply to direct it to the original source. [0052] When router 110 determines that the incoming packet has the translated IP address, router 110 modifies the incoming packet's destination IP address to replace the translated IP address with the source IP address of the original outgoing packet);
direct the first inbound communication to the SD-WAN base over the first overlay tunnel (Caputo, see fig. 1 for 2 tunnels 130 and 132. [0020] Service provider network 104 connects to customer network 102 with different network services: a network service 130 and a network service 132. [0033] router 110 sends messages 150 and 152 to customer network 102. [0052- 0053] on the return traffic to direct the traffic to the correct source IP address … on the return traffic to direct the traffic to the correct source IP address. Net. Note: router on customer network 102 is the SD-WAN base) ; and
translate a source address of the second outbound communication from a second IP address of the SD-WAN base to the IP address of the SD-WAN remote (Caputo, Fig. 1 [0021] Each of the ports 140 and 142 may be, for example, on a router of the customer network 102. [0048] router 110 receives an outgoing packet from customer network 102. [0049] When router 110 determines that the outgoing packet has the assigned host's IP address, address translation module 330 modifies the source IP address of the first packet to replace with a translated IP address. [0063] Each of the devices and modules in FIG. 1 may be implemented in hardware, software, firmware, or any combination thereof); and
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Caputo and apply them on the teachings of Vasseur to further implement translate a source address of the first outbound communication from a first Internet protocol (IP) address of the SD-WAN base to an IP address of the SD-WAN remote, translate a destination address of the first inbound communication from the IP address of the SD-WAN remote to the first IP address of the SD-WAN base, direct the first inbound communication to the SD-WAN base over the first overlay tunne, translate a source address of the second outbound communication from a second IP address of the SD-WAN base to the IP address of the SD-WAN remote. One would be motivated to do so because in order to improve better system and method to provide When a router determines that the outgoing packet has the assigned host's IP address, address translation module modifies the source IP address of the first packet to replace with a translated IP address, on the return route, address translation module has to translate the reply to direct it to the original source and the router sends messages to customer network (Caputo, [0033][0049][0051]).
Regarding to claim 2:
Vasseur teaches The system of claim 1, wherein the first overlay tunnel and the second overlay tunnel are IP security (IPSec) tunnels ([0039] Traditionally, failure detection in an SD-WAN has relied on the keep-alive mechanisms of BFD over tunnels, such as IPSec tunnels)
Regarding to claim 4:
Vasseur teaches The system of claim 1, wherein the SD-WAN remote is configured to operate on a virtual machine hosted on an edge device in the network ([0028] SD-WAN techniques allow the WAN functions to be virtualized, essentially forming a virtual connection between local network 160 and data center/cloud 150 on top of the various underlying connection. [0029-0030] node/device 200 … particularly the PE routers 120, CE routers 110, nodes/device 10-20, servers 152-154 … physical network interface 210 may also be used to implement one or more virtual network interfaces)
Regarding to claim 5:
Vasseur teaches The system of claim 4, wherein the edge device is one of a plurality of edge devices in the network and, among the plurality of edge devices, is located geographically closest to the SD-WAN base (see fig. 1. [0083] The contextual information above includes information about configuration on the edge device 308 (e.g., routing, QoS), as well as on each of the tunnels T1 and T2, such as the type of the transport, corresponding ISP, geographical locations of the endpoints).
Regarding to claim 6:
Vasseur teaches The system of claim 1, wherein the failover event is based on a determination made by the SD-WAN base in response to an evaluation of test packets transmitted to the SD-WAN remote against a set of failover criteria (Fig.6A [0074-0075] a head-end device 308a with a tail-end device 308d. Further, assume that device 308a implements a predictive routing service in the network, either by executing a failure prediction model directly or by communicating with a centralized service that executes the model … predict a failure of tunnel T1… device 308a may perform what-if testing of tunnel T2, to obtain training data for the model).
Regarding to claim 7:
Vasseur teaches The system of claim 6, wherein the failover event is in association with the first overlay tunnel (Fig.6A [0074-0075] a head-end device 308a with a tail-end device 308d. Further, assume that device 308a implements a predictive routing service in the network, either by executing a failure prediction model directly or by communicating with a centralized service that executes the model … predict a failure of tunnel T1… device 308a may perform what-if testing of tunnel T2, to obtain training data for the model).
Regarding to claim 8:
Vasseur teaches The system of claim 6, wherein the failover event is determined when one or a combination of service level agreement (SLA) parameters are outside of a specific range, the SLA parameters including ([0051] In some cases, MLFF (machine learning failure forecasting) module 304 may employ a policy to trigger per-customer/SD-WAN specific model training, if the Max_Recall value improvement is greater than a given threshold. [0076] the model may predict the SLA … variables can reflect the number of packets per second, as well as any other traffic characteristic that may impact tunnel utilization and performance. [0046] telemetry collection module 302 may instruct one or more of devices 308 to report certain telemetry variables only after occurrence of certain events. For example, Table 1 below shows some example telemetry variables and when a device 308 may report them to supervisory service 310:):
packet loss ([0052] Prototyping of the techniques herein using simple models and input features based on coarse telemetry, such as 1-minute averages of loss, latency, jitter, traffic, as well as CPU/memory of CE routers, lead to recalls in the range of a few percent with a precision of 80% or more);
latency ([0052] Prototyping of the techniques herein using simple models and input features based on coarse telemetry, such as 1-minute averages of loss, latency, jitter, traffic, as well as CPU/memory of CE routers, lead to recalls in the range of a few percent with a precision of 80% or more); and
jitter ([0052] Prototyping of the techniques herein using simple models and input features based on coarse telemetry, such as 1-minute averages of loss, latency, jitter, traffic, as well as CPU/memory of CE routers, lead to recalls in the range of a few percent with a precision of 80% or more).
Regarding to claim 9:
Vasseur teaches The system of claim 1, wherein the SD-WAN remote is further operative to:
receive a second inbound communication from the destination device ([0075] predict a failure of tunnel T1, but also assess whether rerouting the traffic 602 sent via tunnel T1 onto the secondary tunnel T2 will satisfy the SLA. [0041] Supervisory service 310 may be in communication with any number of devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120. See fig. 3 for 2 tunnels from destination 310 to routers 308);
direct the second inbound communication to the SD-WAN base over the second overlay tunnel (See fig. 6D for the second tunnel T2 between two routers where one router is SD-WAN base and another one is SD-WAN remote).
Vasseures not explicitly disclose translate a destination address of the second inbound communication from the IP address of the SD-WAN remote to the second IP address of the SD-WAN base.
Caputo teaches translate a destination address of the second inbound communication from the IP address of the SD-WAN remote to the second IP address of the SD-WAN base (Caputo, [0051] On the return route, address translation module 330 has to translate the reply to direct it to the original source. [0052] When router 110 determines that the incoming packet has the translated IP address, router 110 modifies the incoming packet's destination IP address to replace the translated IP address with the source IP address of the original outgoing packet); and
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Caputo and apply them on the teachings of Vasseur to further implement translate a destination address of the second inbound communication from the IP address of the SD-WAN remote to the second IP address of the SD-WAN base. One would be motivated to do so because in order to improve better system and method to provide on the return route, address translation module has to translate the reply to direct it to the original source and the router sends messages to customer network (Caputo, [0051]).
Regarding to claim 10:
Vasseur teaches The system of claim 9, wherein when, after the failover event, the first overlay tunnel is determined to be stable ([0091] if device 308a determines that the failure prediction was a false positive and that tunnel T1 did not actually fail at its predicted time, device 308a may opt to reroute traffic 602 back onto tunnel T1), the SD-WAN remote is further operative to:
receive a third outbound communication from the SD-WAN base over the first overlay tunnel (see fig. 1AB the remote router 120/110 (representing SD-WAN remote) can receive multiple outbound communications from multiple local routers 110 (representing SD-WAN base). Multiple outbound communications is third outbound communication);
direct the third outbound communication to the destination device ([0074] a plurality of devices 308a-308f are interconnected by links 604 and a tunnel T1 connects a head-end device 308a with a tail-end device 308d. Further, assume that device 308a implements a predictive routing service in the network, either by executing a failure prediction model directly or by communicating with a centralized service that executes the model (via device 308b). [0043] devices 308 may instead provide the telemetry data to supervisory service 310 on a push basic. [0041] supervisory service 310 is implemented as a cloud-based service (at the end router CE1-110 – see fig. 1B). note: a local router device 110 (fig.1B) or device 308a (fig.6A) from local network 160 communicating with a centralized service at cloud 150 (fig.1B) or the tail-end router (308d – fig 6B) via a plurality of remote interconnected. So it would have been obvious a remote router direct the communication to a centralized service at cloud 150; a supervisory/cloud-based service 150 (see fig.1b) is a destination device)
Vasseures not explicitly disclose translate a source address of the third outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote.
Caputo teaches translate a source address of the third outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote (Caputo, [0017] providing the ability for customers to assign particular DNS hostnames to particular network services. Once a customer assigns a DNS hostname to a network service, embodiments send configuration messages to a router on the customer's network, updating the router's routing tables to direct traffic addressed to the assigned hostname to the assigned network service. [0051] On the return route, address translation module 330 has to translate the reply to direct it to the original source. [0052] When router 110 determines that the incoming packet has the translated IP address, router 110 modifies the incoming packet's destination IP address to replace the translated IP address with the source IP address of the original outgoing packet. Note: Network 102 provides a plurality of customers. Each customer is provided 2 tunnels (see fig.1) teaches the third outbound communication); and
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Caputo and apply them on the teachings of Vasseur to further implement translate a source address of the third outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote. One would be motivated to do so because in order to improve better system and method to provide on the return route, address translation module has to translate the reply to direct it to the original source and the router sends messages to customer network (Caputo, [0051]).
Regarding to claim 11:
Vasseures teaches The system of claim 1, wherein the first interface is connected to an interface of the SD-WAN remote via the first overlay tunnel (See fig. 6A. [0085] traffic 602 is first routed onto tunnel T1 and captured and analyzed)
Vasseures not explicitly wherein in translating the source address of the first outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a first interface of the SD-WAN base.
Caputo teaches wherein in translating the source address of the first outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a first interface of the SD-WAN base (Caputo [0024] router 110 exchanges messages with at least one router on customer network 102. [0048] router 110 receives an outgoing packet from customer network 102. [0049] When router 110 determines that the outgoing packet has the assigned host's IP address, address translation module 330 modifies the source IP address of the first packet to replace with a translated IP address. [0063] Each of the devices and modules in FIG. 1 may be implemented in hardware, software, firmware, or any combination thereof. Note: router on customer network 102 is the SD-WAN base; router 110 is SD-WAN remote),
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Caputo and apply them on the teachings of Vasseur to further implement wherein in translating the source address of the first outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a first interface of the SD-WAN base. One would be motivated to do so because in order to improve better system and method to provide when router determines that the outgoing packet has the assigned host's IP address, address translation module modifies the source IP address of the first packet to replace with a translated IP address (Caputo, [0049]).
Regarding to claim 12:
Vasseures teaches The system of claim 1,
Vasseures not explicitly wherein in translating the source address of the second outbound communication from the second IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a second interface of the SD-WAN base.
Caputo teaches wherein in translating the source address of the second outbound communication from the second IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a second interface of the SD-WAN base (Caputo See fig. 1 for 2 tunnels 130 and 132. [0020] Service provider network 104 connects to customer network 102 with different network services: a network service 130 and a network service 132. [0033] router 110 sends messages 150 and 152 to customer network 102 [0024] router 110 exchanges messages with at least one router on customer network 102. [0048] router 110 receives an outgoing packet from customer network 102. [0049] When router 110 determines that the outgoing packet has the assigned host's IP address, address translation module 330 modifies the source IP address of the first packet to replace with a translated IP address. [0063] Each of the devices and modules in FIG. 1 may be implemented in hardware, software, firmware, or any combination thereof), wherein the second interface is connected to an interface of the SD-WAN remote via the second overlay tunnel ([0075] predict a failure of tunnel T1, but also assess whether rerouting the traffic 602 sent via tunnel T1 onto the secondary tunnel T2 will satisfy the SLA.
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Caputo and apply them on the teachings of Vasseur to further implement wherein in translating the source address of the first outbound communication from the first IP address of the SD-WAN base to the IP address of the SD-WAN remote, the SD-WAN remote is operative to translate the source address from the IP address of a first interface of the SD-WAN base. One would be motivated to do so because in order to improve better system and method to provide when router determines that the outgoing packet has the assigned host's IP address, address translation module modifies the source IP address of the first packet to replace with a translated IP address (Caputo, [0049]).
Regarding to claim 13:
advertising the first overlay tunnel with a higher priority than the second overlay tunnel by default [0078] the model may represent the traffic of the primary tunnel T1 as a probability distribution … If there is a lot variability in the traffic 602, this may be a more precise representation of the traffic that will need to be handled by the backup tunnel)
[Rejection rationale for claim 1 is applicable].
Regarding to claim 14:
[Rejection rationale for claim 9 is applicable].
Regarding to claim 15:
[Rejection rationale for claim 10 is applicable].
Regarding to claim 16:
[Rejection rationale for claims 11-12 is applicable].
Regarding to claim 17:
The method of claim 13, wherein a session is established between the SD-WAN base and the destination device prior to the failover event and continues after the failover event ([0084-0086] device 308a may perform stress testing of tunnel T2, to obtain training data for the what-if modeling. To do so, device 308a may reroute at least a portion of traffic 602 onto tunnel T2 and monitor the resulting QoS metrics on tunnel T2 … such traffic analysis may be triggered on the fly upon receiving a failure prediction event … based on a prediction that tunnel T1 is going to fail, as well as prediction that tunnel T2 can satisfy the SLA of traffic 602, device 308a may proactively reroute traffic 602 onto tunnel T2, prior to the time at which tunnel T1 is predicted to fail. [0033] in response to a needed route to a destination, send a route request into the network to determine which neighboring node may be used to reach the desired destination. [0041] Supervisory service 310 may be in communication with any number of devices 308 (e.g., a first through n.sup.th device), which may be CE routers 110 and/or PE routers 120).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Vasseur (US20200382414 A1), in view of Caputo (US20150249598), further in view of Frey (US20160094688)
Regarding to claim 3:
Vasseur-Caputo teaches The system of claim 1,
Vasseur-Caputo does not explicitly disclose the first outbound communication and the second outbound communication are encapsulated in an IP packet including an IP header; and the SD-WAN remote is further operative to decapsulate the first outbound communication and the second outbound communication prior to the translations of the source address.
Frey teaches wherein: the first outbound communication and the second outbound communication are encapsulated in an IP packet including an IP header; and the SD-WAN remote is further operative to decapsulate the first outbound communication and the second outbound communication prior to the translations of the source address ([0024] each of network access devices 102-103 creates one or more secure communication channels (e.g., a control tunnel) with server 101. [0028] UDP/IP module 111 generates a UDP packet encapsulating the management message as a payload therein. UDP/IP module 111 then transmits the UDP packet to network access device 102. [0057] management server 101 maintains at least two components:1) a process that encapsulates and decapsulates IP packets. [0019] a network access device (see device 103 on fig. 1) may present a gateway device interfacing a LAN to WAN 104 and performs network address translation (NAT) for its clients, which may be client devices 108-109. See fig.3 IP packet comprises IP header Note: see fig.1, server 101 encapsulates and decapsulates and transmits the UDP packet to device 102. The device 102 translates UDP packet for client device 109 teaches encapsulated and decapsulate the first outbound communication and the second outbound communication prior to the translations of the source address).
it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Frey and apply them on the teachings of Vasseur-Caputo to further the first outbound communication and the second outbound communication are encapsulated in an IP packet including an IP header; and the SD-WAN remote is further operative to decapsulate the first outbound communication and the second outbound communication prior to the translations of the source address. One would be motivated to do so because in order to improve better system and method to provide management server encapsulates and decapsulates IP packets. (Frey, [0057]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
This action is a final rejection and is intended to close the prosecution of this application. Applicant’s reply under 37 CFR 1.113 to this action is limited either to an appeal to the Patent Trial and Appeal Board or to an amendment complying with the requirements set forth below.
If applicant should desire to appeal any rejection made by the examiner, a Notice of Appeal must be filed within the period for reply identifying the rejected claim or claims appealed. The Notice of Appeal must be accompanied by the required appeal fee.
If applicant should desire to file an amendment, entry of a proposed amendment after final rejection cannot be made as a matter of right unless it merely cancels claims or complies with a formal requirement made earlier. Amendments touching the merits of the application which otherwise might not be proper may be admitted upon a showing a good and sufficient reasons why they are necessary and why they were not presented earlier.
A reply under 37 CFR 1.113 to a final rejection must include the appeal from, or cancellation of, each rejected claim. The filing of an amendment after final rejection, whether or not it is entered, does not stop the running of the statutory period for reply to the final rejection unless the examiner holds the claims to be in condition for allowance. Accordingly, if a Notice of Appeal has not been filed properly within the period for reply, or any extension of this period obtained under either 37 CFR 1.136(a) or (b), the application will become abandoned.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HIEN DOAN whose telephone number is 571 272-4317. The examiner can normally be reached on Monday-Thursday and biweekly Friday 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571)272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HIEN V DOAN/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449