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
1.This action is response to the communication filed on 03/16/2026. Claims 1-20 are pending.
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.
2. Claim 13 recites the limitation "the RX_DELIV" in line 17. There is insufficient antecedent basis for this limitation in the claim. Claims 14-15, 17-18 are also rejected under rationales of claim 13.
3. Claim 19 recites the limitation "the RX_DELIV" in line 17. There is insufficient antecedent basis for this limitation in the claim. Claims 14-18 are also rejected under rationales of claim 13.
Allowable Subject Matter
4. Claims 13 and 19 recite allowable subject matter. There is no prior art of record, singly or in combination teaches the feature of claim(s) limitations in context of the claims as a whole. However, claims 13 and 19 are not in allowance condition yet because of existing 112 issues in those claims.
5. For claim 13, Fujushiro et al. (US 20240080645), hereafter Fujushiro’0645 teaches a COUNT value as a Packet Data Convergence Protocol (PDCP) variable (Fujishiro [0006]). And Fujishiro (US 20240179800), hereafter Fujishiro’9800 teaches the gNB transmits MBS data of a certain MBS session to a plurality of UEs multicast or broadcast. In the PDCP layer, the gNB includes a PDCP entity associated with the MBS session (specifically, a transmission-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity starts transmission of the MBS session, the PDCP entity manages a PDCP variable updated in response to transmission of a PDCP packet in the MBS session (see Fujishiro’9800, [0094]-[0095]). But the combination of the Fujushiro’0645 and the Fujishiro’9800 does not teach obtaining, by the receiving side, a PDCP COUNT value based on the PDCP COUNT information, and initializing a status variable by using the PDCP COUNT value; and the initializing a status variable by using the PDCP COUNT value comprises: initializing the RX DELIV to the PDCP COUNT value; wherein the RX DELIV represents a first variable that is in a receive window of the receiving side and that is still waiting for reordering and not delivered to a higher layer as claimed. The same reasoning applies to claim 19.
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.
6. Claims 1-4, 11-12, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Akl et al. (US 20220225060) in view of Fujushiro et al. (US 20240080645), hereafter Fujishiro’9800 and further in view of Fujishiro (US 20240179800), hereafter Fujishiro’9800
Regarding claim 1:
An indication method for a status variable of a multicast service, comprising:
sending, by a transmitting side, packet data convergence protocol count (PDCP COUNT) information to a receiving side: (the UE receives message associated with packet data with 32-bit PDCP COUNT: Akl [0086]).
However, Akl does not teach sending the PDCP count information when establishing the multicast service.
In similar art, Fujushiro’0645 teaches a COUNT value as a Packet Data Convergence Protocol (PDCP) variable (Fujishiro [0006]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujushiro’0645’s ideas into Akl's system in order to provide an efficient multicast communication network (see Fujushiro’0645, [0005]).
However, Akl-Fujushiro’0645 does not explicitly teach sending the PDCP COUNT information to the receiving side when establishing the multicast service.
In similar art, Fujishiro’9800 teaches the gNB transmits MBS data of a certain MBS session to a plurality of UEs multicast or broadcast. In the PDCP layer, the gNB includes a PDCP entity associated with the MBS session (specifically, a transmission-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity starts transmission of the MBS session, the PDCP entity manages a PDCP variable updated in response to transmission of a PDCP packet in the MBS session (see Fujishiro’9800, [0094]-[0095]).
sending first signaling to the receiving side, wherein the first signaling comprises the PDCP COUNT information: (the gNB transmits MBS data of a certain MBS session to a plurality of UEs multicast via transmitter and receiver constitute a wireless communication. When the PDCP entity starts transmission of the MBS session, the PDCP entity manages a PDCP variable updated in response to transmission of a PDCP packet in the MBS session: Fujishiro’9800, [0094]-[0095]; [0043]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujishiro’9800’s ideas into Akl-Fujushiro’0645's system in order to provide an efficient multicast communication network (see ujishiro’9800, [0002]).
Regarding claim 2:
In addition to the rejection claim 1, Akl-Fujushiro’0645-Fujishiro’9800 further teaches the PDCP COUNT information further comprises at least one of a PDCP hyper frame number (HFN) value, or a sequence number (SN) value: (Fujushiro’0645' teaches the PDCP variable includes a PDCP SN and hyper frame number (HFN): [0170]); and the sending, by a transmitting side, PDCP COUNT information to a receiving side comprises at least one of the following; sending, by the transmitting side, the PDCP COUNT information to the receiving side in a transmission process of multicast data; or sending, by the transmitting side, the PDCP COUNT information to the receiving side based on feedback information of the receiving side: (communication system that provides a multicast service from a network to a user equipment and includes managing, by the user equipment, a COUNT value as a Packet Data Convergence Protocol (PDCP) variable: Fujushiro’0645 [0006]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujushiro’0645’s ideas into Akl-Fujishiro’9800's system in order to provide an efficient multicast communication network (see Fujushiro’0645, [0005]).
Regarding claim 3:
In addition to the rejection claim 1, Akl-Fujushiro’0645-Fujishiro’9800 further teaches the transmitting side is a network side device, and the receiving side is a terminal; or both the transmitting side and the receiving side are terminals: (the UE receives PDCP packet from gNB: Fujushiro’0645 [0170]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujushiro’0645’s ideas into Akl-Fujishiro’9800's system in order to provide an efficient multicast communication network (see Fujushiro’0645, [0005]).
Regarding claim 4:
In addition to the rejection claim 1, Akl-Fujushiro’0645-Fujishiro’9800 further teaches wherein the sending, by a transmitting side, PDCP COUNT information to a receiving side comprises at least one of the following: sending, by the transmitting side, a first data packet to the receiving side, wherein the first data packet comprises the PDCP COUNT information; or sending, by the transmitting side, a control protocol data unit (PDU) to the receiving side, wherein the control PDU comprises the PDCP COUNT information: (the initial value of RX_DELIV is 0, and in the case of unicast, both gNB and UE increment the HFN for each wrap-around of the PDCP SN based on the initial value. This synchronizes the HFNs of gNB and UE. In the case of multicast, which RX_DELIV the UE starts to receive the PDCP packet at is uncertain. Accordingly, the valid HFN (that is, the HFN managed by the gNB) is not known by looking at only the received PDCP packet. Note that the header of the PDCP PDU includes the PDCP SN but no HFN. In the following, the PDCP variable is the HFN and/or the COUNT value: Fujushiro’0645, [0172]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujushiro’0645’s ideas into Akl-Fujishiro’9800's system in order to provide an efficient multicast communication network (see Fujushiro’0645, [0005]).
Regarding claim 11:
In addition to the rejection claim 4, Akl-Fujushiro’0645-Fujishiro’9800 further teaches wherein the first data packet comprises indication information for a packet format, the indication information for the packet format indicates a data packet format, and the data packet format comprises a format of the first data packet that carries the PDCP COUNT information or a format of a data packet that carries only an SN value; the first data packet comprises indication information for a PDU type, the indication information for the PDU type indicates a data packet format, and the data packet format comprises a format of the first data packet that carries the PDCP COUNT information or a format of a data packet that carries only an SN value; or the first data packet comprises first indication information and a PDCP SN value, and the first indication information indicates whether the PDCP COUNT information exists: (managing, by the user equipment, a COUNT value as a Packet Data Convergence Protocol (PDCP) variable. The managing includes acquiring a PDCP Sequence Number (SN) included in a header of a PDCP packet received first from the network via multicast: Fujushiro’0645 [0006]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fujushiro’0645’s ideas into Akl-Fujishiro’9800's system in order to provide an efficient multicast communication network (see Fujushiro’0645, [0005]).
Regarding claim 12:
The method according to claim 4, wherein the control PDU comprises type indication information, and the type indication information indicates a type of the control PDU, wherein the type of the control PDU comprises one of the following: a type of the control PDU comprising the PDCP COUNT information, a type of a PDCP status report, a type of robust header compression (ROHC) feedback, or a type of ethernet header compression (EHC) feedback: (the limitation “sending, by the transmitting side, a first data packet to the receiving side, wherein the first data packet comprises the PDCP COUNT information” is selected from claim 4 to address, while the limitation “the sending, by the transmitting side, a control PDU to the receiving side” is not selected to address, therefore it does not need to address the limitation in claim 12).
Regarding claim 20:
This claim is rejected under rationales of claim 1.
7. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Akl-Fujushiro’0645-Fujishiro’9800 in view of Li et al. (EP 4262310 A1)
Regarding claim 5:
Akl-Fujushiro’0645-Fujishiro’9800 discloses the invention substantially as disclosed in claim 4, but does not explicitly teach in a case that the transmitting side sends the first signaling or the control PDU to the receiving side, the PDCP COUNT information comprises at least one of the following: PDCP COUNT information corresponding to a next to-be-sent data packet by the transmitting side; PDCP COUNT information corresponding to a latest sent data packet by the transmitting side; PDCP COUNT information corresponding to a data packet that has been sent by the transmitting side, wherein the data packet that has been sent does not comprise a latest sent data packet; or PDCP COUNT information corresponding to a future to-be-sent data packet by the transmitting side, wherein the future to-be-sent data packet does not comprise a next to-be-sent data packet.
In similar art, Li teaches to schedule packet transmission on each logical channel, the transmit device generally allocates a PDCP buffer corresponding to the to-be-sent buffer in the claims to each logical channel. All packets of the to-be-sent METU are put into the PDCP buffer, and sent in sequence (Li, page 11).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Li’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system in order to save time and development resources by implying Li’s ideas into Akl-Fujushiro’0645’s system.
8. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Akl-Fujushiro’0645-Fujishiro’9800 in view of Zheng et al. (US 20210014924).
Regarding claim 6:
Akl-Fujushiro’0645-Fujishiro’9800 discloses the invention substantially as disclosed in claim 4, but does not explicitly teach the sending, by the transmitting side, a first data packet to the receiving side comprises at least one of the following: sending, by the transmitting side, N first data packets in a case that a new receiving side is determined to join multicast service reception; sending, by the transmitting side, the N first data packets based on a quantity of data packets that have been sent; sending, by the transmitting side, the N first data packets based on a running status of a timer; or sending, by the transmitting side, the N first data packets based on feedback information of the receiving side; and N is a positive integer.
In similar art, Zheng teaches the transmitting may be in response to determining that a sequence number of a next PDCP data packet expected to be received is greater than a sequence number of a first PDCP data packet not delivered to an upper layer by a length of a reception window, wherein the reception window represents a predetermined number of PDCP data packets. The PDCP entity receives, from the transmitter device, in response to sending the PDCP status report, one or more PDCP data packets of the plurality of PDCP data packets that were not successfully received at the receiver device (Zheng [0132]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Zheng’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system in order to save time and development resources by implying Zheng’s ideas into Akl-Fujushiro’0645’s system.
8. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Akl-Fujushiro’0645-Fujishiro’9800 in view of Cai et al. (CN 113973284)
Regarding claim 7:
Akl-Fujushiro’0645-Fujishiro’9800 discloses the invention substantially as disclosed in claim 4, but does not explicitly teach the sending, by the transmitting side, a control PDU to the receiving side comprises at least one of the following: sending, by the transmitting side, one control PDU in a case that a new receiving side is determined to join multicast service reception; sending, by the transmitting side, the one control PDU based on a quantity of data packets that have been sent; sending, by the transmitting side, the one control PDU based on a running status of a timer; or sending, by the transmitting side, the one control PDU based on feedback information of the receiving side.
In similar art, Cai teaches the first terminal device and the second terminal device can distinguish the Uu SRB corresponding to a certain PDCP PDU is the Uu SRB, so as to correctly distinguish the different Uu SRB bearing data packet, improving the quality and efficiency of the data transmission (Cai page 33).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Cai’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system in order to save time and development resources by implying Cai’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system.
9. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Akl-Fujushiro’0645-Fujishiro’9800 in view of Fuskshiro et al. (US 20240015850) (hereafter Fuskshiro’5850).
Regarding claim 8:
Akl-Fujushiro’0645-Fujishiro’9800 discloses the invention substantially as disclosed in claim 4, but does not explicitly teach the PDCP COUNT information to the receiving side on a point-to-multipoint (PTM) transmission leg; or sending, by the transmitting side, the PDCP COUNT information to the receiving side on a point-to-point (PTP) transmission leg.
In similar art, Fuskshiro’5850 teaches the UE receives MBS data transmitted from the gNB through a transmission scheme either of the PTP transmission or the PTM transmission. The UE transmits to the gNB a message including information indicating a sequence number (SN) (hereinafter referred to as an “SN notification message”) of a received packet related to the switching. The SN may be a PDCP SN assigned in units of PDCP packets. The SN may be a COUNT value for identifying a PDCP packet. The COUNT value includes a Hyper Frame Number (HFN) and a PDCP SN. The SN may be an RLC SN assigned in units of RLC packets. In the following, assume mainly a case that the SN is a PDCP SN. Thus, a packet refers to a PDCP packet (see Fuskshiro’5850 [0112]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Fuskshiro’5850’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system in order to save time and development resources by implying Fuskshiro’5850’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system.
10. Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Akl-Fujushiro’0645-Fujishiro’9800 in view of Pradas et al. (US 20200235869)
Regarding claim 9:
Akl-Fujushiro’0645-Fujishiro’9800 discloses the invention substantially as disclosed in claim 4, but does not explicitly teach the sending, by the transmitting side, a control PDU to the receiving side comprises at least one of the following: when a radio link control (RLC) layer of the transmitting side is configured as an acknowledged mode (AM), sending, by the transmitting side, one control PDU to the receiving side; when an RLC layer of the transmitting side is configured as an unacknowledged mode (UM), sending, by the transmitting side, the control PDU to the receiving side based on hybrid automatic repeat request (HARQ) feedback information at a medium access control (MAC) layer, wherein the HARQ feedback information at the MAC layer indicates whether the control PDU is correctly received by the receiving side; or sending, by the transmitting side, a plurality of control PDUs or the control PDU for a plurality of times, to the receiving side.
In similar art, Pradas teaches when RLC Acknowledge Mode (AM) is configured, each RLC entity will perform retransmissions until the data has been successfully acknowledged or the maximum number of RLC retransmissions has been reached. In the latter case, the UE triggers the Radio Link Failure (RLF) procedure. In limited-coverage situations, the maximum number of RLC retransmissions may be reached (Pradas [0004]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify Pradas’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system in order to save time and development resources by implying Pradas’s ideas into Akl-Fujushiro’0645-Fujishiro’9800’s system.
Regarding claim 10:
In addition to the rejection claim 9, Akl-Fujushiro’0645-Fujishiro’9800- Pradas further teaches wherein the sending, by the transmitting side, the control PDU to the receiving side based on HARQ feedback information at a MAC layer comprises: in a case that it is determined, based on the HARQ feedback information at the MAC layer, that the control PDU is not correctly received by the receiving side, re-sending, by the transmitting side, the control PDU, to the receiving side; or re-generating, by the transmitting side, a control PDU and sending a re-generated control PDU to the receiving side: (the limitation “when a radio link control (RLC) layer of the transmitting side is configured as an acknowledged mode (AM), sending, by the transmitting side, one control PDU to the receiving side” is selected from claim 9 to address, therefore it does not need to address the limitation in claims 9-10).
11. 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.
Conclusions
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAN DAI T TRUONG whose telephone number is (571)272-7959. The examiner can normally be reached Monday-Friday 7:00 Am to 3:00 PM.
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, Follansbee John A can be reached on 571-272-3964. 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.
/LAN DAI T TRUONG/ Primary Examiner, Art Unit 2444
Prosecution Insights