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 .
Finality
Applicant's request for reconsideration of the finality of the rejection of the last Office action is persuasive and, therefore, the finality of that action filed on 02/27/2026 is withdrawn.
In view of the Appeal Brief Filed on 07/02/2026, PROSECUTION IS HEREBY REOPENED. Details are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/DERRICK W FERRIS/
Claims 41-66 in the present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a non final action on the merits based on Applicant’s claims submitted on 04/21/2026.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/22/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Regarding claims 41, 51-53, 55, and 64-66 previously rejected under 35 U.S.C. § 102(a)(2), Applicant's arguments in Appeal Brief Filed, see “There is no suggestion, much less disclosure, in Rastegardoost of using the LCID value selection process itself as an implicit mechanism for a wireless device to provide the wireless network with an indication of the device's RedCap status.” on page 7, filed on 07/02/2026, with respect to Rastegardoost et al. US Pub 2022/0210806, claiming provisional 63132883 priority 2020-12-31 (hereinafter “Rastegardoost”), have been fully considered and are persuasive. Therefore, the previous rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Futaki et al. US Pub 2022/0287102 (hereinafter “Futaki”), in combination with previously applied reference Rastegardoost. See section Claim Rejections - 35 USC § 103 below for complete details.
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 of this title, 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.
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 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.
Claims 41, 51-53, 55, and 64-66 are rejected under 35 U.S.C. 103 as being unpatentable over Rastegardoost et al. US Pub 2022/0210806, claiming provisional 63132883 priority 2020-12-31 (hereinafter “Rastegardoost”), and in view of Futaki et al. US Pub 2022/0287102 (hereinafter “Futaki”).
Regarding claim 41
Rastegardoost discloses a method performed by a wireless device (i.e. “UE” in Fig. 13A) for performing random access (“see Fig. 13A), the method comprising:
the LCID or eLCID value is selected from outside the first plurality of values that are reserved values in a legacy Msg3 (“Identification of RedCap UEs may be done during Msg3 (PUSCH) transmission. The options may comprise using the spare bit in existing Msg3 definition; extending the Msg3 size to carry additional one or more bits, indicating RedCap UE type(s).” [0251]), or, to indicate that the wireless device is not a reduced capability device (“A mechanism for differentiating enhanced UE (supporting coverage recovery) and legacy UE may be needed. The mechanism may comprise separate PRACH configurations (e.g., separate PRACH occasions and/or preambles).” [0250]).
transmitting a Msg3 message (“The UE may transmit the Msg 3 1313 in response to a successful reception of the Msg 2 1312 (e.g., using resources identified in the Msg 2 1312)” [0175]) to a network node (i.e. “BS” in Fig. 13A) of a wireless network, for performing the random access towards the network node (“see Fig. 13A), wherein the Msg3 message includes a Medium Access Control Control Element (MAC CE) (“network may identify RedCap UEs based on receiving a Msg3 message by a wireless device. For example, a transport block, based on a new transport block size (TBS) value, may carry additional one or more bits indicating a UE type/category/capability and may be transmitted via the Msg3 PUSCH. For example, for RedCap UEs, additional TBS value(s) may be (pre-)defined/configured. For example, a non-RedCap UE may determine a first TBS value of one or more first TBS values. A RedCap UE may determine a second TBS value of one or more second TBS values. For example, the one or more first TBS values may be different from the one or more second TBS values. In an example, additional information may be included in the transport block, e.g., as an RRC message and/or a MAC-CE/MAC-subheader/MAC-subPDU.” [0279]) that includes the selected LCID or eLCID (“A MAC CE may be preceded by a MAC subheader with a similar format as described for MAC SDUs and may be identified with a reserved value in the LCID field that indicates the type of control information included in the MAC CE.” [0074]).
Rastegardoost does not specifically teach selecting a Logical Channel ID (LCID) or enhanced LCID (eLCID) value that indicates whether the wireless device is a reduced capability wireless device, wherein to indicate that the wireless device is a reduced capability wireless device.
In an analogous art, Futaki discloses selecting a Logical Channel ID (LCID) or enhanced LCID (eLCID) value that indicates whether the wireless device is a reduced capability wireless device (“the UE 2 may indicate a specific logical channel ID (LCID) associated with second type of UEs (e.g., reduced capability UEs) to the gNB 1 in transmitting the third message (Msg3) (e.g., RRC Setup Request) in a random access procedure (e.g., RRC Setup procedure).” [0118]), wherein to indicate that the wireless device is a reduced capability wireless device (“In the transmission of step 305 in FIG. 3, the UE 2 may indicate, to the gNB 1, a specific logical channel ID (LCID) associated with the second type of UEs (e.g., reduced capability UEs). Based on the reception of such specific LCID, the gNB 1 can identify (or detect) that the UE 2 is the second type of UE. Additionally or alternatively, in the transmission of step 307 in FIG. 3, the UE 2 may include, in the RRC Setup Complete message, an indication indicating that it is the second type of UE. Based on the reception of such indication, the gNB 1 can identify (or detect) that the UE 2 is the second type of UE.” [0073] and furthermore “In the transmission of step 605, the UE 2 indicates, to the gNB 1, a specific logical channel ID (LCID) associated with the second type of UEs (e.g., reduced capability UEs). The specific LCID may be, for example, a pre-defined LCID to be used for a Common Control CHannel (CCCH). Based on the reception of the specific LCID, the gNB 1 identifies (or detects) that the UE 2 is the second type of UE.” [0088]).
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Rastegardoost’s method for uplink data transmission for random access of reduced capability device, to include Futaki’s method for early identification of RedCap UEs, in order to effectively identify UE type (Futaki [0088]). Thus, a person of ordinary skill would have appreciated the ability to incorporate Futaki’s method for early identification of RedCap UEs into Rastegardoost’s method for uplink data transmission for random access of reduced capability device since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 51
Rastegardoost, as modified by Futaki, previously discloses the method of claim 41,
Rastegardoost further discloses wherein the Msg3 message indicates a User Equipment ID (UE ID) of the wireless device (“the UE may include a device identifier in the Msg 3 1313” [0175]).
Regarding claim 52
Rastegardoost, as modified by Futaki, previously discloses the method of claim 41,
Rastegardoost further discloses wherein the wireless device comprises a User Equipment (UE) (i.e. “UE” in Fig. 13A) and the network node comprises a base station (i.e. “BS” in Fig. 13A).
Regarding claim 53
Rastegardoost, as modified by Futaki, previously discloses the method of claim 41,
Rastegardoost further discloses wherein the indication included in the Msg3 message indicates whether the wireless device is a reduced capability wireless device (“Identification of RedCap UEs may be done during Msg3 (PUSCH) transmission. The options may comprise using the spare bit in existing Msg3 definition; extending the Msg3 size to carry additional one or more bits, indicating RedCap UE type(s).” [0251]) according to 3GPP Release 17 (“when RedCap is introduced in Rel-17” [0242]).
Regarding claim 55
Rastegardoost discloses a method performed by a network node (i.e. “BS” in Fig. 13A) of a wireless network for random access (see Fig. 13A), the method comprising:
receiving a Msg3 message (“The UE may transmit the Msg 3 1313 in response to a successful reception of the Msg 2 1312 (e.g., using resources identified in the Msg 2 1312)” [0175]) from a wireless device (i.e. “UE” in Fig. 13A) that is performing a random access (see Fig. 13A) towards the network node (i.e. “BS” in Fig. 13A), wherein the Msg3 message includes a Medium Access Control Control Element (MAC CE) (“network may identify RedCap UEs based on receiving a Msg3 message by a wireless device. For example, a transport block, based on a new transport block size (TBS) value, may carry additional one or more bits indicating a UE type/category/capability and may be transmitted via the Msg3 PUSCH. For example, for RedCap UEs, additional TBS value(s) may be (pre-)defined/configured. For example, a non-RedCap UE may determine a first TBS value of one or more first TBS values. A RedCap UE may determine a second TBS value of one or more second TBS values. For example, the one or more first TBS values may be different from the one or more second TBS values. In an example, additional information may be included in the transport block, e.g., as an RRC message and/or a MAC-CE/MAC-subheader/MAC-subPDU.” [0279]), and wherein the MAC CE includes a Logical Channel ID (LCID) or an enhanced LCID (eLCID) having a value selected by the wireless device (“A MAC CE may be preceded by a MAC subheader with a similar format as described for MAC SDUs and may be identified with a reserved value in the LCID field that indicates the type of control information included in the MAC CE.” [0074]); and
determining whether the selected LCID or eLCID value is or is not (“network may identify RedCap UEs based on receiving a Msg3 message by a wireless device. For example, a transport block, based on a new transport block size (TBS) value, may carry additional one or more bits indicating a UE type/category/capability and may be transmitted via the Msg3 PUSCH. For example, for RedCap UEs, additional TBS value(s) may be (pre-)defined/configured. For example, a non-RedCap UE may determine a first TBS value of one or more first TBS values. A RedCap UE may determine a second TBS value of one or more second TBS values. For example, the one or more first TBS values may be different from the one or more second TBS values. In an example, additional information may be included in the transport block, e.g., as an RRC message and/or a MAC-CE/MAC-subheader/MAC-subPDU.” [0279]) among a first plurality of values that are reserved values in a legacy Msg3 (“Identification of RedCap UEs may be done during Msg3 (PUSCH) transmission. The options may comprise using the spare bit in existing Msg3 definition; extending the Msg3 size to carry additional one or more bits, indicating RedCap UE type(s).” [0251]).
Rastegardoost does not specifically teach determining whether the wireless device is a reduced capability wireless device by determining the selected LCID or eLCID value.
In an analogous art, Futaki discloses determining whether the wireless device is a reduced capability wireless device by determining the selected LCID or eLCID value (“the UE 2 may indicate a specific logical channel ID (LCID) associated with second type of UEs (e.g., reduced capability UEs) to the gNB 1 in transmitting the third message (Msg3) (e.g., RRC Setup Request) in a random access procedure (e.g., RRC Setup procedure).” [0118]; “In the transmission of step 305 in FIG. 3, the UE 2 may indicate, to the gNB 1, a specific logical channel ID (LCID) associated with the second type of UEs (e.g., reduced capability UEs). Based on the reception of such specific LCID, the gNB 1 can identify (or detect) that the UE 2 is the second type of UE. Additionally or alternatively, in the transmission of step 307 in FIG. 3, the UE 2 may include, in the RRC Setup Complete message, an indication indicating that it is the second type of UE. Based on the reception of such indication, the gNB 1 can identify (or detect) that the UE 2 is the second type of UE.” [0073] and furthermore “In the transmission of step 605, the UE 2 indicates, to the gNB 1, a specific logical channel ID (LCID) associated with the second type of UEs (e.g., reduced capability UEs). The specific LCID may be, for example, a pre-defined LCID to be used for a Common Control CHannel (CCCH). Based on the reception of the specific LCID, the gNB 1 identifies (or detects) that the UE 2 is the second type of UE.” [0088]).
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Rastegardoost’s method for uplink data transmission for random access of reduced capability device, to include Futaki’s method for early identification of RedCap UEs, in order to effectively identify UE type (Futaki [0088]). Thus, a person of ordinary skill would have appreciated the ability to incorporate Futaki’s method for early identification of RedCap UEs into Rastegardoost’s method for uplink data transmission for random access of reduced capability device since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 64
The method of claim 55, wherein the Msg3 message indicates a User Equipment ID (UE ID) of the wireless device.
The scope and subject matter of method claim 64 are similar to the scope and subject matter as claimed in method claim 51. Therefore method claim 64 corresponds to method claim 51 and is rejected for the same reasons of obviousness as used in claim 51 rejection above.
Regarding claim 65
Rastegardoost discloses a wireless device (i.e. “wireless device 1502” in Fig. 15; [0202]) configured for communicating with a wireless network (see Fig. 1B), the wireless device comprising:
a processor (“processing system 1518” in Fig. 15; [02020]); and
a memory (“memory 1524” in Fig. 15; [0206]) associated with the processor and storing computer program instructions that,
when executed by the processor cause the wireless device to:
select a Logical Channel ID (LCID) or enhanced LCID (eLCID) value that indicates whether the wireless device is a reduced capability wireless device, wherein to indicate that the wireless device is a reduced capability wireless device, the LCID or eLCID value is selected from a first plurality of values that are reserved values in a legacy Msg3, or, to indicate that the wireless device is not a reduced capability device, the LCID or eLCID value is selected from outside the first plurality of values; and
transmit a Msg3 message to a network node of the wireless network, for performing random access towards the network node, wherein the Msg3 message includes a Medium Access Control Control Element (MAC CE) that includes the selected LCID or eLCID value.
The scope and subject matter of apparatus claim 65 is drawn to the apparatus of using the corresponding method claimed in claim 41. Therefore apparatus claim 65 corresponds to method claim 41 and is rejected for the same reasons of obviousness as used in claim 41 rejection above.
Regarding claim 66
Rastegardoost discloses a network node (i.e. “base station 1504” in Fig. 15; [0202]) configured for operation in a wireless network (see Fig. 1B), the network node comprising:
a processor (“processing system 1508” in Fig. 15; [0203]); and
memory (“memory 1514” in Fig. 15; [0206]) associated with the processor and storing computer program instructions that,
when executed by the processor, configure the network node to:
receive a Msg3 message from a wireless device performing a random access towards the network node, wherein the Msg3 message includes a Medium Access Control Control Element (MAC CE), and wherein the MAC CE includes a Logical Channel ID (LCID) or an enhanced LCID (eLCID) having a value selected by the wireless device; and
determine whether the wireless device is a reduced capability wireless device by determining whether the selected LCID or eLCID value is or is not among a first plurality of values that are reserved values in a legacy Msg3.
The scope and subject matter of apparatus claim 66 is drawn to the apparatus of using the corresponding method claimed in claim 55. Therefore apparatus claim 66 corresponds to method claim 55 and is rejected for the same reasons of obviousness as used in claim 55 rejection above.
Claim 54 is rejected under 35 U.S.C. 103 as being unpatentable over Rastegardoost, in view of Futaki, and further in view of Ericsson NPL “Identification and access control of RedCap UEs”, 3GPP R2-2009618, November 2nd – 13th 2020 (hereinafter “Ericsson”).
Regarding claim 54
Rastegardoost, as modified by Futaki, previously discloses the method of claim 41,
Rastegardoost does not specifically teach comprising receiving a further message from the network node, wherein the further message is based at least on the indication of whether the wireless device is a reduced capability wireless device, wherein the further message comprises a RRCSetup or RRCReject message that is based on the indication of whether the wireless device is a reduced capability wireless device.
In an analogous art, Ericsson discloses comprising receiving a further message from the network node (i.e. “gNB”), wherein the further message is based at least on the indication of whether the wireless device is a reduced capability wireless device (i.e. “RedCap UE”), wherein the further message comprises a RRCSetup (“the gNB will be aware of the UEs radio capabilities after the connection establishment procedure once RRCSetupComplete has been received” section 2.1) or RRCReject message that is based on the indication of whether the wireless device is a reduced capability wireless device (“Also, for the possibility for the network to reject an RRC request from a RedCap UE, we think an indication should be provided in Msg3” Observation 2, section 2.1).
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Rastegardoost’s method for uplink data transmission for random access of reduced capability device, as modified by Futaki, to include Ericsson’s method for early identification of RedCap UEs, in order to effectively identify UE type (Ericsson [2.1]). Thus, a person of ordinary skill would have appreciated the ability to incorporate Ericsson’s method for early identification of RedCap UEs into Rastegardoost’s method for uplink data transmission for random access of reduced capability device since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUONG M NGUYEN whose telephone number is (571)272-8184. The examiner can normally be reached M-F 10:00am - 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, Derrick Ferris can be reached at 571-272-3123. 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.
/CHUONG M NGUYEN/Primary Examiner, Art Unit 2411
Prosecution Insights