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 .
Response to Arguments
Applicant's arguments filed 2/25/26 have been fully considered but they are not persuasive.
For claim 1, Applicant argues: Dai has not been shown to teach or suggest specifically that the DL DATA DELIVERY STATUS frame includes one specific SN that indicates a combined result of the
highest SN of the first PDCP PDU that are successfully sent by the DU to each of the at least two
terminal devices.
In response, Examiner respectfully disagrees: Table 1 in view of FIGs. 1-5 shows the DATA DELIVERY STATUS frame that includes a field “Highest Delivered NR PDCP SN Ind” which indicate the
highest SN of the first PDCP PDU that are successfully sent by the DU to each of the at least two
terminal devices. Note that the phase “a combined result of the highest SN of the first PDCP PDU” is not supported in the specification and its meaning is unclean, with Examiner interpreted it as “the highest SN of the first PDCP PDU”.
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.
Claims 1,5-10,15-16 and 20-25 are 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 recites “… the first field comprises a highest successfully delivered new radio (NR) PDCP sequence number (SN) that indicates a combined result of a highest SN of an NR PDCP PDU that is successfully sent by the CU to all of the at least two terminal devices”. There is insufficient support for this claim limitation in the specification, particularly “a combined result of a highest SN of an NR PDCP PDU”.
Independent claims 10, 16 and 21 are rejected because each has the same problem as claim 1.
Dependent claims are rejected because each of them depends on the corresponding independent claim.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1,5-10,15-16 and 20-25 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “the first field comprises a highest successfully delivered new radio (NR) PDCP sequence number (SN) that indicates a combined result of a highest SN of an NR PDCP PDU that is successfully sent by the CU to all of the at least two terminal devices”. The “combined result” only has one element “a highest SN of an NR PDCP PDU”, and it is unclear what is the “combined result”.
Independent claims 10, 16 and 21 are rejected because each has the same problem as claim 1.
Dependent claims are rejected because each of them depends on the corresponding independent claim.
To continue prosecution on merit, the claims will be interpreted as best understood.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 9-10, 15-16 and 21-22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Dai (US 20240080216 A1).
For claim 1, Dai discloses a method comprising:
receiving, by a distributed unit (DU), a first packet data convergence protocol (PDCP) packet data unit (PDU) from a central unit (CU) (FIG. 5 shows DU receives PDCP data from CU, in view of the associated text, such as “[0090] … Referring to FIG. 5, a shared tunnel for PTM transmission may be established between the CU and the DU. The shared tunnel may be used to transmit data (e.g., PDCP PDU) to the DU such that DU may transmit the data to one or more UEs (e.g., UE 102a and UE 102b) by a PTM mode.”), wherein the first PDCP PDU carries data of a multicast broadcast service (MBS) (“[0077] The PTM mode may refer to transmitting same MBS data to one or more UEs (e.g., UE 102a and UE 102b) via a multicast mode.”);
sending, by the DU, the first PDCP PDU to at least two terminal devices (“[0090] … Referring to FIG. 5, a shared tunnel for PTM transmission may be established between the CU and the DU. The shared tunnel may be used to transmit data (e.g., PDCP PDU) to the DU such that DU may transmit the data to one or more UEs (e.g., UE 102a and UE 102b) by a PTM mode.” In view of FIGs. 1 and 5); and
sending, by the DU, a status report to the CU, wherein the status report indicates results of sending the first PDCP PDU by the DU to the at least two terminal devices ([0096] “the DU may transmit a data transmission indication to activate the PTP mode via the individual tunnel established for PTP transmission for the UE to the CU. The indication may be transmitted in a frame via the user plane protocol as shown in FIG. 2. In an embodiment, the frame may be a DL DATA DELIVERY STATUS frame”);
wherein the status report is a downlink data delivery status, the downlink delivery status (“[0099] The following Table 1 shows an example DL DATA DELIVERY STATUS frame …”) comprises a first field, and the first field comprises a highest successfully delivered new radio (NR) PDCP sequence number (SN) (Table 1 shows an example of DL DATA DELIVERY STATUS frame, Octet 1, bit 2 “Highest Delivered NR PDCP SN Ind”) that indicates a combined result of a highest SN of an NR PDCP PDU that is successfully sent by the CU to all of the at least two terminal devices (Table 1 in view of FIGs. 1-5 and the associated text, such as “[0090] … DU may transmit the data to one or more UEs (e.g., UE 102a and UE 102b) by a PTM mode.” and [0096] “the DU may transmit a data transmission indication to activate the PTP mode via the individual tunnel established for PTP transmission for the UE to the CU. The indication may be transmitted in a frame via the user plane protocol as shown in FIG. 2. In an embodiment, the frame may be a DL DATA DELIVERY STATUS frame”; and Table 1 shows an example of DL DATA DELIVERY STATUS frame, Octet 1, bit 2 “Highest Delivered NR PDCP SN Ind”).
Independent claim 10 is rejected because it describes the same downlink data delivery process between an eNB (which includes both CU and DU) and the associated UEs as disclosed by claim 1 and has the same subject matter.
Independent claim 16 is rejected because it is a claim of a generic apparatus that performs the method of claim 1 and has the same subject matter.
Independent claim 21 is rejected because it is a claim of a generic apparatus that performs the method of claim 10 and has the same subject matter.
As to claim 9, Dai discloses claim 1, Dai further discloses: wherein the sending, by the DU, a status report to the CU comprises: sending, by the DU, the status report to the CU through a first channel, wherein the first channel is a general packet radio service tunneling protocol-user plane (GTP-U) tunnel shared by a plurality of terminal devices (“[0152] After receiving the status report from the UE at step 703, the CU may identify the receiving status of the set of data packets. … [0157] … The data received from the shared tunnel may be delivered to one RLC entity (or one RLC bearer) of the two RLC entities for the PTM transmission. In an embodiment, the shared tunnel may be an F1-U GTP-U tunnel.” in view of FIGs. 1-11).
As to claim 14, Dai discloses claim 10, Dai further discloses: wherein the receiving, by the CU, a status report from the DU (as disclosed by the parent claim) comprises:
receiving, by the CU, a first status report from the DU, wherein the first status report indicates a result of sending the first PDCP PDU to a first terminal device in the at least two terminal devices, and the first terminal device comprises at least one terminal device ((“[0152] After receiving the status report from the UE at step 703, the CU may identify the receiving status of the set of data packets. … [0157] … The data received from the shared tunnel may be delivered to one RLC entity (or one RLC bearer) of the two RLC entities for the PTM transmission.” in view of FIGs. 1-11); and
receiving, by the CU, a second status report from the DU, wherein the second status report indicates a result of sending the first PDCP PDU to a second terminal device in the at least two terminal devices, and the second terminal device comprises at least one terminal device ([0096] “the DU may transmit a data transmission indication to activate the PTP mode via the individual tunnel established for PTP transmission for the UE to the CU. The indication may be transmitted in a frame via the user plane protocol as shown in FIG. 2. In an embodiment, the frame may be a DL DATA DELIVERY STATUS frame” and “[0077] The PTM mode may refer to transmitting same MBS data to one or more UEs (e.g., UE 102a and UE 102b) via a multicast mode.”).
As to claims 15 and 22, Dai discloses claims 10 and 16, Dai further discloses: wherein the receiving, by the CU, a status report from the DU comprises: receiving, by the CU, the status report from the DU through a first channel, wherein the first channel is a general packet radio service tunneling protocol-user plane (GTP-U) tunnel shared by a plurality of terminal device ([0157] … The data received from the shared tunnel may be delivered to one RLC entity (or one RLC bearer) of the two RLC entities for the PTM transmission. In an embodiment, the shared tunnel may be an F1-U GTP-U tunnel.” in view of FIGs. 1-11).
As to claim 17, Dai discloses claim 16, Dai further discloses: wherein the status report is a downlink data delivery status ([0096] “the DU may transmit a data transmission indication to activate the PTP mode via the individual tunnel established for PTP transmission for the UE to the CU. The indication may be transmitted in a frame via the user plane protocol as shown in FIG. 2. In an embodiment, the frame may be a DL DATA DELIVERY STATUS frame”), the downlink delivery status comprises a first field, and the first field indicates the results of sending the first PDCP PDU by the apparatus to the at least two terminal devices (Table 1 shows an example DL DATA DELIVERY STATUS frame, Octet 1, bit 2 “Highest Delivered NR PDCP SN Ind”, bit 3 “Highest Transmitted NR PDCP SN Ind”, bit 0 “Lost Packet Report” and “[0077] The PTM mode may refer to transmitting same MBS data to one or more UEs (e.g., UE 102a and UE 102b) via a multicast mode.” in view of FIGs. 1-11).
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, 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 5-8, 20 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Dai (US 20240080216 A1) in view of TEYEB (US 20210211939 A1).
As to claims 5 and 23, Dai discloses claims 1 and 16, and is silent but TEYEB, in the same field of wireless communication, discloses: wherein the sending, by the DU, the first PDCP PDU to at least two terminal devices (as disclosed by the parent claim) comprises: sending, by the DU, the first PDCP PDU to each terminal device by using a radio link control (RLC) unacknowledged mode (UM) (“[0138] … For RLC UM, the corresponding node may remove the respective NR PDCP PDUs after transmitting to lower layers.”). OOSA would have been motivated to apply the teaching of TEYEB above to the DL PDCP data delivery by Dai to yield of predictable result of promptly removing the PDCP PDUs that have been delivered.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine Dai and TEYEB for the benefit of promptly removing the PDCP PDUs that have been delivered ([0138] of TEYEB).
As to claims 6 and 24, Dai discloses claims 5 and 23, and is silent but TEYEB, in the same field of wireless communication, discloses: wherein the status report carries indication information that indicates the status report corresponding to the RLC UM (“[0138] In case of RLC AM, after the highest NR PDCP PDU sequence number successfully delivered in sequence is reported to the node hosting the NR PDCP entity, the corresponding node removes the respective NR PDCP PDUs. …”). OOSA would have been motivated to apply the teaching of TEYEB above to the DL PDCP data delivery by Dai to yield of predictable result of promptly removing the PDCP PDUs that have been delivered.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine Dai and TEYEB for the benefit of promptly removing the PDCP PDUs that have been delivered ([0138] of TEYEB).
As to claims 7 and 20, Dai discloses claims 1 and 16, and is silent but TEYEB, in the same field of wireless communication, discloses: wherein the sending, by the DU, the first PDCP PDU to at least two terminal devices (as disclosed by the parent claims) comprises:
sending, by the DU, the first PDCP PDU to a first terminal device in the at least two terminal devices by using an RLC acknowledged mode (AM), wherein the first terminal device comprises at least one terminal device (“[0138] In case of RLC AM, after the highest NR PDCP PDU sequence number successfully delivered in sequence is reported to the node hosting the NR PDCP entity, the corresponding node removes the respective NR PDCP PDUs. …”); and
sending, by the DU, the first PDCP PDU to a second terminal device in the at least two terminal devices by using an RLC UM, wherein the second terminal device comprises at least one terminal device (“[0138] … For RLC UM, the corresponding node may remove the respective NR PDCP PDUs after transmitting to lower layers.”).
wherein: the status report indicates a result of sending the first PDCP PDU to the first terminal device and a result of sending the first PDCP PDU to the second terminal device (“[0143] First, F1-U flow control (and the associated downlink delivery status report that is used to facilitate that) sends information to the CU only about bearers associated with UEs that are being served by the DU sending the report. In FIG. 12, IAB2 is serving two UEs …”). OOSA would have been motivated to apply the teaching of TEYEB above to the DL PDCP data delivery by Dai to yield of predictable result of reporting data delivery status.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine Dai and TEYEB for the benefit of reporting data delivery status ([0143] of TEYEB).
As to claim 8, Dai in view of TEYEB discloses claim 7, TEYEB further discloses: wherein the sending, by the DU, a status report to the CU comprises:
sending, by the DU, a first status report to the CU, wherein the first status report indicates the result of sending the first PDCP PDU to the first terminal device (“[0143] First, F1-U flow control (and the associated downlink delivery status report that is used to facilitate that) sends information to the CU only about bearers associated with UEs that are being served by the DU sending the report. In FIG. 12, IAB2 is serving two UEs …”); and
sending, by the DU, a second status report to the CU, wherein the second status report indicates the result of sending the first PDCP PDU to the second terminal device (“[0143] First, F1-U flow control (and the associated downlink delivery status report that is used to facilitate that) sends information to the CU only about bearers associated with UEs that are being served by the DU sending the report. In FIG. 12, IAB2 is serving two UEs …”). The motivation of combining Dai and TEYEB is the same as stated in the parent claim.
Independent claims 1, 10, 16 and 21 are also rejected under 35 U.S.C. 103 as being unpatentable over D1 (3GPP R3-210622) in view of Dai (US 20240080216 A1).
For claim 1, D1 discloses a method comprising:
receiving, by a distributed unit (DU), a first packet data convergence protocol (PDCP) packet data unit (PDU) from a central unit (CU), wherein the first PDCP PDU carries data of a multicast broadcast service (MBS) (p1, Section 2, Solution 1: “… The gNB-CU sends MBS user data (PDCP PDU) and DL USER DATA user plane frame to gNB-DU over the shared GTP-U tunnel at least for PTM transmission.”);
sending, by the DU, the first PDCP PDU to at least two terminal devices (p1, Section 2, Observation 1: “… At least for PTM transmission, a shared F1-U GTP-U tunnel is used, wherein the shared F1-U GTP-U tunnel is used for multiple UEs who belong to a same multicast group. …”); and
sending, by the DU, a status report to the CU, wherein the status report indicates results of sending the first PDCP PDU by the DU to the at least two terminal devices (p1, Section 2, Solution 1: “… The gNB-DU sends the DL DATA DELIVERY STATUS user plane frame including the per individual UE control information to the gNB-CU over the dedicated tunnel. The dedicated tunnel may be the same as the tunnel for PTP transmission if any.”).
D1 does not specifically state, but Dai, in the same field of endeavor of sending, by the DU, the first PDCP PDU to at least two terminal devices (FIGs. 1 and 5-11 and the associated text, such as [0090] “Referring to FIG. 5, a shared tunnel for PTM transmission may be established between the CU and the DU. The shared tunnel may be used to transmit data (e.g., PDCP PDU) to the DU such that DU may transmit the data to one or more UEs (e.g., UE 102a and UE 102b) by a PTM mode. …”);
wherein the status report is a downlink data delivery status, the downlink delivery status (“[0099] The following Table 1 shows an example DL DATA DELIVERY STATUS frame …”) comprises a first field, and the first field comprises a highest successfully delivered new radio (NR) PDCP sequence number (SN) (Table 1 shows an example of DL DATA DELIVERY STATUS frame, Octet 1, bit 2 “Highest Delivered NR PDCP SN Ind”) that indicates a combined result of a highest SN of an NR PDCP PDU that is successfully sent by the CU to all of the at least two terminal devices (Table 1 in view of FIGs. 1-5 and the associated text, such as “[0090] … DU may transmit the data to one or more UEs (e.g., UE 102a and UE 102b) by a PTM mode.” and [0096] “the DU may transmit a data transmission indication to activate the PTP mode via the individual tunnel established for PTP transmission for the UE to the CU. The indication may be transmitted in a frame via the user plane protocol as shown in FIG. 2. In an embodiment, the frame may be a DL DATA DELIVERY STATUS frame”; and Table 1 shows an example of DL DATA DELIVERY STATUS frame, Octet 1, bit 2 “Highest Delivered NR PDCP SN Ind”).
OOSA would have been motivated to apply the teaching of Dai above to yield an expected result of describing a complete downlink data delivery process (step 1: CU sends PDCP PDUs to DU; step 2: DU sends received PDCP PDUs to UES; step 3: DU sends the data delivery status report received from UEs to CU) between an eNB (which include CU and DU) and the associated UEs because Dai explicitly teaches step 2 of the process that is not clearly stated in D1.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Dai for the benefit of describing a complete process ([0090] of Dai).
Independent claim 10 is rejected because it describes the same downlink data delivery process between an eNB and the associated UEs as disclosed by claim 1 (from CU point of view) and has the same subject matter.
Independent claim 16 is rejected because it is a claim of a generic apparatus that performs the method of claim 1 and has the same subject matter.
Independent claim 21 is rejected because it is a claim of a generic apparatus that performs the method of claim 10 and has the same subject matter.
Conclusion
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 JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/JIANYE WU/Primary Examiner, Art Unit 2462