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
In the amendment filed July 20, 2026, claims 1, 8 and 12 have been amended, claim 19 is new and claims 1, 3-4, 6-7, 8, 12, 14-15, and 17-19 are currently pending for examination.
Response to Arguments
Regarding 35 U.S.C. 112 applicant’s arguments, see page 6 paragraph 3 – page 8 paragraphs 3, filed July 20, 2026, with respect to claims 1, 8 and 12 have been fully considered and are persuasive. However, a new of rejection is presented in view of the claim amendments. See sections 5 and 6 below, for further 112 rejections in view of the claim amendments.
Regarding 35 U.S.C. 103 applicant’s arguments, see page 8 paragraph 4 - page 14 (all), filed July 20, 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, “ … Additionally, the Office Action also cites proposal 2 of Huawei. However, proposal 2 states the following: "Within NR, RLC can continue to transmit the stored PDCP PDU with old SN- length during PDCP-SN length reconfiguration." Applicant respectfully submits that proposal 2 is silent regarding the operation of releasing and adding RLC entity. In contrast, the cited portion of Huawei teaches away from the claimed invention. Instead of releasing and adding RLC entity when the PDSN SN length changes, proposal 2 of Huawei suggests the opposite, which is to continue to use current RLC with the old SN-length. Therefore, Huawei has not been shown to teach or suggest these features. The Office Action acknowledges the above-identified deficiency in Huawei and cites other references to remedy the deficiency. However, none of Park, Agiwal, or Sirotkin has been shown to teach the missing limitations. For example, in the first rejection, the Office Action cites Park as teaching CU and DU deployment of an eNB. However, Applicant respectfully submits that these cited passages of Park merely provide a general description of a structure of a gNB, such as different functional splits between the CU and DU in a gNB, including e.g., upper layers in CU and lower layers in DU, RRC in CU and PDCP/RLC/MAC/PHY in DU, etc. However, these cited passages of Park 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, or sending the configuration information for releasing and adding a RLC entity of the first bearer from the first DU to the first CU of the same node. 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 the CU-DU configuration in an gNB, these discussions are unrelated to the transmission of a PDCP SN length. Moreover, Park is silent in disclosing if any of these steps recited in the claims, e.g., sending the configuration information for releasing and adding a RLC entity of the first bearer, or sending PDCP SN length of the first bearer, are to be performed between the CU and the DU, much less being performed by the specific entity as recited in the claim..
In response to applicant's argument, the examiner respectfully disagrees with the argument above. See sections 5 and 6 below.
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 is a first centralized unit (CU) and a first distributed unit (DU), see Park, paragraphs 62-63.
Regarding amended claim 1, Huawei discloses, see Fig.1, when the PDCP SN length changes, 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), wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer (see Fig.1, Fig.3, section 4, end/release/releasing SN for old SN length) and configuration information for adding a RLC entity corresponding to the bearer identifier (see Fig.1, Fig.3, section 4, adding/using the new SN length, add new SN in the SN length field); the Examiner further states that Park 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); and wherein the configuration information for modifying and adding a RLC entity comprises configuration information for modifying a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier (see para. 0297, the RRC message comprises a radio resource config dedicated information element comprising at least one of a list of one or more radio bearers to be added and/or modified, one or more radio resource configuration information for the one or more radio bearers, radio bearer identifiers, radio bearer type information, rlc configuration information, PDU session identifiers, QoS flow identifiers, EPS bearer identifiers, pdcp configuration information, logical channel identifiers associated with the one or more radio bearer, see also para. 0071, release of an RRC connection between a wireless device and NG-RAN, which comprises at least one of addition, modification and release of carrier aggregation; or addition, modification, and/or release of dual connectivity in NR or between E-UTRA and NR. Services and/or functions of an RRC sublayer may further comprise at least one of security functions comprising key management; establishment, configuration, maintenance, and/or release of Signaling Radio Bearers (SRBs) and/or Data Radio Bearers (DRBs), see also para. 0330-0331, to modify an RRC connection, e.g., to establish, modify and/or release RBs (radio bearers) and when the received RRC connection reconfiguration message includes the sCellToReleaseList, the wireless device 3310 performs SCell release and when the received RRC Connection Reconfiguration message includes the sCellToAddModList, the wireless device 3310 performs SCell additions or modification).
Under the broadest reasonable interpretation, the combination of the system as disclosed by Huawei and Park reads upon “cause the first CU to: determine a packet data convergence protocol sequence number (PDCP SN) length of a first bearer; 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; and when the PDCP SN length changes, receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU, wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier” as recites in the claim.
Regarding claim 1, the applicant further argued that, see page 12 -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, or sending the configuration information for releasing and adding a RLC entity of the first bearer from the first DU to the first CU of the same node. 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. Agiwal also has not been shown to teach or suggest if the PDCP SN length and configuration information for releasing and adding a RLC entity of the first bearer are to be exchanged between the CU and DU, much less at which direction these information should be sent. Therefore, 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 to arrive the alleged combination based on Agiwal. Therefore, Applicant respectfully submits that none of the rejections teach at least the above-identified limitations. For at least these reasons, Applicant respectfully requests allowance of independent claim 1 and its dependents.
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.
In response to applicant's argument, the examiner respectfully disagrees with the argument above. See sections 5 and 6 below.
Regarding amended claim 1, Huawei teaches, 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 when the PDCP SN length changes, 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), wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer (see Fig.1, Fig.3, section 4, end/release/releasing SN for old SN length) and configuration information for adding a RLC entity corresponding to the bearer identifier (see Fig.1, Fig.3, section 4, adding/using the new SN length, add new SN in the SN length field), the Examiner further states that 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); and wherein the configuration information for reconfiguring a RLC entity comprises a RLC entity corresponding to a bearer identifier of the first bearer (see para. 0134-0138, If the MCG DRB is configured with LTE PDCP then for performing the bearer type reconfiguration to the SCG or Split DRB, the PDCP version is changed from the LTE PDCP to the NR PDCP for the MCG DRB through the handover procedure which involves PDCP re-establishment. During the UE mobility from the legacy LTE to Rel-15 LTE node, for EN-DC capable UE the PDCP version change of MCG DRB from LTE PDCP to NR PDCP can be supported through handover procedure. From the UE 102 perspective, there are only three bearer types i.e. MCG DRB, SCG DRB and Split DRB. The split DRB can either terminate at the MN or terminates at the SN based on the MN decision. In the EN-DC, the network can configure the split bearer with the following configuration: Split bearer: The NR PDCP container+LTE configurations on the RLC, the MAC and the physical layers +the NR configuration container on the NR RLC, the MAC and physical layers, etc. Split bearer whose PDCP termination point is at the MN can be termed as the split bearer terminated at the MN. The split bearer whose PDCP termination point is at the SN can be termed as the split bearer terminated at the SN / a RLC entity corresponding to a bearer identifier of the first bearer, see also para. 0114, 0390, 0394).
The applicant further argues, see page 12, “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.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 11-13 and 17-19 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 has been amended to recite in lines 5-7, " ... when the PDCP SN length changes, receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU, wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier” . Neither the claim nor the specification further describe, “when the PDCP SN length changes, receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU, wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier”. Paragraph 0109 of instant application disclose, “In an embodiment, the network is configured to perform a PDCP version change in a lossless manner from the first PDCP entity to the second PDCP entity for one or more configured radio bearers includes determining whether a sequence number (SN) length of the first PDCP entity associated with the radio bearer configured by a source node is less than or equal to a SN length of a second PDCP entity configured by a target node.” The claims and the specification of the instant application does not describe the method/step, “... when the PDCP SN length changes, receive configuration information for releasing and adding a radio link control (RLC) entity of the first bearer from the first DU, wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier”.
Therefore claim 1 is rejected under 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement
The subject matter was not described in the specification (see paragraph 0109, 0117, 0189, 0242) in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and /or use the invention.
Claim 8 and 12 are also rejected for the same reason as set forth above for claim 1.
Claims 3-4, 6-7, 14-15, and 17-19 are also rejected since they are dependent on the rejected dependent claims 1, 8 and 12, respectfully, as set forth above.
Claims 1, 8, 12 and 19 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 has been amended to recite in lines 9, “when the PDCP SN length changes”, and lines 7-8, recites “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 as to what is meant by “when the PDCP SN length changes”. In view of step A, it is unclear what determines “the PDCP SN length changes”, since there are no other steps other than “determine a packet data convergence protocol sequence number (PDCP SN) length of a first bearer”.
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”.
New Claim 19 recites, “…wherein a change of PDCP SN length triggers the first CU to generate ….”. It is unclear as to what is meant by “a change of PDCP SN length”. What /how is “a change of PDCP SN length” determine? The independent claim determines “a PDCP SN length”, it is unclear whether/how “a change of PDCP SN length” is determined.
Examiner Note: Paragraphs 0158, 0180, 0183 of published application specifically disclose, “For example, when the MN 01 is an eNB, for example, an eNB in an EN-DC or NGEN-DC scenario, a RadioResourceConfigDedicated information element in section 6.3.2 in 3GPP TS 36.331 V15.1.0 may be used for implementation. The second configuration information may include the RadioResourceConfigDedicated. DRB-ToReleaseList in the RadioResourceConfigDedicated includes a bearer identifier 1, and DRB-ToAddMod includes the bearer identifier 1. The same logical channel identifier or bearer identifier is deleted and added, so that an RLC entity of a bearer may be deleted and then added by using one configuration message. In this way, the PDCP SN length is changed.”
Paragraphs 0570-0572, 0579-0580, 0613 of published application specifically disclose, “The secondary node configuration information of the first bearer may include the configuration information for releasing the PDCP entity corresponding to the first bearer identifier, the configuration information for adding the PDCP entity corresponding to the second bearer identifier, the configuration information for adding the RLC entity corresponding to the second bearer identifier, and configuration information for adding a MAC entity corresponding to the second bearer identifier. Seems that there is “a second configuration information” and “a second bearer identifier”, as recited in the specification, to implement the invention.
Claims 8 and 12 are also rejected for the same reason as set forth above for claim 1.
Claims 3-4, 6-7, 14-15, and 17-19 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-19 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
when the PDCP SN length changes, 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),
wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer (see Fig.1, Fig.3, section 4, end/release/releasing SN for old SN length) and configuration information for adding a RLC entity corresponding to the bearer identifier (see Fig.1, Fig.3, section 4, adding/using the new SN length, add new SN in the SN length field).
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)’
wherein the configuration information for modifying and adding a RLC entity comprises configuration information for modifying a RLC entity corresponding to a bearer identifier of the first bearer and configuration information for adding a RLC entity corresponding to the bearer identifier (see para. 0297, the RRC message comprises a radio resource config dedicated information element comprising at least one of a list of one or more radio bearers to be added and/or modified, one or more radio resource configuration information for the one or more radio bearers, radio bearer identifiers, radio bearer type information, rlc configuration information, PDU session identifiers, QoS flow identifiers, EPS bearer identifiers, pdcp configuration information, logical channel identifiers associated with the one or more radio bearer, see also para. 0071, release of an RRC connection between a wireless device and NG-RAN, which comprises at least one of addition, modification and release of carrier aggregation; or addition, modification, and/or release of dual connectivity in NR or between E-UTRA and NR. Services and/or functions of an RRC sublayer may further comprise at least one of security functions comprising key management; establishment, configuration, maintenance, and/or release of Signaling Radio Bearers (SRBs) and/or Data Radio Bearers (DRBs), see also para. 0330-0331, to modify an RRC connection, e.g., to establish, modify and/or release RBs (radio bearers) and when the received RRC connection reconfiguration message includes the sCellToReleaseList, the wireless device 3310 performs SCell release and when the received RRC Connection Reconfiguration message includes the sCellToAddModList, the wireless device 3310 performs SCell additions or modification).
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 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.
As per claim 19, the combination of Huawei and Park disclose the first DU according to claim 8.
Huawei further disclose wherein a change of PDCP SN length triggers the first CU to generate configuration information for releasing and adding a PDCP entity of the first bearer, wherein the configuration information for releasing and adding a PDCP entity comprises configuration information for releasing a PDCP entity corresponding to a bearer identifier of the first bearer and configuration information for adding a PDCP entity corresponding to the bearer identifier (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).
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
when the PDCP SN length changes, 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),
wherein the configuration information for releasing and adding a RLC entity comprises configuration information for releasing a RLC entity corresponding to a bearer identifier of the first bearer (see Fig.1, Fig.3, section 4, end/release/releasing SN for old SN length) and configuration information for adding a RLC entity corresponding to the bearer identifier (see Fig.1, Fig.3, section 4, adding/using the new SN length, add new SN in the SN length field).
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); and
wherein the configuration information for reconfiguring a RLC entity comprises a RLC entity corresponding to a bearer identifier of the first bearer (see para. 0134-0138, If the MCG DRB is configured with LTE PDCP then for performing the bearer type reconfiguration to the SCG or Split DRB, the PDCP version is changed from the LTE PDCP to the NR PDCP for the MCG DRB through the handover procedure which involves PDCP re-establishment. During the UE mobility from the legacy LTE to Rel-15 LTE node, for EN-DC capable UE the PDCP version change of MCG DRB from LTE PDCP to NR PDCP can be supported through handover procedure. From the UE 102 perspective, there are only three bearer types i.e. MCG DRB, SCG DRB and Split DRB. The split DRB can either terminate at the MN or terminates at the SN based on the MN decision. In the EN-DC, the network can configure the split bearer with the following configuration: Split bearer: The NR PDCP container+LTE configurations on the RLC, the MAC and the physical layers +the NR configuration container on the NR RLC, the MAC and physical layers, etc. Split bearer whose PDCP termination point is at the MN can be termed as the split bearer terminated at the MN. The split bearer whose PDCP termination point is at the SN can be termed as the split bearer terminated at the SN / a RLC entity corresponding to a bearer identifier of the first bearer, see also para. 0114, 0390, 0394).
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
Claims 4 and 15 are 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 5 and 6) 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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