DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 submission filed on 3/17/26 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3, 5-9, and 11, and 13-16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Please see the new rejection below.
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 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jo et al. (US2021/0153282, hereinafter Jo) in view of Jo et al. (US 2020/0196189, hereinafter Jo ‘189) in further view of Jo et al. (US 2021/0136625, hereinafter Jo ‘625).
Regarding claims 1 and 9. A user equipment (UE) (and method) in a wireless communication system (fig. 3), the UE comprising:
a transceiver (fig. 3 item 114); and
a controller coupled with the transceiver (fig. 3 item 120) and configured to:
receiving, from an upper layer, a request for a packet data convergence protocol (PDCP) re-establishment of a PDCP entity, entity (par. 224, When upper layers request a PDCP entity re-establishment, the receiving PDCP entity shall; par. 228, t-reordering is running),
processing a PDCP protocol data unit (PDU) received from a lower layer according to a re-establishment of the lower layer (par. 225, process the PDCP Data PDUs that are received from lower layers due to the re-establishment of the lower layers);
stopping and resetting a reordering timer, in case that the reordering timer is running (par. par. 227 and 242; if t-Reordering is running, (i) stop and reset t-Reordering…)
performing a header decompression for all stored PDCP service data units (SDUs) (par. 228, “deliver all stored PDCP SDUs…after performing header decompression”)
delivering all header decompressed PDCP SDUs to the upper layer in ascending order of associated count values (par. 228 and 242, “deliver all stored PDCP SDUs to the upper layer in ascending order of associated COUNT values after performing header decompression”),
wherein a data radio bearer (DRB) associated with the PDCP entity is par. 214, “when upper layer requests a PDCP entity re-establishment for a radio bearer, the UE shall establish a PDCP entity”, and par. 228, “for UM DRBs”, thus the DRB in this example is associated with a link of an unacknowledged mode, which reads on the entirety of this limitation. However, for clarity and compact prosecution, the examiner has provided a secondary reference that explicitly discloses this feature.). However, although Jo teaches unacknowledged mode DRBs (see above), he does not specifically disclose wherein a data radio bearer (DRB) associated with the PDCP entity is mapped to radio link control (RLC) entity of an unacknowledged mode (UM).
Jo ‘189, in the same field of endeavor, teaches:
wherein a data radio bearer (DRB) associated with the PDCP entity is mapped to radio link control (RLC) entity of an unacknowledged mode (UM) (par. 68 “When upper layers request PDCP re-establishment while the PDCP entity is configured for a DRB mapped on RLC UM”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of (effective) filing to incorporate PDCP entity is mapped to radio link control (RLC) entity of an unacknowledged mode of Jo ‘189 into the method and system of Jo. The motivation for doing so would have been to allow for an improved communication and increase in reliability (Jo ‘189 par. 8). However, although the combination of Jo and Jo ‘189 disclose header decompression and the specifics of the claims as noted above, they do not specifically disclose a request for PDCP re-establishment of a PDCP entity, configured with an ethernet header compression (EHC) (par. ) or that the performing header decompression for all stored PDCP service data units (SDUs) is using the EHC configured for the PDCP entity. Jo ‘625, in the same field of endeavor, teaches that a request for PDCP re-establishment of a PDCP entity, configured with an ethernet header compression (EHC) (par. 106 discusses PDCP re-establishment, further par. 224 discusses that the transmitting PDCP entity shall perform header compression of the PDCP SDU using…EHC,) and that the performing header decompression for all stored PDCP service data units (SDUs) is using the EHC configured for the PDCP entity. (par. 229 notes that if EHC is configured by the upper layers….the PDCP data PDUs may be decompressed by THE EHC protocol, thus the same EHC protocol)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of (effective) filing to incorporate the use of EHC as in Jo ‘625, with the combined method and apparatus of Jo and Jo ‘189. The motivation for doing so would have been to allow for improving system efficiency and performance (Jo ‘625 par. 3).
Claim(s) 3 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jo, in view of Jo’189, in further view of Joe ‘625, and 3GPP TS 138 300 V15.5.0 (2019-05 hereinafter 3GPP).
Regarding claims 3 and 11. The combination of Jo, Jo’189, and Jo ‘625 teach the method and apparatus of the previous claims 1 and 9.
However, they do not specifically disclose wherein the request for the PDCP re- establishment is based on a radio resource control (RRC) message including a mobility control information indication.
3GPP_300, in the same field of endeavor, discloses: wherein the request for the PDCP re-establishment is based on a radio resource control (RRC) message including a mobility control information indication. (Pg. 47-49, Section 9.2.3.2 “Handover”, Fig. 9.2.3.2.1-1 (shows that during Handover Mobility Control Information is provided by AMF), Pg. 48, Paragraph 5, “RRC managed Handovers with and without PDCP entity re-establishment are both supported”, Pg. 49, Fig. 9.2.3.2.1-1, “Step 0: Mobility Control Information Provided by AMF “… Pg. 49: “0:The UE context within the source gNB contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA update.” Therefore, it would have been obvious to one of ordinary skill in the art at the time of (effective) filing to incorporate the teachings of 3GPP with the combined method and apparatus of Jo, Jo ‘189, and Joe ‘625. The motivation for doing so would be to enable applying Network controlled mobility to UEs in RRC_CONNECTED. (3GPP_300, Pg. 47, Section 9.2.3.1).
Claim(s) 5-8 and 13-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jo, in view of Jo ‘189, in further view of Joe ‘625 and 3GPP TS 136 323 V16.4.0 (2021-10), hereinafter 3GPP_323V16.
Regarding claims 5 and 13. The combination of Jo, Jo ‘189, and Joe ‘625teach the limitations of the previous claims 4 and 12.
However, they do not specifically disclose in case that the PDCP entity is associated with at least one RLC entity configured with out-or-order delivery and an indicator indicating a continuous use of the EHC for a downlink is not configured, reset the EHC for the downlink.
In the same field of endeavor, 3GPP_323V16 discloses: wherein the controller is further configured to: in case that the PDCP entity is associated with at least one RLC entity configured with out-or-order delivery (Pg., 25, Section 5.2.2.1 a , if the PDCP entity is associated with at least one RLC entity configured with rlc-OutOfOrderDelivery:) and an indicator indicating a continuous use of the EHC for a downlink is not configured, (Pg., 25, Section 5.2.2.1 a, … if drb-ContinueEHC- DL is not configured, see TS 36.331 [3]; … ), reset the EHC for the downlink. (if the PDCP entity is associated with at least one RLC entity configured with rlc-OutOfOrderDelivery: perform header decompression (if configured) using EHC for all stored PDCP SDUs if drb-ContinueEHC- DL is not configured in TS 36.331 [3]; reset the EHC protocol for downlink (if configured) if drb-ContinueEHC-DL is not configured, see TS 36.331 [3];)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jo, Jo ‘189, and Joe ‘625 to incorporate the teaching of 3GPP_323V16 to provide in case that the PDCP entity is associated with at least one RLC entity configured with out-or-order delivery and an indicator indicating a continuous use of the EHC for a downlink is not configured, reset the EHC for the downlink. The modification would enable UE to perform re-establishment procedure when the PDCP entity is associated with at least on RLC entity configured with out-of-order deliver. (3GPP_323V16, section 5.2.2.1a).
Regarding claims 6 and 14. The combination of Jo, Jo’189, Joe ‘625, and 3GPP_323V16 teach the method of claims 5 and 13. 3GPP_323V16 further discloses: wherein the controller is further configured to: set a next PDCP reception sequence number (NEXT_PDCP_RX_SN) variable and a reception hyper frame number (RX_HFN) variable to 0, (3GPP_323V16, Pg 26, Section 5.2.2.2 a, “set Next_PDCP_RX_SN, and RX_HFN to 0 and Last_submitted_PDCP_RX_SN to Maximum_PDCP_SN;” ) and set a last submitted PDCP reception sequence number (Last_submitted_PDCP_RX_SN) variable to maximum PDCP sequence number (Maximum_PDCP_SN). (3GPP_323V16, Pg 26, Section 5.2.2.2 a, “set Next_PDCP_RX_SN, and RX_HFN to 0 and Last_submitted_PDCP_RX_SN to Maximum_PDCP_SN;”) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jo, Jo ‘189, and Joe ‘625 to incorporate the teaching of 3GPP_323V16 to provide the controller is further configured to: set a next PDCP reception sequence number (NEXT_PDCP_RX_SN) variable and a reception hyper frame number (RX_HFN) variable to 0, and set a last submitted PDCP reception sequence number (Last_submitted_PDCP_RX_SN) variable to maximum PDCP sequence number (Maximum_PDCP_SN). The modification would enable UE to perform re-establishment procedure when the PDCP entity is associated with at least on RLC entity configured with out-of-order delivery. (3GPP_323V16, section 5.2.2.2a).
Regarding claims 7 and 15. Jo, Jo ‘189, Joe ‘625 and 3GPP_323V16 disclose all limitations of previous claims 6 and 14 as discussed above.
3GPP_323V16 further discloses: wherein the controller is further configured to: apply a ciphering algorithm and a key provided by the upper layer during the PDCP re-establishment. (3GPP_323V16, Pg. 26, Section 5.2.2.3, “apply the ciphering and integrity protection algorithms and keys provided by upper layers during the re- establishment procedure.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jo, Jo ‘189, and Joe ‘625 to incorporate the teaching of 3GPP_323V16 to provide applying a ciphering algorithm and a key provided by the upper layer during the PDCP re-establishment. The modification would enable UE to perform re-establishment procedure when the PDCP entity is associated with at least on RLC entity configured with out-of-order delivery. (3GPP_323V16, section 5.2.2.2a).
Regarding claims 8 and 16, Jo, Jo ‘189, and Joe ‘625 disclose all limitations of claims 1 and 9 as discussed above. However, the combination does not specifically disclose wherein the header decompression is performed for the all stored PDCP SDUs using the EHC configured for the PDCP entity, after performing a deciphering.
In the same field of endeavor, 3GPP_323V16 discloses: wherein the header decompression is performed for the all stored PDCP SDUs using the EHC configured for the PDCP entity, after performing a deciphering. (3GPP_323V16, Pg. 12, 13, Figure. 4.2.2.1 and Figure. 4.2.2.2, show that Header Decompression is performed after deciphering, also in Pg. 14, Section 4.4 “Functions: The Packet Data Convergence Protocol supports the following functions: header compression and decompression of Ethernet data flows using the EHC protocol; compression and decompression of uplink PDCP SDU; ciphering and deciphering of user plane data and control plane data.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jo, Jo ‘189, and Joe ‘625 to incorporate the teaching of 3GPP_323V16 to provide the header decompression is performed for the all stored PDCP SDUs using the EHC configured for the PDCP entity, after performing a deciphering. The modification would enable configuring PDCP entity to use either uplink data compression (UDC) or to use header compression. (3GPP_323V16, Pg. 10, Section 4.2.2)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL THIER whose telephone number is (571)272-2832. The examiner can normally be reached M-Th 6:30 AM - 4:00 PM, Fri 7:00 AM-10:00 AM.
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.
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.
/Michael Thier/Supervisory Patent Examiner, Art Unit 2474
Michael Thier
Supervisory Patent Examiner
Art Unit 2474
Prosecution Insights