DETAILED ACTION
Claim(s) 1-20 have been examined and are pending.
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 § 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, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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.
Claim(s) 1, 3, 4, 7, 9, 10, 13, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR (US 11381474 B1).
In regards to claim 1, ZAD TOOTAGHAJ (US 20210392070 A1) teaches a method performed at least in part by a
enabling, at the (ZAD TOOTAGHAJ teaches enabling at a device, SDN enabled device /SD-WAN infrastructure device , a path trace of underlay paths, by sending network probes along an underlay route, between the SDN/enabled device/SD-WAN infrastructure device and a remote device, SDN enabled device 105c, and sending from the SD enabled device/SD-WAN infrastructure device to a control plane, network orchestrator, underlay path trace data, underlay path trace data such as delay times, transmission timestamps, network probe ID information, SD-WAN link information, “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106. When the network probes are received at SDN enabled device 105c, delay times are calculated by subtracting the transmission timestamp for each network probe from the received time for each network probe. In some examples, SDN enabled device 105c generates a reply (either a single reply for all network probes in the series of network probes, or a reply for each network probe) that includes delay times for each network probe and transmits the reply to SDN enabled device 105a. In some other examples, SDN enabled device 105c transmits the delay times, along with additional information, such as the transmission timestamps, network probe ID information, and SD-WAN link information, to the network orchestrator.”);
receiving, from the control plane, a policy indicating segments of the underlay paths that are associated with an attribute for an entity associated with the (ZAD TOOTAGHAJ teaches where the SDN enabled device /SD-WAN infrastructure device receives from the network orchestrator, a policy, such as a policy of achieving a cheapest business cost while maintaining a QoS requirement, indicating segments of the underlay paths that are associated with an attribute, an attribute such as a congested physical (i.e. underlay) link for an entity, an entity such as a network administrator associated with the SDN enabled/SD-WAN infrastructure device, “[0015] Simply finding the most efficient path across the SD-WAN (overlay network) to the destination isn't the only concern. Physical links have business costs associated with them, and the costs for each link can conform to one of a number of models. For example, an ISP may charge a flat monthly rate for a DSL link between two WAN sites. In another model, the ISP may charge a flat monthly rate for the DSL link as long as monthly bandwidth usage is less than 100 GB, and then charge a per-GB rate for all data transacted over 100 GB. In yet another model, the ISP may only charge a per-GB rate for usage of the link. [0016] A cost-conscious network administrator may prefer to route network traffic in a way that costs the least while still maintaining quality of service (QoS) requirements for each type of network traffic. For example, routing streaming video traffic through the cheapest and lowest QoS route may cost less than routing the streaming video traffic through a more expensive route, but the cheapest route may violate QoS requirements for the streaming video traffic… [0025] Once each flow from the flow order has had a least costly path selected, the routing solution is complete. The network orchestrator proceeds to generate a new flow order optimizing for a different flow, and calculates a routing solution calculated optimizing for each flow of the SD-WAN, the network orchestrator selects a total minimum cost routing solution based on a minimum total operational cost when comparing total operational costs of each routing solution. The total minimum cost routing solution is then implemented by sending flow rules to SD-WAN infrastructure devices that modify their routing behaviors to be congruent with the total minimum cost routing solution…[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links…[0066] A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.”);
determining whether the attribute indicates that the segments of the underlay paths are to be avoided or included in a first underlay path, wherein:
in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are avoided ;
or in response to the attribute indicating that the segments are to be included, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are included; and routing data on behalf of the entity through the first underlay path (ZAD TOOTAGHAJ teaches determining whether the attribute, congestion of an underlay path, indicates that segments of the underlay paths are to be avoided or included in a first underlay path, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path (i.e. underlay route 112, underlay route 116) for sending data on behalf of the network administrator associated with the, SDN enabled device/SD-WAN infrastructure device, such that the segments of the underlay paths (i.e. segments of underlay route 106), that are associated with the congested underlay path are avoided, or in response to the attribute indicating that the segments (i.e. segments of underlay route 106, in a case where there is a high correlation between SD-WAN links 108 and 114) are to be included, identifying the first underlay path (i.e. underlay route 106) for sending data on behalf of the network administrator associated with the SD-Enabled/ SD-WAN Infrastructure Device such that the segments of the underlay paths that are associated with the attributed are included (i.e. , and routing data on behalf of the network administrator through the first underlay path), and routing data (i.e. flows) on behalf of the network administrator through the first underlay path “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106…[0032]…The network orchestrator may analyze data across pairs of SD-WAN links for correlation…Correlation between pairs of SD-WAN links may indicate direct or indirect shared congested underlay links. For example, if network change 110a is congestion across the link between device 103 and device 105c, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link), but delay times for network probes assigned to SD-WAN link 114 may not increase (because associated underlay route 112 does not pass through the congested link). This will result in a reduced correlation between SD-WAN link 108 and SD-WAN link 114. However, if network change 110b is congestion across the link between device 105a and device 103, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link) and delay times for network probes assigned to SD-WAN link 114 may increase (because associated underlay route 112 also passes through the congested link). This will result in an increased correlation between SD-WAN links 108 and 114….[0033] Correlation information can be used to make routing decisions. For example, if network change 110a is causing packets of flow routed across SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a low correlation between SD-WAN links 108 and 114, that network change 110a can be bypassed by moving flows routed across SD-WAN link 108 to instead use SD-WAN link 114 and SD-WAN link 118 to reach SDN enabled device 105c. As another example, if network change 110b is causing packets of flow routed through SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a high correlation between SD-WAN links 108 and 114, that network change 110b cannot be bypassed by moving flow routed across SD-WAN link 108 to SD-WAN link 114, since underlay route 112 also uses the link affected by network change 110b. Flows routed across SD-WAN link 108 may be worse off being routed around underlay route 112 rather than staying with underlay route 106. In FIG. 1, as well as in the rest of this disclosure, SD-WAN links are shown as unidirectional data paths.”).
ZAD TOOTAGHAJ (US 20210392070 A1) differs from claim 1, in that ZAD TOOTAGHAJ (US 20210392070 A1) is silent on where the device (i.e. SD-WAN device) comprises an edge device. Despite these differences similar features have seen in other prior art involving software defined (SD) Wide Area Network(s) (WANs). KUMAR (US 11381474 B1) teaches a feature for SD-WAN where a device that performs monitoring comprises a SD-WAN edge device, the monitoring being regarded as analogous to the probing feature of ZAD TOOTAGHAJ ([Col. 8, Line 59 – Col 9, Line 25] “SD-WAN edges 108 process and forward received network traffic for SD-WAN service 101 according to policies and configuration data from service orchestrator 102, routing information, and current network conditions including underly connection performance characteristics. In some examples, service orchestrator 102 may push SLA parameters, path selection parameters and related configuration to SD-WAN edges 108, and SD-WAN edges 108 monitors the links for SLA violations and can switch an application to a different one of WAN links 142. SD-WAN edges 108 may thereby implement the data plane functionality of SD-WAN service 101 over the underlay connections including, in such examples, application switching to different WAN links 142 for application QoE. If there is an SLA violation detected by one of SD-WAN edges 108, the SD-WAN edge may report and send log messages to service orchestrator 102 describing the SLA violation and the selected WAN link. SD-WAN edges 108 may also aggregate, optionally average, and report SLA metrics for WAN links 142 in log messages to service orchestrator 102. In some examples, service orchestrator 102 may receive SLA metrics from SD-WAN edges 108, determine an SLA for an application has been violated, and perform path selection to select a new one of WAN links 142 for the SLA-violated application. Service orchestrator 102 may then configure one or more of SD-WAN edges 108 to switch the application traffic for the application on the new WAN link. SLA metric analysis, SLA evaluation, path selection, and link switching functionality are all performed by SD-WAN system 100, but different examples of SD-WAN system 100 may have a different distribution of control plane functionality between service orchestrator 102 and SD-WAN edges 108 than those examples just described. However, such functionality is described below primarily with respect to SD-WAN edges 108.”, [Col. 9, Line 61 – Col. 10, Line 17] “(31) To monitor the SLA compliance of the link on which the application traffic is sent, service orchestrator 102 may cause SD-WAN edges 108 to send inline probes along WAN links 142 (in some cases along with the application traffic already being sent). These inline probes may be referred to as “passive probes.” To identify the best available one of WAN links 142 for an application in case the active WAN link fails to meet the SLA criteria, service orchestrator 102 monitors and collects SLA compliance data for other available WAN links 142 for SD-WAN service 101. The probes that service orchestrator 102 sends over other WAN links 142 to check the SLA compliance may be referred to as “active probes.” The active probes are carried out based on probe parameters provided in some cases by the subscriber. Active and passive probe measurements are used for an end-to-end analysis of WAN links 142. The data collected by active and passive probing is used for monitoring the network for sources of failures or congestion. If there is a violation detected for any application or group of multiple applications (“application group”), service orchestrator 102 evaluates the synthetic probe metrics to determine a satisfactory, and in some cases best, WAN link 142 that satisfies the SLA. As used herein, reference to an application may refer to a single application or any application group.”).
Thus, based upon the teachings of KUMAR (US 11381474 B1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN device of ZAD TOOTAGHAJ, to comprise an edge device, as similarly seen in the SD-WAN feature of KUMAR, in order to provide a reliable means to implement the desired monitoring/probing functionality taught by ZAD TOOTAGHAJ.
In regards to claim 7, ZAD TOOTAGHAJ (US 20210392070 A1) teaches a system comprising: one or more processors; and one or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (“[0066] A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.”):
enabling, at an (ZAD TOOTAGHAJ teaches enabling at a device, SDN enabled device /SD-WAN infrastructure device , a path trace of underlay paths, by sending network probes along an underlay route and sending from the SD enabled device/SD-WAN infrastructure device to a control plane, network orchestrator, underlay path trace data, underlay path trace data such as delay times, transmission timestamps, network probe ID information, SD-WAN link information, “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106. When the network probes are received at SDN enabled device 105c, delay times are calculated by subtracting the transmission timestamp for each network probe from the received time for each network probe. In some examples, SDN enabled device 105c generates a reply (either a single reply for all network probes in the series of network probes, or a reply for each network probe) that includes delay times for each network probe and transmits the reply to SDN enabled device 105a. In some other examples, SDN enabled device 105c transmits the delay times, along with additional information, such as the transmission timestamps, network probe ID information, and SD-WAN link information, to the network orchestrator.”);
receiving, from the control plane, a policy indicating segments of the underlay paths that are associated with an attribute for an entity associated with the (ZAD TOOTAGHAJ teaches where the SDN enabled device /SD-WAN infrastructure device receives from the network orchestrator, a policy, such as a policy of achieving a cheapest business cost while maintaining a QoS requirement, indicating segments of the underlay paths that are associated with an attribute, an attribute such as a congested physical (i.e. underlay) link for an entity, an entity such as a network administrator associated with the SDN enabled/SD-WAN infrastructure device, “[0015] Simply finding the most efficient path across the SD-WAN (overlay network) to the destination isn't the only concern. Physical links have business costs associated with them, and the costs for each link can conform to one of a number of models. For example, an ISP may charge a flat monthly rate for a DSL link between two WAN sites. In another model, the ISP may charge a flat monthly rate for the DSL link as long as monthly bandwidth usage is less than 100 GB, and then charge a per-GB rate for all data transacted over 100 GB. In yet another model, the ISP may only charge a per-GB rate for usage of the link. [0016] A cost-conscious network administrator may prefer to route network traffic in a way that costs the least while still maintaining quality of service (QoS) requirements for each type of network traffic. For example, routing streaming video traffic through the cheapest and lowest QoS route may cost less than routing the streaming video traffic through a more expensive route, but the cheapest route may violate QoS requirements for the streaming video traffic… [0025] Once each flow from the flow order has had a least costly path selected, the routing solution is complete. The network orchestrator proceeds to generate a new flow order optimizing for a different flow, and calculates a routing solution calculated optimizing for each flow of the SD-WAN, the network orchestrator selects a total minimum cost routing solution based on a minimum total operational cost when comparing total operational costs of each routing solution. The total minimum cost routing solution is then implemented by sending flow rules to SD-WAN infrastructure devices that modify their routing behaviors to be congruent with the total minimum cost routing solution…[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links…[0066] A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.”);
determining whether the attribute indicates that the segments of the underlay paths are to be avoided or included in a first underlay path, wherein:
in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path for sending data on behalf of the entity associated with the
in response to the attribute indicating that the segments are to be included, identifying the first underlay path for sending data on behalf of the entity associated with the ZAD TOOTAGHAJ teaches determining whether the attribute, congestion of an underlay path, indicates that segments of the underlay paths are to be avoided or included in a first underlay path, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path (i.e. underlay route 112, underlay route 116) for sending data on behalf of the network administrator associated with the, SDN enabled device/SD-WAN infrastructure device, such that the segments of the underlay paths (i.e. segments of underlay route 106), that are associated with the congested underlay path are avoided, or in response to the attribute indicating that the segments (i.e. segments of underlay route 106, in a case where there is a high correlation between SD-WAN links 108 and 114) are to be included, identifying the first underlay path (i.e. underlay route 106) for sending data on behalf of the network administrator associated with the SD-Enabled/ SD-WAN Infrastructure Device such that the segments of the underlay paths that are associated with the attributed are included (i.e. , and routing data on behalf of the network administrator through the first underlay path), and routing data (i.e. flows) on behalf of the network administrator through the first underlay path “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106…[0032]…The network orchestrator may analyze data across pairs of SD-WAN links for correlation…Correlation between pairs of SD-WAN links may indicate direct or indirect shared congested underlay links. For example, if network change 110a is congestion across the link between device 103 and device 105c, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link), but delay times for network probes assigned to SD-WAN link 114 may not increase (because associated underlay route 112 does not pass through the congested link). This will result in a reduced correlation between SD-WAN link 108 and SD-WAN link 114. However, if network change 110b is congestion across the link between device 105a and device 103, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link) and delay times for network probes assigned to SD-WAN link 114 may increase (because associated underlay route 112 also passes through the congested link). This will result in an increased correlation between SD-WAN links 108 and 114….[0033] Correlation information can be used to make routing decisions. For example, if network change 110a is causing packets of flow routed across SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a low correlation between SD-WAN links 108 and 114, that network change 110a can be bypassed by moving flows routed across SD-WAN link 108 to instead use SD-WAN link 114 and SD-WAN link 118 to reach SDN enabled device 105c. As another example, if network change 110b is causing packets of flow routed through SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a high correlation between SD-WAN links 108 and 114, that network change 110b cannot be bypassed by moving flow routed across SD-WAN link 108 to SD-WAN link 114, since underlay route 112 also uses the link affected by network change 110b. Flows routed across SD-WAN link 108 may be worse off being routed around underlay route 112 rather than staying with underlay route 106. In FIG. 1, as well as in the rest of this disclosure, SD-WAN links are shown as unidirectional data paths.”).
ZAD TOOTAGHAJ (US 20210392070 A1) differs from claim 7, in that ZAD TOOTAGHAJ (US 20210392070 A1) is silent on where the device (i.e. SD-WAN device) comprises an edge device. Despite these differences similar features have seen in other prior art involving software defined (SD) Wide Area Network(s) (WANs). KUMAR (US 11381474 B1) teaches a feature for SD-WAN where a device that performs monitoring comprises a SD-WAN edge device, the monitoring being regarded as analogous to the probing feature of ZAD TOOTAGHAJ ([Col. 8, Line 59 – Col 9, Line 25] “SD-WAN edges 108 process and forward received network traffic for SD-WAN service 101 according to policies and configuration data from service orchestrator 102, routing information, and current network conditions including underly connection performance characteristics. In some examples, service orchestrator 102 may push SLA parameters, path selection parameters and related configuration to SD-WAN edges 108, and SD-WAN edges 108 monitors the links for SLA violations and can switch an application to a different one of WAN links 142. SD-WAN edges 108 may thereby implement the data plane functionality of SD-WAN service 101 over the underlay connections including, in such examples, application switching to different WAN links 142 for application QoE. If there is an SLA violation detected by one of SD-WAN edges 108, the SD-WAN edge may report and send log messages to service orchestrator 102 describing the SLA violation and the selected WAN link. SD-WAN edges 108 may also aggregate, optionally average, and report SLA metrics for WAN links 142 in log messages to service orchestrator 102. In some examples, service orchestrator 102 may receive SLA metrics from SD-WAN edges 108, determine an SLA for an application has been violated, and perform path selection to select a new one of WAN links 142 for the SLA-violated application. Service orchestrator 102 may then configure one or more of SD-WAN edges 108 to switch the application traffic for the application on the new WAN link. SLA metric analysis, SLA evaluation, path selection, and link switching functionality are all performed by SD-WAN system 100, but different examples of SD-WAN system 100 may have a different distribution of control plane functionality between service orchestrator 102 and SD-WAN edges 108 than those examples just described. However, such functionality is described below primarily with respect to SD-WAN edges 108.”, [Col. 9, Line 61 – Col. 10, Line 17] “(31) To monitor the SLA compliance of the link on which the application traffic is sent, service orchestrator 102 may cause SD-WAN edges 108 to send inline probes along WAN links 142 (in some cases along with the application traffic already being sent). These inline probes may be referred to as “passive probes.” To identify the best available one of WAN links 142 for an application in case the active WAN link fails to meet the SLA criteria, service orchestrator 102 monitors and collects SLA compliance data for other available WAN links 142 for SD-WAN service 101. The probes that service orchestrator 102 sends over other WAN links 142 to check the SLA compliance may be referred to as “active probes.” The active probes are carried out based on probe parameters provided in some cases by the subscriber. Active and passive probe measurements are used for an end-to-end analysis of WAN links 142. The data collected by active and passive probing is used for monitoring the network for sources of failures or congestion. If there is a violation detected for any application or group of multiple applications (“application group”), service orchestrator 102 evaluates the synthetic probe metrics to determine a satisfactory, and in some cases best, WAN link 142 that satisfies the SLA. As used herein, reference to an application may refer to a single application or any application group.”).
Thus, based upon the teachings of KUMAR (US 11381474 B1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN device of ZAD TOOTAGHAJ, to comprise an edge device, as similarly seen in the SD-WAN feature of KUMAR, in order to provide a reliable means to implement the desired monitoring/probing functionality taught by ZAD TOOTAGHAJ.
In regards to claim 13, ZAD TOOTAGHAJ (US 20210392070 A1) teaches one or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations comprising (“[0066] A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.”):
receiving, at a control plane, underlay path trace data associated with a path trace of underlay paths between an edge device and a remote device (ZAD TOOTAGHAJ teaches enabling at a device, SDN enabled device /SD-WAN infrastructure device , a path trace of underlay paths, by sending network probes along an underlay route, between the SDN/enabled device/SD-WAN infrastructure device and a remote device, SDN enabled device 105c, and sending from the SD enabled device/SD-WAN infrastructure device to a control plane, network orchestrator, underlay path trace data, underlay path trace data such as delay times, transmission timestamps, network probe ID information, SD-WAN link information, “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106. When the network probes are received at SDN enabled device 105c, delay times are calculated by subtracting the transmission timestamp for each network probe from the received time for each network probe. In some examples, SDN enabled device 105c generates a reply (either a single reply for all network probes in the series of network probes, or a reply for each network probe) that includes delay times for each network probe and transmits the reply to SDN enabled device 105a. In some other examples, SDN enabled device 105c transmits the delay times, along with additional information, such as the transmission timestamps, network probe ID information, and SD-WAN link information, to the network orchestrator.”);
using the underlay path trace data, determining attributes associated with portions of the underlay paths;
determining, based at least in part on the attributes associated with portions of the underlay paths, a policy indicating one or more portions of the underlay paths that are associated with an attribute for an entity associated with the edge device; and
sending the policy to the (ZAD TOOTAGHAJ teaches using the underlay path trace data, to determine attributes, such as congestion, associated with portions of the underlay paths. ZAD TOOTAGHAJ also teaches determining a policy, cheapest business cost while maintain a QoS requirement, indicating one or more portions of the underlay paths that are associated with congestion for an entity, network administrator, associated with the SDN enabled device/ SD-WAN infrastructure device. ZAD further teaches sending the policy to the SDN enabled device/SD-WAN infrastructure device, “[0015] Simply finding the most efficient path across the SD-WAN (overlay network) to the destination isn't the only concern. Physical links have business costs associated with them, and the costs for each link can conform to one of a number of models. For example, an ISP may charge a flat monthly rate for a DSL link between two WAN sites. In another model, the ISP may charge a flat monthly rate for the DSL link as long as monthly bandwidth usage is less than 100 GB, and then charge a per-GB rate for all data transacted over 100 GB. In yet another model, the ISP may only charge a per-GB rate for usage of the link. [0016] A cost-conscious network administrator may prefer to route network traffic in a way that costs the least while still maintaining quality of service (QoS) requirements for each type of network traffic. For example, routing streaming video traffic through the cheapest and lowest QoS route may cost less than routing the streaming video traffic through a more expensive route, but the cheapest route may violate QoS requirements for the streaming video traffic…[0017] In this disclosure, a two phase process infers underlay physical network topologies of a SD-WAN and determines a minimum cost routing solution constrained by QoS requirements and physical link limitations for all SD-WAN flows. One example consistent with this disclosure is a linear integer programming formulation which can be solved using different ILP (integer linear programming) optimization toolkits such as gurobi or CPLEX. Since this problem formulation is NP-Hard and intractable for large networks, examples consistent with this disclosure include a greedy and a heuristic approach to solve it in a timely manner. [0018] In the first phase, software defined networking (SDN) enabled network infrastructure devices of the SD-WAN may send network probes across certain SD-WAN links to determine delay times for the certain SD-WAN links. Some links may include multiple interfaces, such as when multiple redundant uplinks connect a pair of SD-WAN sites using multiple ISPs, communication technologies, or combinations thereof. The delay times are then received at the network orchestrator. The network orchestrator then determines a correlation between each pair of SD-WAN links. In some examples, the correlation corresponds to whether the pair of SD-WAN links shares a congested physical link, like the ISP router described in paragraph 0014. However, the correlation may also capture additional relationships, such as when a pair of SD-WAN links does not share a congested physical link, but each link of the pair of SD-WAN links shares a congested physical link with a third SD-WAN link….[0025] Once each flow from the flow order has had a least costly path selected, the routing solution is complete. The network orchestrator proceeds to generate a new flow order optimizing for a different flow, and calculates a routing solution calculated optimizing for each flow of the SD-WAN, the network orchestrator selects a total minimum cost routing solution based on a minimum total operational cost when comparing total operational costs of each routing solution. The total minimum cost routing solution is then implemented by sending flow rules to SD-WAN infrastructure devices that modify their routing behaviors to be congruent with the total minimum cost routing solution…[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links…[0066] A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.”).
ZAD TOOTAGHAJ (US 20210392070 A1) differs from claim 13, in that ZAD TOOTAGHAJ (US 20210392070 A1) is silent on where the device (i.e. SD-WAN device) comprises an edge device. Despite these differences similar features have seen in other prior art involving software defined (SD) Wide Area Network(s) (WANs). KUMAR (US 11381474 B1) teaches a feature for SD-WAN where a device that performs monitoring comprises a SD-WAN edge device, the monitoring being regarded as analogous to the probing feature of ZAD TOOTAGHAJ ([Col. 8, Line 59 – Col 9, Line 25] “SD-WAN edges 108 process and forward received network traffic for SD-WAN service 101 according to policies and configuration data from service orchestrator 102, routing information, and current network conditions including underly connection performance characteristics. In some examples, service orchestrator 102 may push SLA parameters, path selection parameters and related configuration to SD-WAN edges 108, and SD-WAN edges 108 monitors the links for SLA violations and can switch an application to a different one of WAN links 142. SD-WAN edges 108 may thereby implement the data plane functionality of SD-WAN service 101 over the underlay connections including, in such examples, application switching to different WAN links 142 for application QoE. If there is an SLA violation detected by one of SD-WAN edges 108, the SD-WAN edge may report and send log messages to service orchestrator 102 describing the SLA violation and the selected WAN link. SD-WAN edges 108 may also aggregate, optionally average, and report SLA metrics for WAN links 142 in log messages to service orchestrator 102. In some examples, service orchestrator 102 may receive SLA metrics from SD-WAN edges 108, determine an SLA for an application has been violated, and perform path selection to select a new one of WAN links 142 for the SLA-violated application. Service orchestrator 102 may then configure one or more of SD-WAN edges 108 to switch the application traffic for the application on the new WAN link. SLA metric analysis, SLA evaluation, path selection, and link switching functionality are all performed by SD-WAN system 100, but different examples of SD-WAN system 100 may have a different distribution of control plane functionality between service orchestrator 102 and SD-WAN edges 108 than those examples just described. However, such functionality is described below primarily with respect to SD-WAN edges 108.”, [Col. 9, Line 61 – Col. 10, Line 17] “(31) To monitor the SLA compliance of the link on which the application traffic is sent, service orchestrator 102 may cause SD-WAN edges 108 to send inline probes along WAN links 142 (in some cases along with the application traffic already being sent). These inline probes may be referred to as “passive probes.” To identify the best available one of WAN links 142 for an application in case the active WAN link fails to meet the SLA criteria, service orchestrator 102 monitors and collects SLA compliance data for other available WAN links 142 for SD-WAN service 101. The probes that service orchestrator 102 sends over other WAN links 142 to check the SLA compliance may be referred to as “active probes.” The active probes are carried out based on probe parameters provided in some cases by the subscriber. Active and passive probe measurements are used for an end-to-end analysis of WAN links 142. The data collected by active and passive probing is used for monitoring the network for sources of failures or congestion. If there is a violation detected for any application or group of multiple applications (“application group”), service orchestrator 102 evaluates the synthetic probe metrics to determine a satisfactory, and in some cases best, WAN link 142 that satisfies the SLA. As used herein, reference to an application may refer to a single application or any application group.”).
Thus, based upon the teachings of KUMAR (US 11381474 B1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN device of ZAD TOOTAGHAJ, to comprise an edge device, as similarly seen in the SD-WAN feature of KUMAR, in order to provide a reliable means to implement the desired monitoring/probing functionality taught by ZAD TOOTAGHAJ.
In regards to claim 3, The combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR suggests the method of claim 1, the attribute including: a geographic location; a particular internet service provider; a network outage; or a network hotspot (ZAD TOOTAGHAJ teaches where the attribute includes a network hotpsot, a congested link, “[0018] In the first phase, software defined networking (SDN) enabled network infrastructure devices of the SD-WAN may send network probes across certain SD-WAN links to determine delay times for the certain SD-WAN links. Some links may include multiple interfaces, such as when multiple redundant uplinks connect a pair of SD-WAN sites using multiple ISPs, communication technologies, or combinations thereof. The delay times are then received at the network orchestrator. The network orchestrator then determines a correlation between each pair of SD-WAN links. In some examples, the correlation corresponds to whether the pair of SD-WAN links shares a congested physical link, like the ISP router described in paragraph 0014. However, the correlation may also capture additional relationships, such as when a pair of SD-WAN links does not share a congested physical link, but each link of the pair of SD-WAN links shares a congested physical link with a third SD-WAN link..”).
In regards to claim 9, he combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR suggests the system of claim 7, the attribute including: a geographic location; a particular internet service provider; a network outage; or a network hotspot (ZAD TOOTAGHAJ teaches where the attribute includes a network hotpsot, a congested link, “[0018] In the first phase, software defined networking (SDN) enabled network infrastructure devices of the SD-WAN may send network probes across certain SD-WAN links to determine delay times for the certain SD-WAN links. Some links may include multiple interfaces, such as when multiple redundant uplinks connect a pair of SD-WAN sites using multiple ISPs, communication technologies, or combinations thereof. The delay times are then received at the network orchestrator. The network orchestrator then determines a correlation between each pair of SD-WAN links. In some examples, the correlation corresponds to whether the pair of SD-WAN links shares a congested physical link, like the ISP router described in paragraph 0014. However, the correlation may also capture additional relationships, such as when a pair of SD-WAN links does not share a congested physical link, but each link of the pair of SD-WAN links shares a congested physical link with a third SD-WAN link..”).
In regards to claim 16, he combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR suggests the one or more non-transitory computer-readable media of claim 13, wherein the attribute is an undesirable attribute for the entity associated with the edge device, the undesirable attribute including: a high-risk geographic location; a high-risk internet service provider; a network outage; or a network hotspot (ZAD TOOTAGHAJ teaches where the attribute includes a network hotpsot, a congested link, “[0018] In the first phase, software defined networking (SDN) enabled network infrastructure devices of the SD-WAN may send network probes across certain SD-WAN links to determine delay times for the certain SD-WAN links. Some links may include multiple interfaces, such as when multiple redundant uplinks connect a pair of SD-WAN sites using multiple ISPs, communication technologies, or combinations thereof. The delay times are then received at the network orchestrator. The network orchestrator then determines a correlation between each pair of SD-WAN links. In some examples, the correlation corresponds to whether the pair of SD-WAN links shares a congested physical link, like the ISP router described in paragraph 0014. However, the correlation may also capture additional relationships, such as when a pair of SD-WAN links does not share a congested physical link, but each link of the pair of SD-WAN links shares a congested physical link with a third SD-WAN link…”).
In regards to claim 4, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR suggests the method of claim 1, wherein enabling the path trace further includes: sending, from the edge device, path traces over the underlay paths; and receiving underlay path trace data indicating the segments of the underlay paths. With regards to the method of claim 1, the combination of ZAD TOOTAGHAJ in view of KUMAR is believed to arrive at the method of claim 1, and more specifically the edge device, for the same reasoning provided with respect to claim 1 above. With respect to the remaining features of claim 4, ZAD TOOTAGHAJ teaches wherein enabling the path trace further includes: sending, from the device, path traces over the underlay paths; and receiving underlay path trace data indicating the segments of the underlay paths (ZAD TOOTAGHAJ teaches enabling at a device, SDN enabled device /SD-WAN infrastructure device , a path trace of underlay paths, by sending network probes along an underlay route, between the SDN/enabled device/SD-WAN infrastructure device and a remote device, SDN enabled device 105c, and receiving underlay path trace data, underlay path trace data such as delay times, transmission timestamps, network probe ID information, SD-WAN link information indicating the segments of the underlay paths “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106. When the network probes are received at SDN enabled device 105c, delay times are calculated by subtracting the transmission timestamp for each network probe from the received time for each network probe. In some examples, SDN enabled device 105c generates a reply (either a single reply for all network probes in the series of network probes, or a reply for each network probe) that includes delay times for each network probe and transmits the reply to SDN enabled device 105a. In some other examples, SDN enabled device 105c transmits the delay times, along with additional information, such as the transmission timestamps, network probe ID information, and SD-WAN link information, to the network orchestrator.”), thus the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, is believed to arrive at claim 4, where the device of TOOTAGHAJ comprises an edge device for substantially the same reasoning relied upon the motivate the combination to arrive at the edge device in claim 1.
In regards to claim 10, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR suggests the system of claim 7, wherein enabling the path trace further includes: sending, from the edge device, path traces over the underlay paths; and receiving underlay path trace data indicating the segments of the underlay paths. With regards to the system of claim 7, the combination of ZAD TOOTAGHAJ in view of KUMAR is believed to arrive at the system of claim 7, and more specifically the edge device, for the same reasoning provided with respect to claim 7 above. With respect to the remaining features of claim 10, ZAD TOOTAGHAJ teaches wherein enabling the path trace further includes: sending, from the device, path traces over the underlay paths; and receiving underlay path trace data indicating the segments of the underlay paths (ZAD TOOTAGHAJ teaches enabling at a device, SDN enabled device /SD-WAN infrastructure device , a path trace of underlay paths, by sending network probes along an underlay route, between the SDN/enabled device/SD-WAN infrastructure device and a remote device, SDN enabled device 105c, and receiving underlay path trace data, underlay path trace data such as delay times, transmission timestamps, network probe ID information, SD-WAN link information indicating the segments of the underlay paths “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106. When the network probes are received at SDN enabled device 105c, delay times are calculated by subtracting the transmission timestamp for each network probe from the received time for each network probe. In some examples, SDN enabled device 105c generates a reply (either a single reply for all network probes in the series of network probes, or a reply for each network probe) that includes delay times for each network probe and transmits the reply to SDN enabled device 105a. In some other examples, SDN enabled device 105c transmits the delay times, along with additional information, such as the transmission timestamps, network probe ID information, and SD-WAN link information, to the network orchestrator.”), thus the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, is believed to arrive at claim 10, where the device of TOOTAGHAJ comprises an edge device for substantially the same reasoning relied upon the motivate the combination to arrive at the edge device in claim 7.
Claim(s) 2, 5, 11, 14, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR (US 11381474 B1) in view of ZHAO (US 20190334820 A1)
In regards to claim 2, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the method of claim 1, wherein the policy is a first policy and the attribute is a first attribute, the method further comprising:
receiving, from the control plane, a second policy indicating segments of the underlay paths that are associated with a second attribute for the entity associated with the edge device; determining whether the second attribute indicates that the segments of the underlay paths are to be avoided or included in a second underlay path, wherein: in response to the second attribute indicating that the segments are to be avoided, identifying the second underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the second attribute are avoided; or in response to the second attribute indicating that the segments are to be included, identifying the second underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the second attribute are included; and routing data on behalf of the entity through the second underlay path instead of the first underlay path.
However, ZAD TOOTAGHAJ in view of KUMAR teaches many of the features seen in claim 2, being performed with respect to a (first) policy and an (first) attribute of an attribute for an entity associated with the edge device. Refer to claim 1, where the combination of ZAD TOOTAGHAJ in view of KUMAR was found to teach a method performed at least in part by an edge device of a software-defined wide area network (SD-WAN), the method comprising: enabling, at the edge device, a path trace of underlay paths between the edge device and a remote device, sending, from the ; receiving, from the control plane, a policy indicating segments of the underlay paths that are associated with an attribute for an entity associated with the ; determining whether the attribute indicates that the segments of the underlay paths are to be avoided or included in a first underlay path, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are avoided; or in response to the attribute indicating that the segments are to be included, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are included; and routing data on behalf of the entity through the first underlay path. Thus, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR differs from claim 2, mainly in that ZAD TOOTAGHAJ in view of KUMAR is silent on applying an additional (second) policy associated with additional (second) attribute, and routing data on a second underlay path determined based upon the second policy and second attribute instead of the first underlay path.
ZHAO for example teaches a feature directed to SD-WANs (“[0003] A software-defined wide area network (SD-WAN) is a new type of wide area network architecture that can centrally control wide area network traffic on a plurality of paths…[0004] As shown in FIG. 1, the SD-WAN includes a controller and a plurality of customer-premises equipments (CPE)…”). ZHAO further teaches with respect to SD-WANs a feature pertaining to an additional/second policy, new routing policy and further suggests routing data on a second path instead of a first path based on the new routing policy and a second attribute, path score. (“[0086] In another embodiment of the present invention, an original routing policy of the first customer-premises equipment includes at least one service application, and a priority, a primary path, and a secondary path that are corresponding to each of the at least one service application; and the determining module 12 is configured to: determine a service application whose priority is higher than a preset priority in the at least one service application, as a target application, where a primary path corresponding to the target application is a first path; determine a path score of the first path; and when the path score of the first path is less than a second threshold, change the primary path corresponding to the target application from the first path to any path whose path score is greater than a first threshold, to obtain a new routing policy of the first customer-premises equipment.”). ZHAO suggests performing this feature in order to avoid congested paths and to provide more reliable, stable, and secure data transmission(“[0006] Embodiments of the present invention provide a routing method and apparatus, to resolve a prior-art problem that a path becomes busy and congested when a plurality of branches simultaneously use the path to transmit data packets to headquarters… [0077] According to the method provided in this embodiment of the present invention, path quality of each path can be scored based on the path measurement message obtained after the first customer-premises equipment measures each of the at least two paths between the first customer-premises equipment and the second customer-premises equipment and according to the preset rule; the routing policy suitable for a current network-wide path status is automatically generated based on the path scores; and the generated routing policy is automatically delivered to the first customer-premises equipment and the second customer-premises equipment, to ensure that the customer-premises equipments in an entire network can transmit a data packet sent by a service application more quickly, stably, and securely. This improves data packet transmission quality.”).
Thus, based upon the teachings of ZHAO a person of ordinary skill in the art would have been motivated before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ in view of KUMAR, to adopt use of second policy and a second attribute to determine a second route/second path (i.e. second underlay path), as similarly seen in ZHAO, to thus arrive at claim 2, in order to provide a benefit of avoiding congested paths and providing more reliable, stable, and secure data transmission, based upon additional/second attribute information.
In regards to claim 14, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the one or more non-transitory computer-readable media of claim 13, wherein the policy is a first policy and the attribute is a first attribute, the operations further comprising: determining, based at least in part on the attributes associated with portions of the underlay paths, a second policy indicating one or more portions of the underlay paths that are associated with a second attribute for the entity associated with the edge device; and sending the second policy to the edge device.
However, ZAD TOOTAGHAJ in view of KUMAR teaches many of the features seen in claim 14, being performed with respect to a (first) policy and an (first) attribute of an attribute for an entity associated with the edge device. ZAD TOOTAGHAJ is believed to teach a method performed at least in part by a device of a software-defined wide area network (SD-WAN), the method comprising: determining, based at least in part on attribute associated with portions of the underlay paths a policy associated indicating one or more portions of the underlay paths that are associated with an attribute for the entity associated with the device, and sending the policy to the device (ZAD TOOTAGHAJ teaches determining based on an attribute associated with portions of an underlay paths, congestion of an underlay path, a policy indicating one or more portions of the underlay paths are to be avoided/undesired or included/desired in a first underlay path for an entity, network administrator, associated with the SDN devices and sending the policy to the SDN devices, by configuring/reconfiguring the SDN devices, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path (i.e. underlay route 112, underlay route 116) for sending data on behalf of the network administrator associated with the, SDN enabled device/SD-WAN infrastructure device, such that the segments of the underlay paths (i.e. segments of underlay route 106), that are associated with the congested underlay path are avoided, or in response to the attribute indicating that the segments (i.e. segments of underlay route 106, in a case where there is a high correlation between SD-WAN links 108 and 114) are to be included, identifying the first underlay path (i.e. underlay route 106) for sending data on behalf of the network administrator associated with the SD-Enabled/ SD-WAN Infrastructure Device such that the segments of the underlay paths that are associated with the attributed are included (i.e. , and routing data on behalf of the network administrator through the first underlay path), and routing data (i.e. flows) on behalf of the network administrator through the first underlay path “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106…[0032]…The network orchestrator may analyze data across pairs of SD-WAN links for correlation…Correlation between pairs of SD-WAN links may indicate direct or indirect shared congested underlay links. For example, if network change 110a is congestion across the link between device 103 and device 105c, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link), but delay times for network probes assigned to SD-WAN link 114 may not increase (because associated underlay route 112 does not pass through the congested link). This will result in a reduced correlation between SD-WAN link 108 and SD-WAN link 114. However, if network change 110b is congestion across the link between device 105a and device 103, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link) and delay times for network probes assigned to SD-WAN link 114 may increase (because associated underlay route 112 also passes through the congested link). This will result in an increased correlation between SD-WAN links 108 and 114….[0033] Correlation information can be used to make routing decisions. For example, if network change 110a is causing packets of flow routed across SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a low correlation between SD-WAN links 108 and 114, that network change 110a can be bypassed by moving flows routed across SD-WAN link 108 to instead use SD-WAN link 114 and SD-WAN link 118 to reach SDN enabled device 105c. As another example, if network change 110b is causing packets of flow routed through SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a high correlation between SD-WAN links 108 and 114, that network change 110b cannot be bypassed by moving flow routed across SD-WAN link 108 to SD-WAN link 114, since underlay route 112 also uses the link affected by network change 110b. Flows routed across SD-WAN link 108 may be worse off being routed around underlay route 112 rather than staying with underlay route 106. In FIG. 1, as well as in the rest of this disclosure, SD-WAN links are shown as unidirectional data paths….[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links.
[0054] FIG. 5 illustrates an example network orchestrator including instructions to reconfigure SD-WAN routes. Network orchestrator 500 includes processing circuitry 501 and memory 502. Memory 502 includes routing solutions 504, a total minimum cost routing solution 510, and instructions for determining routing solutions and the total minimum cost routing solution (not shown). Network orchestrator 500 may be a physical device, as illustrated in FIG. 5, or may be deployed as a cloud service, network service, virtualized device, or any other appropriate deployment method.”).
With respect to where the device of ZAD TOOTAGHAJ comprises an edge device, the combination of ZAD TOOTAGHAJ in view of KUMAR, the combination of ZAD TOOTAGHAJ in view of KUMAR is believed to arrive at wherein the device comprises an edge device for the same reasons motivated to arrive at the edge device of claim 13. Thus, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR has been found to differ from claim 14, mainly in that ZAD TOOTAGHAJ in view of KUMAR is silent on applying an additional (second) policy associated with additional (second) attribute, and routing data on a second underlay path determined based upon the second policy and second attribute instead of the first underlay path. Despite these differences similar features have been seen in other prior art involving Software Defined Wide Area Network SD-WANs.
ZHAO for example teaches a feature directed to SD-WANs (“[0003] A software-defined wide area network (SD-WAN) is a new type of wide area network architecture that can centrally control wide area network traffic on a plurality of paths…[0004] As shown in FIG. 1, the SD-WAN includes a controller and a plurality of customer-premises equipments (CPE)…”). ZHAO further teaches with respect to SD-WANs a feature pertaining to an additional/second policy, new routing policy and further suggests routing data on a second path instead of a first path based on the new routing policy and a second attribute, path score. (“[0086] In another embodiment of the present invention, an original routing policy of the first customer-premises equipment includes at least one service application, and a priority, a primary path, and a secondary path that are corresponding to each of the at least one service application; and the determining module 12 is configured to: determine a service application whose priority is higher than a preset priority in the at least one service application, as a target application, where a primary path corresponding to the target application is a first path; determine a path score of the first path; and when the path score of the first path is less than a second threshold, change the primary path corresponding to the target application from the first path to any path whose path score is greater than a first threshold, to obtain a new routing policy of the first customer-premises equipment.”). ZHAO suggests performing this feature in order to avoid congested paths and to provide more reliable, stable, and secure data transmission(“[0006] Embodiments of the present invention provide a routing method and apparatus, to resolve a prior-art problem that a path becomes busy and congested when a plurality of branches simultaneously use the path to transmit data packets to headquarters… [0077] According to the method provided in this embodiment of the present invention, path quality of each path can be scored based on the path measurement message obtained after the first customer-premises equipment measures each of the at least two paths between the first customer-premises equipment and the second customer-premises equipment and according to the preset rule; the routing policy suitable for a current network-wide path status is automatically generated based on the path scores; and the generated routing policy is automatically delivered to the first customer-premises equipment and the second customer-premises equipment, to ensure that the customer-premises equipments in an entire network can transmit a data packet sent by a service application more quickly, stably, and securely. This improves data packet transmission quality.”).
Thus, based upon the teachings of ZHAO a person of ordinary skill in the art would have been motivated before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ in view of KUMAR, to adopt use of second policy and a second attribute to determine a second route/second path (i.e. second underlay path), as similarly seen in ZHAO, to thus arrive at claim 14, in order to provide a benefit of avoiding congested paths and providing more reliable, stable, and secure data transmission, based upon additional/second attribute information.
In regards to claim 17, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the one or more non-transitory computer-readable media of claim 13, wherein the policy is a first policy, the operations further comprising: determining, based at least in part on the attributes associated with portions of the underlay paths, a second policy indicating one or more portions of the underlay paths that are associated with a desirable attribute for the entity associated with the edge device; and sending the second policy to the edge device.
However, ZAD TOOTAGHAJ in view of KUMAR teaches many of the features seen in claim 17, being performed with respect to a (first) policy and an (first) attribute of an attribute for an entity associated with the edge device. ZAD TOOTAGHAJ is believed to teach a method performed at least in part by a device of a software-defined wide area network (SD-WAN), the method comprising: determining, based at least in part on attribute associated with portions of the underlay paths a policy associated indicating one or more portions of the underlay paths that are associated with a desirable attribute for the entity associated with the device, and sending the policy to the device (ZAD TOOTAGHAJ teaches determining based on an attribute associated with portions of an underlay paths, congestion of an underlay path, a policy indicating one or more portions of the underlay paths are to be avoided/undesired or included/desired in a first underlay path for an entity, network administrator, associated with the SDN devices and sending the policy to the SDN devices, by configuring/reconfiguring the SDN devices, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path (i.e. underlay route 112, underlay route 116) for sending data on behalf of the network administrator associated with the, SDN enabled device/SD-WAN infrastructure device, such that the segments of the underlay paths (i.e. segments of underlay route 106), that are associated with the congested underlay path are avoided, or in response to the attribute indicating that the segments (i.e. segments of underlay route 106, in a case where there is a high correlation between SD-WAN links 108 and 114) are to be included, identifying the first underlay path (i.e. underlay route 106) for sending data on behalf of the network administrator associated with the SD-Enabled/ SD-WAN Infrastructure Device such that the segments of the underlay paths that are associated with the attributed are included (i.e. , and routing data on behalf of the network administrator through the first underlay path), and routing data (i.e. flows) on behalf of the network administrator through the first underlay path “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106…[0032]…The network orchestrator may analyze data across pairs of SD-WAN links for correlation…Correlation between pairs of SD-WAN links may indicate direct or indirect shared congested underlay links. For example, if network change 110a is congestion across the link between device 103 and device 105c, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link), but delay times for network probes assigned to SD-WAN link 114 may not increase (because associated underlay route 112 does not pass through the congested link). This will result in a reduced correlation between SD-WAN link 108 and SD-WAN link 114. However, if network change 110b is congestion across the link between device 105a and device 103, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link) and delay times for network probes assigned to SD-WAN link 114 may increase (because associated underlay route 112 also passes through the congested link). This will result in an increased correlation between SD-WAN links 108 and 114….[0033] Correlation information can be used to make routing decisions. For example, if network change 110a is causing packets of flow routed across SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a low correlation between SD-WAN links 108 and 114, that network change 110a can be bypassed by moving flows routed across SD-WAN link 108 to instead use SD-WAN link 114 and SD-WAN link 118 to reach SDN enabled device 105c. As another example, if network change 110b is causing packets of flow routed through SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a high correlation between SD-WAN links 108 and 114, that network change 110b cannot be bypassed by moving flow routed across SD-WAN link 108 to SD-WAN link 114, since underlay route 112 also uses the link affected by network change 110b. Flows routed across SD-WAN link 108 may be worse off being routed around underlay route 112 rather than staying with underlay route 106. In FIG. 1, as well as in the rest of this disclosure, SD-WAN links are shown as unidirectional data paths….[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links.
[0054] FIG. 5 illustrates an example network orchestrator including instructions to reconfigure SD-WAN routes. Network orchestrator 500 includes processing circuitry 501 and memory 502. Memory 502 includes routing solutions 504, a total minimum cost routing solution 510, and instructions for determining routing solutions and the total minimum cost routing solution (not shown). Network orchestrator 500 may be a physical device, as illustrated in FIG. 5, or may be deployed as a cloud service, network service, virtualized device, or any other appropriate deployment method.”).
With respect to where the device of ZAD TOOTAGHAJ comprises an edge device, the combination of ZAD TOOTAGHAJ in view of KUMAR is believed to arrive at wherein the device comprises an edge device for the same reasons motivated to arrive at the edge device of claim 13. Thus, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR has been found to differ from claim 17, mainly in that ZAD TOOTAGHAJ in view of KUMAR is silent on applying an additional (second) policy associated with additional (second) attribute, and routing data on a second underlay path determined based upon the second policy and second attribute instead of the first underlay path. Despite these differences similar features have been seen in other prior art involving Software Defined Wide Area Network SD-WANs.
ZHAO for example teaches a feature directed to SD-WANs (“[0003] A software-defined wide area network (SD-WAN) is a new type of wide area network architecture that can centrally control wide area network traffic on a plurality of paths…[0004] As shown in FIG. 1, the SD-WAN includes a controller and a plurality of customer-premises equipments (CPE)…”). ZHAO further teaches with respect to SD-WANs a feature pertaining to an additional/second policy, new routing policy and further suggests routing data on a second path instead of a first path based on the new routing policy and a second attribute, path score. (“[0086] In another embodiment of the present invention, an original routing policy of the first customer-premises equipment includes at least one service application, and a priority, a primary path, and a secondary path that are corresponding to each of the at least one service application; and the determining module 12 is configured to: determine a service application whose priority is higher than a preset priority in the at least one service application, as a target application, where a primary path corresponding to the target application is a first path; determine a path score of the first path; and when the path score of the first path is less than a second threshold, change the primary path corresponding to the target application from the first path to any path whose path score is greater than a first threshold, to obtain a new routing policy of the first customer-premises equipment.”). ZHAO suggests performing this feature in order to avoid congested paths and to provide more reliable, stable, and secure data transmission(“[0006] Embodiments of the present invention provide a routing method and apparatus, to resolve a prior-art problem that a path becomes busy and congested when a plurality of branches simultaneously use the path to transmit data packets to headquarters… [0077] According to the method provided in this embodiment of the present invention, path quality of each path can be scored based on the path measurement message obtained after the first customer-premises equipment measures each of the at least two paths between the first customer-premises equipment and the second customer-premises equipment and according to the preset rule; the routing policy suitable for a current network-wide path status is automatically generated based on the path scores; and the generated routing policy is automatically delivered to the first customer-premises equipment and the second customer-premises equipment, to ensure that the customer-premises equipments in an entire network can transmit a data packet sent by a service application more quickly, stably, and securely. This improves data packet transmission quality.”).
Thus, based upon the teachings of ZHAO, a person of ordinary skill in the art would have been motivated before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ in view of KUMAR, to adopt use of a second policy and a second attribute to determine a second route/second path (i.e. second underlay path), as similarly seen in ZHAO, to thus arrive at claim 17, in order to provide a benefit of avoiding congested paths and providing more reliable, stable, and secure data transmission, based upon additional/second attribute information.
In regards to claim 5, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the method of claim 1, wherein the policy is a first policy, the method further comprising: receiving, from the control plane, a second policy indicating segments of the underlay paths that include an undesirable attribute for the entity associated with the edge device; identifying a second underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the undesirable attribute are avoided; and routing data on behalf of the entity through the second underlay path.
However, ZAD TOOTAGHAJ in view of KUMAR teaches many of the features seen in claim 5, being performed with respect to a (first) policy and an (first) attribute of an attribute for an entity associated with the edge device. Refer to claim 1, where the combination of ZAD TOOTAGHAJ in view of KUMAR was found to teach a method performed at least in part by an edge device of a software-defined wide area network (SD-WAN), the method comprising: receiving, from the control plane, a policy indicating segments of the underlay paths that are associated with an attribute for an entity associated with the ; determining whether the attribute indicates that the segments of the underlay paths are to be avoided/undesirable or included/desirable in a first underlay path, wherein: in response to the attribute indicating that the segments are to be avoided/undesirable, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are avoided; or in response to the attribute indicating that the segments are to be included/desirable, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are included; and routing data on behalf of the entity through the first underlay path. Thus, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR differs from claim 2, mainly in that ZAD TOOTAGHAJ in view of KUMAR is silent on applying an additional (second) policy associated with additional (second) attribute, and routing data on a second underlay path determined based upon the second policy and second attribute instead of the first underlay path.
ZHAO for example teaches a feature directed to SD-WANs (“[0003] A software-defined wide area network (SD-WAN) is a new type of wide area network architecture that can centrally control wide area network traffic on a plurality of paths…[0004] As shown in FIG. 1, the SD-WAN includes a controller and a plurality of customer-premises equipments (CPE)…”). ZHAO further teaches with respect to SD-WANs a feature pertaining to an additional/second policy, new routing policy and further suggests routing data on a second path instead of a first path based on the new routing policy and a second attribute, path score. (“[0086] In another embodiment of the present invention, an original routing policy of the first customer-premises equipment includes at least one service application, and a priority, a primary path, and a secondary path that are corresponding to each of the at least one service application; and the determining module 12 is configured to: determine a service application whose priority is higher than a preset priority in the at least one service application, as a target application, where a primary path corresponding to the target application is a first path; determine a path score of the first path; and when the path score of the first path is less than a second threshold, change the primary path corresponding to the target application from the first path to any path whose path score is greater than a first threshold, to obtain a new routing policy of the first customer-premises equipment.”). ZHAO suggests performing this feature in order to avoid congested paths and to provide more reliable, stable, and secure data transmission(“[0006] Embodiments of the present invention provide a routing method and apparatus, to resolve a prior-art problem that a path becomes busy and congested when a plurality of branches simultaneously use the path to transmit data packets to headquarters… [0077] According to the method provided in this embodiment of the present invention, path quality of each path can be scored based on the path measurement message obtained after the first customer-premises equipment measures each of the at least two paths between the first customer-premises equipment and the second customer-premises equipment and according to the preset rule; the routing policy suitable for a current network-wide path status is automatically generated based on the path scores; and the generated routing policy is automatically delivered to the first customer-premises equipment and the second customer-premises equipment, to ensure that the customer-premises equipments in an entire network can transmit a data packet sent by a service application more quickly, stably, and securely. This improves data packet transmission quality.”).
Thus, based upon the teachings of ZHAO a person of ordinary skill in the art would have been motivated before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ in view of KUMAR, to adopt use of second policy and a second attribute to determine a second route/second path (i.e. second underlay path), as similarly seen in ZHAO, to thus arrive at claim 5, in order to provide a benefit of avoiding congested paths and providing more reliable, stable, and secure data transmission, based upon additional/second attribute information.
In regards to claim 11, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the system of claim 7, wherein the policy is a first policy, the operations further comprising: receiving, from the control plane, a second policy indicating segments of the underlay paths that include an undesirable attribute for the entity associated with the edge device; identifying a second underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the undesirable attribute are avoided; and routing data on behalf of the entity through the second underlay path.
However, ZAD TOOTAGHAJ in view of KUMAR teaches many of the features seen in claim 11, being performed with respect to a (first) policy and an (first) attribute of an attribute for an entity associated with the edge device. Refer to claim 7, where the combination of ZAD TOOTAGHAJ in view of KUMAR was found to teach receiving, from the control plane, a policy indicating segments of the underlay paths that are associated with an attribute for an entity associated with the ; determining whether the attribute indicates that the segments of the underlay paths are to be avoided/undesirable or included/desirable in a first underlay path, wherein: in response to the attribute indicating that the segments are to be avoided/undesirable, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are avoided; or in response to the attribute indicating that the segments are to be included/desirable, identifying the first underlay path for sending data on behalf of the entity associated with the edge device such that the segments of the underlay paths that are associated with the attribute are included; and routing data on behalf of the entity through the first underlay path. Thus, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR differs from claim 11, mainly in that ZAD TOOTAGHAJ in view of KUMAR is silent on applying an additional (second) policy associated with additional (second) attribute, and routing data on a second underlay path determined based upon the second policy and second attribute instead of the first underlay path.
ZHAO for example teaches a feature directed to SD-WANs (“[0003] A software-defined wide area network (SD-WAN) is a new type of wide area network architecture that can centrally control wide area network traffic on a plurality of paths…[0004] As shown in FIG. 1, the SD-WAN includes a controller and a plurality of customer-premises equipments (CPE)…”). ZHAO further teaches with respect to SD-WANs a feature pertaining to an additional/second policy, new routing policy and further suggests routing data on a second path instead of a first path based on the new routing policy and a second attribute, path score. (“[0086] In another embodiment of the present invention, an original routing policy of the first customer-premises equipment includes at least one service application, and a priority, a primary path, and a secondary path that are corresponding to each of the at least one service application; and the determining module 12 is configured to: determine a service application whose priority is higher than a preset priority in the at least one service application, as a target application, where a primary path corresponding to the target application is a first path; determine a path score of the first path; and when the path score of the first path is less than a second threshold, change the primary path corresponding to the target application from the first path to any path whose path score is greater than a first threshold, to obtain a new routing policy of the first customer-premises equipment.”). ZHAO suggests performing this feature in order to avoid congested paths and to provide more reliable, stable, and secure data transmission(“[0006] Embodiments of the present invention provide a routing method and apparatus, to resolve a prior-art problem that a path becomes busy and congested when a plurality of branches simultaneously use the path to transmit data packets to headquarters… [0077] According to the method provided in this embodiment of the present invention, path quality of each path can be scored based on the path measurement message obtained after the first customer-premises equipment measures each of the at least two paths between the first customer-premises equipment and the second customer-premises equipment and according to the preset rule; the routing policy suitable for a current network-wide path status is automatically generated based on the path scores; and the generated routing policy is automatically delivered to the first customer-premises equipment and the second customer-premises equipment, to ensure that the customer-premises equipments in an entire network can transmit a data packet sent by a service application more quickly, stably, and securely. This improves data packet transmission quality.”).
Thus, based upon the teachings of ZHAO a person of ordinary skill in the art would have been motivated before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ in view of KUMAR, to adopt use of second policy and a second attribute to determine a second route/second path (i.e. second underlay path), as similarly seen in ZHAO, to thus arrive at claim 11, in order to provide a benefit of avoiding congested paths and providing more reliable, stable, and secure data transmission, based upon additional/second attribute information.
Claim(s) 6, 12, and 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR (US 11381474 B1) in view of ARANHA (“US 20180302320 A1”).
In regards to claim 6, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the method of claim 1, wherein the policy is based at least in part on an entity input indicating the attribute for the entity associated with the edge device. Despite these differences similar features have been seen in other prior art involving software defined wide area networks (SD-WAN).
ARANHA (“US 20180302320 A1”) for example teaches a feature where with respect to a SD-WAN, a policy is based at least in part on an entity input indicating an attribute associated with an edge device (“[0037] As another example, with IP forwarding, the edge network devices 110 may include one or more policies to route packets via a particular type of communication link in an IP network. For example, such a policy may take into account factors such as packet size, services specified by a header, characteristics of potential links to other routers in the network, and/or others. Using such factors, the edge network devices 110 may forward packets based on a selected algorithm, such as a shortest path. …[0049] In some embodiments, the system 200 may include a network management device 290 that may communicate with the control devices 220 over a management network 232. The network management device 290 may provide management and control of one or more devices associated with the internal network domain 205, including the edge network devices 210, the control devices 220, and/or others. For example, the network management device 290 may provide a graphical user interface (GUI) that provides a network administrator with access to control or observe operation of the internal network domain 205. In some embodiments, the network administrator may input policies via the network management device 290 that may be communicated to the control devices 220 for implementation via the edge network devices 210. In some embodiments, the network management device 290 may provide a GUI dashboard with a visual and/or textual description of one or more properties of the internal network domain 205, such as a number and/or status and/or health of edge network devices 210, a number and/or status of control devices 220, a number of and/or last time of reboot, transport health (such as loss, latency, and/or jitter), a number of sites that are operating or not operating, application consumption of network resources, application routing, and/or others.”).
Thus, based upon the teachings of ARANHA it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, by adopting a feature wherein the policy is based at least in part on an entity input indicating the attribute for the entity associated with the edge device, as similarly seen in ARANHA to thus arrive at claim 6, in order to provide a benefit of an interface that allows a network administrator to implement/enable network policies.
In regards to claim 12, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the system of claim 7, wherein the policy is based at least in part on an entity input indicating the attribute for the entity associated with the edge device. Despite these differences similar features have been seen in other prior art involving software defined wide area networks (SD-WAN).
ARANHA (“US 20180302320 A1”) for example teaches a feature where with respect to a SD-WAN, a policy is based at least in part on an entity input indicating an attribute associated with an edge device (“[0037] As another example, with IP forwarding, the edge network devices 110 may include one or more policies to route packets via a particular type of communication link in an IP network. For example, such a policy may take into account factors such as packet size, services specified by a header, characteristics of potential links to other routers in the network, and/or others. Using such factors, the edge network devices 110 may forward packets based on a selected algorithm, such as a shortest path. …[0049] In some embodiments, the system 200 may include a network management device 290 that may communicate with the control devices 220 over a management network 232. The network management device 290 may provide management and control of one or more devices associated with the internal network domain 205, including the edge network devices 210, the control devices 220, and/or others. For example, the network management device 290 may provide a graphical user interface (GUI) that provides a network administrator with access to control or observe operation of the internal network domain 205. In some embodiments, the network administrator may input policies via the network management device 290 that may be communicated to the control devices 220 for implementation via the edge network devices 210. In some embodiments, the network management device 290 may provide a GUI dashboard with a visual and/or textual description of one or more properties of the internal network domain 205, such as a number and/or status and/or health of edge network devices 210, a number and/or status of control devices 220, a number of and/or last time of reboot, transport health (such as loss, latency, and/or jitter), a number of sites that are operating or not operating, application consumption of network resources, application routing, and/or others.”).
Thus, based upon the teachings of ARANHA it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, by adopting a feature wherein the policy is based at least in part on an entity input indicating the attribute for the entity associated with the edge device, as similarly seen in ARANHA to thus arrive at claim 12, in order to provide a benefit of an interface that allows a network administrator to implement/enable network policies.
In regards to claim 18, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the one or more non-transitory computer-readable media of claim 13, the operations further comprising:
receiving, from the entity associated with the edge device, entity input indicating the attribute for the entity associated with the edge device; and
determining, based at least in part on the attributes associated with portions of the underlay paths and the entity input, the policy indicating one or more portions of the underlay paths that are associated with the attribute for the entity associated with the edge device.
However, ZAD TOOTAGHAJ (US 20210392070 A1) does at least teach with respect to claim 13, determining, based at least in part on the attributes associated with portions of the underlay paths and the entity(ZAD TOOTAGHAJ teaches determining based in part on attributes, congestion of an underlay path, associated with portions of the underlay paths and the entity, the network administrator, the policy, a policy such as maintaining QoS requirement at a minimum cost, that indicates that segments of the underlay paths are to be avoided or included in underlay paths associated with the SDN enabled device/WAN infrastructure device, wherein: in response to the attribute indicating that the segments are to be avoided, identifying the first underlay path (i.e. underlay route 112, underlay route 116) for sending data on behalf of the network administrator associated with the, SDN enabled device/SD-WAN infrastructure device, such that the segments of the underlay paths (i.e. segments of underlay route 106), that are associated with the congested underlay path are avoided, or in response to the attribute indicating that the segments (i.e. segments of underlay route 106, in a case where there is a high correlation between SD-WAN links 108 and 114) are to be included, identifying the first underlay path (i.e. underlay route 106) for sending data on behalf of the network administrator associated with the SD-Enabled/ SD-WAN Infrastructure Device such that the segments of the underlay paths that are associated with the attributed are included (i.e. , and routing data on behalf of the network administrator through the first underlay path), and routing data (i.e. flows) on behalf of the network administrator through the first underlay path “[0031] As an example operation of the network probe, the network orchestrator requests network probes be sent for SD-WAN link 108. SDN enabled device 105a, as the originating infrastructure device of SD-WAN link 108, generates a number of network probes (the number may be configured by the network orchestrator) with transmission timestamps, and forwards them along underlay route 106…[0032]…The network orchestrator may analyze data across pairs of SD-WAN links for correlation…Correlation between pairs of SD-WAN links may indicate direct or indirect shared congested underlay links. For example, if network change 110a is congestion across the link between device 103 and device 105c, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link), but delay times for network probes assigned to SD-WAN link 114 may not increase (because associated underlay route 112 does not pass through the congested link). This will result in a reduced correlation between SD-WAN link 108 and SD-WAN link 114. However, if network change 110b is congestion across the link between device 105a and device 103, delay times for network probes assigned to SD-WAN link 108 may increase (because associated underlay route 106 passes through the congested link) and delay times for network probes assigned to SD-WAN link 114 may increase (because associated underlay route 112 also passes through the congested link). This will result in an increased correlation between SD-WAN links 108 and 114…. [0033] Correlation information can be used to make routing decisions. For example, if network change 110a is causing packets of flow routed across SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a low correlation between SD-WAN links 108 and 114, that network change 110a can be bypassed by moving flows routed across SD-WAN link 108 to instead use SD-WAN link 114 and SD-WAN link 118 to reach SDN enabled device 105c. As another example, if network change 110b is causing packets of flow routed through SD-WAN link 108 to violate quality of service (QoS) requirements, the network orchestrator may determine, due to a high correlation between SD-WAN links 108 and 114, that network change 110b cannot be bypassed by moving flow routed across SD-WAN link 108 to SD-WAN link 114, since underlay route 112 also uses the link affected by network change 110b. Flows routed across SD-WAN link 108 may be worse off being routed around underlay route 112 rather than staying with underlay route 106. In FIG. 1, as well as in the rest of this disclosure, SD-WAN links are shown as unidirectional data paths…[0053] In block 414, a total minimum cost routing solution is selected from the routing solutions determined in block 412. The selection of the total minimum cost routing solution is based on a total routing cost of each routing solution determined in block 412. In some examples, the total routing cost for each routing solution is calculated in block 414. Once the total minimum cost routing solution is selected, it may be implemented on the SD-WAN. In some examples, the network orchestrator issues updated flow rules to reconfigure the flows across SD-WAN links. [0054] FIG. 5 illustrates an example network orchestrator including instructions to reconfigure SD-WAN routes. Network orchestrator 500 includes processing circuitry 501 and memory 502. Memory 502 includes routing solutions 504, a total minimum cost routing solution 510, and instructions for determining routing solutions and the total minimum cost routing solution (not shown). Network orchestrator 500 may be a physical device, as illustrated in FIG. 5, or may be deployed as a cloud service, network service, virtualized device, or any other appropriate deployment method.”).
Furthermore, with regards to an edge device, KUMAR (US 11381474 B1) teaches a feature for SD-WAN where a device that performs monitoring comprises a SD-WAN edge device, the monitoring being regarded as analogous to the probing feature of ZAD TOOTAGHAJ (See KUMAR [Col. 8, Line 59 – Col 9, Line 25].”).
Thus, based upon the teachings of KUMAR (US 11381474 B1) it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN device of ZAD TOOTAGHAJ, to comprise an edge device, as similarly seen in the SD-WAN feature of KUMAR, in order to provide arrive at the one or more non-transitory computer-readable media of claim 13, the operations further comprising: determining, based at least in part on the attributes associated with portions of the underlay paths and the entity, the policy indicating one or more portions of the underlay paths that are associated with the attribute for the entity associated with the edge device, in order to provide a reliable means to implement the desired monitoring/probing functionality taught by ZAD TOOTAGHAJ.
The combination of ZAD TOOTAGHAJ in view of KUMAR differs from claim 18, in that the combined teachings are silent on receiving, from the entity associated with the edge device, entity input indicating the attribute for the entity associated with the edge device, and determining, based at least in part on the attributes associated with portions of the underlay paths and the entity input, the policy indicating one or more portions of the underlay paths that are associated with the attribute for the entity associated with the edge device, as arranged with the remaining elements of claim 18. Despite these differences similar features have been seen in other prior art involving Software-Defined Wide Area Networks.
ARANHA (“US 20180302320 A1”) for example teaches a feature where with respect to a SD-WAN, a policy is based at least in part on an entity input indicating an attribute associated with an edge device (“[0037] As another example, with IP forwarding, the edge network devices 110 may include one or more policies to route packets via a particular type of communication link in an IP network. For example, such a policy may take into account factors such as packet size, services specified by a header, characteristics of potential links to other routers in the network, and/or others. Using such factors, the edge network devices 110 may forward packets based on a selected algorithm, such as a shortest path. …[0049] In some embodiments, the system 200 may include a network management device 290 that may communicate with the control devices 220 over a management network 232. The network management device 290 may provide management and control of one or more devices associated with the internal network domain 205, including the edge network devices 210, the control devices 220, and/or others. For example, the network management device 290 may provide a graphical user interface (GUI) that provides a network administrator with access to control or observe operation of the internal network domain 205. In some embodiments, the network administrator may input policies via the network management device 290 that may be communicated to the control devices 220 for implementation via the edge network devices 210. In some embodiments, the network management device 290 may provide a GUI dashboard with a visual and/or textual description of one or more properties of the internal network domain 205, such as a number and/or status and/or health of edge network devices 210, a number and/or status of control devices 220, a number of and/or last time of reboot, transport health (such as loss, latency, and/or jitter), a number of sites that are operating or not operating, application consumption of network resources, application routing, and/or others.”).
Thus, based upon the teachings of ARANHA it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the SD-WAN feature suggested by the combined teachings of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, by adopting a feature wherein the policy is based at least in part on an entity input indicating the attribute for the entity associated with the edge device, as similarly seen in ARANHA to thus arrive at claim 18, in order to provide a benefit of an interface that allows a network administrator to implement/enable network policies.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR (US 11381474 B1) in view of CALCEV (US 20050094620 A1)
In regards to claim 15, the combination of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR is silent on the one or more non-transitory computer-readable media of claim 13, wherein the attributes associated with portions of the underlay paths include at least one of: a geographic location; or a particular network service provider. Despite these differences similar features have been seen in other prior art involving making routing decisions using attributes of underlay paths. CALCEV (US 20050094620 A1) teaches where one attribute of an underlay path used to make a routing decision includes a geographic location (“[0026] The above-described procedures are illustrated in FIG. 6 through FIG. 8. With reference to FIG. 6, node 601 wishes to discover a route to node 603. By informing overlay transceiver 104 of this fact, transceiver 104 determines geographic locations for all nodes within the underlay communication system and determines which nodes are to become seed nodes. In determining which nodes are to become seed nodes, transceiver 104 may use such criteria as node density, node's distance from the straight line that connects source and target, propagation data, node's activity, traffic patterns, node's battery level, node's mobility (for instance fixed relays could be preferred to the mobile nodes), etc. The proper selection of the seeds, based on their mobility, battery level, or traffic loads improves the overall throughput in the system as well as the route reliability and availability. In the preferred embodiment of the present invention seeds are chosen to be those units nearest a straight line connecting the source (node 601) and the destination nodes (node 603). More particularly, The seed selection is made so that the seeds are close to the straight line between source and target, if there are no additional information about the propagation conditions between source and target. The number of seeds is proportional to the distance between source and the target.”).
Thus based upon the teachings of CALVEL it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the routing feature for the SD-WAN suggested by the combined teachings of ZAD TOOTAGHAJ (US 20210392070 A1) in view of KUMAR, by adopting use of underlay attributes such as a geographic location as similarly seen in the routing feature of CALCEV (US 20050094620 A1), in order to take advantage of the known benefits provided by using geographic location of underlay paths to make routing decisions.
Allowable Subject Matter
Claim(s) 8, 19-20 are 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TARELL A HAMPTON whose telephone number is (571)270-7162. The examiner can normally be reached 9:00 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ayaz Sheikh can be reached at 5712723795. 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.
/TARELL A HAMPTON/Examiner, Art Unit 2476 /AYAZ R SHEIKH/Supervisory Patent Examiner, Art Unit 2476
Prosecution Insights