Prosecution Insights
Last updated: April 19, 2026
Application No. 18/798,544

REAL-TIME TRANSPORT PROTOCOL HEADER EXTENSION FOR THE REMAINING PROTOCOL DATA UNIT SET SIZE

Non-Final OA §102§103§112
Filed
Aug 08, 2024
Examiner
HACKENBERG, RACHEL J
Art Unit
2454
Tech Center
2400 — Computer Networks
Assignee
Qualcomm Incorporated
OA Round
1 (Non-Final)
79%
Grant Probability
Favorable
1-2
OA Rounds
2y 10m
To Grant
99%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allow Rate
236 granted / 300 resolved
+20.7% vs TC avg
Strong +26% interview lift
Without
With
+26.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
35 currently pending
Career history
335
Total Applications
across all art units

Statute-Specific Performance

§101
4.9%
-35.1% vs TC avg
§103
53.2%
+13.2% vs TC avg
§102
14.2%
-25.8% vs TC avg
§112
17.8%
-22.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 300 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Information Disclosure Statement The information disclosure statement (IDS) was submitted on 10/30/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. Claim(s) 2-3, 13-14, 20, 23-24, 28-29 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 2 recites the limitation "those PDUs of the PDU set" in line 2. This renders the claim unclear as there is insufficient antecedent basis for this limitation in the claim. It is unclear as to what “those” refers back to. This same rejection applies to Claims 3, 13-14, 23-24, 28-29. Claim 2 recites the limitation "the current PDU" in lines 1-2. This renders the claim unclear as there is insufficient antecedent basis for this limitation in the claim. Previous limitations do not recite “a current PDU”. This same rejection applies to Claims 3, 13-14, 23-24, 28-29. Claim 20 recites the limitation "the PDU sequence number of the second RTP packet is greater than the PDU sequence number of the first RTP packet by 1" in lines 8-9. This renders the claim unclear as there is insufficient antecedent basis for this limitation in the claim. Previous limitations do not recite “a PDU sequence number of the second RTP packet”, “a PDU sequence number of the first RTP packet”. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claim(s) 1-11, 22-26 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2024/0259454 Al (provisional 63/441,279 priority date 01/26/2023)(Kammachi). Regarding Claim 1: Kammachi teaches A method comprising: determining a protocol data unit (PDU) set, the PDU set comprising a plurality of PDUs, each PDU comprising a corresponding real-time transport protocol (RTP) packet; ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) determining, for a current RTP packet (ie. first packet) of the PDU set, a remaining PDU set size, the remaining PDU set size being indicative of a size of a sum of a remainder of the PDUs of the PDU set; ([0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) and transmitting the current RTP packet, the current RTP packet comprising an RTP header extension comprising a value indicative of the remaining PDU set size. ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212. [0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claim 22: Kammachi teaches A computing device comprising: one or more memories configured to store a real-time transport protocol (RTP) packet; and one or more processors coupled to the one or more memories ([0461] Example 15. An apparatus includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive as input a protocol data unit set containing one or more protocol data units; wherein the one or more protocol data units carry one or more levels of priority information; [0548] The memory(ies) may comprise a database for storing data.), the one or more processors being configured to: determine a protocol data unit (PDU) set, the PDU set comprising a plurality of PDUs, each PDU comprising a corresponding RTP packet; ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) determine, for a current RTP packet of the PDU set, a remaining PDU set size, the remaining PDU set size being indicative of a size of a sum of a remainder of the PDUs of the PDU set; ([0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) and transmit the current RTP packet, the current RTP packet comprising an RTP header extension comprising a value indicative of the remaining PDU set size. ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212. [0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claims 2, 23: Kammachi teaches on the inventions of claims 1, 22 as described. Kammachi teaches wherein the remainder of the PDUs comprises the current PDU and those PDUs of the PDU set to be transmitted after the current PDU, wherein the current PDU corresponds to the current RTP packet. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claims 3, 24: Kammachi teaches on the inventions of claims 1, 22 as described. Kammachi teaches wherein the remainder of the PDUs comprises those PDUs of the PDU set to be transmitted after the current PDU. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claims 4, 25: Kammachi teaches on the inventions of claims 1, 22 as described. Kammachi teaches wherein the value indicative of the remaining PDU set size comprises a number of bytes. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claim 5: Kammachi teaches on the invention of claim 1 as described. Kammachi teaches wherein the RTP header extension further comprises a header extension element header having a length of at least one-byte. ([0420] a RTP header extension (two types of RTP header extensions are shown, 2102-1 and 2102-2) of an RTP header 2100 for signaling PDU set dependency information and PDU set priority is illustrated in FIG. 21, and a similar RTP header extension 2202 of an RTP header 2200 is shown in FIG. 22. The RTP header extensions (2102-1, 2102-2, 2202) have the following semantics.) Figs 21, 22: Elements in these headers are at least one byte. Regarding Claim 6: Kammachi teaches on the invention of claim 5 as described. Kammachi teaches wherein the header extension element header comprises an identifier and a length indicator, wherein the identifier is indicative of the RTP header extension including the value indicative of the remaining PDU set size, and wherein the length indicator is indicative of the length of the header extension element. ([0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. In another embodiment, a value for ID is fixed, and the value cannot be negotiated with a network element using SDP. [0422] L: length minus one of the extension element. This value may be set to 14. 15 bytes of data may not be needed. In FIG. 22, L is set to 6.) Regarding Claim 7: Kammachi teaches on the invention of claim 5 as described. Kammachi teaches wherein the header extension element header comprises an identifier and a length indicator, wherein the identifier is indicative of the RTP header extension including the value indicative of a PDU set size re-interpreted as the remaining PDU Set Size, and wherein the length indicator is indicative of the length of the header extension element. ([0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. [0422] L: length minus one of the extension element. This value may be set to 14. 15 bytes of data may not be needed. In FIG. 22, L is set to 6. [0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claims 8, 26: Kammachi teaches on the inventions of claims 1, 22 as described. Kammachi teaches further comprising prior to transmitting the RTP packet, negotiating, by a first computing device with a second computing device, the use of the RTP header extension. ([0339] The PDUs in a PDU set may carry the length information of the PDU headers, for example the length of the PDU set RTP header extension. The length of the RTP header extension may be fixed or dynamic. For the dynamic length case, the length depends on the specific fields used in the RTP HE. The extension attribute is negotiated during SDP exchange and the length remains fixed for the duration of the session or at least until another SDP exchange takes place to change the length. [0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. [0422] L: length minus one of the extension element.) Regarding Claim 9: Kammachi teaches on the invention of claim 8 as described. Kammachi teaches wherein negotiating the use of the RTP header extension comprises negotiating re-interpretation of a PDU set size to the remaining PDU set size. ([0339] The PDUs in a PDU set may carry the length information of the PDU headers, for example the length of the PDU set RTP header extension. The length of the RTP header extension may be fixed or dynamic. For the dynamic length case, the length depends on the specific fields used in the RTP HE. The extension attribute is negotiated during SDP exchange and the length remains fixed for the duration of the session or at least until another SDP exchange takes place to change the length. [0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. [0422] L: length minus one of the extension element.) Regarding Claim 10: Kammachi teaches on the invention of claim 1 as described. Kammachi further comprising determining a count of a number PDUs in the PDU set, wherein the RTP header extension further comprises the count of the number of PDUs in the PDU set. ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) Regarding Claim 11: Kammachi teaches on the invention of claim 1 as described. Kammachi teaches wherein the remaining PDU set size is a first remaining PDU set size and the RTP header extension is a first RTP header extension, ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) the method further comprising: determining, for a second RTP packet of the PDU set, a second remaining PDU set size, the second remaining PDU set size being indicative of the size of the sum of the remainder of the PDUs of the PDU set minus a size of a first PDU; ([0336] The PDUs following the first PDU in a PDU set may carry the PDU count in a decreasing order of the count value. For example, a PDU set has N PDUs, the first PDU carries the value of N for the PDU count and the second PDU carries the value of N-1 for the PDU count until the last PDU which carries the value of 1 for the PDU count. [0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set. … PSSize is the same set of bytes that either represents the PDU set size in bytes (when S=l) or the number of PDUs remaining in the current PDU set (when S=0).) and transmitting the second RTP packet, the second RTP packet comprising a second RTP header extension comprising a value indicative of the second remaining PDU set size. ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212. [0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 12-19, 21, 27-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over the provisional 63/441,279 of US 2024/0259454 Al (Kammachi) in view of US 2025/0008508 Al (Wu). Regarding Claim 12: Kammachi teaches A method comprising: receiving, by a first computing device, a current real-time transport protocol (RTP) packet, ([0166] In accordance with the examples described herein, one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212. [0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) the current RTP packet comprising a protocol data unit (PDU) of a PDU set and comprising an RTP header extension comprising a value indicative of a remaining PDU set size, ([0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) the remaining PDU set size being indicative of a size of a sum of a remainder of the PDUs of the PDU set; ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) and allocating, by the first computing device, resources (ie. data channel) for the remainder of the PDUs ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212.) Kammachi teaches on transmitting the remaining RTP packets via resources ([0166]). However, Wu teaches allocating, by the first computing device, resources for the remainder of the PDUs based on the remaining PDU set size. Wu teaches, in the same field of endeavor, determining a remaining PDB of a data packet in a buffer, and reporting related information of the remaining PDB to a base station, Abstract. Wu also teaches allocating, by the first computing device, resources for the remainder of the PDUs based on the remaining PDU set size. ([0303]-[0305] Fig 15, Step S301: determining a remaining packet delay bucket (PDB) of a data packet in a buffer of an logical channel (LCH). The determination of the remaining PDB of a data packet may be implemented by the UE. Step S302: selecting an LCH and allocating resources for an uplink scheduling, based on the remaining PDB.) remaining packet delay bucket = remaining size. It would have been obvious to a person having ordinary skill the art before the effective filing of the claim invention, to modify Kammachi per Wu to include allocate resources for the remainder of the PDUs based on the remaining PDU set size. This would have been advantageous as discussed above, as it would allow the modified system to provide sufficient resources while dynamically load balancing. Regarding Claim 27: Kammachi teaches A computing device comprising: one or more memories configured to store a real-time transport protocol (RTP) packet; and one or more processors coupled to the one or more memories ([0461] Example 15. An apparatus includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive as input a protocol data unit set containing one or more protocol data units; wherein the one or more protocol data units carry one or more levels of priority information; [0548] The memory(ies) may comprise a database for storing data.), the one or more processors being configured to: receive a current RTP packet, ([0166] In accordance with the examples described herein, one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212. [0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) the current RTP packet comprising a protocol data unit (PDU) of a PDU set and comprising an RTP header extension comprising a value indicative of a remaining PDU set size, ([0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) the remaining PDU set size being indicative of a size of a sum of a remainder of the PDUs of the PDU set; ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) and allocate resources (ie. data channel) for the remainder of the PDUs ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212.) Kammachi teaches on transmitting the remaining RTP packets via resources ([0166]). However, Wu teaches allocate resources for the remainder of the PDUs based on the remaining PDU set size. Wu teaches allocate resources for the remainder of the PDUs based on the remaining PDU set size. ([0303]-[0305] Fig 15, Step S301: determining a remaining packet delay bucket (PDB) of a data packet in a buffer of an logical channel (LCH). The determination of the remaining PDB of a data packet may be implemented by the UE. Step S302: selecting an LCH and allocating resources for an uplink scheduling, based on the remaining PDB.) remaining packet delay bucket = remaining size. It would have been obvious to a person having ordinary skill the art before the effective filing of the claim invention, to modify Kammachi per Wu to include allocate resources for the remainder of the PDUs based on the remaining PDU set size. This would have been advantageous as discussed above, as it would allow the modified system to provide sufficient resources while dynamically load balancing. Regarding Claims 13, 28: Kammachi (as modified by Wu) teaches on the inventions of claims 12, 27 as described. Kammachi teaches wherein the remainder of the PDUs comprises the current PDU and those PDUs of the PDU set to be transmitted after the current PDU, wherein the current PDU corresponds to the current RTP packet. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claims 14, 29: Kammachi (as modified by Wu) teaches on the inventions of claims 12, 27 as described. Kammachi teaches wherein the remainder of the PDUs comprises those PDUs of the PDU set to be transmitted after the current PDU. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claim 15: Kammachi (as modified by Wu) teaches on the invention of claim 12 as described. Kammachi teaches wherein the remaining PDU set size comprises a number of bytes. ([0428] PS Size corresponds to PDUSetSize: the size in bytes of all PDUs of the PDU set, excluding RTP headers and header extensions, effectively conveying the size of the media data of that PDU Set. Alternatively, the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set.) Regarding Claim 16: Kammachi (as modified by Wu) teaches on the invention of claim 12 as described. Kammachi teaches wherein the RTP header extension comprises a header extension element header having a length of at least one-byte. ([0420] In another example implementation embodiment, a RTP header extension (two types of RTP header extensions are shown, 2102-1 and 2102-2) of an RTP header 2100 for signaling PDU set dependency information and PDU set priority is illustrated in FIG. 21, and a similar RTP header extension 2202 of an RTP header 2200 is shown in FIG. 22. The RTP header extensions (2102-1, 2102-2, 2202) have the following semantics.) Figs 21, 22: Elements in these headers are at least one byte. Regarding Claim 17: Kammachi (as modified by Wu) teaches on the invention of claim 16 as described. Kammachi teaches wherein the header extension element header comprises an identifier and a length indicator, wherein the identifier is indicative of the RTP header extension including the value indicative of the remaining PDU set size, and wherein the length indicator is indicative of the length of the header extension element. ([0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. In another embodiment, a value for ID is fixed, and the value cannot be negotiated with a network element using SDP. [0422] L: length minus one of the extension element. This value may be set to 14. 15 bytes of data may not be needed. In FIG. 22, L is set to 6.) Regarding Claims 18, 30: Kammachi (as modified by Wu) teaches on the inventions of claims 12, 27 as described. Kammachi teaches further comprising prior to transmitting the RTP packet, negotiating, by a first computing device with a second computing device, the use of the RTP header extension. ([0339] The PDUs in a PDU set may carry the length information of the PDU headers, for example the length of the PDU set RTP header extension. The length of the RTP header extension may be fixed or dynamic. For the dynamic length case, the length depends on the specific fields used in the RTP HE. The extension attribute is negotiated during SDP exchange and the length remains fixed for the duration of the session or at least until another SDP exchange takes place to change the length. [0421] ID: identifier of the one-byte extension element. This identifier shall be negotiated using the SDP extmap attribute. [0422] L: length minus one of the extension element.) Regarding Claim 19: Kammachi (as modified by Wu) teaches on the invention of claim 12 as described. Kammachi teaches wherein the RTP header extension further comprises a count of a number of PDUs in the PDU set. ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes. ) Regarding Claim 21: Kammachi (as modified by Wu) teaches on the invention of claim 12 as described. Kammachi teaches wherein the remaining PDU set size is a first remaining PDU set size and the RTP header extension is a first RTP header extension, ([0336]-[0338] Identifying PDUs in a PDU Set: the first PDU in the PDU set may optionally carry the value of PDU count or PDU sequence number in the PDU set information, for example as part of the RTP header extension. The first PDU in a PDU set may carry information, for example as part of the RTP header extension, of the size of the PDU set in bytes.) the method further comprising: receiving, by the first computing device, a second RTP packet of the PDU set, comprising a second RTP header extension comprising a value indicative of a second remaining PDU set size, the second remaining PDU set size being indicative of the size of the sum of the remainder of the PDUs of the PDU set minus a size of the second RTP packet a remaining PDU set size; ([0336] The PDUs following the first PDU in a PDU set may carry the PDU count in a decreasing order of the count value. For example, a PDU set has N PDUs, the first PDU carries the value of N for the PDU count and the second PDU carries the value of N-1 for the PDU count until the last PDU which carries the value of 1 for the PDU count. [0412] The RTP HE can have a start bit that indicates that the PDU is the first in a PDU set followed by the number of PDUs remaining in the PDU set. For the first PDU in the PDU set, the start bit is set to 1, and the remaining PDU counter is set appropriately. [0428] PS Size corresponds to PDUSetSize: … the PS Size may indicate the number of bytes still to come in the PDU set in which case PSSize will indicate the remaining bytes of the PDU set. … PSSize is the same set of bytes that either represents the PDU set size in bytes (when S=l) or the number of PDUs remaining in the current PDU set (when S=0).)) and allocating, by the first computing device, resources for the current RTP packet ([0166] one or more PDU sets (216-1, 216-2) are transmitted and received over the data channel 212.) Kammachi teaches on transmitting the remaining RTP packets via resources ([0166]). However, Wu teaches allocate resources for the remainder of the PDUs based on the remaining PDU set size. Wu teaches allocate resources for the remainder of the PDUs based on the remaining PDU set size. ([0303]-[0305] Fig 15, Step S301: determining a remaining packet delay bucket (PDB) of a data packet in a buffer of an logical channel (LCH). The determination of the remaining PDB of a data packet may be implemented by the UE. Step S302: selecting an LCH and allocating resources for an uplink scheduling, based on the remaining PDB.) remaining packet delay bucket = remaining size. It would have been obvious to a person having ordinary skill the art before the effective filing of the claim invention, to modify Kammachi per Wu to include allocate resources for the remainder of the PDUs based on the remaining PDU set size. This would have been advantageous as discussed above, as it would allow the modified system to provide as it would allow the modified system to provide sufficient resources while dynamically load balancing. Claim(s) not rejected with Prior Art Claim 20 is allowable over the prior art as no art was discovered to read on the claim. However, Claim 20 is rejected under 112(b) and is dependent on a rejected claim. Claim 20. The method of claim 12, wherein the remaining PDU set size is a first remaining PDU set size, the value is a first value, and the RTP header extension is a first RTP header extension, the method further comprising: receiving, by the first computing device, a second RTP packet of the PDU set, the second RTP packet comprising a second RTP header extension comprising a second value indicative of a second remaining PDU set size, the second remaining PDU set size being indicative of the size of the remainder of the PDUs of the PDU set minus a size of a first PDU, wherein the PDU sequence number of the second RTP packet is greater than the PDU sequence number of the first RTP packet by 1; subtracting, by the first computing device, the second value from the first value to determine an indicated size of the first PDU; determining, by the first computing device, an actual size of the first PDU; determining, by the first computing device, a difference equal to the actual size of the first PDU minus the indicated size of the first PDU; and adding, by the first computing device, a product of the difference and the count of the number of PDUs in the PDU set to the indicated PDU set size to determine an actual size of the PDU set. Conclusion & Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F. 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, Glenton B Burgess can be reached at (571)272-3949. 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. /RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454
Read full office action

Prosecution Timeline

Aug 08, 2024
Application Filed
Dec 27, 2025
Non-Final Rejection — §102, §103, §112
Mar 12, 2026
Interview Requested
Mar 25, 2026
Applicant Interview (Telephonic)
Mar 25, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12587464
FAULT INJECTION CONFIGURATION EQUIVALENCY TESTING
2y 5m to grant Granted Mar 24, 2026
Patent 12580819
DETERMINING SERVICE GROUP CAPACITY BASED ON AN AGGREGATE RISK METRIC
2y 5m to grant Granted Mar 17, 2026
Patent 12500823
SYSTEM AND METHOD FOR ENTERPRISE - WIDE DATA UTILIZATION TRACKING AND RISK REPORTING
2y 5m to grant Granted Dec 16, 2025
Patent 12495001
CAPACITY AWARE LOAD PACKING FOR LAYER-4 LOAD BALANCER
2y 5m to grant Granted Dec 09, 2025
Patent 12470508
RESTRICTING MESSAGE NOTIFICATIONS AND CONVERSATIONS BASED ON DEVICE TYPE, MESSAGE CATEGORY, AND TIME PERIOD
2y 5m to grant Granted Nov 11, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
79%
Grant Probability
99%
With Interview (+26.4%)
2y 10m
Median Time to Grant
Low
PTA Risk
Based on 300 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month