DETAILED ACTION
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 .
Response to Amendment
Applicant’s Submission filed on 02/18/2026 has been entered. Claims 1-20 are pending in the application. Claims 1, 5, 8, 11, 15, 18 and 20 have been amended and claim 2-4, 6-7, 9-10, 12-14, 16-17, and 19 were previously presented.
Response to Arguments
Applicant's arguments filed on 02/18/2026 have been fully considered but they are not persuasive.
Applicant argues that Khurshid fails to teach or suggest at least "configuring, by the device, the predictive networking engine based on the set of one or more constraints, the configuring including configuring the predictive networking engine to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, or refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints," in claims 1 and 11 (Page 8-9, Remarks).
In response to A), the examiner respectfully disagrees. Khurshid teaches configure the predictive networking engine based on the set of one or more constraints ([0050] states “the network verification system may provide a flexible format to specify a query that requests retrieval of predicted network behavior subject to user-specified constraints. These constraints may describe the type of data flow traffic of interest, as well as the kind of paths through the network “and [0125] describes including of a graphical interface to allow users to interactively select a policy template, enter parameters, and request to define the behavior/policies to be verified., as stated in [0123] lines 10-12. That implies the configuration of the predictive networking engine based on the constraints), the predictive networking engine being configured to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0149] states “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query. For example, if a diff query determines that an earlier snapshot better meets an intent parameter for particular devices or a particular region of the network, the system can recommend that the configuration for those devices or that particular region be returned to their configurations as in the earlier snapshot.” And [0150] describes if the pre-deployment verification indicates that all intents are satisfied, the system may automatically make the changes and notify the user. These parts implies the system uses query results to recommend changes to the network), refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0147] states “the system (1) receives modified configurations from a user, (2) builds the pre-deployment snapshot as discussed above, (3) verifies a predefined set of intents within the pre-deployment snapshot; then, (4) if all intents are satisfied, the configuration change can be automatically deployed to each physical device in the network in order to modify its behavior, or (5) if not all intents are satisfied, results or alerts are pushed to the user but the configuration change is not deployed.” And Claim 18 states “upon verifying that the modifications comply with the network policies, sending the modifications to the network devices for adoption by the network devices.” That implies the system automated deployment prevention.[0072] using the pre-deployment verification to avoid the implementation of changes that fails to meet the constraints), or refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints( we don't give that limitation patentable weight due to the use of "or" which means the limitation is written in the alternative). Therefore, the office action still teach the limitations as currently claimed.
Applicant argues that Khurshid fails to teach or suggest the features of Applicant's amended claim 20 (Page 10, Remarks).
In response to B), the examiner respectfully disagrees. Khurshid teaches providing, by the device, the plurality of characteristics of the different portions of a network to a user interface (Abstract, lines 11-18, the data structure stores the information (characteristics ) about the network including the different variables then, the user interface can receive and display these characteristics of network virtually, [0135], lines 1-5, [0016], Figs. 6-7 show how the user interface display the available variables to the user); ; receiving, at the device and via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network (As described in Abstract “A user-interface is configured to receive queries from a user that request verification of network policies and predictions of network behavior. The user-interface is configured to display responses to the queries that are obtained using the data structure”, which implies the user interface can receive these queries and then display the results (responses) of these queries to the user, [0050], lines 1-6, describes the flexible query format to support constraints on traffic types, paths, and network objects which allows the users to determine specific detailed constraints to limit the recommendation or analysis [0051], lines 7-12, “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query” [0149], lines 1-3, [0016], Fig. 6 show how the user can input constraints via user interface), and configuring, by the device, the predictive networking engine based on the set of one or more constraints ([0050] states “the network verification system may provide a flexible format to specify a query that requests retrieval of predicted network behavior subject to user-specified constraints. These constraints may describe the type of data flow traffic of interest, as well as the kind of paths through the network “and [0125] describes including of a graphical interface to allow users to interactively select a policy template, enter parameters, and request to define the behavior/policies to be verified., as stated in [0123] lines 10-12. That implies the configuration of the predictive networking engine based on the constraints), the configuring including configuring the predictive networking engine to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0149] states “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query. For example, if a diff query determines that an earlier snapshot better meets an intent parameter for particular devices or a particular region of the network, the system can recommend that the configuration for those devices or that particular region be returned to their configurations as in the earlier snapshot.” And [0150] describes if the pre-deployment verification indicates that all intents are satisfied, the system may automatically make the changes and notify the user. These parts implies the system uses query results to recommend changes to the network), refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0147] states “the system (1) receives modified configurations from a user, (2) builds the pre-deployment snapshot as discussed above, (3) verifies a predefined set of intents within the pre-deployment snapshot; then, (4) if all intents are satisfied, the configuration change can be automatically deployed to each physical device in the network in order to modify its behavior, or (5) if not all intents are satisfied, results or alerts are pushed to the user but the configuration change is not deployed.” And Claim 18 states “upon verifying that the modifications comply with the network policies, sending the modifications to the network devices for adoption by the network devices.” That implies the system automated deployment prevention. [0072] using the pre-deployment verification to avoid the implementation of changes that fails to meet the constraints), or refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints.( we don't give that limitation patentable weight due to the use of "or" which means the limitation is written in the alternative). Therefore, the office action still teach the limitations as currently claimed.
Applicant argues that the remaining claims, dependent claims are allowable for similar reasons (Pages 10-11, Remarks).
Examiner respectfully disagrees, for at least the same reasons given in the response above, and as detailed in the Claim Rejections section.
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.
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.
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-6, 8-13, 15-16, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur et al. (US-20200382414-A1) in view of Khurshid et al. (US-20220094614-A1).
As to claims 1-3, 5-6, 8-9 see similar rejections to claims 11-13, 15-16, 18-19, respectively. The apparatus teaches the methods.
Regarding claim 10 (Original), Vasseur and Khurshid teach the method as in claim 1.
Vasseur further teaches wherein the predictive networking engine comprises a machine learning model configured to predict issues in the network ([0040], [0042], [0048], claim 4, describe key functionality of MLFF module 304 is to train any number of machine learning-based models to predict different network elements).
Regarding claim 11 (Currently Amended), Vasseur teaches an apparatus, comprising: one or more network interfaces, a processor coupled to the one or more network interfaces ; and a memory configured to store instructions that, when executed by the processor (Fig. 2, [0029]-[0031], illustrate an apparatus (device) includes network interfaces “Device 200 comprises one or more network interfaces 210, one or more processors 220, and a memory 240 interconnected by a system bus 250, and is powered by a power supply 260.” And [0033] describes process (services) 248 contains computer executable instructions executed by the processor to perform functions of the method. ([0031]-[0032], illustrate the operating system as a software portions of which are typically resident in memory 240 and executed by the processor(s), functionally organizes the node, invoking network operations in support of software processors and/or services executing on the device to perform the method); configure the processor to identify a plurality of characteristics of different portions of a network for which a predictive networking engine is available (Fig. 3, [0043]-[0046], Table 1, theses sections describe how the telemetry collection module gathering the telemetry data along with the set of candidate telemetry variables (set of characteristics /variables requested as shown in Table 1) from network devices, which are required for model training by MLFF module (can be used by machine learning module as a predictive network engine [0083], lines 14-17));
Vasseur fails to teach provide information indicative of the plurality of characteristics of the different portions of a network to a user interface; receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network, and configure the predictive networking engine based on the set of one or more constraints, the predictive networking engine being configured to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, or refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints.
However, Khurshid teaches provide information indicative of the plurality of characteristics of the different portions of a network to a user interface (Abstract, lines 11-18, the data structure stores the information (characteristics ) about the network including the different variables then, the user interface can receive and display these characteristics of network virtually, [0135], lines 1-5, [0016], Figs. 6-7 show how the user interface display the available variables to the user); receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network (As described in Abstract “A user-interface is configured to receive queries from a user that request verification of network policies and predictions of network behavior. The user-interface is configured to display responses to the queries that are obtained using the data structure”, which implies the user interface can receive these queries and then display the results (responses) of these queries to the user, [0050], lines 1-6, describes the flexible query format to support constraints on traffic types, paths, and network objects which allows the users to determine specific detailed constraints to limit the recommendation or analysis [0051], lines 7-12, “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query” [0149], lines 1-3, [0016], Fig. 6 show how the user can input constraints via user interface), and configure the predictive networking engine based on the set of one or more constraints ([0050] states “the network verification system may provide a flexible format to specify a query that requests retrieval of predicted network behavior subject to user-specified constraints. These constraints may describe the type of data flow traffic of interest, as well as the kind of paths through the network “and [0125] describes including of a graphical interface to allow users to interactively select a policy template, enter parameters, and request to define the behavior/policies to be verified., as stated in [0123] lines 10-12. That implies the configuration of the predictive networking engine based on the constraints), the predictive networking engine being configured to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0149] states “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query. For example, if a diff query determines that an earlier snapshot better meets an intent parameter for particular devices or a particular region of the network, the system can recommend that the configuration for those devices or that particular region be returned to their configurations as in the earlier snapshot.” And [0150] describes if the pre-deployment verification indicates that all intents are satisfied, the system may automatically make the changes and notify the user. These parts implies the system uses query results to recommend changes to the network), refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0147] states “the system (1) receives modified configurations from a user, (2) builds the pre-deployment snapshot as discussed above, (3) verifies a predefined set of intents within the pre-deployment snapshot; then, (4) if all intents are satisfied, the configuration change can be automatically deployed to each physical device in the network in order to modify its behavior, or (5) if not all intents are satisfied, results or alerts are pushed to the user but the configuration change is not deployed.” And Claim 18 states “upon verifying that the modifications comply with the network policies, sending the modifications to the network devices for adoption by the network devices.” That implies the system automated deployment prevention.[0072] using the pre-deployment verification to avoid the implementation of changes that fails to meet the constraints), or refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur to incorporate the teachings of Khurshid (in analogous art) by adding receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network to focus on specific analysis because intermediate steps between source and destination have been eliminated (Khurshid, [0128], lines 4-9).
Regarding 12 (Original), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur further teaches wherein the plurality of characteristics is indicative of usage of the different portions of the network ([0035], lines 6-9, [0083], lines 1-7, the set of characteristics (telemetry data) is indicative of the usage of different potions of the network from the devices includes which collected from the devices, [0053], lines 5-10).
Regarding claim 13 (Original), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur fails to teach wherein the plurality of characteristics comprises at least one of: a number of users for a particular portion of the network or link utilization in the particular portion of the network.
However, Khurshid teaches wherein the plurality of characteristics comprises at least one of: link utilization in the particular portion of the network ([0135],-[0140], the Graphical user interface GUI may display a map of the network showing overlays with annotations , coloring and labeling interconnections (links) between devices, where the overlay includes [0138] interface utilization metrics, [0139], interface packet errors, and [0140] interface packet drops. [0141], [0143] describe the GUI may show increasing amount of detailed information as the user zooms into certain portion of the network) or a number of users for a particular portion of the network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur to incorporate the teachings of Khurshid (in analogous art) by adding receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network to focus on specific analysis because intermediate steps between source and destination have been eliminated (Khurshid, [0128], lines 4-9).
Regarding claim 15 (Currently Amended), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur fails to teach wherein the processor is configured to identify the plurality of characteristics of the different portions of the network by receiving data from a network controller for the network.
However, Khurshid teaches wherein the processor is configured to identify the plurality of characteristics of the different portions of the network by receiving data from a network controller for the network (Figs. 2 and 8 and [0027] describes the system provides an interface and a search query processor 211 to query the network model to obtain objects and data flow behavior, and where a plurality of network device interfaces are configured to collect state information for a plurality of network devices, as stated in Abstract. [0006], [0024], and claim 16 which states “the network devices are virtual network devices and the state information of the virtual network devices is collected from a controller of a software-defined network.” That’s imply the system obtain rule modifications (set of characteristics) from the controller and send the rule modifications for execution by network devices different portions of network. [0151] provides details about the computer system that includes a processor as a part of the interface.).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur to incorporate the teachings of Khurshid (in analogous art) by adding receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network to focus on specific analysis because intermediate steps between source and destination have been eliminated (Khurshid, [0128], lines 4-9).
Regarding claim 16 (Original), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur further teaches wherein the plurality of characteristics of the different portions of the network are indicative of at least one of: wide area network (WAN) circuit information ([0002]-[0004], [0014], and [0028] states “ a software-defined WAN (SD-WAN) may be used in network 100 to connect local network 160, local network 162, and data center/cloud 150. In general, an SD-WAN uses a software defined networking (SDN)-based approach to instantiate tunnels on top of the physical network and control routing decisions, accordingly”), an Internet breakout type ( [0021]-[0022], describe two types of connections to the network “Site Type B2: a site connected to the network using one MPLS VPN link and one link connected to the public Internet, with potentially a backup link (e.g., a 3G/4G/5G/LTE connection) “ and “Site Type B3: a site connected to the network using two links connected to the public Internet, with potentially a backup link (e.g., a 3G/4G/5G/LTE connection).” [0003], lines 8-12, these backup links are essential for maintaining network reliability, ensuring SLA compliance and prevent the effect of potential failures or false predictions) or redundancy strategy information.
Regarding claim 18 (Currently Amended), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur further teaches wherein the processor is configured to configure the predictive networking engine to provide a recommendation to reroute traffic for a particular application from one path in the network to another ([0034] states “as detailed further below, predictive routing process 248 may also include computer executable instructions that, when executed by processor(s) 220, cause device 200 to predict failures of network elements in the network (e.g., a link or node/device), thereby allowing device 200 to proactively reroute traffic to avoid the failed element. “ and Abstract, [0067], [0096], lines 4-8, “device predicts a failure of a first tunnel in a software-defined wide area network (SD-WAN). The device makes a prediction as to whether a second tunnel in the SD-WAN will satisfy a service level agreement (SLA) associated with traffic on the first tunnel. The device proactively reroutes the traffic from the first tunnel onto the second tunnel, based on the prediction as to whether that the second tunnel will satisfy the SLA of the traffic.” which confirm the process of predictive routing can involve failure prediction, SLA assessment, and proactive rerouting between tew different parts of the system).
Regarding claim 19 (Original), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur further teaches wherein the plurality of characteristics of the different portions of the network are indicative of different applications whose traffic is conveyed via the different portions of the network ([0085], lines 4-7, the traffic rout through the tunnel is captured and analyzed to detect the nature (e.g., application ID) of traffic 602, along with its volume, which indicates the network can identify specific application by the traffic features. [0083], lines 1-7 describe the impotent information such as type of the transport, ISP, geographical locations, and bandwidth with the ISP can be used to define the requirements of different applications and their impact on tunnel use. [0076], describe how different applications with distinct traffic features can effect on the network behavior).
Regarding claim 20 (Currently Amended), Vasseur teaches a tangible, non-transitory, computer-readable medium storing program instructions that cause a device to execute a process comprising (Claim 15, states “A tangible, non-transitory, computer-readable medium storing program instructions that cause a device in a software-defined wide area network (SD-WAN) to execute a process comprising” ): identifying, by the device, a plurality of characteristics of different portions of a network for which a predictive networking engine is available ( Fig. 3, [0043]-[0046], Table 1, theses sections describe how the telemetry collection module gathering the telemetry data along with the set of candidate telemetry variables (set of characteristics /variables requested as shown in Table 1) from network devices, which are required for model training by MLFF module (can be used by machine learning module as a predictive network engine [0083], lines 14-17));
Vasseur fails to teach providing, by the device, information indicative of the plurality of characteristics of the different portions of a network to a user interface; receiving, at the device and via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network, and configuring, by the device, the predictive networking engine based on the set of one or more constraints, the configuring including configuring the predictive networking engine to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints, or refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints.
However, Khurshid teaches providing, by the device, the plurality of characteristics of the different portions of a network to a user interface (Abstract, lines 11-18, the data structure stores the information (characteristics ) about the network including the different variables then, the user interface can receive and display these characteristics of network virtually, [0135], lines 1-5, [0016], Figs. 6-7 show how the user interface display the available variables to the user); ; receiving, at the device and via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network (As described in Abstract “A user-interface is configured to receive queries from a user that request verification of network policies and predictions of network behavior. The user-interface is configured to display responses to the queries that are obtained using the data structure”, which implies the user interface can receive these queries and then display the results (responses) of these queries to the user, [0050], lines 1-6, describes the flexible query format to support constraints on traffic types, paths, and network objects which allows the users to determine specific detailed constraints to limit the recommendation or analysis [0051], lines 7-12, “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query” [0149], lines 1-3, [0016], Fig. 6 show how the user can input constraints via user interface), and configuring, by the device, the predictive networking engine based on the set of one or more constraints ([0050] states “the network verification system may provide a flexible format to specify a query that requests retrieval of predicted network behavior subject to user-specified constraints. These constraints may describe the type of data flow traffic of interest, as well as the kind of paths through the network “and [0125] describes including of a graphical interface to allow users to interactively select a policy template, enter parameters, and request to define the behavior/policies to be verified., as stated in [0123] lines 10-12. That implies the configuration of the predictive networking engine based on the constraints), the configuring including configuring the predictive networking engine to at least one of filter out recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0149] states “The system may use results of user initiated queries to recommend changes to the network. These recommendations may be specific to results of a particular query. For example, if a diff query determines that an earlier snapshot better meets an intent parameter for particular devices or a particular region of the network, the system can recommend that the configuration for those devices or that particular region be returned to their configurations as in the earlier snapshot.” And [0150] describes if the pre-deployment verification indicates that all intents are satisfied, the system may automatically make the changes and notify the user. These parts implies the system uses query results to recommend changes to the network), refrain from automatically implementing recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints ([0147] states “the system (1) receives modified configurations from a user, (2) builds the pre-deployment snapshot as discussed above, (3) verifies a predefined set of intents within the pre-deployment snapshot; then, (4) if all intents are satisfied, the configuration change can be automatically deployed to each physical device in the network in order to modify its behavior, or (5) if not all intents are satisfied, results or alerts are pushed to the user but the configuration change is not deployed.” And Claim 18 states “upon verifying that the modifications comply with the network policies, sending the modifications to the network devices for adoption by the network devices.” That implies the system automated deployment prevention.[0072] using the pre-deployment verification to avoid the implementation of changes that fails to meet the constraints), or refrain from generating recommendations for portions of the network having one or more characteristics that satisfy the one or more constraints.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur to incorporate the teachings of Khurshid (in analogous art) by adding receive, via the user interface, a set of one or more constraints to limit recommendations by the predictive networking engine for a selected portion of the network from among the different portions of the network to focus on specific analysis because intermediate steps between source and destination have been eliminated (Khurshid, [0128], lines 4-9).
Claims 4, 7, 14, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur et al. (US-20200382414-A1) in view of Khurshid et al. (US-20220094614-A1) and further in view of Mermoud et al. (US-20180278486-A1).
As to claims 4 and 7 see similar rejections to claims 14 and 17, respectively. The apparatus teaches the methods.
Regarding claim 14 (Original), Vasseur and Khurshid teach apparatus as in claim 11.
Vasseur and Khurshid do not explicitly teach wherein the plurality of characteristics for the selected portion of the network comprises a metric indicative of a number of critical incidents reported by users in the selected portion of the network.
However, Mermoud teaches wherein the plurality of characteristics for the selected portion of the network comprises a metric indicative of a number of critical incidents reported by users in the selected portion of the network ([0057], lines 5-8 and [0064] describe the feedback from the users about the quality of service can be considered by the system to improve it. [0071], states “ the user may of user interface 402 may provide feedback to rule evaluation engine 404 about the rule itself, ranging from binary feedback (e.g., like/dislike, relevant/not relevant, etc.) to more complex and structured feedback (e.g., natural language, edit proposals, etc.)” which can be used for retrain the predictive network engine. [0074], describes some examples about the feedback from the user on rule evaluations, such as QoS metric for at least a portion of the network. [0066], “Example objective QoS metrics may include, but are not limited to, throughput, delay, jitter, user ratings in specific applications, combinations thereof, or the like. In general, the QoS metrics may differ from the actual network conditions evaluated by the rule(s) of rule-based engine 406.”,[0048], observed network conditions and user rating).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur in view of Khurshid to incorporate the teachings of Mermoud (in analogous art) by adding the plurality of characteristics for the selected portion of the network comprises a metric indicative of a number of critical incidents reported by users in the selected portion of the network to adjust and refine the machine learning-based classifier-based on feedback associated with generated predictions (Mermoud, [0057], lines 8-10).
Regarding claim 17 (Original), Vasseur and Khurshid teach the apparatus as in claim 11.
Vasseur and Khurshid do not explicitly teach wherein the plurality of characteristics of the different portions of the network are indicative of whether a particular portion of the network is a hub, a branch, a data center, a cloud, or a factory.
However, Mermoud teaches wherein the plurality of characteristics of the different portions of the network are indicative of whether a particular portion of the network is a hub, a branch, a data center, a cloud, or a factory (Fig. 1B, [0021] illustrate the data center( cloud), and different local network (branches), these portions are connected via a network backbone and be located in different geographic locations, [0022], lines 7-9, “network 100 may include any number of local networks, data centers, cloud environments, devices/nodes, servers, etc.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Vasseur in view of Khurshid to incorporate the teachings of Mermoud (in analogous art) by adding the plurality of characteristics for the selected portion of the network comprises a metric indicative of a number of critical incidents reported by users in the selected portion of the network to adjust and refine the machine learning-based classifier-based on feedback associated with generated predictions (Mermoud, [0057], lines 8-10).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
Veres et al. (US-20210328884-A1), Vasseur et al. (US-20150195149-A1), Nucciet al. (US-20210226863-A1), Pant et al. (US-20200136949-A1), Wakim et al. (US-20210400501-A1) teach methods using predictive networking engine (ML) to enhance the efficiency and reliability of the system in wireless communication.
Conclusion
THIS ACTION IS MADE FINAL. 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 SANAA S AL SAMAHI whose telephone number is (571)272-4171. The examiner can normally be reached M-F 8-5 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, Asad Nawaz can be reached at (571) 272-3988. 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.
/SANAA S AL SAMAHI/Examiner, Art Unit 2463 /ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463