Prosecution Insights
Last updated: July 17, 2026
Application No. 19/050,518

CONFIGURATION OF RTP HEADER EXTENSIONS HAVING THE SAME SYNTAX BUT WITH DIFFERENT SEMANTICS

Non-Final OA §102§103
Filed
Feb 11, 2025
Priority
Mar 22, 2024 — provisional 63/568,536
Examiner
COUSINS, JOSEPH M
Art Unit
Tech Center
Assignee
Qualcomm Incorporated
OA Round
1 (Non-Final)
63%
Grant Probability
Moderate
1-2
OA Rounds
1y 10m
Est. Remaining
84%
With Interview

Examiner Intelligence

Grants 63% of resolved cases
63%
Career Allowance Rate
183 granted / 289 resolved
+3.3% vs TC avg
Strong +20% interview lift
Without
With
+20.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
12 currently pending
Career history
301
Total Applications
across all art units

Statute-Specific Performance

§101
1.3%
-38.7% vs TC avg
§103
86.5%
+46.5% vs TC avg
§102
3.3%
-36.7% vs TC avg
§112
3.4%
-36.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 289 resolved cases

Office Action

§102 §103
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 . Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1, 7-8, 10-11,13-14,16, 22-23, 25-26 and 28-29 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP TS 26.522 V0.3.0 (2024-01) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G Real-time Media Transport Protocol Configurations. Claims 1 and 14, A method comprising: sending, by a first computing device to a second computing device, information indicative of a use of a first meaning of a plurality of meanings of a Real-Time Transport Protocol (RTP) header extension syntax of an RTP header extension of an RTP packet (4.3.2 SDP signaling- The extension attribute "3DOF" indicates that the sender uses the RTP HE to signal a 3DoF XR pose, i.e., an XR pose that does not include the position fields x, y, z. An RTP client that supports the RTP HE for XR pose and receives an SDP offer with "a=extmap" attribute with the URN "urn:3gpp:xr-pose" and the extension attribute "3DOF", shall include the extension attribute "3DOF" in the SDP answer, if the SDP offer is accepted. The extension attribute "6DOF" indicates that the sender uses the RTP header extension to signal a 6DoF XR pose, i.e., an XR pose that includes both the position fields x, y, z and the orientation fields rx, ry, rz, rw.) ; and processing, by the first computing device and based on the first meaning, the RTP packet, the RTP packet comprising extended reality (XR) application data. (4.3.3 - If the RTP HE for XR pose is used by a server, the server should use the RTP HE for XR pose to associate the selected pose with the rendered frame) Claim 14 is rejected under the same rationale. Claim 7, The method of claim 1, wherein sending the information comprises sending the first meaning in the RTP header extension (4.3.2- SDP Signaling An RTP client that supports the RTP HE for XR pose shall negotiate the use of the extension using SDP. The signaling of the RTP HE for XR pose shall follow the SDP signaling design, the syntax, and semantics of the "extmap" attribute as outlined in RFC8285 [11]. For IANA registration, the "reference" field in the registry is 3GPP TS 26.522. The ABNF syntax for this RTP HE extends the "extmap" attribute as follows: extensionname = "urn:3gpp:xr-pose" extensionattributes = "3DOF" / "6DOF" ["media:" 1*(SP token)]). Claim 8, The method of claim 7, wherein sending the first meaning in the RTP header extension comprises setting or reading a flag in the RTP header extension. (4.3.2- extensionattributes = "3DOF") Claim 10, The method of claim 1, wherein the first computing device comprises at least one of a first server or a first client device and wherein the second computing device comprises at least one of a second server or a second client device. (4.3.1-An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose), Server is mapped to the RTP sender and UE is mapped to client). Claim 11, The method of claim 1, wherein the RTP header extension is indicative of the RTP packet comprising XR pose data.( 4.3.1- An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose). Claim 13, The method of claim i1, wherein the first meaning comprises rendered pose and wherein processing the RTP packet comprises using the XR application data as a rendered pose. ( 4.3.1- An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose)) Claims 16 and 29, A method comprising: receiving, by a first computing device from a second computing device, information indicative of a use of a first meaning of a plurality of meanings of a Real- Time Transport Protocol (RTP) header extension syntax of an RTP header extension of an RTP packet (4.3.2 SDP signaling- The extension attribute "3DOF" indicates that the sender uses the RTP HE to signal a 3DoF XR pose, i.e., an XR pose that does not include the position fields x, y, z. An RTP client that supports the RTP HE for XR pose and receives an SDP offer with "a=extmap" attribute with the URN "urn:3gpp:xr-pose" and the extension attribute "3DOF", shall include the extension attribute "3DOF" in the SDP answer, if the SDP offer is accepted. The extension attribute "6DOF" indicates that the sender uses the RTP header extension to signal a 6DoF XR pose, i.e., an XR pose that includes both the position fields x, y, z and the orientation fields rx, ry, rz, rw.); and processing, by the first computing device and based on the first meaning, the RTP packet, the RTP packet comprising extended reality (XR) application data. (4.3.2 - An RTP client that supports the RTP HE for XR pose and receives an SDP offer with "a=extmap" attribute with the URN "urn:3gpp:xr-pose" shall remove the attribute from the answer for any media that will not use the extension, and retain it for any media that will use it.) Claim 22, The method of claim 16, wherein receiving the information comprises receiving the first meaning in the RTP header extension. (4.3.2- SDP Signaling An RTP client that supports the RTP HE for XR pose shall negotiate the use of the extension using SDP. The signaling of the RTP HE for XR pose shall follow the SDP signaling design, the syntax, and semantics of the "extmap" attribute as outlined in RFC8285 [11]. For IANA registration, the "reference" field in the registry is 3GPP TS 26.522. The ABNF syntax for this RTP HE extends the "extmap" attribute as follows: extensionname = "urn:3gpp:xr-pose" extensionattributes = "3DOF" / "6DOF" ["media:" 1*(SP token)]) Claim 23, The method of claim 22, wherein receiving the first meaning in the RTP header extension comprises setting or reading a flag in the RTP header extension. (4.3.2- extensionattributes = "3DOF") Claim 25, The method of claim 16, wherein the first computing device comprises at least one of a first server or a first client device and wherein the second computing device comprises at least one of a second server or a second client device. (4.3.1-An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose), Server is mapped to the RTP sender and UE is mapped to client). Claim 26, The method of claim 16, wherein the RTP header extension is indicative of the RTP packet comprising XR pose data. ( 4.3.1- An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose) Claim 28, Themethodofclaim26,wherein the first meaning comprises rendered pose and wherein processing the RTP packet comprises using the XR application data as a rendered pose. ( 4.3.1- An RTP sender that uses RTP to deliver pre-rendered video streams to a UE should include an RTP HE for XR pose to indicate the XR pose used for rendering the media (rendered pose) Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries 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 2-6, 9, 12, 15, 17-21, 24, 27 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP in view of Rhyu et al. U.S. Patent Application publication 2024/0273776. Claims 2 and 15, Although 3GPP disclose substantial limitations of the invention it fails to disclose: wherein sending the information comprises sending the information out-of-band. In an analogous art, Rhyu discloses wherein sending the information comprises sending the information out-of-band. (para 0241- disclose SDP out-band signaling) One of ordinary skill in the art before the effective filing date of the invention would find it obvious to combine the out of band RTP negotiations of Rhyu with the 3GPP system to produce the predictable result of RTP stream configuration negotiations. Claim 3, The method of claim 2, wherein sending the information out-of-band comprises signaling the information via session description protocol. (Rhyu para 0241) Claim 4, The method of claim 2, wherein sending the information out-of-band comprises sending a first extension name, wherein the first extension name comprises the information indicative of the use of the first meaning of the RTP header extension syntax. (3GPP 4.3.2- extensionattributes = "3DOF") Claim 5, The method of claim 4, wherein the first extension name is chosen from a plurality of extension names, each of the plurality of extension names comprising information indicative of a use of a respective meaning. (3GPP 4.3.2- extensionattributes = "3DOF" or "6DOF") Claim 6, The method of claim 2, wherein sending the information out-of-band comprises sending the information in an extension attribute. (3GPP 4.3.2- extensionattributes = "3DOF") Claim 9, Although 3GPP disclose substantial limitations of the invention it fails to disclose: The method of claim 8, wherein the flag is one bit in length. In an analogous art, Rhyu discloses The method of claim 8, wherein the flag is one bit in length. (para 0244- discloses a plurality of single bit flags to disclose context of the RTP HE.) One of ordinary skill in the art before the effective filing date of the invention would find it obvious to combine the one-bit flags of Rhyu with the 3GPP system to produce the predictable result of exchanging RTP stream configuration between computing devices. Claim 12, Although 3GPP disclose substantial limitations of the invention it fails to disclose: The method of claim 11, wherein the first meaning comprises pose to render, and wherein processing the RTP packet comprises rendering a pose based on the XR application data. In an analogous art, Rhyu discloses The method of claim 11, wherein the first meaning comprises pose to render (para 0246- F0: An identifier indicating whether the PoseData field 1704 contains a value of pose used in the rendering of the associated media frame. For example, a case in which a value of F0 is 0 may indicate that the PoseData field 1704 contains only information to identify an estimated pose stored by the UE 500, while a case in which a value of F0 is 1 may indicate that the PoseData field 1704 contains an estimated pose;), and wherein processing the RTP packet comprises rendering a pose based on the XR application data (para 0019- transmitting the first media frame and first pose information related to estimated pose to a server, receiving a second media frame, generated by rendering based on the first media frame and estimated pose,). One of ordinary skill in the art before the effective filing date of the invention would find it obvious to combine the estimate pose flags of Rhyu with the 3GPP system to produce the predictable result of rendering XR data based on the estimate pose. One of ordinary skill in the art would be motivated to apply the teachings of Rhyu to improve the synchronization of timing for renderings based on poses in a split-rendering environment. Claim 27 is rejected under the same rationale as claim 12 Claims 17 and 30, Although 3GPP disclose substantial limitations of the invention it fails to disclose: wherein sending the information comprises sending the information out-of-band. In an analogous art, Rhyu discloses wherein sending the information comprises sending the information out-of-band. (para 0241- disclose SDP out-band signaling) One of ordinary skill in the art before the effective filing date of the invention would find it obvious to combine the out of band RTP negotiations of Rhyu with the 3GPP system to produce the predictable result of RTP stream configuration negotiations. Claim 18, The method of claim 17, wherein receiving the information out-of-band comprises signaling the information via session description protocol. (Rhyu para 0241) Claim 19, The method of claim 17, wherein receiving the information out-of band comprises receiving a first extension name, wherein the first extension name comprises the information indicative of the use of the first meaning of the RTP header extension syntax. (3GPP 4.3.2- extensionattributes = "3DOF") Claim 20, The method of claim 19, wherein the first extension name is chosen from a plurality of extension names, each of the plurality of extension names comprising information indicative of a use of a respective meaning. (3GPP 4.3.2- extensionattributes = "3DOF" or "6DOF") Claim 21, The method of claim 17, wherein receiving the information out-of-band comprises receiving the information in an extension attribute. (3GPP 4.3.2- extensionattributes = "3DOF"). Claim 24, Although 3GPP disclose substantial limitations of the invention it fails to disclose: The method of claim 23, wherein the flag is one bit in length. In an analogous art, Rhyu discloses The method of claim 23, wherein the flag is one bit in length. (para 0244- discloses a plurality of single bit flags to disclose context of the RTP HE.) One of ordinary skill in the art before the effective filing date of the invention would find it obvious to combine the one-bit flags of Rhyu with the 3GPP system to produce the predictable result of exchanging RTP stream configuration between computing devices. Conclusion Relevant prior art: Zhu et al. U.S. Patent Application Publication 2025/0280320-discloses a method which filters packets based on flags with a RTP header extension. Ahsan et al. U.S. Patent Application Publication 2025/0252616- discloses a protocol to enable split render between a Client device and server device via a media server. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH M COUSINS whose telephone number is (571)270-7746. The examiner can normally be reached 9:00am -5:00pm EST. 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, Tonia Dollinger can be reached at (571) 272-4170. 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. /SCHQUITA D GOODWIN/Primary Examiner, Art Unit 2459 /JMC/Examiner, Art Unit 2459
Read full office action

Prosecution Timeline

Feb 11, 2025
Application Filed
Jul 02, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683872
RADIO ACCESS NETWORK NODE REGISTRATION AND DISCOVERY
2y 5m to grant Granted Jul 14, 2026
Patent 12683860
TOPOLOGY-DRIVEN INTERCONVERSION OF RING NETWORK CONFIGURATIONS
2y 5m to grant Granted Jul 14, 2026
Patent 12677342
METHOD AND DEVICE FOR MANAGING ROAMING SESSION FOR EDGE COMPUTING SERVICE
1y 10m to grant Granted Jul 07, 2026
Patent 12665845
CONCURRENTLY SUPPORTING INTERNET PROTOCOL VERSION 6 (IPV6) AND INTERNET PROTOCOL VERSION 4 (IPV4) IN A CLOUD-MANAGED WIRELESS TELECOMMUNICATION NETWORK
1y 10m to grant Granted Jun 23, 2026
Patent 12652191
LOOP DETECTING AND REMEDIATING SYSTEM AND METHOD FOR A HETEROGENEOUS COMPUTING PLATFORM
2y 2m to grant Granted Jun 09, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
63%
Grant Probability
84%
With Interview (+20.4%)
3y 3m (~1y 10m remaining)
Median Time to Grant
Low
PTA Risk
Based on 289 resolved cases by this examiner. Grant probability derived from career allowance 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