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 .
DETAILED ACTION
Claims 1, 3-4, 6-8, 10, 12, 14-15, and 17-18 are presented for examination.
Claims 1, 3-4, 6-8, 10 and 12 are amended.
Claims 2, 5, 9, 11, 13 and 16 are 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, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 3/02/2026 has been entered.
Response to Arguments
Regarding Drawing objections applicant’s arguments, see page 7 paragraph 2, filed March 2, 2026, have been fully considered and are persuasive. The Drawing objection have been withdrawn.
Regarding 35 U.S.C. 112 applicant’s arguments, see page 12 lines 30 – page 16 lines 15, filed March 2, 2026, with respect to claims 4 and 6-7 have been fully considered and are persuasive. Therefore, the 112 rejection has been withdrawn.
Regarding 35 U.S.C. 103 applicant’s arguments, see page 9 paragraph 2 - page 13 (all), filed March 2, 2026, with respect to claims 1, 8 and 12 have been fully considered and are not persuasive.
Regarding claim 1, the applicant first argued that, see page 10 – page 11 paragraphs 3, “ … In particular, the PDCP SN length of the first bearer is sent from the first CU to the first DU of the same node. The Office Action fails to cite any of the references that teach or suggest these features. For example, the Office Action cites Figure 3 of Huawei as teaching the transmission of PDCP SN length. Figure 3 is reproduced below: Figure 3: "handshaking" between the Transmitting PDCP entity and the Receiving PDCP entity In summary, Figure 3 of Huawei describes a handshaking procedure between a transmitting PDCP entity and a receiving PDCP entity. However, Huawei has not been shown to teach or suggest that the handshaking procedure is performed between a CU and a DU of the same node. In contrast, as discussed in section 4.1 of Huawei. The handshaking procedure is performed between a base station (NR gNB) and a UE, not between a CU and a DU, much less between the CU and DU of the same node.
In response to applicant's argument, the examiner respectfully disagrees with the argument above. See section 11 below.
Regarding amended claim 1, Huawei discloses, see Fig.1, a communication between a source PDCP entity and a target PDCP entity. It this case a source PDCP entity is a CU and a target PDCP entity is a DU. The secondary reference clearly teaches a CU – DU split , where the CU interface with the DU. Huawei clearly teaches, determine a packet data convergence protocol sequence number (PDCP SN) length of a first bearer (see Fig.3, para. 4.1, the Receiving PDCP entity / first communications apparatus determines and sends/ sending the first PDCP SN length information to the Transmitting PDCP, also NR gNB is able to read SN with old length before handshaking and read SN with new length after handshaking / determining (PDCP SN) length of a first bearer/DRB); send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node ((see Fig.3, para. 4.1, the Receiving PDCP entity / first communications apparatus sending the first PDCP SN length information to a NB gNB/SN /Transmitting PDCP / a first distributed unit (DU)), and receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU (see Fig.3, section 4, the transmitting PDCP entity / first DU, sending configuration information for releasing and adding a radio link control (RLC) entity of the first bearer, end/release/releasing SN for old SN length and adding/using the new SN length, add new SN in the SN length field, see also Section 5, Proposal 2, within NR, RLC will continue to transmit the stored PDCP PDU with old SN-length during PDCP¬ SN length reconfiguration).
Regarding claim 1, the applicant further argued that, see page 12 paragraphs 1-2, “ … Furthermore, the Office Action has not demonstrated any teaching, suggestion, or motivation to combine the cited references in a way to teach or suggest the claim limitation. While Park discusses CU and DU in an gNB, these discussions are unrelated to the transmission of a PDCP SN length. Therefore, there is no prima facie obviousness because a person of ordinary skill would not have been motivated or otherwise led to modify the handshaking procedure between gNB and UE discussed in Huawei to become a procedure between the CU and DU in the gNB.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, so as to deploy a NB gNB with a first centralized unit (CU) and a first distributed unit (DU). In the centralized deployment, different functional split options between the CU 1311 and the DU 1312. In the split option example 3, the NR RRC 1401, the NR PDCP 1403, and a partial function of the NR RLC (e.g., the High NR RLC 1404) is in a CU, and the other partial function of the NR RLC (e.g., the Low NR RLC 1405), the NR MAC, the NR PHY, and the RF 1410 is in a DU, see para. 0112-0113.
Regarding claim 1, the applicant further argued that, see page 12 paragraph 3 – page 13, “ … However, Applicant respectfully submits that like Park, these cited passages of Agiwal also include merely a general description of CU and DU split, e.g., the PDCP entity resides in the CU while the RLC and MAC entity resides in the DU. Like Park, these cited passages of Agiwal have not been shown to teach or suggest sending PDCP SN length of the first bearer from the CU to the DU of the same node.
In response to applicant's argument, the examiner respectfully disagrees with the argument above. See section 11 below.
Regarding claim 1, Huawei discloses, see Fig.1, a communication between a source PDCP entity and a target PDCP entity. It this case a source PDCP entity is a CU and a target PDCP entity is a DU. The secondary reference clearly teaches a CU – DU split, Agiwal clearly teaches wherein a first CU and a first DU belong to a master node, or the first CU and the first DU belong to a secondary node (see Fig.2A-7A-7C, para. 0160-0161, wherein a first CU and a first DU belong to a master node, see also para. 0063-0068, 0092-0098).
The applicant further argues, see page 13, “Similarly to the first rejection, the Office Action has not demonstrated any teaching, suggestion, or motivation to combine the cited references in a way to teach or suggest the claim limitation. Like Park, the discussion of CU and DU in Agiwal is a general description and is unrelated to the specific operation of transmitting a PDCP SN length. Therefore, there is no prima facie obviousness because a person of ordinary skill would not have been motivated or otherwise led to modify the handshaking procedure between gNB and UE discussed in Huawei to become a procedure between the CU and DU based on Agiwal.”
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, so as to support various operations performed by the UE during TRP/DU switch for the radio protocol stack or user plane functions where the user plane functions may be split between a CU and a TRP/DU.
Terminal Disclaimer
The terminal disclaimer filed on March 3, 2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Patent No.: 11895722 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 8 and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites in lines 7-8, “send the PDCP SN length from a first centralized unit (CU) to a first distributed unit (DU)”( Step A) and in in lines 10-11, “receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU” (step B). It is unclear the relationship between step A and step B. In view of step A the DU receiving the PDCP SN length , it is unclear whether the DU will possess the knowledge of a bearer (releasing and adding a radio link control (RLC) entity of the first bearer), since in view of step B, there were no steps in the claim to determine whether the bearer type is changed. Thus the claim is indefinite.
It is unclear as to what is meant by “receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU”,
It is unclear whether/how the DU determine “configuration information” for releasing and adding a radio link control (RLC) entity of the first bearer, in order to send to CU, based on receiving the PDCP SN length.
It is unclear the relationship between “the received PDCP SN length” and “configuration information” for releasing and adding a radio link control (RLC) entity of the first bearer”.
Claims 8 and 12 are also rejected for the same reason as set forth above for claim 1.
Claims 2-6, 8-12, 14-18, 20-24, 26-29, and 31-33 are also rejected since they are dependent on the rejected dependent claims 1, 8 and 12, respectfully, as set forth above.
For purpose of examination, the examiner interprets the limitation as best understood.
Notice re prior art available under both pre-AIA and AIA
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 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.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 1, 3, 6-8, 10, 12, 14-15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Huawei (PDCP SN Reconfiguration, R2-1702587, 04-2017), and further in view of Park et al. (US provisional 62/575127 and published as US Pub.:2019/0124572).
As per claim 1, Huawei disclose a first centralized unit (CU) (see Fig.1, Fig.3, Receiving PDCP entity / a Cu/Source gNodeB/MN node), comprising: at least one processor (see Fig.3, Receiving PDCP entity with a CPU / a processor) ; and a memory (see Fig.3, Receiving PDCP entity with a memory for storing) coupled to the at least one processor and storing executable instructions that, when executed by the at least one processor, cause the first CU to:
determine a packet data convergence protocol sequence number (PDCP SN) length of a first bearer (see Fig.1, Fig.3, para. 4.1, the Receiving PDCP entity / first communications apparatus determines and sends/ sending the first PDCP SN length information to the Transmitting PDCP, also NR gNB is able to read SN with old length before handshaking and read SN with new length after handshaking / determining (PDCP SN) length of a first bearer/DRB);
send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node (see Fig.1, Fig.3, para. 4.1, the Receiving PDCP entity / CU sending the first PDCP SN length information to a NB gNB/SN /Transmitting PDCP / a first distributed unit (DU)), and
receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU (see Fig.1, Fig.3, section 4, the transmitting PDCP entity / first DU, sending configuration information for releasing and adding a radio link control (RLC) entity of the first bearer, end/release/releasing SN for old SN length and adding/using the new SN length, add new SN in the SN length field, see also Section 5, Proposal 2, within NR, RLC will continue to transmit the stored PDCP PDU with old SN-length during PDCP SN length reconfiguration).
Examiner Note: Instant specification disclose: [0408] “In this embodiment of this application, an action of sending or receiving performed by the SN 11 may be performed by a CU 1111. Configuration information of a PDCP entity in the first configuration information that is of the first bearer and that is generated by the SN 11 is generated by the CU 1111. Configuration information of an RLC entity or configuration information of a MAC entity in the first configuration information is generated by a DU 1121”. [0410] “The CU 1111 may generate a PDCP SN length, and the CU 1111 may send the PDCP SN length of the first bearer to the DU 1121. The DU 1121 determines, based on the received PDCP SN length of the first bearer, whether the PDCP SN length is changed, and generates the configuration information of an RLC entity or the configuration information of a MAC entity. The CU 1111 may send the PDCP SN length of the first bearer to the MN 01, for example, the CU 0111”. [0420-0424] “For details, refer to related content in FIG. 8 to FIG. 13. Details are not described herein again”.
Although Huawei disclose send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node.
Huawei however does not explicitly disclose send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node;
Park however disclose wherein a first CU and a first DU belong to a master node, or the first CU and the first DU belong to a secondary node (see FIG. 13B show examples for gNB deployment, para. 0112, 0113,upper layers of a gNB is located in a Central Unit (CU) 1311 and with the split option example 2, the NR RRC 1401 and the NR PDCP 1403 is in a CU, and the NR RLC, the NR MAC, the NR PHY, and the RF 1410 is in a DU, see also para. 0114, the functional split is configured per CU, per DU, per wireless device, per bearer, per slice, and/or with other granularities. In a per CU split, a CU have a fixed split, and DUs are configured to match the split option of the CU, see prov. para. 0062-0064) and a NB gNB with a first distributed unit (DU) (see 13B, Fig.14, para. 0112-0114, Centralized deployment gNB with a Central Unit , CU-DU interface and Distributed Unit, see prov. Fig. 6, Fig.7, para. 0037-0040, Fig.13B, Fig.14, para. 0062-0064).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a first CU and a first DU belong to a master node, or the first CU and the first DU belong to a secondary node, as taught by Park, in the system of Huawei, so as to deploy a NB gNB with is a first centralized unit (CU) and a first distributed unit (DU), see Park, paragraphs 62-63.
As per claim 3, the combination of Huawei and Park disclose the first CU according to claim 1.
Huawei further disclose wherein the instructions that cause the first CU to determine the PDCP SN length of the first bearer comprises instructions that cause the first CU to generate the PDCP SN length; and the instructions, when executed by the at least one processor, further cause the first CU to: when the PDCP SN length changes, generate configuration information for releasing and adding a PDCP entity of the first bearer (see Fig.3, section 4.1, use old PDCP-SN length until SN=X, and use new PDCP-SN length from SN=Y, the PDCP SN length changes, configuration information for releasing and adding a PDCP).
As per claim 6, the combination of Huawei and Park disclose the first CU according to claim 1.
Huawei further disclose wherein the first CU is a CU of a master node, and the instructions that cause the first CU to determine the PDCP SN length of the first bearer comprises instructions that cause the first CU to receive the PDCP SN length from a secondary node; or the first CU is a CU of a secondary node, and the instructions that cause first CU to determine the PDCP SN length of the first bearer comprises instructions that cause the apparatus to receive the PDCP SN length from a master node (see Fig.3, section 4, use new PDCP-SN length from new SN=Y/receive the PDCP SN length from a secondary node).
As per claim 7, the combination of Huawei and Park disclose the apparatus according to claim 6.
Huawei further disclose wherein the instructions that cause the apparatus to receive the PDCP SN length from the secondary node comprises instructions that cause the first CU to: receive the PDCP SN length from the secondary node in a secondary node addition request message, a secondary node modification request message, or a secondary node modification required message (see Fig.3, section 4, for lossless data delivery when long to short SN change happens, source gNB forward PDCP SDU(s) with the long SN format to the target gNB. Besides data forwarding for downlink data retransmission, PDUs with long SN format is transmitted in air interface for uplink retransmission and PDCP status report can still be generated in long SN format until all PDCP stored data has been transmitted successfully. After all stored PDCP data has been transmitted successfully short SN length can be used / receive the PDCP SN length from the secondary node).
As per claim 8, claim 8, is rejected the same way as claim 1. Park also disclose a first distributed unit (see Fig.13B, Fig.14, para. 0062-0064, Centralized deployment gNB with a Central Unit , CU-DU interface and Distributed Unit, see also Fig. 6, Fig.7, para. 0037-0040)
As per claim 10, claim 10, is rejected the same way as claim 3.
As per claim 12, claim 12, is rejected the same way as claim 1.
As per claim 14, claim 14, is rejected the same way as claim 3.
As per claim 15, claim 15, is rejected the same way as claim 4.
As per claim 17, claim 17, is rejected the same way as claim 6.
As per claim 18, claim 18, is rejected the same way as claim 7.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Second Rejection
Claims 1, 8 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Huawei (PDCP SN Reconfiguration, R2-1702587, 04-2017), and further in view of Agiwal (US Pub. No.:2018/0083688).
As per claim 1, Huawei disclose a first centralized unit (CU) (see Fig.1, Fig.3, Receiving PDCP entity / Source gNodeB/MN node), comprising: at least one processor (see Fig.3, Receiving PDCP entity with a CPU / a processor) ; and a memory (see Fig.3, Receiving PDCP entity with a memory for storing) coupled to the at least one processor and storing executable instructions that, when executed by the at least one processor, cause the first CU to:
determine a packet data convergence protocol sequence number (PDCP SN) length of a first bearer (see Fig.3, para. 4.1, the Receiving PDCP entity / first communications apparatus determines and sends/ sending the first PDCP SN length information to the Transmitting PDCP, also NR gNB is able to read SN with old length before handshaking and read SN with new length after handshaking / determining (PDCP SN) length of a first bearer/DRB);
send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node ((see Fig.3, para. 4.1, the Receiving PDCP entity / first communications apparatus sending the first PDCP SN length information to a NB gNB/SN /Transmitting PDCP / a first distributed unit (DU)), and
receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU (see Fig.3, section 4, the transmitting PDCP entity / first DU, sending configuration information for releasing and adding a radio link control (RLC) entity of the first bearer, end/release/releasing SN for old SN length and adding/using the new SN length, add new SN in the SN length field, see also Section 5, Proposal 2, within NR, RLC will continue to transmit the stored PDCP PDU with old SN-length during PDCP¬ SN length reconfiguration).
Examiner Note: Instant specification disclose: [0408] “In this embodiment of this application, an action of sending or receiving performed by the SN 11 may be performed by a CU 1111. Configuration information of a PDCP entity in the first configuration information that is of the first bearer and that is generated by the SN 11 is generated by the CU 1111. Configuration information of an RLC entity or configuration information of a MAC entity in the first configuration information is generated by a DU 1121”. [0410] “The CU 1111 may generate a PDCP SN length, and the CU 1111 may send the PDCP SN length of the first bearer to the DU 1121. The DU 1121 determines, based on the received PDCP SN length of the first bearer, whether the PDCP SN length is changed, and generates the configuration information of an RLC entity or the configuration information of a MAC entity. The CU 1111 may send the PDCP SN length of the first bearer to the MN 01, for example, the CU 0111”. [0420-0424] “For details, refer to related content in FIG. 8 to FIG. 13. Details are not described herein again”.
Although Huawei disclose send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node.
Huawei however does not explicitly disclose send the PDCP SN length to a first distributed unit (DU), wherein the first CU and the first DU belong to a master node, or the first CU and the first DU belong to a secondary node;
Agiwal however disclose wherein a first CU and a first DU belong to a master node, or the first CU and the first DU belong to a secondary node (see Fig.2A-7A-7C, para. 0160-0161, wherein a first CU and a first DU belong to a master node, see also para. 0063-0068, 0092-0098)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a first CU and a first DU belong to a master node, or the first CU and the first DU belong to a secondary node, as taught by Agiwal, in the system of Huawei, so as to support various operations performed by the UE during TRP/DU switch for the radio protocol stack or user plane functions where the user plane functions may be split between a CU and a TRP/DU, see Agiwal, paragraphs 17-20.
Allowable Subject Matter
Claim 4 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form (and overcoming the 112 rejections as set forth on sections 10 and 11) including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ingale (IN 201741028700 filed 08/11/2017) - see para. 0169, during the PDCP version change, the network 104 releases the configured radio bearer with the first PDCP entity and adds the radio bearer with second PDCP entity and refresh the security key associated with the concerned radio bearer, see IN700, Fig.5-7, para. 0044-0047, 0097, Fig.8.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAKERAM JANGBAHADUR whose telephone number is (571)272-1335. The examiner can normally be reached on M-F 7 am - 4 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ian Moore can be reached on 571-272-3085. 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 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LAKERAM JANGBAHADUR/
Primary Examiner, Art Unit 2469
Prosecution Insights