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 .
This office action is in response to the application serial number 18/808,595 filed on 08/19/2024.
Claims 1, 2-5, 6, 7-10, 11, 12-15, 16, 17-20 are pending.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. REPUBLIC OF KOREA 10-2020-0071847, filed on 06/12/2020.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/13/2025, 11/21/2025, 04/23/2026 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 5, 6, 7, 9, 10, 11, 12, 14, 15, 16, 17, 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over QI et al. ( US 20230023919, hereinafter, QI’s 919) in view of CHEN et al. ( US 20230040690, Provisional Application No. 62959741).
Regarding to the claim 1, US 20230023919 teaches a method performed by a user equipment (UE) in a wireless communication system, the method comprising:
receiving, via a radio resource control (RRC) message (release of an RLC bearer ) [see Paragraph 0054 ] , configuration information for a multicast broadcast service (MBS) ( Multicast / Broadcast Radio Bearer (MBR) configuration which servers the multicast / broadcast service ) [see Paragraph 0052 ] ;
wherein the MBS is received via a multicast bearer for the MBS [see Paragraphs 0070 – 0071 ] ( [0070] In some embodiments, the RLC bearer of a certain MRB serving the multicast/broadcast service in the configuration received by the UE is a typel attribute, and the UE performs reception of the multicast/broadcast service according to the RLC bearer included in the cell group configuration in the reconfiguration message. In this case, the UE receives the multicast/broadcast service in a PTP manner. The process is as follows. The UE receives data according to the UE-specific physical layer identifier, such as C-RNTI (Cell-Radio Network Temporary Identifier) or Configured Scheduling RNTI (CS-RNTI). Then, the MAC entity delivers the MAC PDU to the appropriate logical channel (LCH) according to the LCID in the data packet and the RLC bearer configuration, and then the corresponding RLC entity and PDCP entity will receive and process the multicast/broadcast service data in the corresponding layer. ) , and
wherein a packet data convergence protocol (PDCP) entity, a radio link control (RLC) entity, a medium access control (MAC) entity, a physical layer entity, and a service data adaptation protocol (SDAP) entity [see Paragraph 0052] [see Paragraphs 0007-0009]
[0007] In some embodiments, the multicast radio resource configuration information may include a multicast radio bearer configuration of a multicast radio bearer serving the multicast service, a service data adaptation protocol (SDAP) configuration, a packet data convergence protocol (PDCP) configuration, a radio link control (RLC) bearer configuration, an RLC configuration, or a multicast medium access control (MAC) and physical (PHY) layer configuration set.
[0008] In some embodiments, the multicast radio resource configuration information may include at least one operation corresponding to a multicast radio bearer configuration, an RLC bearer configuration, or a MAC and PHY layer configuration set. In some embodiments, the SDAP configuration may include a multicast service session identifier for identifying a session corresponding to the multicast service
[0009] In some embodiments, for multicast radio bearer configured with one RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer may be associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions. In some embodiments, for multicast radio bearer configured with one RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer may be associated with the at least one UM DL RLC entity. In some embodiments, for multicast radio bearer configured with both type 1 and type 2 RLC bearers, each PDCP entity corresponding to the multicast radio bearer may be associated with: the AM RLC entity or the UM RLC entities, and the at least one UM DL RLC entity)
And a service data adaptation protocol (SDAP) entity are configured for the multicast bearer for the MBS [see Paragraph 0056 ] ( The QoS Flow data are mapped to one or more MRBs by the SDAP entity associated with the multicast/broadcast service (note that each QoS Flow can only be mapped to one specific MRB), and each MRB is associated with one PDCP entity.).
However, US 20230023919 does not explicitly teach entering an RRC inactive state based on receiving the RRC release message; and receiving, based on the configuration information for the MBS, the MBS in the RRC inactive state.
( US 20230040690, Provisional Application No. 62959741), from the same or similar fields of endeavor, teaches receiving, via a radio resource control (RRC) message, configuration information for a multicast broadcast service (MBS) [see Paragraphs 0130 & 0132 ] [see the Provisional Application 62959741, Page 13 – Page 14 ]
( A UE (e.g., in RRC_IDLE state or RRC_INACTIVE state) may receive the MBS-related control information/associated configuration(s) via a Broadcast Control Channel (BCCH) and/or a MCCH. For example, a new SIB may be used to accommodate the configuration of MBS-related control information ) ;
entering an RRC inactive state based on receiving the RRC release message [ see Paragraph 0073 ] (a UE in RRC_INACTIVE state (which is referred to as an “RRC_INACTIVE UE”) or in RRC_IDLE state (which is referred to as an “RRC_IDLE UE”) may report to the network about its capability of supporting receiving MBS (e.g., MBS with low QoS requirements). The UE's capability may be reported to the network via an RA procedure (e.g., a 2-step RA procedure or a 4-step RA procedure) or via preconfigured PUSCH resource(s), where the preconfigured PUSCH resource(s) may be configured via dedicated signaling (e.g., via an RRC Release message) or broadcast in system information. In some implementations, an RRC_IDLE UE or an RRC_INACTIVE UE may report its capability of supporting receiving MBS based on a network instruction or predefined rules, where the network instruction may be provided by dedicated signaling and/or system information broadcast by the network) [see the Provisional Application 62959741, Page 13 – Page 14 ] ; and
receiving, based on the configuration information for the MBS (the configuration of MBS-related control information) , the MBS in the RRC inactive state [see Paragraph 0130 & 0132 ]
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the system of US 20230023919 in view US 20230040690 because US 20230040690 suggests that a QoS flow may be allocated and mapped to one or more radio communication resources for carrying data loads associated with the QoS flow.
Regarding to the claim 2, US 20230023919 further teaches wherein the SDAP entity provides mapping between a quality of service (QoS) flow and the multicast bearer for the MBS [see Paragraph 0056] ( The QoS Flow data are mapped to one or more MRBs by the SDAP entity associated with the multicast/broadcast service (note that each QoS Flow can only be mapped to one specific MRB), and each MRB is associated with one PDCP entity.).
Regarding to the claim 4 , US 20230023919 further teaches wherein the RLC entity includes an RLC unacknowledged mode (UM) entity for a multicast transmission [see Paragraphs 0061-0063 & 0131] ([0061] For MRB configured with one RLC bearer of type 1, each PDCP entity may be associated with one AM (Acknowledged Mode) RLC entity, or two UM (Unacknowledged Mode) RLC entities (one for each direction), each comprising or corresponding to an RLC entity of type 1 (or type 1 RLC entity). In this case, an MRB serving the multicast/broadcast service may be associated with a type 1 RLC bearer. The associated RLC entity and the RLC bearer is of PTP type. The RLC entity may be of AM attribute or of UM attribute. In this case, the UE is receiving the MRB data of the multicast/broadcast service in the PTP manner. The network may configure the corresponding RLC entity as AM attribute or UM attribute, according to the characteristics of the service. For example, in the QoS characteristics corresponding to an MRB of a multicast/broadcast service, if the packet delay budget is high and the packet error rate is low, the corresponding RLC entity can be configured to be AM mode. If the packet delay budget is low and the packet error rate is high, the corresponding RLC entity can be configured to be UM mode.).
Regarding to the claim 5, US 20230023919 further teaches wherein the MBS is scheduled by using a radio network temporary identifier (RNTI) of the multicast transmission [see Paragraph 0017] ( [0017] In some embodiments, the wireless communication device may receive an indication of the enabling or disabling operation of the configuration via RRC signaling layer 1 signaling. The layer 1 signaling comprises a MAC control element (CE) or downlink control information (DCI). The MAC CE or DCI may include an identifier of the multicast service. In some embodiments, the associated identifier is identified by a G-RNTI or session identifier to identify the multicast service, or an identifier that other wireless communication devices can use to identify the multicast service. In some embodiments, the disabling operation may include releasing a corresponding RLC bearer. In some embodiments, the disabling operation may include suspension of an RLC bearer without removing or by retaining (e.g., potentially for later use) the configuration of the RLC bearer. ).
Regarding to the claim 6, US 20230023919 teaches a method performed by a base station in a wireless communication system, the method comprising:
transmitting, via a radio resource control (RRC) message (release of an RLC bearer ) [see Paragraph 0054 ], configuration information for a multicast broadcast service (MBS) to a user equipment (UE) ( Multicast / Broadcast Radio Bearer (MBR) configuration which servers the multicast / broadcast service ) [see Paragraph 0052 ];
wherein the MBS is received via a multicast bearer for the MBS [see Paragraphs 0070 – 0071 ] ( [0070] In some embodiments, the RLC bearer of a certain MRB serving the multicast/broadcast service in the configuration received by the UE is a typel attribute, and the UE performs reception of the multicast/broadcast service according to the RLC bearer included in the cell group configuration in the reconfiguration message. In this case, the UE receives the multicast/broadcast service in a PTP manner. The process is as follows. The UE receives data according to the UE-specific physical layer identifier, such as C-RNTI (Cell-Radio Network Temporary Identifier) or Configured Scheduling RNTI (CS-RNTI). Then, the MAC entity delivers the MAC PDU to the appropriate logical channel (LCH) according to the LCID in the data packet and the RLC bearer configuration, and then the corresponding RLC entity and PDCP entity will receive and process the multicast/broadcast service data in the corresponding layer. ) , and
wherein a packet data convergence protocol (PDCP) entity, a radio link control (RLC) entity, a medium access control (MAC) entity, a physical layer entity, and a service data adaptation protocol (SDAP) entity [see Paragraph 0052] [see Paragraphs 0007-0009]
[0007] In some embodiments, the multicast radio resource configuration information may include a multicast radio bearer configuration of a multicast radio bearer serving the multicast service, a service data adaptation protocol (SDAP) configuration, a packet data convergence protocol (PDCP) configuration, a radio link control (RLC) bearer configuration, an RLC configuration, or a multicast medium access control (MAC) and physical (PHY) layer configuration set.
[0008] In some embodiments, the multicast radio resource configuration information may include at least one operation corresponding to a multicast radio bearer configuration, an RLC bearer configuration, or a MAC and PHY layer configuration set. In some embodiments, the SDAP configuration may include a multicast service session identifier for identifying a session corresponding to the multicast service
[0009] In some embodiments, for multicast radio bearer configured with one RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer may be associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions. In some embodiments, for multicast radio bearer configured with one RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer may be associated with the at least one UM DL RLC entity. In some embodiments, for multicast radio bearer configured with both type 1 and type 2 RLC bearers, each PDCP entity corresponding to the multicast radio bearer may be associated with: the AM RLC entity or the UM RLC entities, and the at least one UM DL RLC entity)
And a service data adaptation protocol (SDAP) entity are configured for the multicast bearer for the MBS [see Paragraph 0056 ] ( The QoS Flow data are mapped to one or more MRBs by the SDAP entity associated with the multicast/broadcast service (note that each QoS Flow can only be mapped to one specific MRB), and each MRB is associated with one PDCP entity.).
However, US 20230023919 does not explicitly teach wherein the RRC release message causes the UE to enter an RRC inactive state.
( US 20230040690, Provisional Application No. 62959741), from the same or similar fields of endeavor, teaches transmitting, via a radio resource control (RRC) release message, configuration information for a multicast broadcast service (MBS) to a user equipment (UE) [see Paragraphs 0130 & 0132],
wherein the RRC release message causes the UE to enter an RRC inactive state [see Paragraph 0073] (a UE in RRC_INACTIVE state (which is referred to as an “RRC_INACTIVE UE”) or in RRC_IDLE state (which is referred to as an “RRC_IDLE UE”) may report to the network about its capability of supporting receiving MBS (e.g., MBS with low QoS requirements). The UE's capability may be reported to the network via an RA procedure (e.g., a 2-step RA procedure or a 4-step RA procedure) or via preconfigured PUSCH resource(s), where the preconfigured PUSCH resource(s) may be configured via dedicated signaling (e.g., via an RRC Release message) or broadcast in system information. In some implementations, an RRC_IDLE UE or an RRC_INACTIVE UE may report its capability of supporting receiving MBS based on a network instruction or predefined rules, where the network instruction may be provided by dedicated signaling and/or system information broadcast by the network) [see the Provisional Application 62959741, Page 13 – Page 14 ] ;
transmitting, based on the configuration information for the MBS (the configuration of MBS-related control information) , the MBS in the RRC inactive state [see Paragraph 0130 & 0132 ] [see the Provisional Application 62959741, Page 13 – Page 14 ].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the system of US 20230023919 in view US 20230040690 because US 20230040690 suggests that a QoS flow may be allocated and mapped to one or more radio communication resources for carrying data loads associated with the QoS flow.
Regarding to the claim 7, claim 7 is rejected the same limitations of the claim 2 above.
Regarding to the claim 9, claim 9 is rejected the same limitations of the claim 4 above.
Regarding to the claim 10, claim 10 is rejected the same limitations of the claim 5 above.
Regarding to the claim 11, US 20230023919 teaches a user equipment (UE) in a wireless communication system, the UE comprising: a transceiver; and at least one processor operatively connected with the transceiver and configured to:
receive, via a radio resource control (RRC) message (release of an RLC bearer ) [see Paragraph 0054 ] , configuration information for a multicast broadcast service (MBS) ( Multicast / Broadcast Radio Bearer (MBR) configuration which servers the multicast / broadcast service ) [see Paragraph 0052 ] ;
wherein the MBS is received via a multicast bearer for the MBS [see Paragraphs 0070 – 0071 ] ( [0070] In some embodiments, the RLC bearer of a certain MRB serving the multicast/broadcast service in the configuration received by the UE is a typel attribute, and the UE performs reception of the multicast/broadcast service according to the RLC bearer included in the cell group configuration in the reconfiguration message. In this case, the UE receives the multicast/broadcast service in a PTP manner. The process is as follows. The UE receives data according to the UE-specific physical layer identifier, such as C-RNTI (Cell-Radio Network Temporary Identifier) or Configured Scheduling RNTI (CS-RNTI). Then, the MAC entity delivers the MAC PDU to the appropriate logical channel (LCH) according to the LCID in the data packet and the RLC bearer configuration, and then the corresponding RLC entity and PDCP entity will receive and process the multicast/broadcast service data in the corresponding layer. ) , and
wherein a packet data convergence protocol (PDCP) entity, a radio link control (RLC) entity, a medium access control (MAC) entity, a physical layer entity, and a service data adaptation protocol (SDAP) entity [see Paragraph 0052] [see Paragraphs 0007-0009]
[0007] In some embodiments, the multicast radio resource configuration information may include a multicast radio bearer configuration of a multicast radio bearer serving the multicast service, a service data adaptation protocol (SDAP) configuration, a packet data convergence protocol (PDCP) configuration, a radio link control (RLC) bearer configuration, an RLC configuration, or a multicast medium access control (MAC) and physical (PHY) layer configuration set.
[0008] In some embodiments, the multicast radio resource configuration information may include at least one operation corresponding to a multicast radio bearer configuration, an RLC bearer configuration, or a MAC and PHY layer configuration set. In some embodiments, the SDAP configuration may include a multicast service session identifier for identifying a session corresponding to the multicast service
[0009] In some embodiments, for multicast radio bearer configured with one RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer may be associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions. In some embodiments, for multicast radio bearer configured with one RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer may be associated with the at least one UM DL RLC entity. In some embodiments, for multicast radio bearer configured with both type 1 and type 2 RLC bearers, each PDCP entity corresponding to the multicast radio bearer may be associated with: the AM RLC entity or the UM RLC entities, and the at least one UM DL RLC entity)
And a service data adaptation protocol (SDAP) entity are configured for the multicast bearer for the MBS [see Paragraph 0056 ] ( The QoS Flow data are mapped to one or more MRBs by the SDAP entity associated with the multicast/broadcast service (note that each QoS Flow can only be mapped to one specific MRB), and each MRB is associated with one PDCP entity.).
However, US 20230023919 does not explicitly teach enter an RRC inactive state based on receiving the RRC release message; and receiving, based on the configuration information for the MBS, the MBS in the RRC inactive state.
( US 20230040690, Provisional Application No. 62959741), from the same or similar fields of endeavor, teaches receive, via a radio resource control (RRC) message, configuration information for a multicast broadcast service (MBS) [see Paragraphs 0130 & 0132 ] [see the Provisional Application 62959741, Page 13 – Page 14 ]
( A UE (e.g., in RRC_IDLE state or RRC_INACTIVE state) may receive the MBS-related control information/associated configuration(s) via a Broadcast Control Channel (BCCH) and/or a MCCH. For example, a new SIB may be used to accommodate the configuration of MBS-related control information ) ;
enter an RRC inactive state based on receiving the RRC release message [ see Paragraph 0073 ] (a UE in RRC_INACTIVE state (which is referred to as an “RRC_INACTIVE UE”) or in RRC_IDLE state (which is referred to as an “RRC_IDLE UE”) may report to the network about its capability of supporting receiving MBS (e.g., MBS with low QoS requirements). The UE's capability may be reported to the network via an RA procedure (e.g., a 2-step RA procedure or a 4-step RA procedure) or via preconfigured PUSCH resource(s), where the preconfigured PUSCH resource(s) may be configured via dedicated signaling (e.g., via an RRC Release message) or broadcast in system information. In some implementations, an RRC_IDLE UE or an RRC_INACTIVE UE may report its capability of supporting receiving MBS based on a network instruction or predefined rules, where the network instruction may be provided by dedicated signaling and/or system information broadcast by the network) [see the Provisional Application 62959741, Page 13 – Page 14 ] ; and
receive, based on the configuration information for the MBS (the configuration of MBS-related control information) , the MBS in the RRC inactive state [see Paragraph 0130 & 0132 ]
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the system of US 20230023919 in view US 20230040690 because US 20230040690 suggests that a QoS flow may be allocated and mapped to one or more radio communication resources for carrying data loads associated with the QoS flow.
Regarding to the claim 12, claim 12 is rejected the same limitations of the claim 2 above.
Regarding to the claim 14, claim 14 is rejected the same limitations of the claim 4 above.
Regarding to the claim 15, claim 15 is rejected the same limitations of the claim 5 above.
Regarding to the claim 16, US 20230023919 teaches a base station in a wireless communication system, the base station comprising: a transceiver; and at least one processor operatively connected with the transceiver and configured to:
transmit, via a radio resource control (RRC) message (release of an RLC bearer ) [see Paragraph 0054 ], configuration information for a multicast broadcast service (MBS) to a user equipment (UE) ( Multicast / Broadcast Radio Bearer (MBR) configuration which servers the multicast / broadcast service ) [see Paragraph 0052 ];
wherein the MBS is received via a multicast bearer for the MBS [see Paragraphs 0070 – 0071 ] ( [0070] In some embodiments, the RLC bearer of a certain MRB serving the multicast/broadcast service in the configuration received by the UE is a typel attribute, and the UE performs reception of the multicast/broadcast service according to the RLC bearer included in the cell group configuration in the reconfiguration message. In this case, the UE receives the multicast/broadcast service in a PTP manner. The process is as follows. The UE receives data according to the UE-specific physical layer identifier, such as C-RNTI (Cell-Radio Network Temporary Identifier) or Configured Scheduling RNTI (CS-RNTI). Then, the MAC entity delivers the MAC PDU to the appropriate logical channel (LCH) according to the LCID in the data packet and the RLC bearer configuration, and then the corresponding RLC entity and PDCP entity will receive and process the multicast/broadcast service data in the corresponding layer. ) , and
wherein a packet data convergence protocol (PDCP) entity, a radio link control (RLC) entity, a medium access control (MAC) entity, a physical layer entity, and a service data adaptation protocol (SDAP) entity [see Paragraph 0052] [see Paragraphs 0007-0009]
[0007] In some embodiments, the multicast radio resource configuration information may include a multicast radio bearer configuration of a multicast radio bearer serving the multicast service, a service data adaptation protocol (SDAP) configuration, a packet data convergence protocol (PDCP) configuration, a radio link control (RLC) bearer configuration, an RLC configuration, or a multicast medium access control (MAC) and physical (PHY) layer configuration set.
[0008] In some embodiments, the multicast radio resource configuration information may include at least one operation corresponding to a multicast radio bearer configuration, an RLC bearer configuration, or a MAC and PHY layer configuration set. In some embodiments, the SDAP configuration may include a multicast service session identifier for identifying a session corresponding to the multicast service
[0009] In some embodiments, for multicast radio bearer configured with one RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer may be associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions. In some embodiments, for multicast radio bearer configured with one RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer may be associated with the at least one UM DL RLC entity. In some embodiments, for multicast radio bearer configured with both type 1 and type 2 RLC bearers, each PDCP entity corresponding to the multicast radio bearer may be associated with: the AM RLC entity or the UM RLC entities, and the at least one UM DL RLC entity)
And a service data adaptation protocol (SDAP) entity are configured for the multicast bearer for the MBS [see Paragraph 0056 ] ( The QoS Flow data are mapped to one or more MRBs by the SDAP entity associated with the multicast/broadcast service (note that each QoS Flow can only be mapped to one specific MRB), and each MRB is associated with one PDCP entity.).
However, US 20230023919 does not explicitly teach wherein the RRC release message causes the UE to enter an RRC inactive state.
( US 20230040690, Provisional Application No. 62959741), from the same or similar fields of endeavor, teaches transmit, via a radio resource control (RRC) release message, configuration information for a multicast broadcast service (MBS) to a user equipment (UE) [see Paragraphs 0130 & 0132],
wherein the RRC release message causes the UE to enter an RRC inactive state [see Paragraph 0073] (a UE in RRC_INACTIVE state (which is referred to as an “RRC_INACTIVE UE”) or in RRC_IDLE state (which is referred to as an “RRC_IDLE UE”) may report to the network about its capability of supporting receiving MBS (e.g., MBS with low QoS requirements). The UE's capability may be reported to the network via an RA procedure (e.g., a 2-step RA procedure or a 4-step RA procedure) or via preconfigured PUSCH resource(s), where the preconfigured PUSCH resource(s) may be configured via dedicated signaling (e.g., via an RRC Release message) or broadcast in system information. In some implementations, an RRC_IDLE UE or an RRC_INACTIVE UE may report its capability of supporting receiving MBS based on a network instruction or predefined rules, where the network instruction may be provided by dedicated signaling and/or system information broadcast by the network) [see the Provisional Application 62959741, Page 13 – Page 14 ] ;
transmit, based on the configuration information for the MBS (the configuration of MBS-related control information) , the MBS in the RRC inactive state [see Paragraph 0130 & 0132 ] [see the Provisional Application 62959741, Page 13 – Page 14 ].
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the system of US 20230023919 in view US 20230040690 because US 20230040690 suggests that a QoS flow may be allocated and mapped to one or more radio communication resources for carrying data loads associated with the QoS flow.
Regarding to the claim 17, claim 17 is rejected the same limitations of the claim 2 above.
Regarding to the claim 19, claim 19 is rejected the same limitations of the claim 4 above.
Regarding to the claim 20, claim 20 is rejected the same limitations of the claim 5 above.
Claim(s) 3, 8, 13, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over QI et al. ( US 20230023919, hereinafter, QI’s 919) in view of CHEN et al. ( US20230040690, Provisional Application No. 62959741 ), and further in view of Kim ( US 20050094670, hereinafter, Kim’s 670 )
Regarding to the claim 3, US 20230023919 and ( US 20230040690, Provisional Application No. 62959741) teach the limitations of the claim 1 above.
However, US 20230023919 does not explicitly teach wherein the PDCP entity provides a header compression and decompression function based on a robust header compression (ROHC) or an Ethernet header compression (EHC) and a PDCP reordering function.
US 20050094670, from the same or similar fields of endeavor, teaches wherein the PDCP entity provides a header compression and decompression function based on a robust header compression (ROHC) [see Paragraphs 0031-0032] ( [0031] It is expected that the MBMS data will be provided in the form of IP/UDP/RTP (Internet ProtocoWser Datagram Protocol/Real-Time Transport Protocol) packets, and a multimedia streaming service will be the most important MBMS application service. The use of IP/UDP/RTP is the most effective way to provide the multimedia streaming service. Since the size of an IP/UDP/RTP packet is 40 or 60 bytes, it is not efficient to transmit the IP/UDP/RTP packet without alteration in the radio link. For this reason, header compression and decompression is performed in the PDCP entity as described above with reference to FIG. 3, so that the header is compressed into several bytes and transmitted via the Uu interface. A header compression technique called "Robust Header Compression (ROHC)" will be used for the MBMS service, so that the PDCP entities of the RNC and the UE, which handle the MBMS data, must be provided with an ROHC header compressor and an ROHC header decompressor, respectively. )
or an Ethernet header compression (EHC) and a PDCP reordering function
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to modify the combined system ( US 20230023919 and US 20230030690 ), and further in view of US 20050094670 because US 20050094670 suggests that The present invention relates to a mobile communication system for providing a packet data service, and more particularly to a method for requesting retransmission of packet data received by user equipment when an error occurs in the received packet data.
Regarding to the claim 8, claim 8 is rejected the same limitations of the claim 3 above.
Regarding to the claim 13, claim 13 is rejected the same limitations of the claim 3 above.
Regarding to the claim 18, claim 18 is rejected the same limitations of the claim 3 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUONG T HO whose telephone number is (571)272-3133. The examiner can normally be reached 7:30-4:00.
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, Charles C Jiang can be reached at 571-270-7191. 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.
/CHUONG T HO/Examiner, Art Unit 2412
Prosecution Insights