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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 20 March 2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-20 recite “augmenting”/”augment” “a predictive network system previously deployed to a network that previously used a prediction model that predicts performance of a network path to enact routing policies, to use the quality of experience model to enact routing policies for routing traffic of the online application instead of using the prediction model”. However, it is unclear how the “predictive network system” is “augmented” when it is expressly claimed that the system “previously used a prediction model that predicts performance of a network path to enact routing policies” to “use” “the quality of experience model to enact routing policies for routing traffic of the online application instead of using the prediction model”.
Claim 5 similarly recites “augmenting” “the predictive network system to use the first quality of experience model when there are no traffic flows in the network with the online application and the second quality of experience model when there are traffic flows in the network with the online application” to which is the same is applied. It is unclear what is meant by “augmenting” the “predictive network system” to “use” a “first” and “second” “quality of experience model” when there are “no traffic flows” or “are traffic flows” “in the network with the online application”.
Claim 6 recites “using, by the device, Layer 7 telemetry from the online application to augment how the predictive network system estimates user activity with respect to the online application”. Given that claim 1 antecedent to claim 6, it is also unclear what is “augmented” in the “predictive network system” that “uses” the “Layer 7 telemetry”.
Claim 15 recites “augment the predictive network system to switch between using the first quality of experience model and the second quality of experience model, depending on whether there are traffic flows in the network with the online application”. Again, it is unclear what is meant by “augment” the “predictive network system” “to switch between using the first quality of experience model and the second quality of experience model”.
Therefore, it is generally unclear how the term “augmenting” is being used in conjunction with the claimed invention and appears to be relative in nature. The use of the term causes a number of clarity issues such that the scope of the invention is not readily apparent. Examiner will apply prior art as best understood.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4, 6-7, 10-17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20210314238 to Cioffi et al. (“Cioffi”).
Regarding claim 1, Cioffi taught a method comprising:
training, by a device, a quality of experience model to predict a quality of experience metric for an online application based on any one of (i) Layer 3 metrics, (ii) Layer 7 metrics, or (iii) both (i) and (ii) (consider paragraphs 0082-0091 regarding the “OSI stack and its seven layers”, specifically paragraph 0091, “This document refers to the 7 layers or levels to indicate at which level is the QoS or QoE data collected and to which layer is the improved parameter(s) tuned. A profile may contain values for several layers”); (consider paragraph 0041, specifically “Estimation determines a function of input data that produces outputs based on those inputs. The estimating function or estimator may be parametrized, and estimation often includes learning or otherwise computing and/or inferring the parameter values from QoE data or from other knowledge about the function's desired behavior. For example, an estimator may learn from a set of QoS data, plus user feedback information, and labelled QoE from earlier or training uses, and generate a function that will predict the current QoE measure. This estimated QoE parameters are often learned by correlating a user's QoE training or other data indicative of QoE within application-specific activities to the network performance measured by QoS data.”) (consider further paragraph 0042, “Prediction is the application of a trained or otherwise derived model to input data to generate outputs based on the inputs. A trained model can predict QoE, ASC or other productivity-related metrics for specific applications based on a variety of different inputs. For example, a machine-learning model may be trained using correlated QoE, productivity metrics such as diminished work throughput, or other information related to the desired output of the model”) (consider further paragraph 0078, specifically “FIG. 3B illustrates a generalized QoE estimation that trains on normalized and aggregated user QoE feedback data according to various embodiments of the invention. The QoE estimator 350 results provide indications, or sometimes just a single number, that can be used to gauge network performance, employee-user performance, and WFH success. The QoE estimator 350 may be located within the WFH metric apparatus 288 of the server 270, In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360… Performance data 380 may include QoS data from various OSI layers”)
augmenting, by the device, a predictive network system previously deployed to a network that previously used a prediction model that predicts performance of a network path to enact routing policies, to use the quality of experience model to enact routing policies for routing traffic of the online application instead of using the prediction model; (consider paragraph 0041, specifically “This estimated data may be used to train a second machine-learning model that attempts to optimize or improve the values of the parameters and their consequent function output's predicted QoE by adapting various user profile parameters.”) (consider further paragraph 0058, specifically “The server 270 collects quality of service (QoS) operational/performance, user QoE feedback, and user preference data at any or all of the three networks. The server 270 determines a preferred policy (sometimes referred to as a profile as well) and/or policies to provide to at least one (or more) network component and/or devices. This preferred policy and associated improvement will impact the currently active WFH service application's QoE or ASC metric.”) (consider further paragraph 0078, specifically “FIG. 3B illustrates a generalized QoE estimation that trains on normalized and aggregated user QoE feedback data according to various embodiments of the invention. The QoE estimator 350 results provide indications, or sometimes just a single number, that can be used to gauge network performance, employee-user performance, and WFH success. The QoE estimator 350 may be located within the WFH metric apparatus 288 of the server 270, In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360.”) (consider further paragraph 0080, “The training illustrated in FIG. 3B occurs when actual user QoE feedback 360 (such as “labelled data”) is present. The learned functional relationships are then available for subsequent QoE estimation use when that user QoE feedback is no longer present. In certain examples, these QoE estimates then depend on the QoS operational/performance data and possibly any user-preference data 370. Training may update each time additional direct user QoE feedback data 360 is present; the consequent updated QoE-from-QoS functional-estimate relations then continue again when the direct user QoE feedback data ceases to be available. The QoS and QoE data inputs to learned combinations may come from any, combinations of, or all of the sources identified within FIG. 3B.”) (consider further paragraphs 0242-0245, specifically “The server's policy and profile improvement then prioritize profiles for the corresponding WFH application and device. The policy also may specify how to detect and associate the WFH device and application with the preferred service category. The profile further allows prioritization to be implemented within different home network subsystems. For example: …LAN profile can assign WFH applications and devices to the best QoS paths/links; this may include improving Wi-Fi spatial streams and associated beamforming to better serve the WFH device. WFH applications' data may be input to higher priority queues.”) (consider further paragraph 0284, specifically “To prioritize certain WFH (or other mission-critical) applications or lines, the server 270 may re-profiles the shared-lines' uplink queues dynamically. For example, optimized or improved WFH profiles can reconfigure DOCSIS 3.1 cable modems' to different links to prioritize different service/lines through DOCSIS-3.1-supported AQM, which provides at least the following tunable parameters: enable/disable AQM per service flow, per-flow latency targets, and per-flow buffer sizes. Consider when WFH line/service flow's QoE is low, AQM can then shorten a non-WFH service flow's target latency to initiate more aggressive non-WFH packet dropping. Simultaneously, AQM actions can initiate TCP flow control to reduce TCP flow rate for the affected flow. Alternatively, if similar prioritization occurs instead in the uplink scheduler, TCP flow control will not be triggered until a buffer overflows, so the uplink latency for the de-prioritized user will continue to increase. Therefore, the WFH's AQM optimization/improvement likely maintains better QoE for all connections, even those deprioritized. In general, uplink prioritization can be better managed by jointly optimizing/improving all links”)
obtaining, by the device, policy information indicative of whether the predictive network system enacted one or more routing policies in the network based on a prediction by the quality of experience model; and ensuring, by the device and based on the policy information, that the predictive network system that was augmented to use the quality of experience model enacted a routing policy that accurately matches traffic for the online application. (consider paragraph 0059, specifically “The in-home network's gateway 283 connects LAN devices 284. These LAN devices 284 thereby connect through the Internet 282 to application servers via the ISPs' WAN backhaul(s) and the core ISP network. A gateway 283 can prioritize applications/devices through priority queues that allow fail-over service by switching to an alternative ISP (e.g., switching from wireline to cellular) when the primary ISP's connection has insufficient positive ASC metric effect. The server 270 may interface to a gateway-located agent, described in detail below, to collect QoS operational/performance data and correspondingly to re-profile (i.e., improve) based on the WFH policy.”) (consider paragraph 0149, specifically “User QoE feedback data help to train; i.e., learn by a ML or AI based method, the proper relationships between the QoS data and the QoE data, so that QoS data can be used in the future to estimate QoE data accurately, when such user QoE-feedback data are not available. Actual user QoE feedback data or QoE estimates from QoS data may assist dynamic improvement methods in supervised or reinforced modes.”) (consider further paragraph 0242, specifically “In certain embodiments, home gateways may prioritize certain applications or devices based on a WFH situation. For example, a WFH user might mandate a WFH tool or application in the associated preferred service category to be prioritized. The server's policy and profile improvement then prioritize profiles for the corresponding WFH application and device. The policy also may specify how to detect and associate the WFH device and application with the preferred service category.”) (consider further paragraph 0251, specifically “FIG. 7 illustrates flow identification possibilities within a home gateway. In this Figure, device types 710, media ports 720 and DSCP/WMMMs 730 are configured to support specific flows across a variety of WFH applications 740. One skilled in the art will recognize that there are numerous combinations that can be implemented to support different flows and network performance and associated metrics.”) (consider further paragraph 0257, “WAN interface optimization or improvement can also prioritize a data flow to optimize or improve network performance and associated metrics. Referring to the example in FIG. 5, home gateway may connect to 2 WANs, such as DSL as the main broadband service and a metered LTE as a back-up. When the main broadband service's performance degrades, fail-over can redirect high-priority device's/applications' packets through the back-up LTE link. These packets can also pass through both WANs 510, 515 to increase prioritized application's overall data rate. The consequent multi-path transmission may dynamically use one or more estimated ASC metrics through the server's direct reprofiling, or through policy specification that enables immediate profile change upon the WAN's router's contention sensing. This multi-path control prioritizes the routing within a 2-WAN mesh network. If the WAN additionally supports multiple network slices and the poor QoE or ASC metric results from the current network-slice choice, then the high-priority devices'/applications' packets may switch to another higher-priority slice as a function of the measured WFH QoE or ASC metric.”)
Regarding claim 2, Cioffi taught the method as in claim 1, wherein the device trains the quality of experience model using feedback from users of the online application. (again, consider paragraph 0041, specifically “Estimation determines a function of input data that produces outputs based on those inputs. The estimating function or estimator may be parametrized, and estimation often includes learning or otherwise computing and/or inferring the parameter values from QoE data or from other knowledge about the function's desired behavior. For example, an estimator may learn from a set of QoS data, plus user feedback information, and labelled QoE from earlier or training uses, and generate a function that will predict the current QoE measure. This estimated QoE parameters are often learned by correlating a user's QoE training or other data indicative of QoE within application-specific activities to the network performance measured by QoS data.”) (again, consider further paragraph 0078, specifically “FIG. 3B illustrates a generalized QoE estimation that trains on normalized and aggregated user QoE feedback data according to various embodiments of the invention. The QoE estimator 350 results provide indications, or sometimes just a single number, that can be used to gauge network performance, employee-user performance, and WFH success. The QoE estimator 350 may be located within the WFH metric apparatus 288 of the server 270, In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360.”) (again, consider paragraph 0149, specifically “User QoE feedback data help to train; i.e., learn by a ML or AI based method, the proper relationships between the QoS data and the QoE data, so that QoS data can be used in the future to estimate QoE data accurately, when such user QoE-feedback data are not available. Actual user QoE feedback data or QoE estimates from QoS data may assist dynamic improvement methods in supervised or reinforced modes.”)
Regarding claim 3, Cioffi taught the method as in claim 1, wherein the quality of experience model takes as input Layer 3 (consider paragraph 0086) telemetry obtained from the network. (consider paragraph 0074, specifically “The diagnostic engine 310 receives a plurality of OSI (Open Systems Interconnection) Layer 1 QoS parameters 320 that will change as network demand, capacity, bandwidth, data rate, application, etc. vary over time. In addition, OSI Layer 2 and above QoS parameters are also inputted into the diagnostics engine 310.”) (consider also paragraph 0078, specifically “In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360. The operational data 375 may include informational data such as an application type, a device type, etc., transaction data, and other data such as port usage, queue length, etc. Performance data 380 may include QoS data from various OSI layers.”) (consider also paragraph 0224 regarding how “[t]he improvement may occur at many layers of the OSI stack” such that “Improved profiles may specify control parameters at any, a combination of, or all layers”)
Regarding claim 4, Cioffi taught the method as in claim 3, wherein the quality of experience model takes as input Layer 7 (consider paragraph 0090) telemetry obtained from the online application. (consider paragraph 0074, specifically “The diagnostic engine 310 receives a plurality of OSI (Open Systems Interconnection) Layer 1 QoS parameters 320 that will change as network demand, capacity, bandwidth, data rate, application, etc. vary over time. In addition, OSI Layer 2 and above QoS parameters are also inputted into the diagnostics engine 310.”) (consider also paragraph 0078, specifically “In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360. The operational data 375 may include informational data such as an application type, a device type, etc., transaction data, and other data such as port usage, queue length, etc. Performance data 380 may include QoS data from various OSI layers.”) (consider also paragraph 0024 regarding how “[t]he improvement may occur at many layers of the OSI stack” such that “Improved profiles may specify control parameters at any, a combination of, or all layers”)
Regarding claim 6, Cioffi taught the method as in claim 1, further comprising: using, by the device, Layer 7 telemetry from the online application to augment how the predictive network system estimates user activity with respect to the online application. (consider paragraph 0038, specifically “User feedback comprises information about the performance and/or usability of users' activities (e.g., video-conferencing). User feedback may be directly provided by the user or may be indirectly determined based on user action or other information related to the application specific activities. Examples of indirect user feedback for WFH video-conferencing activities include measures of churn (e.g., either switching the user's ISP or switching the video-conferencing software provider), refusals to use a particular video-conferencing software, counts and characterization of the nature of calls and/or emails to help desks, excessive repeats of collaborative sessions, etc. In certain instances, user feedback may be a component in determining Quality of Experience (QoE)”) (consider also paragraph 0078, specifically “In various embodiments, the QoE estimator 350 receives a set of user preference inputs 370, operational data 375, performance data (QoS) 380 and direct user feedback 360. The operational data 375 may include informational data such as an application type, a device type, etc., transaction data, and other data such as port usage, queue length, etc. Performance data 380 may include QoS data from various OSI layers.”) (consider further paragraphs 0124-0128 and 0145 regarding ”application-specific QoS data” such that “The application's QoS performance data then constitutes the feedback information from the application-service delivery to the application server, and presumably then also to the server 270”) (consider also paragraph 0224 regarding how “[t]he improvement may occur at many layers of the OSI stack” such that “Improved profiles may specify control parameters at any, a combination of, or all layers”)
Regarding claim 7, Cioffi taught the method as in claim 1, further comprising: causing, by the device, the predictive network system to detect congestion in the network using the quality of experience model. (consider paragraph 0040, specifically “QoS data may include packet loss count, signal levels, noise levels, outages, margin levels, data rates, throughputs, latency (delay), and all other forms of both current and historical operational and performance data. QoS performance data relate to the performance of a communications link (e.g., throughput, jitter, packet loss, etc.), while QoS operational data relate to the operation of the communications link (e.g., queue length, target data rate, port usage, etc.). Both operational data and performance data can affect QoS.”) (consider further paragraph 0079, specifically “However when present, this direct QoE feedback 360 can help machine learning methods to learn how QoE may be estimated from continuously available QoS data like packet losses, signal levels, noise levels, outages, margin levels, data rates, throughputs, latency (delay), and all other forms of both current and historical operational/performance data.”) (consider further paragraph 0104 and 0120-0123 regarding “throughput” and “transmission delay”)
Regarding claim 10, Cioffi taught the method as in claim 1, wherein ensuring that the predictive network system enacted a routing policy that accurately matches traffic for the online application comprises: splitting an existing routing policy or enacting a new routing policy. (again, consider paragraph 0059, specifically “The in-home network's gateway 283 connects LAN devices 284. These LAN devices 284 thereby connect through the Internet 282 to application servers via the ISPs' WAN backhaul(s) and the core ISP network. A gateway 283 can prioritize applications/devices through priority queues that allow fail-over service by switching to an alternative ISP (e.g., switching from wireline to cellular) when the primary ISP's connection has insufficient positive ASC metric effect. The server 270 may interface to a gateway-located agent, described in detail below, to collect QoS operational/performance data and correspondingly to re-profile (i.e., improve) based on the WFH policy.”) (consider further paragraph 0251, specifically “FIG. 7 illustrates flow identification possibilities within a home gateway. In this Figure, device types 710, media ports 720 and DSCP/WMMMs 730 are configured to support specific flows across a variety of WFH applications 740. One skilled in the art will recognize that there are numerous combinations that can be implemented to support different flows and network performance and associated metrics.”) (consider further paragraph 0257, “WAN interface optimization or improvement can also prioritize a data flow to optimize or improve network performance and associated metrics. Referring to the example in FIG. 5, home gateway may connect to 2 WANs, such as DSL as the main broadband service and a metered LTE as a back-up. When the main broadband service's performance degrades, fail-over can redirect high-priority device's/applications' packets through the back-up LTE link. These packets can also pass through both WANs 510, 515 to increase prioritized application's overall data rate. The consequent multi-path transmission may dynamically use one or more estimated ASC metrics through the server's direct reprofiling, or through policy specification that enables immediate profile change upon the WAN's router's contention sensing.”)
Claims 11 and 20 recite an apparatus and tangible non-transitory computer-readable medium that contain substantially the same limitations as recited in claim 1 and are also rejected under 35 USC § 102(a)(1) as being anticipated by the same teachings of Cioffi.
Claims 12-17 recite an apparatus that contain substantially the same limitations as recited in claims 2-7 respectively and are also rejected under 35 USC § 102(a)(1) as being anticipated by the same teachings of Cioffi.
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.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Cioffi in view of US 2021040998 A1 to Kwok et al. (“Kwok”).
Regarding claim 18, Cioffi taught the apparatus as in claim 17.
Cioffi may be interpreted as not expressly teaching the apparatus further comprising causing, by the device, the predictive network system to reroute non-critical traffic onto a different path in the network from a path that conveys traffic associated with the online application, when there is detected congestion along the path that conveys traffic associated with the online application, however, Cioffi did teach detecting along the path that conveys traffic associated with the online application. (again, consider paragraph 0040, specifically “QoS data may include packet loss count, signal levels, noise levels, outages, margin levels, data rates, throughputs, latency (delay), and all other forms of both current and historical operational and performance data. QoS performance data relate to the performance of a communications link (e.g., throughput, jitter, packet loss, etc.), while QoS operational data relate to the operation of the communications link (e.g., queue length, target data rate, port usage, etc.). Both operational data and performance data can affect QoS.”) (again, consider further paragraph 0079, specifically “However when present, this direct QoE feedback 360 can help machine learning methods to learn how QoE may be estimated from continuously available QoS data like packet losses, signal levels, noise levels, outages, margin levels, data rates, throughputs, latency (delay), and all other forms of both current and historical operational/performance data.”) (again, consider further paragraph 0104 and 0120-0123 regarding “throughput” and “transmission delay”)
In an analogous art relating to packet traffic congestion mitigation in consideration of critical and non-critical application packet traffic (consider paragraph 0017), Kwok taught rerouting non-critical traffic onto a different path in a network from a path that conveys traffic associated with an online application, when there is detected congestion along the path that conveys traffic associated with the online application. (consider paragraph 0017, specifically “However, many previous conventional dual connectivity routing solutions route data packets without considering the QoE provided to users with respect to different types of data packets. For example, static routing algorithms used in many previous solutions may treat data packets for delay-sensitive real-time gaming applications and for delay-tolerant web browsing sessions equally, and route both types of data packets through an LTE eNB by default unless the eNB's buffer is overflowing. However, in such situations, the user's QoE might have been improved if the delay-sensitive real-time gaming data packets had instead been routed over a 5G connection that has a lower latency than the default LTE connection.”) (consider further paragraph 0032, specifically “In some examples, packet characteristics 202 can include Quality of Service (QoS) Class Indicator (QCI) value associated with the data packet. For example, the QCI value may indicate a priority level associated with the data packet, whether the data packet is targeted for transmission at a guaranteed bit rate (GBR) or at a non-GBR, a packet delay budget associated with the data packet, and/or a packet error loss rate associated with the data packet. In some examples, QCI values 1 through 4 can be associated with GBR traffic, with QCI value 1 signifying conversational voice traffic, QoS value 2 signifying conversational video (live streaming) traffic, QoS value 3 signifying traffic such as real-time gaming traffic, and QoS value 4 signifying non-conversational video (buffered streaming). Additionally, in some examples, QCI values 5 through 9 can be associated with non-GBR best-effort traffic, with QCI value 5 signifying IP Multimedia Subsystem (IMS) signaling, QCI values 6, 8, and 9 signifying buffered streaming video and TCP-based file transfers, and QCI value 7 signifying non-GBR voice, live streaming video, and interactive gaming.”) (consider further paragraph 0048, specifically “The flow controller 114 may use one or more types of packet characteristic 202 to determine a corresponding QoE goal 204 and/or a routing scheme 206. For instance, in some examples the flow controller 114 may use QCI values to differentiate GBR and non-GBR data packets, and be configured to route GBR data packets over the 5G connection 112 and non-GBR data packets over the LTE connection 110.”) (consider further paragraph 0077, specifically “For example, the UE telemetry 610 can include such as measurement reports provided by the UE 102 of current radio conditions, measured signal strengths, measured latency values, measured throughput values, and/or other telemetry data. In other examples, the UE telemetry 610 can include measurements of latency, throughput, bandwidth, congestion levels, and/or other data associated with the LTE connection 110 and/or the 5G connection 112 measured by the network element 600 or provided by other network elements.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, the Examiner finds that, based on the references’ analogous disclosure regarding application packet traffic congestion mitigation, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Claim(s) 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cioffi in view of US 20210083948 A1 to Paruchuri et al. (“Paruchuri”).
Regarding claim 9, Cioffi taught the method as in claim 1.
Cioffi may be interpreted as not expressly teaching wherein the prediction model predicts service level agreement (SLA) violations by the network path.
However, in an analogous art relating to SLAs in conjunction with determining quality of experience (QoE) metrics, Paruchuri taught that a prediction model used to predict network path performance may be used to predict service level agreement (SLA) violations by a network path. (consider paragraph 0005, specifically “In some SD-WANs, the SD-WAN routing appliance may specify a path for data flows between client devices and application servers. These paths are typically selected using service-level agreement (SLA) parameters and various metrics of the WAN links. While the SLA parameters may be more static in nature, or at least predetermined prior to the SD-WAN appliance receiving the flow, the metrics of the various WAN links may be more dynamic, as the metrics describing the capabilities of the particular WAN link may vary based on various current aspects of the network.”) (consider paragraph 0033, specifically “In the example network architecture illustrated in FIG. 1, SD-WAN appliance 18 is configured to perform the QoE metric predictions. SD-WAN appliance 18 allows for load sharing across connections and adjusts traffic flows based on network conditions to improve performance.”) (consider further paragraph 0035, specifically “SD-WAN appliance 18, which performs the path selection algorithms, also determine QoE metrics, such as service level agreement (SLA) metrics that include round-trip time (RTT), jitter, and packet loss, which were influenced by applications' real-time parameters like packet size, queues and burst of packets to determine the best path.”) (consider further paragraph 0066, “Sometime after initiating the probing process for the data flow, other traffic may be received or some other incident may occur causing the one or more QoE metrics for the first link to fail to satisfy service level agreement (SLA) metrics for the application. Once traffic engine 110 determines this to be the case, traffic engine 110 may send one or more probe packets over a second link of the plurality of links to determine one or more QoE metrics for the second link. Traffic engine 110 may send the one or more probe packets over the links one-by-one until a satisfactory link is found, or may, approximately simultaneously, send each of the one or more probe packets over each of the plurality of links that reach the intended destination to determine the QoE metrics for each link at the same time.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, the Examiner finds that, based on the references’ analogous disclosure regarding prediction of network path performance, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Claim 19 recites an apparatus that contains substantially the same limitations as recited in claim 9 and is also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Cioffi and Paruchuri and the same rationale supporting the conclusion of obviousness.
Allowable Subject Matter
Claims 5 and 8 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.
This indication of allowable subject matter is contingent upon the anticipated resolution of the remaining issues detailed in this action.
In the event that any amendment made to the claims changes the scope of the indicated allowable subject matter, further reconsideration of whether the claims continue to distinguish from the prior art and/or are subject to further rejection under applicable statutes may be deemed necessary.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR § 1.111(b) and MPEP § 707.07(a).
Response to Arguments
Applicant’s arguments with regards to amended claims 5 and 8 have been considered and are persuasive, therefore, the 102 rejection under Cioffi and the 103 rejection under Cioffi and Kwok respectively have been withdrawn.
Examiner notes that claim 18 remains previously presented and continues to be rejected for the reasons found below. If Applicant intends to make claim 18 commensurate in scope with claim 8, then it also must be amended in kind.
Applicant’s arguments with regards to the other argued claims have been fully considered and are found unpersuasive.
Applicant argues that “Cioffi does not disclose training a QoE model based on Layer 3 metrics, Layer 7 metrics, or both. While Cioffi references OSI layers in paragraph 0074 and discusses ‘OSI Layer 1 QoS parameters 320" and "OSI Layer 2 and above QoS parameters,’ this disclosure relates to inputting various QoS parameters into a diagnostic engine, not training a QoE prediction model based on specifically Layer 3 and/or Layer 7 metrics”.
However, as the updated rejection shows, Cioffi does reasonably teach that the “QOS data”/”performance data” used by the “QoE estimator” to perform “estimation” that, as also shown previously, “often includes learning or otherwise computing and/or inferring the parameter values from QoE data or from other knowledge about the function's desired behavior. For example, an estimator may learn from a set of QoS data, plus user feedback information, and labelled QoE from earlier or training uses, and generate a function that will predict the current QoE measure. This estimated QoE parameters are often learned by correlating a user's QoE training or other data indicative of QoE within application-specific activities to the network performance measured by QoS data”. Given that Cioffi teaches that “Performance data 380 may include QoS data from various OSI layers” and that “the 7 layers or levels…indicate at which level is the QoS or QoE data collected and to which layer is the improved parameter(s) tuned”, Cioffi does reasonably teach training a QoE model using “metrics” at those specifically recited “layers” such that Cioffi does reasonably teach “training, by a device, a quality of experience model to predict a quality of experience metric for an online application based on any one of (i) Layer 3 metrics, (ii) Layer 7 metrics, or (iii) both (i) and (ii)”.
Applicant also argues that Cioffi fails to teach “augmenting, by the device, a predictive network system previously deployed to a network that previously used a prediction model that predicts performance of a network path to enact routing policies, to use the quality of experience model to enact routing policies for routing traffic of the online application instead of using the prediction model”. Application supports such an argument by arguing that “While Cioffi uses the term "policy," Cioffi's policies are not routing policies that select network paths for traffic. Instead, Cioffi's policies relate to prioritization, bandwidth allocation, and parameter adaptation within a WFH environment. In contrast, the claimed invention is directed to determining how to route traffic for an online application. QoS prioritization policies (which adjust bandwidth allocation, queue management, or device priority) are fundamentally different from routing policies (which select the network path, such as sequence of routers and links, that packets traverse to reach their destination). Cioffi's disclosure of QoS-related policies does not anticipate the claimed invention's use of QoE models to enact routing policies.”
However, as the updated rejection shows, Cioffi teaches at paragraphs 0242-0245 by teaching that “The server's policy and profile improvement then prioritize profiles for the corresponding WFH application and device. The policy also may specify how to detect and associate the WFH device and application with the preferred service category. The profile further allows prioritization to be implemented within different home network subsystems. For example: …LAN profile can assign WFH applications and devices to the best QoS paths/links; this may include improving Wi-Fi spatial streams and associated beamforming to better serve the WFH device. WFH applications' data may be input to higher priority queues” and also paragraph 0284 that “To prioritize certain WFH (or other mission-critical) applications or lines, the server 270 may re-profiles the shared-lines' uplink queues dynamically. For example, optimized or improved WFH profiles can reconfigure DOCSIS 3.1 cable modems' to different links to prioritize different service/lines through DOCSIS-3.1-supported AQM, which provides at least the following tunable parameters: enable/disable AQM per service flow, per-flow latency targets, and per-flow buffer sizes. Consider when WFH line/service flow's QoE is low, AQM can then shorten a non-WFH service flow's target latency to initiate more aggressive non-WFH packet dropping. Simultaneously, AQM actions can initiate TCP flow control to reduce TCP flow rate for the affected flow. Alternatively, if similar prioritization occurs instead in the uplink scheduler, TCP flow control will not be triggered until a buffer overflows, so the uplink latency for the de-prioritized user will continue to increase. Therefore, the WFH's AQM optimization/improvement likely maintains better QoE for all connections, even those deprioritized. In general, uplink prioritization can be better managed by jointly optimizing/improving all links”.
Therefore, as best understood by Examiner, Cioffi reasonably teaches that the disclosed “profiles” do enact application-specific routing policies such that Cioffi does teach “augmenting, by the device, a predictive network system previously deployed to a network that previously used a prediction model that predicts performance of a network path to enact routing policies, to use the quality of experience model to enact routing policies for routing traffic of the online application instead of using the prediction model”.
Applicant also argues that “Cioffi does not disclose augmenting a previously deployed system. Instead, Cioffi describes a WFH system designed ab initio with QoE estimation capabilities. Cioffi's dual-mode operation, including a training mode (when user QoE feedback is available) and estimation mode (when it is not), is part of Cioffi's designed system architecture, not a post-deployment modification of an existing system. The claimed invention requires taking a system that was already deployed and operational (using network path performance prediction) and modifying it to use a different type of model (QoE prediction). This temporal sequence of previous deployment with one model type, followed by augmentation to use a different model type is not disclosed in Cioffi. Cioffi's system does not exist "previously" in a QoS-only state and then get augmented; rather, it is designed from inception to toggle between training and estimation modes”.
However, regardless of the clarity issues surrounding what Applicant means by “augmenting” (modifying or otherwise), Applicant’s arguments fail to be commensurate with the scope of the claim. While claims are interpreted in light of the specification, importing claim limitations that are not part of the claim is improper. See MPEP § 2111.01, subsection II. There is no “QoS-only state” claimed, only “a prediction model that predicts performance of a network path to enact routing policies”, something Cioffi does reasonably teach for the same reasons Examiner explains above. Furthermore, the claims do not require that the “predictive network system” be in any particular state at any particular time, only that a “prediction model that predicts performance of a network path to enact routing policies” is “previously used”. Indeed, Cioffi’s teachings are dynamic in nature in that a “prediction model” can be and was “previously deployed” at some point in time before a “quality of experience model” is “trained” and “augmented” as best understood by Examiner to be used “instead” of the “prediction model”. Cioffi’s teachings reasonably envision such a system of evolution, while the claims appear to require such “dual-mode” operation by use of the “instead of” clause, again, as best understood by Examiner. There is also no “modifying” of anything in the claim, only “augmenting” that Examiner finds to be a term that requires further clarification.
Therefore, Examiner finds these arguments to be unpersuasive.
Applicant then argues that Cioffi fails to teach or reasonably suggest “ensuring, by the device and based on the policy information, that the predictive network system that was augmented to use the quality of experience model enacted a routing policy that accurately matches traffic for the online application” since “Routing policies enacted by the predictive network system are evaluated to ensure they accurately match the traffic considered by the QoE model. This verification and correction mechanism may validate that a matching policy exists, create a new policy if none is found, or split an existing policy that is too broad and applies to unintended applications. Cioffi does not disclose such a verification and correction mechanism. While Cioffi discusses applying policies and collecting operational/performance data, Cioffi does not disclose obtaining policy information to verify that enacted policies accurately match the traffic scope of the QoE model, nor does Cioffi disclose creating or splitting policies based on such verification”.
However, the claims do not require any verification and correction mechanism that “may validate that a matching policy exists, create a new policy if none is found, or split an existing policy that is too broad and applies to unintended applications” and Examiner will not import these limitations into the claims. These arguments also fail to be commensurate with the claim’s scope which only allows for any sort of assurance that the predictive network system that was augmented to use the quality of experience model enacted a routing policy that accurately matches traffic for the online application” “based on the policy information”, limitations that have been shown as anticipated by Cioffi. Applicant fails to point to any aspect of the teachings of Cioffi as relied upon in the rejection, therefore, Examiner finds that there is no actionable rationale to remove Cioffi from consideration in response to these arguments.
Conclusion
An updated search did not reveal additional prior art that is relevant to the claimed invention or to the broader disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
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, Tonia Dollinger, can be reached at 571-272-4170. 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.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459
Prosecution Insights