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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/29/2025 has been entered.
Response to Arguments
Applicant’s arguments, see Applicant’s Arguments and Remarks, filed 12/29/2025, with respect to the objection to claims 24-27 have been fully considered and are persuasive (Applicant’s Argument and Remarks, page 8). The previous ground of objection has been withdrawn.
The remainder of Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive.
Regarding claims 1, 20, 24 and 28, Applicant argues that LCID of Tan is not associated with specific capability parameters of the UE, especially the now claimed maximum transmission power, maximum data rate or maximum channel bandwidth (Applicant’s Argument and Remarks, pages 9-12). The Examiner disagrees, paragraph 0037-0039 of Tan disclose:
“The radio capability information may be radio capability information of the user equipment (UE), and may include information such as…a bandwidth…sent radio capability information may include the reduced capability NR UE information, and the UE may in particular be a reduced capability NR UE and have corresponding reduced capability NR UE information…In an implementation, a characteristic of the UE includes at least one of: a reduction of a number of UE RX/TX antennas, a reduction of a UE bandwidth” (see also 985, page 12)
Therefore, the capabilities associated with a reduced capability UE include a reduced maximum UE bandwidth with respect to the maximum bandwidth capabilities of a standard UE. Therefore, Applicant’s Arguments have been considered and are not persuasive.
Regarding the dependent claims, Applicant argues they are allowable for the same reasons at the independent claims (Id at 12). Therefore, the examiner disagrees for the same reasons.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 16-18, 20-22, 24-26 and 28-30 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Tan, et al. (US Pre Grant Publication No. 2023/0038753; note also CIPO Application No. 202010071985 “985”], with attached translation, all citations to translation) in view of Behravan, et al. (US Pre Grant Publication No. 2023/0354432) note also 62/958,990 (“990”), with parallel citations and
Regarding claims 16 and 24, Tan discloses a method performed by a user equipment (UE) in a wireless communications system, the method comprising and a user equipment (UE) in a wireless communication, the UE comprising a transceiver and at least one processor (paragraph 0199 – input/output apparatus is the transceiver; see also 985, page 37) coupled with the transceiver and configured to :
a. receiving/receive, from a base station (BS), system information (SI) including information indicating whether a reduced capability (RedCap) UE is supported on a cell; (The UE receives a SIB indicating a PRACH configuration for a RedCap UE [paragraph 0060, 0155-0156, note also 985, pages 15-17 and 29-30] [configuring am uplink PRACH resource for RedCap indicates support for it] based on the SIB, the UE will transmit a MSG1 to the gNB [paragraphs 0060-0063, 0155-0156, note also 985, pages 15-17 and 29-30].)
b. transmitting, to the BS, a random access (RA) preamble, based on preamble configuration information included in the SI (The SIB information the UE receives includes PRACH resource configuration information [paragraphs 0155, 0060, note also 985, pages 29-30 and 15-17] and the PRACH resource configuration information indicates a set of random access preambles corresponding to the RedCap UE [paragraph 0156, 0060, note also 985, pages 29-30 and 15-17]. The RedCap UE then transmits the MSG1 using the indicated PRACH preamble to the gNB/BS [paragraphs 0060-0063, 0156, note also 985, pages 15-17 and 29-30].)
c. in response to the RA preamble, receiving from the BS, a RA response (RAR) (Although not explicitly discussed with respect to fig. 7, it is understood that a message 2/response to the RA preamble is transmitted as a part of the random access process and triggers msg3 transmission [see, for example, paragraph 0069 – msg2/RA response triggers transmission of msg3 in random access process; note also 985, page 17].)
d. transmitting, to the BS, a message 3 (Msg3) associated with a logical channel identifier (LCID) wherein the LCID is used to report first RedCap UE capability information wherein the LCID is associated with a maximum channel bandwidth of the UE (In response to receiving the MSG2/response to the RA preamble transmitted from the base station based on the MSG1/preamble, the UE will transmit a MSG3 that may use a reserved LCID in the MAC CE header of the MSG3 to indicate the reduced capability NR UE [paragraph 0065-0068, 0158-0160; note also 985, pages 15-17 and 29-30]; paragraph 0069 – msg2/RA response triggers transmission of msg3 in random access process; note also 985, page 17. The Reserved LCID indicates the capability information of the UE including the maximum bandwidth capability/maximum channel bandwidth of the UE based on the reduction of the standard UE maximum bandwidth and is therefore associated with the maximum bandwidth of the UE. [it is noted that the BRI of the term “maximum channel bandwidth” is the maximum frequency bandwidth of the channel. This also appears to be consistent with applicant’s use of the term in Applicant’s specification [see paragraph 0060 of the PGPUB of the present application – “ To achieve e.g., 100 Mbps of transmission speed, the LTE system may use Orthogonal Frequency Division Multiplexing (OFDM) in e.g., 20 MHz of bandwidth”]] [paragraph 0037-0039- “The radio capability information may be radio capability information of the user equipment (UE), and may include information such as…a bandwidth…sent radio capability information may include the reduced capability NR UE information, and the UE may in particular be a reduced capability NR UE and have corresponding reduced capability NR UE information…In an implementation, a characteristic of the UE includes at least one of: a reduction of a number of UE RX/TX antennas, a reduction of a UE bandwidth”; see also 985, page 12).
Tan, in another embodiment, discloses the use of a message/Msg5/RRCSetup complete message (Another embodiment of Tan discloses that following a MSG4, a MESSAGE/MSG5/RRC connection complete message may be transmitted [paragraph 0048, see also 985, page 13 – “RRC MSG4 may be an RRC connection establishment, and the RRC MESSAGE/MSG5 message does not carry any actual message and only functions as an RRC layer confirmation, the RRC MESSAGE/MSG5 may be an RRC connection establishment completion”].)
Tan fails to disclose a RA response including resource information or, based on a msg4 received in response to the msg3, transmitting, to the BS, a message/Msg5 including a second RedCap UE capability information. In the same field of endeavor, Behravan discloses a RA response including resource information and based on a msg4 received in response to the msg3, transmitting, to the BS, a message/Msg5 including a second RedCap UE capability information (The system of Behravan discloses that message 2/RA response includes uplink resources for scheduling msg3 based on the UE capabilities indicated in message 1/RA request [paragraphs 0048-0051; see also 990, paged 2, lines 3-23]. Behravan further discloses that the UE may place capability information in both the message 1/RA request and in message 5 [paragraph 0060 – “The UE capability reporting methods include at least: (a) reporting using a different set of preambles; (b) capability or UE ID reporting in message 3 or Message 5; and/or (c) reporting using both methods (a) and (b).”]; see also 990, page 6, lines 4-8.)
Therefore, since Behravan discloses msg2/a random access response including uplink resource information determined based on a msg1/random access request and inclusion of UE capability information in both msg1/random access request and message/Msg5, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the capability inclusion of Behravan with the system of Tan by including uplink resource information in the msg2/RA response determined based on capability information/preamble configuration information of the UE included in msg1/RA request and to further include additional UE capability information in a message/Msg5/RRC Setup compete transmitted in response to msg4 received at the UE. The motive to combine is to allow capability information necessary to the scheduling/uplink resource information included in msg2 to be included in the msg1/RA request and to further allow additional capability information in message/Msg5, so as to allow the UE to keep a small message size in msg1/RA by only including immediately necessary capability information in msg 1 and to then allow further capability information to be included in message/Msg5, to allow for reduced spectrum utilization in the frequently transmitted msg1 to improve efficiency.
Regarding claims 17 and 25, Tan discloses when the Msg3 is an RRCSetupRequest message, a size of the RRCSetupRequest message associated with the LCID is One of M bits, and wherein when the Msg3 is an RRCResumeRequest message, a size of the RRCResumeRequest message associated with the LCID is One of M bits or N bits. (Tan discloses the MSG3 may be a RRCSetupRequest or RRCResumeRequest [paragraph 0065-0068, 0158-0160; note also 985, pages 15-17 and 29-30]. Note that any resume/request messages would meet the stated length requirements as M can be arbitrarily made to the size of the RRCSetupRequest and the RRC Resume request could be the same size M or a different size N.)
Regarding claims 18 and 26, the first embodiment of Tan fails to disclose receiving, from the BS, a UE capability enquiry message and transmitting, to the BS, a UE capability information message including third RedCap UE capability information. In the same field of endeavor, another embodiment of Tan discloses receiving a UE capability enquiry message from the BS and transmitting, to the BS, a UE third capability information message including RedCap UE capability information. (Another embodiment of Tan discloses that in the case of a TAU, the eNB/gNB may be required to actively enquire of the UE regarding its capabilities by sending a capability enquiry message and the UE will then respond with capability information indicating the RedCap UEs capabilities (paragraph 0053).
Therefore, since the second embodiment of Tan discloses a further technique for updating UE capability information when necessary, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the capability updates of the second embodiment with the first embodiment of Tan by transmitting a capability enquire message to the UE when the capabilities of the UE need to be updated, such as when a TAU update occurs and having the UE respond in third RedCap UE capability message. The motive to combine is to improve operation by allowing the UE capabilities to be updated in response to events that may require updated UE capabilities to allow the network to be updated with appropriate UE capabilities.
Regarding claims 20 and 28, Tan discloses a method performed by a base station (BS) in a wireless communications system, the method comprising and a base station (BS) in a wireless communication system comprising a transceiver and at least one processor (paragraph 0199 – input/output apparatus is the transceiver; see also 985, page 37) coupled with the transceiver and configured to:
a. transmitting, to a user equipment (UE), system information (SI) including information indicating whether a reduced capability (RedCap) UE is supported on a cell (The UE receives and base station transmits a SIB indicating a PRACH configuration for a RedCap UE [paragraph 0060, 0155-0156, note also 985, pages 15-17 and 29-30] [configuring am uplink PRACH resource for RedCap indicates support for it] based on the SIB, the UE will transmit a MSG1 to the gNB [paragraphs 0060-0063, 0155-0156, note also 985, pages 15-17 and 29-30].)
b. receiving, from the UE, a random access (RA) preamble based on a preamble configuration information included in the SI (The SIB information the UE receives/base station trasmits includes PRACH resource configuration information [paragraphs 0155, 0060, note also 985, pages 29-30 and 15-17] and the PRACH resource configuration information indicates a set of random access preambles corresponding to the RedCap UE [paragraph 0156, 0060, note also 985, pages 29-30 and 15-17]. The RedCap UE then transmits the MSG1 using the indicated PRACH preamble to the gNB/BS [paragraphs 0060-0063, 0156, note also 985, pages 15-17 and 29-30].)
c. in response to the RA preamble, transmitting, to the UE, a RA response including uplink resource information (Although not explicitly discussed with respect to fig. 7, it is understood that a message 2/response to the RA preamble is transmitted as a part of the random access process and triggers msg3 transmission [see, for example, paragraph 0069 – msg2/RA response triggers transmission of msg3 in random access process; note also 985, page 17].)
d. receiving, form the UE, a message3 (Msg3) associated with a logical channel identifier (LCID), wherein the LCID is used to report a first RedCap UE capability information wherein the LCID is associated with a maximum channel bandwidth of the UE (In response to receiving the MSG2/response to the RA preamble transmitted from the base station based on the MSG1/preamble, the UE will transmit, and a base station receive, a MSG3 that may use a reserved LCID in the MAC CE header of the MSG3 to indicate the reduced capability NR UE [paragraph 0065-0068, 0158-0160; note also 985, pages 15-17 and 29-30]; paragraph 0069 – msg2/RA response triggers transmission of msg3 in random access process; note also 985, page 17. The Reserved LCID indicates the capability information of the UE including the maximum bandwidth capability/maximum channel bandwidth of the UE based on the reduction of the standard UE maximum bandwidth and is therefore associated with the maximum bandwidth of the UE. [it is noted that the BRI of the term “maximum channel bandwidth” is the maximum frequency bandwidth of the channel. This also appears to be consistent with applicant’s use of the term in Applicant’s specification [see paragraph 0060 of the PGPUB of the present application – “ To achieve e.g., 100 Mbps of transmission speed, the LTE system may use Orthogonal Frequency Division Multiplexing (OFDM) in e.g., 20 MHz of bandwidth”]] [paragraph 0037-0039- “The radio capability information may be radio capability information of the user equipment (UE), and may include information such as…a bandwidth…sent radio capability information may include the reduced capability NR UE information, and the UE may in particular be a reduced capability NR UE and have corresponding reduced capability NR UE information…In an implementation, a characteristic of the UE includes at least one of: a reduction of a number of UE RX/TX antennas, a reduction of a UE bandwidth”; see also 985, page 12)
Tan, in another embodiment, discloses the use of a message/Msg5/RRCSetup complete message (Another embodiment of Tan discloses that following a MSG4, a MESSAGE/MSG5/RRC connection complete message may be transmitted [paragraph 0048, see also 985, page 13 – “RRC MSG4 may be an RRC connection establishment, and the RRC MESSAGE/MSG5 message does not carry any actual message and only functions as an RRC layer confirmation, the RRC MESSAGE/MSG5 may be an RRC connection establishment completion”].)
Tan fails to disclose a RA response including uplink resource information or based on a msg4 transmitted in response to the msg2, receiving, from the UE, a message including second RedCap UE Capability Information. In the same field of endeavor, Behravan discloses a a RA response including uplink resource information or based on a msg4 transmitted in response to the msg2, receiving, from the UE, a message including second RedCap UE Capability Information (The system of Behravan discloses that message 2/RA response includes uplink resources for scheduling msg3 based on the UE capabilities indicated in message 1/RA request [paragraphs 0048-0051; see also 990, paged 2, lines 3-23]. Behravan further discloses that the UE may place capability information in both the message 1/RA request and in message 5 [paragraph 0060 – “The UE capability reporting methods include at least: (a) reporting using a different set of preambles; (b) capability or UE ID reporting in message 3 or Message 5; and/or (c) reporting using both methods (a) and (b).”]; see also 990, page 6, lines 4-8.)
Therefore, since Behravan discloses msg2/a random access response including uplink resource information determined based on a msg1/random access request and inclusion of UE capability information in both msg1/random access request and message/Msg5, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the capability inclusion of Behravan with the system of Tan by including uplink resource information in the msg2/RA response determined based on capability information/preamble configuration information of the UE included in msg1/RA request and to further include additional UE capability information in a message/Msg5/RRC Setup compete received at the base station in response to msg4 transmitted by the base station. The motive to combine is to allow capability information necessary to the scheduling/uplink resource information included in msg2 to be included in the msg1/RA request and to further allow additional capability information in message/Msg5, so as to allow the UE to keep a small message size in msg1/RA by only including immediately necessary capability information in msg 1 and to then allow further capability information to be included in message/Msg5, to allow for reduced spectrum utilization in the frequently transmitted msg1 to improve efficiency.
Regarding claims 21 and 29, Tan discloses when the Msg3 is an RRCSetupRequest message, a size of the RRCSetupRequest message associated with the LCID is One of M bits, and wherein when the Msg3 is an RRCResumeRequest message, a size of the RRCResumeRequest message associated with the LCID is One of M bits or N bits. (Tan discloses the MSG3 may be a RRCSetupRequest or RRCResumeRequest [paragraph 0065-0068, 0158-0160; note also 985, pages 15-17 and 29-30]. Note that any resume/request messages would meet the stated length requirements as M can be arbitrarily made to the size of the RRCSetupRequest and the RRC Resume request could be the same size M or a different size N.)
Regarding claims 22 and 30, the first embodiment of Tan fails to disclose transmitting, to the UE, a UE capability enquiry message to the GE and receiving, from the UE, a UE capability information message including third RedCap UE capability information. In the same field of endeavor, another embodiment of Tan discloses r transmitting, to the UE, a UE capability enquiry message to the GE and receiving, from the UE, a UE capability information message including third RedCap UE capability information. (Another embodiment of Tan discloses that in the case of a TAU, the eNB/gNB may be required to actively enquire of the UE regarding its capabilities by sending a capability enquiry message and the UE will then respond with capability information indicating the RedCap UEs capabilities (paragraph 0053).
Therefore, since the second embodiment of Tan discloses a further technique for updating UE capability information when necessary, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to combine the capability updates of the second embodiment with the first embodiment of Tan by transmitting a capability enquire message to the UE when the capabilities of the UE need to be updated, such as when a TAU update occurs and having the UE respond with the capabilities of the RedCap UE. The motive to combine is to improve operation by allowing the UE capabilities to be updated in response to events that may require updated UE capabilities to allow the network to be updated with appropriate UE capabilities.
Claim(s) 19, 23, 27 and 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tan, et al. (US Pre Grant Publication No. 2023/0038753; note also CIPO Application No. 202010071985 “985”], with attached translation, all citations to translation) as modified by Behravan, et al. (US Pre Grant Publication No. 2023/0354432) note also 62/958,990 (“990”), with parallel citations as applied to claims 16, 20, 24, and 28 and further in view of Liu, et al. (US Pre Grant Publication No. 2021/0258768 A1).
Regarding claims 19 and 27, Tan as modified by Behravan discloses the transmission of a message/Msg5/RRCSetupComplete message (see the combination with Behravan in claims 16 and 24, supra).
Tan as modified by Behravan fails to disclose the message/Msg5 comprises a non-access stratum container including a registration request message to a core network. In the same field of endeavor Liu discloses the message/Msg5 comprises a non-access stratum container including a registration request message to a core network (Liu discloses that as a part of the RRC setup complete message a NAS message may encapsulate a registration request for a core network device when the UE indicates if it wishes to support a capability [i.e. when a terminal is acting in a reduced capacity for power savings, for example] [paragraphs 0145-0151, in particular 0150-0151].)
Therefore, since Liu suggests RRC setup complete message encapsulating a core network message, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to include the NAS encapsulated capability identifiers of Liu in the RRCSetupComplete/MESSAGE/MSG5 of Tan as modified by Behravan, which is passed on to the core network. The motive to combine is to allow the UE to repot capabilities to the core network to allow the core network to be aware of the UE capabilities so the network can be configured properly relative to the capabilities of the UE to allow for best operation of the core network.
Regarding claims 23 and 31, Tan as modified by Behravan discloses the transmission of a message/Msg5/RRCSetupComplete message (see the combination with Behravan in claims 16 and 24, supra).
Tan as modified by Behravan fails to disclose the message/Msg5 comprises a non-access stratum container including a registration request message to a core network. In the same field of endeavor Liu discloses the message/Msg5 comprises a non-access stratum container including a registration request message to a core network (Liu discloses that as a part of the RRC setup complete message a NAS message may encapsulate a registration request for a core network device when the UE indicates if it wishes to support a capability [i.e. when a terminal is acting in a reduced capacity for power savings, for example] [paragraphs 0145-0151, in particular 0150-0151].)
Therefore, since Liu suggests RRC setup complete message encapsulating a core network message, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to include the NAS encapsulated capability identifiers of Liu in the RRCSetupComplete/MESSAGE/MSG5 of Tan as modified by Behravan, which is passed on to the core network. The motive to combine is to allow the UE to repot capabilities to the core network to allow the core network to be aware of the UE capabilities so the network can be configured properly relative to the capabilities of the UE to allow for best operation of the core network.
Conclusion
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 CHRISTOPHER M CRUTCHFIELD whose telephone number is (571)270-3989. The examiner can normally be reached 9am-5pm M-F.
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, Faruk Hamza can be reached on (571) 272-7969. 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.
/CHRISTOPHER M CRUTCHFIELD/Primary Examiner, Art Unit 2466