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 Arguments
Applicant's arguments filed 12/2/2025 have been fully considered but they are not persuasive.
Regarding claim 25, Applicant argues that Wu does not distinguish between specified and default configurations (page 7). Examiner agrees and notes the Liu is cited for these elements. Applicant further argues that Liu does not cure the deficiencies of Wu as it does not disclose the claimed first and second RLC channel. However, the system of Wu is cited for these elements as discussed, infra. Therefore, Applicant’s Arguments have been considered and are not persuasive.
Applicant further argues that Wu does not disclose a second, different PC5 RLC channel as it is not clear if the PC5 RLCs are “directionally distinct” or how the PC5 RLC connection is channelized (page 8). Examiner disagrees, as the broadest reasonable interpretation of RLC channel includes the separate over-the-air channels for uplink and downlink RLC transmission, regardless of if the uplink or DL RLC entities are “channelized” or distinct. Therefore, Applicant’s Arguments have been considered and are not persuasive. Furthermore, even if this were not the case the system of Liu discloses distinct UL and DL RLC channels with different default configurations, as discussed and combined with Wu, infra (Paragraph 0140 of Liu- “[0140] …Certainly, the uplink Uu signaling and the downlink Uu signaling may alternatively be transmitted by using different sidelink RLC bearers.”].)
Therefore, Applicant’s Argument have been considered and are not persuasive.
Regarding claim 17, Applicant argues that 047 in view of Burbridge fails to disclose a first RLC channel applied with a specified configuration and a second RLC channel applied with a default configuration.
Applicant first argues that Burbridge does not disclose a first RLC channel over a PC5 interface, as it discloses the RRC Connection setup optimization for a default Uu interface. Examiner agrees, but notes this ignores the combination made.
That is, as discussed in the rejection, infra, 047 discloses a first RLC channel, SRB0, with a specific/predetermined configuration is used to transmit the SRB0 message/RRC Setup Request.
047 further discloses that before establishment of a base station configured second/SRB1/SRB2 channel by RRC Reconfiguration, the transmission response to the RRC connection setup/response message is sent by the relay UE to the remote UE using a RLC channel, however, the exact channel is not specified. However, it is further shown in 047 that the only available RLC channels for the transmission at the time of sending the transmission response to the RRC connection setup/response message are a default RLC channel on SRB1/2 [i.e. second RLC channel], as the base station configured SRB1/2 have not yet been established via RRC Reconfiguration. This strongly suggests, but does not prove, that the default SRB1/SRB2/second RLC channel is used for the transmission of the RRC connection setup/response message. The system of Birbridge is only used to demonstrate that it was known to transmit a RRC connection setup/response message using a default SRB1/second RLC channel. This is in the context of a Uu connection with the base station, but that is not relevant to the combination made which only needs to demonstrate that it was known to use a default SRB1/second RLC channel to send a RRC connection setup response message as the system of 047 already discloses a default SRB1/second RLC channel used for singling on the PC5 interface, it is just not explicit about the use of default SRB1/second RLC channel for transmission of a RRC connection setup response message. Therefore, Applicant’s Arguments have been considered and are not persuasive.
Applicant further argues that the default configuration of Burbridge for a Uu connection cannot simply be applied to a PC5 interface. Examiner notes that this does not address the combination made, as the system of 047 already discloses a PC5 second RLC channel/SRB1 with a default configuration, it is just not totally explicit that this could be used for sending the transmission response to the RRC connection setup/response message. The system of Burbridge discloses using a RLC channel/SRB1 with a default configuration for sending a transmission response to a RRC connection setup/response message in the context of a Uu interface and a person of ordinary skill in the art would recognize that this could also be applied to the a PC5 second RLC channel/SRB1 with a default configuration taught by 047.
Applicant further argues that 047 teaches away from the claimed combination as in proposal 8 it discloses all bearer/LCH mappings at remote UE and relay UE are configured by the gNB. This statement is true, but ignores the process present in 047. That is, the a RRC connection setup/response message occur before the RRCReconfiguraiton messages used by the base station to reconfigure the bearers/SIB1/second RLC channel from the default state [proposal 3 – “For SRB1 and SRB2 of the Remote UE, we prefer to reuse the existing design, i.e., there will be default configuration for SRB1 and SRB2 which are includes Uu and PC5 hops. For Uu part, the existing default configuration can be reused. For PC5 part, a set of default configuration can be defined similar to the SL-SRB. In addition, we also think it is beneficial to support reconfiguration by the gNB as what we specified for the Uu SRB1/SRB2.; page 8, step 7 – “Step7: RRC Reconfiguration procedure between remote UE and gNB. Similarly, the RRC Reconfiguration is performed between remote UE and gNB via relay UE. – note this occurs after steps 3-4 which are the RRC setup/complete transmission]. Therefore, as discussed in the rejection, infra, at the time the RRC connection setup/response message in step 3 there is no configured SRB1/2 connection for use for transmission of the RRC connection setup/response message and only default SRB1/SRB2 connections exist. This occurs despite later reconfiguration of the default SRB1/2 to bearer parameters specifically needed for QoS transmission in step 7.
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) 17, 18, 22 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over R2-2008047 (“047”) (Author Unknown, Study aspects of UE-to-Network relay and solutions for L2 relay, Doc. No. R2-2008047, pages 1-12, 28 August 2020) in view of Burbidge, et al. (US Pre Grant Publication No. 2019/0215887 A1).
Regarding claim 17, 047 discloses a method by a relay user equipment (UE), comprising:
(a) receiving a signal radio bearer 0 (SRB0) message from a remote UE, wherein the SRB0 is transmitted via a first radio link control (RLC) channel over PC5 interface, and wherein the first RLC channel is applied with a specified configuration; (047 discloses that a remote UE transmits and the relay UE receives a SRB0 message containing a RRC Setup request [pages 6-8, Proposal 14, in particular step 3 and fig. 7, element 3]. The request is transmitted on a sidelink/SL/PC5 connection and the RLC channel is configured based on a preconfigured/specified configuration [pages 6-8, Proposal 14, in particular step 3 and fig. 7, element 3].)
(b) forwarding the SRB0 message to a base station; (pages 6-8, Proposal 14, in particular step 3 and fig. 7, element 3 – “Further, relay UE forwards the received RRCSetupRequest message to gNB, e.g. via a default Uu RLC bearer”)
(c) receiving a response message from the base station; and (pages 6-8, Proposal 14, in particular step 4 and fig. 7, element 4 - “If gNB accepts the request from remote UE, it responses the RRCSetup message to remote UE via relay UE…Upon reception of the adaptation layer PDU encapsulating RRCSetup message, the relay UE acquires the local identifier from the adaptation layer header and determines the linked remote UE based on this local identifier. Then the relay UE is able to relay the received RRC PDU to remote UE.”)
(d) the response message is transmitted via a second channel over PC5 interface (The response is transmitted by the relay to the UE [pages 6-8, Proposal 14, in particular step 4 and fig. 7, element 4 - “If gNB accepts the request from remote UE, it responses the RRCSetup message to remote UE via relay UE…Upon reception of the adaptation layer PDU encapsulating RRCSetup message, the relay UE acquires the local identifier from the adaptation layer header and determines the linked remote UE based on this local identifier. Then the relay UE is able to relay the received RRC PDU to remote UE.”.)
047 fails to explicitly disclose the response message is transmitted via a second channel over PC5 interface, and wherein the second RLC channel is applied with a default configuration. In the same field of endeavor, Burbidge, et al discloses the second RLC channel is applied with a default configuration.
That is 047 discloses that the relay uses an RLC channel for transmissions to the remote UE (see page 6, in particular, Fig. 6 – relay transmissions are via SL-RLC). 047 further discloses only two RLC channels for the connection between the relay and the remote UE, SRB1 and SRB2 [page 4, proposal 3]. Finally 047 discloses that SRB1 and SRB2 operate with a default configuration before specific configuration by the base station [page 4, proposal 3, SRB1 and SRB2 are initially applied with a default configuration; see also page; pages 7-8 step 3 – relay notes connection ID and uses it to route on the return path] which has not happened yet at the time of reception of the response/RRCSetup message [see pages 6-8, Proposal 14, no configuration of the SRB1 or SRB2 for the new UE has occurred]. Therefore, 047 discloses only two RLC channels SRB1 and SRB2 each with a default configuration are available for transmissions from the relay to the remote UE at the time the response/RRCSetup message is received, which is highly suggestive that one of the channels would be used for transmission of the response/RRCSetup. However, this suggestion is not conclusive.
The system of Burbidge discloses that it was known in the art to use an SRB1 with a default configuration for transmission of a RRCSetup/response message (paragraph 0071).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time of the invention to combine the SRB1 transmission of Burbidge with the system of 047 by transmitting the RRCSetup/response message using the SRB1 RLC channel with a default configuration. The motive to combine is to allow the use of an already configured default channel to reduce signaling overhead vs configuring a new channel.
Regarding claim 18, 047 discloses (b) involves forwarding the SRB0 message via a default RLC channel over Uu interface for SRB0 transmission (Page 8, step 3, - “Further, relay UE forwards the received RRCSetupRequest message to gNB, e.g. via a default Uu RLC bearer. …The default Uu RLC bearer is introduced to carry SRB0 related messages in Uu.)
Regarding claim 22, 047 discloses the SRB0 message is transmitted together with an ID of the remote UE (Relay UE determines the source L2 ID of the UE from the contents of the RRCSetupRequest/SRB0 message [pages 7-8, step 3].)
Regarding claim 23, 047 discloses the ID of the remote UE is determined by the remote UE, the relay UE, or by the base station to identify the remote UE associated with the SRB0 message (Relay UE determines the source L2 ID of the UE from the contents of the RRCSetupRequest/SRB0 message and uses it for routing the response/RRCSetup to the remote UE [pages 7-8, steps 3 and 4].)
Claim(s) 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over R2-2008047 (“047”) (Author Unknown, Study aspects of UE-to-Network relay and solutions for L2 relay, Doc. No. R2-2008047, pages 1-12, 28 August 2020) and Burbidge, et al. (US Pre Grant Publication No. 2019/0215887 A1) as applied to claim 17 and further in view of TS 38.331 v16.1.0 (“331”) (Author Unknown, TS 38.331 v16.1.0, Pages 1-356, July 2020)
Regarding claim 19, 047 as modified by Burbridge discloses the SRB0 message is contained in a RRC message transmitted using Uu SRB1 (see discussion in the combination with Burbridge in claim 17, supra)
047 as modified by Burbridge fails to disclose the Uu SRB1 transmission uses the UL-DCCH such that the RRC message is on a UL-DCCH over Uu. In the same field of endeavor, 331 discloses the Uu SRB1 transmission uses the UL-DCCH such that the RRC message is on a UL-DCCH over Uu.(331 discloses that uplink transmissions via SRB1 utilize the DCCH [Pages 29-30, Section 4.2.2 – SRB1 is sent on DCCH, which will be UL-DCCH in the case of an uplink transmission])
Therefore, since 331 discloses SRB1 UL-DCCH transmission 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 SRB1 UL-DCCH transmission of 331 with the system of 047 as modified by Burbridge by forwarding the request message/RRCSetup request to the base station by the relay using an UL-DCCH Uu. The motive to combine is to utilize the already existing SRB1 UL-DCCH control channel for sending control information to reduce overhead vs establishing an addition control channel.
Regarding claim 20, 047 as modified by Burbridge fails to disclose the response message in (c) is contained within a radio resource control (RRC) message on a DL-DCCH (downlink dedicated control channel) over Uu. In the same field of endeavor, 331 discloses the response message in (c) is contained within a radio resource control (RRC) message on a DL-DCCH (downlink dedicated control channel) over Uu. (331 discloses that SRB1 is to be used for transmitting RRC messages via DCCH, which in the case of a DL transmission would be a DL-DCCH [Pages 29-30, Section 4.2.2 – SRB1 DCCH is used for RRC transmissions.])
Therefore, since 331 discloses SRB1 DL-DCCH for RRC message transmission, 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 SRB1 DL-DCCH transmission of 331 with the system of 047 as modified by Burbridge by transmitting the response/RRCSetup message on the DL Uu connection to the relay using an SRB1 DL-DCCH. The motive to combine is to utilize the already existing SRB1 UL-DCCH control channel for sending control information to reduce overhead vs establishing an addition control channel.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over R2-2008047 (“047”) (Author Unknown, Study aspects of UE-to-Network relay and solutions for L2 relay, Doc. No. R2-2008047, pages 1-12, 28 August 2020) and Burbidge, et al. (US Pre Grant Publication No. 2019/0215887 A1) as applied to claim 17 and further in view of Pan, et al. (US Pre Grant Publication No. 2021/0160939 A1; note also 62940460 (“460”), with parallel citations).
Regarding claim 21, 047 as modified by Burbidge fails to disclose the response message in (d) is contained within a radio resource control (RRC) message on a SCCH (sidelink control channel) over PC5 interface. In the same field of endeavor, Pan discloses the response message in (d) is contained within a radio resource control (RRC) message on a SCCH (sidelink control channel) over PC5 interface. (Pan discloses that each SRB used for PC5-RRC transmission [which would include the SRB 1 of the SL of claim 17] is associated with a SCCH configuration [paragraph 0254; note also 460, page 23, second to last paragraph].)
Therefore, since Pan discloses associating a SCCH with a SRB, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to associate the SRB 1 of 047 as modified by Burbidge with a SCCH used for transmission. The motive to combine is to utilize a dedicated control channel for transmitting high importance RRC data at higher coding rates for better reliability.
Claim(s) 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over R2-2008047 (“047”) (Author Unknown, Study aspects of UE-to-Network relay and solutions for L2 relay, Doc. No. R2-2008047, pages 1-12, 28 August 2020) and Burbidge, et al. (US Pre Grant Publication No. 2019/0215887 A1) as applied to claim 17 and further in view of Zhao, et al. (US Pre Grant Publication No. 2023/0164665; note also CN 202010315891.5 (“891”), with parallel citations to translation).
Regarding claim 24, 047 as modified by Burbidge fails to disclose the ID of the remote UE is included on one of an adaptation layer header. In the same field of endeavor, Zhao discloses the ID of the remote UE is included on one of an adaptation layer header. (Zhao discloses the adaptation layer PDU header includes the source L2 ID [paragraph 0159; note also 891, page 37, paragraph starting with “mode 1”; note that the interface source identifier is a L2 source identifier as the referenced bearers are L2 bearers [page 12, “Background Art”].)
Therefore, since Zhao discloses including the source L2 ID in the adaptation layer header, 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 L2 ID of the remote ID in an adaptation layer header. The motive to combine is to allow the relay to quickly ascertain the source ID by placing it in the header.
Claim(s) 25 -29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wu, et al. (US Pre Grant Publication No. 2022/0312535; note also PCT/CN2020/103781 – all paragraphs the same for citation) as applied to claim 25 and further in view of Liu, et al. (US Pre Grant Publication No. 2023/0023135 A1; note translation of CN20201035343 (“343”) with parallel citations).
Regarding claim 25, Wu discloses a method by a relay user equipment (UE), comprising:
a. receiving a system information request message from a remote UE, wherein the request message is transmitted via a first radio link control (RLC) channel over PC5 interface; and (Wu discloses a remote UE may transmit a request message for SI to relay user equipment via the PC5 interface, which receives it, when the UE is idle to base station but in connected state with the relay UE [i.e. case 2] [fig. 11, element 1114; paragraph 0052 and 0064-0066] the same is also true when the UE is RRC connected with the base station and the relay [i.e. case 3] [paragraph 0053, 0067]. Finally, when the UE is idle with respect to both the base station and relay [i.e. case 1] the UE may request SI as well [paragraphs 0051, 0054 0069]. Both the remote UE to relay UE connection and the relay UE to network/base station connection transmit information using an RLC channel [paragraphs 0004, 0031, note also fig. 2A].)
b. transmitting requested system information to the remote UE via a via a second RLC channel over PC5 interface, wherein the second RLC channel is different from the first RLC channel (The relay UE retrieves the requested information from the base station or local storage and transmits it to the remote UE [case 2- fig. 11, element 1122; paragraphs 0052, 0066 – idle connection to BS, RRC connected with relay; case 3 - paragraphs 0053, 0067 – connected with both BS and relay; case 1 - paragraphs 0051, 0054 0069]. Wu discloses that in case 2, the remote UE may be in an inactive/idle state with respect to the base station and a connected state with respect to the relay UE [i.e. the UE is in an idle state under the broadest reasonable interpretation as it is idle with respect to the base station] [fig. 11, element 1114; paragraph 0052 and 0064-0066]. Wu further discloses that in case 2, the relay UE may be in a RRC Connected state with respect to the base station [i.e. the claimed “RRC CONNECTED” state] [paragraphs 0065, 0072]. When the relay UE is in the RRC Connected state with respect to the base station it may request system information from the base station using RRC System Info Request and send a response to the remote UE [paragraph 0065, 0072]. As with all remote UE to relay UE transmissions, the response uses an RLC channel [paragraphs 0004, 0031, note also fig. 2A] which is a different/second RLC channel from the first/uplink RLC channel as it is on the downlink.)
Wu fails to disclose the first RLC channel is applied with a specified or a default configuration or the transmitting requested system information is via a second RLC channel over PC5 interface wherein the second RLC channel is applied with a specified or default configuration and is different form the first RLC channel. In the same field of endeavor, Liu discloses he first RLC channel is applied with a specified or a default configuration or the transmitting requested system information is via a second RLC channel over PC5 interface wherein the second RLC channel is applied with a specified or default configuration and is different form the first RLC channel. (Liu discloses that the remote UE may establish different default configured channels for communication on UL and DL with the relay UE either for Uu forwarding by explicit configuration [paragraph 0131-0134 – default configuration; 0140 – Uu UL and DL channels linked with different SL RLC bearers; see also 343, page 22] or implicitly [paragraph 0144; see also 343, page 22-23].)
Therefore, since Liu discloses using default configurations for different uplink and downlink RLC channels, it would have been obvious to a person of ordinary skill in the art at before the effective filing date of the invention to combine the RLC channels of Wu with the system of Liu by implementing the first uplink RLC channel using a default configuration and the second downlink RLC channel using a default configuration. The motive to combine is to simplify configuration by using a default configuration that does not require signaling overhead to configure.
Regarding claim 26, Wu discloses the remote UE is in a radio resource control (RRC) CONNECTED state, and wherein the request message is a DedicatedSlBRequest message, and wherein the procedure for the relay UE to handle the request message further comprising forwarding the request message to a base station, receiving a response message from the base station and forwarding the response message to the remote UE, wherein the response message is transmitted via a second RLC channel over PC5 interface. (In case 3, where the remote UE is in RRC connected with the base station and the relay UE, the remote UE may send a Dedicated SIB Request message to trigger the SIB retrieval [paragraphs 0053, 0067]. As with all remote UE to relay UE transmissions, the response uses an RLC channel [paragraphs 0004, 0031, note also fig. 2A] which is a different/second RLC channel from the first/uplink RLC channel as it is on the downlink.).
Regarding claim 27, Wu further discloses the first RLC channel is used by the remote UE to send the system information and (see independent claim, supra) and wherein the remote UE is in an radio resource control (RRC) IDLE state or in RRC INACTIVE state and wherein a procedure for the relay UE to transmit the requested system information to the remote UE further comprising transmitting the requested system information to the remote UE when the relay UE has a stored valid version of the requested system information and otherwise, triggering a system information acquisition procedure to acquire the requested system information when the relay UE does not have the stored valid version of the requested system information. (Wu discloses that in case 2, the remote UE may be in an inactive/idle state with respect to the base station and a connected state with respect to the relay UE [i.e. the UE is in an idle state under the broadest reasonable interpretation as it is idle with respect to the base station] [fig. 11, element 1114; paragraph 0052 and 0064-0066]. In relay UE RRC inactive state with respect to the base station/case 2, the remote UE may transmit a request for on demand SI/system information request to the relay UE and the relay UE may determine if it has stored the requested SI and if so, return it to the remote UE and if not, request the information from the base station using a RRC System Info Request (if in RRC connected with respect to the base station) or a RACH procedure (if in RRC idle with respect to the base station) [paragraph 0065, 0072].)
Regarding claim 28, Wu discloses the requested system information is transmitted via the second RLC channel over the PC5 interface (see the independent claim, supra) and the relay UE is in an RRC CONNECTED state, and wherein the system information acquisition procedure further comprising transmitting a DedicatedSlBRequest message which indicates the system information requested by the remote UE to a base station, receiving one or more response messages including the requested system information from the base station and forwarding the requested system information to the remote UE, wherein the requested system information is transmitted via a second RLC channel over PC5 interface (Wu discloses that in case 2, the remote UE may be in an inactive/idle state with respect to the base station and a connected state with respect to the relay UE [i.e. the UE is in an idle state under the broadest reasonable interpretation as it is idle with respect to the base station] [fig. 11, element 1114; paragraph 0052 and 0064-0066]. Wu further discloses that in case 2, the relay UE may be in a RRC Connected state with respect to the base station [i.e. the claimed “RRC CONNECTED” state] [paragraphs 0065, 0072]. When the relay UE is in the RRC Connected state with respect to the base station it may request system information from the base station using RRC System Info Request and send a response to the remote UE [paragraph 0065, 0072]. As with all remote UE to relay UE transmissions, the response uses an RLC channel [paragraphs 0004, 0031, note also fig. 2A] which is a different/second RLC channel from the first/uplink RLC channel as it is on the downlink.)
Wu fails to disclose the second RLC channel is applied with a default or a specified configuration. In the same field of endeavor, Liu discloses the second RLC channel is applied with a default or a specified configuration. (Liu discloses that the remote UE may establish default configured channels for communication on UL and DL with the relay UE either for Uu forwarding by explicit configuration [paragraph 0131-0134; see also 343, page 22] or implicitly [paragraph 0144; see also 343, page 22-23].)
Therefore, since Liu discloses using default configurations for uplink and downlink RLC channels, it would have been obvious to a person of ordinary skill in the art at before the effective filing date of the invention to combine the RLC channels of Wu with the system of Liu by implementing the first uplink RLC channel using a default configuration and the second downlink RLC channel using a default configuration. The motive to combine is to simplify configuration by using a default configuration that does not require signaling overhead to configure.
Regarding claim 29, Wu discloses the relay UE is in an RRC IDLE state or in an RRC INACTIVE state, and wherein the system information acquisition procedure involves the relay UE performing a random access channel (RACH) procedure when the requested system information is provided by a base station on demand (Wu discloses that in case 2, the remote UE may be in an inactive/idle state with respect to the base station and a connected state with respect to the relay UE [i.e. the UE is in an idle state under the broadest reasonable interpretation as it is idle with respect to the base station] [fig. 11, element 1114; paragraph 0052 and 0064-0066]. Wu further discloses that in case 2, the relay UE may be in a RRC IDLE state with respect to the base station [i.e. the claimed “RRC IDLE” state] [paragraphs 0065, 0072]. When the relay UE is in the RRC IDLE state with respect to the base station it may request system information from the base station using a RCH procedure [paragraph 0065, 0072].)
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 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 at (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