Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed on 6/26/2026 where claims 3, 11, and 19 are cancelled while claims 1-2, 4-10, 12-18, and 20-24 are pending and ready for examination.
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.
Applicant's arguments filed 6/26/2026 have been fully considered but they are not persuasive.
Applicant’s arguments have been reviewed in their entirety (Pages 10-18).
Applicant’s argument is not cogent, On the one hand, Applicant argues that the Examiner must construe the recited “false acknowledgement message” by importing additional characteristics from the Specification, including that the message is locally generated or injected to “trick” the TCP layer. Such characteristics however, are not recited in claim 3. On the other hand, Applicant’s own dependent claim 4 expressly recites that “the first false acknowledgement message is a duplicate acknowledgement (DUP ACK) message” Thus, Applicant cannot reasonably maintain that a DUP ACK cannot correspond to the recited falsie acknowledgement while simultaneously claiming a DUP ACK as a species of that very false acknowledgement message. Under the broadest reasonable interpretation of the actual claim language, and without importing unclaimed implementation details from the specification, Tang and Lopez-Serrano’s disclosure of DUP ACK signaling that causes the TCP layer to reduce its congestion window reasonably corresponds to the recited first false acknowledgement message.
Applicant’s characterization oof Kompella s merely disclosing “static” congestion control parameters is unpersuasive. Paragraph [0065] expressly teaches altering congestion control parameters that govern how the congestion window responds during operation, including changing the mount by which the congestion window is reduced when packet loss is encountered. Thus while Kompella may permit a parameter value to be selected or configured, the selected value controls the subsequent dynamic congestion control response to packet-loss conditions. Applicant therefore improperly equates the configurability of a parameter with the absence of dynamic congestion window behavior.
Moreover, the rejection does not rely upon Kompella alone for dynamically determining the claimed optimal congestion window threshold based on packet loss rate. Kompella is relied upon for its teaching that congestion-window control parameters, including window growth and window reduction behavior, are adjustable. Applicant’s argument attacks Kompella individually for failing to disclose the entirety of the combined rejection.
Applicant appears to equate “dynamic” only with its preferred implementation in which a particular threshold is continuously generated or mapped from observed packet-loss rate. The claim, however, does not require that narrow implementation.
Kompella expressly describes tuning or adjusting congestion-control parameters so that the TCP connection responds differently when packet loss is encountered, including changing the amount by which the congestion window is reduced. That is dynamic congestion-control behavior: a control parameter is changed, and the operative response of the TCP connection changes as a consequence . Nothing in the claim establishes metes and bounds requiring every variable effecting that control operation to be continuously fluctuating or recalculated in real time. Applicant therefore appears to impose an unduly narrow construction of “dynamically” as though the claim required continuously varying inputs and outputs rather than adjustment of congestion-control operation in response to relevant conditions.
The claim recites dynamically adjusting the congestion window size, not dynamically varying every parameter or input used to effect that adjustment. Kompella’s disclosure that congestion -control parameters may be turned to alter the resulting congestion window response therefore directly bears on the claimed dynamic adjustment.
Applicant further characterizes Kompella’s congestion control parameters as “static”, but provides no evidentiary basis for that characterization. Paragraph [0065] expressly describes parameters that may be altered or tuned to change congestion-control behavior, including changing the amount b which the congestion window is reduced when packet loss is encountered. Nothing in the cited disclosure establishes that such parameters are fixed, immutable, or incapable of adjustment during operation. Applicant therefore cannot simply label the disclosed parameters “static” and rely on that unsupported characterization to distinguish the claimed dyinamic adjustment.
Indeed, Kompellas’s express teaching that the congestion-control settings may be changed undermines Applicant’s attempt to characterize those settings categorically as static. At minimum, the disclosure shows adjustable congestion-control parameters whose values affect the TCP congestion window response. Applicant has not identified any limitation in the claim requiring a particular timing, frequency, or mechanism by which those parameters must be adjusted in order for the congestion window adjustment to be “dynamic”
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 1, 4-6, 8-9, 12-14, 16-17, 20-22, and 24 are rejected under 35 USC 103 as being unpatentable over Sze (US 20240098155) in view of Nilsson (US 20190342591) and in further view of Kompella (US 20150085665) and in further view of Tang
Regarding claim 1. Sze discloses a method for controlling transmission control protocol performance in a wireless network, wherein the method is used in a server device and the server device is in communication with a client device based on a transmission control protocol (TCP) connection, comprising:
receiving a plurality of packets from a TCP layer in the server device (Sze; Sze teaches receiving packets via an input queue at a server and handling arrival of new data packets in the system ([0015]), where packets are processed within a transport/communication pipeline and associated with connections, including TCP-based communications as evidenced by ACK/NACK handling and TCP behavior ([0200])
[0015] “... queue data ... ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ...”
[0200] “... TCP ...”
Fig. 1B shows Sender 100 including the input queue 102 and scheduler (104B) whthing a transmission pipeline, and forwarding packets via the network toward a receiver associated with a LAN (client side). Accordingly, the input queue and scheduler are part of the sender-side device, corresponding to the server device.
see e.g. [0419] “Throughout the foregoing discussion, numerous references may have been made in respect of packet controllers, servers, instances, interfaces, portals, platforms, or other systems formed from computing devices.”);
storing the packets in a buffer, recording the packets in a transmission list, and forwarding the packets to the client device, wherein each packet has a packet sequence number provided by TCP (Sze; Sze teaches storing packets in queue, i.e.. a buffer ([0014]-[0015]). Sze further teaches a scheduler that queues and assigns packets for transmission ([0015]). Because scheduling requires selecting packets from those pending transmission, the scheduler must maintain and track a set of packets awaiting transmission; this maintained set corresponds to recording packets in a transmission list under BRI. The scheduler /transmission stage forwards packets to a network interface to client device ([0014]). Sze operates in a TCP context, and TCP packets include sequence numbers as part of the protocol ([0200]), thereby satisfying the requirement that each packet has a sequence number provided by TCP;
see e.g. [0014] “... having a first input queue and scheduling stage, a second connection characteristics monitoring stage (e.g., providing congestion control and packet buffering, and encapsulating pacing instructions), and a third transmission stage for communicating packets to a network interface”
see e.g. [0015] “... a scheduler configured to queue data packets for transmission in response to a monitored communication event (also called a trigger event). Example trigger events (other than a timer), include an ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ... The scheduler assigns data packets to the various networks based on their monitored characteristics at the time of the trigger event”
[0095] The input queue 102 is also responsible for applying a drop policy to packets, in the event that the scheduler (as described herein) is not able to service the input queue 102 at the same rate that new packets arrive from LAN-side clients. This typically occurs if the LAN clients are transmitting at a rate that is higher than the aggregate WAN transmission capacity.);
in response to receiving a packet acknowledgment message sent from the client device, determining a packet loss rate of the client device based on the packet acknowledgment message (Sze; Sze teaches ACK/NACK feedback events as monitored communication events ([0015]). Such acknowledgement feedback inherently indicates whether transmitted packets were successfully received or require retransmission, thereby providing a basis for determining packet loss. Sze further describes packet loss behavior in relation to TCP acknowledgements, including retransmission behavior in response to increase packet loss ([0200]). Because packet loss is determined based on acknowledgement feedback, and Sze teaches that packet loss, throughput, and latency jointly influence congestion control ([0200]), one of ordinary skill in the art would express the determined packet loss in rate form (i.e. packet loss rate) so that it can be used consistently with throughput in controlling behavior;
see e.g. [0200] “Packet loss, latency, and throughput are not completely independent variables. The three of them combined influence each other depending on the application's congestion control behaviour. This is because for example, with TCP, higher packet loss results in longer periods of over-the-air “silence” (underutilized channel) as the sender waits for DUP ACKs or RTOs to occur.
see e.g. [0015] “... a scheduler configured to queue data packets for transmission in response to a monitored communication event (also called a trigger event). Example trigger events (other than a timer), include an ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ...);
and dynamically adjusting a congestion window size of the TCP connection based on the packet loss rate to control a transmission rate of the TCP layer (Sze; Sze teaches monitoring packet loss as a connection characteristic d([0016]) and adjusting congestion window (CWND) t control transmission rate ([0181] – ][0182]). Because packet loss is a measured , continuously evaluated characteristic and Sze permits derivation of characteristics from measured values, one of ordinary skill in the art would have expressed packet loss rate form as a quantitative congestion indicator. I t would have been obvious to use this packet loss rate as an input to the disclosed CWDN adjustment rate;
[0016] Monitored characteristics of an individual connection are a subset of its operating characteristics, and can include, but are not limited to, estimated throughput, measured and/or expected latency, measured packet loss, and other characteristics that can be derived from the measured or expected values. In a clarifying example, the operating characteristics may include estimated throughput, measured and/or expected latency, measured packet loss, and other characteristics that can be derived from the measured or expected values, and the monitored characteristics may be limited to estimated throughpu)
[0181] The set of active connections has capacity to send packets if at least one connection in the set has available CWND (congestion window), meaning that the number of inflight bytes currently tracked by the Scheduler for this connection does not exceed the CWND that has been determined for this connection. In one embodiment, the CWND for the connection may be the CWND as reported by the next pipeline stage, or the Scheduler may choose to reduce the reported CWND if throttling or priority routing are in effect.
[0182] In one embodiment, a connection that is being throttled to a certain rate has its CWND reduced by the same factor as the throttle rate over the bottleneck bandwidth (or the CWND is unchanged if the throttle rate is higher than the bandwidth estimate). Similarly, a connection's CWND may be reduced if it is subject to priority routing (where the embodiment supports connection grouping into priority levels which are activated when total goodput (throughput excluding overhead) of all connections in higher-priority levels drops below the configured threshold for the level to be activated). Various methods for determining the CWND reduction in these scenarios will be described subsequently in relation to FIGS. 8 and 9.).
As evidence of the rationale above Nilsson discloses:
and dynamically adjusting a congestion window size of the TCP connection based on the packet loss rate to control a transmission rate of the TCP layer (Nilsson; Nilsson teaches that packet loss rate (PLR) may be used to set the congestion window size for delivering segments ([0099]), thereby confirming that packet rate loss is a known control input for adjusting CWND to control transmission behavior;
see e.g. [0099] As another example, the packet loss rate PLR(m) may be used to set the size of the congestion window for delivering a subsequent segment n. For example, the congestion window size for segment n may be set in dependence on the packet loss rate for segment m in accordance with a TCP protocol )
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions.
Sze in view of Nilsson does not expressly disclose:
wherein the step of dynamically adjusting the congestion window size of the TCP connection based on the packet loss rate to control the transmission rate of the TCP layer further comprises
obtaining an optimal congestion window threshold based on the packet loss rate;
sending a first false acknowledgment message to the TCP layer to instruct the TCP layer to reduce the congestion window size when the congestion window size is greater than the optimal congestion window threshold;
sending a second false confirmation message to the TCP layer to instruct the TCP layer to increase the congestion window size when the congestion window size is smaller than the optimal congestion window threshold
Kompella discloses:
obtaining an optimal congestion window threshold based on the packet loss rate (Kompella; [0065] For other embodiments, congestion control parameter knob(s) or settings may be used to select different settings for various congestion control parameters such as initial congestion window, slow start threshold, rate at which the additive increase of the congestion window happens, the congestion window decrease factor upon encountering packet loss, and the duplicate ACK threshold for triggering fast retransmission.
The examiner notes as teaching is within the context of throughput one of ordinary skill in the art is readily able to extrapolate packet loss to packet loss rate);
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kompella’s optimization scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of managing network traffic.
Sze in view of Nilssan and in further view of Kompella disclose:
sending a first false acknowledgment message to the TCP layer to instruct the TCP layer to reduce the congestion window size when the congestion window size is greater than the optimal congestion window threshold (Sze; Sze teaches that duplicate acknowledgements are generated and used as a congestion/loss signal that triggers reduction of the congestion window ([0200]). A duplicate ACK repeats a prior acknowledgement and does not advance the sequence state. Accordingly it would have been obvious to transmit a duplicated (i.e. “false”) acknowledgement message to cause a decrease in CWND when above a threshold to control transmission rate”); and
sending a second false confirmation message to the TCP layer to instruct the TCP layer to increase the congestion window size when the congestion window size is smaller than the optimal congestion window threshold (Sze further teaches ACK driven adjustment of CWND, where subsequent acknowledgement feedback (e.g., following recovery/changed conditions) results in increase of the congestion window. This it would have been obvious to transmit a s subsequent message (i.e. a second ‘false confirmation” message under the claimed terminology) to cause an increase in CWND when below a threshold consistent with Sze’s ACK-based control of transmission behavior)
As evidence of the rationale above Tang discloses:
Acknowledgement messages (Tang; Tang teaches acknowledgement signaling including duplicate acknowledgements that repeat prior confirmation information and are used to control congestion window behavior ([0083], [0095]). Tang shows that such duplicate acknowledgements (i.e., repeated acknowledgements/confirmation information) are interpreted by the sender to adjust CWND, thereby supporting the rationale that acknowledgment messages that do not advance sequence state can be used
to selectively decrease or increase the congestion window size as set forth above)
Regarding claim 4, Sze in view of Nilsson and in further view of Kompella and in further view of Tang disclose the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1, wherein the first false acknowledgment message is a duplicate acknowledgment (DUP ACK) message (Sze;
[0200] “... DUP ACKS ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 5, Sze in view of Nilsson and in further view of Kompella and in further view of Tang disclose the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1, wherein the second false acknowledgment message is an acknowledgment (ACK) message (Sze,
See e.g. [0237] “... cellular ...”
See e.g. [0015] “... ACK... “)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 6, Sze in view of Nilsson and in further view of Kompella and in further view of Tang discloses the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1, further comprising:
receiving a first packet from the TCP layer (Sze: Sze teaches receiving packets via an input queue within a TCP-based communication pipeline, where packets are associated with TCP connections and processed upon arrival (e.g. [0015], [0200]), which corresponds to receiving a packet from a TCP layer);
checking whether a first packet sequence number of the first packet is in the transmission list (The combined solution per Nilsson, as Nilsson teaches that acknowledgment messages include sequence numbers reflecting received packet state, and that sequence number information is inspected to determine packet delivery status (e.g. [0104]). This corresponds to checking whether a packet sequence number is already represented in a maintained set (i.e., a transmission list under BRI).;
when the first packet sequence number is not in the transmission list, storing the first packet in the buffer, recording the first packet in the transmission list, and forwarding the first packet to the client device(Sze; Sze teaches storing packets in a queue (buffer) and scheduling them for transmission ([0014] – [0015]), which corresponds to recording packets for transmission, Forwarding to the client device is taught via the transmission state that communicates packets to the receiving endpoint. Under BRI, maintaining queued/scheduled packets corresponds to recording them in a transmission list, and forwarding corresponds to transmitting to the client device); and
discarding the first packet when the first packet sequence number is in the transmission list (The combined solution per Nilsson as Nilsson teaches detecting packet loss and duplicate sequence number conditions via acknowledgement message analysis, including identifying when sequence numbers repeat or do not advance ([0104). Under BRI, once a packet corresponding to a given sequence number is already accounted for (i.e. present in the transmission list), subsequent packets with the same sequence number represent duplicates or already processed data and are not forwarded , which corresponds to discarding the packet).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 8, Sze in view of Nilsson and in further view of Kompella and in further view of Tang disclose the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1 (Sze; see e.g. [0237] “... cellular ...”), wherein the packet acknowledgment message comprises an acknowledgment (ACK) message (Sze, see e.g. [0015] “... ACK...”).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 9, claim 9 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 12, claim 12 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 13, claim 13 comprises the same and/or similar subject matter as claim 5 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 14, claim 14 comprises the same and/or similar subject matter as claim 6 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 8 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 17, claim 17 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 20, claim 20 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 21, claim 21 comprises the same and/or similar subject matter as claim 5 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 22, claim 22 comprises the same and/or similar subject matter as claim 6 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 24, claim 24 comprises the same and/or similar subject matter as claim 8 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 2, 10, and 18 are rejected under 35 USC 103 as being unpatentable over Sze in view of Nilsson and in further view of Kompella and in further view of Kompella and in further view of Tang and in further view of Shimizu (US 20030007785)
Regarding claim 2, Sze in view of Nilsson and in further view of Kompella and in further view of Tang discloses the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1, wherein the packet acknowledgment message comprises a latest confirmation sequence number and lost packet sequence numbers and the method further comprises (Sze; Sze taches that packet acknowledgements may be positive or negative and that packet loss results in retransmission of the lost packets ([0208]), In the TCP-based connection of Sze, packets are tracked using sequence numbers, and acknowledgement feedback reflects the progression of successfully received packets while identifying packets that remain lost. Accordingly, the packet acknowledgment message comprises a latest confirmation sequence number and lost packet sequence numbers):
retransmitting lost packets corresponding to the lost packet sequence numbers to the client device according to the packet acknowledgment message (Sze; Sze teaches that packet acknowledgements may be positive or negative and that packet loss results in retransmission of the lost packets ([0208]). In Sze’s TCP-based connection, packets are tracked and acknowledged using sequence numbers associated with the packets of the connection. The acknowledgment feedback therefore indicates the highest sequence number packet that has been successfully received and identifies packets that remain lost for retransmission. Accordingly, the packet acknowledgement message comprises a latest confirmation sequence number and lost packet sequence numbers under BRI:
[0208] In this example, even though Connection B has significantly higher loss (25% vs 1%), its lower RTT compensates and causes it to compare with a better MathisFactor than Connection A. The explanation for this is that Connection B's lower RTT allows it to exchange packet acknowledgements (positive and negative) for the lost packets, and complete any necessary packet retransmissions faster than Connection A can with its higher RTT, even though it has a smaller percentage loss.
The examiner notes Nilsson further discloses that acknowledgment messages include sequence numbers indicative of received data and that inspection of those sequence numbers is used to detect packet loss ([0104[), which may be utilized in conjunction with Sze ([0104]
[0104]“ ... Each acknowledgement message contains a sequence number indicative of the amount of contiguous data (e.g. the number of consecutive packets) received from a specified time. Following a packet loss, the client continues to send acknowledgement messages, but with identical sequence numbers. Thus, an inspection of the sequence numbers of the acknowledgement messages received at the interface 212 can be used to detect a packet loss event, and hence a packet loss rate. Alternatively, the packet loss rate PLR(m) may be calculated at the client 108 and communicated back to the server 104”).;
Sze in view of Nilsson and in further view of Kompella and in further view of Tang does not expressly disclose:
deleting packets whose packet sequence numbers are smaller than the latest confirmation sequence number and are not the lost packet sequence numbers;
Shimizu discloses:
deleting packets whose packet sequence numbers are smaller than the latest confirmation sequence number and are not the lost packet sequence numbers (Shimizu; Shimizu teaches detecting a discontinuity in packet sequence numbers corresponding toa lost packet sequence number and copying packets associated with the lost packet sequence number while deleting those packets from a buffer ([0075]). This reflects identifying lost packet sequence number s and managing packets based on sequence number progression. Accordingly Zhou contemplates deleting packets based on sequence number relative to a detective loss condition while retaining packets associated with lost packet sequence numbers;
[0075] On the other hand, when detecting discontinuity of the packet sequence number, packet receiver 321 notifies reception notification processor 148 of the last sequence number of the discontinuity range (or simply referred to as the lost packet sequence number). Reception notification processor 148 then copies into lost packet storage 16 the packets having no greater number than the lost packet sequence number (i.e. the packet having the lost packet sequence number and the previous packets) and at the same time deletes these packets from lost packet buffer 147. );
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shimizu’s scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network traffic.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 10, claim 10 comprises the same and/or similar subject matter as claim 2 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 18, claim 18 comprises the same and/or similar subject matter as claim 2 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 7, 15,and 23 is rejected under 35 USC 103 as being unpatentable over Sze in view of Nilsson and in further view of Kompella and in further view of Tang and in further view of Nam (US 20180211364)
Regarding claim 7, Sze in view of Nilsson and in further view of Kompella and in further view of Tang discloses the method for controlling transmission control protocol performance in a wireless network as claimed in claim 1 (Sze; see e.g. [0237]), Sze does not expressly disclose wherein the packet acknowledgment message comprises a selective acknowledgment (SACK) message.
Nam discloses:
wherein the packet acknowledgment message comprises a selective acknowledgment (SACK) message (Nam;
[0206] If some of packets transmitted by a server through the TCP protocol are lost, a UE may notify the server that some packets have been lost by transmitting an SACK. The server that has received the SACK recognizes that some of the packets have been lost, and may enter a congestion avoidance phase in which a CWND is decreased. That is, if some of the packets are lost, the server may decrease the transfer speed of the packets by decreasing the CWND)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nam’s SACK. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies in managing network transmission.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 15, claim 15 comprises the same and/or similar subject matter as claim 7 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 23, claim 23 comprises the same and/or similar subject matter as claim 7 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 1, 9, and 17 are rejected under 35 USC 103 as being unpatentable over Sze (US 20240098155) in view of Nilsson (US 20190342591) and in further view of Kompella (US 20150085665) and in further view of Lopez Serrano (US 2017/0195231)
Regarding claim 1. Sze discloses a method for controlling transmission control protocol performance in a wireless network, wherein the method is used in a server device and the server device is in communication with a client device based on a transmission control protocol (TCP) connection, comprising:
receiving a plurality of packets from a TCP layer in the server device (Sze; Sze teaches receiving packets via an input queue at a server and handling arrival of new data packets in the system ([0015]), where packets are processed within a transport/communication pipeline and associated with connections, including TCP-based communications as evidenced by ACK/NACK handling and TCP behavior ([0200])
[0015] “... queue data ... ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ...”
[0200] “... TCP ...”
Fig. 1B shows Sender 100 including the input queue 102 and scheduler (104B) whthing a transmission pipeline, and forwarding packets via the network toward a receiver associated with a LAN (client side). Accordingly, the input queue and scheduler are part of the sender-side device, corresponding to the server device.
see e.g. [0419] “Throughout the foregoing discussion, numerous references may have been made in respect of packet controllers, servers, instances, interfaces, portals, platforms, or other systems formed from computing devices.”);
storing the packets in a buffer, recording the packets in a transmission list, and forwarding the packets to the client device, wherein each packet has a packet sequence number provided by TCP (Sze; Sze teaches storing packets in queue, i.e.. a buffer ([0014]-[0015]). Sze further teaches a scheduler that queues and assigns packets for transmission ([0015]). Because scheduling requires selecting packets from those pending transmission, the scheduler must maintain and track a set of packets awaiting transmission; this maintained set corresponds to recording packets in a transmission list under BRI. The scheduler /transmission stage forwards packets to a network interface to client device ([0014]). Sze operates in a TCP context, and TCP packets include sequence numbers as part of the protocol ([0200]), thereby satisfying the requirement that each packet has a sequence number provided by TCP;
see e.g. [0014] “... having a first input queue and scheduling stage, a second connection characteristics monitoring stage (e.g., providing congestion control and packet buffering, and encapsulating pacing instructions), and a third transmission stage for communicating packets to a network interface”
see e.g. [0015] “... a scheduler configured to queue data packets for transmission in response to a monitored communication event (also called a trigger event). Example trigger events (other than a timer), include an ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ... The scheduler assigns data packets to the various networks based on their monitored characteristics at the time of the trigger event”
[0095] The input queue 102 is also responsible for applying a drop policy to packets, in the event that the scheduler (as described herein) is not able to service the input queue 102 at the same rate that new packets arrive from LAN-side clients. This typically occurs if the LAN clients are transmitting at a rate that is higher than the aggregate WAN transmission capacity.);
in response to receiving a packet acknowledgment message sent from the client device, determining a packet loss rate of the client device based on the packet acknowledgment message (Sze; Sze teaches ACK/NACK feedback events as monitored communication events ([0015]). Such acknowledgement feedback inherently indicates whether transmitted packets were successfully received or require retransmission, thereby providing a basis for determining packet loss. Sze further describes packet loss behavior in relation to TCP acknowledgements, including retransmission behavior in response to increase packet loss ([0200]). Because packet loss is determined based on acknowledgement feedback, and Sze teaches that packet loss, throughput, and latency jointly influence congestion control ([0200]), one of ordinary skill in the art would express the determined packet loss in rate form (i.e. packet loss rate) so that it can be used consistently with throughput in controlling behavior;
see e.g. [0200] “Packet loss, latency, and throughput are not completely independent variables. The three of them combined influence each other depending on the application's congestion control behaviour. This is because for example, with TCP, higher packet loss results in longer periods of over-the-air “silence” (underutilized channel) as the sender waits for DUP ACKs or RTOs to occur.
see e.g. [0015] “... a scheduler configured to queue data packets for transmission in response to a monitored communication event (also called a trigger event). Example trigger events (other than a timer), include an ACK/NACK of previously transmitted WAN packets, the arrival of new data at the Input Queue ...);
and dynamically adjusting a congestion window size of the TCP connection based on the packet loss rate to control a transmission rate of the TCP layer (Sze; Sze teaches monitoring packet loss as a connection characteristic d([0016]) and adjusting congestion window (CWND) t control transmission rate ([0181] – ][0182]). Because packet loss is a measured , continuously evaluated characteristic and Sze permits derivation of characteristics from measured values, one of ordinary skill in the art would have expressed packet loss rate form as a quantitative congestion indicator. I t would have been obvious to use this packet loss rate as an input to the disclosed CWDN adjustment rate;
[0016] Monitored characteristics of an individual connection are a subset of its operating characteristics, and can include, but are not limited to, estimated throughput, measured and/or expected latency, measured packet loss, and other characteristics that can be derived from the measured or expected values. In a clarifying example, the operating characteristics may include estimated throughput, measured and/or expected latency, measured packet loss, and other characteristics that can be derived from the measured or expected values, and the monitored characteristics may be limited to estimated throughpu)
[0181] The set of active connections has capacity to send packets if at least one connection in the set has available CWND (congestion window), meaning that the number of inflight bytes currently tracked by the Scheduler for this connection does not exceed the CWND that has been determined for this connection. In one embodiment, the CWND for the connection may be the CWND as reported by the next pipeline stage, or the Scheduler may choose to reduce the reported CWND if throttling or priority routing are in effect.
[0182] In one embodiment, a connection that is being throttled to a certain rate has its CWND reduced by the same factor as the throttle rate over the bottleneck bandwidth (or the CWND is unchanged if the throttle rate is higher than the bandwidth estimate). Similarly, a connection's CWND may be reduced if it is subject to priority routing (where the embodiment supports connection grouping into priority levels which are activated when total goodput (throughput excluding overhead) of all connections in higher-priority levels drops below the configured threshold for the level to be activated). Various methods for determining the CWND reduction in these scenarios will be described subsequently in relation to FIGS. 8 and 9.).
As evidence of the rationale above Nilsson discloses:
and dynamically adjusting a congestion window size of the TCP connection based on the packet loss rate to control a transmission rate of the TCP layer (Nilsson; Nilsson teaches that packet loss rate (PLR) may be used to set the congestion window size for delivering segments ([0099]), thereby confirming that packet rate loss is a known control input for adjusting CWND to control transmission behavior;
see e.g. [0099] As another example, the packet loss rate PLR(m) may be used to set the size of the congestion window for delivering a subsequent segment n. For example, the congestion window size for segment n may be set in dependence on the packet loss rate for segment m in accordance with a TCP protocol )
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions.
Sze in view of Nilsson does not expressly disclose:
wherein the step of dynamically adjusting the congestion window size of the TCP connection based on the packet loss rate to control the transmission rate of the TCP layer further comprises
obtaining an optimal congestion window threshold based on the packet loss rate;
sending a first false acknowledgment message to the TCP layer to instruct the TCP layer to reduce the congestion window size when the congestion window size is greater than the optimal congestion window threshold;
sending a second false confirmation message to the TCP layer to instruct the TCP layer to increase the congestion window size when the congestion window size is smaller than the optimal congestion window threshold
Kompella discloses:
obtaining an optimal congestion window threshold based on the packet loss rate (Kompella; [0065] For other embodiments, congestion control parameter knob(s) or settings may be used to select different settings for various congestion control parameters such as initial congestion window, slow start threshold, rate at which the additive increase of the congestion window happens, the congestion window decrease factor upon encountering packet loss, and the duplicate ACK threshold for triggering fast retransmission.
The examiner notes as teaching is within the context of throughput one of ordinary skill in the art is readily able to extrapolate packet loss to packet loss rate);
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Kompella’s optimization scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of managing network traffic.
Sze in view of Nilssan and in further view of Kompella disclose:
sending a first false acknowledgment message to the TCP layer to instruct the TCP layer to reduce the congestion window size when the congestion window size is greater than the optimal congestion window threshold (Sze; Sze teaches that duplicate acknowledgements are generated and used as a congestion/loss signal that triggers reduction of the congestion window ([0200]). A duplicate ACK repeats a prior acknowledgement and does not advance the sequence state. Accordingly it would have been obvious to transmit a duplicated (i.e. “false”) acknowledgement message to cause a decrease in CWND when above a threshold to control transmission rate”); and
sending a second false confirmation message to the TCP layer to instruct the TCP layer to increase the congestion window size when the congestion window size is smaller than the optimal congestion window threshold (Sze further teaches ACK driven adjustment of CWND, where subsequent acknowledgement feedback (e.g., following recovery/changed conditions) results in increase of the congestion window. This it would have been obvious to transmit a s subsequent message (i.e. a second ‘false confirmation” message under the claimed terminology) to cause an increase in CWND when below a threshold consistent with Sze’s ACK-based control of transmission behavior)
As evidence of the rationale above Lopez-Serrano discloses:
Acknowledgement based congestion control (Serrano teaches that acknowledgement segments are used to control transmission behavior, including that duplicate acknowledgement segments trigger reduction of the congestion window ([0027]) and that acknowledgment segments are used to increase the congestion window during growth phases ([0025]-[0026]). Serrano further teaches continued adjustment of the congestion window based on acknowledgement signaling ([0028], ).
Accordingly, the duplicate acknowledgment segments correspond to the claimed fist false acknowledgements message, and the acknowledgement segments used to increase the congestion window correspond to the claimed second false confirmation message, as both are acknowledgement based signals used to control congestion window size)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Serrano’s scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nilsson’s CWND size determination scheme. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of managing network transmissions
Regarding claim 9, claim 9 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 17, claim 17 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304
/TODD L BARKER/Primary Examiner, Art Unit 2449
Prosecution Insights