DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to remarks and claim amendments filed by Applicant’s representative on October 31, 2025.
Response to Amendments and Remarks
With regards to Applicant’s latest claim amendments and associated remarks filed on October 31, 2025, the Office notes that Applicant’s remarks / comments are generally directed to the latest filed amended claim features for amended independent claims 1 and 14, which now incorporate the features / limitations previously recited by dependent claim 3 (now canceled). In this regard, the Office has fully considered the latest filed claim amendments and corresponding remarks, but finds the claim amendment(s) and remarks unpersuasive to overcome the current rejection of the claims over the applied prior art or prior art combination, as the amended and/or argued claim feature{s} appear to be still taught or disclosed by one or more of the applied prior art reference(s), as previously cited in the last office action.
With respect to amended independent claims 1 and 14 and claim 1 in particular, Applicant notes and remarks that the claim{s} have been amended to now recite
“A method for communicating data with user equipment, UE, the method comprising the steps of:
establishing a data radio bearer, DRB, between a base station and the UE; and
transmitting data packets between the base station and the UE through the DRB,
wherein data packets are transmitted using different transmission quality parameters, and wherein the transmission quality parameters for each data packet are determined from information within the MAC header “.
With respect to the independent claim(s), and amended independent claim 1 in particular, Applicant firstly notes and/or remarks that none of the applied prior art (Tremblay et al, Fu et al) sufficiently teaches or discloses the newly amended feature(s) of “wherein the transmission quality parameters for each data packet are determined from information within the MAC header …”, as currently recited by the claim.
In support of this position, Applicant remarks that Chae does not disclose transmitting data packets between the base station using different ‘transmission quality parameters, where the transmission quality parameters are being determined from information ‘within a MAC header’, because the cited portions of Chae disclosing the MAC sub header comprising fields for information such as the Local Channel Identifier [LCID], a ‘flag’ field, and a Reserved Bit [R] field, for example, merely discloses a MAC sub-header in general terms and its composition, but none of the ‘fields’ (information elements) are used to determine ‘transmission quality parameters’ for the data packet. The Office respectfully disagrees.
In response to Applicant’s argument or remark above, the Office firstly asserts and significantly notes that the features / limitations of dependent claims 4 and 5 (which depend on the above amended / argued feature of wherein ‘transmission quality parameters’ for each data packet are determined from ‘information’ within the MAC header ) respectively recite: ‘wherein the information in included within a R-field within the MAC header’ (claim 4), and ‘wherein the information is included within a LCID and/or eLCID field within the MAC header’ (claim 5), and ‘further define’ or give specificity to the amended / argued feature. The recited features of dependent claims 4 and 5 were rejected in view of teachings and disclosures by Chae, as cited in the Office action, and Applicant does not contest or dispute the rejection of the features recited by claims 4 and 5 (i.e., wherein the ‘information’ is ‘included’ {specifically found or ‘located’} within a ‘R-field’ or an ‘LCID / eLCID field’ that is within the MAC header. Thus, any ‘information’ that is found in an ‘information field’ {R-field, LCID / eLCID field} ‘located within’ the MAC header {MAC sub-header} is also the same ‘information’ as that which can be found in the ‘MAC header’, and given that the ‘information’ of claim 3 {now in amended claim 1} corresponds or pertains to ‘transmission quality parameters’, then such ‘information’ is also to be found in the ‘R-field’ and/or, ‘LCID / eLCID field’ further comprising the MAC header of the packet. The amended / argued feature is thus properly and sufficiently disclosed by Chae, and the Office maintains its rejection of the claim feature / limitation for at least this reason.
Second, the Office also notes and remarks that Applicant does not characterize, specify or define the recited ‘information’ which is indicative of transmission quality parameters, but merely recites them as general ‘information’. In this regard, the Office notes and asserts that the express disclosure by Chae of ‘local channel identification [LCID]’ information found / located in the ‘LCID field’ of the MAC sub-header (which is ‘within the MAC header’) discloses at least one possible embodiment for the ‘information’ used to determine a ‘transmission quality parameter’. Indeed, Chae expressly discloses as part of his invention and in one aspect that:
“The MACs 212 and 222 may perform multiplexing/demultiplexing of logical channels and/or mapping between logical channels and transport channels. The multiplexing/demultiplexing may include multiplexing/demultiplexing of data units, belonging to the one or more logical channels, into/from Transport Blocks (TBs) delivered to/from the PHYs 211 and 221. The MAC 222 may be configured to perform ‘Scheduling’ {i.e., Scheduling Assignment}, scheduling information reporting, and ‘priority handling’ between UEs by means of dynamic scheduling. ‘Scheduling’ may be performed in the gNB 220 (at the MAC 222) for downlink and uplink. The MACs 212 and 222 may be configured to perform error correction through Hybrid Automatic Repeat Request (HARQ) (e.g., one HARQ entity per carrier in case of Carrier Aggregation (CA)), ‘Priority handling’ between logical channels of the UE 210 by means of ‘Logical Channel Prioritization’, and/or padding. The MACs 212 and 222 may support one or more numerologies and/or ‘transmission timings’. In an example, mapping restrictions in a logical channel prioritization may control which numerology and/or transmission timing a logical channel may use. As shown in FIG. 3, the MACs 212 and 222 may provide ‘logical channels’ as a service to the RLCs 213 and 223…” [Chae: 0068]
Based on the above, and as is ‘well-known’ in the technical field, performance of ‘priority handling’ in transmission services, as performed by the MAC entities, ensures and/or guarantees that ‘higher-priority data packets’ {i.e., higher Quality of Services [QoS] data packets / streams, such as voice packets or video packets} are served or serviced first and/or with guaranteed bit rates or latencies, over ‘lower-priority data packets’ or streams having a lower QoS. And as expressly taught by Chae above, “the MACs 212 and 223 may perform -- among others -- (i) ‘mapping’ between logical channels and transport channels, and (ii) ‘priority handling between logical channels of the UE 210 by means of ‘logical channel prioritization’ and/or padding…”. ‘Logical channel prioritization’ involves ‘mapping’ or determining the correspondence between the designated ‘priority’ of the data packet / flow and one of the logical channels [LCIDs] on which the packet may be transmitted and at a assigned schedule. Thus, the ‘information’ of the LCID field {LCID ‘value’} comprising the MAC ‘sub-header’ represents an ‘information element [IE]’ which constitutes or embodies one of the ‘transmission parameters’ required in ‘mapping’ LCID channel information to the packet / stream ‘priority’ {another transmission parameter} and needed for implementing logical channel / packet ‘Priority Handling’ when processing / transmitting data packets in the communication network, and where the ‘value’ of the Logical Channel ID { a ‘transmission quality parameter’} is associated with a specific ‘priority’ of the data packet {another transmission quality parameter}. Significantly, and as is also well-known in the technical field, the ‘priority’ level of the data packet can be included in the header of the MAC PDU. In support of the Office’s assertions and position above regarding the well-known features as it relates to Chae’s disclosures and the claim amendments, the Office invites Applicant to review teachings / disclosures by Rudolf et al [US Patent Publication 20170230939 A1] – cited but not referred to in this Office action – which is provided as evidentiary support for the Office’s position.
Accordingly, the Office asserts that the above amended / argued feature(s) of independent claims 1 and 14 are thus expressly and sufficiently disclosed by at least Chae, as discussed above and cited in a same ground of rejection included with this Office action (below).
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)(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 claim invention.
Claim(s) 1-2, 4-9, 12-15, is/are rejected under 3 5 U.S.C. 102(a)(2) as being disclosed by Chae et al (hereinafter Chae), US Patent Publication 20240357515 A1 (provisional date December 2021)
As per claim{s} 1, 14, 15, Chae discloses a method for communicating data with user equipment, UE, the method comprising the steps of:
establishing a data radio bearer, DRB, between a base station and the UE (Chae: e.g., the Radio Resource Controller(s) 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 {Base Station} or, more generally, between the UE 210 and the RAN. The RRCs 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 via ‘signaling messages’, referred to as ‘RRC messages’. RRC messages may be transmitted between the UE 210 and the RAN using signaling radio bearers and the same/similar PDCP, RLC, MAC, and PHY protocol layers... RRCs 216 and 226 may provide ‘control plane functionality’ such as: broadcast of system information related to AS and NAS; paging initiated by the CN or the RAN; establishment, maintenance and release of an RRC connection between the UE 210 and the RAN; security functions including key management; “Establishment, configuration, maintenance and release of Signaling Radio Bearers and Data Radio Bearers”; mobility functions; ‘QoS management functions’; the UE measurement reporting and control of the reporting; detection of and recovery from radio link failure (RLF); and/or NAS message transfer. As part of establishing an ‘RRC connection’, RRCs 216 and 226 may establish an RRC context, which may involve configuring ‘parameters’ for communication between the UE 210 and the RAN {which includes the gNB / Base Station}) [0098; Figs. 1a-b & 2a-b]; and
transmitting data packets between the base station and the UE through the DRB, wherein data packets are transmitted using different transmission quality parameters (Chae: e.g., As part of establishing an RRC connection, RRCs 216 and 226 may establish an ‘RRC context’, which may involve configuring ‘parameters’ for communication between the UE 210 and the RAN…..In RRC connected 602, the UE has an established ‘RRC context’ and may have at least one ‘RRC connection’ with a Base station. The Base station may be similar to one of the one or more base stations included in the RAN 104 depicted in FIG. 1A, one of the gNBs 160 or ng-eNBs 162 depicted in FIG. 1B, the gNB 220 depicted in FIG. 2A and FIG. 2B, or any other ‘base station’ described in the present disclosure. The Base station with which the UE is connected may have the RRC context for the UE. The RRC context, referred to as the ‘UE context’, may comprise ‘parameters’ for communication between the UE and the base station. These ‘parameters’ may include, for example: one or more AS contexts; one or more ‘Radio link Configuration Parameters’; ‘Bearer Configuration information’ {i.e., relating to a ‘Data Radio Bearer’, Signaling radio bearer, logical channel, ‘QoS flow’, and/or PDU session); security information; and/or PHY, MAC, RLC, PDCP, and/or SDAP layer configuration information. While in RRC connected 602, mobility of the UE may be managed by the RAN (e.g., the RAN 104 or the NG-RAN 154). The UE may measure the ‘signal levels’ (e.g., reference signal levels) from a serving cell and neighboring cells and report these measurements to the Base station currently serving the UE ) [0098-0100; Fig. 6] (e.g., As illustrated in FIG. 1B, the 5G-CN 152 includes an Access and Mobility Management Function (AMF) 158A and a User Plane Function (UPF) 158B, which are shown as one component AMF/UPF 158 in FIG. 1B for ease of illustration. The UPF 158B may serve as a gateway between the NG-RAN 154 and the one or more DNs. The UPF 158B may perform functions such as ‘packet routing and forwarding’, packet inspection and user plane policy rule enforcement, traffic usage reporting, ‘uplink classification to support routing of traffic flows to the one or more DNS’, ‘quality of service (QOS) handling for the user plane (e.g., packet filtering, gating, uplink/downlink rate enforcement, and uplink traffic verification), downlink packet buffering’, and downlink data notification triggering ) [0053; Fig. 1b] (e.g., FIG. 3 illustrates an example of services provided between protocol layers of the NR user plane protocol stack. Starting from the top of FIG. 2A and FIG. 3, the SDAPs 215 and 225 may perform ‘QoS flow handling’. The UE 210 may receive services through a ‘PDU {packet data unit} session’, which may be a logical connection between the UE 210 and a DN. The ‘PDU session’ may have one or more ‘QoS flows’. A UPF of a CN (e.g., the UPF 158B) may map ‘IP packets’ to the one or more ‘QoS flows’ of the PDU session based on ‘QoS {parameter} requirements’ (e.g., in terms of {packet} ‘delay’, ‘data rate’, and/or ‘error rate’). The SDAPs 215 and 225 may perform mapping/de-mapping between the one or more ‘QoS flows’ and one or more ‘Data Radio Bearers’. The mapping/de-mapping between the QoS flows and the data radio bearers may be determined by the SDAP 225 at the gNB 220. The SDAP 215 at the UE 210 may be ‘informed’ of the ‘mapping between the QoS flows and the Data Radio Bearers through reflective mapping or control signaling received from the gNB 220 {Base Station}. For ‘reflective mapping’, the SDAP 225 at the gNB 220 may mark the downlink packets with a QoS flow indicator (QFI), which may be observed by the SDAP 215 at the UE 210 to determine the mapping/de-mapping between the QoS flows and the data radio bearers…The PDCPs 214 and 224 may perform header compression/decompression to reduce the amount of data that needs to be ’transmitted’ over the air interface, ciphering / deciphering to prevent unauthorized decoding of data transmitted over the air interface, and integrity protection (to ensure control messages originate from intended sources. The PDCPs 214 and 224 may perform ‘retransmissions of undelivered packets’, ‘in-sequence delivery and reordering of packets’, and removal of packets received in duplicate due to, for example, an intra-gNB handover. The PDCPs 214 and 224 may perform packet duplication to improve the likelihood of the packet being received and, at the receiver, remove any duplicate packets. Packet duplication may be useful for services that require high reliability ) [0064-0065; Figs. 2a-b & 3], and wherein the transmission quality parameters for each data packet are determined from information within the MAC header (Chae: e.g., FIG. 4B illustrates an example format of a ‘MAC subheader’ in a MAC PDU. The MAC subheader includes: an SDU length field for indicating the length (e.g., in bytes) of the MAC SDU to which the MAC subheader corresponds; a Logical channel identifier (LCID) field for identifying the logical channel from which the MAC SDU originated to aid in the demultiplexing process; a Flag (F) for indicating the size of the SDU length field; and a Reserved bit (R) field for future use) [0073; Fig. 4b] (e.g., The RRCs 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 or, more generally, between the UE 210 and the RAN. The RRCs 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 via ‘signaling messages’, referred to as ‘RRC messages’. RRC messages may be transmitted between the UE 210 and the RAN using signaling radio bearers and the same/similar PDCP, RLC, ‘MAC, and PHY protocol layers’. The MAC may multiplex control-plane and user-plane data into the same transport block (TB). The RRCs 216 and 226 may provide ‘control plane functionality’ such as: broadcast of system information related to AS and NAS; paging initiated by the CN or the RAN; establishment, maintenance and release of an RRC connection between the UE 210 and the RAN; security functions including key management; establishment, configuration, maintenance and release of signaling radio bearers and data radio bearers; mobility functions; QoS management functions; the UE measurement reporting and control of the reporting; detection of and recovery from radio link failure (RLF); and/or NAS message transfer. As part of establishing an RRC connection, RRCs 216 and 226 may establish an ‘RRC context’, which may involve configuring ‘parameters’ for communication between the UE 210 and the RAN ) [0098; Fig. 4b].
Claim(s) 14, 15 recite(s) substantially the same limitations / features as claim 1, is/are distinguishable only by its/their statutory category (Device / apparatus, Computer Program Product, apparatus / device), and accordingly rejected on the same basis.
As per claim{s} 2, Chae discloses the method wherein the transmission quality parameters for each data packet are determined by the base station (Chae: e.g., As part of establishing an RRC connection, RRCs 216 and 226 may establish an ‘RRC context’, which may involve configuring ‘parameters’ for communication between the UE 210 and the RAN…..In RRC connected 602, the UE has an established ‘RRC context’ and may have at least one ‘RRC connection’ with a Base station. The Base station may be similar to one of the one or more base stations included in the RAN 104 depicted in FIG. 1A, one of the gNBs 160 or ng-eNBs 162 depicted in FIG. 1B, the gNB 220 depicted in FIG. 2A and FIG. 2B, or any other ‘base station’ described in the present disclosure. The Base station with which the UE is connected may have the ‘RRC context’ for the UE. The RRC context, referred to as the ‘UE context’, may comprise ‘parameters’ for communication between the UE and the base station. These ‘parameters’ may include, for example: one or more AS contexts; one or more ‘Radio link Configuration Parameters’; ‘Bearer Configuration information’ {i.e., relating to a ‘Data Radio Bearer’, Signaling radio bearer, logical channel, ‘QoS flow’, and/or PDU session); security information; and/or PHY, MAC, RLC, PDCP, and/or SDAP layer configuration information. While in RRC connected 602, mobility of the UE may be managed by the RAN (e.g., the RAN 104 or the NG-RAN 154). The UE may measure the ‘signal levels’ (e.g., reference signal levels) from a serving cell and neighboring cells and report these measurements to the Base station currently serving the UE ) [0098-0100; Fig. 6].
As per claim{s} 4, Chae discloses the method wherein information is included within a R field within the MAC header (Chae: e.g., FIG. 4B illustrates an example format of a ‘MAC subheader’ in a MAC PDU. The MAC subheader includes: an SDU length field for indicating the length (e.g., in bytes) of the MAC SDU to which the MAC subheader corresponds; a Logical channel identifier (LCID) field for identifying the logical channel from which the MAC SDU originated to aid in the demultiplexing process; a Flag (F) for indicating the size of the SDU length field; and a ‘Reserved bit (R)’ field for future use) [0073; Fig. 4b].
As per claim{s} 5, Chae discloses the method wherein information is included within a R field within the MAC header (Chae: e.g., FIG. 4B illustrates an example format of a ‘MAC subheader’ in a MAC PDU. The MAC subheader includes: an SDU length field for indicating the length (e.g., in bytes) of the MAC SDU to which the MAC subheader corresponds; a ‘Logical channel identifier’ (LCID) field for identifying the logical channel from which the MAC SDU originated to aid in the demultiplexing process; a Flag (F) for indicating the size of the SDU length field; and a ‘Reserved bit (R)’ field for future use) [0073; Fig. 4b].
As per claim{s} 6, Chae discloses the method wherein the transmission quality parameters comprise any one or more of: 5QI value, priority level, packet error rate, maximum data burst volume, averaging window, bit rate, resource type, and packet delay budget (Chae: e.g., FIG. 3 illustrates an example of services provided between protocol layers of the NR user plane protocol stack. Starting from the top of FIG. 2A and FIG. 3, the SDAPs 215 and 225 may perform ‘QoS flow handling’. The UE 210 may receive services through a ‘PDU {packet data unit} session’, which may be a logical connection between the UE 210 and a DN. The ‘PDU session’ may have one or more ‘QoS flows’. A UPF of a CN (e.g., the UPF 158B) may map ‘IP packets’ to the one or more ‘QoS flows’ of the PDU session based on ‘QoS {parameter} requirements’ (e.g., in terms of {packet} ‘delay’, ‘data rate’, and/or ‘error rate’). The SDAPs 215 and 225 may perform mapping/de-mapping between the one or more ‘QoS flows’ and one or more ‘Data Radio Bearers’ ) [0064; Figs. 2a-b & 3].
As per claim{s} 7, Chae discloses the method further comprising configuring the UE with a set of parameters based on the different transmission quality parameters (Chae: e.g., he RRCs 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 or, more generally, between the UE 210 and the RAN. The RRCs 216 and 226 may provide ‘control plane functionality’ between the UE 210 and the gNB 220 via ‘signaling messages’, referred to as ‘RRC messages’. RRC messages may be transmitted between the UE 210 and the RAN using signaling radio bearers and the same/similar PDCP, RLC, ‘MAC, and PHY protocol layers’. The MAC may multiplex control-plane and user-plane data into the same transport block (TB). The RRCs 216 and 226 may provide ‘control plane functionality’ such as: broadcast of system information related to AS and NAS; paging initiated by the CN or the RAN; establishment, maintenance and release of an RRC connection between the UE 210 and the RAN; security functions including key management; establishment, ‘configuration’, maintenance and release of signaling radio bearers and data radio bearers; mobility functions; QoS management functions; the UE measurement reporting and control of the reporting; detection of and recovery from radio link failure (RLF); and/or NAS message transfer. As part of establishing an RRC connection, RRCs 216 and 226 may establish an ‘RRC context’, which may involve configuring ‘parameters’ for communication between the UE 210 and the RAN ) [0098; Fig. 4b].
As per claim{s} 8, Chae discloses the method wherein the set of parameters comprise the number of hybrid automatic repeat request (HARQ) repetitions (Chae: e.g., The MACs 212 and 222 may be configured to perform error correction through Hybrid Automatic Repeat Request (HARQ) {i.e., one HARQ entity per carrier in case of Carrier Aggregation (CA)}, priority handling between logical channels of the UE 210 by means of logical channel prioritization, and/or padding) [0068] (e.g., The UE may transmit uplink control signaling (e.g., uplink control information (UCI) to a base station. The uplink control signaling may comprise hybrid automatic repeat request (HARQ) acknowledgements for received DL-SCH transport blocks. The UE may transmit the HARQ acknowledgements after receiving a DL-SCH transport block. Uplink control signaling may comprise channel state information (CSI) indicating channel quality of a physical downlink channel. The UE may transmit the CSI to the base station. The base station, based on the received CSI, may determine transmission format parameters (e.g., comprising multi-antenna and beamforming schemes) for a downlink transmission. Uplink control signaling may comprise scheduling requests (SR). The UE may transmit an SR indicating that uplink data is available for transmission to the base station. The UE may transmit a UCI (e.g., HARQ acknowledgements (HARQ-ACK), CSI report, SR, and the like) via a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH)) [0197] and/or DRX-RetransmissionTimerUL (Chae: e.g., FIG. 4B further illustrates MAC control elements (CEs) inserted into the MAC PDU by a MAC, such as MAC 223 or MAC 222. For example, FIG. 4B illustrates two MAC CEs inserted into the MAC PDU. MAC CEs may be inserted at the beginning of a MAC PDU for downlink transmissions (as shown in FIG. 4B) and at the end of a MAC PDU for uplink transmissions. MAC CEs may be used for in-band control signaling. Example ‘MAC CEs’ include: scheduling-related MAC CEs, such as buffer status reports and power headroom reports; activation/deactivation MAC CEs, such as those for activation/deactivation of PDCP duplication detection, channel state information (CSI) reporting, sounding reference signal (SRS) transmission, and prior configured components; ‘Discontinuous Reception (DRX) related MAC CEs’; timing advance MAC CEs; and random access related MAC CEs) [0074; Fig. 4b].
As per claim{s} 9, Chae discloses the method wherein the data packets are transmitted using different transmission quality parameters and data packets of separate data flows and/or data packet types (Chae: e.g., FIG. 3 illustrates an example of services provided between protocol layers of the NR user plane protocol stack. Starting from the top of FIG. 2A and FIG. 3, the SDAPs 215 and 225 may perform QoS flow handling. The UE 210 may receive services through a ‘PDU session’, which may be a logical connection between the UE 210 and a DN. The PDU session may have ‘one or more QoS flows’. A UPF of a CN (e.g., the UPF 158B) may ‘map’ IP packets to the one or more QoS flows of the PDU session based on QoS {parameter} requirements (e.g., in terms of {packet} ‘delay’, ‘data rate’, and/or ‘error rate’). The SDAPs 215 and 225 may perform ‘mapping’/de-mapping between the one or more QoS flows and one or more Data Radio Bearers. The ‘mapping’/de-mapping between the QoS flows and the Data Radio Bearers may be determined by the SDAP 225 at the gNB 220 {Base Station}. The SDAP 215 at the UE 210 may be ‘informed’ of the mapping between the QoS flows and the Data Radio Bearers through reflective mapping or control signaling received from the gNB 220. For reflective mapping, the SDAP 225 at the gNB 220 may mark the downlink packets with a QoS flow indicator (QFI), which may be observed by the SDAP 215 at the UE 210 to determine the mapping/de-mapping between the QoS flows and the data radio bearers… The PDCPs 214 and 224 may perform header compression/decompression to reduce the amount of data that needs to be transmitted over the air interface, ciphering / deciphering to prevent unauthorized decoding of data transmitted over the air interface, and integrity protection (to ensure control messages originate from intended sources). The PDCPs 214 and 224 may perform ‘retransmissions’ of undelivered packets, ‘in-sequence delivery’ and reordering of packets, and removal of packets received in duplicate due to, for example, an intra-gNB handover. ) [0064-0065; Fig. 3] (e.g., ‘transmission parameter{s}’ ) [0239-0242; Figs. 17a-b].
As per claim{s} 12, Chae discloses the method wherein the data packets transmitted between the base station and the UE are uplink data packets (Chae: e.g., As illustrated in FIG. 1B, the 5G-CN 152 includes an Access and Mobility Management Function (AMF) 158A and a User Plane Function (UPF) 158B, which are shown as one component AMF/UPF 158 in FIG. 1B for ease of illustration. The UPF 158B may serve as a gateway between the NG-RAN 154 and the one or more DNs. The UPF 158B may perform ‘functions’ such as ‘packet routing and forwarding’, packet inspection and user plane policy rule enforcement, traffic usage reporting, ‘Uplink’ classification to support routing of traffic flows to the one or more DNS, ‘Quality of Service (QOS) handling’ for the user plane {i.e., packet filtering, gating, uplink/downlink rate enforcement, and ‘uplink traffic verification’}, downlink packet buffering, and downlink data notification triggering) [0053; Fig.1b] (e.g., FIG. 4A illustrates a ‘downlink’ data flow of three ‘IP packets’ (n, n+1, and m) through the NR user plane protocol stack to generate two TBs at the gNB 220. An ‘Uplink’ data flow through the NR user plane protocol stack may be ‘similar’ to the Downlink data flow depicted in FIG. 4A) [0070; Fig. 4a].
As per claim{s} 13, Chae discloses the method wherein the uplink data packets are transmitted on a physical uplink shared channel, PUSCH (Chae: e.g., The PHY may use ‘physical channels’ to pass information between processing levels of the PHY. A physical channel may have an associated set of time-frequency resources for carrying the information of one or more transport channels. The PHY may generate control information to support the low-level operation of the PHY and provide the control information to the lower levels of the PHY via physical control channels, known as L1/L2 control channels. The set of physical channels and physical control channels defined by NR include, among others, a Physical uplink shared channel (PUSCH) for carrying uplink data and signaling messages from the UL-SCH and in some instances uplink control information [UCI]) [0088] (e.g., The UE may transmit uplink transmissions {i.e., PUCCH or ‘PUSCH’} in an uplink BWP according to a configured numerology {i.e., subcarrier spacing and cyclic prefix length for the uplink BWP} ) [0118].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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) 10, 11 is/are rejected under 35 U.S.C. 103 as being disclosed by Chae in view of Fu et al (hereinafter Fu), US Patent Pub 20240244476 A1 (effective / priority date to CON PCT/CN2021/110388 August 2021).
As per claim{s} 10, Chae discloses substantial features of the invention above but does not expressly disclose the additional recited feature of the method wherein different data packet types are transmitted using different transmission quality parameters where data packets of the same type have the same transmission quality parameters.
However, in a related endeavor, Fu particularly discloses the additional recited feature(s) of the method wherein different data packet types are transmitted using different transmission quality parameters where data packets of the same type have the same transmission quality parameters (Fu: e.g., At S42, the SMF entity determines an appropriate QoS flow for the received PCC rule according to the PCC rule and other information (such as UE subscription information), so as to transmit the service data stream corresponding to the PCC rule. Specifically, (a), one QoS flow may be used to transmit a ‘plurality of service data streams’, and is a collection of service data streams having the same QoS requirement. (b) a plurality of service data streams of an object (such as application, a service, an application server) are ‘mapped’ to different QoS flows, and different QoS flows correspond to ‘different types of frames’ (for example, ‘I-frame’ and ‘P-frame’), or different QoS flows correspond to different types of data streams. (c) Optionally, the type information is informed to the Base station through the QoS flow configuration) [0397-0400].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify and/or combine Chae’s invention with the above said additional feature, as expressly disclosed by Fu, for the motivation of providing a method for wireless communication and devices, which can implement the mapping between the data stream and the QoS flow, or the mapping between the service and the QoS flow, or the mapping between the application and the QoS flow, thereby satisfying different transmission requirements [Fu: Abstract, 0003; Fig. 1].
As per claim{s} 11, Chae in view of Fu, and Fu in particular, discloses the method wherein the different data packet types comprise I and P frames (Fu: e.g., At S15, after the QoS flow configuration information and the TSCAI information are received, the base station configures the corresponding wireless side resources. (a) optionally, for the UL, the ‘relevant information of the first type of frame’ or the recommended corresponding ‘configuration information’ may also be ‘indicated’ to the Base station through the UE. Specifically, (b) the relevant information of the first type of frame: an arrival time of the first type of frame, an deviation of the arrival time of the first type of frame, a cycle of the first type of frame, a size of the first type of frame or IP 5-tuple information of different types of frames. (c) the relevant information of the first type of frame may further include a ‘correspondence’ between the first type of frame and (b), or a correspondence between the identification of the first type of frame and (b) {i.e., for determining which is an ‘I-frame’ is, which is a ‘P-frame’ or B-frame is, etc.) [0332-0338].
Conclusion
Applicant’s amendment necessitated the same grounds of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.06(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 extension fee 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 GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, 9am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Christopher Parry can be reached on 571-272- 8328. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/GLENFORD J MADAMBA/ Primary Examiner, Art Unit 2451