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 .
Claim Status
Claims 1, 3-5, 8-9, 11-13, 15, 17, 21, 25, 31 and 33-34 are pending and claims 2, 6, 7, 10-12, 14, 16, 18-20, 22-24, 26-30 and 32 are canceled and claims 33-34 are newly added.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 13, 25 and 31 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rune et al. WO2019139525A1 (with pub. date 2019-07-18, translation provided for citation), hereinafter Rune.
Regarding claim 1, Rune teaches a system information transmission method, executed by a network- side device (network node 360/gNB), and comprising:
(Rune: para. [0093-0095 & 0092] Figure 3, network node 360 includes processing circuitry 370, device readable medium 380, interface 390, auxiliary equipment 384, power source 386, power circuitry 387, and antenna 362. network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions)
receiving a message 3 comprising a system information (SI) request (SI request included in Msg3) message
(Rune: Fig. 2 gNB receives Msg3 from UE, where msg3 includes SI request, and para. [0007] allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI)
on a second initial uplink (UL) (initial UL BWP) bandwidth part;
(Rune: para. [0011 & 0075] initial data exchange between the UE and the network, e.g. during the process of moving a UE from RRCJDLE or RRCJNACTIVE state to RRC_CONNECTED state, the initial DL BWP and initial UL BWP are configured in the minimum SI. para. [0012] BWP may only be configured for a UE in RRC_CONNECTED state, i.e. other than an initial BWP (one for UL and one for DL). Para. [0057 & 0080] wireless device has been notified of the upcoming SI update, the wireless device may be configured to receive the updated SI on physical resources outside of the BWP. In other words, the wireless device, whilst notified about the upcoming SI without having to leave the BWP may have to leave the BWP to receive the SI update)
sending configuration information, wherein the configuration information comprises first SI scheduling information (scheduling allocation on the PDCCH), and the first SI scheduling information (scheduling allocation on the PDCCH) is applied to configure transmission of an SI (remaining minimum SI (RMSI) using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure) on a first initial downlink (DL)
(Rune: Fig. 2 gNB sends Msg4 to UE, and para. [0007] After receiving the confirming Msg4, the UE monitors the downlink for the broadcast of the requested SI in accordance with the scheduling information for the requested SI, as indicated in the minimum SI (in SIB1). Para. [0008 & 0080 & 0069] base station broadcasts a certain SI message at some point within the SI window associated with the SI message. The UE can identify a SI message transmission from the scheduling allocation on the PDCCH, which is addressed to a for this purpose dedicated RNTI denoted SI-RNTI (i.e. the SI-RNTI is encoded into the CRC of the DCI carrying the scheduling allocation) It has also been decided to transmit a broadcast channel, denoted NR-PBCH (a.k.a. PBCH), following a periodic synchronization signal (for example, consisting of two parts NR-PSS and NR-SSS (a.k.a. PSS and SSS) from which the Physical Cell Identity (PCI) can be derived). Together, the NR-PSS+NR-SSS+NR-PBCH may form an entity denoted SS Block. Some of the minimum SI will be broadcast on the NR-PBCH, e.g. the denoted Master Information Block (MIB or NR-MIB), while the remaining minimum SI (RMSI) may be periodically broadcast on another channel, for example, using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure, i.e. with a scheduling allocation transmitted on the NR-PDCCH, allocating transmission resources on the NR-PDSCH, where the actual RMSI is transmitted. According to further agreements in 3GPP, information enabling a UE to receive the NR-PDCCH/NR- PDSCH carrying the RMSI may be transmitted on the NR-PBCH)
on a first initial downlink (DL) bandwidth part (another DL BWP); and sending the SI on the first initial downlink bandwidth part
(Rune: para. [0069] instruction to a wireless device may be a variant of the DCI (Downlink Control Information on the PDCCFI) instructing the wireless device to switch to another DL BWP. For instance, the instruction to read updated SI may be a parameter in such DCI. Para. [0008 & 0080 & 0069] base station broadcasts a certain SI message at some point within the SI window associated with the SI message. The UE can identify a SI message transmission from the scheduling allocation on the PDCCH, which is addressed to a for this purpose dedicated RNTI denoted SI-RNTI (i.e. the SI-RNTI is encoded into the CRC of the DCI carrying the scheduling allocation) It has also been decided to transmit a broadcast channel, denoted NR-PBCH (a.k.a. PBCH), following a periodic synchronization signal (for example, consisting of two parts NR-PSS and NR-SSS (a.k.a. PSS and SSS) from which the Physical Cell Identity (PCI) can be derived). Together, the NR-PSS+NR-SSS+NR-PBCH may form an entity denoted SS Block. Some of the minimum SI will be broadcast on the NR-PBCH, e.g. the denoted Master Information Block (MIB or NR-MIB), while the remaining minimum SI (RMSI) may be periodically broadcast on another channel, for example, using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure, i.e. with a scheduling allocation transmitted on the NR-PDCCH, allocating transmission resources on the NR-PDSCH, where the actual RMSI is transmitted. According to further agreements in 3GPP, information enabling a UE to receive the NR-PDCCH/NR- PDSCH carrying the RMSI may be transmitted on the NR-PBCH)
wherein the first initial downlink bandwidth part (another DL BWP/other than an initial BWP (one for UL and one for DL)) is a downlink bandwidth part in a first initial DL/UL bandwidth part, (Rune: para. [0069] instruction to a wireless device may be a variant of the DCI (Downlink Control Information on the PDCCFI) instructing the wireless device to switch to another DL BWP. For instance, the instruction to read updated SI may be a parameter in such DCI)
the second initial uplink bandwidth part is an uplink bandwidth part in a second initial DL/UL bandwidth part (initial BWP (one for UL and one for DL)), and the first initial DL/UL bandwidth part is different from the second initial DL/UL bandwidth part.
(Rune: para. [0012] BWP may only be configured for a UE in RRC_CONNECTED state, i.e. other than an initial BWP (one for UL and one for DL). Para. [0057 & 0080] wireless device has been notified of the upcoming SI update, the wireless device may be configured to receive the updated SI on physical resources outside of the BWP. In other words, the wireless device, whilst notified about the upcoming SI without having to leave the BWP may have to leave the BWP to receive the SI update)
Regarding claim 13, Rune teaches a system information transmission method, executed by a first type of terminal, and comprising:
(Rune: Figure 3 and para. [0108-0112] Processing circuitry 320 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other WD 310 components)
sending a message 3 comprising an SI request (SI request included in Msg3) message
(Rune: Fig. 2 gNB receives Msg3 from UE, where msg3 includes SI request, and para. [0007] allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI)
on a second initial uplink (UL) (initial UL BWP) bandwidth part; (Rune: para. [0011 & 0075] initial data exchange between the UE and the network, e.g. during the process of moving a UE from RRCJDLE or RRCJNACTIVE state to RRC_CONNECTED state, the initial DL BWP and initial UL BWP are configured in the minimum SI. para. [0012] BWP may only be configured for a UE in RRC_CONNECTED state, i.e. other than an initial BWP (one for UL and one for DL). Para. [0057 & 0080] wireless device has been notified of the upcoming SI update, the wireless device may be configured to receive the updated SI on physical resources outside of the BWP. In other words, the wireless device, whilst notified about the upcoming SI without having to leave the BWP may have to leave the BWP to receive the SI update)
receiving configuration information, wherein the configuration information comprises first SI scheduling information (scheduling allocation on the PDCCH), and the first SI scheduling information is applied to configure transmission of an SI (remaining minimum SI (RMSI) using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure) on a first initial downlink (DL) bandwidth part;
(Rune: Fig. 2 gNB sends Msg4 to UE, and para. [0007] After receiving the confirming Msg4, the UE monitors the downlink for the broadcast of the requested SI in accordance with the scheduling information for the requested SI, as indicated in the minimum SI (in SIB1). Para. [0008 & 0080 & 0069] base station broadcasts a certain SI message at some point within the SI window associated with the SI message. The UE can identify a SI message transmission from the scheduling allocation on the PDCCH, which is addressed to a for this purpose dedicated RNTI denoted SI-RNTI (i.e. the SI-RNTI is encoded into the CRC of the DCI carrying the scheduling allocation) It has also been decided to transmit a broadcast channel, denoted NR-PBCH (a.k.a. PBCH), following a periodic synchronization signal (for example, consisting of two parts NR-PSS and NR-SSS (a.k.a. PSS and SSS) from which the Physical Cell Identity (PCI) can be derived). Together, the NR-PSS+NR-SSS+NR-PBCH may form an entity denoted SS Block. Some of the minimum SI will be broadcast on the NR-PBCH, e.g. the denoted Master Information Block (MIB or NR-MIB), while the remaining minimum SI (RMSI) may be periodically broadcast on another channel, for example, using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure, i.e. with a scheduling allocation transmitted on the NR-PDCCH, allocating transmission resources on the NR-PDSCH, where the actual RMSI is transmitted. According to further agreements in 3GPP, information enabling a UE to receive the NR-PDCCH/NR- PDSCH carrying the RMSI may be transmitted on the NR-PBCH)
and
receiving the SI on the first initial downlink bandwidth part, (Rune: para. [0069] instruction to a wireless device may be a variant of the DCI (Downlink Control Information on the PDCCFI) instructing the wireless device to switch to another DL BWP. For instance, the instruction to read updated SI may be a parameter in such DCI. Para. [0008 & 0080 & 0069] base station broadcasts a certain SI message at some point within the SI window associated with the SI message. The UE can identify a SI message transmission from the scheduling allocation on the PDCCH, which is addressed to a for this purpose dedicated RNTI denoted SI-RNTI (i.e. the SI-RNTI is encoded into the CRC of the DCI carrying the scheduling allocation) It has also been decided to transmit a broadcast channel, denoted NR-PBCH (a.k.a. PBCH), following a periodic synchronization signal (for example, consisting of two parts NR-PSS and NR-SSS (a.k.a. PSS and SSS) from which the Physical Cell Identity (PCI) can be derived). Together, the NR-PSS+NR-SSS+NR-PBCH may form an entity denoted SS Block. Some of the minimum SI will be broadcast on the NR-PBCH, e.g. the denoted Master Information Block (MIB or NR-MIB), while the remaining minimum SI (RMSI) may be periodically broadcast on another channel, for example, using a NR-PDCCH/NR-PDSCH (a.k.a. PDCCH/PDSCH) structure, i.e. with a scheduling allocation transmitted on the NR-PDCCH, allocating transmission resources on the NR-PDSCH, where the actual RMSI is transmitted. According to further agreements in 3GPP, information enabling a UE to receive the NR-PDCCH/NR- PDSCH carrying the RMSI may be transmitted on the NR-PBCH)
wherein the first initial downlink bandwidth part (another DL BWP/other than an initial BWP (one for UL and one for DL)) is a downlink bandwidth part in a first initial DL/UL bandwidth part, (Rune: para. [0069] instruction to a wireless device may be a variant of the DCI (Downlink Control Information on the PDCCFI) instructing the wireless device to switch to another DL BWP. For instance, the instruction to read updated SI may be a parameter in such DCI)
the second initial uplink bandwidth part is an uplink bandwidth part in a second initial DL/UL bandwidth part (initial BWP (one for UL and one for DL)), and
the first initial DL/UL bandwidth part is different from the second initial DL/UL bandwidth part. (Rune: para. [0012] BWP may only be configured for a UE in RRC_CONNECTED state, i.e. other than an initial BWP (one for UL and one for DL). Para. [0057 & 0080] wireless device has been notified of the upcoming SI update, the wireless device may be configured to receive the updated SI on physical resources outside of the BWP. In other words, the wireless device, whilst notified about the upcoming SI without having to leave the BWP may have to leave the BWP to receive the SI update)
Regarding claim 25, Rune teaches all the limitations as discussed in the rejection of claim 1, and therefore system claim 25 is rejected using the same rationales.
Regarding claim 31, Rune teaches a non-transitory computer-readable storage medium, configured for storing instructions thereon, wherein when executed by a processor, the instructions perform a method according to claim 1. (Rune: para. [0093-0095 & 0092] Figure 3, network node 360 includes processing circuitry 370, device readable medium 380, interface 390, auxiliary equipment 384, power source 386, power circuitry 387, and antenna 362. network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions)
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.
Claim(s) 3 – 5, 8 – 9, 15, 17, 21 and 33 – 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rune in view of Chien US 20220377798 A1, hereinafter Chien.
Regarding claim 3, Rune teaches the method according to claim 1, wherein sending the SI on the first initial downlink bandwidth part comprises: in response to receiving the message 3 comprising the SI request message
(Rune: Fig. 2 gNB receives Msg3 from UE, where msg3 includes SI request, and para. [0007] allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI)
Rune does not explicitly teach: message sent by a first type of terminal using a first specific physical random access channel (PRACH) resource, sending the SI on the first initial downlink bandwidth part; wherein the first specific PRACH resource used by the first type of terminal is different from a second specific PRACH resource used by a second type of terminal; a terminal capability of the first type of terminal is different from a terminal capability of the second type of terminal.
However, Chien from the same or similar fields of endeavor teaches the use of:
message sent by a first type (RedCap/extended UE) of terminal using a first specific physical random access channel (PRACH) resource (PRACH resources for RedCap/extended UE), sending the message on the first initial downlink bandwidth part; (Chien: para. [0043 & 0062] device type related information may comprise a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP for the extended device type UE. para. [0065] RedCap UE may implicitly provide device type related information, using a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP. A UE (e.g., the lower complexity RedCap UE) with bandwidth less than 20 MHz may need the predefined initial DL/UL BWP for RedCap UE.)
wherein the first specific PRACH resource used by the first type of terminal is different from the second specific PRACH resource used by a second type of terminal;
(Chien: para. [0244] gNB, may configure one or more of the initial UL BWP, the preamble sequence, and the PRACH resources to differentiate the RedCap UE from the legacy UE. para. [0237] separated PRACH resources dedicated to the RedCap UE other than PRACH resources for the legacy UE)
a terminal capability of the first type of terminal is different from a terminal capability of the second type of terminal; (Chien: para. [0043] extended device type UE comprises a reduced capability user equipment (RedCap UE). The device type related information may explicitly comprise a UE identity, a device type, or a UE capability of the extended device type UE. para. [0041 & 0037] extended UE type may comprise a device type of reduced capability (RedCap) UE. The device type of RedCap UE type may be referred to as RedCap UE. The legacy UE type may be referred to as legacy UE.). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claim 4, Rune and Chien teach the method according to claim 3, Rune does not explicitly teaches: wherein the first specific PRACH resource comprises at least one of: a specific preamble; a specific PRACH transmission opportunity; a specific frequency resource; or a specific initial uplink bandwidth part.
However, Chien from the same or similar fields of endeavor teaches the use of: wherein the first specific PRACH resource comprises at least one of: a specific preamble; (Chien: para. [0043] device type related information may comprise a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP for the extended device type UE)
a specific PRACH transmission opportunity; a specific frequency resource; (Chien: para. [0143] restricted PRACH resources are restricted time-frequency radio resources wherein PRACH preamble and signals can be transmitted for the RedCap UE)
or
a specific initial uplink bandwidth part. (Chien: para. [0043 & 0062-0072] device type related information may comprise a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP for the extended device type UE) Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claim 5, Rune and Chien teach the method according to claim 3, Rune does not explicitly teach: further comprising: sending first configuration information, wherein the first configuration information comprises at least one of the first specific PRACH resource or the second specific PRACH resource.
However, Chien from the same or similar fields of endeavor teaches the use of: further comprising: sending first configuration information, wherein the first configuration information comprises at least one of the first specific PRACH resource (Chien: para. 0138-0143 & 0223-0227] restricted preamble is a RedCap UE specific PRACH preamble and may comprise a restricted preamble sequence or a preamble format for the RedCap UE. The restricted PRACH resources are restricted time-frequency radio resources wherein PRACH preamble and signals can be transmitted for the RedCap UE) or the second specific PRACH resource (Chien: para. [0244] gNB, may configure one or more of the initial UL BWP, the preamble sequence, and the PRACH resources to differentiate the RedCap UE from the legacy UE. para. [0237] separated PRACH resources dedicated to the RedCap UE other than PRACH resources for the legacy UE). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claim 8, Rune teaches the method according to claim 1, wherein the message 3 comprises the SI request message (Rune: Fig. 2 gNB receives Msg3 from UE, where msg3 includes SI request, and para. [0007] allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI), and Rune does not explicitly teach: wherein the message 3 comprises an information field.
However, Chien from the same or similar fields of endeavor teaches the use of: wherein the message 3 comprises an information field. (Chien: para. [0258] extended device type UE may transmit msg3 a message based on configuration in received RAR, and the device type related information of the extended device type UE is included in the msg3 message. The RedCap UE transmit msg3 based on the configuration in received RAR. The RedCap UE can include the device type of the RedCap UE in the msg3 message) Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claim 9, Rune teaches the method according to claim 1, further comprising: receiving a random access request message of terminal (Rune: para. [0007] With the Msg3 solution the request procedure begins like a regular random access procedure - i.e. the UE transmits one of the regular (non-dedicated) preambles in Msg1 and receives a regular Msg2 in response, where the Msg2, as any regular Msg2, allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI. The network, e.g. the gNB also transmits a Msg4 confirming the successful reception of the Msg3 and confirming that the requested SI will be broadcast) on the second initial uplink bandwidth part (Rune: para. [0011 & 0075] initial data exchange between the UE and the network, e.g. during the process of moving a UE from RRCJDLE or RRCJNACTIVE state to RRC_CONNECTED state, the initial DL BWP and initial UL BWP are configured in the minimum SI.
Rune does not explicitly teach: further comprising: receiving a random access request message of the first type of terminal.
However, Chien from the same or similar fields of endeavor teaches the use of: further comprising: receiving a random access request message of the first type of terminal. (Chien: para. [0043 & 0062] device type related information may comprise a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP for the extended device type UE. para. [0065] RedCap UE may implicitly provide device type related information, using a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP. A UE (e.g., the lower complexity RedCap UE) with bandwidth less than 20 MHz may need the predefined initial DL/UL BWP for RedCap UE.) Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claim 33, Rune teaches the method according to claim 1, wherein the first SI scheduling information indicates that the SI request message (Rune: Fig. 2 gNB receives Msg3 from UE, where msg3 includes SI request, and para. [0007] allocates uplink transmission resources for transmission of Msg3, as well as provides a timing advance indication to enable the UE to transmit Msg3 with correct timing. The SI request included in Msg3 triggers the network to broadcast/transmit the parts of the other SI that are specified in the Msg3 from the UE in accordance with scheduling information in the minimum SI) is sent on the second initial uplink (initial UL BWP) bandwidth part (Rune: para. [0011 & 0075] initial data exchange between the UE and the network, e.g. during the process of moving a UE from RRCJDLE or RRCJNACTIVE state to RRC_CONNECTED state, the initial DL BWP and initial UL BWP are configured in the minimum SI. para. [0012] BWP may only be configured for a UE in RRC_CONNECTED state, i.e. other than an initial BWP (one for UL and one for DL). Para. [0057 & 0080] wireless device has been notified of the upcoming SI update, the wireless device may be configured to receive the updated SI on physical resources outside of the BWP. In other words, the wireless device, whilst notified about the upcoming SI without having to leave the BWP may have to leave the BWP to receive the SI update)
Rune does not explicitly teach: or message is sent on a first specific PRACH resource; wherein the first specific PRACH resource used by a first type of terminal is different from a second specific PRACH resource used by a second type of terminal.
However, Chien from the same or similar fields of endeavor teaches the use of:
message sent on a first specific PRACH resource (PRACH resources for RedCap/extended UE); (Chien: para. [0043 & 0062] device type related information may comprise a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP for the extended device type UE. para. [0065] RedCap UE may implicitly provide device type related information, using a predefined preamble, predefined physical random access channel (PRACH) resources, a predefined initial DL or UL BWP. A UE (e.g., the lower complexity RedCap UE) with bandwidth less than 20 MHz may need the predefined initial DL/UL BWP for RedCap UE.)
wherein the first specific PRACH resource used by the first type of terminal is different from the second specific PRACH resource used by a second type of terminal;
(Chien: para. [0244] gNB, may configure one or more of the initial UL BWP, the preamble sequence, and the PRACH resources to differentiate the RedCap UE from the legacy UE. para. [0237] separated PRACH resources dedicated to the RedCap UE other than PRACH resources for the legacy UE). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of Chien in the method of Rune. One of ordinary skill in the art would be motivated to do so for provides advantageous effects of maintaining coexistence performance for NR RedCap UEs and NR legacy UEs, and allows operators to restrict NR RedCap UE's access, ensure NR RedCap UE types are only used for the intended use cases, and reduce NR RedCap UE power consumption due to unnecessary cell access. The network can distinguish RedCap UE from non-RedCap UE and performs relaxed scheduling and DL/UL data transmission during cell access and random-access procedure for RedCap UEs (Chien: para. [0025]).
Regarding claims 15, 17, 21 and 34, Rune and Chien teach all the limitations as discussed in the rejection of claims 3, 5, 9 and 33, and therefore system claims 15, 17, 21 and 34 are rejected using the same rationales.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-5, 8-9, 11-13, 15, 17, 21, 25, 31 and 33-34 have been considered but are 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please also see PTO-892.
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 WUTCHUNG CHU whose telephone number is (571)272-4064. The examiner can normally be reached 10:00 AM - 4:00 PM.
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, Moo R Jeong can be reached at (571) 272-9617. 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.
/WUTCHUNG CHU/Primary Examiner, Art Unit 2418
Prosecution Insights