DETAILED ACTION
This communication is in response to applicant’s response filed under 37 C.F.R. §1.111 in response to a non-final office action. Claims 2, 5-9, 11, 14-18, 20 have been canceled. Claims 1, 3, 4, 10, 12-13, and 19 are subject to examination.
Response to Arguments
Applicant's arguments filed 02/13/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
The applicant argues, on page 6 in substance that" Specifically, in the cited paragraphs, Yoshioka 413 describes that an eMBB PUCCH maybe for a HARQ-ACK, an SR, or CSI, however, in all cases, the URLLC HARQ-ACK and URLLC PUCCH would be both prioritized. In other words, Yoshioka 413 merely describes performing HARQ-ACK multiplexing with the same priority on a PUCCH.
By contrast, unamended claim 1 emphasizes "determine uplink control information (UCI) multiplexing on a single physical uplink control channel (PUCCH) when a low priority PUCCH
carrying a hybrid automatic repeat request-acknowledgement (HARQ-ACK) collides with a high priority PUCCH carrying a HARQ-ACK based on a radio resource control (RRC) configuration."
Therefore, Yoshioka413 fails to teach, disclose, or suggest, at least, "determine uplink
control information (UCI) multiplexing on a single physical uplink control channel (PUCCH) when a low priority PUCCH carrying a hybrid automatic repeat request-acknowledgement (HARQ-ACK) collides with a high priority PUCCH carrying a HARQ-ACK based on a radio resource control (RRC) configuration," as recited in unamended claim 1."
Examiner’s Response:
The examiner respectfully disagrees. Yoshioka413 teaches in Fig 4 that channel collision occurs and eMBB HARQ-ACK”, and “URLLC HARQ-ACK” collide with each other where URLLC priority may be higher than eMBB priority[0037]. The “eMBB HARQ-ACK” refers to HARQ-ACK for UCI associated with eMBB, the “eMBB SR” is SR for UCI associated with eMBB, and “URLLC HARQ-ACK” refers to HARQ-ACK for UCI associated with URLLC[046]. Yoshioka413 further in [0047 teaches when the collision control is applied a process in which HARQ-ACK and SR are multiplexed is performed, and in a final state, “eMBB HARQ-ACK+SR” and “URLLC HARQ-ACK” are transmitted. However, claim 1 merely recites ... determine uplink control information (UCI) multiplexing on a single physical uplink control channel (PUCCH) ...collides with a high priority PUCCH carrying a HARQ-ACK based on a radio resource control (RRC) configuration,
Applicant’s Argument:
The applicant argues, on page 7-8 in substance that "Specifically, after reviewing the cited paragraphs of Yoshioka413, a person having ordinary skill in the art would have realized that, in Yoshioka413, the URLLC PUCCH (for HARQ-ACK) is always transmitted and the eMBB PUCCH (for HARQ-ACK) is always dropped because Yoshioka 413, at least in the cited paragraphs, does NOT describe that the dropping operation is performed only when (i) the timeline condition or (ii) the condition that HARQ-ACK multiplexing with different priorities is supported/configured is not satisfied. The Office Action also mentions that Yoshioka413 does NOT describe "determine a processing timeline for the UCI multiplexing ...". See, e.g., page 4 of the Office Action. Therefore, Yoshioka 413 also fails to teach, disclose, or suggest, at least, "when the processing timeline is not satisfiable or the PUCCH configured for the high priority HARQ-ACK is not capable of supporting the multiplexed HARQ-ACK bits, drop the low priority HARQ-ACK, and transmit only the high priority HARQ-ACK only on the PUCCH configured for the high priority HARQ-ACK," as recited in unamended claim 1.”
Examiner’s Response:
The examiner respectfully disagrees. Yoshioka413 teaches a channel having a lower priority of the colliding channels may be dropped. The collisions occurs in time domain and [0088] The channel collision may be detected in the time domain in fig. 5 Yoshioka413 teaches the “eMBB SR” is dropped. In a final state, the “eMBB HARQ-ACK” and the “URLLC HARQ-ACK” are transmitted. Therefore QoSs (Quality of Services) that defer in a throughput, a delay time, a packet loss rate and the control in the collision between channels associated with different service types has been discussed. For example, a channel having a lower priority of the colliding channels may be dropped. However, claim1 merely recites ...processing timeline is not satisfiable ... drop the low priority...configured for the high priority HARQ-ACK
Applicant’s Argument:
The applicant argues, on page 7-8 in substance that "Specifically, the cited paragraph [0032] of Li states: When the UE processes the HARQ-ACK codebooks with high and low priorities, ... Li, however, does NOT describe that those methods would be applied under what particular condition. Also, when multiplexing is performed, Li merely describes that one PUCCH resource is selected without describing which URLLC PUCCH resource should be selected.”
Examiner’s Response:
The examiner respectfully disagrees. Li teaches when there is a conflict in time domain UE will discard the PUCCH channel of the low-priority HARQ-ACK and only transmit the PUCCH channel of high-priority HARQ-ACK codebook. Further, Li teaches, later in time domain that the low-priority HARQ-ACK codebook is transmitted and also points out that channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook which examiner is construing that in certain time domain low priority HARQ-ACK codebook drops and multiplexing only under certain time domain. However, claim 1 merely recites determine a processing timeline for the UCI multiplexing, and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits."
Regarding all other arguments presented by applicant, the arguments are substantially the same as those which have already been addressed above and in the interest of brevity; the examiner directs the applicant to those responses above.
Claim Rejections - 35 USC § 103
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.
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 1, 10, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yoshioka et al. (Yoshioka_413 hereafter) (US 20220225413 A1) in view of Li (Li hereafter) (US 20230094455 A1).
Regarding claim 1 Yoshioka_413 teaches, A user equipment (UE), comprising: a processor configured to:
determine uplink control information (UCI) ([0039]PUCCH resource set is determined by a UCI payload size) multiplexing ([0048]one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH) on a single physical uplink control channel (PUCCH) ([0038] A channel collision may be detected when multiple channels overlap at least in a time domain. ) when a low priority PUCCH carrying a hybrid automatic repeat request-acknowledgement (HARQ-ACK) collides with a high priority PUCCH carrying a HARQ-ACK ([0049] the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied) based on a radio resource control (RRC) configuration (RRC connection) (Yoshioka_413; [0039] In FIG. 3, (*) indicates that a PUCCH resource set is determined by a UCI payload size, and that a PUCCH resource is determined by a PUCCH resource indicator field, which is the same as a PUCCH-resource determining method for HARQ-ACK after an RRC connection. [0048]As a collision condition, a case in which an opportunity to transmit UCI (hereafter referred to as “URLLC-PUCCH”) associated with URLLC, on a PUCCH resource occurs; in which an opportunity to transmit UCI (hereafter referred to as “eMBB-PUCCH”) associated with eMBB, on another PUCCH resource occurs; and in which at least one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH, 0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized ),
when the processing timeline is not satisfiable, or the PUCCH configured for the high priority HARQ-ACK is not capable of supporting the multiplexed HARQ-ACK bits ([0035] (defer in a throughput, a delay time, a packet loss rate), drop the low priority HARQ-ACK, and transmit only the high priority HARQ-ACK only on the PUCCH configured for the high priority HARQ-ACK (URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped, URLLC HARQ-ACK” are transmitted) (Yoshioka_413; [0035] the case with eMBB (enhanced Mobile Broadband) enabling high speed and large capacity; and URLLC (Ultra Reliable and Low Latency Communications) enabling high reliability and low delay communication. In other words, QoSs (Quality of Services) that defer in a throughput, a delay time, a packet loss rate, or the like are assumed to be provided., [0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized. Next, the collision control given by “eMBB vs. eMBB” and/or “URLLC vs. URLLC” is applied, and UCI to be transmitted based on a given UCI type, as illustrated in FIG. 3, may be determined. Then, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized and the process may be repeated. Alternatively, an unintended error may be defined for the user apparatus 20. [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped. In a final state, the “eMBB HARQ-ACK” and the “URLLC HARQ-ACK” are transmitted, [0037], [0088]).
Yoshioka_413 fails to explicitly teach, determine a processing timeline for the UCI multiplexing, and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits,
However, in the same field of endeavor Li teaches, determine a processing timeline (conflicts in time domain) for the UCI multiplexing (satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook), and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK (channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook) when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits (one PUCCH resource is selected), and (Li; [0032] When the UE processes the HARQ-ACK codebooks with high and low priorities, it processes the HARQ-ACK codebooks with corresponding processing rules, such as: when the PUCCH resource of the high priority HARQ-ACK codebook and the PUCCH resource of the low priority HARQ-ACK codebook conflicts in time domain, the UE will discard the PUCCH channel of the low-priority HARQ-ACK codebook, that is, discard the low-priority HARQ-ACK codebook, and only transmit the PUCCH channel of high-priority HARQ-ACK codebook
…. channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook that satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook).
It would have been obvious to one of ordinary skilled in the art before the effective filing date to create the invention of Yoshioka_413 to include the above recited limitations as taught by Li in order to support two types of HARQ-ACK codebooks with high and low priorities (Li; [0031]).
Regarding claim 10 Yoshioka_413 teaches, A user equipment (UE), comprising: a processor configured to:
determine uplink control information (UCI) ([0039]PUCCH resource set is determined by a UCI payload size) multiplexing ([0048]one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH) on a single physical uplink control channel (PUCCH) ([0038] A channel collision may be detected when multiple channels overlap at least in a time domain. ) when a low priority PUCCH carrying a hybrid automatic repeat request-acknowledgement (HARQ-ACK) collides with a high priority PUCCH carrying a HARQ-ACK ([0049] the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied) based on a radio resource control (RRC) configuration (RRC connection) (Yoshioka_413; [0039] In FIG. 3, (*) indicates that a PUCCH resource set is determined by a UCI payload size, and that a PUCCH resource is determined by a PUCCH resource indicator field, which is the same as a PUCCH-resource determining method for HARQ-ACK after an RRC connection. [0048]As a collision condition, a case in which an opportunity to transmit UCI (hereafter referred to as “URLLC-PUCCH”) associated with URLLC, on a PUCCH resource occurs; in which an opportunity to transmit UCI (hereafter referred to as “eMBB-PUCCH”) associated with eMBB, on another PUCCH resource occurs; and in which at least one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH, 0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized ),
when the processing timeline is not satisfiable, or the PUCCH configured for the high priority HARQ-ACK is not capable of supporting the multiplexed HARQ-ACK bits ([0035] (defer in a throughput, a delay time, a packet loss rate), forgo receiving the low priority HARQ-ACK, and receive only the high priority HARQ-ACK only on the PUCCH configured for the high priority HARQ-ACK (URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped, URLLC HARQ-ACK” are transmitted) (Li; [0035] the case with eMBB (enhanced Mobile Broadband) enabling high speed and large capacity; and URLLC (Ultra Reliable and Low Latency Communications) enabling high reliability and low delay communication. In other words, QoSs (Quality of Services) that defer in a throughput, a delay time, a packet loss rate, or the like are assumed to be provided., [0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized. Next, the collision control given by “eMBB vs. eMBB” and/or “URLLC vs. URLLC” is applied, and UCI to be transmitted based on a given UCI type, as illustrated in FIG. 3, may be determined. Then, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized and the process may be repeated. Alternatively, an unintended error may be defined for the user apparatus 20. [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped. In a final state, the “eMBB HARQ-ACK” and the “URLLC HARQ-ACK” are transmitted,[0037], [0088]).
Yoshioka_413 fails to explicitly teach, determine a processing timeline for the UCI multiplexing, and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits,
However, in the same field of endeavor Li teaches, determine a processing timeline (conflicts in time domain) for the UCI multiplexing (satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook), and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK (channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook) when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits (one PUCCH resource is selected), and (Li; [0032] When the UE processes the HARQ-ACK codebooks with high and low priorities, it processes the HARQ-ACK codebooks with corresponding processing rules, such as: when the PUCCH resource of the high priority HARQ-ACK codebook and the PUCCH resource of the low priority HARQ-ACK codebook conflicts in time domain, the UE will discard the PUCCH channel of the low-priority HARQ-ACK codebook, that is, discard the low-priority HARQ-ACK codebook, and only transmit the PUCCH channel of high-priority HARQ-ACK codebook….channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook that satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook).
It would have been obvious to one of ordinary skilled in the art before the effective filing date to create the invention of Yoshioka_413 to include the above recited limitations as taught by Li in order to support two types of HARQ-ACK codebooks with high and low priorities (Li; [0031]).
Regarding claim 19 Yoshioka_413 teaches, A user equipment (UE), comprising: a processor configured to:
determine uplink control information (UCI) ([0039]PUCCH resource set is determined by a UCI payload size) multiplexing ([0048]one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH) on a single physical uplink control channel (PUCCH) ([0038] A channel collision may be detected when multiple channels overlap at least in a time domain. ) when a low priority PUCCH carrying a hybrid automatic repeat request-acknowledgement (HARQ-ACK) collides with a high priority PUCCH carrying a HARQ-ACK ([0049] the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied) based on a radio resource control (RRC) configuration (RRC connection) (Yoshioka_413; [0039] In FIG. 3, (*) indicates that a PUCCH resource set is determined by a UCI payload size, and that a PUCCH resource is determined by a PUCCH resource indicator field, which is the same as a PUCCH-resource determining method for HARQ-ACK after an RRC connection. [0048]As a collision condition, a case in which an opportunity to transmit UCI (hereafter referred to as “URLLC-PUCCH”) associated with URLLC, on a PUCCH resource occurs; in which an opportunity to transmit UCI (hereafter referred to as “eMBB-PUCCH”) associated with eMBB, on another PUCCH resource occurs; and in which at least one PUCCH overlaps the URLLC-PUCCH and the eMBB-PUCCH, [0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized),
when the processing timeline is not satisfiable, or the PUCCH configured for the high priority HARQ-ACK is not capable of supporting the multiplexed HARQ-ACK bits ([0035] (defer in a throughput, a delay time, a packet loss rate), dropping the low priority HARQ-ACK, and transmit only the high priority HARQ-ACK only on the PUCCH configured for the high priority HARQ-ACK (URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped, URLLC HARQ-ACK” are transmitted) (Yoshioka_413; [0035] the case with eMBB (enhanced Mobile Broadband) enabling high speed and large capacity; and URLLC (Ultra Reliable and Low Latency Communications) enabling high reliability and low delay communication. In other words, QoSs (Quality of Services) that defer in a throughput, a delay time, a packet loss rate, or the like are assumed to be provided., [0049] The collision control that is first applied is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” may be prioritized. Next, the collision control given by “eMBB vs. eMBB” and/or “URLLC vs. URLLC” is applied, and UCI to be transmitted based on a given UCI type, as illustrated in FIG. 3, may be determined. Then, when the URLLC-PUCCH and eMBB-PUCCH further overlap, the collision control that is applied again is given by “eMBB vs. URLLC,” and for example, “URLLC-PUCCH” is prioritized and the process may be repeated. Alternatively, an unintended error may be defined for the user apparatus 20. [0050] As illustrated in FIG. 5 in which the above collision control is applied, when “eMBB SR” collides with “eMBB HARQ-ACK” and “URLLC HARQ-ACK”, the collision control that is first applied is given by “eMBB vs. URLLC,” and for example, the “URLLC HARQ-ACK” is prioritized and the “eMBB SR” is dropped. In a final state, the “eMBB HARQ-ACK” and the “URLLC HARQ-ACK” are transmitted, [0037, [0088]).
Yoshioka_413 fails to explicitly teach, determining a processing timeline for the UCI multiplexing, and multiplexing high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits.
However, in the same field of endeavor Li teaches, determine a processing timeline (conflicts in time domain) for the UCI multiplexing (satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook), and multiplex high priority HARQ-ACK and low priority HARQ-ACK on a PUCCH configured for the high priority HARQ-ACK (channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook) when the processing timeline is satisfiable and the PUCCH configured for the high priority HARQ-ACK is capable of supporting multiplexed HARQ-ACK bits (one PUCCH resource is selected), and (Li; [0032] When the UE processes the HARQ-ACK codebooks with high and low priorities, it processes the HARQ-ACK codebooks with corresponding processing rules, such as: when the PUCCH resource of the high priority HARQ-ACK codebook and the PUCCH resource of the low priority HARQ-ACK codebook conflicts in time domain, the UE will discard the PUCCH channel of the low-priority HARQ-ACK codebook, that is, discard the low-priority HARQ-ACK codebook, and only transmit the PUCCH channel of high-priority HARQ-ACK codebook….channel multiplexing is performed on the high-priority HARQ-ACK codebook and the low-priority HARQ-ACK codebook that satisfy the channel multiplexing conditions, and one PUCCH resource is selected to transmit the high-priority HARQ-ACK codebook).
It would have been obvious to one of ordinary skilled in the art before the effective filing date to create the invention of Yoshioka_413 to include the above recited limitations as taught by Li in order to support two types of HARQ-ACK codebooks with high and low priorities (Li; [0031]).
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Yoshioka_413-Li as applied to claims 1 and 10 above, and further in view of Takahashi et al. (Takahashi hereafter) (US 20230048080 A1).
Regarding claims 3 and 12 Yoshioka_413-Li teaches, The claim 1 and 10,
Yoshioka_413-Li fails to explicitly teach, wherein a plurality of RRC parameters is configured to allow multiplexing of HARQ-ACK codebooks with different priorities on the single PUCCH.
However, in the same field of endeavor Takahashi teaches, wherein a plurality of RRC parameters is configured to allow multiplexing of HARQ-ACK codebooks with different priorities on the single PUCCH. (Takahashi; [0048] priorities may be set for HARQ-ACK codebooks corresponding to these HARQ-ACKs. [0050] The collision between different UL signals/UL channels may be a case where time resources (or time resources and frequency resources) of the different UL signals or UL channels overlap with each other or a case where transmission timing of the different UL signals or UL channels overlap with each other. [0052] UE may send HARQ-ACK feedback using one piece of PUCCH resource for every HARQ-ACK codebook including one or more bits of delivery acknowledgement information (for example, hybrid automatic repeat request acknowledgement (HARQ-ACK)). HARQ-ACK bits may be referred to as HARQ-ACK information, HARQ-ACK information bits, or the like. [0055] type-1 HARQ-ACK codebook and the type-2 HARQ-ACK codebook is used may be set in the UE by using higher layer parameters [0056] type-1 HARQ-ACK codebook, a UE may feedback, in a given range (for example, a range set on the basis of higher layer parameters)).
It would have been obvious to one of ordinary skilled in the art before the effective filing date to create the invention of Yoshioka_413 to include the above recited limitations as taught by Yoshioka_678 in order to configure a plurality of PUCCH transmission opportunities for transmitting HARQ-ACKs in one slot (Yoshioka_678; [0049]).
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Yoshioka_413-Li as applied to claims 1 and 10 above, and further in view of Lee et al. (Lee hereafter) (US 20210409182 A1).
Regarding claims 4 and 13 Yoshioka_413-Li teaches, The claims 1 and 10,
Yoshioka_413-Li fails to explicitly teach, wherein the processing timeline allows extra processing time of potential multiplexing of HARQ-ACK codebooks with different priorities
However, in the same field of endeavor Lee teaches, wherein the processing timeline allows extra processing time of potential multiplexing of HARQ-ACK codebooks with different priorities (Lee; [0169] When the HARQ-ACK MUX RE is located so much before the HARQ-ACK PUCCH as to require a shorter processing time than the processing time supported by the UE capability, the UE could not derive valid HARQ-ACK information due to lack of a time for processing the HARQ-ACK. Therefore, it may be regulated that the UE does not expect occurrence of this HARQ-ACK (e.g., an HARQ-ACK with T_mux_i_j<T1) or that exceptionally, the UE piggybacks the HARQ-ACK to an earliest PUSCH requiring a processing time equal to or greater than the processing time supported by the UE capability among overlapped PUSCHs in the same cell (or PUSCHs overlapped irrespective of cell indexes). Alternatively, it may be regulated that the UE piggybacks only an HARQ-ACK requiring piggyback mapping with a processing time within the UE capability).
It would have been obvious to one of ordinary skilled in the art before the effective filing date to create the invention of Yoshioka_413-Li to include the above recited limitations as taught by Lee in order to transmit all of overlapped HARQ-ACKs (Lee; [0167]).
Conclusion
THIS ACTION IS MADE FINAL. 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 WILFRED THOMAS whose telephone number is (571)270-0353. The examiner can normally be reached Mon -Thurs 9:00 am-4: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, Noel R Beharry can be reached at 571-270-5630. 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.
/W. T/Examiner, Art Unit 2416
/NOEL R BEHARRY/Supervisory Patent Examiner, Art Unit 2416
Prosecution Insights