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 .
Response to Amendment
The amendment to the claims filed on 12/31/2025 complies with the requirements of 37 CFR 1.121(c) and has been entered.
Response to Arguments
Applicant's Arguments/Remarks filed 12/31/2025 (hereinafter Resp.) are fully considered hereinafter.
Applicant’s argument against the configuredGrantTimer disclosed in Babaei et al., U.S. Patent Application No. 2022/0070928 (hereinafter Babaei1) as anticipating the second timer required by the claimed invention is that “the configuredGrantTimer has already been started while the terminal is in the RRC connected state. When the terminal subsequently receives an RRC Release command from the network and enters the RRC inactive state, the configuredGrantTimer has already been running for a period of time” – See Resp., §I, 11:¶2. Examiner respectfully disagrees with Applicant’s explanation of how the configuredGrantTimer parameter received by the UE in an UL configured grant Type 1 while the UE is in RRC_CONNECTED state with the network work. Specifically, § 5.4.2, 3GPP TS 38.321 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16)” (hereinafter 3GPP TS 38.321) teaches that the configuredGrantTimer is intimately related to HARQ processes in that for each HASRQ process associated with an uplink transmission, the timer is started when the transmission is performed, not when the UE is configured with the UL configured grant – See 3GPP TS 38.321:43 (stating: “4>instruct the identified HARQ process to trigger a new transmission; 4>if the uplink grant is a configured uplink grant: 5>start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed;” (emphasis added)). A person of ordinary skills in the art would reasonably consider a case where the UE is configured through ConfiguredGrantConfig RRC IE while in RRC_CONNECT and transition to RRC_INACTIVE before a PDU is delivered to the HARQ Entity at the MAC layer. Then, based on other teachings in the art further cited in the present Office Action, the UE may send, while in RRC_INACTIVE, data on a configured PUSCH resource covered by the ConfiguredGrantConfig with HARQ process enabled therefore starting the configuredGrantTimer.
In addition, Applicant claims that “the second timer is started during the process in which the terminal switches from the RRC connected state to the RRC inactive state. In this way, the starting moment of the second timer is associated with the RRC state transition” without pointing to a specific paragraph of the Specification in support. To be sure, there is no paragraph in the Specification minimally alleging that the second timer would be associated with “the RRC state transition” – See [¶0059] (“the second timer starts to time at the time that the terminal is in the radio resource control (RRC) connected state, and continues to time up until timing times out after the terminal switches to the radio resource control (RRC) inactive state”); [¶0060](“the second timer starts to time after the terminal switches to the radio resource control (RRC) inactive state”). Applicant’s explanation of the independent claims limitation “wherein the second timer is started during a process that the terminal switches from a radio resource control (RRC) connected state to an RRC inactive state” meaning that “the starting moment of the second timer is associated with the RRC state transition,” now clearly rejects the interpretation given to the claim language in previous Office actions. There, the language “started during a process that the terminal switches from a radio resource control (RRC) connected state” was narrowly interpreted as the second timer being started “right before” the terminal switches from a radio resource control (RRC) connected state, i.e., the UE is still in the RRC state, and continuing into the RRC_INACTIVE in order to avoid a § 112(a) rejection.
For these reasons, Applicant’s argument against Babaei1’s disclosure of a second timer is not persuasive.
Regarding Babaei1, Applicant also argues that “the transport block size in Babaei is affected by variable configuration parameters and does not involve a fixed set threshold” – See Resp., 16:¶3. While it is true that a TB size is configured to the UE, so is any threshold for small data, possibly through the same mechanism known in the art, e.g., a cell specific SIB or dedicated RRC(Re)configuration message, hence the distinction is not very clear. In addition, Babaei1 also discloses a message size threshold to distinguish between small data and larger data sent uplink in a Msg3, whereby that threshold is fixed to allow the UE to choose between preamble group A and group B – See [¶¶0283-84]. Therefore, this argument is also non-persuasive.
In response to applicant's arguments against the reference Höglund et al., U.S. Patent Application Publication 2022/0007391 (hereinafter Höglund) taken individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). However, even taken individually, Höglund teaches, at least in part, the amended limitations because Höglund teaches “a mechanism that can be used to determine the validity of such a TA at the moment an IDLE mode transmission on pre-configured UL resources is intended to be performed” – See [¶0344], including “a Time Alignment Timer for idle mode” – See [¶0356] when “receiving user data using non-recurring preconfigured resources during an idle mode or an inactive mode based on a timing advance transmitted the last time the wireless device was in a connected mode or transmitted during the idle mode” – See [¶0212], i.e., the validity timer may be started during the RRC_CONNECTED mode or may be started in RRC_INACTIVE mode, with “UEs in RRC_IDLE (or INACTIVE state) to one PUR transmission occasion” – See [¶0062]. In addition, the argument against Höglund is also moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In sum, Applicant’s arguments have been fully considered but they are either unpersuasive or moot.
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, 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.
Claims 1, 3-9, 19-22, and 24-29, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Babaei et al., U.S. Patent Application No. 2022/0070928 (hereinafter Babaei1) and further in view of Chin et al., U.S. Patent Application Publication No. 2023/0141487 (hereinafter Chin).
Regarding Amended Claim 1, Babaei1 teaches a method for sending data, performed by a terminal (“gNB may transmit to or receive from, a wireless device, data packets scheduled on one or more RBGs and one or more slots” – See [¶0244] with “a selected plurality of wireless devices, and/or a subset of total wireless devices in a coverage area which perform according to disclosed methods” – See [¶0543]), the method comprising:
determining an uplink synchronization state of the terminal (e.g., the UE determines “DL or UL data arrival during RRC_CONNECTED when UL synchronization status is non-synchronized, transition from RRC_Inactive, and/or request for other system information” and “trigger[s] a random access procedure” for UL synchronization – See [¶0281]) and
a state of an unlicensed physical uplink shared channel (PUSCH) resource pre-configured by a base station for the terminal (“with scheduled PUSCH transmissions on an unlicensed carrier,” – See [¶0330] “[p]re-configured grant such as configured grant in NR may be used for NR-U, which may decrease the number of LBTs performed and control signaling overhead” – See [¶0332]; e.g., “a Type 1 configured grant, an uplink grant is provided by RRC, and stored as configured uplink grant” – See [¶0333], whereby “the IE ConfiguredGrantConfig may be used to configure uplink transmission without dynamic grant” when “the actual uplink grant may be configured via RRC (type1)” – See [¶0465] containing also rrc-ConfiguredUplinkGrant indicator of "configured grant" transmission with fully RRC-configured UL grant (Type1) – See [¶0467]; furthermore, “RRC may configure the following parameters when the configured grant Type 1 is configured: . . . periodicity: periodicity of the configured grant Type 1;” – See [¶0442]); and
sending, on the unlicensed PUSCH resource, data to the base station in response to the terminal being in the uplink synchronization state (e.g., Fig. 19, showing data transmission in the second BWP on the unlicensed PUSCH resource in a periodic configured grant wherein the UE must be synchronized for UL transmission; in addition, “For configured grants on unlicensed bandwidth parts (e.g., bandwidth parts of unlicensed cells) comprising resource elements/blocks in unlicensed frequency, a transmission of a packet is preceded by a listen-before-talk procedure at the physical layer” and “the bandwidth part inactivity timer at the base station and the wireless device need to be synchronized” – See [¶0485])
and the unlicensed PUSCH resource being valid (“The second configuration parameters may comprise/indicate second configured grant/periodic resource allocation/autonomous uplink configuration parameters indicating a second plurality of configured grants for the unlicensed cell and/or second bandwidth part of the unlicensed cell” whereby “configured grants may be activated upon/in response to receiving the second configured grant/ periodic resource allocation configuration/autonomous uplink parameters and without further receiving an activation command” or a DCI “may be validated as an activation command” of the configured unlicensed PUSCH resources – See [¶0505])
wherein the data is data with a number of bits occupied being less than a set threshold (“a grant” may have a size to “indicate transmission of one or more transport blocks. The transmission parameters of the one or more transport blocks may be indicated in the grant and/or RRC configuration parameters (e.g., in configured grant configuration parameters, e.g., if the grant is a configured grant)” – See [¶0497]; e.g., the IE ConfiguredGrantConfig defines the mcsAndTBS parameter for PUSCH transmissions – See [¶0465], and the “RRC may additionally control the LCP procedure by configuring mapping restrictions for a logical channel: . . . maximum PUSCH duration allowed for transmission;” – See [¶0470] therefore, for logical channels with configuredGrantTypelAllowed, a threshold is set for the a number of bits occupied in one PUSCH transmission; furthermore, “the MAC entity is given a UL grant size,” e.g., “equal to or [less] than 8 bytes” – See [¶0478], and “the UE may maximize the transmission of data . . .to fill the grant of the associated MAC entity as much as possible” – See [¶0477], therefore the size of a valid grant is also a set threshold)
wherein determining the state of the unlicensed PUSCH resource pre-configured by the base station for the terminal comprises:
determining whether the unlicensed PUSCH resource is in a valid state or an invalid state according to a timing state of a second timer (for “configured grant Type 1 where an uplink grant is provided by RRC, and stored as configured uplink grant” – See [¶0440], the “RRC may configure . . . nrofHARQ-Processes: the number of HARQ processes” – See [¶0442] and “for a Serving Cell and a configured uplink grant, if configured and activated, . . . the MAC entity may: set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration; and if the configuredGrantTimer for the corresponding HARQ process is not running,” i.e., it is a new transmission1, “the MAC entity may consider the NDI bit for the corresponding HARQ process to have been toggled and the MAC entity may deliver the configured uplink grant and the associated HARQ information to the HARQ entity” – See [¶0455] whereby “the IE configuredGrantTimer may indicate an initial value of the configured grant timer in number of periodicities” – See [¶0467] and the configured grant may be with repetitions, “when the UE is configured with repK >l, the UE may repeat the TB across the repK consecutive slots applying the same symbol allocation in each slot,” – See [¶0464], i.e., multiple PUSCH durations in one grant with retransmissions under one HARQ process; furthermore, “[f]rom a MAC layer perspective, if a packet is created for a configured grant (e.g., if the configured grant is not skipped), and the packet is sent from MAC layer to physical layer for transmission, the packet is considered transmitted irrespective of whether the listen before talk is successful and the packet is actually transmitted or the listen before talk fails and the packet is not transmitted by the physical layer,” – See [¶0502] i.e., “a transmission is performed” when “the MAC entity may allocate resources to the logical channels” according to the grant – See [¶0474] and that transmission starts the configuredGrantTimer protecting the validity of the allocated PUSCH resources, until “when a configured uplink grant is released by upper layers, all the corresponding configurations may be released and all corresponding uplink grants may be cleared immediately” – See [¶0448]; see also § 5.4.2, 3GPP TS 38.321:42-43, “[f]or each uplink grant, the HARQ entity shall . . . identify the HARQ process associated with this grant” and “if a MAC PDU to transmit has been obtained: . . . deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process; . . . instruct the identified HARQ process to trigger a new transmission; . . .start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed;” (emphasis added), including retransmissions, until the “HARQ process receives downlink feedback information” where “acknowledgement is indicated” then “stop the configuredGrantTimer, if running” else let the configuredGrantTimer expire for that HARQ process and stop retransmissions, if configured, terminating the grant for the PUSCH duration – See id, at page 46, i.e., the PUSCH resource becomes invalid for the transmission) and
wherein the second timer is started during a process that the terminal switches from a radio resource control (RRC) connected state to an RRC inactive state and the second timer continues to time up during a time that the terminal is in the RRC inactive state until timing times out (e.g., as explained above, the UE MAC layer may perform a PDU transmission on a PUSCH resource allocated by configured grant Type 1, triggering the start of the configuredGrantTimer for that HARQ process, while, at the same time, “a wireless device may transition a UE RRC state from an RRC connected state to an RRC inactive state in a base station” – See [¶0304] whereby “an anchor base station . . . may keep a UE context (a wireless device context) of a wireless device at least during a time period that a wireless device stays in a RAN notification area (RNA) of an anchor base station, and/or that a wireless device stays in an RRC inactive state” – See [¶0303], i.e., the HARQ process at the UE is still pending/ configuredGrantTimer is still running, because “a base station receiving one or more uplink packets from a wireless device in an RRC inactive state may fetch a UE context of a wireless device” – See [¶0308] and the “UE context (e.g. a wireless device context) may comprise at least one of an access stratum context, one or more radio link configuration parameters, bearer (e.g. data radio bearer (DRB), signaling radio bearer (SRB), logical channel, QoS flow, PDU session, and/or the like) configuration information, security information, PHY/MAC/RLC/PDCP/SDAP layer configuration information, and/or the like configuration information for a wireless device” – See [¶0301], hence the HARQ acknowledgement may come back to the UE during the maintained PDU session on SRB0; see also Chin disclosure, infra);
wherein the method further comprises:
sending the data to the base station through a random access channel in response to the terminal being in the uplink synchronization state and the unlicensed PUSCH resource being invalid (e.g., when the configuredGrantTimer expired and/or the configured grant released for the unlicensed PUSCH resource, then, “if a wireless device in an RRC inactive state has one or more packets, in a buffer, to transmit to a network, the wireless device may initiate a random access procedure to transmit one or more packets to a base station of a cell that the wireless device selects,” – See [¶0307] i.e., selecting another cell of the same anchor base station triggers a random access procedure even though the UE was in uplink synchronization state; or “[a] UE may adjust an uplink transmission timing based on a timing advanced command indicated by a random access response and may transmit one or more transport blocks based on an uplink grant indicated by a random access response” – See [¶0290], i.e., the UE is in uplink synchronization when sending data to the base station and obtained a grant during the RAR procedure).
Although Babaei1 discloses that “the base station may transmit one or more MAC CEs indicating one or more timing advance values for one or more Timing Advance Groups (TAGs)” – See [¶0199], Babaei1 does not detail uplink synchronization state of the terminal comprising a first timer.
Chin, like Babaei1, discloses “wireless communication methods and UEs for performing transmissions in an RRC_INACTIVE state” – See [¶0006] whereby the “method includes: receiving, in an RRC_CONNECTED state an RRC release message including . . . a plurality of Configured Grant (CG) configurations” and “transitioning from the RRC_CONNECTED state to the RRC_INACTIVE state in response to the RRC release message” – See [¶0007], the “UE is either in RRC_CONNECTED state or in RRC_INACTIVE state when an RRC connection has been established. If this is not the case, e.g., no RRC connection is established, the UE is in RRC_IDLE state” – See [¶0049]. Chin further teaches that “NR Rel-17 opens the possibility for a UE to perform UL transmission even when it is in RRC_INACTIVE state” – See [¶0102] and “UL resources (e.g., PUSCH resources corresponding to (e.g., derived from) CG configurations) for a UE to perform UL transmission in RRC_INACTIVE state may be configured, by the network, while the UE is in either RRC_INACTIVE or RRC_CONNECTED state” – See [¶0106] while the “UE may transmit an RRC_INACTIVE configured UL grant service/modification request in order to inform the network of the parameters and/or parameter values that it prefers regarding the CG configurations for UL transmission in RRC_INACTIVE state . . . on SRB0 when a UE is in RRC_INACTIVE state and/or RRC_CONNECTED state.” – See [¶0161].
Chin further teaches the means to configure or reconfigure the UE for transmissions during RRC_INACTIVE state (“Upon reception of one or multiple pieces of the specific information, the UE may apply the received specific information upon/during/after entering RRC_INACTIVE state,” information “included in the (SuspendConfig IE of the) RRCRelease message and transmitted to a UE when a network needs to transition a UE from RRC_CONNECTED state to RRC_ INACTIVE state” or “in an RRCReconfiguration message and transmitted to a UE while the UE is in RRC_CONNECTED state” or “in a SIB and transmitted to a UE while the UE is in RRC_INACTIVE state” or “in dedicated RRC signaling and transmitted to a UE while the UE is in RRC_INACTIVE state (e.g., in the RRCRelease message in response to a UL transmission on a CG by the UE in RRC_INACTIVE state)” or “in a paging message and transmitted to a UE while the UE is in RRC_INACTIVE state” – See [¶0189]. Chin further teaches the UE may apply in the RRC_INACTIVE state the same parameters as in CG Type1 taught by Babaei1 (“Each of the CG configurations includes the parameters that may be applied by the UE in RRC_INACTIVE state. (e.g., the parameters the same as the parameters required to configure a CG Type1) . . . e.g., ConfiguredGrantConfig IE provided in 3GPP TS 38.331”– See [¶0192] and, “the UE may still perform UL transmission on the UL resources (e.g., PUSCH resources) configured/indicated in the ConfiguredGrantConfigList” even if “the UE may consider all the configured timeAlignmentTimers as expired as part of a MAC reset when transitioning from RRC_CONNECTED state to RRC_INACTIVE state” – See [¶0197]). Chin teaches small data transmission (SDT) configuration for UE in RRC_INACTIVE state (“The network may transmit the capability indication (s) to its serving UE via SIB (e.g., SIB1 or SIB2 or small-data-transmission-specific SIB) for UE(s) in RRC_INACTIVE state” – See [¶0132]).
Chin further teaches wherein determining the uplink synchronization state of the terminal comprises: determining whether the terminal is in the uplink synchronization state or in the non-uplink-synchronization-state according to a timing state of a first timer (“the UE is no longer synchronised with the network (e.g., a timeAlignmentTimers used by the UE in RRC_INACTIVE has expired)” – See [¶0258], whereby “timeAlignmentTimers may be provided in 3GPP TS 38.321” – See [¶0195], whereby § 5.2, 3GPP TS 38.321:34-36, defines “timeAlignmentTimer (per TAG) which controls how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned” stating that when “the maximum uplink transmission timing difference between TAGs of the MAC entity or the maximum uplink transmission timing difference between TAGs of any MAC entity of the UE is exceeded, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired” and “[t]he MAC entity shall not perform any uplink transmission on a Serving Cell except the Random Access Preamble and MSGA transmission when the timeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running,” i.e., the uplink synchronization state or in the non-uplink-synchronization-state is determined according to timeAlignmentTimer running or expired),
wherein the first timer starts to time after the terminal switches to the RRC inactive state (e.g., as explained supra, one or multiple pieces of the specific information that the UE may apply after entering RRC_INACTIVE state may be a timer, and “[t]he specific timer may be a timer to control the validity of the TA corresponding to the configured UL grant(s) (configurations);” – See [¶0151], i.e., this timeAlignmentTimer will start after the UE switches to the RRC inactive state), or
the first timer starts to time at the time that the terminal is in the RRC connected state and continues to time up until timeout after the terminal switches to the RRC inactive state (“the UE may not consider the configured time alignment timers (e.g., timeAlignmentTimers, which are associated with a PTAG and/or STAG) as expired while performing MAC reset when transitioning from RRC_CONNECTED state to RRC_INACTIVE state” – See [¶0195]).
Thus, Babaei1 and Chin each teaches UE methods of uplink transmissions on configured grants/pre-configured PUSCH resources whereby the UE may be switched by the base station from an RRC_CONNECT state to an RRC_INACTIVE state. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the specific information regarding configured grants in RRC_INACTIVE state, including the timer whose state indicates synchronized or unsynchronized state of the UE for uplink transmissions, as taught by Chin, could have been combined with the steps performed by the UE in Babaei1 because both used configured grants describing PUSCH resources for sending data compliant with 3GPP specifications. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of expanding Babaei1 UE’s capabilities for UL transmission in RRC_INACTIVE state, including transmission of small data, following Rel-17 NR developments, as taught by Chin.
Therefore, Amended Claim 1 is obvious over Babaei1 in view of Chin.
Regarding Claim 3, dependent from Amended Claim 1, Babaei1 further teaches the method according to claim 1, wherein sending the data to the base station through the random access channel comprises:
sending the data to the base station through a 2-step random access channel or a 4-step random access channel according to random access configuration of the terminal (“if a wireless device in an RRC inactive state has one or more packets, in a buffer, to transmit to a network, the wireless device may initiate a random access procedure to transmit one or more packets to a base station” whereby “[a] random access procedure may be performed with two messages (e.g. 2 stage random access) and/or four messages ( e.g. 4 stage random access) between the wireless device and the base station” – See [¶0307]; and whereby each UE is configured with cell specific RACH-configCommon and Information Element based on the initial Uplink BWP configured to the terminal by SIB1 – See, e.g., 3GPP TS 38.331:329-330, 507-510.
Therefore, Claim 3 is obvious over Babaei1 in view of Chin.
Regarding Claim 4, dependent from Claim 3, although Babaei1 teaches the random access procedure according to claim 3, and that “rach-ConfigCommon may indicate configuration of cell specific random access parameters which the UE may use for contention based and contention free random access” – See [¶0426] and that the UE “may transmit one or more transport blocks based on an uplink grant indicated by a random access response” – See [¶0290], Babaei1 does not explicitly teach sending the data to the base station through the 2-step random access channel in response to determining that the terminal supports 2-step random access according to the random access configuration.
However, Chin references 3GPP TS 38.321 for MAC related procedures and these procedures include RAR procedures based on the rach-Config – See § 5.1.1, 3GPP TS 38.321:18-20 (stating that “if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure . . . set the RA_TYPE to 2-stepRA” and “perform the Random Access Resource selection procedure for 2-step RA type,” whereby the RA_TYPE is one of the “UE variables are used for the Random Access procedure”), and thereafter the UE “may transmit one or more transport blocks based on an uplink grant indicated by a random access response” – See Babaei1:[¶0290].
Thus, Babaei1 in combination with Chin teaches wherein sending the data to the base station through the random access channel comprises: sending the data to the base station through a 2-step random access channel or a 4-step random access channel according to random access configuration of the terminal.
Therefore, Claim 4 is obvious over Babaei1 in view of Chin.
Regarding Claim 5, dependent from Claim 4, Babaei1 in view of Chin further teaches wherein sending the data to the base station comprises: sending the data to the base station through the 4-step random access channel in response to determining that the terminal does not support the 2-step random access according to the random access configuration – See § 5.1.1, 3GPP TS 38.321:19-20 (stating that “if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure: . . . set the RA_TYPE to 4-stepRA”; similarly, “if the BWP selected for Random Access procedure is configured with both 2-step and 4-step RA type Random Access Resources and the RSRP of the downlink pathloss reference is [below] RSRP_THRESHOLD_RA_TYPE_SELECTION . . . set the RA_TYPE to 4-stepRA,” i.e., channel conditions are not suitable for the faster 2-step RA procedure) thereafter the UE “may transmit one or more transport blocks based on an uplink grant indicated by a random access response” – See Babaei1:[¶0290].
Therefore, Claim 5 is obvious over Babaei1 in view of Chin.
Regarding Claim 6, dependent from Amended Claim 1, although Babaei1 further teaches that “[o]ne or more events may trigger a random access procedure” including “UL data arrival . . . when UL synchronization status is non-synchronized” or “transition from RRC_Inactive” – See [¶0281], Babei1 does not explicitly teach a TimeAlignmentTimer maintained by the terminal.
Chin teaches that the first timer is the TimeAlignmentTimer described in 3GPP TS 38.321 as explained in Regarding Amended Claim 1, reciting wherein determining the uplink synchronization state of the terminal comprises: determining that the terminal is in the uplink synchronization state according to a timing state of a first timer, whereby “the UE may not consider the configured time alignment timers (e.g., timeAlignmentTimers, which are associated with a PTAG and/or STAG) as expired . . . when transitioning from RRC_CONNECTED state to RRC_INACTIVE state” – See [¶0195], therefore at least a TimeAlignmentTimer maintained by the terminal is valid and the MAC entity of the UE may perform uplink transmissions because the Timing Advance is still valid.
Therefore, Claim 6 is obvious over Babaei1 in view of Chin.
Regarding Claim 7, dependent from Amended Claim 1, Babaei1 further teaches wherein determining the state of the unlicensed physical uplink shared channel (PUSCH) resource pre-configured by the base station for the terminal comprises:
determining that the unlicensed PUSCH resource is valid in response to a configuredGrantTimer being valid (“the IE ConfiguredGrantConfig may be used to configure uplink transmission without dynamic grant” – See [¶0465] wherein “the IE configuredGrantTimer may indicate an initial value of the configured grant timer” – See [¶0467]; i.e., the pre-configured PUSCH resource on an unlicensed carrier/BWP, as explained in Regarding Amended Claim 1, supra, is no longer valid when the timer expires; see also Chin:[¶0270] (“specific timer corresponding to the cleared/suspended configured UL grant(s) ( configurations) . . . may be a timer to control the validity of the configured UL grant(s) (configurations),”) whereby the specific timer may be configuredGrantTimer – See [¶0240] (“The RRC_INACTIVE UL resource may be preconfigured by the UE or configured by the network via RRC signaling. The network may provide an indication (via RRC signaling) to a UE while it is in RRC_CONNECTED state. This indication may be used to indicate whether a UE is allowed to use the configuredGrantConfig IE when it is in RRC_INACTIVE state”).
Therefore, Claim 7 is obvious over Babaei1 in view of Chin.
Regarding Claim 8, dependent from Amended Claim 1, Babaei1 further teaches wherein sending, on the unlicensed PUSCH resource, the data to the base station comprises:
sending, on the PUSCH resource, the data and a terminal identifier of the terminal to the base station (“RRC may configure the following parameters when the configured grant Type 1 is configured: cs-RNTI: CS-RNTI for retransmission” – See [¶0442]; whereby, for Type 1 grants, the cs-RNTI identifies the UE’s MAC entity retransmitting data2; see also Chin:[¶¶0091-92]).
Therefore, Claim 8 is obvious over Babaei1 in view of Chin.
Regarding Claim 9, dependent from Claim 8, Babaei1 further teaches the method according to claim 8 wherein an I-RNTI is used in RRC_INACTIVE state (“[i]n an RRC_Inactive state, a wireless device may perform at least one of . . . monitoring/receiving a RAN/CN paging initiated by NG-RAN/5GC” – See [¶0205]; and the RRC_INACTIVE state of a UE described in § 4.2.1 of 3GPP TS 38.331:26 wherein the UE “Monitors a Paging channel for CN paging using 5G-S-TMSI and RAN paging using full I-RNTI”). Chin also teaches that an “Inactive Radio Network Temporary Identifier” (I-RNTI) and that “[t]he suspend configuration may refer to a parameter/IE denoted as "suspendConfig" which provides information to a UE” including “full I-RNTI/short I-RNTI: Used to identify the suspended UE context of a UE in RRC_INACTIVE state” – See [¶0071].
Therefore, Claim 9 is obvious over Babaei1 in view of Chin.
Regarding Amended Claim 19, Babaei1 discloses in Fig. 3 a communication device, comprising: an antenna; a memory; and one or more processors, collectively connected with the antenna and the memory respectively (“The wireless device 110 may comprise at least one communication interface 310 (e.g. a wireless modem, an antenna, and/or the like), at least one processor 314, and at least one set of program code instructions 316 stored in non-transitory memory 315 and executable by the at least one processor 314” – See [¶0213]), wherein the one or more processors are collectively configured to: perform the steps of the method disclosed in Amended Claim 1, recited with the same language. Because Amended Claim 1 is obvious over Babaei1 in view of Chin, Amended Claim 19 is also obvious over Babaei1 in view of Chin.
Regarding Amended Claim 20, Babaei1 discloses a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer-executable instructions; and the computer-executable instructions, after being when collectively executed by one or more processors of a terminal (the non-transitory memory 315 of Fig. 3 contains “code stored in a memory device to implement protocol(s), protocol layers, communication drivers, device drivers, combinations thereof”; furthermore “[t]he firmware interface may comprise a combination of embedded hardware and code stored in and/or in communication with a memory device to implement connections, electronic device operations, protocol(s), protocol layers, communication drivers, device drivers, hardware operations, combinations thereof” – See [¶0221]) cause the terminal to perform the steps of the method disclosed in Amended Claim 1, recited with the same language. Because Amended Claim 1 is obvious over Babaei1 in view of Chin, Amended Claim 20 is also obvious over Babaei1 in view of Chin.
Regarding Claim 21, dependent from Amended Claim 1, Babaei1 teaches Time Alignment but does not teach a TimeAlignmentTimer.
However, as explained in Amended Claim 1, supra, Chin teaches wherein determining the uplink synchronization state of the terminal comprises: determining that the terminal is in a non uplink-synchronization-state in accordance with the state of a first timer, whereby the first timer is a TimeAlignmentTimer, and “the UE is no longer synchronised with the network (e.g., a timeAlignmentTimers used by the UE in RRC_INACTIVE has expired” – See [¶0258], whereby “timeAlignmentTimers may be provided in 3GPP TS 38.321” – See [¶0195], whereby § 5.2, 3GPP TS 38.321:34-36, defines “timeAlignmentTimer (per TAG) which controls how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned.”
Therefore, Claim 21 is obvious over Babaei1 in view of Chin.
Regarding Claim 22, dependent from Amended Claim 1, Babaei1 in view of Chin teaches wherein determining the state of the unlicensed physical uplink shared channel (PUSCH) resource pre-configured by the base station for the terminal comprises: determining whether the unlicensed PUSCH resource is in a valid state or an invalid state according to a timing state of a second timer whereby the second timer is configuredGrantTimer that may expire, as explained in Regarding Amended Claim 1, supra. In addition, Chin teaches that the unlicensed PUSCH resource is invalid in response to the configuredGrantTimer being invalid (e.g., configuredGrantTimer is “a timer to control the validity of the configured UL grant(s) (configurations)” and its stopping “correspond[s] to the cleared/suspended configured UL grant(s) ( configurations)” – See [¶0151], hence invalidating the pre-configured PUSCH resources).
Therefore, Claim 22 is obvious over Babaei1 in view of Chin.
Regarding Claims 24-29, dependent from Amended Claim 19, each claim merely recites the apparatus of Amended Claim 19, further limited by the steps recited in Claims 3-8, respectively, using the same language. Because each of the Claims 3-8, and 19, is obvious over Babaei1 in view of Chin, each of the Claims 24-29 is also obvious over Babaei1 in view of Chin.
In sum, Claims 1, 3-9, 19-22, and 24-29, as amended, are rejected under 35 U.S.C. §103 as obvious over Babaei1 in view of Chin.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Chen et al., U.S. Patent Application Publication No. 2023/0030443 discloses Small Data Transmission Via Configured Grants [¶0047] the BS may configure the following parameters when the configured grant Type 1 for the RRC_INACTIVE state is configured: nrofHARQ-Processes: the number of HARQ (Hybrid Automatic Repeat reQuest) processes for configured grant;
Xu et al., U.S. Patent Application Publication No. 2025/0142667 discloses multiple transmission schemes for performing data communication in the RRC inactive state using pre-configured grants/assignments, dynamic scheduling, and/or RACH procedures whereby the first uplink transmission may be provided together with the UE's I-RNTI, e.g., to identify the wireless device to the network;
Babaei, U.S. Patent Application Publication No. 2024/0129995 discloses data transmission in inactive state of the UE;
Höglund et al., U.S. Patent Application Publication 2022/0007391 teaches preconfigured resource (PUR) on which a wireless device may transmit even in idle mode or inactive mode;
Chen et al., U.S. Patent Application Publication 2024/0414775 teaches MAC layer in RRC_INACTIVE state, that in Rel-17 small and infrequent data traffic will be allowed in INACTIVE state, and data may be transmitted either via a pre-configured PUSCH resource (if available) or by triggering an appropriate (2-step/4-step) random access procedure;
Ryoo et al., U.S. Patent Application Publication No. 2021/0314988 discloses timers for transitioning between RRC states, a timer value to applv dedicated RACH resource, and various transmissions options including starting transmission in RRC_INACTIVE and continuing in RRC_ACTIVE state;
Hoglund et al., U.S. Patent Application Publication No. 2022/0038997 discloses control of wireless device whether it is allowed or is not allowed to use the preconfigured resources and the preconfigured resource depending on the received information;
Sha et al., U.S. Patent Application Publication No. 2023/0413375 discloses method and apparatus for transmitting data on pre-configured terminal-specific dedicated resources, wherein the terminal is in an idle mode and is without an established RRC connection;
Lee et al., U.S. Patent Application Publication No. 2024/0224209 teaches a method for maintaining uplink synchronization for a serving cell by a terminal in an inactive state and that full I-RNTI may be a terminal identifier used for the RRC resume request (RRCResumeRequest1), and the short I-RNTI may correspond to a terminal identifier used for the RRC resume request (RRCResumeRequest); and that CS-RNTI may correspond to an identifier of a terminal for uplink transmission/retransmission;
Ohara, U.S. Patent Application Publication No. 20220174750, discloses various methods to for determine the validity of a plurality of PUSCH resources notified from the network (for example, the base station) to the UE in advance;
Sun et al., U.S. Patent Application Publication No. 2021/0321451 discloses PRACH-PUSCH transmissions in shared or unlicensed spectrum applications;
Tao et al., U.S. Patent Application Publication No. 20230104628 discloses user equipment and base station involved in transmission of small data in UE inactive state;
Zhang et al., WIPO Patent Application Publication WO 2019/028732 discloses UE in IDLE state performing transfer of the data during the RA process and associated timers;
3GPP TS 38.321 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16)”;
3GPP TS 38.331 V16.0.0 (2020-03), “NR; Radio Resource Control (RRC) protocol specification (Release 16)”;
3GPP TS 38.300 V16.1.0 (2020-03), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)”;
3GPP TSG RAN Meeting #86, RP-193252, Title: “Work Item on NR small data transmissions in INACTIVE state,” Source: ZTE Corporation, Agenda Item: 9.1.2; December 2019 and subsequent contributions to this WID in RAN1 and RAN2 prior to the effective filing date of the present application;
3GPP TSG RAN WG1 #97, R1-1906581, Title: “On Procedure for 2-step RACH,” Source: Oppo. May 2019;
3GPP TSG-RAN WG2 Meeting #109 electronic, R2-2000417, Title: “Remaining issues on NR-U configured grant,” Source: Oppo, March 2020;
3GPP TSG RAN WG1 #97, R1-1906193, Title: "Discussion on Procedure for Two-step RACH," Source: NTT DOCOMO, INC., Reno, USA, May 13th – 17th, 2019;
3GPP TSG-RAN WG2 Meeting #109bis-e, R2-2003639, Title: [H227] TP for the description of CG configuration, Source: Huawei, HiSilicon, April 2020.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
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, Joseph AVELLINO can be reached at (571)272-3905. 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.
/L.G.G./ Examiner, Art Unit 2478
/JOSEPH E AVELLINO/ Supervisory Patent Examiner, Art Unit 2478
1 See § 5.4.2, 3GPP TS 38.321 V16.0.0 (2020-03), “Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 16)” (hereinafter 3GPP TS 38.321), stating, at page 40, that: “For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall: . . . set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;” and “if, for the corresponding HARQ process, the configuredGrantTimer is not running and cg-RetransmissionTimer is not configured (i.e. new transmission)” it means new transmission on the PUSCH resource configured by the CG; see also § 6.4.1.1.3, 3GPP TS 38.211 V16.1.0 (2020-03), “Technical Specification Group Radio Access Network;
NR; Physical channels and modulation (Release 16),” at page 72-75, defining the PUSCH duration as “the duration between the first OFDM symbol of the slot and the last OFDM symbol of the scheduled PUSCH resources in the slot” as further specified in Table 6.4.1.1.3-3.
2 See, e.g., § 5.4.1 of 3GPP TS 38.321:39 “[a]n uplink grant addressed to CS-RNTI with NDI = 0 is considered as a configured uplink grant”