DETAILED ACTION
Applicant’s Amendment filed on January 5, 2026 has been reviewed.
Claims 1, 4-5, 8, 11-12, 15 and 18-19 are amended in the amendment.
Claims 1-20 have been examined.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 5, 2026 has been entered.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, and further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun.
With respect to claim 1, Sridhar teaches A method for adjusting a bitrate for video streaming (maintaining a sustainable quality level for all adaptive bitrate streaming flows associated with users in congestion conditions, para. 0048), the method comprising:
determining whether there is network congestion for a packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
based on a determination that there is network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
setting congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
sending packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031);
applying an adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Sridhar does not explicitly teach
determining whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI) provided from a Media Access Control (MAC) Scheduler is lower than a CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value, or (iii) based on UE Assistance Information (UAI) reported by the UE;
based on a determination that there is network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header and
setting congestion state of a user IP to true;
sending packet;
applying an adaptive bitrate to adjust a quality based on the congestion state.
However, Munir teaches
determining whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value (congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100), or based on UE Assistance Information (UAI) reported by a user equipment (UE);
based on a determination that there is network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size, para. 0038) and
setting a congestion state of a user IP to true (the ECN filed set to either ‘10’ or ‘01’ to announce that the congestion control at the host supports ECN marking, para. 0039; the corresponding register bit set to ‘1’ to indicate that the queue size of the corresponding egress port is greater than a threshold (i.e., congestion exists), para. 0063-0064; also see para. 0038);
sending packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040);
applying an adaptive bitrate to adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the method of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir does not explicitly teach
determining whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value; and
However, Sun teaches
determining whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value (determining a quantity of the first UE for the Qi.sup.th resource pool scheduling allocation period based on a quantity of UE that is authorized for scheduling in the scheduling queue, a quantity of UE that is unauthorized for scheduling in the scheduling queue, and a quantity of UE whose transmission delay is greater than the congestion control delay threshold; when the congestion control policy is specifically used to instruct the first UE to adjust a current packet transmission period to a first packet transmission period in the measurement period, determining the first packet transmission period based on a quantity of UE that is authorized for scheduling in a scheduling queue and a quantity of UE that is unauthorized for scheduling in the scheduling queue, where the first packet transmission period is greater than the current packet transmission period, and UE in the scheduling queue is UE corresponding to the measurement period, para. 0080) in order to improve a congestion control effect as taught by Sun (para. 0030); and
Therefore, based on Sridhar in view of Munir, and further in view of Sun, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sun to the method of Sridhar in view of Munir in order to improve a congestion control effect as taught by Sun (para. 0030).
With respect to claim 8, Sridhar teaches An apparatus for adjusting the bitrate for video streaming (maintaining a sustainable quality level for all adaptive bitrate streaming flows associated with users in congestion conditions, para. 0048), the apparatus comprising:
a memory storing one or more instructions (processor, para. 0004); and
a processor operatively coupled to the memory and configured to execute the one or more instruction (processor, para. 0004);
wherein the one or more instruction, when executed by the processor (processor, para. 0004), cause the apparatus to:
determine whether there is network congestion for a packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
based on a determination that there is network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
set a congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
send packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031);
apply an adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Sridhar does not explicitly teach
determine whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI) provided from a Media Access Control (MAC) Scheduler is lower than a CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value, or (iii) based on UE Assistance Information (UAI) reported by the UE;
based on a determination that there is network congestion:
set an explicit congestion notification (ECN) bit in an IP packet header and
set a congestion state of a user IP to true;
send packet;
apply an adaptive bitrate to adjust a quality based on the congestion state.
However, Munir teaches
determine whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI) provided from a Media Access Control (MAC) Scheduler is lower than a CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value (congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100), or based on UE Assistance Information (UAI) reported by a user equipment (UE);
based on a determination that there is network congestion:
set an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size, para. 0038) and
set a congestion state of a user IP to true (the ECN filed set to either ‘10’ or ‘01’ to announce that the congestion control at the host supports ECN marking, para. 0039; the corresponding register bit set to ‘1’ to indicate that the queue size of the corresponding egress port is greater than a threshold (i.e., congestion exists), para. 0063-0064; also see para. 0038);
send packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040);
apply an adaptive bitrate to adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the apparatus of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir does not explicitly teach
determine whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value; and
However, Sun teaches
determine whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value (determining a quantity of the first UE for the Qi.sup.th resource pool scheduling allocation period based on a quantity of UE that is authorized for scheduling in the scheduling queue, a quantity of UE that is unauthorized for scheduling in the scheduling queue, and a quantity of UE whose transmission delay is greater than the congestion control delay threshold; when the congestion control policy is specifically used to instruct the first UE to adjust a current packet transmission period to a first packet transmission period in the measurement period, determining the first packet transmission period based on a quantity of UE that is authorized for scheduling in a scheduling queue and a quantity of UE that is unauthorized for scheduling in the scheduling queue, where the first packet transmission period is greater than the current packet transmission period, and UE in the scheduling queue is UE corresponding to the measurement period, para. 0080) in order to improve a congestion control effect as taught by Sun (para. 0030); and
Therefore, based on Sridhar in view of Munir, and further in view of Sun, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sun to the apparatus of Sridhar in view of Munir in order to improve a congestion control effect as taught by Sun (para. 0030).
With respect to claim 15, Sridhar teaches A non-transitory computer-readable recording medium having recorded thereon instructions to perform a method (non-transitory computer-readable storage medium stores instructions to perform a corresponding method, para. 0004) comprising:
determining whether there is network congestion for a packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
based on a determination that there is network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
setting a congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
sending packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031);
applying an adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Sridhar does not explicitly teach
determining whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI) provided from a Media Access Control (MAC) Scheduler is lower than a CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value, or (iii) based on UE Assistance Information (UAI) reported by the UE;
based on a determination that there is network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header and
setting a congestion state of a user IP to true;
sending packet;
applying an adaptive bitrate to adjust a quality based on the congestion state.
However, Munir teaches
determining whether there is network congestion for a packet (i) based on whether a filtered cell quality indicator (CQI) provided from a Media Access Control (MAC) Scheduler is lower than a CQI threshold value, (ii) based on whether a radio link control (RLC) scheduling queue delay between the RLC and the MAC scheduler is greater than a queue delay threshold value (congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100), or (iii) based on UE Assistance Information (UAI) reported by the UE;
based on a determination that there is network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size, para. 0038) and
setting a congestion state of a user IP to true (the ECN filed set to either ‘10’ or ‘01’ to announce that the congestion control at the host supports ECN marking, para. 0039; the corresponding register bit set to ‘1’ to indicate that the queue size of the corresponding egress port is greater than a threshold (i.e., congestion exists), para. 0063-0064; also see para. 0038);
sending packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040);
applying an adaptive bitrate to adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the medium of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir does not explicitly teach
determining whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value; and
However, Sun teaches
determining whether there is no longer network congestion for the packet based on whether a scheduling queue delay of the UE is greater than the queue delay recovery threshold value (determining a quantity of the first UE for the Qi.sup.th resource pool scheduling allocation period based on a quantity of UE that is authorized for scheduling in the scheduling queue, a quantity of UE that is unauthorized for scheduling in the scheduling queue, and a quantity of UE whose transmission delay is greater than the congestion control delay threshold; when the congestion control policy is specifically used to instruct the first UE to adjust a current packet transmission period to a first packet transmission period in the measurement period, determining the first packet transmission period based on a quantity of UE that is authorized for scheduling in a scheduling queue and a quantity of UE that is unauthorized for scheduling in the scheduling queue, where the first packet transmission period is greater than the current packet transmission period, and UE in the scheduling queue is UE corresponding to the measurement period, para. 0080) in order to improve a congestion control effect as taught by Sun (para. 0030); and
Therefore, based on Sridhar in view of Munir, and further in view of Sun, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sun to the medium of Sridhar in view of Munir in order to improve a congestion control effect as taught by Sun (para. 0030).
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and in view of Connor et al. (US 2020/0177660 A1), hereinafter referred to as Connor, and furthermore in view of Yang et al. (US 2025/0081033 A1), hereinafter referred to as Yang.
With respect to claim 2, Sridhar in view of Munir, and further in view of Sun teaches The method of claim 1 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet, and.
However, Connor teaches wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet (adding streaming headers such as RTP-related headers in a packet and to pace traffic transmission according to the applicable streaming control protocol over quick Internet Connections (QUIC) and A TCP protocol header can be formed and appended to the combination, para. 0044) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001), and
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the method of Sridhar in view of Munir in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor does not explicitly teach the packet is sent to Packet Data Convergence Protocol (PDCP).
However, Yang teaches the packet is sent to Packet Data Convergence Protocol (PDCP) (the CU mark packet headers of Packet Data Convergence Protocol (PDCP) packets with the generated ECN, para. 0014) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Connor, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the method of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
With respect to claim 9, Sridhar in view of Munir, and further in view of Sun teaches The apparatus of claim 8 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet, and.
However, Connor teaches wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet (adding streaming headers such as RTP-related headers in a packet and to pace traffic transmission according to the applicable streaming control protocol over quick Internet Connections (QUIC) and A TCP protocol header can be formed and appended to the combination, para. 0044) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001), and
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the apparatus of Sridhar in view of Munir, and further in view of Sun in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor does not explicitly teach the packet is sent to Packet Data Convergence Protocol (PDCP).
However, Yang teaches the packet is sent to Packet Data Convergence Protocol (PDCP) (the CU mark packet headers of Packet Data Convergence Protocol (PDCP) packets with the generated ECN, para. 0014) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
Therefore, based on Sridhar in view of Munir, and further in view of Sun, and in view of Connor, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the apparatus of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
With respect to claim 16, Sridhar in view of Munir, and further in view of Sun teaches The non-transitory computer-readable recording medium of claim 15 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet, and the packet is sent to Packet Data Convergence Protocol (PDCP).
However, Connor teaches wherein the packet is a non-guaranteed bitrate bearer downlink TCP-QUIC packet (adding streaming headers such as RTP-related headers in a packet and to pace traffic transmission according to the applicable streaming control protocol over quick Internet Connections (QUIC) and A TCP protocol header can be formed and appended to the combination, para. 0044) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001), and.
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the medium of Sridhar in view of Munir, and further in view of Sun in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor does not explicitly teach the packet is sent to Packet Data Convergence Protocol (PDCP).
However, Yang teaches the packet is sent to Packet Data Convergence Protocol (PDCP) (the CU mark packet headers of Packet Data Convergence Protocol (PDCP) packets with the generated ECN, para. 0014) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Connor, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the medium of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and furthermore in view of Connor et al. (US 2020/0177660 A1), hereinafter referred to as Connor.
With respect to claim 3, Sridhar in view of Munir, and further in view of Sun teaches The method of claim 1 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the IP packet header is IPV4, and wherein based on a determination that there is network congestion, the method further comprises recalculating a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink.
However, Connor teaches wherein the IP packet header is IPV4 (header includes IPv4 field, para. 0049), and wherein based on a determination that there is network congestion, the method further comprises recalculating a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink (timestamps and data verification fields (e.g., checksums) as fields in a packet are updated prior to transmission and recalculated by the network interface; a checksum can be generated over a portion of a packet (e.g., packet and/or header), para. 0046) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the method of Sridhar in view of Munir, and further in view of Sun in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
With respect to claim 10, Sridhar in view of Munir, and further in view of Sun teaches The apparatus of claim 8 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the IP packet header is IPV4, and wherein based on a determination that there is network congestion, the apparatus is further configured to recalculate a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink.
However, Connor teaches wherein the IP packet header is IPV4 (header includes IPv4 field, para. 0049), and wherein based on a determination that there is network congestion, the method further comprises recalculating a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink (timestamps and data verification fields (e.g., checksums) as fields in a packet are updated prior to transmission and recalculated by the network interface; a checksum can be generated over a portion of a packet (e.g., packet and/or header), para. 0046) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the apparatus of Sridhar in view of Munir, and further in view of Sun in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
With respect to claim 17, Sridhar in view of Munir, and further in view of Sun teaches The non-transitory computer-readable recording medium of claim 15 as described above,
Sridhar in view of Munir, and further in view of Sun does not explicitly teach wherein the IP packet header is IPV4, and wherein based on a determination that there is network congestion, the method further comprises recalculating a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink.
However, Connor teaches wherein the IP packet header is IPV4 (header includes IPv4 field, para. 0049), and wherein based on a determination that there is network congestion, the method further comprises recalculating a checksum in uplink towards a carrier grade network address translator (CGNAT) for the UE which is scheduled for downlink (timestamps and data verification fields (e.g., checksums) as fields in a packet are updated prior to transmission and recalculated by the network interface; a checksum can be generated over a portion of a packet (e.g., packet and/or header), para. 0046) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the medium of Sridhar in view of Munir, and further in view of Sun in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and furthermore in view of Yang et al. (US 2025/0081033 A1), hereinafter referred to as Yang.
With respect to claim 4, Sridhar teaches The method of claim 1,
wherein the determining whether there is no network congestion for a packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
wherein the method further comprises:
based on a determination that there is no network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
setting the congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
sending the packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031); and
applying adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Further, Munir teaches
wherein the determining whether there is no network congestion for a packet (congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100);
wherein the method further comprises:
based on a determination that there is no network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075) and
setting the congestion state of a user IP to true (the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075);
sending the packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040); and
adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the method of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir, and further in view of Sun does not explicitly teach
wherein the determining whether there is no longer network congestion for the packet is further based on whether the filtered CQI is greater than a cell quality recovery threshold value;
However, Yang teaches
wherein the determining whether there is no longer network congestion for the packet is further based on whether the filtered CQI is greater than a cell quality recovery threshold value (the signal strength or quality parameter value may include a Channel Quality Indicator (CQI) value, the congestion notification sent from the DU to the CU include an indication that a loading parameter value for a base station associated with the UE device is above a quality threshold, para. 0015; quality thresholds is determined a congestion condition, para. 0046) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014);
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the method of Sridhar in view of Munir, and further in view of Sun in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
With respect to claim 11, Sridhar teaches The apparatus of claim 8, wherein
the determination(the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
wherein the one or more instructions, when executed by the processor, further cause the apparatus to:
based on a determination that there is no network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
setting the congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
send the packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031), and
apply adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Further, Munir teaches
the determination(congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100);
wherein the one or more instructions, when executed by the processor, further cause the apparatus to:
based on a determination that there is no network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075), and
setting the congestion state of a user IP to false (the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075),
send the packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040), and
adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the apparatus of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir, and further in view of Sun does not explicitly teach
the determination
However, Yang teaches
the determination(the signal strength or quality parameter value may include a Channel Quality Indicator (CQI) value, the congestion notification sent from the DU to the CU include an indication that a loading parameter value for a base station associated with the UE device is above a quality threshold, para. 0015; quality thresholds is determined a congestion condition, para. 0046) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014),
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the apparatus of Sridhar in view of Munir, and further in view of Sun in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
With respect to claim 18, Sridhar teaches The non-transitory computer-readable recording medium of claim 15, wherein
wherein the determining whether there is no network congestion for a packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
wherein the method further comprises:
based on a determination that there is no network congestion (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048):
setting the congestion state (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; determining the target flow rate of the adaptive bitrate streaming flow based on at least one of a cell congestion status, para. 0048; claim 3);
sending the packet (the adaptive bitrate streaming flows identified based on information included in packet headers of packets of the adaptive bitrate streaming flows, information included in packet payloads of packets of the adaptive bitrate streaming flows, para. 041; to ensure a consistent level of QoE under congestion conditions by ensuring that the amount of data in each chunk is delivered within each chunk time period and to determine whether transmission scheduling events represent a good or poor channel quality, para. 0031); and
applying adaptive bitrate to adjust a quality of a video stream based on the congestion state (the target flow rate for the adaptive bitrate streaming flow modified dynamically over time (e.g., the target flow rate for the adaptive bitrate streaming flow may be reduced gradually as the congestion level increases and increased as the congestion level decreases), para. 0048).
Further, Munir teaches
wherein the determining whether there is no network congestion for a packet (congestion feedback performed by marking packet headers based on an egress queue size; in the context of ECN, a packet header comprise two ECN fields for marking; in case of congestion, the one or more ECN field in the packet header marked based on the egress queue size; the size of outgoing queue (egress que size) at switch 108 is larger than a certain value or a threshold, then the ECN field of the packet header may be set to ‘11’; the markings (in the case of ECN, ECN marking) indicate congestion information, para. 0038; also see para. 0100);
wherein the method further comprises:
based on a determination that there is no network congestion:
setting an explicit congestion notification (ECN) bit in an IP packet header (a header of the second packet include marking according to one of: explicit congestion notification (ECN), para. 0013; the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075) and
setting the congestion state of a user IP to true (the value of the corresponding bit indicated no congestion at the first egress port, then, in an aspect, the switch may not mark the second packet (e.g., change ECN field) to ‘0’, thereby indicating no congestion at the first egress port (e.g., egress queue is less than the threshold), para. 0075);
sending the packet (when the packet 104 arrives at destination 106, the receiver copy the congestion information indicated by the header marking into a header of an acknowledgement (ACK) packet 114 that carry the congestion information back to the source 102, e.g., congestion feedback; once the source 102 receives the information, the source change condition window size, change the sending rate, etc, para. 0040); and
adjust a quality based on the congestion state (the congestion information (e.g., ECN information) received from the second packet 414 used to control the congestion window size or rate of the outgoing traffic, para. 0078; also see para. 0040) in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Therefore, based on Sridhar in view of Munir, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Munir to the medium of Sridhar in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Sridhar in view of Munir, and further in view of Sun does not explicitly teach
wherein the determining whether there is no longer network congestion for the packet is further based on whether the filtered CQI is greater than a cell quality recovery threshold value;
However, Yang teaches
wherein the determining whether there is no longer network congestion for the packet is further based on whether the filtered CQI is greater than a cell quality recovery threshold value (the signal strength or quality parameter value may include a Channel Quality Indicator (CQI) value, the congestion notification sent from the DU to the CU include an indication that a loading parameter value for a base station associated with the UE device is above a quality threshold, para. 0015; quality thresholds is determined a congestion condition, para. 0046) in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014);
Therefore, based on Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Yang to the medium of Sridhar in view of Munir, and further in view of Sun in order to quickly and efficiently respond to the congestion condition by adjusting a data rate such as reduce the data rate as taught by Yang (para. 0014).
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and in view of Yang et al. (US 2025/0081033 A1), hereinafter referred to as Yang, and furthermore in view of Fu et al. (US 2023/0362707 A1), hereinafter referred to as Fu.
With respect to claim 5, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The method of claim 4 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit
However, Fu teaches
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit (air interface delay, which refers to a time interval from transmission time indicated by a scheduling grant (grant) to successfully receiving a transmitted data block; Radio Link Control (RLC) delay, which refers to a time interval from an RLC layer receiving an RLC Protocol Data Unit (PDU) containing the first RLC Service Data Unit (SDU) to the RLC layer delivering the RLC SDU to the PDCP layer, para. 0056-0063) in order to ensure transmission performance as taught by Fu (para. 0071)
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Fu, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Fu to the method of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to ensure transmission performance as taught by Fu (para. 0071).
With respect to claim 12, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The apparatus of claim 11 as described above, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit
However, Fu teaches
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit (air interface delay, which refers to a time interval from transmission time indicated by a scheduling grant (grant) to successfully receiving a transmitted data block; Radio Link Control (RLC) delay, which refers to a time interval from an RLC layer receiving an RLC Protocol Data Unit (PDU) containing the first RLC Service Data Unit (SDU) to the RLC layer delivering the RLC SDU to the PDCP layer, para. 0056-0063) in order to ensure transmission performance as taught by Fu (para. 0071)
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Fu, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Fu to the apparatus of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to ensure transmission performance as taught by Fu (para. 0071).
With respect to claim 19, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The non-transitory computer-readable recording medium of claim 18 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit
However, Fu teaches
wherein the scheduling queue delay indicates a delay of a RLC Protocol Data Unit (air interface delay, which refers to a time interval from transmission time indicated by a scheduling grant (grant) to successfully receiving a transmitted data block; Radio Link Control (RLC) delay, which refers to a time interval from an RLC layer receiving an RLC Protocol Data Unit (PDU) containing the first RLC Service Data Unit (SDU) to the RLC layer delivering the RLC SDU to the PDCP layer, para. 0056-0063) in order to ensure transmission performance as taught by Fu (para. 0071)
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Fu, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Fu to the medium of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to ensure transmission performance as taught by Fu (para. 0071).
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and in view of Yang et al. (US 2025/0081033 A1), hereinafter referred to as Yang, and furthermore in view of Uchino et al. (US 2025/0097768 A1), hereinafter referred to as Uchino.
With respect to claim 6, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The method of claim 4 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE.
However, Uchino teaches wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE (a DU of a network node (e.g., the network node 110) includes means for receiving, from one or more of a UE, assistance information, wherein the assistance information indicates congestion related information, para. 0055) in order to improve the overall system performance as taught by Uchino (para. 0027).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Uchino, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Uchino to the method of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
With respect to claim 13, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The apparatus of claim 11 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE.
However, Uchino teaches wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE (a DU of a network node (e.g., the network node 110) includes means for receiving, from one or more of a UE, assistance information, wherein the assistance information indicates congestion related information, para. 0055) in order to improve the overall system performance as taught by Uchino (para. 0027).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Uchino, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Uchino to the apparatus of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
With respect to claim 20, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The non-transitory computer-readable recording medium of claim 18 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE.
However, Uchino teaches wherein determining whether there is no longer network congestion for the packet is further based on UAI reported by the UE (a DU of a network node (e.g., the network node 110) includes means for receiving, from one or more of a UE, assistance information, wherein the assistance information indicates congestion related information, para. 0055) in order to improve the overall system performance as taught by Uchino (para. 0027).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Uchino, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Uchino to the medium of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to improve throughput and reduce latency for solving congestion as taught by Munir (para. 0013).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Sridhar et al. (US 2018/0109468 A1), hereinafter referred to as Sridhar, in view of Munir et al. (US 2024/0163220 A1), hereinafter referred to as Munir, further in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun, and in view of Yang et al. (US 2025/0081033 A1), hereinafter referred to as Yang, and furthermore in view of Connor et al. (US 2020/0177660 A1), hereinafter referred to as Connor.
With respect to claim 7, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The method of claim 4 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach wherein the IP packet header is IPV4, and wherein based on a determination that there is no longer network congestion, the method further comprises recalculating a checksum in uplink towards a user plane function (UPF) for the UE which is scheduled for downlink.
However, Connor teaches wherein the IP packet header is IPV4, and wherein based on a determination that there is no longer network congestion, the method further comprises recalculating a checksum in uplink towards a user plane function (UPF) for the UE which is scheduled for downlink (timestamps and data verification fields (e.g., checksums) as fields in a packet are updated prior to transmission and recalculated by the network interface; a checksum can be generated over a portion of a packet (e.g., packet and/or header), para. 0046) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the method of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
With respect to claim 14, Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang teaches The method of claim 11 as described above,
Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang does not explicitly teach wherein the IP packet header is IPV4, and wherein based on a determination that there is no longer network congestion, the apparatus is further configured to recalculate a checksum in uplink towards a user plane function (UPF) for the UE which is scheduled for downlink.
However, Connor teaches wherein the IP packet header is IPV4, and wherein based on a determination that there is no longer network congestion, the method further comprises recalculating a checksum in uplink towards a user plane function (UPF) for the UE which is scheduled for downlink (timestamps and data verification fields (e.g., checksums) as fields in a packet are updated prior to transmission and recalculated by the network interface; a checksum can be generated over a portion of a packet (e.g., packet and/or header), para. 0046) in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Therefore, based on Sridhar in view of Munir, further in view of Sun, and in view of Yang, and furthermore in view of Connor, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Connor to the apparatus of Sridhar in view of Munir, further in view of Sun, and furthermore in view of Yang in order to facilitate real-time control of the media streaming from the server to a client such as video-on-demand as taught by Connor (para. 0001).
Response to Arguments
Applicant's arguments, filed on January 5, 2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 103 have been fully considered but are moot in view of the new ground(s) of rejection is made in view of Sun et al. (US 2019/0174349 A1), hereinafter referred to as Sun.(See the new ground(s) of rejection set forth herein above).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO HONG NGUYEN whose telephone number is (571)272-2666. The examiner can normally be reached on Monday-Friday 8AM-4:30PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H. Hwang can be reached on (571)272-40364036. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.H.N/Examiner, Art Unit 2447
January 24, 2026
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447