DETAILED ACTION
This office action is a response to a communication made on 02/18/2026.
Claims 1, 11 and 17 are currently amended.
Claim 20 is canceled.
Claim 21 is new.
Claims 1-19 and 21 are pending for this application.
Request for Continued Examination (RCE) 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 02/18/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/26/2025 was filed before the mailing date of the final action on 08/08/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Allowable Subject Matter
Claim 21 is 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.
Response to Arguments
Applicant: Applicant’s arguments, see remarks on page 7-8, filed 02/18/2026, applicant argues that, “Palyi in view of Ohkawa do not teach or suggest, detecting for a network congestion signal" (id) in one, let alone "both (i) the before-loss-window ... and (ii) the after-loss-window.. ." (id) as claimed”.
Examiner: Applicant's arguments filed 02/18/2026 have been fully considered but they are not persuasive. Examiner respectfully disagrees.
Palyi ¶0047-¶0048, teaches determining the number of data packet loss events, during a pre-determined first time period or per a pre-determined first number of data packets sent from the first network node, based on the detected data packet loss… When the determined number of data packet loss events comprises a number of data packet loss events during a pre-determined second time period, said number of data packet loss events during a pre-determined second time period may be considered as a single data packet loss event, ¶0061, teaches in order to detect a data frame delay, the so-called delay reference time field of data frames may be used. The delay reference time may be regarded as a timestamp of the data packet when located at or passing a first network node. At the time the data packet is located at or passing a second network node, an amount of time has passed. This amount of time is checked and handled according to the presented method, ¶0072, teaches a time line along which data frame loss events can be detected. An “X” is a marker of a detected data frame loss event along the time line. At the time a first data frame loss events occurs, an “X” 50 is marked along the time line and a timer T is started. If a second data frame loss event “X” 52 is detected within a time Tp from the detection of the first data frame loss event, the first 50 and second 52 data frame loss events are considered a single data frame loss event.
However, Palyi remain silent on detecting congestion-based packet loss by detecting a network congestion signal in both (i) the before-loss-window prior to detecting the loss of the one or more data packets and (ii) the after-loss-window subsequent to detecting the loss of the one or more data packets.
Ohkawa teaches detecting congestion-based packet loss by detecting a network congestion signal in both (i) the before-loss-window prior to detecting the loss of the one or more data packets and (ii) the after-loss-window subsequent to detecting the loss of the one or more data packets because ¶0065, ¶0068, ¶0085, ¶0089 and ¶0092 teaches when a packet loss occurs, the CPU 31 stores RTT (RTTLoss) as of immediately before the occurrence of the loss in the RAM 32. Furthermore, the CPU 31 stores the window size (previous window size) as of immediately before the occurrence of the loss in the RAM 32. The CPU 31 changes the loss status to NOW_LOSS. After the loss status changes to PRE_LOSS…a congestion state is detected from a packet loss… RTT as of immediately before the occurrence of the packet loss in the RAM 32 (step S162). The CPU 31 stores the window size as of immediately before the occurrence of the packet loss in the RAM 32 (step S163). The CPU 31 changes the loss status to NOW_LOSS (step S164)…calculates the difference between the window size as of immediately before the occurrence of the loss (i.e. a before-loss-window) and the window size as of immediately after the occurrence of the loss (i.e. an after-loss-window)… the CPU 31 calculates the difference between the window size as of immediately before the occurrence of the loss and the window size as of immediately after the occurrence of the loss, thereby determining the first amount of reduction.
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.
Claim(s) 1-3, 7-8, 11-13 and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Palyi et al. (US 2014/0301225), hereinafter “Palyi” in view of Ohkawa et al. (US 2017/0289054 A1), hereinafter “Ohkawa”.
With respect to claim 1, Palyi discloses a method using a communication protocol for controlling network traffic for a computer network, the method comprising:
detecting a loss of one or more data packets in network traffic received from one or more sender nodes (¶0044, teaches in 202 a data packet loss in receiving a data packet flow, is detected. In 204 it is detected data delay information of data packets of the data packet flow as received from the first network node);
controlling a flow of network traffic in the computer network based on a determined reason for the packet loss (¶0039, teaches a gap in the sequence of data packet flow indicates a data packet loss, and this data packet loss is interpreted as congestion in the per-flow HSPA transport network congestion control, ¶0040, teaches Packet loss is therefore always considered to be due to congestion. In the case of a detected packet loss, congestion action will be performed irrespective of the reason of the packet loss),
wherein the reason for packet loss is due to link congestion or a different reason for packet loss (¶0006, teaches packet loss may occur due to congestion or due to other reasons, i.e. data corruption, ¶0040, teaches Packet loss is therefore always considered to be due to congestion. In the case of a detected packet loss, congestion action will be performed irrespective of the reason of the packet loss, ¶0054, teaches congestion control can be applied in both the uplink and downlink, i.e. high-speed uplink data packet access and high-speed downlink data packet access, respectively).
However, Palyi remain silent on initializing, based on at least one of packet loss rate environments or real time network conditions, a before-loss-window and an after-loss-window, determining a reason for the loss, comprising detecting for a network congestion signal in both (i) the before-loss-window prior to detecting the loss of the one or more data packets and (ii) the after-loss-window subsequent to detecting the loss of the one or more data packets.
Ohkawa discloses initializing, based on at least one of a packet loss rate environment or a real time network condition, two time-windows within which to detect congestion-based packet loss, wherein the two time-windows comprises a before-loss-window and an after-loss-window (¶0065, ¶0068 and ¶0089, teaches When a packet loss occurs, the CPU 31 stores RTT (RTTLoss) as of immediately before the occurrence of the loss in the RAM 32. Furthermore, the CPU 31 stores the window size (previous window size) as of immediately before the occurrence of the loss in the RAM 32. The CPU 31 changes the loss status to NOW_LOSS. After the loss status changes to PRE_LOSS …a congestion state is detected from a packet loss… calculates the difference between the window size as of immediately before the occurrence of the loss (i.e. a before-loss-window) and the window size as of immediately after the occurrence of the loss (i.e. an after-loss-window), wherein before the occurrence of the loss and after the occurrence of the loss are two time windows to detect congestion based packet loss);
determining the reason for the loss (¶0068, teaches a congestion state is detected from a packet loss), comprising detecting congestion-based packet loss by detecting a network congestion signal in both (i) the before-loss-window prior to detecting the loss of the one or more data packets and (ii) the after-loss-window subsequent to detecting the loss of the one or more data packets (¶0065, ¶0068, ¶0085, ¶0089 and ¶0092 teaches when a packet loss occurs, the CPU 31 stores RTT (RTTLoss) as of immediately before the occurrence of the loss in the RAM 32. Furthermore, the CPU 31 stores the window size (previous window size) as of immediately before the occurrence of the loss in the RAM 32. The CPU 31 changes the loss status to NOW_LOSS. After the loss status changes to PRE_LOSS…a congestion state is detected from a packet loss… RTT as of immediately before the occurrence of the packet loss in the RAM 32 (step S162). The CPU 31 stores the window size as of immediately before the occurrence of the packet loss in the RAM 32 (step S163). The CPU 31 changes the loss status to NOW_LOSS (step S164)…calculates the difference between the window size as of immediately before the occurrence of the loss (i.e. a before-loss-window) and the window size as of immediately after the occurrence of the loss (i.e. an after-loss-window)… the CPU 31 calculates the difference between the window size as of immediately before the occurrence of the loss and the window size as of immediately after the occurrence of the loss, thereby determining the first amount of reduction).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Palyi’s packet loss may occur due to congestion or due to other reasons, i.e. data corruption with initializing, based on at least one of a packet loss rate environment or a real time network condition, two time-windows within which to detect congestion-based packet loss, wherein the two time-windows comprises a before-loss-window and an after-loss-window, determining a reason for the loss, comprising detecting congestion-based packet loss by detecting for a network congestion signal in both (i) the before-loss-window prior to detecting the loss of the one or more data packets and (ii) the after-loss-window subsequent to detecting the loss of the one or more data packets of Ohkawa, in order to accurate diagnosis of loss cause, smart adaption of congestion control and better performance and user experience, especially in lossy environments (Ohkawa, ¶0099).
For claim 11, it is a congestion controller claim corresponding to the method of claim 1. Therefore claim 11 is rejected under the same ground as claim 1.
For claim 17, it is a non-transitory computer-readable medium claim corresponding to the method of claim 1. Therefore claim 17 is rejected under the same ground as claim 1.
With respect to claims 2, 12 and 18, Palyi in view of Ohkawa discloses the method of claim 1,
wherein in response to the network congestion signal being detected (Palyi, ¶0023, teaches an explicit congestion notification (i.e. a network congestion signal) mark of a data packet of the data packet flow), the method comprises determining that the reason for the packet loss is due to link congestion (Palyi, ¶0006, teaches packet loss may occur due to congestion or due to other reasons, i.e. data corruption, ¶0025-¶0026, teaches receiving the data packet flow may comprise receiving a high-speed uplink packet access data packet flow, or a high-speed downlink packet access data packet flow… The network node comprises a receiver that is configured to receive the data packet flow, and a detector that is configured to detect a data packet loss in the received data packet flow, and to detect data delay information of data packets of the data packet flow, ¶0040, teaches Packet loss is therefore always considered to be due to congestion. In the case of a detected packet loss, congestion action will be performed irrespective of the reason of the packet loss, ¶0054, teaches congestion control can be applied in both the uplink and downlink, i.e. high-speed uplink data packet access and high-speed downlink data packet access, respectively, Ohkawa, ¶0068, teaches a congestion state is detected from a packet loss, ¶0102, teaches the CPU 31 reads out a measure time period (a start time and an end time) for a connection (i.e. link congestion) determined to be subjected to first congestion control.).
With respect to claims 3 and 13, Palyi in view of Ohkawa discloses the method of claim 2, wherein the network congestion signal includes one or more of an Explicit Congestion Notification (ECN), a Round-Trip Time (RTT), or Inband Network Telemetry (INT) (Palyi, ¶0023, teaches an explicit congestion notification mark of a data packet of the data packet flow).
With respect to claims 7 and 15, Palyi in view of Ohkawa discloses the method of claim 2,
wherein in response to detecting the network congestion signal in one of the at least two time windows (Palyi, ¶0047-¶0048 and ¶0061, Ohkawa, ¶0065 and ¶0089, teaches calculates the difference between the window size as of immediately before the occurrence of the loss and the window size as of immediately after the occurrence of the loss, wherein before the occurrence of the loss and after the occurrence of the loss are two time windows to detect congestion based packet loss), the method further comprises:
determining that the reason for the packet loss is due to link congestion (Palyi, ¶0006, teaches packet loss may occur due to congestion or due to other reasons, i.e. data corruption, ¶0040, teaches Packet loss is therefore always considered to be due to congestion. In the case of a detected packet loss, congestion action will be performed irrespective of the reason of the packet loss, ¶0054, teaches congestion control can be applied in both the uplink and downlink, i.e. high-speed uplink data packet access and high-speed downlink data packet access, respectively, Ohkawa, ¶0068, teaches a congestion state is detected from a packet loss, ¶0102, teaches the CPU 31 reads out a measure time period (a start time and an end time) for a connection (i.e. link congestion) determined to be subjected to first congestion control), and
reducing the flow of network traffic (Palyi, ¶0022, teaches omitting to reduce the maximum allowed bitrate for the data packet flow).
With respect to claims 8 and 16, Palyi in view of Ohkawa discloses the method of claim 1,
wherein in response to the network congestion signal not being detected (Palyi, ¶0041, teaches a data packet loss does not need to be caused by congestion, Ohkawa, ¶0107, teaches In a case where the CPU 31 does not determine that there is a connection having a high throughput and there is another connection subjected to the second type of congestion control or the third type of congestion control (NO in step S201)), the method comprises maintaining the flow of the network traffic (Palyi, ¶0073, teaches receiving (i.e. maintaining) a data packet flow from a first network node).
Claim(s) 4-5, 9-10, 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Palyi in view of Ohkawa, and further in view of Thakur (US 2007/0070906).
With respect to claims 4, 14 and 19, Palyi in view of Ohkawa discloses the method of claim 1, in response to the reason for packet loss being due to the link congestion (¶0006, teaches packet loss may occur due to congestion or due to other reasons, i.e. data corruption, ¶0040, teaches Packet loss is therefore always considered to be due to congestion. In the case of a detected packet loss, congestion action will be performed irrespective of the reason of the packet loss, ¶0054, teaches congestion control can be applied in both the uplink and downlink, i.e. high-speed uplink data packet access and high-speed downlink data packet access, respectively, Ohkawa, ¶0068, teaches a congestion state is detected from a packet loss, ¶0102, teaches the CPU 31 reads out a measure time period (a start time and an end time) for a connection (i.e. link congestion) determined to be subjected to first congestion control).
However, Palyi remain silent on wherein the controlling the flow of the network traffic includes reducing a size of a congestion window for the network traffic.
Thakur discloses wherein the controlling the flow of the network traffic includes reducing a size of a congestion window for the network traffic (¶0032, teaches the transmitting host 100 decreases the size of the congestion window 108 once the transmitting host 100 detects congestion on any of the TCP connections… In one implementation, if m TCP connections are established, and the size of the congestion window 108 is n bytes when congestion is detected, the transmitting host 100 reduces the size to the congestion 108 window by n/m bytes in response to congestion).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Palyi’s packet loss may occur due to congestion or due to other reasons and data packet loss is interpreted as congestion in the per-flow HSPA transport network congestion control with reducing a size of a congestion window for the network traffic of Thakur, in order to prevent packet loss, allow recovery and helps give other connections a fair chance (Thakur, ¶0037).
With respect to claim 5, Palyi in view of Ohkawa, and further in view of Thakur discloses the method of claim 4, wherein the reducing the size of the congestion window includes reducing the size of the congestion window by a multiplicative factor (Thakur, ¶0032, teaches the transmitting host 100 decreases the size of the congestion window 108 once the transmitting host 100 detects congestion on any of the TCP connections… In one implementation, if m TCP connections are established, and the size of the congestion window 108 is n bytes when congestion is detected, the transmitting host 100 reduces the size to the congestion 108 window by n/m bytes in response to congestion, ¶0038, teaches the fair share for a TCP connection (FSCON) is calculated to be the size of the congestion window (CWS) multiplied by the ratio (i.e. multiplicative factor) of the number of TCP segments that the TCP connection is ready to transfer into the common send queue (PRRCON) to the number of TCP segments that all of the established TCP connections are ready to transfer into the common send queue (PRRALL).
With respect to claim 9, Palyi in view of Ohkawa discloses the method of claim 1, however, Palyi remain silent on further comprising increasing an amount of the network traffic by increasing a size of a congestion window at an end node by a fixed amount, until the packet loss is detected.
Thakur discloses further comprising increasing an amount of the network traffic by increasing a size of a congestion window at an end node by a fixed amount, until the packet loss is detected (¶0007, teaches the transmitting host generally increases the size of its congestion window for a particular TCP connection if the transmitting host timely receives an ACK for an in-transit TCP segment on that TCP connection (e.g., within the retransmission timeout interval). However, if the transmitting host detects loss of data on a TCP connection (e.g., if an ACK for an in-transit TCP segment is not received within the retransmission timeout interval), ¶0008, teaches In the slow-start mechanism, the transmitting host initially sets the size of the congestion window for a new (or previously-idle) TCP connection to a “maximum segment size” (MSS) (i.e. fixed amount), i.e., the maximum number of bytes in a TCP segment. ¶0031, teaches After the first TCP connection is established between two hosts, the size of the congestion window 108 is incremented, e.g., by one MSS (or a multiple number of MSS, such as two or three MSS) each time an additional TCP connection is established between the two hosts).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Palyi’s packet loss may occur due to congestion or due to other reasons in view of Ohkawa’s system with increasing an amount of the network traffic by increasing a size of a congestion window at an end node by a fixed amount, until the packet loss is detected of Thakur, in order to keep the network balanced and avoid sudden congestion (Thakur, ¶0033).
With respect to claim 10, Palyi in view of Ohkawa, and further in view of Thakur discloses the method of claim 9, wherein the fixed amount is at least one Maximum Segment Size (MSS) for the congestion window (Thakur, ¶0008, teaches In the slow-start mechanism, the transmitting host initially sets the size of the congestion window for a new (or previously-idle) TCP connection to a “maximum segment size” (MSS) (i.e. fixed amount), i.e., the maximum number of bytes in a TCP segment).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Palyi in view of Ohkawa in view of Thakur, and further in view of Droz (US 6292466).
With respect to claim 6, Palyi in view of Ohkawa, and further in view of Thakur discloses the method of claim 5, however, Palyi in view of Thakur remain silent on wherein the multiplicative factor is at least a half or a quarter size of the congestion window.
Droz discloses wherein the multiplicative factor is at least a half or a quarter size of the congestion window (Col-14, II. 4-5, teaches a typical multiplication factor is ½).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Palyi’s in view of Ohkawa’s in view of Thakur’s the size of the congestion window (CWS) multiplied by the ratio (i.e. multiplicative factor) of the number of TCP segments with the multiplicative factor is at least a half or a quarter size of the congestion window of Droz, in order to ensure that competing flows back off equally and balance quick reaction with network efficiency and fairness (Droz).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GOLAM MAHMUD whose telephone number is (571)270-0385. The examiner can normally be reached Mon-Fri 8.00-5.00pm.
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, Umar Cheema can be reached on 5712703037. 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.
/GOLAM MAHMUD/Examiner, Art Unit 2458