CTFR 18/049,159 CTFR 70717 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Amendment Claims 29 and 30 were canceled. New claims 31 and 32 were added. Applicant’s statement regarding adequate written support under 35 U.S.C 112f is acknowledged. Applicant’s response to the 35 U.S.C 101 rejection is persuasive. The 35 U.S.C 101 rejection therefore is withdrawn. Applicant’s response regarding the 35 U.S.C 103 rejections is not persuasive. Applicant argued that the applied references do not disclose nor suggest the amended limitation: “wherein selectively update the data flow model is based on at least in part on one or more data flows or paths within the domain having a bottleneck link outside of the domain.” The argument is not persuasive because the amended limitation merely recites a traffic condition. The bottleneck/congestion is an occurrence not under control of the invention. LIRON, YADAV, and GANESH suggest collecting network traffics and to update the network model. Hence, any bottleneck or other traffic conditions would be applied to the network model. SEID was added (for pre-amended claim 6) to show inter-domain path. Hence, the applied references combined would suggest collecting traffic on all paths including traffic on a path connecting to another domain; thereby, would have captured traffic information (including bottleneck condition) on that path. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-20-02-aia AIA 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. 07-21-aia AIA Claim s 1, 2, 3, 4, 7, 8, 10, 11, 12, 13, 16, 17, 19, 20, 23, 25, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Liron et al (US 5598532 A) hereinafter “Liron”, in view of Yadav et al. (US 20180359172 A1) hereinafter “Yadav”, in view of Ganesh et al. (US 20170288991 A1) hereinafter “Ganesh”, in view of Seid et al. (US 5768271 A), hereinafter “Seid” . Regarding claim 1, Liron teaches a method performed by a network entity, comprising: generating a data flow model for a domain associated with the network entity ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." FIG. 2 step 103 states a network model is made according to collected network data, that includes traffic flows.), obtaining a set of measured flow rates and a set of expected flow rates that are calculated based at least in part on the data flow model ([Column 4, Lines 36-46] " Referring to FIG. 2, optimization method 100 collects 101 data describing network 11, including its topology and traffic flow patterns. Data collection is accomplished in the preferred embodiment using segment collectors 17 on the LAN segments 13 of interest; information about other LAN segments 13 can be ignored if desired. These segment collectors 17 collect data local to their attached LAN segment 13. Some conventional networks 11 use segment collectors 17 (e.g. SNMP, RMON, network analyzers, etc.) which may relay the collected information to a network management console 23." The collection of data describing a network includes collecting traffic flow patterns. [Column 6, Lines 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client.sub.-- r] for the unidirectional traffic flow (for example in bytes) from CLIENT[j] to R, and TRAFFIC[j, r.sub.-- client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 .” Known flow is interpreted by the examiner as expected flow. [Column 11, Lines 11-24] " which assigns a score dependent on the values of the traffic variables A, B, C. For example, Eq. (9) can define a function for scoring hub(p) based on the delays incurred when going through a switching element 19 between the partitions on LAN segment 13 at hub(p). The delays in and between partitions PA(p) and PB(p) are themselves functions of the traffic values A, B, and C. The scoring function can assign a score which is equal to the average byte delay depending on which of PA(p), PB(p) or the switching element 19 participate in transmitting the byte from its source node 16 to the destination node 16. The functions can be based on either actual network traffic and delay data acquired by segment collectors 17, or thorough simulation by simulator 39." Actual network data is interpreted by the examiner as the measured flow rates.) . However, Liron does not teach selectively updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates, nor that the domain in which the model is representing is part of a multi-domain network. Yadav, in the same field of endeavor, teaches updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates ([0004] " A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by one or more processors of a network administration device, cause the one or more processors to receive first operational information regarding a first set of network devices; receive first flow information relating to a first set of traffic flows associated with the first set of network devices; generate a model, based on a machine learning technique, to identify predicted performance of the first set of network devices with regard to the first set of traffic flows; receive or obtain second operational information and/or second flow information regarding the first set of network devices or a second set of network devices; determine path information for the first set of traffic flows or a second set of traffic flows using the model and based on the second operational information and/or the second flow information; configure the first set of network devices or the second set of network devices to implement the path information; and/or update the model based on a machine learning technique and based on observations after the path information is implemented ." Yadav teaches a method and device that receives information relating to the traffic flow between devices, and then generates a model using a machine learning technique. The examiner interprets this model based on traffic flow to be a network data flow model. [0018] " FIGS. 1A-1D are diagrams of an overview of example implementations 100 described herein. As shown in FIG. 1A, and by reference number 102, a network administration device (shown as NAD) may receive a training set of flow information, network topology information, and operational information regarding a plurality of network devices of a network. The network administration device may receive the flow information, the network topology information, and the operational information to generate a model for determining traffic flow paths in the network or another network ." Paragraph 0018 further solidifies the examiner’s interpretation that the model is one representative of a network topology and the data flows within, i.e. a network data flow model. [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results. " [0035] " In this way, the network administration device generates a predictive model using machine learning to determine updated path information for a network of network devices, which permits dynamic improvement and updating of the predictive model, and which may be simpler to implement than a complicated and/or static routing protocol. Furthermore, using a machine learning technique may generate a more efficient routing protocol than using a human-based technique. Further, the network administration device may avoid or limit traffic drops due to black-holing of traffic by misconfigured or malfunctioning network devices. This may be particularly advantageous for failure modes that are not detected by traditional routing protocols, such as network device degradation, black-holing, and/or the like. Also, the network administration device may continuously gather useful telemetry and/or performance information over time, which may permit analysis of network information over time " Yadav teaches that it can then update the generated model based on dynamically changing traffic information. The machine learning technique can iteratively update the model to improve the accuracy of the model and the data it represents.) However, Yadav does not teach that the domain in which the model is representing is part of a multi-domain network. Ganesh, in the same field of endeavor, teaches the domain being part of a multi-domain network ([0019] " It is another object of the present invention to provide system and method for monitoring multi-domain network, which generates visualization of different domains in a telecommunication network across layers and identifies the exact root cause of network element using the layered approach based on configuration, performance and alarm data collected across multiple domains.") . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron, with a method to generate a data flow model of a network/domain, and obtain the measured flow rates and expected flow rates pertaining to the connections of said generated model, with the teaching of Yadav to further update the model according to the rates obtained to be sure the model is accurate, and further with the teachings of Ganesh wherein the method is applied to a domain being part of a multi-domain network. One of ordinary skill in the art need only apply the model generation method taught by Liron, with the updating of a traffic model from Yadav, and further to apply it to a multidomain environment as taught by Ganesh to further increase the accuracy of the generated data flow model, even if given domain does not have an oracle view of other neighboring domains. All so one can generate an accurate representation of a network data flow model that may more efficiently show where bottlenecks occur. Liron, Yadav, and Ganesh do not teach wherein updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain. Seid, in the same field of endeavor, teaches updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain ([Column 3, Lines 3-14] " Each VP is allocated a positive guaranteed bandwidth (VP-CIR), and each VC on a VP is also allocated a bandwidth (VC-CIR) greater than or equal to zero. Packets of information to be transmitted over a VC are provided with an address field having local significance for identifying the respective VCs and VPs used by the VPN to which the packets of information are associated. Congestion control of the network is provided such that congestion control and management are carried out on a per VPN basis, and congestion outside of a VPN's logical domain does not affect the performance of the VPN ." Seid discloses a method of packet switching within a network. It recognizes congestion located outside of a VPN's logical domain. Seid further teaches wherein when congestion occurs on a physical path, only a virtual path using bandwidth greater than the respective positive guaranteed bandwidth is required to reduce submission rate of packets onto the network, thereby providing some basic required level of QOS. The examiner interprets the above as an acknowledgment that a bottleneck may occur outside a given domain.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh wherein their update of the data flow model may be based or influenced by a bottleneck existing outside of the immediate domain as taught by Seid. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Seid to more accurately create a data flow model to represent the correct locations of bottleneck/congested links. Proper and accurate mapping is required to better plan flow distribution to take care of areas where bottlenecks may be an issue, even if said bottleneck is outside of the immediate domain. Regarding claim 2, Liron, Yadav, Ganesh, and Seid teach the method of claim 1 (discussed above). Liron further teaches performing data flow management based at least in part on the data flow model ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." The data collected for the optimization of the model includes traffic flows, and is therefore interpreted by the examiner as a form of data flow management based on the generated model taught by Liron and showcased in FIG. 2.) . Regarding claim 3 , Liron, Yadav, Ganesh, and Seid teach the method of claim 2 (discussed above). Liron further teaches wherein performing data flow management comprises performing network modeling ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory." The optimization and adjustments made to the network model based on those optimizations are interpreted by the examiner as a form of network modeling.) . Regarding claim 4 , Liron, Yadav, Ganesh, and Seid teach the method of claim 1 (discussed above). However, Liron does not explicitly teach generating an updated data flow model based at least in part on iteratively updating the data flow model. Yadav, in the same field of endeavor, teaches generating an updated data flow model based at least in part on iteratively updating the data flow model ( [0015] " Furthermore, some implementations described herein may update the model using the machine learning technique and based on observations regarding efficacy of the configuration of the path information. In this way, the model may adapt to changing network conditions and topology (e.g., in real time as the network conditions and/or the topology change), which may require human intervention for a predefined routing policy. Thus, network throughput, reliability, and conformance with SLAs is improved. Further, some implementations described herein may use a rigorous, well-defined approach to path selection, which may reduce uncertainty, subjectivity, and inefficiency that may be introduced by a human actor attempting to define a routing policy based on observations regarding network performance." [0016] " Also, some implementations described herein may identify the best paths for traffic associated with different SLAs. Since these best paths may iteratively change based on traffic load and node behavior/faults, the machine learning component of implementations described herein may regularly reprogram the paths for particular traffic flows across the network domain. This reprogramming may be based on dynamic prediction of the traffic flows, traffic drops and delays. Thus, implementations described herein may improve adaptability and versatility of path computation for the network domain in comparison to a rigidly defined routing protocol." [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results" Based on the above, Yadav teaches that flow information changes, and is therefore dynamic. The best paths in the model may “iteratively change” and the machine learning component can update the model based on this “updated flow information”. In order to keep the current model accurate, Yadav may then “ dynamically or iteratively improving the path selection model in view of results of using the path selection model”. The examiner interprets this as generating an updated flow model based on iteratively updating the flow model.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the combination teachings of Liron, Yadav, and Ganesh, with the further teaching of Yadav wherein the model is iteratively updated. The motivation to do so would be to ensure an accurate data flow model is available. Data flows can be dynamic in which bottlenecks may occur slowing the flow. Having an updated model that reflects these changes would allow one to better allocate flow within a network/domain. Regarding claim 7, Liron, Yadav, Ganesh, and Seid teach the method of claim 1 (discussed above). Liron further teaches wherein the data flow model indicates one or more of bottleneck links or non-bottleneck links of one or more data flows or paths within the domain ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." The generated network model taught in Liron includes topology, traffic flows, links, etc. The examiner interprets these links to include "non-bottleneck links".). Regarding claim 8, Liron, Yadav, Ganesh, and Seid teach the method of claim 1 (discussed above). Liron further teaches wherein the set of expected flow rates is based at least in part on calculated capacities of links traversed by data flows or paths within the domain ([Column 13, Lines 27-43] " Tables 1 and 2 below illustrate the results of a hub tree optimization process 500 applied to an actual LAN segment 13 called "<134.177.120.9>" whose traffic flow is shown in FIG. 6. The optimization goal 31 was set to "minimize the maximum load". The LAN segment 13 started off with a load of 61 %. Optimization process 500 resulted in two segments partitioned at a hub 402 called "<134.177.120.9_hub9>." The resulting partitions now operate at 21 % and 42% of maximum segment capacity. That the sum of the two loads is above the original LAN segment load of 61 % indicates that some (very little) traffic is crossing between the two new segments. Decreasing a segment load from 61 % to 42% typically reduces the delay by a factor of about 10 because at a load of 61 % the segment operates much above the "knee" of the non-linear delay vs. load curve." Liron’s FIG. 6 showcases the bidirectional traffic flow from node to node in a network. Liron teaches that there is an expected flowrate between these nodes, further represented in node tables 1 and 2 that collects the flow information, and organizes the nodes by an expected capacity (Table 1 with an expected load of 21%, and table 2 with nodes that have an expected load of 42%).) , and wherein the set of measured flow rates is based at least in part on an observed transmission rate of data flow through the links ([Column 6, Line 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client_r] for the unidirectional traffic flow (for example in bytes) from CLIENTU] to R, and TRAFFIC[j, r_client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 ." The "actual measurements" as taught by Liron is interpreted by the examiner as a measured flow rate of the observed traffic/transmission rates between nodes in the generated network model. This information is then stored in a list labeled as TRAFFIC and used to generate the network model.) . Regarding claim 10, Liron teaches a network entity for wireless communication, comprising: a memory (FIG. 1 label #43) ; and one or more processors, coupled to the memory ([Column 4, Lines 60-62] “ In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory.”) , configured to: generate a data flow model for a domain associated with the network entity, ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." FIG. 2 step 103 states a network model is made according to collected network data, that includes traffic flows.), obtaining a set of measured flow rates and a set of expected flow rates that are calculated based at least in part on the data flow model ([Column 4, Line 36] " Referring to FIG. 2, optimization method 100 collects 101 data describing network 11, including its topology and traffic flow patterns. Data collection is accomplished in the preferred embodiment using segment collectors 17 on the LAN segments 13 of interest; information about other LAN segments 13 can be ignored if desired. These segment collectors 17 collect data local to their attached LAN segment 13. Some conventional networks 11 use segment collectors 17 (e.g. SNMP, RMON, network analyzers, etc.) which may relay the collected information to a network management console 23." The collection of data describing a network includes collecting traffic flow patterns. [Column 6, Lines 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client.sub.-- r] for the unidirectional traffic flow (for example in bytes) from CLIENT[j] to R, and TRAFFIC[j, r.sub.-- client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 .” Known flow is interpreted by the examiner as expected flow. [Column 11, Lines 11-24] " which assigns a score dependent on the values of the traffic variables A, B, C. For example, Eq. (9) can define a function for scoring hub(p) based on the delays incurred when going through a switching element 19 between the partitions on LAN segment 13 at hub(p). The delays in and between partitions PA(p) and PB(p) are themselves functions of the traffic values A, B, and C. The scoring function can assign a score which is equal to the average byte delay depending on which of PA(p), PB(p) or the switching element 19 participate in transmitting the byte from its source node 16 to the destination node 16. The functions can be based on either actual network traffic and delay data acquired by segment collectors 17, or thorough simulation by simulator 39." Actual network data is interpreted by the examiner as the measured flow rates.) ; and However, Liron does not teach selectively updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates, nor that the domain in which the model is representing is part of a multi-domain network. Yadav, in the same field of endeavor, teaches updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates ([0004] " A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by one or more processors of a network administration device, cause the one or more processors to receive first operational information regarding a first set of network devices; receive first flow information relating to a first set of traffic flows associated with the first set of network devices; generate a model, based on a machine learning technique, to identify predicted performance of the first set of network devices with regard to the first set of traffic flows; receive or obtain second operational information and/or second flow information regarding the first set of network devices or a second set of network devices; determine path information for the first set of traffic flows or a second set of traffic flows using the model and based on the second operational information and/or the second flow information; configure the first set of network devices or the second set of network devices to implement the path information; and/or update the model based on a machine learning technique and based on observations after the path information is implemented ." Yadav teaches a method and device that receives information relating to the traffic flow between devices, and then generates a model using a machine learning technique. The examiner interprets this model based on traffic flow to be a network data flow model. [0018] " FIGS. 1A-1D are diagrams of an overview of example implementations 100 described herein. As shown in FIG. 1A, and by reference number 102, a network administration device (shown as NAD) may receive a training set of flow information, network topology information, and operational information regarding a plurality of network devices of a network. The network administration device may receive the flow information, the network topology information, and the operational information to generate a model for determining traffic flow paths in the network or another network ." Paragraph 0018 further solidifies the examiner’s interpretation that the model is one representative of a network topology and the data flows within, i.e. a network data flow model. [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results. " [0035] " In this way, the network administration device generates a predictive model using machine learning to determine updated path information for a network of network devices, which permits dynamic improvement and updating of the predictive model, and which may be simpler to implement than a complicated and/or static routing protocol. Furthermore, using a machine learning technique may generate a more efficient routing protocol than using a human-based technique. Further, the network administration device may avoid or limit traffic drops due to black-holing of traffic by misconfigured or malfunctioning network devices. This may be particularly advantageous for failure modes that are not detected by traditional routing protocols, such as network device degradation, black-holing, and/or the like. Also, the network administration device may continuously gather useful telemetry and/or performance information over time, which may permit analysis of network information over time " Yadav teaches that it can then update the generated model based on dynamically changing traffic information. The machine learning technique can iteratively update the model to improve the accuracy of the model and the data it represents.) However, Yadav does not teach that the domain in which the model is representing is part of a multi-domain network. Ganesh, in the same field of endeavor, teaches the domain being part of a multi-domain network ([0019] " It is another object of the present invention to provide system and method for monitoring multi-domain network, which generates visualization of different domains in a telecommunication network across layers and identifies the exact root cause of network element using the layered approach based on configuration, performance and alarm data collected across multiple domains.") . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron, with a method to generate a data flow model of a network/domain, and obtain the measured flow rates and expected flow rates pertaining to the connections of said generated model, with the teaching of Yadav to further update the model according to the rates obtained to be sure the model is accurate, and further with the teachings of Ganesh wherein the method is applied to a domain being part of a multi-domain network. One of ordinary skill in the art need only apply the model generation method taught by Liron, with the updating of a traffic model from Yadav, and further to apply it to a multidomain environment as taught by Ganesh to further increase the accuracy of the generated data flow model, even if given domain does not have an oracle view of other neighboring domains. All so one can generate an accurate representation of a network data flow model that may more efficiently show where bottlenecks occur. Liron, Yadav, and Ganesh do not teach wherein updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain. Seid, in the same field of endeavor, teaches updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain ([Column 3, Lines 3-14] " Each VP is allocated a positive guaranteed bandwidth (VP-CIR), and each VC on a VP is also allocated a bandwidth (VC-CIR) greater than or equal to zero. Packets of information to be transmitted over a VC are provided with an address field having local significance for identifying the respective VCs and VPs used by the VPN to which the packets of information are associated. Congestion control of the network is provided such that congestion control and management are carried out on a per VPN basis, and congestion outside of a VPN's logical domain does not affect the performance of the VPN ." Seid discloses a method of packet switching within a network. It recognizes congestion located outside of a VPN's logical domain. Seid further teaches wherein when congestion occurs on a physical path, only a virtual path using bandwidth greater than the respective positive guaranteed bandwidth is required to reduce submission rate of packets onto the network, thereby providing some basic required level of QOS. The examiner interprets the above as an acknowledgment that a bottleneck may occur outside a given domain.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh wherein their update of the data flow model may be based or influenced by a bottleneck existing outside of the immediate domain as taught by Seid. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Seid to more accurately create a data flow model to represent the correct locations of bottleneck/congested links. Proper and accurate mapping is required to better plan flow distribution to take care of areas where bottlenecks may be an issue, even if said bottleneck is outside of the immediate domain. Regarding claim 11, Liron, Yadav, Ganesh, and Seid teach the entity of claim 10 (discussed above). Liron further teaches wherein the one or more processors are further configured to: perform data flow management based at least in part on the data flow model ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." The data collected for the optimization of the model includes traffic flows, and is therefore interpreted by the examiner as a form of data flow management based on the generated model taught by Liron and showcased in FIG. 2.) . Regarding claim 12, Liron, Yadav, Ganesh, and Seid teach the entity of claim 11 (discussed above). Liron further teaches wherein the one or more processors, to perform data flow management, are configured to perform network modeling ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory." The optimization and adjustments made to the network model based on those optimizations are interpreted by the examiner as a form of network modeling.) . Regarding claim 13, Liron, Yadav, Ganesh, and Seid teach the entity of claim 10 (discussed above). However, Liron does not explicitly teach wherein the one or more processors are further configured to: generating an updated data flow model based at least in part on iteratively updating the data flow model. Yadav, in the same field of endeavor, teaches generating an updated data flow model based at least in part on iteratively updating the data flow model ( [0015] " Furthermore, some implementations described herein may update the model using the machine learning technique and based on observations regarding efficacy of the configuration of the path information. In this way, the model may adapt to changing network conditions and topology (e.g., in real time as the network conditions and/or the topology change), which may require human intervention for a predefined routing policy. Thus, network throughput, reliability, and conformance with SLAs is improved. Further, some implementations described herein may use a rigorous, well-defined approach to path selection, which may reduce uncertainty, subjectivity, and inefficiency that may be introduced by a human actor attempting to define a routing policy based on observations regarding network performance." [0016] " Also, some implementations described herein may identify the best paths for traffic associated with different SLAs. Since these best paths may iteratively change based on traffic load and node behavior/faults, the machine learning component of implementations described herein may regularly reprogram the paths for particular traffic flows across the network domain. This reprogramming may be based on dynamic prediction of the traffic flows, traffic drops and delays. Thus, implementations described herein may improve adaptability and versatility of path computation for the network domain in comparison to a rigidly defined routing protocol." [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results" Based on the above, Yadav teaches that flow information changes, and is therefore dynamic. The best paths in the model may “iteratively change” and the machine learning component can update the model based on this “updated flow information”. In order to keep the current model accurate, Yadav may then “ dynamically or iteratively improving the path selection model in view of results of using the path selection model”. The examiner interprets this as generating an updated flow model based on iteratively updating the flow model. ) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the combination teachings of Liron, Yadav, and Ganesh, with the further teaching of Yadav wherein the model is iteratively updated. The motivation to do so would be to ensure an accurate data flow model is available. Data flows can be dynamic in which bottlenecks may occur slowing the flow. Having an updated model that reflects these changes would allow one to better allocate flow within a network/domain. Regarding claim 16, Liron, Yadav, Ganesh, and Seid teach the entity of claim 10 (discussed above). Liron further teaches wherein the data flow model indicates one or more of bottleneck links or non-bottleneck links of one or more data flows or paths within the domain ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." The generated network model taught in Liron includes topology, traffic flows, links, etc. The examiner interprets these links to include "non-bottleneck links".). Regarding claim 17, Liron, Yadav, Ganesh, and Seid teach the entity of claim 10 (discussed above). Liron further teaches wherein the set of expected flow rates is based at least in part on calculated capacities of links traversed by data flows or paths within the domain, ([Column 13, line 27-43] " Tables 1 and 2 below illustrate the results of a hub tree optimization process 500 applied to an actual LAN segment 13 called "<134.177.120.9>" whose traffic flow is shown in FIG. 6. The optimization goal 31 was set to "minimize the maximum load". The LAN segment 13 started off with a load of 61 %. Optimization process 500 resulted in two segments partitioned at a hub 402 called "<134.177.120.9_hub9>." The resulting partitions now operate at 21 % and 42% of maximum segment capacity. That the sum of the two loads is above the original LAN segment load of 61 % indicates that some (very little) traffic is crossing between the two new segments. Decreasing a segment load from 61 % to 42% typically reduces the delay by a factor of about 10 because at a load of 61 % the segment operates much above the "knee" of the non-linear delay vs. load curve." Laron’s FIG. 6 showcases the bidirectional traffic flow from node to node in a network. Liron teaches that there is an expected flowrate between these nodes, further represented in node tables 1 and 2 that collects the flow information, and organizes the nodes by an expected capacity (Table 1 with an expected load of 21%, and table 2 with nodes that have an expected load of 42%).) , and wherein the set of measured flow rates is based at least in part on an observed transmission rate of data flow through the links ([Column 6, Lines 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client_r] for the unidirectional traffic flow (for example in bytes) from CLIENTU] to R, and TRAFFIC[j, r_client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 ." The "actual measurements" as taught by Liron is interpreted by the examiner as a measured flow rate of the observed traffic/transmission rates between nodes in the generated network model. This information is then stored in a list labeled as TRAFFIC and used to generate the network model.) . Regarding claim 19, Liron teaches a non-transitory computer-readable medium storing a set of instructions for wireless communication, the set of instructions comprising: one or more instructions that, when executed by one or more processors ([Column 4, Lines 60-62] “ In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory.”) of a network entity, cause the network entity to: generate a data flow model for a domain associated with the network entity, ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." FIG. 2 step 103 states a network model is made according to collected network data, that includes traffic flows.), obtain a set of measured flow rates and a set of expected flow rates that are calculated based at least in part on the data flow model ([Column 4, Line 36] " Referring to FIG. 2, optimization method 100 collects 101 data describing network 11, including its topology and traffic flow patterns. Data collection is accomplished in the preferred embodiment using segment collectors 17 on the LAN segments 13 of interest; information about other LAN segments 13 can be ignored if desired. These segment collectors 17 collect data local to their attached LAN segment 13. Some conventional networks 11 use segment collectors 17 (e.g. SNMP, RMON, network analyzers, etc.) which may relay the collected information to a network management console 23." The collection of data describing a network includes collecting traffic flow patterns. [Column 6, Line 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client.sub.-- r] for the unidirectional traffic flow (for example in bytes) from CLIENT[j] to R, and TRAFFIC[j, r.sub.-- client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 .” Known flow is interpreted by the examiner as expected flow. [Column 11, Lines 11-24] " which assigns a score dependent on the values of the traffic variables A, B, C. For example, Eq. (9) can define a function for scoring hub(p) based on the delays incurred when going through a switching element 19 between the partitions on LAN segment 13 at hub(p). The delays in and between partitions PA(p) and PB(p) are themselves functions of the traffic values A, B, and C. The scoring function can assign a score which is equal to the average byte delay depending on which of PA(p), PB(p) or the switching element 19 participate in transmitting the byte from its source node 16 to the destination node 16. The functions can be based on either actual network traffic and delay data acquired by segment collectors 17, or thorough simulation by simulator 39." Actual network data is interpreted by the examiner as the measured flow rates.) . However, Liron does not teach selectively updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates, nor that the domain in which the model is representing is part of a multi-domain network. Yadav, in the same field of endeavor, teaches updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates ([0004] " A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by one or more processors of a network administration device, cause the one or more processors to receive first operational information regarding a first set of network devices; receive first flow information relating to a first set of traffic flows associated with the first set of network devices; generate a model, based on a machine learning technique, to identify predicted performance of the first set of network devices with regard to the first set of traffic flows; receive or obtain second operational information and/or second flow information regarding the first set of network devices or a second set of network devices; determine path information for the first set of traffic flows or a second set of traffic flows using the model and based on the second operational information and/or the second flow information; configure the first set of network devices or the second set of network devices to implement the path information; and/or update the model based on a machine learning technique and based on observations after the path information is implemented ." Yadav teaches a method and device that receives information relating to the traffic flow between devices, and then generates a model using a machine learning technique. The examiner interprets this model based on traffic flow to be a network data flow model. [0018] " FIGS. 1A-1D are diagrams of an overview of example implementations 100 described herein. As shown in FIG. 1A, and by reference number 102, a network administration device (shown as NAD) may receive a training set of flow information, network topology information, and operational information regarding a plurality of network devices of a network. The network administration device may receive the flow information, the network topology information, and the operational information to generate a model for determining traffic flow paths in the network or another network ." Paragraph 0018 further solidifies the examiner’s interpretation that the model is one representative of a network topology and the data flows within, i.e. a network data flow model. [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results. " [0035] " In this way, the network administration device generates a predictive model using machine learning to determine updated path information for a network of network devices, which permits dynamic improvement and updating of the predictive model, and which may be simpler to implement than a complicated and/or static routing protocol. Furthermore, using a machine learning technique may generate a more efficient routing protocol than using a human-based technique. Further, the network administration device may avoid or limit traffic drops due to black-holing of traffic by misconfigured or malfunctioning network devices. This may be particularly advantageous for failure modes that are not detected by traditional routing protocols, such as network device degradation, black-holing, and/or the like. Also, the network administration device may continuously gather useful telemetry and/or performance information over time, which may permit analysis of network information over time " Yadav teaches that it can then update the generated model based on dynamically changing traffic information. The machine learning technique can iteratively update the model to improve the accuracy of the model and the data it represents.) However, Yadav does not teach that the domain in which the model is representing is part of a multi-domain network. Ganesh, in the same field of endeavor, teaches the domain being part of a multi-domain network ([0019] " It is another object of the present invention to provide system and method for monitoring multi-domain network, which generates visualization of different domains in a telecommunication network across layers and identifies the exact root cause of network element using the layered approach based on configuration, performance and alarm data collected across multiple domains.") . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron, with a method to generate a data flow model of a network/domain, and obtain the measured flow rates and expected flow rates pertaining to the connections of said generated model, with the teaching of Yadav to further update the model according to the rates obtained to be sure the model is accurate, and further with the teachings of Ganesh wherein the method is applied to a domain being part of a multi-domain network. One of ordinary skill in the art need only apply the model generation method taught by Liron, with the updating of a traffic model from Yadav, and further to apply it to a multidomain environment as taught by Ganesh to further increase the accuracy of the generated data flow model, even if given domain does not have an oracle view of other neighboring domains. All so one can generate an accurate representation of a network data flow model that may more efficiently show where bottlenecks occur. Liron, Yadav, and Ganesh do not teach wherein updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain. Seid, in the same field of endeavor, teaches updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain ([Column 3, Lines 3-14] " Each VP is allocated a positive guaranteed bandwidth (VP-CIR), and each VC on a VP is also allocated a bandwidth (VC-CIR) greater than or equal to zero. Packets of information to be transmitted over a VC are provided with an address field having local significance for identifying the respective VCs and VPs used by the VPN to which the packets of information are associated. Congestion control of the network is provided such that congestion control and management are carried out on a per VPN basis, and congestion outside of a VPN's logical domain does not affect the performance of the VPN ." Seid discloses a method of packet switching within a network. It recognizes congestion located outside of a VPN's logical domain. Seid further teaches wherein when congestion occurs on a physical path, only a virtual path using bandwidth greater than the respective positive guaranteed bandwidth is required to reduce submission rate of packets onto the network, thereby providing some basic required level of QOS. The examiner interprets the above as an acknowledgment that a bottleneck may occur outside a given domain.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh wherein their update of the data flow model may be based or influenced by a bottleneck existing outside of the immediate domain as taught by Seid. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Seid to more accurately create a data flow model to represent the correct locations of bottleneck/congested links. Proper and accurate mapping is required to better plan flow distribution to take care of areas where bottlenecks may be an issue, even if said bottleneck is outside of the immediate domain. Regarding claim 20, Liron, Yadav, Ganesh, and Seid teach the non-transitory computer-readable medium of claim 19 (discussed above). However, Liron does not explicitly teach wherein the one or more instructions further cause the network entity to: generate an updated data flow model based at least in part on iteratively updating the data flow model. Yadav, in the same field of endeavor, teaches generating an updated data flow model based at least in part on iteratively updating the data flow model ( [0015] " Furthermore, some implementations described herein may update the model using the machine learning technique and based on observations regarding efficacy of the configuration of the path information. In this way, the model may adapt to changing network conditions and topology (e.g., in real time as the network conditions and/or the topology change), which may require human intervention for a predefined routing policy. Thus, network throughput, reliability, and conformance with SLAs is improved. Further, some implementations described herein may use a rigorous, well-defined approach to path selection, which may reduce uncertainty, subjectivity, and inefficiency that may be introduced by a human actor attempting to define a routing policy based on observations regarding network performance." [0016] " Also, some implementations described herein may identify the best paths for traffic associated with different SLAs. Since these best paths may iteratively change based on traffic load and node behavior/faults, the machine learning component of implementations described herein may regularly reprogram the paths for particular traffic flows across the network domain. This reprogramming may be based on dynamic prediction of the traffic flows, traffic drops and delays. Thus, implementations described herein may improve adaptability and versatility of path computation for the network domain in comparison to a rigidly defined routing protocol." [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results" Based on the above, Yadav teaches that flow information changes, and is therefore dynamic. The best paths in the model may “iteratively change” and the machine learning component can update the model based on this “updated flow information”. In order to keep the current model accurate, Yadav may then “ dynamically or iteratively improving the path selection model in view of results of using the path selection model”. The examiner interprets this as generating an updated flow model based on iteratively updating the flow model. ) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the combination teachings of Liron, Yadav, and Ganesh, with the further teaching of Yadav wherein the model is iteratively updated. The motivation to do so would be to ensure an accurate data flow model is available. Data flows can be dynamic in which bottlenecks may occur slowing the flow. Having an updated model that reflects these changes would allow one to better allocate flow within a network/domain. Regarding claim 23, Liron, Yadav, Ganesh, and Seid teach the non-transitory computer-readable medium of claim 19 (discussed above). Liron further teaches wherein the set of expected flow rates is based at least in part on calculated capacities of links traversed by data flows or paths within the domain ([Column 13, Lines 27-43] " Tables 1 and 2 below illustrate the results of a hub tree optimization process 500 applied to an actual LAN segment 13 called "<134.177.120.9>" whose traffic flow is shown in FIG. 6. The optimization goal 31 was set to "minimize the maximum load". The LAN segment 13 started off with a load of 61 %. Optimization process 500 resulted in two segments partitioned at a hub 402 called "<134.177.120.9_hub9>." The resulting partitions now operate at 21 % and 42% of maximum segment capacity. That the sum of the two loads is above the original LAN segment load of 61 % indicates that some (very little) traffic is crossing between the two new segments. Decreasing a segment load from 61 % to 42% typically reduces the delay by a factor of about 10 because at a load of 61 % the segment operates much above the "knee" of the non-linear delay vs. load curve." Laron’s FIG. 6 showcases the bidirectional traffic flow from node to node in a network. Liron teaches that there is an expected flowrate between these nodes, further represented in node tables 1 and 2 that collects the flow information, and organizes the nodes by an expected capacity (Table 1 with an expected load of 21%, and table 2 with nodes that have an expected load of 42%).) , and wherein the set of measured flow rates is based at least in part on an observed transmission rate of data flow through the links ([Column 6, Line 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client_r] for the unidirectional traffic flow (for example in bytes) from CLIENTU] to R, and TRAFFIC[j, r_client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 ." The "actual measurements" as taught by Liron is interpreted by the examiner as a measured flow rate of the observed traffic/transmission rates between nodes in the generated network model. This information is then stored in a list labeled as TRAFFIC and used to generate the network model.) . Regarding claim 25, Liron teaches an apparatus for wireless communication, comprising: means for generating a data flow model for a domain associated with the apparatus, the domain being part of a multi-domain network ([Column 4, Lines 47-62] " Next, optimization method 100 builds 103 an overall network model 27 from local data collected by segment collectors 17, using consolidator 25. In the preferred embodiment, the input to consolidator 25 comes either directly from segment collectors 17 or indirectly from segment collectors 17 via network management console 23. In either case consolidator 25 produces a network model 27 of the portions of network 11 for which data was collected, including its network topology, the clients 15, switching devices 19, links 41, LAN segments 13, the network protocols employed, and the traffic flows. Alternatively, network model 27 can be based on data acquired from both segment collectors 27 and network management console 23. In the preferred embodiment, consolidator 25 is implemented as a processor executing software routines stored in memory ." FIG. 2 step 103 states a network model is made according to collected network data, that includes traffic flows.), means for obtaining a set of measured flow rates and a set of expected flow rates that are calculated based at least in part on the data flow model ([Column 4, Line 36] " Referring to FIG. 2, optimization method 100 collects 101 data describing network 11, including its topology and traffic flow patterns. Data collection is accomplished in the preferred embodiment using segment collectors 17 on the LAN segments 13 of interest; information about other LAN segments 13 can be ignored if desired. These segment collectors 17 collect data local to their attached LAN segment 13. Some conventional networks 11 use segment collectors 17 (e.g. SNMP, RMON, network analyzers, etc.) which may relay the collected information to a network management console 23." The collection of data describing a network includes collecting traffic flow patterns. [Column 6, Line 12-22] " Optimization process 200 determines 209 the amount of network traffic known to flow between the given clients 15 and R over a given time t. These traffic flow amounts are stored in TRAFFIC. TRAFFIC has C elements, C being the number of clients 15 in CLIENTS. The j-th entry in TRAFFIC comprises TRAFFIC[j, client.sub.-- r] for the unidirectional traffic flow (for example in bytes) from CLIENT[j] to R, and TRAFFIC[j, r.sub.-- client] for the traffic from R to CLIENT[j]. TRAFFIC is formed from network model 27 using actual measurements, or through estimation, for example, using simulation by simulator 37 .” Known flow is interpreted by the examiner as expected flow. [Column 11, Lines 11-24] " which assigns a score dependent on the values of the traffic variables A, B, C. For example, Eq. (9) can define a function for scoring hub(p) based on the delays incurred when going through a switching element 19 between the partitions on LAN segment 13 at hub(p). The delays in and between partitions PA(p) and PB(p) are themselves functions of the traffic values A, B, and C. The scoring function can assign a score which is equal to the average byte delay depending on which of PA(p), PB(p) or the switching element 19 participate in transmitting the byte from its source node 16 to the destination node 16. The functions can be based on either actual network traffic and delay data acquired by segment collectors 17, or thorough simulation by simulator 39." Actual network data is interpreted by the examiner as the measured flow rates.) ; and However, Liron does not teach means for selectively updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates, nor that the domain in which the model is representing is part of a multi-domain network. Yadav, in the same field of endeavor, teaches means for updating the data flow model based at least in part on an accuracy of the data flow model, with the accuracy determined based at least in part on the set of measured flow rates and the set of expected flow rates ([0004] " A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by one or more processors of a network administration device, cause the one or more processors to receive first operational information regarding a first set of network devices; receive first flow information relating to a first set of traffic flows associated with the first set of network devices; generate a model, based on a machine learning technique, to identify predicted performance of the first set of network devices with regard to the first set of traffic flows; receive or obtain second operational information and/or second flow information regarding the first set of network devices or a second set of network devices; determine path information for the first set of traffic flows or a second set of traffic flows using the model and based on the second operational information and/or the second flow information; configure the first set of network devices or the second set of network devices to implement the path information; and/or update the model based on a machine learning technique and based on observations after the path information is implemented ." Yadav teaches a method and device that receives information relating to the traffic flow between devices, and then generates a model using a machine learning technique. The examiner interprets this model based on traffic flow to be a network data flow model. [0018] " FIGS. 1A-1D are diagrams of an overview of example implementations 100 described herein. As shown in FIG. 1A, and by reference number 102, a network administration device (shown as NAD) may receive a training set of flow information, network topology information, and operational information regarding a plurality of network devices of a network. The network administration device may receive the flow information, the network topology information, and the operational information to generate a model for determining traffic flow paths in the network or another network ." Paragraph 0018 further solidifies the examiner’s interpretation that the model is one representative of a network topology and the data flows within, i.e. a network data flow model. [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results. " [0035] " In this way, the network administration device generates a predictive model using machine learning to determine updated path information for a network of network devices, which permits dynamic improvement and updating of the predictive model, and which may be simpler to implement than a complicated and/or static routing protocol. Furthermore, using a machine learning technique may generate a more efficient routing protocol than using a human-based technique. Further, the network administration device may avoid or limit traffic drops due to black-holing of traffic by misconfigured or malfunctioning network devices. This may be particularly advantageous for failure modes that are not detected by traditional routing protocols, such as network device degradation, black-holing, and/or the like. Also, the network administration device may continuously gather useful telemetry and/or performance information over time, which may permit analysis of network information over time " Yadav teaches that it can then update the generated model based on dynamically changing traffic information. The machine learning technique can iteratively update the model to improve the accuracy of the model and the data it represents.) However, Yadav does not teach that the domain in which the model is representing is part of a multi-domain network. Ganesh, in the same field of endeavor, teaches the domain being part of a multi-domain network ([0019] " It is another object of the present invention to provide system and method for monitoring multi-domain network, which generates visualization of different domains in a telecommunication network across layers and identifies the exact root cause of network element using the layered approach based on configuration, performance and alarm data collected across multiple domains.") . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron, with a method to generate a data flow model of a network/domain, and obtain the measured flow rates and expected flow rates pertaining to the connections of said generated model, with the teaching of Yadav to further update the model according to the rates obtained to be sure the model is accurate, and further with the teachings of Ganesh wherein the method is applied to a domain being part of a multi-domain network. One of ordinary skill in the art need only apply the model generation method taught by Liron, with the updating of a traffic model from Yadav, and further to apply it to a multidomain environment as taught by Ganesh to further increase the accuracy of the generated data flow model, even if given domain does not have an oracle view of other neighboring domains. All so one can generate an accurate representation of a network data flow model that may more efficiently show where bottlenecks occur. Liron, Yadav, and Ganesh do not teach wherein updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain. Seid, in the same field of endeavor, teaches updating the data flow model is based at least in part on one or more data flows or paths of the domain having a bottleneck link outside of the domain ([Column 3, Lines 3-14] " Each VP is allocated a positive guaranteed bandwidth (VP-CIR), and each VC on a VP is also allocated a bandwidth (VC-CIR) greater than or equal to zero. Packets of information to be transmitted over a VC are provided with an address field having local significance for identifying the respective VCs and VPs used by the VPN to which the packets of information are associated. Congestion control of the network is provided such that congestion control and management are carried out on a per VPN basis, and congestion outside of a VPN's logical domain does not affect the performance of the VPN ." Seid discloses a method of packet switching within a network. It recognizes congestion located outside of a VPN's logical domain. Seid further teaches wherein when congestion occurs on a physical path, only a virtual path using bandwidth greater than the respective positive guaranteed bandwidth is required to reduce submission rate of packets onto the network, thereby providing some basic required level of QOS. The examiner interprets the above as an acknowledgment that a bottleneck may occur outside a given domain.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh wherein their update of the data flow model may be based or influenced by a bottleneck existing outside of the immediate domain as taught by Seid. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Seid to more accurately create a data flow model to represent the correct locations of bottleneck/congested links. Proper and accurate mapping is required to better plan flow distribution to take care of areas where bottlenecks may be an issue, even if said bottleneck is outside of the immediate domain. Regarding claim 26, Liron, Yadav, Ganesh, and Seid teach the apparatus of claim 25 (discussed above). However, Liron does not explicitly teach a means to generate an updated data flow model based at least in part on iteratively updating the data flow model. Yadav, in the same field of endeavor, teaches generating an updated data flow model based at least in part on iteratively updating the data flow model ( [0015] " Furthermore, some implementations described herein may update the model using the machine learning technique and based on observations regarding efficacy of the configuration of the path information. In this way, the model may adapt to changing network conditions and topology (e.g., in real time as the network conditions and/or the topology change), which may require human intervention for a predefined routing policy. Thus, network throughput, reliability, and conformance with SLAs is improved. Further, some implementations described herein may use a rigorous, well-defined approach to path selection, which may reduce uncertainty, subjectivity, and inefficiency that may be introduced by a human actor attempting to define a routing policy based on observations regarding network performance." [0016] " Also, some implementations described herein may identify the best paths for traffic associated with different SLAs. Since these best paths may iteratively change based on traffic load and node behavior/faults, the machine learning component of implementations described herein may regularly reprogram the paths for particular traffic flows across the network domain. This reprogramming may be based on dynamic prediction of the traffic flows, traffic drops and delays. Thus, implementations described herein may improve adaptability and versatility of path computation for the network domain in comparison to a rigidly defined routing protocol." [0034] " As shown by reference number 138, the network administration device may compare the updated operational information and/or the updated flow information to the predicted performance information outputted by the path selection model. As shown by reference number 140, the network administration device may update the path selection model using machine learning and based on the comparison of the updated operational information and/or the updated flow information to the predicted performance information. For example, machine learning may provide a mechanism for dynamically or iteratively improving the path selection model in view of results of using the path selection model. When observed results deviate from predicted results, the network administration device may adjust the path selection model using a machine learning algorithm to improve accuracy of the predicted results to better match the observed results" Based on the above, Yadav teaches that flow information changes, and is therefore dynamic. The best paths in the model may “iteratively change” and the machine learning component can update the model based on this “updated flow information”. In order to keep the current model accurate, Yadav may then “ dynamically or iteratively improving the path selection model in view of results of using the path selection model”. The examiner interprets this as generating an updated flow model based on iteratively updating the flow model. ) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the combination teachings of Liron, Yadav, and Ganesh, with the further teaching of Yadav wherein the model is iteratively updated. The motivation to do so would be to ensure an accurate data flow model is available. Data flows can be dynamic in which bottlenecks may occur slowing the flow. Having an updated model that reflects these changes would allow one to better allocate flow within a network/domain . Claim Rejections - 35 USC § 103 07-21-aia AIA Claim s 5, 14, 21, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Liron, Yadav, Ganesh, and Seid in view of Dooze et al. ( US 10931537 B2), hereinafter “Dooze” . Regarding claim 5, Liron, Yadav, Ganesh, and Seid teach the method of claim 4 (discussed above). However, Liron and Genesh do not teach updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold. Dooze, in the same field of endeavor, teaches updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold ([Column 1, Lines 63-65] ” The invention aims to improve the situation by way of a method for updating a predictive model of a variable representative of the operation of a mobile terminal ” Dooze teaches an updating of a predictive flow model. [Column 2, Line 54-67] " By virtue of the invention, the predictive model is updated while minimizing data exchanges. Specifically, the feed message used to update the predictive model is sent by the mobile terminal, and the resulting replacement predictive model is received by the terminal only if the contribution made by the data contained in the feed message to improving the predictive model is sufficient. One way of estimating this contribution is for example the difference between the instantaneous bit rate measured by the cellphone and the instantaneous bit rate estimated by the cellphone using the predictive model. If this difference is large, this means that the predictive model is able to be improved and that the measured bit rate value, as well as the values of the predictors, that the cellphone is able to provide may make a useful contribution to improving it. " The instantaneous bit rate measured by the cellphone is interpreted by the examiner as a measured rate and the instantaneous bit rate measured from using the predictive model is interpreted as an expected rate. The contribution to the data flow by the cellphone is then calculated by finding the difference between the rate based on the predictive model and the instantaneous rate. Depending of the difference meeting a threshold, an improved model might be possible to achieve. The feed threshold described in the following citation is interpreted by the examiner as the accuracy threshold that must be satisfied by the difference between the two flows; [Column 2, Lines 10-13] " generating a feed message, comprising at least the measured value and the values of the predictors, if the difference between the measured value and the estimated value is greater than or equal to a determined threshold, called feed threshold ,".) It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh where their iterative update of the data flow model is limited by a difference between the measured rates and expected rates satisfy some fort of threshold as taught by Dooze. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Dooze to better and more accurately update the data flow model. By setting a limiting threshold one avoids an endless loop of updating the model, creating the opposite effect with an overcalculated and a more-than-likely inaccurate network model. Regarding claim 14, Liron, Yadav, Ganesh, and Seid teach the entity of claim 13 (discussed above). However, Liron, Yadav, and Genesh do not teach updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold. Dooze, in the same field of endeavor, teaches updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold ([Column 1, Lines 63-65] ” The invention aims to improve the situation by way of a method for updating a predictive model of a variable representative of the operation of a mobile terminal ” Dooze teaches an updating of a predictive flow model. [Column 2, Line 54-67] " By virtue of the invention, the predictive model is updated while minimizing data exchanges. Specifically, the feed message used to update the predictive model is sent by the mobile terminal, and the resulting replacement predictive model is received by the terminal only if the contribution made by the data contained in the feed message to improving the predictive model is sufficient. One way of estimating this contribution is for example the difference between the instantaneous bit rate measured by the cellphone and the instantaneous bit rate estimated by the cellphone using the predictive model. If this difference is large, this means that the predictive model is able to be improved and that the measured bit rate value, as well as the values of the predictors, that the cellphone is able to provide may make a useful contribution to improving it. " The instantaneous bit rate measured by the cellphone is interpreted by the examiner as a measured rate and the instantaneous bit rate measured from using the predictive model is interpreted as an expected rate. The contribution to the data flow by the cellphone is then calculated by finding the difference between the rate based on the predictive model and the instantaneous rate. Depending of the difference meeting a threshold, an improved model might be possible to achieve. The feed threshold described herein is interpreted by the examiner as the accuracy threshold that must be satisfied by the difference between the two flows [Column 2, Lines 10-13] " generating a feed message, comprising at least the measured value and the values of the predictors, if the difference between the measured value and the estimated value is greater than or equal to a determined threshold, called feed threshold ,".) It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh where their iterative update of the data flow model is limited by a difference between the measured rates and expected rates satisfy some fort of threshold as taught by Dooze. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Dooze to better and more accurately update the data flow model. By setting a limiting threshold one avoids an endless loop of updating the model, creating the opposite effect with an overcalculated and a more-than-likely inaccurate network model. Regarding claim 21, Liron, Yadav, Ganesh, and Seid teach the non-transitory computer-readable medium of claim 20 (discussed above). However, Liron, Yadav, and Genesh do not teach updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold. Dooze, in the same field of endeavor, teaches updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold ([Column 1, Lines 63-65] ” The invention aims to improve the situation by way of a method for updating a predictive model of a variable representative of the operation of a mobile terminal ” Dooze teaches an updating of a predictive flow model. [Column 2, Line 54-67] " By virtue of the invention, the predictive model is updated while minimizing data exchanges. Specifically, the feed message used to update the predictive model is sent by the mobile terminal, and the resulting replacement predictive model is received by the terminal only if the contribution made by the data contained in the feed message to improving the predictive model is sufficient. One way of estimating this contribution is for example the difference between the instantaneous bit rate measured by the cellphone and the instantaneous bit rate estimated by the cellphone using the predictive model. If this difference is large, this means that the predictive model is able to be improved and that the measured bit rate value, as well as the values of the predictors, that the cellphone is able to provide may make a useful contribution to improving it. " The instantaneous bit rate measured by the cellphone is interpreted by the examiner as a measured rate and the instantaneous bit rate measured from using the predictive model is interpreted as an expected rate. The contribution to the data flow by the cellphone is then calculated by finding the difference between the rate based on the predictive model and the instantaneous rate. Depending of the difference meeting a threshold, an improved model might be possible to achieve. The feed threshold described herein is interpreted by the examiner as the accuracy threshold that must be satisfied by the difference between the two flows [Column 2, Lines 10-13] " generating a feed message, comprising at least the measured value and the values of the predictors, if the difference between the measured value and the estimated value is greater than or equal to a determined threshold, called feed threshold ,".) It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh where their iterative update of the data flow model is limited by a difference between the measured rates and expected rates satisfy some fort of threshold as taught by Dooze. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Dooze to better and more accurately update the data flow model. By setting a limiting threshold one avoids an endless loop of updating the model, creating the opposite effect with an overcalculated and a more-than-likely inaccurate network model. Regarding claim 27, Liron, Yadav, Ganesh, and Seid teach the apparatus of claim 26 (discussed above). However, Liron, Yadav, and Genesh do not teach updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold. Dooze, in the same field of endeavor, teaches updating the data flow model until a difference between the set of measured flow rates and a set of updated expected flow rates satisfies an accuracy threshold ([Column 1, Lines 63-65] ” The invention aims to improve the situation by way of a method for updating a predictive model of a variable representative of the operation of a mobile terminal ” Dooze teaches an updating of a predictive flow model. [Column 2, Line 54-67] " By virtue of the invention, the predictive model is updated while minimizing data exchanges. Specifically, the feed message used to update the predictive model is sent by the mobile terminal, and the resulting replacement predictive model is received by the terminal only if the contribution made by the data contained in the feed message to improving the predictive model is sufficient. One way of estimating this contribution is for example the difference between the instantaneous bit rate measured by the cellphone and the instantaneous bit rate estimated by the cellphone using the predictive model. If this difference is large, this means that the predictive model is able to be improved and that the measured bit rate value, as well as the values of the predictors, that the cellphone is able to provide may make a useful contribution to improving it. " The instantaneous bit rate measured by the cellphone is interpreted by the examiner as a measured rate and the instantaneous bit rate measured from using the predictive model is interpreted as an expected rate. The contribution to the data flow by the cellphone is then calculated by finding the difference between the rate based on the predictive model and the instantaneous rate. Depending of the difference meeting a threshold, an improved model might be possible to achieve. The feed threshold described herein is interpreted by the examiner as the accuracy threshold that must be satisfied by the difference between the two flows [Column 2, Lines 10-13] " generating a feed message, comprising at least the measured value and the values of the predictors, if the difference between the measured value and the estimated value is greater than or equal to a determined threshold, called feed threshold ,".) It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh where their iterative update of the data flow model is limited by a difference between the measured rates and expected rates satisfy some fort of threshold as taught by Dooze. One of ordinary skill in the art need only to apply what is taught in the combination of Liron and Ganesh with the teachings of Dooze to better and more accurately update the data flow model. By setting a limiting threshold one avoids an endless loop of updating the model, creating the opposite effect with an overcalculated and a more-than-likely inaccurate network model . Claim Rejections - 35 USC § 103 07-21-aia AIA Claim s 6, 9, 18, 24, and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Liron, Yadav, Ganesh, and Seid, in view of Imai et al. (US 20130024561 A1), hereinafter “Imai”, and further in view of Nordenstam et al. (US 6442615 B1), hereinafter “Nordenstam” . Regarding claims 9, 18, 24 and 28 Liron, Yadav, Ganesh, and Seid teach claims 1, 10, 19 and 25 (discussed above). However, they do not teach identifying a data flow or a path for which an expected flow rate is greater than a measured flow rate; and adding a virtual link to a set of links modeled via the data flow model, wherein the virtual link is associated with the data flow or the path and the measured flow rate. Imai, in the same field of endeavor, teaches identifying a data flow or a path for which an expected flow rate is greater than a measured flow rate (Examining the following figure from Imai: PNG media_image1.png 618 914 media_image1.png Greyscale Imai introduces a virtual link setter and route determinator that compares existing flow (interpreted as the actual data flow) to a created constraint condition (interpreted as an expected data flow rate). FIG. 5 showcases an example of link cost calculating data in the network management system. It also shows in the columns labeled "Link Traffic Amount" what is interpreted by the examiner as the measured flow rate of the link. When looking at the values of the mentioned columns and compare them to values in the columns labeled "Physical Link Rate" or "Virtual Link rate", it shows the values to be greater. The virtual/physical link rate values is interpreted by the examiner as the expected flow rate.) . However, Imai does not teach adding a virtual link to a set of links modeled via the data flow model, wherein the virtual link is associated with the data flow or the path and the measured flow rate. Nordenstam, in the same field of endeavor, teaches adding a virtual link to a set of links modeled via the data flow model, wherein the virtual link is associated with the data flow or the path and the measured flow rate ([Column 11, Lines 1-8] " The network modification unit 24 shown in FIG. 3 is particularly provided to evaluate different system configurations, that is to calculate how the load situation would change in case there is inserted another network element or link. Thus, the network modification unit 24 together with the I/O unit 26 provides functionality to add new nodes and links into both, the virtual network and the real network ." [Column 5, Lines 13-19] " collect data with respect to a real traffic flow in the network, network modelling means to model the network through a virtual network having virtual links without capacity restrictions imposed thereon, and network load evaluation means to map the actual traffic flow onto the virtual network assuming optimal routing and to compare the capacity used for each virtual link with the capacity assigned thereto ." It is taught above by Nordenstam that the unit 24 from figure 3 may add new nodes an links into the network representing a virtual model and the actual network model. To improve traffic data evaluation in a network, the data on the real traffic flow (interpreted as the actual/measured flow) is used to first model the network, and then adds the respective virtual links to map said network. Each link is given a capacity in the virtual model without restriction, and the evaluation maps the actual traffic flow (interpreted as the data flow) on the virtual network. By applying data corresponding to real traffic flow to created virtual links in a network model, Nordenstam can improve the approach to traffic data evaluation.) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention to apply the teachings of Liron and Genesh to apply the method to generate a data flow model of a network/domain wherein the domain is part of a multi-domain network, obtaining the measured flow rates and expected flow rates pertain to the connections of said generated model, and further update the model according to the rates obtained with the goal to further optimize further optimize said model, with the teachings of Imai wherein a path is identified to have the measured flow rate be less than the expected flow rate. One would further combine this with the teaching of adding a virtual link to the set of obtained links representing the measured flow rate. The motivation to combine Liron, Ganesh, and Imai would be keeping an accurate record of links that are possibly experiencing a bottleneck and therefore have a lower output rate than expected, i.e. measured/actual rate is less than expected rate. Then one of ordinary skill in the art would further apply the teaching of Nordenstam wherein virtual links are added corresponding to measured links to have the virtual model reflect a more accurate representation of actual/measured flow rates. Regarding claims 6 and 31 , claims 6 + 31 recite essentially equivalent to limitations of claim 9. Hence, claims 6 + 31 are rejected for the similar rationale as claim 9 . Claim Rejections - 35 USC § 103 07-21-aia AIA Claim s 15, 22 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Liron, Yadav, Ganesh, and Seid, and further in view of Nordenstam et al. (US 6442615 B1), hereinafter “Nordenstam” . Regarding claims 15, 22 and 28 , Liron, Yadav, Ganesh, and Seid do not teach add, to a dataflow model, a virtual link that is based at least on a data flow in an other domain . Nordenstam, in the same field of endeavor, teaches adding a virtual link to the data flow model, ([Column 11, Lines 1-8] " The network modification unit 24 shown in FIG. 3 is particularly provided to evaluate different system configurations, that is to calculate how the load situation would change in case there is inserted another network element or link. Thus, the network modification unit 24 together with the I/O unit 26 provides functionality to add new nodes and links into both, the virtual network and the real network ." [Column 5, Lines 13-19] " collect data with respect to a real traffic flow in the network, network modelling means to model the network through a virtual network having virtual links without capacity restrictions imposed thereon, and network load evaluation means to map the actual traffic flow onto the virtual network assuming optimal routing and to compare the capacity used for each virtual link with the capacity assigned thereto ." It is taught above by Nordenstam that the unit 24 from figure 3 may add new nodes an links into the network representing a virtual model and the actual network model. To improve traffic data evaluation in a network, the data on the real traffic flow (interpreted as the actual/measured flow) is used to first model the network, and then adds the respective virtual links to map said network. Each link is given a capacity in the virtual model without restriction, and the evaluation maps the actual traffic flow (interpreted as the data flow) on the virtual network. By applying data corresponding to real traffic flow to created virtual links in a network model, Nordenstam can improve the approach to traffic data evaluation.) . Claim Rejections - 35 USC § 103 07-21-aia AIA Claim 32 is rejected under 35 U.S.C. 103 as being unpatentable over Liron, Yadav, Ganesh, and Seid, and further in view of Ros-Giralt et al. (US 12137051 B1), hereinafter “Ros” . Regarding claim 32, Liron, Yadav, Ganesh, and Seid teach claims 1 (discussed above). However, they do not teach wherein the data flow model comprises a path gradient graph (PGG) model. Ros, in the same field of invention, teaches using path gradient graph to better analyze bottleneck links (col.1 lines 53-65). Hence, it would have been obvious for one of ordinary skill in the art to combine the teaching of Ros to utilize path gradient graph in the data flow model because it can reveal interactions of bottleneck links and system-wide ripple effects caused by perturbations in the network (col.1 lines 57-62). Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUNG C DINH whose telephone number is (571)272-3943. The examiner can normally be reached 10am – 5pm EST. 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, Sudhanshu Pathak can be reached at (571) 272-5509. 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. DUNG C. DINH Primary Examiner Art Unit 6214 /DUNG C DINH/ Primary Examiner, Art Unit 6214 Application/Control Number: 18/049,159 Page 2 Art Unit: 6214 Application/Control Number: 18/049,159 Page 3 Art Unit: 6214 Application/Control Number: 18/049,159 Page 4 Art Unit: 6214 Application/Control Number: 18/049,159 Page 5 Art Unit: 6214 Application/Control Number: 18/049,159 Page 6 Art Unit: 6214 Application/Control Number: 18/049,159 Page 7 Art Unit: 6214 Application/Control Number: 18/049,159 Page 8 Art Unit: 6214 Application/Control Number: 18/049,159 Page 9 Art Unit: 6214 Application/Control Number: 18/049,159 Page 10 Art Unit: 6214 Application/Control Number: 18/049,159 Page 11 Art Unit: 6214 Application/Control Number: 18/049,159 Page 12 Art Unit: 6214 Application/Control Number: 18/049,159 Page 13 Art Unit: 6214 Application/Control Number: 18/049,159 Page 14 Art Unit: 6214 Application/Control Number: 18/049,159 Page 15 Art Unit: 6214 Application/Control Number: 18/049,159 Page 16 Art Unit: 6214 Application/Control Number: 18/049,159 Page 17 Art Unit: 6214 Application/Control Number: 18/049,159 Page 18 Art Unit: 6214 Application/Control Number: 18/049,159 Page 19 Art Unit: 6214 Application/Control Number: 18/049,159 Page 20 Art Unit: 6214 Application/Control Number: 18/049,159 Page 21 Art Unit: 6214 Application/Control Number: 18/049,159 Page 22 Art Unit: 6214 Application/Control Number: 18/049,159 Page 23 Art Unit: 6214 Application/Control Number: 18/049,159 Page 24 Art Unit: 6214 Application/Control Number: 18/049,159 Page 25 Art Unit: 6214 Application/Control Number: 18/049,159 Page 26 Art Unit: 6214 Application/Control Number: 18/049,159 Page 27 Art Unit: 6214 Application/Control Number: 18/049,159 Page 28 Art Unit: 6214 Application/Control Number: 18/049,159 Page 29 Art Unit: 6214 Application/Control Number: 18/049,159 Page 30 Art Unit: 6214 Application/Control Number: 18/049,159 Page 31 Art Unit: 6214 Application/Control Number: 18/049,159 Page 32 Art Unit: 6214 Application/Control Number: 18/049,159 Page 33 Art Unit: 6214 Application/Control Number: 18/049,159 Page 34 Art Unit: 6214 Application/Control Number: 18/049,159 Page 35 Art Unit: 6214 Application/Control Number: 18/049,159 Page 36 Art Unit: 6214 Application/Control Number: 18/049,159 Page 37 Art Unit: 6214 Application/Control Number: 18/049,159 Page 38 Art Unit: 6214 Application/Control Number: 18/049,159 Page 39 Art Unit: 6214 Application/Control Number: 18/049,159 Page 40 Art Unit: 6214 Application/Control Number: 18/049,159 Page 41 Art Unit: 6214 Application/Control Number: 18/049,159 Page 42 Art Unit: 6214 Application/Control Number: 18/049,159 Page 43 Art Unit: 6214 Application/Control Number: 18/049,159 Page 44 Art Unit: 6214 Application/Control Number: 18/049,159 Page 45 Art Unit: 6214 Application/Control Number: 18/049,159 Page 46 Art Unit: 6214 Application/Control Number: 18/049,159 Page 47 Art Unit: 6214 Application/Control Number: 18/049,159 Page 48 Art Unit: 6214 Application/Control Number: 18/049,159 Page 49 Art Unit: 6214 Application/Control Number: 18/049,159 Page 50 Art Unit: 6214 Application/Control Number: 18/049,159 Page 51 Art Unit: 6214 Application/Control Number: 18/049,159 Page 52 Art Unit: 6214 Application/Control Number: 18/049,159 Page 53 Art Unit: 6214
Prosecution Insights