DETAILED ACTION
Applicant’s response filed on 08/27/2026 has been entered and made of record.
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 Status
Claims 1, 4, 10-12, 19-20, 23 and 25 are amended.
Claims 5-9, 13-18 and 21-22 are canceled.
New claims 26-33 are added.
Claims 1-4, 10-12, 19-20 and 23-33 are pending for examination.
Applicant Argument
Applicant’s arguments (remark pages 6-9), filed on 08/27/2026, with respect to claims 1-4, 10-12, 19-20 and 23-33 have been considered but are moot in view of the new ground of rejection below which better address the claimed invention as amended.
This Office Action is made Final.
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 19, 23, 25, 28-29 and 32-33 are rejected under 35 U.S.C. 103 as being unpatentable over Sha et al. (US 20240373282 A1), hereinafter “Sha”, in view of Wang et al. (US 20230224383 A1), hereinafter “Wang”.
Per claim 1 and 25:
Regarding claim 25, Sha teaches ‘A network node’ (Sha: [FIG.25]; [0201]: “FIG. 25 is a structural schematic of a communication device”; [0204]: “the communication device is a first communication node”; [0205]: “the communication device is a second communication node”); ‘comprising: one or more processors’ (Sha: [FIG.25]: “Processor”); ‘a non-transitory memory storage’ (Sha: [FIG.25]: “Memory”); ‘storing instructions that’ (Sha: [0202]: “the memory 2520 may be configured to store a software program, a computer-executable program”); ‘when executed by the one or more processors, cause the network node to perform operations including’ (Sha: [0204]: “When the communication device is a first communication node, the device provided above may be configured to execute the parameter configuration method applied to the first communication node provided in any one of the above embodiments, and has corresponding functions and effects”);
‘receiving a media packet of a flow’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”, [0039]: “a video sequence has a plurality of I-frames, P-frames, and B-frames”; receive an IP packet in a media flow; [FIG.3]: S310: “Receive a frame format of a packet data unit (PDU) session sent by a second communication node”, S320: “Determine scheduling priorities or resource allocation weights of different IP packets in a same QoS flow according to the frame format of the PDU session”; [0035]: “identify a correlation between an Internet protocol (IP) packet and an application packet, a correlation between application packets, and different priorities of application packets mapped to a same QoS flow”).
Sha does not expressly teach, but Wang in the same field of endeavor teaches ‘the media packet being a real time transport protocol (RTP) packet’ (Wang: [FIG.15]: “QoS FLOW” -> “IP PACKET” -> “UDP PACKET” -> “RTP PACKET” -> “XR TRAFFIC”, the IP packet of a media flow is a RTP packet; [0011]: “the multiple protocol layers include an IP layer and a real-time transport protocol (RTP) layer”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching with that of Sha in order to deliver live audio and video data across networks with minimal delay.
Combination of Sha and Wang teaches ‘determining that the media packet of the flow belongs to a protocol data unit (PDU) set’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n” => packet belong to I-frame “I1” (a PDU set); [0039]: “in services such as XR, different PDUs may have different priorities, but there are dependency relationships between the PDUs. For example, a video sequence has a plurality of I-frames, P-frames, and B-frames”; [0091]: “The application packet type may indicate an application packet type corresponding to the IP packet, for example, indicating an I frame packet, a B frame packet, and a P frame packet in a video stream”. Wang: [0032]: “The ADU can be a data burst or a PDU set … data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission”);
‘obtaining a packet priority mark (PPM) for the PDU set by mapping information in a RTP payload header in an RTP payload of the media packet to the PPM’ (Sha: [0090]: “application packets of different priorities are mapped to a same QoS Flow, and application packet identification information or a priority indication is introduced into the frame format of the PDU session … the application packet priority is used by the base station to identify the importance of the PDUs”. Wang: [FIG.6]: “UPF” (network node), “BS” (network node); [0060]: “multiple priority levels can be defined and mapped to XR traffic types and/or packet types (e.g., I-frame, P-frame”; [0053]: “An RTP payload type at an RTP header may provide the information that this packet belongs to a specific ADU, such as a particular frame (e.g., a particular I-frame or P-frame for a video stream) or a particular slice. By inspecting the RTP payload type (carried in a PT field of an RTP header), a lower layer (e.g., IP, SDAP, PDCP, and the like) can classify an RTP packet (or a data unit carrying this RTP packet) based on which type of ADU the RTP packet belongs to. The lower layer can also determine the ADU which the RTP packet (or the data unit carrying this RTP packet) is associated with. Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”; [0064]: “the UPF 403 can inspect the RTP payload type (PT field of an RTP header) of each packet and classify different packets to different QoS flows”);
‘the PPM indicating an importance of the media packet’ (Sha: [0046]: “The application packet information may also be indicated by means of importance of an application packet”. Wang: [0032]: “data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance”);
‘obtaining a PDU sequence mark (PSM) for the PDU set, the PSM indicating a sequence number for the PDU set to which the media packet belongs’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n” => Sequence number of IP packet indicating packet belong to I-frame “I1” (a PDU set); [FIG.14]: “First Level Application Data Unit Sequence Number”, “Second Level Application Data Unit Sequence Number”. Wang: [0032]: “The ADU can be a data burst or a PDU set”);
‘performing congestion handling on the media packet in accordance with the PPM and the PSM’ (Sha: [0092]: “Based on the application packet sub-priority or application packet sub-flow information … to determine a scheduling priority, a reliability requirement, or a resource allocation weight of the PDU”. Wang: [FIG.8]: congestion handling; [0085]: “critical packets and normal (non-critical) packets at a PDCP layer are assigned timers with different time intervals based on packet inspection results. Critical packets are assigned with a longer discard timer than normal packets. Accordingly, critical packets can be kept longer than normal packets when PDCP congestion happens”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Regarding claim 1, claim 1 recites the method implemented by the network node of claim 25 (see rejection of claim 25 above).
Regarding claim 2, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Sha teaches ‘wherein the PDU set is a subset of a quality of service (QoS) flow’ (Sha: [FIG.1]; [FIG.6]: “QoS Flow Identifier”, “sub-Flow ID”; [FIG.7]: “QoS flow level QoS parameters”, “QoS sub-Flow Item #1” .. “QoS sub-Flow Item #n”; [0048]: “the QoS sub-flow identifier refers to an identifier of each QoS sub-flow included in the QoS flow”);
‘wherein the QoS flow includes a second PDU set, each packet of the second PDU set includes a second PSM indicating a second sequence number different from the sequence number’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “B2” -> “B21 … B2n” => Sequence number of IP packet indicating packet belong to B-frame “B2” (another PDU set); [FIG.14]: “First Level Application Data Unit Sequence Number”, “Second Level Application Data Unit Sequence Number”);
‘the second PDU set corresponding to a second PPM different from the PPM’ (Sha: [FIG.6]: “sub-Priority”; [FIG.8]: “QoS Sub-priority #1” … “QoS Sub-priority #n”; [0039]: “in services such as XR, different PDUs may have different priorities”; [0048]: “the QoS sub-flow priority refers to a priority of each QoS sub-flow included in the QoS flow. In one embodiment, the QoS sub-flow identifier and the QoS sub-flow priority may be represented by a QoS sub-priority, that is, the QoS sub-priority includes both the QoS sub-flow identifier and the QoS sub-flow priority”).
Regarding claim 3, combination of Sha and Wang teaches the method of claim 2 (discussed above).
Sha teaches ‘wherein the QoS flow corresponds to a video stream’ (Sha: [FIG.1]; [0055]: “the first level of application data unit may be a video stream, and the second level of application data unit may be a video frame”; [0039]: “in services such as XR, different PDUs may have different priorities, but there are dependency relationships between the PDUs. For example, a video sequence has a plurality of I-frames, P-frames, and B-frames”);
‘wherein the PDU set corresponds to a video frame of the video stream’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n”, I-frame);
‘wherein the second PDU set corresponds to a second video frame of the video stream different from the video frame’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “B2” -> “B21 … B2n”, B-frame).
Regarding claim 19, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Combination of Sha and Wang teaches ‘mapping the information in the RTP payload header to the PPM using a configured rule in an enhanced media identification filter’ (Sha: [FIG.1]; [FIG.3]; [FIG.6]: “Application packet Type, sub-Flow ID or sub-Priority”; [0042]-[0048]: “enhance the frame format of the PDU session … the QoS sub-flow identifier refers to an identifier of each QoS sub-flow included in the QoS flow; and the QoS sub-flow priority refers to a priority of each QoS sub-flow included in the QoS flow”. Wang: [0062]: “The UPF 403 is configured to classify (filter) IP flows from applications into QoS flows by using a set of service data flow (SDF) templates or traffic flow templates (TFTs)”, configured rule such as SDF/TFT; [0064]: “the UPF 403 can inspect the RTP payload type (PT field of an RTP header) of each packet and classify different packets to different QoS flows”; [0053]: “By inspecting the RTP payload type (carried in a PT field of an RTP header), a lower layer (e.g., IP, SDAP, PDCP, and the like) can classify an RTP packet (or a data unit carrying this RTP packet) based on which type of ADU the RTP packet belongs to. The lower layer can also determine the ADU which the RTP packet (or the data unit carrying this RTP packet) is associated with. Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”);
‘the configured rule obtained from a control plane node’ (Sha: [0052]: “the first communication node receives the QoS sub-flow configuration information sent by the second communication node through control plane signaling”, obtain the configured rule from control plane).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha for network node in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Regarding claim 23, combination of Sha and Wang teaches the method of claim 19 (discussed above).
Combination of Sha and Wang teaches ‘setting the PPM to indicate a high importance based on the media packet being in an independent frame as specified in the configured rule’ (Sha: [FIG.6]: extension of 3GPP GTP-U header: “Application packet type, sub-Flow ID or sub-Priority”; [0046]: “the application packet type includes: an I frame packet, a B frame packet and a P frame packet. The application packet information may also be indicated by means of importance of an application packet”; determine that Application packet type is I-frame. Wang: [0052]: “critical packets can be defined as packets of high importance … critical packets can be an I-frame and normal packets (i.e., non-critical packets) can be a P-frame (or a B-frame)”; [0053]: “An RTP payload type at an RTP header may provide the information that this packet belongs to a specific ADU, such as a particular frame (e.g., a particular I-frame or P-frame for a video stream)”, rule to set high importance based on RTP header type indicating I-frame; [0053]: “By inspecting the RTP payload type … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”);
‘setting the PPM to indicate a low importance based on the media packet being in a discardable frame as specified in the configured rule, or setting the PPM based on an application preference for motion or quality as specified in the configured rule’ (these are optional).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Per claim 28 and 32:
Regarding claim 32, combination of Sha and Wang teaches the network node of claim 25 (discussed above).
Combination of Sha and Wang teaches ‘identifying a PDU set boundary based on at least one of second information in the RTP payload header or information in a RTP header’ (Sha: [FIG.1]: “Application Data Frame” : I-Frame PDU set “I1” => {“I11” … “I1n”}, B-Frame PDU set “B2” => {“B21” … “B2m”}, identify boundary between I-Frame and B-Frame. Wang: [FIG.15]: “RTP PACKET” -> “XR TRAFFIC”: {“I FRAME”, “B-FRAME”}; [0053]: “An RTP payload type at an RTP header may provide the information that this packet belongs to a specific ADU, such as a particular frame (e.g., a particular I-frame or P-frame for a video stream) or a particular slice. By inspecting the RTP payload type … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Regarding claim 28, claim 28 recites the method implemented by the network node of claim 32 (see rejection of claim 32 above).
Per claim 29 and 33:
Regarding claim 33, combination of Sha and Wang teaches the network node of claim 25 (discussed above).
Combination of Sha and Wang teaches ‘wherein a same value of the PSM is applied to all media packets that belong to the PDU set’ (Sha: [FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n” => packet belong to I-frame “I1” (a PDU set); [FIG.6]: “Application packet Type, sub-Flow ID or sub-Priority”; [0091]: “The application packet type may indicate an application packet type corresponding to the IP packet, for example, indicating an I frame packet, a B frame packet, and a P frame packet in a video stream”; same packet priority applied to a given sub-Flow (a PDU set) identified by application packet type such as I-Frame or B-Frame. Wang: [0032]: “The ADU can be a data burst or a PDU set”; [0052]: “critical packets can be an I-frame, and normal packets (i.e., non-critical packets) can be a P-frame (or a B-frame)”; [0053]: “An RTP payload type at an RTP header may provide the information that this packet belongs to a specific ADU, such as a particular frame (e.g., a particular I-frame or P-frame for a video stream) or a particular slice. By inspecting the RTP payload type … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”, all packets in a given PDU set has same priority such as critical packets for all I-fame (PDU set) and non-critical packets for all P-frame (PDU set)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Regarding claim 29, claim 29 recites the method implemented by the network node of claim 33 (see rejection of claim 33 above).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over combination of Sha and Wang as applied to claim 1 above, in view of Ma et al. (US 20160219088 A1), hereinafter “Ma”.
Regarding claim 4, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Combination of Sha and Wang teaches ‘determining whether to forward or drop the media packet in accordance with the PPM, the PSM, and a congestion level’ (Sha: [0050]: “the first communication node can determine scheduling priorities or resource allocation weights of different IP packets in the same QoS flow according to the frame format of the PDU session”; [0092]: “Based on the application packet sub-priority or application packet sub-flow information … to determine a scheduling priority, a reliability requirement, or a resource allocation weight of the PDU”. Wang: [FIG.8]: congestion handling => for each packet, determine whether to forward (“TRANSMITED”) or drop (“DISCARDED”) based on packet importance {“CRITICAL DATA” or “NON-CRITICAL DATA”} and the packet sequence number {“1” … “10”}; [0053]: “By inspecting the RTP payload type … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”; [0085]: “Critical packets are assigned with a longer discard timer than normal packets. Accordingly, critical packets can be kept longer than normal packets when PDCP congestion happens”). However, combination of Sha and Wang fails to expressly teach in accordance with a congestion level.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload type with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Ma in the same field of endeavor teaches congestion handling in accordance with a congestion level (Ma: [0263]: “The LC-Codel results shown in Table 1 and Table 2 may focus on high congestion. LC-Codel may be configured to perform active queue management in other congestion regimes. As congestion decreases, DropTail handling of congestion may improve traffic in a wireless network … where the congestion level for Table 3 is higher than Table 4”, different strategy (algorithm) to drop or forward packet according to congestion level; [0035]: “an active queue management algorithm”; [0042]: “DropTail (DT) algorithm”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ma’s teaching with that of combination of Sha and Wang the network node to determine whether to forward or drop the media packet in accordance with the PPM, the PSM, and a congestion level in order to improve traffic by applying a strategy (algorithm) suitable for a congestion level (see reference quotes in element above).
Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over combination of Sha and Wang as applied to claim 1 above, in view of Stoica et al. (US 20230199198 A1), hereinafter “Stoica”.
Regarding claim 10, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Sha teaches ‘determining that a configured network adaptation layer (NAL) independent (I) flag is set to 1; and setting the PPM to indicate a high importance in response to the configured NAL I flag being set to 1.’ (Sha: [FIG.6]: extension of 3GPP GTP-U header: “Application packet type, sub-Flow ID or sub-Priority”; [0046]: “the application packet type includes: an I frame packet, a B frame packet and a P frame packet. The application packet information may also be indicated by means of importance of an application packet. For example, application packets are divided into primary packets and secondary packets according to the importance”, determine that Application packet type is I-frame; [0091]: “determine the application packet type corresponding to the PDU, so as to determine a scheduling priority, a reliability requirement level, or a resource allocation weight of the PDU”). However, combination of Sha and Wang fails to expressly teach ‘a configured NAL independent (I) flag is set to 1’.
Stoica in the same field of endeavor teaches XR media Network Abstraction (Adaptation) Layer and flag keyframe indicating I-frame (Stoica: [FIG.5]: “NAL unit type”, “VCL NAL”; [FIG.7]: block 702: “keyframe”, “I Frame”, flag “Keyframe” to indicate an important “I Frame”; [FIG.8]: “Importance Indicator Processing”; [0078]: “The NAL units are the main syntax elements of a video codec and these may encapsulate encoded video metadata, e.g., video/sequence/picture parameter set (“VPS”/“SPS”/“PPS”), supplemental enhancement information (“SEI”) messages”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stoica’s teaching with that of combination of Sha and Wang to determine that a configured network adaptation layer (NAL) independent (I) flag is set to 1; and setting the PPM to indicate a high importance in response to the configured NAL I flag being set to 1, in order to encapsulate encoded video metadata and SEI (see reference quotes in element above).
Regarding claim 11, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Sha teaches ‘mapping NAL priority field values for enhanced layers to the PPM in accordance with an application preference for motion or quality’ (Sha: [FIG.6]: “Application packet type, sub-Flow ID or sub-Priority”; [0046]: “the application packet type includes: an I frame packet, a B frame packet and a P frame packet”, map packet priority based on application packet type such as I/B/P frame). However, combination of Sha and Wang fails to expressly teach NAL priority field and based on an application preference for motion or quality.
Stoica teaches NAL priority field, priority for motion and preference for video quality (Stoica: [FIG.5]: “NAL Header” : “Temporal video coding layer ID”; [FIG.7]: block 702: “keyframe”, “I Frame”, flag “Keyframe” to indicate an important “I Frame”; [FIG.8]: “Important Indicator Processing”; NAL priority field; [FIG.9]: “Main layer (temporal layer 0) importance offset”; [0077]: “video codec performing both spatial and temporal (motion) compression of a video source”; [0147]: “the preferred encoding strategy for high-quality advanced video media”; [0078]: “The NAL units are the main syntax elements of a video codec and these may encapsulate encoded video metadata, e.g., video/sequence/picture parameter set (“VPS”/“SPS”/“PPS”), supplemental enhancement information (“SEI”) messages”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stoica’s teaching with that of combination of Sha and Wang to map network adaptation layer (NAL) priority field values for enhanced layers to the PPM in accordance with an application preference for motion or quality in order to encapsulate encoded video metadata and SEI (see reference quotes in element above).
Regarding claim 12, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Combination of Sha and Wang teaches ‘determining that no NAL application specific information is configured in the RTP payload; and setting the PPM to indicate a low importance in response to no NAL application specific information being configured’ (Sha: [FIG.2]: does not include extension: “Application packet type”; [0046]: “The application packet information may also be indicated by means of importance of an application packet”; [0099]: “the more important the data frame or the PDU is (the higher the scheduling priority is”, no Applicant packet type would mean a low importance packet; [0091]: “determine the application packet type corresponding to the PDU, so as to determine a scheduling priority, a reliability requirement level, or a resource allocation weight of the PDU”. Wang: [0045]: “The RTP layer or a network adaptation layer (NAL)”; [FIG.15]: “RTP PACKET” -> “XR TRAFFIC” : {“I FRAME”, “P FRAME”}; [0053]: “By inspecting the RTP payload type (carried in a PT field of an RTP header), a lower layer (e.g., IP, SDAP, PDCP, and the like) can classify an RTP packet (or a data unit carrying this RTP packet) based on which type of ADU the RTP packet belongs to … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”; [FIG.1]: “TCP”). However, combination of Sha and Wang fails to expressly teach ‘no NAL application specific information is configured in the RTP payload’.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload with that of Sha for network node in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in elements above).
Stoica teach Network Abstraction (adaptation) Layer to encode XR media (Stoica: [FIG.5]: “Video coded elementary stream”, “NAL unit”; [0078]: “The NAL units are the main syntax elements of a video codec and these may encapsulate encoded video metadata, e.g., video/sequence/picture parameter set (“VPS”/“SPS”/“PPS”), supplemental enhancement information (“SEI”) messages”; No NAL => not XR media video packet => low importance).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Stoica’s teaching with that of combination of Sha and Wang to determine that no NAL application specific information is configured in the RTP payload; and set the PPM to indicate a low importance in response to no NAL application specific information being configured in order to encapsulate encoded video metadata and SEI (see reference quotes in element above).
Claims 20 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over combination of Sha and Wang as applied to claim 1 above, in view of Dao et al. (US 20200145876 A1). Hereinafter “Dao”.
Regarding claim 20, combination of Sha and Wang teaches the method of claim 19 (discussed above).
Sha teaches ‘wherein an application function (AF) node configures the configured rule to the control plane node’ (Sha: [0052]: “the first communication node receives the QoS sub-flow configuration information sent by the second communication node through control plane signaling”, obtain the configured rule from control plane). However, combination of Sha and Wang fails to expressly teach ‘an application function (AF) node’;
‘wherein the configured rule specifies parameters for mapping to the PPM’ (Sha: 0052]: “the first communication node receives the QoS sub-flow configuration information sent by the second communication node through control plane signaling”, configuration specifies QoS sub-flow (parameters) for mapping priority; [FIG.7]: “QoS flow level QoS parameters”).
Dao in the same field of endeavor teaches AF indicate packet handling policy to PCF (control plane node) (Dao: [0213]: “the PHP parameters may be updated by the PCF and sent to the SMF using the PDU Session Modification procedure. The AF may request the PCF, either directly or indirectly, via the NEF, to indicate the PHP parameters”; [0010]: “a packet handling policy (PHP)”; [Abstract]: “sending the PHP to other network functions for instructing devices in the user plane of the mobile wireless network how to handle delayed packets”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dao’s teaching with that of combination of Sha and Wang for AF node to configure the configured rule to the control plane node in order to instruct devices in the user plane of the mobile wireless network how to handle delayed packets (see reference quotes in element above).
Regarding claim 24, combination of Sha and Wang teaches the method of claim 1 (discussed above).
Sha teaches ‘determining, by the network node, that there is a match between a data network name (DNN) or a single-network slice selection assistance information (S-NSSAI) and a QoS flow of the PDU set’ (Sha: [FIG.7]: “QoS flow level QoS parameters”; [0003]: “a mapping from a packet data unit session (PDU session) to a quality of service flow (QoS flow) level”; FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n” => packet belong to I-frame “I1” (a PDU set)). However, combination of Sha and Wang fails to expressly teach a DNN or a S-NSSAI;
‘setting, by the network node, the PPM in accordance with at least one of a packet type’ (Sha: FIG.6]: “Application packet type, sub-Flow ID or sub-Priority”; [0091]: “The application packet type may indicate an application packet type corresponding to the IP packet, for example, indicating an I frame packet, a B frame packet, and a P frame packet in a video stream”; set packet priority based on packet type);
‘a service address, a port, a protocol, a frame information field, a payload size, a packet rate, or a packet idle time’ (these are optional).
Dao in the same field of endeavor teaches match between a DNN or S-NSSAI and QoS flow (Dao: [0121]: “The SMF may create PHP parameters for the QoS Profile in the (R)AN, and/or the QoS Rules in the UE, and/or the Packet Detection Rule (PDR) in UPF”; [0122]: “The SMF may use the information provided by the UE and AMF such as single network slice selection assistance information (S-NSSAI), data network name (DNN) Access Type, radio access technology (RAT) Type, PDU Session Type to determine the PHP parameters … the Drop-Delayed-Packet parameter for the DL and/or UL QoS flows for the UPF”; [Abstract]: “sending the PHP to other network functions for instructing devices in the user plane of the mobile wireless network how to handle delayed packets”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dao’s teaching with that of combination of Sha and Ma in order to instruct devices in the user plane of the mobile wireless network how to handle delayed packets (see reference quotes in element above).
Claims 26 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over combination of Sha and Wang, in view of MIKLÓS et al . (US 20160359750 A1), hereinafter “Miklos”.
Per claim 26 and 30:
Regarding claim 30, combination of Sha and Wang teaches the network node of claim 25 (discussed above).
Combination of Sha and Wang teaches ‘comparing the congestion level to a configured drop priority level for a QoS flow of the PDU set’ (Sha: [FIG.6]: “PPI” (packet priority indicator), “Application packet Type, sub-Flow ID or sub-Priority”, sub-Priority (priority level for a QoS flow of the PDU set such as an I-Frame; [FIG.1]: “Application Data Unit” -> “IP Packet”: “I1” -> “I11 … I1n” => packet belong to I-frame “I1” (a PDU set). Wang: [0032]: “The ADU can be a data burst or a PDU set”; [FIG.8]: congestion handling => for each packet, determine whether to forward (“TRANSMITED”) or drop (“DISCARDED”) based on packet importance (priority level)). However, combination of Sha and Wang fails to expressly teach ‘comparing the congestion level to a configured drop priority level’
‘forwarding the media packet to a next hop when the congestion level does not exceed the configured drop priority level, or dropping the media packet when the congestion level exceeds the configured drop priority level and the PPM indicates a lower importance’ (Wang: [FIG.8]: “CRITICAL DATA” => high importance, “NON-CRITICAL DATA” => low importance, forward or discarded based on packet importance. Ma: [0263]: different strategy (algorithm) to drop or forward packet according to congestion level). However, combination of Sha and Wang fails to expressly teach based on whether the congestion level exceeds configured drop priority level or not;
‘wherein all packets of the PDU set sharing the PSM are processed consistently in accordance with the PPM’ (Wang: [0053]: “By inspecting the RTP payload type … Knowing the association of data units with a PDU helps a low layer to do coordinated processing for a group of packets, such as collectively packet dropping, packet prioritization and/or packet preemption”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Wang’s teaching of RTP payload with that of Sha in order to perform coordinated processing for a group of packets via RTP payload header inspection (see reference quotes in element above).
Miklos in the same field of endeavor teaches packet drop precedence (drop priority level) depending on congestion level where a higher congestion level corresponding to a higher drop precedence (drop priority level) (Miklos [0169]: “apply differentiated packet dropping depending on the congestion level marking. I.e., the packets with a higher congestion level marking have a higher drop precedence value. The packets with a higher drop precedence are dropped earlier in case the buffer length increases during congestion”; [0171]: “use different drop precedence depending on the congestion level”; : [FIG.9]: :”Congestion Level” -> {“High”, “Medium”, “Low”}, priority from low to high => {“Background”, “Best Effort” … “Operator Video”}; [Abstract]: “provide congestion level dependent QoS targets for the traffic classes”; [0002]: “operators need efficient and flexible tools by which they can control how the bottleneck RAN capacity can be best shared so that they can maximize the Quality of Experience of their users”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Miklos’s teaching with that of combination of Sha and Wang to compare the congestion level to a configured drop priority level for a QoS flow of the PDU set; and forward the media packet to a next hop when the congestion level does not exceed the configured drop priority level, or drop the media packet when the congestion level exceeds the configured drop priority level and the PPM indicates a lower importance, wherein all packets of the PDU set sharing the PSM are processed consistently in accordance with the PPM, in order to maximize QoE via congestion level dependent QoS (see reference quotes in element above).
Regarding claim 26, claim 26 recites the method implemented by the network node of claim 30 (see rejection of claim 30 above).
Claims 27 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over combination of Sha and Wang, in view of Coban et al. (US 20140355616 A1), hereinafter “Coban”.
Per claim 27 and 31:
Regarding claim 31, combination of Sha and Wang teaches the network node of claim 25 (discussed above).
Combination of Sha and Wang does not expressly teach, but Coban in the same field of endeavor teaches ‘the information in the RTP payload header comprising information in an NAL unit header’ (Coban: [0061]: “RTP packets sent over the session may include RTP payloads that contain video data encoded using the HEVC standard. As such, RTP payloads may include NAL units”; [0062]: “For some RTP payloads adhering to the RTP payload format for HEVC, the RTP payload header consists of the same fields as the NAL unit header for HEVC”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Coban’s teaching with that of combination of Sha and Wang in order to utilize the RTP payload format for HEVC (see reference quotes in element above).
Regarding claim 27, claim 27 recites the method implemented by the network node of claim 31 (see rejection of claim 31 above).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUOXING FAN whose telephone number is (703)756-1310. The examiner can normally be reached Monday - Friday 9:00 am - 5:30 pm ET.
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, Yemane Mesfin can be reached at (571)272-3927. 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.
/G.F./Examiner, Art Unit 2462
/YEMANE MESFIN/Supervisory Patent Examiner, Art Unit 2462
