DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
2. The restriction requirement has been withdrawn.
Claim Rejections - 35 USC § 102
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
4. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
5. Claims 1-4, 6, 7, 9, 10, 31, 40 and 42 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Huang et al. (US 2020/0323024 A1, hereinafter “Huang”).
Regarding claim 1, Huang teaches a service transmission method, applied to a network device, wherein the method comprises: receiving, on the basis of packet data convergence protocol (PDCP) entity configured for a broadcast/multicast service, data corresponding to at least one quality of service (QoS) flow of the broadcast/multicast service (figs. 16-19, ¶ [0056]-¶ [00058], ¶ [0059], replicating, by the access network device, the to-be-sent multicast service data at the packet data convergence protocol PDCP layer, and storing the to-be-sent multicast service data. ¶ [0224], The radio bearer configuration may carry one of the following information: a radio bearer ID, an evolved packet system bearer ID (bearer ID) corresponding to a multicast service, a quality of service (quality of service, QoS) flow (flow), configuration information of multicast service session information, PDCP configuration information, or RLC configuration information.); transmitting, through a multicast channel corresponding to the PDCP entity, data corresponding to at least one QoS flow to a plurality of target terminals (figs. 14, 16-19, ¶ [0261], ¶ [0268], user equipment switches to receive multicast service data in a multicast manner, and establishes a radio bearer applicable to receiving the multicast service data in the multicast manner.), and/or transmitting, through a unicast channel corresponding to the PDCP entity, data corresponding to the at least one QoS flow to one target terminal (figs. 14, 16-19, ¶ [0056], sending, by the access network device, to-be-sent multicast service data to a unicast radio link control (radio link control, RLC) entity by using a packet data convergence protocol (packet data convergence protocol, PDCP) layer, and sending the to-be-sent multicast service data in the unicast manner. ¶ [0261]).
Regarding claim 31, Huang teaches a service transmission method, applied to a terminal, wherein the method comprises: receiving, through a multicast channel or a unicast channel, data sent by a network device (figs. 14, 16-19, ¶ [0261], ¶ [0268], user equipment switches to receive multicast service data in a multicast manner, and establishes a radio bearer applicable to receiving the multicast service data in the multicast manner. ¶ [0056], sending, by the access network device, to-be-sent multicast service data to a unicast radio link control (radio link control, RLC) entity by using a packet data convergence protocol (packet data convergence protocol, PDCP) layer, and sending the to-be-sent multicast service data in the unicast manner. ¶ [0261]); parsing the data through a PDCP entity to obtain the parsed data, wherein the multicast channel and the unicast channel correspond to the same PDCP entity, and the PDCP entity is a PDCP entity configured for a broadcast/multicast service (figs. 16-19, ¶ [0056]-¶ [00058], ¶ [0059], replicating, by the access network device, the to-be-sent multicast service data at the packet data convergence protocol PDCP layer, and storing the to-be-sent multicast service data. ¶ [0224], The radio bearer configuration may carry one of the following information: a radio bearer ID, an evolved packet system bearer ID (bearer ID) corresponding to a multicast service, a quality of service (quality of service, QoS) flow (flow), configuration information of multicast service session information, PDCP configuration information, or RLC configuration information.).
Regarding claim 2, Huang teaches the service transmission method according to claim 1, wherein the method further comprises: sending, by medium access control (MAC) entity, in a case that the network device receives NACK feedback corresponding to first data on the multicast channel of a terminal or does not receive the feedback corresponding to the first data on the multicast channel of the terminal, retransmitted data to the target terminal through the unicast channel, wherein the first data comprises at least one MAC PDU (figs. 18A-19, ¶ [0063], ¶ [0283], The user equipment specifies, by using a fixed relationship between feedback information and a retransmitted data packet, for example, a manner of sending a NACK by using a physical layer feedback channel, that the access network device retransmits, in the unicast manner, a data packet. ¶ [0314], ¶ [0315]).
Regarding claim 3, Huang teaches the service transmission method according to claim 2, wherein the multicast channel comprises: a first radio link control (RLC) entity, a first MAC entity, and a first physical layer (PHY) entity (figs. 17-19); the transmitting, through the multicast channel corresponding to the PDCP entity, data corresponding to at least one QoS flow to the plurality of target terminals comprises: transmitting, through the first RLC entity, the first MAC entity, and the first physical layer (PHY) entity in sequence, data corresponding to at least one QoS flow to the plurality of target terminals (figs. 17-19, ¶ [0286]).
Regarding claim 4, Huang teaches the service transmission method according to claim 3, wherein the unicast channel comprises: a second radio link control (RLC) entity, a second MAC entity, and a second physical layer (PHY) entity (figs. 17-19); the transmitting, through the unicast channel corresponding to the PDCP entity, data corresponding to at least one QoS flow to one target terminal comprises: transmitting, through the second RLC entity, the second MAC entity, and the second physical layer (PHY) entity in sequence, data corresponding to at least one QoS flow to one target terminal (figs. 17-19, ¶ [0289]).
Regarding claim 6, Huang teaches the service transmission method according to claim 4, wherein the sending, by medium access control (MAC) entity, retransmitted data to the target terminal through the unicast channel, comprises at least one of the following: sending, by the first MAC entity, the first data that needs to be retransmitted to the second MAC entity, and sending, through the second MAC entity and the second PHY entity, the first data to the target terminal; sending, by the first MAC entity, feedback information to the first RLC entity, or triggering, by the first RLC entity, the PDCP entity to send the second data to the second RLC entity through F1 interface signaling or F1 control data frame, and sending, through the second MAC entity and the second PHY entity, the second data to the target terminal, wherein the second data is an RLC SDU corresponding to the first data that needs to be retransmitted, or the second data is the first data that needs to be retransmitted, or the second data is an RLC SDU multiplexed with other data, or, the second data is an RLC SDU in which a plurality of RLC SDUs corresponding to the first data are segmented; sending, by the first MAC entity, the feedback information to the first RLC entity, or triggering, by the first RLC layer, the PDCP entity to send the second data to the second RLC entity, and sending, through the second MAC entity and the second PHY entity, the second data to the target terminal, wherein the second data is an RLC SDU corresponding to the first data that needs to be retransmitted, or the second data is an RLC SDU multiplexed with other data, or, the second data is an RLC SDU in which a plurality of RLC SDUs corresponding to the first data are segmented (figs. 17-18, ¶ [0289], receiving in the multicast manner fails, an ARQ entity of the user equipment initiates an RLC status report, to request a multicast RLC entity of an access network device to retransmit PDU data corresponding to a missing RLC SN identifier. Where it is implicit that the RLC status report is forwarded from PHY entity to MAC entity to RLC entity. ¶ [0280], After the user equipment in a multicast group fails to receive multicast service data, an access network device retransmits the multicast service data. In this embodiment of the present invention, the multicast service data may be retransmitted in the unicast manner. ¶ [0281], In a process of retransmitting a data packet, the user equipment may receive the multicast service data in both a multicast manner and a unicast manner. Fig. 19, where the missing RLC SDU is sent through the unicast/second MAC entity and second PHY entity to the target terminal); transmitting transparently, by the first MAC entity, the first data that needs to be retransmitted to the second MAC entity through the first RLC entity and the PDCP entity, and sending, through the second PHY entity, the first data that needs to be retransmitted to the target terminal.
Regarding claim 7, Huang teaches the service transmission method according to claim 6, wherein in a case that the first MAC entity sends the first data that needs to be retransmitted to the second MAC entity, the method further comprises: sending, by the first MAC entity, HARQ process information used by the first data last time to the second MAC entity (the limitation further limits a non-selected alternative limitation).
Regarding claim 9, Huang teaches the service transmission method according to claim 6, wherein the F1 interface signaling or the F1 control data frame comprises: a sequence number field of PDCP packet data unit (PDU) of the retransmitted data; or, a start sequence number of the PDCP packet data unit (PDU) of the retransmission data, a quantity of PDUs comprised in the retransmitted data, a start sequence number of MAC service data unit (SDU) of the retransmitted data, and a quantity of SDUs comprised in the retransmitted data (the limitation further limits a non-selected alternative limitation).
Regarding claim 10, Huang teaches the service transmission method according to claim 1, further comprising: in a case that the RLC entity of the multicast channel PTM is in AM mode, if a negative acknowledgment or/and positive acknowledgment for an RLC SDU or RLC SDU segment is received, the negative acknowledgment or/and positive acknowledgment is indicated by a state PDU from an AM RLC entity at a peer layer, the state PDU comprises a payload (figs. 17-19, ¶ [0225], ¶ [0288], When the PDCP layer determines that a data packet is lost, for example, when SNs are inconsecutive, the PDCP layer may initiate a retransmission request, for example, notify the access network device of a missing data packet SN number by using a PDCP status report. The retransmission request is fed back to a unicast RLC entity corresponding to the access network device in the unicast manner, and is submitted by the unicast RLC entity of the access network device to the multicast PDCP layer. ¶ [0289], when receiving in the multicast manner fails, an ARQ entity of the user equipment initiates an RLC status report, to request a multicast RLC entity of an access network device to retransmit PDU data corresponding to a missing RLC SN identifier.).
Regarding claim 40, Huang teaches a network device comprises: a transceiver, configured to perform the service transmission method according to claim 1 (figs. 1A, 1B, 14, 16-19, 20, ¶ [0291]).
Regarding claim 42, Huang teaches a terminal comprises: a transceiver, configured to receive, through a multicast channel or a unicast channel, data sent by a network device; and a processor, configured to perform the parsing step in the service transmission method according to claim 31 (figs. 1A, 1B, 14, 16-19, 21, ¶ [0319]).
6. Claims 21, 22 and 46 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by He et al. (US 2023/0275704 A1, hereinafter “He”).
Regarding claim 21, He teaches a service transmission method, applied to a terminal, wherein the method comprises: determining, according to whether a logical channel and/or HARQ process corresponding to radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent (figs. 1, 2, ¶ [0007], configuration of enabling or disabling of HARQ uplink retransmission for a logical channel, and association between logical channels and HARQ processes. ¶ [0033], Disabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device does not need to perform retransmission with grants based on a decoding status of uplink data of the terminal. ¶ [0034]).
Regarding claim 46, He teaches the service transmission method according to claim 21, comprising at least one of the following: allowing data of the logical channel LCH whose HARQ feedback is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose HARQ feedback is disabled on one MAC PDU; allowing data of the logical channel LCH whose data retransmission is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose data retransmission is disabled on one MAC PDU (¶ [0039], in a case that the HARQ uplink retransmission indication is used to indicate that the first uplink grant is for scheduling transmission with HARQ uplink retransmission disabled, only data of a logical channel configured with HARQ uplink retransmission disabled can be multiplexed into MAC PDU corresponding to the first uplink grant; and in a case that the HARQ uplink retransmission indication is used to indicate that the first uplink grant is for scheduling transmission with HARQ uplink retransmission enabled, only data of a logical channel configured with HARQ uplink retransmission enabled can be multiplexed into the MAC PDU corresponding to the first uplink grant. ¶ [0044]).
Regarding claim 22, He teaches the service transmission method according to claim 46, wherein the determining, according to whether the logical channel and/or HARQ process corresponding to the radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent, comprises at least one of the following: not starting the HARQ feedback for received data in a case that a logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback disabling; not starting the retransmission of the data that fails to be sent in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission disabling (¶ [0033], Disabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device does not need to perform retransmission with grants based on a decoding status of uplink data of the terminal. ¶ [0007]); starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that fails to be sent (¶ [0034], Enabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device needs to perform retransmission with grants based on a decoding status of uplink data of the terminal. For example, in a case of a decoding failure of some uplink data, the network side device needs to perform retransmission with grants for the uplink data decoded unsuccessfully. ¶ [0007]); starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data, wherein m is an integer greater than 1, and one MAC PDU comprises a plurality of cascaded RLC PDUs; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that failed to be sent, wherein m is an integer greater than 1, and one MAC PDU comprises the plurality of cascaded RLC PDUs.
Claim Rejections - 35 USC § 103
7. 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.
8. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
9. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Huang in view of Erceg et al. (US 2019/0200415 A1, hereinafter “Erceg”).
Regarding claim 5, Huang teaches the service transmission method according to claim 4, including the first MAC entity and the second MAC entity (figs. 17-19, ¶ [0025]).
Huang does not explicitly teach wherein the first MAC entity and the second MAC entity share one MAC entity.
Erceg teaches the first MAC entity and the second MAC entity share one MAC entity (figs. 2, 3, ¶ [0032], The unified MAC module 204 may include a primary MAC module 306 and one or more secondary MAC modules 308A-N).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to utilize a shared MAC entity including the first MAC entity and the second MAC entity in the system of Huang. The motivation for doing this is a matter of design choice.
10. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Huang in view of Wang et al. (2023/0116092 A1, hereinafter “Wang”).
Regarding claim 11, Huang teaches the service transmission method according to claim 10, wherein an indication information configured for distinguishing terminals is related to at least one of the following information: cell radio network temporary identifier (C-RNTI) of the terminal, a truncated C-RNTI of the terminal, recovery identification information of the terminal, truncated recovery identification information of the terminal, and a temporary mobile user identification code TMSI of the terminal, an offset configured by a network side device, and a unique index of the terminal in the group (¶ [0235], ¶ [0218], In this case, the user equipment may receive scheduling information of the base station for a specific identity (identity, ID) of the user equipment, and perform corresponding data receiving and feedback. The specific ID may be a cell radio network temporary identity (cell radio network temporary identity, C-RNTI), a medium access control (medium access control, MAC) address, or another ID that can uniquely identify the user equipment).
Huang does not explicitly teach wherein the state PDU indication further comprises: indication information configured for distinguishing terminals.
Wang teaches wherein the state PDU indication further comprises: indication information configured for distinguishing terminals, wherein the indication information configured for distinguishing terminals is related to at least one of the following information: cell radio network temporary identifier (C-RNTI) of the terminal, a truncated C-RNTI of the terminal, recovery identification information of the terminal, truncated recovery identification information of the terminal, and a temporary mobile user identification code TMSI of the terminal, an offset configured by a network side device, and a unique index of the terminal in the group (fig. 10, ¶ [0051], the UE provides uplink feedback for MBS data reception status through the PTP RB using a cell radio network temporary identifier (C-RNTI)).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include an indication information, configured for distinguishing terminals, in the state PDU in the system of Huang to utilize conventional techniques in the art.
11. Claims 16, 17 and 45 are rejected under 35 U.S.C. 103 as being unpatentable over Huang in view of He.
Regarding claim 16, Huang teaches the service transmission method according to claim 1.
Huang does not explicitly teach further comprising: determining, according to whether a logical channel and/or HARQ process corresponding to radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent.
He teaches determining, according to whether a logical channel and/or HARQ process corresponding to radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent (figs. 1, 2, ¶ [0007], configuration of enabling or disabling of HARQ uplink retransmission for a logical channel, and association between logical channels and HARQ processes. ¶ [0033], Disabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device does not need to perform retransmission with grants based on a decoding status of uplink data of the terminal. ¶ [0034], ¶ [0038]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to determine, according to whether a logical channel and/or HARQ process corresponding to radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent in the system of Huang to improve industrial applicability.
Regarding claim 45, Huang in view of He teaches the service transmission method according to claim 16.
Huang does not explicitly teach comprising at least one of the following: allowing data of the logical channel LCH whose HARQ feedback is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose HARQ feedback is disabled on one MAC PDU; allowing data of the logical channel LCH whose data retransmission is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose data retransmission is disabled on one MAC PDU.
He teaches at least one of the following: allowing data of the logical channel LCH whose HARQ feedback is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose HARQ feedback is disabled on one MAC PDU; allowing data of the logical channel LCH whose data retransmission is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose data retransmission is disabled on one MAC PDU (¶ [0039], in a case that the HARQ uplink retransmission indication is used to indicate that the first uplink grant is for scheduling transmission with HARQ uplink retransmission disabled, only data of a logical channel configured with HARQ uplink retransmission disabled can be multiplexed into MAC PDU corresponding to the first uplink grant; and in a case that the HARQ uplink retransmission indication is used to indicate that the first uplink grant is for scheduling transmission with HARQ uplink retransmission enabled, only data of a logical channel configured with HARQ uplink retransmission enabled can be multiplexed into the MAC PDU corresponding to the first uplink grant. ¶ [0044]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include at least one of the following: allowing data of the logical channel LCH whose HARQ feedback is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose HARQ feedback is disabled on one MAC PDU; allowing data of the logical channel LCH whose data retransmission is enabled to be multiplexed on one MAC PDU, and multiplexing data of the logical channel LCH whose data retransmission is disabled on one MAC PDU in the system of Huang to improve quality of service (¶ [0005] and ¶ [0053] of He).
Regarding claim 17, Huang in view of He teaches the service transmission method according to claim 45.
Huang does not explicitly teach wherein the determining, according to whether the logical channel and/or HARQ process corresponding to the radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent, comprises at least one of the following: not starting the HARQ feedback for received data in a case that a logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback disabling; not starting the retransmission of the data that fails to be sent in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission disabling; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that fails to be sent; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data, wherein m is an integer greater than 1, and one MAC PDU comprises a plurality of cascaded RLC PDUs; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that failed to be sent, wherein m is an integer greater than 1, and one MAC PDU comprises the plurality of cascaded RLC PDUs.
He teaches wherein the determining, according to whether the logical channel and/or HARQ process corresponding to the radio resource control RLC PDU is configured with enabling or disabling of HARQ feedback and/or retransmission, whether to start HARQ feedback and/or retransmission of data that fails to be sent, comprises at least one of the following: not starting the HARQ feedback for received data in a case that a logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback disabling; not starting the retransmission of the data that fails to be sent in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission disabling (¶ [0033], Disabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device does not need to perform retransmission with grants based on a decoding status of uplink data of the terminal. ¶ [0007]); starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that fails to be sent (¶ [0034], Enabling HARQ uplink retransmission as mentioned in each embodiment of this specification may include: the network side device needs to perform retransmission with grants based on a decoding status of uplink data of the terminal. For example, in a case of a decoding failure of some uplink data, the network side device needs to perform retransmission with grants for the uplink data decoded unsuccessfully. ¶ [0007]); starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data, wherein m is an integer greater than 1, and one MAC PDU comprises a plurality of cascaded RLC PDUs; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that failed to be sent, wherein m is an integer greater than 1, and one MAC PDU comprises the plurality of cascaded RLC PDUs.
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include at least one of: not starting the HARQ feedback for received data in a case that a logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback disabling; not starting the retransmission of the data that fails to be sent in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission disabling; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data; starting, in a case that the logical channel LCH corresponding to one RLC PDU in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that fails to be sent; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with HARQ feedback enabling, the HARQ feedback for received data, wherein m is an integer greater than 1, and one MAC PDU comprises a plurality of cascaded RLC PDUs; starting, in a case that the logical channel LCH corresponding to more than or equal to m RLC PDUs in the MAC PDU is configured with data retransmission enabling, the retransmission of the data that failed to be sent, wherein m is an integer greater than 1, and one MAC PDU comprises the plurality of cascaded RLC PDUs in the system of Huang to improve quality of service (¶ [0005] and ¶ [0053] of He).
Allowable Subject Matter
12. Claim 8 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
13. The following is a statement of reasons for the indication of allowable subject matter: prior art of record fails to teach or fairly suggest the limitations specified in the base claim, intervening claims and “wherein the sending, by the first MAC entity, the feedback information to the first RLC entity, or triggering, by the first RLC layer, the PDCP entity to send the second data to the second RLC entity, and sending, through the second MAC entity and the second PHY entity, the second data to the target terminal, further comprises: sending, by the first MAC entity, the first data that needs to be retransmitted and HARQ process information used for the last sending of the first data to the first RLC entity, and forwarding, by the first RLC entity, the first data that needs to be retransmitted and HARQ process information used for the last sending of the first data to the PDCP entity, and forwarding, through the PDCP entity, the first data that needs to be retransmitted and HARQ process information used for the last sending of the first data to the second RLC entity, and sending, by the second PHY entity, the second data and the HARQ process used for the last sending of the first data to the target terminal through the second MAC entity, wherein the second data is the first data that needs to be retransmitted.”
Conclusion
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477