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 claim amendments / remarks filed by Applicant’s representative on April 10, 2026 via the filing of an RCE re-opening prosecution of the application claims. Claims 1-2 & 4-15 are pending, and claim 3 has been previously canceled.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's RCE submission filed on April 10, 2026 is entered.
Response to Amendments and Remarks
Applicant’s latest filed claim amendments and corresponding remarks dated April 10, 2026 have been fully considered. Applicant’s remarks and/or comments are generally directed to the current claim amendment(s), and accordingly deemed moot in light of the new grounds of rejection provided with this action.
With regards to Applicant’s latest amendments and remarks, Applicant firstly notes and remarks that the independent claim(s), and particularly independent claim 1, has been further amended to now additionally and expressly recite
“A method for communicating data with user equipment (UE), the method comprising:
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, the transmission quality parameters comprise any one or more of: 5QI value, priority level, maximum data burst volume, averaging window, bit rate, resource type, and packet delay budget, and
the transmission quality parameters for each data packet are determined from information within a media access control (MAC) header”.
With respect to the above, Applicant notes and remarks that none of the prior art reference(s) of the rejection [Chae et al, Fu et al], either individually or in combination with other prior art disclosures, expressly and properly discloses or suggests the above amended claim feature(s) or limitation(s) as currently recited by amended independent claim 1 above (and similarly in independent claim 14). In particular, Applicant states or remarks that the prior art of record does not appear to teach at least the now recited amended feature / limitation of “data packets are transmitted using different transmission quality parameters, the transmission quality parameters comprise any one or more of: 5QI value, priority level, maximum data burst volume, averaging window, bit rate, resource type, and packet delay budget, and the transmission quality parameters for each data packet are determined from information within a media access control (MAC) header” -- and thus the amended independent claims are distinguishable over the cited prior art [Applicant Remarks: par 2, pg. 5 – par 4, pg. 5].
In support of his position, Applicant particularly notes and remarks that while Chae describes MAC-layer fields such as LCID and discusses scheduling and prioritization at the MAC layer, those disclosures are directed to identifying logical channels and enforcing prioritization or scheduling decisions based on channel identity. Chae does not disclose using MAC header information to determine a defined set of transmission quality parameters-such as 5QI value, packet delay budget, maximum data burst volume, and related parameters-for a data packet. Instead, the transmission quality characteristics in Chae are configured or associated at the level of logical channels, QoS flows, or scheduling frameworks that are established independently of any per-packet derivation of transmission quality parameters from MAC header information.
Applicant further remarks that Chae fails to disclose associating different data packet types with different corresponding sets of transmission quality parameters as required by the claims. Although MAC headers in Chae may carry identifiers that distinguish logical channels, those identifiers are not used to derive or select a multi-parameter transmission quality profile for a given packet. Rather, they operate within an existing channel-based framework in which transmission behaviors are predefined and enforced, not determined anew based on MAC header information.
Applicant also notes / remarks that Fu does not remedy the deficiencies of Chae.
However, in response to Applicant’s amended feature(s) and associated remarks, the Office asserts and notes that the newly amended feature(s) above are now expressly taught or disclosed in view of teachings and/or disclosures by at least Stojanovski et al, as discussed / cited in a new ground of rejection below with this action.
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) 1-2, 4-9, 12-15 is/are rejected under 35 U.S.C. 103 as being disclosed by Chae et al (hereinafter Chae), US Patent Publication 20240357515 A1 (provisional date December 2021) in view of Stojanovski et al (hereinafter Stojanovski), WIPO Publication WO 2017196386 A1 (pub date November 2017).
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, (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].
But while Chae discloses substantial features of the invention above, he does not expressly disclose the additional recited feature of the method wherein: data packets are transmitted using different transmission quality parameters, the transmission quality parameters comprise any one or more of: 5QI value, priority level, maximum data burst volume, averaging window, bit rate, resource type, and packet delay budget, and the transmission quality parameters for each data packet are determined from information within a media access control (MAC) header.
However, in a related endeavor, Stojanovski particularly discloses the additional recited feature(s) of the method wherein data packets are transmitted using different transmission quality parameters, the transmission quality parameters comprise any one or more of: 5QI value, priority level, maximum data burst volume, averaging window, bit rate, resource type, and packet delay budget (Stojanovski: e.g., Flow Priority Indicator {FPI} value) [0040, 0048, 0060], and the transmission quality parameters for each data packet are determined from information within a media access control (MAC) header (Stojanovski: e.g., A UE can include the applied ‘FPI’ {value / level} in the packet data convergence protocol (PDCP) header, a radio link control (RLC) header, or a media access control (MAC) header of an uplink data unit) [0019] (e.g., Further, a Radio Bearer ID could be implemented to indicate such change, which could be the FPI change itself or designated within an encapsulation header at a PDU session establishment for example. All traffic that requests / demands the same QoS handling can be put on the same FPI, and in this case the Radio Bearer I D can be the FPI itself. If the radio bearer ID is not the FPI or FPI marking (e.g., FPI value or level corresponding to a particular type of data such as GBR, non-GBR, voice, video, gaming, emergency, etc.) itself, then the ‘FPI’ {value / level} or FPI marking can be provided within the PDCP (or RLC or MAC) header, which can be used for different functions ) [0060].
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 Stojanovski, for the motivation of providing a method and system for quality of service (QoS) signaling, and more specifically, to avoiding explicit QoS signaling over the radio interface [Stojanovski: Abstract, 0002; Fig. 1].
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} 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(s) 6 is/are rejected under 35 U.S.C. 103 as being disclosed by Chae in view of Stojanovski and in further view of Huang et al (hereinafter Huang), CN 101932007 A (pub date December 2010).
As per claim{s} 6, the combination of Chae in view of Stojanovski discloses substantial features of the invention above but does not expressly disclose the additional recited feature of the method wherein the transmission quality parameters comprise a packet error rate.
However, in a related endeavor, Huang particularly discloses the additional recited feature(s) of the method wherein the transmission quality parameters comprise a packet error rate (Huang: e.g., ‘error rate’ {Packet Error Loss Rate}) [0013].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify the combination with the above said additional feature, as expressly disclosed by Huang, for the motivation of providing a method for realizing service flow transmission of a mobile terminal and a wireless relay system [Huang: Abstract, 0001; Fig. 1].
Claim(s) 10, 11 is/are rejected under 35 U.S.C. 103 as being disclosed by Chae in view of Stojanovski and in further 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, the combination of Chae in view of Stojanovski 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 the combination 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 Stojanovski 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
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 from 9am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/GLENFORD J MADAMBA/ Primary Examiner, Art Unit 2451
Prosecution Insights