DETAILED ACTION
Response to Amendment
This Office Action is responsive to the Amendment filed on: 07/15/2026.
Claims 1-20 are pending for Examination.
Claims 1-3, 9-10, and 17 have been amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statements
The information disclosure statement (IDS) submitted on: 07/17/2026 is determined to be compliance with the provisions of 37 CFR 1.97. Accordingly, this IDS is being considered by the Examiner.
Response to Arguments
Applicant's arguments filed 07/15/2026 have been fully considered but they are determined not to be persuasive.
With respect to claims 1, 9, and 17, Applicant argues the amended claim limitations recited within each of its independent claims sufficiently overcome the §103 rejection (based on Seetharaman in view of Balaiah), respectively applied thereto, in the previous Office Action. Applicant’s Remarks at pp. 9-12. The Examiner agrees.
However, in view of the claim amendments made by Applicant in its most-recent response, a new grounds of rejection is applied in this Office Action, i.e., the combination of Wang, to substantially reject the amended claim subject matter at issue of claims 1, 9, and 17. Therefore, Applicant’s argument that the §103 rejection based on Seetharaman in view of Balaiah, has been overcome by its claim amendments, has effectively been rendered moot. The Examiner also notes that there are no other specific arguments to respond to regarding deficiencies of Seetharaman and/or Balaiah, as applied in the current Office Action.
As such, and for all of the above reasons, Applicant’s arguments asserted for each of claims 1, 9, and 17 are determined not to be persuasive, or have otherwise been rendered moot.
With respect to the dependent claims, Applicant only argues these claims as being allowable based on their respective dependence from one of the above-indicated independent claims. Applicant’s Remarks at pp. 10-14. As such, Applicant’s arguments with respect to the dependent claims are likewise determined not to be persuasive or have otherwise rendered moot, for the same reasons described above for the respective independent claims.
Claim Interpretation – Alternative Claim Language
The claims of the instant application are given their Broadest Reasonable Interpretation (BRI) using the plain meaning of the claim language in light of the specification, as it would be understood by one of ordinary skill in the art. Accordingly, the BRI of an alternative claim limitation or term can be determined to be the least-limiting interpretation, consistent with the specification. In this context, the term “or” by plain meaning can be interpreted to alternatively be: one or the other (i.e., A or B), but not both (i.e., not A and B). The term “and/or” by plain meaning can be interpreted to be: “and” or alternatively “or,” but not both, as this would not make sense. In this context, the forward-slash “/” is equivalent to the alternative “or.” Likewise, the alternative terms “at least one of,” “one or more of,” and the like, followed by multiple alternative claim limitations can be reasonably interpreted to be only “one of” a group of alternative claim limitations.
Prior art disclosing any one of multiple alternative claim limitations discloses matter within the scope of the claimed invention. "When a claim covers several structures or compositions, either generically or as alternatives, the claim is deemed anticipated if any of the structures or compositions within the scope of the claim is known in the prior art." Brown v. 3M, 265 F.3d 1349, 1351, 60 USPQ2d 1375, 1376 (Fed. Cir. 2001) (claim to a system for setting a computer clock to an offset time to address the Year 2000 (Y2K) problem, applicable to records with year date data in "at least one of two-digit, three-digit, or four-digit" representations, was held anticipated by a system that offsets year dates in only two-digit formats). See MPEP 2131.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1-3, 5, 7-11, 13, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub. 2023/0261932 A1, Seetharaman et al. (hereinafter “Seetharaman”), in view of US PG Pub. 2023/0107735 A1, Wang et al. (hereinafter “Wang”), in further view of US PG Pub. 2020/0274782 A1, Balaiah et al. (hereinafter “Balaiah”).
With Respect to Claim 1, Seetharaman teaches:
A method implemented at least in part by a central entity across a plurality of networks (paras. [0022]-[0023] and [0073]-[0080]; and MD-Orchestrator/Apparatus 102/1002 of Figs. 1 and 10), the method comprising:
receiving from first networks associated with a plurality of tenants, first telemetry data associated with the first networks and a plurality of first applications that are implemented within one or more of the first networks (paras. [0023]-[0023], and [0026]-[0027]; SD-WAN Controller 112 and Application Performance Monitor 116 of Fig. 1, and Fig. 8 —a MDO/MDNOA system can receive telemetry data from a first software defined (SD) access network/network service, i.e., an SD-WAN, that is related to performance/policies of, i.e., KPIs or performance thresholds, of its supported applications —tenants are interpreted to be users of the respective network applications);
generating, based at least in part on the first telemetry data, an application model for an application of the plurality of first applications (paras. [0027], [0029]-[0031], [0035]-][0036], [0042] and [0049]; and blocks 208, 210, 214 and 218 of Fig. 2 —a machine-learning model can be created/generated for an application(s) associated with the first network(s), i.e., SD-WAN(s), based on received telemetry data, i.e., KPIs/thresholds/policies, for performing impact analysis of network segments/applications);
receiving, from a second network associated with an enterprise user, second telemetry data associated with the second network and a plurality of second applications that are implemented within the second network (paras. [0002]-[0003], [0023]-[0023], and [0026]-[0027]; and Cloud Network Controller 114 and Application Performance Monitor 116 of Fig. 1 —telemetry data including performance/policies, i.e., KPIs or performance thresholds, of an enterprise SD-WAN network’s supported application(s) can be received by the a MDO/MDNOA system —an enterprise network application can have an associated enterprise user thereof);
generating, based at least in part on the application model and the second telemetry data, an impact analysis associated with the second network (paras. [0026], [0029], [0039], [0045]-[0046], and [0062]-[0064]; blocks 412 and 414 of Fig. 4, and Figs. 6 and 8 —an impact analysis can be generated, which is associated with an enterprise network, i.e., an enterprise SD-WAN, described in paras. [0002]-[0003], and based on a modeling of a SD-WAN application (a machine-learning model) of a first network, i.e., an SD-WAN, and second telemetry data, i.e., performance/KPI/policies, etc. of a second, enterprise network —See e.g., the impacted applications and contributions of different network segments of Fig. 6, and telemetry KPI attribution for different network services per application of Fig. 8).
However, Seetharaman does not explicitly teach:
generating an application model configured to provide output regarding a predicted impact of an application of the plurality of first applications in a target network; and
generating an impact analysis indicating a predicted impact on the second network of introducing the first application into the second network.
Wang does teach:
generating an application model configured to provide output regarding a predicted impact of an application in a target network (paras. [0009]-[0010], [0020]-[0024], and [0093]-[0094]; networks 110A-N, NSO 102 w/SDWAN controller 104 of Fig. 1, and ML model 534 trained w/training data 506 of Fig. 5A —prior to forwarding/switching an application/flow between networks/NW links, a ML model can be generated/trained that is associated with a particular WAN/WAN link (e.g., link 142A-A can be associated with WAN transport network 110A) and training data can include both network/application performance data, and including historical data —later the trained model can be run, i.e., by an AI engine, and applied to a different WAN/WAN link to predict future application/network performance within the different WAN/WAN link); and
generating an impact analysis indicating a predicted impact on the second network of introducing the first application into the second network (paras. [0009]-[0010], [0020]-[0024], and [0093]-[0097]; networks 110A-N, NSO 102 w/SDWAN controller 104 of Fig. 1, and AI engine 522 running pretrained ML Model 524 of Fig. 5A-B —an AI engine, can run a trained ML model for an application/flow, i.e., associated with an Application A and/or an Application B, to predict whether/when to transfer an Application traffic to a different WAN/WAN link based on various requirements and data —in this regard, a generated impact analysis prediction may be based on a second WAN/WAN links suitability for the application/flow, considering the trained ML model, and both application requirements and WAN input).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman’s model-based impact analysis solution to further include using a model for an application’s impact in a first network, to predict the application’s impact in a second, target network, as taught by Wang.
The motivation for doing so would have been to better predict an impact of switching an application/flow, i.e., a web application running on a UE, to a new WAN/link, considering known network performance and its effect on application, i.e., QoS/QoE, as recognized by Wang.
However, Seetharaman in view of Wang does not explicitly teach:
outputting the impact analysis to a user device for display.
Balaiah does teach:
outputting the impact analysis to a user device for display (paras. [0034]-[0036], [0087], [0114]-[0115], [0120], and [0124]-[0127]; enterprise apps 708 and cloud apps 76 of Fig. 7, block 854 of Fig. 10, and UI of Fig. 16 —an impact analysis, based on machine learning, depicting impacted applications can be output to a user at a UE, as depicted in the GUI of Fig. 16 —impacted applications can be associated with a private, enterprise network(s) and/or a cloud-based network(s), as depicted in Fig. 7).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman in view of Wang’s impact analysis solution to include outputting an impact analysis to a user at a UE display, as taught by Balaiah.
The motivation for doing so would have been to better inform the end-user of its impacted enterprise/cloud-based application(s), as recognized by Balaiah (paras. [0034]-[0036], [0087], [0114]-[0115], [0120], and [0124]-[0127]).
With respect to claim 2, Seetharaman in view of Wang and Balaiah teaches the method of claim 1.
However, Seetharaman does not explicitly teach:
generating output data associated with the application, the output data including at least one of application bandwidth requirements per user, traffic volume generated by the application per user, SLA requirements within a network at which the application behaves optimally, traffic flow characteristics, usage pattern and seasonality characteristics, pattern of access or prioritization characteristics.
Balaiah does teach:
generating output data associated with an application, the output data including at least one of application bandwidth requirements per user (paras. [0104], [0120]-[0121] and [0128]; Table 2 and Figs. 16, and 18-19 —a GUI output can generate and/or drill down to a specific application output for a specific user over time, i.e., peter_williams, relating to various application performance metrics, such as bandwidth usage), traffic volume generated by the application per user (paras. [0104], [0120]-[0121] and [0128]; Table 2 and Figs. 12, 16, and 18-19 —a GUI output can present a specific application’s output for multiple users over time, relating to various application performance metrics, such as traffic volume which the Examiner interprets to be equivalent to bandwidth usage per user relating to the same application), SLA requirements within a network at which the application behaves optimally, traffic flow characteristics (paras. [0130] and [0137]; and Figs. 19 and 28 —traffic flow detail/characteristic, including bandwidth usage, jitter, packet loss, etc., over particular network segments for a period of time, can be output to a GUI model, as depicted in Fig. 28), usage pattern and seasonality characteristics, pattern of access or prioritization characteristics (paras. [0104], [0120]-[0121] and [0128]; Table 2 and Fig. 28 —a GUI output can generate a pattern of access output for a particular user, i.e., John Doe, relating to user activity over a set time period, corresponding to various applications’ usage/access, as depicted in Fig. 23 —alternative terms, such as: “at least one of” and “or,” only require examination on-the-merits of a single claimed alternative, for the reasons explained above in the Claim Interpretation — Alternative Claim Language section).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman’s impact analysis solution to include outputting its impact analysis, including various performance metrics, to a user at a UE display, as taught by Balaiah.
The motivation for doing so would have been to better inform the end-user of its impacted enterprise/cloud-based application(s) by considering various, known performance metrics/characteristics, as recognized by Balaiah (paras. [0034]-[0036], [0087], [0114]-[0115], [0120], and [0124]-[0127]).
With respect to claim 3, Seetharaman in view of Wang and Balaiah teaches:
The method of claim 1, further comprising:
determining based at least in part on the first telemetry data, application characteristics for the application (Seetharaman: paras. [0027], [0029]-[0031], [0035]-][0036], [0042] and [0049]; and blocks 208, 210, 214 and 218 of Fig. 2 —a machine-learning model can be created/generated for an application(s) associated with the first network(s), i.e., SD-WAN(s), based on received telemetry data, i.e., KPIs/thresholds/policies, for performing impact analysis of network segments/applications), the application characteristics including at least one of flow telemetry data, interface statistic data, link characteristic data, quality of service prioritization data, or application quality metrics and quality of service prioritization data (Seetharaman: paras. [0029], [0046]-[0048], and [0064]-[0065] —application characteristics can include various quality metrics related to application performance considering SLA prioritization for application traffic, considering application latency and bandwidth requirements, etc., i.e., for video services and other applications requiring higher QoS levels —the Examiner interprets this subject matter to be equivalent to QoS service prioritization —alternative terms, such as: “at least one of” and “or,” only require examination on-the-merits of a single claimed alternative, for the reasons explained above in the Claim Interpretation — Alternative Claim Language section).
With respect to claim 5, Seetharaman in view of Wang and Balaiah teaches the method of claim 1, further comprising:
determining network characteristics associated with the second network based at least in part of the second telemetry data (Seetharaman: paras. [0002]-[0003], [0023]-[0023], and [0026]-[0027]; and Application Performance Monitor 116 of Fig. 1 —a MDO/MDNOA system can determined various network characteristics, i.e., bandwidth, latency, jitter, etc., based on telemetry data including performance/policies, i.e., KPIs, thresholds etc., received from an enterprise SD-WAN network), and wherein the impact analysis is further generated based at least in part on inputting the network characteristics to the application model (Seetharaman: paras. [0026], [0029], [0039], [0045]-[0046], and [0062]-[0064]; blocks 412 and 414 of Fig. 4, and Figs. 6 and 8 —an impact analysis can be generated based on a modeling of a SD-WAN application (a machine-learning model) of a first network, i.e., an SD-WAN, and network characteristics of a second, enterprise network —See e.g., the impacted applications and contributions of different network segments of Fig. 6, and telemetry KPI attribution for different network services per application of Fig. 8).
However, Seetharaman does not explicitly teach:
the network characteristics including network topology data, flow telemetry data, interface statistic data, link characteristic data, policy data, usage patterns per existing application, and user data.
Balaiah does teach:
determining network characteristics including:
network topology data (paras. [0034] and [0043]; and Figs. 1 and 28 — network topology/infrastructure, i.e., devices, connections, etc., can be considered in modeling an application),
flow telemetry data (paras. [0034], [0102], and [0130]-[0132]; Figs. 24 and 28 —application flow telemetry data, such as flow performance, bandwidth, latency, jitter, loss, etc., can be considered in modeling an application),
interface statistic data (paras. [0034], [0102], and [0130]-[0132]; Figs. 12-15, 18-20, 24 and 28 —application performance statistical data can be considered in modeling an application),
link characteristic data (paras. [0098], [0106], [0125]and [0130]-[0132]; and Fig. 28 —link performance statistical data can be considered in modeling an application),
policy data (paras. [0022]-[0027] and [0061]-[0062]; and Network Policy Module 106 —network policy data can be considered in modeling an application),
usage patterns per existing application (paras. [0047] and [0072] —network resource/application usage patterns can be considered in modeling an application), and
user data (paras. [0039]-[0041], [0052]-[0054], [0062] and [0064] —user data, i.e., user location, user service KPIs, user groups, can be considered in modeling an application).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman’s impact analysis solution to include consideration of various additional network/application performance characteristics, as taught by Balaiah.
The motivation for doing so would have been to consider other known application performance metrics when considering impact analysis, as recognized by Balaiah (paras. [0034], [0098], [0102], [0106], [0125], and [0130]-[0132]; Figs. 12-15, 18-20, 24, and 28).
With respect to claim 7, Seetharaman in view of Wang and Balaiah teaches:
The method of claim 1, wherein the impact analysis comprises one or more recommendations associated with including the application in the second network, the one or more recommendations corresponding to one or more network characteristics of the second network or one or more application characteristics (Seetharaman: paras. [0118]-[0122], [0136]-[0137], [0143]-[0148]; and block 854 Fig. 10, Figs. 11-12, and 15-21 —various alerts, including high-severity alerts, can be provided to a user via a GUI regarding an enterprise network application that may be problematic —the Examiner interprets alerting a tenant of an impacted application associated with a high-severity alert can act as a visual recommendation not to add/use the application or an associated network segment with the application’s data flow).
With respect to claim 8, Seetharaman in view of Wang and Balaiah teaches the method of claim 1, further comprising:
generating, based at least in part on the first telemetry data, one or more second application models for one or more second applications of the plurality of first applications (Seetharaman: paras. [0027], [0029]-[0031], [0035]-][0036], [0042] and [0049]; and blocks 208, 210, 214 and 218 of Fig. 2 —any number of machine-learning model(s) can be created/generated for an application(s) associated with the first network(s), i.e., SD-WAN(s), based on received telemetry data, i.e., KPIs/thresholds/policies, for performing impact analysis of network segments/applications); and
generating, based at least in part on the one or more second application models and the second telemetry data, one or more second impact analyses associated with the second network (Seetharaman: paras. [0026], [0029], [0039], [0045]-[0046], and [0062]-[0064]; blocks 412 and 414 of Fig. 4, and Figs. 6 and 8 —any number of impact analyses can be generated, which is associated with an enterprise network, i.e., an enterprise SD-WAN, and based on a modeling of a SD-WAN application (a machine-learning model) of a first network, i.e., an SD-WAN, and second telemetry data, i.e., performance/KPI/policies, etc. of a second, enterprise network —See e.g., the impacted applications and contributions of different network segments of Fig. 6, and telemetry KPI attribution for different network services per application of Fig. 8).
However, Seetharaman does not explicitly teach:
outputting the one or more second impact analyses to the user device for display.
Balaiah does teach:
outputting the one or more second impact analyses to the user device for display (paras. [0034]-[0036], [0087], [0114]-[0115], [0120], and [0124]-[0127]; enterprise apps 708 and cloud apps 76 of Fig. 7, block 854 of Fig. 10, and UI of Fig. 16 —any number of impact analyses, based on machine learning, depicting impacted application(s) can be output to a user at a UE, as depicted in the GUI of Fig. 16 —impacted applications can be associated with a private, enterprise network(s) and/or a cloud-based network(s), as depicted in Fig. 7).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman’s impact analysis solution to include outputting its impact analysis to a user at a UE display, as taught by Balaiah.
The motivation for doing so would have been to better inform the end-user of its impacted enterprise/cloud-based application(s), as recognized by Balaiah (paras. [0034]-[0036], [0087], [0114]-[0115], [0120], and [0124]-[0127]).
With respect to claim 9, this claim recites similar features to independent claim 1, except claim 9 is directed to a system comprising one or more processors and one or more computer-readable media (Seetharaman: paras. [0022]-[0027] and [0073]-[0080]; MDO 102 of Fig. 1, and computer system 1002 with processor 1004 and memory 1026/1028/1030 of Fig. 10). As such, claim 9 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for independent claim 1.
With respect to claim 10, this claim recites similar features to dependent claim 2. As such, claim 10 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 2.
With respect to claim 11, this claim recites similar features to dependent claim 3. As such, claim 11 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 3.
With respect to claim 13, this claim recites similar features to dependent claim 5. As such, claim 13 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 5.
With respect to claim 15, this claim recites similar features to dependent claim 7. As such, claim 15 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 7.
With respect to claim 16, this claim recites similar features to dependent claim 8. As such, claim 16 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 8.
With respect to claim 17, this claim recites similar features to independent claim 1, except claim 17 is directed to one or more non-transitory computer-readable media maintaining processor-executable instructions (Seetharaman: paras. [0022]-[0027] and [0073]-[0080]; MDO 102 of Fig. 1, and computer system 1002 memory 1026/1028/1030 of Fig. 10). As such, claim 17 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for independent claim 1.
With respect to claim 19, this claim recites similar features to dependent claim 5. As such, claim 19 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 5.
With respect to claim 20, this claim recites similar features to dependent claim 7. As such, claim 20 is likewise rejected under §103 based on Seetharaman in view of Wang and Balaiah, for the same reasons explained above for dependent claim 7.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Seetharaman in view of Wang and Balaiah, in further view of US PG Pub 2016/0080280 A1, Ramachandran et al. (hereinafter “Ramachandran”).
With respect to claim 4, Seetharaman in view of Wang and Balaiah teaches the method of claim 1.
However, Seetharaman in view of Wang and Balaiah does not explicitly teach:
wherein the application model is accessed based on a request from a device of the enterprise user of a second network, the request identifying the application as being added to the second network.
Ramachandran does teach:
receiving a request identifying an application to be added to an enterprise network, and accessing an application model in response to the request (paras. [0027] [0192] [0229], [0438], [0647]-[0648] and [0885]-[0893]; and Figs. 6 and 10 —a multi-tenant controller can receive a request, including an application ID, from an enterprise user/tenant to add an SaaS application/application site, and in response a model/impact of the application can be accessed).
It would have been prima-facie obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified Seetharaman in view of Wang and Balaiah’s impact analysis solution to include accessing an application model in response to an enterprise user’s request to add a new application, as taught by Ramachandran.
The motivation for doing so would have been to trigger the application model access with a user request, as recognized by Ramachandran (paras. [0027] [0192] [0229], [0438], [0647]-[0648] and [0885]-[0893]; and Figs. 6 and 10).
With respect to claim 12, this claim recites similar features to dependent claim 4. As such, claim 12 is likewise rejected under §103 based on Seetharaman in view of Wang, Balaiah, and Ramachandran, for the same reasons explained above for dependent claim 4.
Allowable Subject Matter
Claim 6, 14, and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
With respect to claims 6, 14, and 18, none of the identified prior art references, individually, or in obvious combination under §103, teach/suggest all of the similar limitations recited in dependent claims 6, 14, and 18 with respect to: “the impact analysis include[ing] one or more outputs indicating one or more sites that meet one or more requirements of the application, one or more sites that fail to meet the one or more requirements of the application, one or more choke points within the second network, additional bandwidth requirements associated with one or more locations within the second network, one or more ISPs that support the application, one or more ISPs that do not support the application, an impact of the application on one or more second applications within the second network, one or more policies within the second network that are met, and one or more policies within the second network that are not met.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure is as follows:
US PG Pub 2024/0364581 A1, Pannu et al.: teaches application model training between various networks/links, and impact analysis with prediction of application performance in the networks considering network diversity and historical input.
US Patent 12/476,918 B2, Wang et al.: teaches AI-assisted network/link selection for SD-WAN-based application services/flow with impact analysis performance predictions.
US Patent 12/355,613 B2, Kalintsev et al.: teaches application flow and network modeling solutions including impact analysis and performance predictions.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Scott Schlack whose telephone number is (571)272-2332. The Examiner can normally be reached Mon. through Fri., from 11am-6pm 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, Moo Jeong can be reached at (571)272-9617. 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.
/Scott A. Schlack/Examiner, Art Unit 2418
/Moo Jeong/Supervisory Patent Examiner, Art Unit 2418
