Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
a. 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 :
- claims 41, 51, 53-55, and 64-66 are amended
- claims 42-50 and 56-63 are cancelled
b. This is a final action on the merits based on Applicant’s claims submitted on 12/10/2025.
Response to Arguments
Regarding Independent claims previously rejected under 35 U.S.C. § 103, Applicant's arguments, see “With respect to independent claim 41, it now incorporates subject matter from prior claims 45, 47, and 48. Similar incorporations appear in the counterpart independent claim 65… Such subject matter is not disclosed in Rastegardoost, nor does Rastegardoost combine with any of the further cited references in a manner that would render claims 41 and 65 legally obvious. In particular, the Office rejected prior claims 47 and 48 as being legally obvious over Rastegardoost in view of Shrestha (US 2022/0078872 A1).” on pages 6-7, filed on 12/10/2025, 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 not persuasive.
Rastegardoost clearly discloses selecting a Logical Channel ID (LCID) or enhanced LCID (eLCID) value that indicates whether the wireless device is a reduced capability 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]), wherein to indicate that the wireless device is a reduced capability wireless device (“Functionalities may be studied that will allow devices with reduced capabilities (RedCap UEs) to be explicitly identifiable to networks and network operators and allow operators to restrict their access if desired.” [0238]).
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]).
Claim Rejections - 35 USC § 102
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 41, 51-53, 55, and 64-66 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Rastegardoost et al. US Pub 2022/0210806, claiming provisional 63132883 priority 2020-12-31 (hereinafter “Rastegardoost”).
Regarding claim 41 (Currently Amended)
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:
selecting a Logical Channel ID (LCID) or enhanced LCID (eLCID) value that indicates whether the wireless device is a reduced capability 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]), wherein to indicate that the wireless device is a reduced capability wireless device (“Functionalities may be studied that will allow devices with reduced capabilities (RedCap UEs) to be explicitly identifiable to networks and network operators and allow operators to restrict their access if desired.” [0238]).
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]).
Regarding claim 51 (Currently Amended)
Rastegardoost 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 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 (Currently Amended)
Rastegardoost 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 (Currently Amended)
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 wireless device is a reduced capability wireless device (“Functionalities may be studied that will allow devices with reduced capabilities (RedCap UEs) to be explicitly identifiable to networks and network operators and allow operators to restrict their access if desired.” [0238]) by 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]).
Regarding claim 64 (Currently Amended)
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 anticipation as used in claim 51 rejection above.
Regarding claim 65 (Currently Amended)
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 anticipation as used in claim 41 rejection above.
Regarding claim 66 (Currently Amended)
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 anticipation as used in claim 55 rejection above.
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.
Claim 54 is rejected under 35 U.S.C. 103 as being unpatentable over Rastegardoost, and 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 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, 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
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 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