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 .
This office action is in response to Applicant’s preliminary amendment filed on 2/1/2024.
Claims 15-34 are currently pending.
Claim Rejections - 35 USC § 102
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 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 15-34 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Takeda et al. (US 2022/0322292 A1; hereafter TAKEDA).
With respect to claim 15, TAKEDA discloses a user equipment (UE) (802, UE in FIG. 8; 902, UE in FIG. 9) for wireless communication, comprising:
at least one memory (376 in FIG. 3); and
at least one processor (370 in FIG. 3) coupled with the at least one memory and configured to cause the UE to:
receive configuration information of a physical uplink control channel (PUCCH) resource pool for a group of UEs receiving a multicast transmission, wherein the group of UEs comprises the UE (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15);
receive a hybrid automatic repeat request acknowledgement (HARQ-ACK) feedback mode indication, wherein the HARQ-ACK feedback mode indication indicates a HARQ-ACK feedback mode for the multicast transmission from a plurality of HARQ-ACK feedback modes (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15); and
determine, based at least in part on the indicated HARQ-ACK feedback mode, a PUCCH resource from the PUCCH resource pool for transmitting HARQ-ACK feedback for the multicast transmission (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 16, TAKEDA further discloses the UE of claim 15, wherein the at least one processor is configured to cause the UE to determine the indicated HARQ-ACK feedback mode based on at least one of:
a quality of service (QOS) of the multicast transmission (paragraph [0057]), a number of UEs in the group of UEs, or a number of PUCCH resources in the PUCCH resource pool (500 in FIG. 5; 600 in FIG. 6; paragraph [0087] and [0088]).
With respect to claim 17, TAKEDA further discloses the UE of claim 15, wherein the HARQ-ACK feedback mode indication is carried in a downlink control information (DCI) format, which schedules the multicast transmission with cyclic redundancy check (CRC) bits scrambled by a radio network temporary identifier (RNTI) common to the group of UEs (paragraphs [0084] and [0094]).
With respect to claim 18, TAKEDA further discloses the UE of claim 15, wherein each PUCCH resource in the PUCCH resource pool carries one bit of acknowledgement (ACK) or negative ACK (NACK) (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 19, TAKEDA further discloses the UE of claim 15, wherein the plurality of HARQ-ACK feedback modes comprises at least one of:
a first HARQ-ACK feedback mode indicating group negative acknowledgement (NACK)-only feedback (paragraph [0043]); a second HARQ-ACK feedback mode indicating UE-specific NACK-only feedback; a third HARQ-ACK feedback mode indicating UE-specific ACK/NACK feedback; and a fourth HARQ-ACK feedback mode indicating no HARQ-ACK feedback (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 20, TAKEDA further discloses the UE of claim 19, wherein to determine the PUCCH resource from the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission, the at least one processor is configured to cause the UE to:
determine a predefined PUCCH resource in the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission in response to the indicated HARQ-ACK feedback mode being the first HARQ-ACK feedback mode (paragraph [0043]);
determine a UE-specific PUCCH resource in the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission based on a member ID of the UE in response to the indicated HARQ-ACK feedback mode being the second HARQ-ACK feedback mode; determine a UE-specific PUCCH resource pair in the PUCCH resource pool for transmitting the HARQ-ACK feedback (paragraph [0043]) for the multicast transmission based on the member ID of the UE in response to the indicated HARQ-ACK feedback mode being the third HARQ-ACK feedback mode; and determine not to transmit the HARQ-ACK feedback for the multicast transmission in response to the indicated HARQ-ACK feedback mode being the fourth HARQ-ACK feedback mode (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 21, TAKEDA further discloses the UE of claim 20, wherein to determine the UE-specific PUCCH resource pair based on the member ID of the UE, the at least one processor is configured to cause the UE to one or more of: pair each two consecutive PUCCH resources in the PUCCH resource pool as a PUCCH resource pair to determine a plurality of PUCCH resource pairs (500 in FIG. 5; 600 in FIG. 6; paragraph [0087] and [0088]), and
select the UE-specific PUCCH resource pair from the plurality of PUCCH resource pairs based on the member ID of the UE; or divide PUCCH resources in the PUCCH resource pool into two sub-pools, and select a PUCCH resource from each of the two sub-pools based on the member ID of the UE as the UE-specific PUCCH resource pair (500 in FIG. 5; 600 in FIG. 6; paragraph [0087] and [0088]).
With respect to claim 22, TAKEDA discloses a user equipment (UE) (802, UE in FIG. 8; 902, UE in FIG. 9) for wireless communication, comprising:
at least one memory (376 in FIG. 3); and
at least one processor (370 in FIG. 3) coupled with the at least one memory and configured to cause the UE to:
receive configuration information of a UE-specific physical uplink control channel (PUCCH) resource set, wherein the UE-specific PUCCH resource set is from a plurality of PUCCH resource sets which are configured for a group of UEs receiving a multicast transmission, and wherein the group of UEs comprises the UE (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15);
receive a PUCCH resource indication, wherein the PUCCH resource indication indicates a PUCCH resource from the UE-specific PUCCH resource set (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15); and
determine, based at least in part on the PUCCH resource indication, a PUCCH resource from the UE-specific PUCCH resource set for transmitting hybrid automatic repeat request acknowledgement (HARQ-ACK) feedback for the multicast transmission (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 23, TAKEDA further discloses the UE of claim 22, wherein the PUCCH resource indication is carried in one of:
a downlink control information (DCI) format which schedules the multicast transmission with cyclic redundancy check (CRC) bits scrambled by a radio network temporary identifier (RNTI) common to the group of UEs (paragraphs [0084] and [0094]);
a radio resource control (RRC) signaling message; a medium access control (MAC) control element (CE); or a DCI format with CRC bits scrambled by an RNTI specific to the UE (paragraphs [0084] and [0094]).
With respect to claim 24, TAKEDA further discloses the UE of claim 22, wherein the at least one processor is configured to cause the UE to determine the PUCCH resource indication based on at least one of:
a quality of service (QOS) of the multicast transmission (paragraph [0057]), a number of UEs in the group of UEs, or a number of PUCCH resources available for the multicast transmission (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 25, TAKEDA further discloses the UE of claim 22, wherein each PUCCH resource in the UE-specific PUCCH resource set carries one bit of acknowledgement (ACK) or negative ACK (NACK) (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 26, TAKEDA further discloses the UE of claim 22, wherein each PUCCH resource set of the plurality of PUCCH resource sets includes at least one of:
a PUCCH resource for group negative acknowledgement (NACK)-only feedback (paragraph [0043]); a PUCCH resource for UE-specific NACK-only feedback; a PUCCH resource pair for UE-specific ACK/NACK feedback; and an indicator for disabling HARQ-ACK feedback for the multicast transmission (paragraph [0043]).
With respect to claim 27, TAKEDA further discloses the UE of claim 22, wherein the at least one processor is configured to cause the UE to determine the plurality of PUCCH resource sets by, among PUCCH resources available for the multicast transmission, maximizing PUCCH resource pairs for UE-specific ACK/NACK feedback, and maximizing PUCCH resources for UE-specific NACK-only feedback (paragraph [0043]).
With respect to claim 28, TAKEDA discloses a processor (370 in FIG. 3) for wireless communication (802, UE in FIG. 8; 902, UE in FIG. 9), comprising:
at least one controller (375 in FIG. 3) coupled with at least one memory (376 in FIG. 3) and configured to cause the processor to:
receive configuration information of a physical uplink control channel (PUCCH) resource pool for a group of user equipment (UEs) receiving a multicast transmission (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15), wherein the group of UEs comprises a UE;
receive a hybrid automatic repeat request acknowledgement (HARQ-ACK) feedback mode indication, wherein the HARQ-ACK feedback mode indication indicates a HARQ-ACK feedback mode for the multicast transmission from a plurality of HARQ-ACK feedback modes (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15); and
determine, based at least in part on the indicated HARQ-ACK feedback mode, a PUCCH resource from the PUCCH resource pool for transmitting HARQ-ACK feedback for the multicast transmission (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 29, TAKEDA further discloses the processor of claim 28, wherein the at least one controller is configured to cause the processor to determine the indicated HARQ-ACK feedback mode based on at least one of:
a quality of service (QOS) of the multicast transmission (paragraph [0057]), a number of UEs in the group of UEs, or a number of PUCCH resources in the PUCCH resource pool (500 in FIG. 5; 600 in FIG. 6; paragraph [0084] and [0094]).
With respect to claim 30, TAKEDA further discloses the processor of claim 28, wherein the HARQ-ACK feedback mode indication is carried in a downlink control information (DCI) format, which schedules the multicast transmission with cyclic redundancy check (CRC) bits scrambled by a radio network temporary identifier (RNTI) common to the group of UEs (paragraphs [0084] and [0094]).
With respect to claim 31, TAKEDA further discloses the processor of claim 28, wherein each PUCCH resource in the PUCCH resource pool carries one bit of acknowledgement (ACK) or negative ACK (NACK) (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15).
With respect to claim 32, TAKEDA further discloses the processor of claim 28, wherein the plurality of HARQ-ACK feedback modes comprises at least one of:
a first HARQ-ACK feedback mode indicating group negative acknowledgement (NACK)-only feedback (paragraph [0043]);
a second HARQ-ACK feedback mode indicating UE-specific NACK-only feedback; a third HARQ-ACK feedback mode indicating UE-specific ACK/NACK feedback; and a fourth HARQ-ACK feedback mode indicating no HARQ-ACK feedback (paragraph [0043]).
With respect to claim 33, TAKEDA further discloses the processor of claim 32, wherein to determine the PUCCH resource from the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission, the at least one controller is configured to cause the processor to:
determine a predefined PUCCH resource in the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission in response to the indicated HARQ-ACK feedback mode being the first HARQ-ACK feedback mode; determine a UE-specific PUCCH resource in the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission based on a member ID of the UE in response to the indicated HARQ-ACK feedback mode being the second HARQ-ACK feedback mode (806, 808, 810 in FIG. 8; 906, 908, 910 in FIG. 9; 1502, 1510, 1520 in FIG. 15);
determine a UE-specific PUCCH resource pair in the PUCCH resource pool for transmitting the HARQ-ACK feedback for the multicast transmission based on the member ID of the UE in response to the indicated HARQ-ACK feedback mode being the third HARQ-ACK feedback mode; and determine not to transmit the HARQ-ACK feedback for the multicast transmission in response to the indicated HARQ-ACK feedback mode being the fourth HARQ-ACK feedback mode (paragraph [0043]).
With respect to claim 34, TAKEDA further discloses the UE of claim 33, wherein to determine the UE-specific PUCCH resource pair based on the member ID of the UE, the at least one controller is configured to cause the processor to one or more of: pair each two consecutive PUCCH resources in the PUCCH resource pool as a PUCCH resource pair to determine a plurality of PUCCH resource pairs, and select the UE-specific PUCCH resource pair from the plurality of PUCCH resource pairs based on the member ID of the UE (500 in FIG. 5; 600 in FIG. 6; paragraph [0087] and [0088]); or
divide PUCCH resources in the PUCCH resource pool into two sub-pools, and select a PUCCH resource from each of the two sub-pools based on the member ID of the UE as the UE-specific PUCCH resource pair (500 in FIG. 5; 600 in FIG. 6; paragraph [0087] and [0088]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian T O'Connor whose telephone number is (571)270-1081. The examiner can normally be reached Mon-Fri Flex 10am-6:30pm.
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, Gary Mui can be reached at 571-270-1420. 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.
/BRIAN T O CONNOR/Primary Examiner, Art Unit 2465 January 6, 2026