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 .
Claims 1-20 are pending for examination.
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.
Claims 1, 4, 7-8, 11, 14-15, 18 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 11641323 (Tuan et al.).
Regarding Claim 1, Tuan teaches a network interface device, comprising: a processor; and a non-transitory computer-readable medium having stored thereon instructions that, when executed by the processor, cause the processor to implement a first processing layer and a second processing layer to perform the following ([Fig. 2] Fig. 2 illustrates control plane layer and data plane layer. [C.4:L.38-46], higher application layer that includes the congestion control (CC) algorithm 120. …the CC algorithm 120 is part of a control plane slow path …also includes the CC data processing unit 135 which is disposed in a control plane fast path layer. Further, the framework 200 includes a data plane that contains the measurement module 140 and the enforcement module 150):
receive, by the first processing layer, an event notification from the second processing layer ([C.7:L.41-49], The trigger 325 keeps track of the status of the flows and generates the corresponding events to the CC data processing unit 135. The per-flow events can be triggered by a timer or by matching packet headers. When the trigger 325 finds a match between a packet and a flow of interest, it obtains the flow ID and forwards it to the CC data processing unit 135. [C.8:L.49-50], the CC data processing unit can receive the performance measurement results from the measurement module 140. [C.7:L.1-3], After being activated by a trigger 325, the CC data processing unit 135 reads the measurement results from the data plane);
in response to the first processing layer determining that congestion control is required based on the event notification ([C.4:L.63 – C.5:L.7], The control plane is composed of two sub-components (i.e., the CC data processing unit 135 and the CC algorithm 120) …These sub-components make decisions to change the behavior of the enforcement module 150 based on the performance data measured by the measurement module 140),
determine, by the first processing layer, an adjustment to a packet forwarding parameter from a first value to a second value by applying a congestion control algorithm, wherein the congestion control algorithm is one of multiple congestion control algorithms that the first processing layer is programmable to apply ([C.7:L.1-5] After being activated by a trigger 325, the CC data processing unit 135 reads the measurement results from the data plane. After that, the CC data processing unit 135 executes a pre-configured decision-making algorithm to process the results. [C.2:L.17-20] the CC data processing unit is capable of being programmed to perform tasks corresponding to a plurality of different CC algorithms. [C.8:L.2-8] Different CC algorithms can enable the measurement module 140 to measure specific parameters via configuration. The proposed framework supports multiple communication flows, and each flow can be associated with a different CC algorithm and a set of measurements. [C.8:L.36-40], the CC runtime 310 configures the CC data processing unit to process the measurements according to the new CC algorithm. the hardware/circuitry of the CC data processing unit may be able to perform many different CC algorithms);
generate and send, by the first processing layer, an instruction to the second processing layer to perform the adjustment ([C.8:L.49-52] the CC data processing unit can receive the performance measurement results from the measurement module 140, process the results, and provide instructions to the enforcement module 150. [C.9:L.1-5], the CC runtime configures the CC data processing unit, to provide control parameters to the enforcement module that tell this module how to process egress packets); and
based on the instruction, configure, by the second processing layer, a component of the network interface device to control packet forwarding towards a physical network based on the second value of the packet forwarding parameter ([C.8:L.66-C.9:L.10] the CC runtime enables the enforcement module to regulate flows based on the control parameters calculated by the CC algorithm. …these received control parameters can tell the enforcement module when, and how many, packets should be transmitted from the host to the network (or other remote location). The enforcement modules schedule regulates the packets. [C.10:L.9-12] forwards the control parameters to the enforcement module which then controls how the egress packets leave the host in response).
Regarding Claim 4, Tuan teaches the network interface device of claim 1, wherein the instructions for determining the adjustment cause the processor to: determine, by the first processing layer, the adjustment to the packet forwarding parameter in the form of a transmission rate, wherein the congestion control algorithm is a rate-based congestion control algorithm ([C.8:L.66 – C.9:L.10], CC runtime enables the enforcement module to regulate flows based on the control parameters calculated by the CC algorithm. … provide control parameters to the enforcement module that tell this module how to process egress packets. For example, these received control parameters can tell the enforcement module when, and how many, packets should be transmitted from the host to the network (or other remote location). The enforcement modules schedule regulates the packets based on the requested pacing value (sending speed. [C.10:L.4-12] forwards the data to the CC runtime 310, where in steps 5 and 6, the slow path (which includes the CC runtime 310, the CC algorithm 120, and the stack 305) calculates instructions (e.g., control parameters such as pacing rate) for the enforcement module. …forwards the control parameters to the enforcement module which then controls how the egress packets leave the host in response. [C.11:L.19-25], the CC framework can read the RTT, sending speed, receiving speed value as well as Bandwidth-Delay-Product (BDP) calculation results. If the RTT sample is not increasing, the CC framework increases the pacing value).
Regarding Claim 7, Tuan teaches the network interface device of claim 1, wherein the instructions for configuring the component cause the processor to: configure, by the second processing layer, the component in the form of a hardware scheduler, the second processing layer acting as an intermediary between the first processing layer and the hardware scheduler ([C.4:L.58-60] The enforcement module 150 controls and schedules when, and how many, packets should leave the host to the remote location. [C.9:L.9-10], the enforcement modules schedule regulates the packets based on the requested pacing value. [C.4:L.42-54] the CC data processing unit 135 which is disposed in a control plane fast path layer. Further, includes a data plane that contains the measurement module 140 and the enforcement module 150. After processing the metrics, in some embodiments, the CC data processing unit 135 sends control parameters to the enforcement module 150 for controlling how egress network traffic is transmitted from the host. [C.3:41-49], the enforcement module implemented in hardware… the hardware components can be programmed to perform measurement, processing, and enforcement tasks).
Regarding Independent Claims 8 and 15, the claim limitations are identical and/or equivalent in scope to claim 1. Therefore, claims 8 and 15 are rejected under the same rationale as claim 1.
Claim 11 is rejected under the same rationale as claim 4, since the claim limitations are identical and/or equivalent in scope.
Claims 14 and 20 are rejected under the same rationale as claim 7, since the claim limitations are identical and/or equivalent in scope.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2-3, 9-10 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Tuan in view of US 11832126 (Chen et al.).
Regarding Claim 2, Tuan teaches the network interface device of claim 1, wherein the instructions for determining that congestion control is required cause the processor to: determine, by the first processing layer, metric information associated with packet forwarding based on the event notification…via the second processing layer; and determine, by the first processing layer, that congestion control is required based on the metric information ([C.4:L.46-54], The measurement module 140 monitors ingress and egress network traffic and provides performance metrics to the CC data processing unit 135 in the control plane. After processing the metrics, the CC data processing unit 135 sends control parameters to the enforcement module 150 for controlling how egress network traffic is transmitted from the host. [C.7:L.2-13], the CC data processing unit 135 executes a pre-configured decision-making algorithm to process the results through a series of steps: determining the state, carrying out calculations, updating local state and communicating messages with the other modules. …algorithms used to calculate advanced measurement metrics such as exponentially weighted moving average (EWMA), smoothed RTT (SRTT), RTT variation (RTTVar), etc., could be supported by the processing unit 135 depending on the hardware configuration. [C.11:L.19-22] the CC framework can read the RTT, sending speed, receiving speed value as well as Bandwidth-Delay-Product (BDP) calculation results).
Tuan does not explicitly teach a probe response, however, Chen teaches a probe response has been received ([C.2:L.47-50] decode a ML probe response frame from the AP of the AP MLD. The ML probe response may include complete information from any of the Aps).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chen's probe-based data collection mechanism into the congestion control system of Tuan because such incorporation would be an obvious enhancement to improve the accuracy and responsiveness of Tuan’s congestion control logic.
Regarding Claim 3, while, Tuan teaches a framework that is designed to be programmable and can be adapted at runtime to various requirements from a user in measurements it captures, enforcement, and hardware-software interactions [C.3:L.27-30], however, Tuan does not explicitly teach, but Chen teaches the network interface device of claim 2, wherein the instructions further cause the processor to: prior to receiving the event notification, determine, by the first processing layer, whether a probe packet is required based on one or more …rules that the first processing layer is programmable to apply (Chen teaches applying rules to determine whether ML probe requests should be transmitted. For example, [C.4:L.52-55] a MLD probe request and response system may facilitate several rules to limit the use of multi-link device (MLD) Probe Request frame in different cases. [C.3L.16-20] the non-AP STA may refrain from transmitting the ML probe request frame …when another non-AP STA (STA2) of the AP MLD has already received a ML probe response. [C.4:L.34-37] it would be considered to limit the use of MLD Probe Request frames only when necessary and prohibit excessive use of them as much as possible. [C.4:L.65 – C.5:L.10] a MLD probe request and response system would limit the use of MLD Probe Request from several aspects. 1. Blind MLD Probe Request: In 11ax, blind Probe Request is prohibited in 6 GHz band as follows: In 11ax 6 GHz the non-AP STA may not transmit a Probe Request frame to the broadcast destination address with the Address 3 field set to the wildcard BSSID, and the SSID set to the wildcard SSID. For 11 be MLD Probing, it should only be done after basic discovery. Therefore, blind MLD Probe Request should also be prohibited); and in response to determination that a probe packet is required, generate and send, by the first processing layer, a request to the second processing layer to send the probe packet towards a receptor that is capable of sending the probe response ([C.1:L.55-58] a non-AP STA (STA1) of the STA MLD may be configured to encode a multi-link (ML) probe request frame for transmission to an access point STA (AP). [C.3:L.66 – C.4:L.1] a mechanism may be defined for a STA …to send a probe request frame to an AP).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chen’s rule-driven probe-request mechanism within Tuan’s programmable layered framework in order to improve congestion detection and network-state estimation using actively generated probe traffic and returned probe responses, thereby enabling more accurate and responsive congestion control decisions.
Claims 9-10 and 16-17 are rejected under the same rationale as claims 2-3, since the claim limitations are identical and/or equivalent in scope.
Claims 5, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tuan in view of US 2023/0300671 (Jian et al.).
Regarding Claim 5, Tuan does not explicitly teach, however, Jian teaches the network interface device of claim 1, wherein the instructions for determining the adjustment cause the processor to: determine, by the first processing layer, the adjustment to the packet forwarding parameter in the form of a congestion window size, wherein the congestion control algorithm is a window-based congestion control algorithm ([Abstract], Jian describes a method for managing wireless network congestion. Measures congestion metrics from the Radio Access Network (RAN) and higher layers, estimates the severity of the congestion, and automatically adjusts its connection parameters to maintain stable communication. [0039-0040], estimate an amount of packet congestion present in the RAN based on the measured parameters. …estimate congestion control parameters associated with a congestion control mechanism at the server based on the congestion metrics. The congestion control parameters may include a round-trip-time (RTT), a bandwidth delay product (BDP), a congestion window size (e.g., a quantity of packets received in a single RTT), or any combination thereof. …predict (calculate or estimate) modified connection parameters that may reduce the packet congestion based on the estimated packet congestion. …input the estimated packet congestion and congestion control parameters to a prediction algorithm to predict the modified connection parameters, …The modified connection parameters may include a throttled acknowledgment rate, an adjusted receiver window size, one or more other connection parameters, or any combination thereof. …may indicate an adjusted receiver window size associated with a quantity of data packets receive within a given time period, and may adjust transmissions based on the receiver window size to reduce data packet congestion).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Jian's congestion window measurement system into the congestion control system of Tuan because such incorporation would have improved accuracy of congestion-control decisions, and more stable rate adjustment.
Claim 12 is rejected under the same rationale as claim 5, since the claim limitations are identical and/or equivalent in scope.
Claim 18 is rejected under the same rationale as claims 4 and 5, since the claim limitations are identical and/or equivalent in scope.
Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tuan in view of US 20210152474 (Shpigelman et al.).
Regarding Claim 6, Tuan does not explicitly teach, however, Shpigelman teaches The network interface device of claim 1, wherein the instructions for determining that congestion control is required cause the processor to: determine, by the first processing layer, that congestion control is required based on the event notification indicating that the second processing layer has detected at least one of the following events: a retransmission timeout (RTO) event, a sequence error negative acknowledgement (NAK) event, and a congestion notification point (CNP) event ([¶¶ 0038-0039, 0042], when congested, may mark packets that the transmitting Network Adapter sends with an Explicit Congestion indication (ECN). …sends return packets back, …including packets that are used for congestion control such as CNP packets, ACK/NACK packets, RTT measurement packets and Programmable CC packets … generate programmable CC packets, to facilitate various programmable congestion control algorithms… execute congestion control algorithms, initiate sending of congestion control packets and mitigate congestion … receives congestion notification packets. The received congestion notification packets may include, for example, ACK and NACK that are received in response to transmitted packets, CNP packets that generated in response to receiving ECN-marked packets, RTT measurement packets and congestion control packets).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shpigelman’s CNP-event driven congestion control techniques into Tuan’s programmable congestion-control framework, because such incorporation would allowed to support multiple congestion-control algorithms and react more quickly to congestion event such as RTO, NAK or CNP events.
Claims 13 and 19 are rejected under the same rationale as claim 6, since the claim limitations are identical and/or equivalent in scope.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights