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 This is in response to an amendment/response/communication filed 8/11/2025. No claims have been cancelled. No claims have been added. Claims(s) 1-20 is/are currently pending. Information Disclosure Statement The information disclosure statement(s) (IDS(s)) submitted on 8/11/2025is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner. Reference designations were not included for Non-Patent Literature Documents citations #1 and #2 on the IDS dated 2025-08-11. The Examiner has included the reference designations on the PTO-802. Drawings The drawings were received on 4/5/2024. These drawings are accepted. Specification The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification. 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 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. Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang et al., “PRACH Resource Indication Methods, Apparatus, Terminal and Network Side Device”, 2025-08-14, WO, WO 2025167921 (citations are from English translation) in view of Moon et al., “Random Access Method and Apparatus for Low Power Communication”, 2025-10-02, WO, WO 2025206670 (citations are from English translation) . As to claim 1: Jiang et al. discloses: An apparatus configured for wireless communications, comprising: one or more memories; and one or more processors coupled to the one or more memories and configured to cause the apparatus to: receive, from a network entity, a first message comprising physical random access channel (PRACH) adaptation information, the PRACH adaptation information comprising: (“Network-side devices can configure resources through RRC or SIB. Network-side devices can activate or deactivate dynamic PRACH resource configuration through paging messages, SIB, RRC release/RRC setup, DCI/MAC CE, and other messages.”; Jiang et al.; p.14, top of page) (“In one specific embodiment, PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO, and the frequency domain starting position and frequency domain length of the dynamically adjusted resources are the same as those of the legacy RO. As shown in Figure 9, blue represents legacy RACH resources, and red represents RACH resources that can be dynamically activated or deactivated (applicable to UEs), which can be named separate PRACH resources or dynamic PRACH resources. The configuration method of the PRACH resource that is allowed to be dynamically activated includes at least one of the following: Configuration method (1): The RA partition configuration method is not used. Configure rach-ConfigCommonForNES in the bandwidth part uplink common configuration (BWP- UplinkCommon ) in the following ways: Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following: The period (y) of PRACH resources (red) allowed to be dynamically activated within a single legacy PRACH resource period (x); The number of PRACH resource clusters (e.g., 3 clusters in Figure 9) or the number of occasions (e.g., 6 occasions per cluster in the figure) that can be dynamically activated within a single legacy PRACH resource period (x) is defined as follows: The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x) (i.e., the period ratio relationship). For example, in Figure 9, x = 4, 1/Q = 1/4; The time interval (y) between multiple PRACH resources (red) allowed to be dynamically activated; The time interval (z) between the first PRACH resource allowed to be dynamically activated and the first legacy PRACH resource in each cycle, and the number of PRACH resources and/or PRACH opportunities allowed to be dynamically activated. The above-mentioned method 2 can reduce the configuration parameters and save the configuration overhead of SIB1. The units of the above-mentioned period include: system frame, subframe, ms , slot, symbol, etc. The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later. Configuration method (2): Use the same configuration method as for RA partition and configure rach-ConfigCommonForNES in additionalRACH-ConfigCommonList .”; Jiang et al.; p.22, bottom of page through top of page 23) ( where “Network-side devices can configure resources through RRC or SIB”/” PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO”/”The configuration method of the PRACH resource that is allowed to be dynamically activated includes at least one of the following:”/” Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following:” maps to “receive, from a network entity, a message comprising physical random access channel (PRACH) adaptation information, the PRACH adaptation information comprising” , where “Network-side devices…through RRC or SIB” maps to “receive, from a network entity” , “RRC or SIB” maps to “message” , “PRACH resource adaptation is performed, and the dynamically adjusted resources”/”configure resources”/”configuration method…PRACH resource that is allowed to be dynamically activated” maps to “comprising physical random access channel (PRACH) adaptation information, the PRACH adaptation information” , where the “dynamically activated resource” is associated with “PRACH resource adaption” maps to “comprising physical random access channel (PRACH) adaptation” , where “Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following:” maps to “information” /”information comprising:” a first PRACH configuration; ( where (“The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later”; Jiang et al.; p.23, middle of page) “Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols” /”The resources configured by rach-ConfigCommonForNES …or they are activated by default” maps to “a default PRACH configuration” , where “ rach -Config Common”/”resource configured by rach-ConfigCommonForNES ” maps to “a default configuration” an indication of an activation … for PRACH adaptation, wherein the indication of the activation … for PRACH adaptation indicates activation or deactivation of one or … PRACH adaptations; and (“The embodiments of the present application provide a PRACH resource indication method, apparatus, terminal, and network-side equipment, which can achieve network energy saving and flexible activation or deactivation of PRACH resources.”; Jiang et al.; p.2, middle of page) (“In this embodiment, the network side device can first configure fewer PRACH resources to save power. When there are more random access requests or a large number of terminals, the second resource is activated to alleviate the probability of random access collision. This can not only achieve network energy saving, but also activate or deactivate PRACH resources.”; Jiang et al.; p.15, lower/middle of page) ( where “ provide a PRACH resource indication method, apparatus, terminal, and network-side equipment, which can achieve network energy saving and flexible activation or deactivation of PRACH resources” perform a random access channel (RACH) procedure based on the PRACH adaptation information. (“The period (y) of PRACH resources (red) allowed to be dynamically activated within a single legacy PRACH resource period (x); The number of PRACH resource clusters (e.g., 3 clusters in Figure 9) or the number of occasions (e.g., 6 occasions per cluster in the figure) that can be dynamically activated within a single legacy PRACH resource period (x) is defined as follows: The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x) (i.e., the period ratio relationship). For example, in Figure 9, x = 4, 1/Q = 1/4; The time interval (y) between multiple PRACH resources (red) allowed to be dynamically activated;”; Jiang et al; p.23, top of page) ( where “number of PRACH resource clusters (e.g. 3 clusters in Figure 9) or the number of occasions”/”the first indication information indicates at least one of the following:”/”activating or deactivating part of the second resource“/Figure 9 maps to “perform one or more random access channel (RACH) in accordance with the indication of the activation” , “The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x)”/Figure 9 maps to “for PRACH adaptation prior to the time period elapsing” , where “period of PRACH resources allowed to be dynamically activated is 1/Q” maps to “time period” , Figure 9 illustrates “prior to the time period elapsing” Jiang et al. teaches configuration of PRACH resource adaptation for dynamically adjusted secondary resources for reducing energy consumption, where the secondary resources can be activated/deactivated as needed, where the configuration of the PRACH resource adaptation is performed via override parameters in an updated SIB, where the parameters included PRACH period. Jiang et al. as described above does not explicitly teach: [ activation] state However, Moon et al. further teaches a state/adaptation capability which includes: [ activation] state (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) ( where “PRACH adaptation indication” /”activate a PRACH resource that is in an active or inactive state” Moon et al. teaches activation of PRACH resources associated with PRACH adaption. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 2: Jiang et al. discloses: wherein the PRACH adaptation information further comprises: a plurality of PRACH adaptation configurations; and an indication of an active PRACH adaptation configuration of the plurality of PRACH adaptation configurations. (see FIG. 9 and FIG. 10) As to claim 3: Jiang et al. discloses: the PRACH adaptation information further comprises one or more additional PRACH configurations; and the one or more processors are configured to cause the apparatus to perform the RACH procedure using a PRACH configuration of the one or more additional PRACH configurations based at least in part on the indication of the activation … for PRACH adaptation. (“In one specific embodiment, PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO, and the frequency domain starting position and frequency domain length of the dynamically adjusted resources are the same as those of the legacy RO. As shown in Figure 9, blue represents legacy RACH resources, and red represents RACH resources that can be dynamically activated or deactivated (applicable to UEs), which can be named separate PRACH resources or dynamic PRACH resources. The configuration method of the PRACH resource that is allowed to be dynamically activated includes at least one of the following: Configuration method (1): The RA partition configuration method is not used. Configure rach-ConfigCommonForNES in the bandwidth part uplink common configuration (BWP- UplinkCommon ) in the following ways: Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following: The period (y) of PRACH resources (red) allowed to be dynamically activated within a single legacy PRACH resource period (x); The number of PRACH resource clusters (e.g., 3 clusters in Figure 9) or the number of occasions (e.g., 6 occasions per cluster in the figure) that can be dynamically activated within a single legacy PRACH resource period (x) is defined as follows: The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x) (i.e., the period ratio relationship). For example, in Figure 9, x = 4, 1/Q = 1/4; The time interval (y) between multiple PRACH resources (red) allowed to be dynamically activated; The time interval (z) between the first PRACH resource allowed to be dynamically activated and the first legacy PRACH resource in each cycle, and the number of PRACH resources and/or PRACH opportunities allowed to be dynamically activated. The above-mentioned method 2 can reduce the configuration parameters and save the configuration overhead of SIB1. The units of the above-mentioned period include: system frame, subframe, ms , slot, symbol, etc. The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later. Configuration method (2): Use the same configuration method as for RA partition and configure rach-ConfigCommonForNES in additionalRACH-ConfigCommonList .”; Jiang et al.; p.22, bottom of page through top of page 23) Jiang et al. as described above does not explicitly teach: [ activation] state However, Moon et al. further teaches a state/adaptation capability which includes: [ activation] state (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) ( where “PRACH adaptation indication” /”activate a PRACH resource that is in an active or inactive state” Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 4: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to receive, from the network entity, a selection parameter indicating the PRACH configuration of the one or more additional PRACH configurations. (“When the network side device wants to adjust the period of PRACH resources, it can update the RACH configuration (including parameters such as PRACH configuration index) through SIB1, but the update speed of SIB1 is too slow and the sending overhead is large. One way is to reduce the configuration parameters in the SIB, and only reconfigure the override parameters in the updated SIB (for example, only reconfigure the PRACH period parameters) to reduce SIB overhead; another way is to update the RACH configuration through other messages instead of SIB messages. For example, for idle UE, the network side device can update the RACH configuration by sending a paging message. For connected UE, the network side device can update the RACH configuration through DCI/MAC CE, which only carries the updated PRACH period (PRACH configuration index), or activate a target RACH configuration among multiple RACH configurations, so as to indicate the identifier of the target RACH configuration, or configure the first resource and the second resource through the first configuration information. When the second resource needs to be activated, the first indication information indicates the activation of the second resource.”; Jiang et al.; p.14, top of page) As to claim 5: Jiang et al. discloses: the PRACH adaptation information further comprises one or more PRACH adaptation parameters for the first PRACH configuration; and the one or more processors are configured to cause the apparatus to apply the one or more PRACH adaptation parameters to the first PRACH configuration based at least in part on the indication of the activation … for PRACH adaptation. (“When the UE receives an activation indication from the network-side device, the UE may apply the parameters of rach-ConfigCommonForNES to determine the RACH resources. For parameters not configured, the UE applies the corresponding parameters indicated in RACH- ConfigCommon or MsgA-ConfigCommon .”; Jiang et al.; p.24, middle of page) Jiang et al. as described above does not explicitly teach: [ activation] state However, Moon et al. further teaches a state/adaptation capability which includes: [ activation] state (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) ( where “PRACH adaptation indication” /”activate a PRACH resource that is in an active or inactive state” Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 6: Jiang et al. discloses: the first PRACH configuration comprises a plurality of occasions for performing the RACH procedure; and the one or more PRACH adaptation parameters comprise a periodicity of the plurality of occasions, a number of occasions configured for the plurality of occasions… (“Network-side devices can configure resources through RRC or SIB. Network-side devices can activate or deactivate dynamic PRACH resource configuration through paging messages, SIB, RRC release/RRC setup, DCI/MAC CE, and other messages.”; Jiang et al.; p.14, top of page) (“In one specific embodiment, PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO, and the frequency domain starting position and frequency domain length of the dynamically adjusted resources are the same as those of the legacy RO. As shown in Figure 9, blue represents legacy RACH resources, and red represents RACH resources that can be dynamically activated or deactivated (applicable to UEs), which can be named separate PRACH resources or dynamic PRACH resources. The configuration method of the PRACH resource that is allowed to be dynamically activated includes at least one of the following: Configuration method (1): The RA partition configuration method is not used. Configure rach-ConfigCommonForNES in the bandwidth part uplink common configuration (BWP- UplinkCommon ) in the following ways: Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following: The period (y) of PRACH resources (red) allowed to be dynamically activated within a single legacy PRACH resource period (x); The number of PRACH resource clusters (e.g., 3 clusters in Figure 9) or the number of occasions (e.g., 6 occasions per cluster in the figure) that can be dynamically activated within a single legacy PRACH resource period (x) is defined as follows: The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x) (i.e., the period ratio relationship). For example, in Figure 9, x = 4, 1/Q = 1/4; The time interval (y) between multiple PRACH resources (red) allowed to be dynamically activated; The time interval (z) between the first PRACH resource allowed to be dynamically activated and the first legacy PRACH resource in each cycle, and the number of PRACH resources and/or PRACH opportunities allowed to be dynamically activated. The above-mentioned method 2 can reduce the configuration parameters and save the configuration overhead of SIB1. The units of the above-mentioned period include: system frame, subframe, ms , slot, symbol, etc. The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later. Configuration method (2): Use the same configuration method as for RA partition and configure rach-ConfigCommonForNES in additionalRACH-ConfigCommonList .”; Jiang et al.; p.22, bottom of page through top of page 23) (see FIG. 9) As to claim 7: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to receive, from the network entity, an additional message comprising an indication of a time period for which the indication of the activation … for PRACH adaptation is valid. (“The unit of the period and/or the time interval includes at least one of the following: a radio frame, a half frame, a subframe, a time slot, a millisecond, a PRACH period, a PRACH time slot, a PRACH opportunity, a PRACH association period, and a PRACH association pattern period. In this embodiment, the number of PRACH slots or ROs of the second resource can be independently configured. In some embodiments, the first indication information indicates at least one of the following:… Activate or deactivate all second resources, where the second resources include time-frequency resources, preamble sequence resources, etc.; activating or deactivating part of the second resource a validity period for activating or deactivating all or part of the second resource;”; Jiang et al.; p.12, top of page) (“When the network side device wants to adjust the period of PRACH resources, it can update the RACH configuration (including parameters such as PRACH configuration index) through SIB1, but the update speed of SIB1 is too slow and the sending overhead is large. One way is to reduce the configuration parameters in the SIB, and only reconfigure the override parameters in the updated SIB (for example, only reconfigure the PRACH period parameters) to reduce SIB overhead”; Jiang et al.; p.14, top of page) Jiang et al. as described above does not explicitly teach: [ activation] state However, Moon et al. further teaches a state/adaptation capability which includes: [ activation] state (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) ( where “PRACH adaptation indication” /”activate a PRACH resource that is in an active or inactive state” Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 8: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to receive, from the network entity, a system information update message indicating one or more updates have been made to a system information message, wherein the time period is shortened based at least in part on receiving the system information update message. (“When the network side device wants to adjust the period of PRACH resources, it can update the RACH configuration (including parameters such as PRACH configuration index) through SIB1, but the update speed of SIB1 is too slow and the sending overhead is large. One way is to reduce the configuration parameters in the SIB, and only reconfigure the override parameters in the updated SIB (for example, only reconfigure the PRACH period parameters) to reduce SIB overhead”; Jiang et al.; p.14, top of page) (“In an embodiment of the present application, the terminal can determine the target PRACH resource from the candidate PRACH resources based on the first configuration information and the first indication information of the network-side device. The network-side device adjusts the PRACH resources to adjust which resources the terminal initiates the random access process on, thereby changing the number and time of detections and adjusting the sleep time to save energy on the network side.…”; Jiang et al.; p.4, top of page) As to claim 9: Jiang et al. discloses: wherein the PRACH adaptation information further comprises a default PRACH configuration. (“The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later”; Jiang et al.; p.23, middle of page) As to claim 10: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to perform the RACH procedure using the default PRACH configuration based on performing an initial access procedure… (“The second resource can be called an additional PRACH resource, a separate PRACH resource, or a dynamic PRACH resource. In this embodiment, the network-side device can initially configure fewer PRACH resources to save power. When there are a large number of random access requests or a large number of terminals, the second resource is activated to mitigate the probability of random access collisions. This achieves network energy conservation and solves the problem of insufficient RACH resources.”; Jiang et al.; p.8, bottom of page) As to claim 11: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to receive, from the network entity, a selection parameter indicating for the apparatus to perform the RACH procedure using the first PRACH configuration, the first PRACH configuration with the one or more PRACH adaptations applied, or… (“In some embodiments, when the time domain resource configuration and frequency domain resource configuration of the second resource only include some parameters of RACH- ConfigCommon , other parameters used to determine the second resource are determined by the time domain resource configuration and/or frequency domain resource configuration of the first resource.”; Jiang et al.; p.10, bottom of page) As to claim 12: Jiang et al. discloses: the indication of the activation state for PRACH adaptation in the first message indicates deactivation of the one or … PRACH adaptations; and the one or more processors are configured to cause the apparatus to: receive, from the network entity, an indication of an adaptation to the first PRACH configuration after receiving the message; apply the adaptation to the first PRACH configuration based at least in part on receiving the indication; and receive, from the network entity, a second message comprising the PRACH adaptation information, wherein the indication of the activation … for PRACH adaptation in the second message indicates activation of the one or … PRACH adaptations. (“Network-side devices can configure resources through RRC or SIB. Network-side devices can activate or deactivate dynamic PRACH resource configuration through paging messages, SIB, RRC release/RRC setup, DCI/MAC CE, and other messages.”; Jiang et al.; p.14, top of page) (“In one specific embodiment, PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO, and the frequency domain starting position and frequency domain length of the dynamically adjusted resources are the same as those of the legacy RO. As shown in Figure 9, blue represents legacy RACH resources, and red represents RACH resources that can be dynamically activated or deactivated (applicable to UEs), which can be named separate PRACH resources or dynamic PRACH resources. The configuration method of the PRACH resource that is allowed to be dynamically activated includes at least one of the following: Configuration method (1): The RA partition configuration method is not used. Configure rach-ConfigCommonForNES in the bandwidth part uplink common configuration (BWP- UplinkCommon ) in the following ways: Method 1: rach-ConfigCommonForNES can be a complete set of RACH time and frequency resource configurations, including all parameters included in rach-ConfigCommon in existing protocols; Method 2: rach-ConfigCommonForNES can indicate only some parameters, such as at least one of the following: The period (y) of PRACH resources (red) allowed to be dynamically activated within a single legacy PRACH resource period (x); The number of PRACH resource clusters (e.g., 3 clusters in Figure 9) or the number of occasions (e.g., 6 occasions per cluster in the figure) that can be dynamically activated within a single legacy PRACH resource period (x) is defined as follows: The period of PRACH resources allowed to be dynamically activated is 1/Q of a single legacy PRACH resource period (x) (i.e., the period ratio relationship). For example, in Figure 9, x = 4, 1/Q = 1/4; The time interval (y) between multiple PRACH resources (red) allowed to be dynamically activated; The time interval (z) between the first PRACH resource allowed to be dynamically activated and the first legacy PRACH resource in each cycle, and the number of PRACH resources and/or PRACH opportunities allowed to be dynamically activated. The above-mentioned method 2 can reduce the configuration parameters and save the configuration overhead of SIB1. The units of the above-mentioned period include: system frame, subframe, ms , slot, symbol, etc. The resources configured by rach-ConfigCommonForNES are not activated by default and are subsequently activated by the network-side device; or they are activated by default and can be deactivated by instructions from the network-side device later. Configuration method (2): Use the same configuration method as for RA partition and configure rach-ConfigCommonForNES in additionalRACH-ConfigCommonList .”; Jiang et al.; p.22, bottom of page through top of page 23) However, Moon et al. further teaches a state/adaptation capability which includes: [ activation] state (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) ( where “PRACH adaptation indication” /”activate a PRACH resource that is in an active or inactive state” Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 13: Jiang et al. discloses: wherein the one or more processors are configured to cause the apparatus to receive the indication of the adaptation via one or more of: a downlink control information (DCI) message, a medium access control (MAC) control element (CE), and… (“When the network side device wants to adjust the period of PRACH resources, it can update the RACH configuration (including parameters such as PRACH configuration index) through SIB1, but the update speed of SIB1 is too slow and the sending overhead is large. One way is to reduce the configuration parameters in the SIB, and only reconfigure the override parameters in the updated SIB (for example, only reconfigure the PRACH period parameters) to reduce SIB overhead; another way is to update the RACH configuration through other messages instead of SIB messages. For example, for idle UE, the network side device can update the RACH configuration by sending a paging message. For connected UE, the network side device can update the RACH configuration through DCI/MAC CE, which only carries the updated PRACH period (PRACH configuration index), or activate a target RACH configuration among multiple RACH configurations, so as to indicate the identifier of the target RACH configuration, or configure the first resource and the second resource through the first configuration information. When the second resource needs to be activated, the first indication information indicates the activation of the second resource.”; Jiang et al.; p.14, top of page) As to claim 14: Jiang et al. as described above does not explicitly teach: wherein the one or more processors are configured to cause the apparatus to not expect to receive a paging message if the indication of the activation state for PRACH adaptation is changed. However, Moon et al. further teaches a state/adaptation capability which includes: wherein the one or more processors are configured to cause the apparatus to not expect to receive a paging message if the indication of the activation state for PRACH adaptation is changed. (“The configuration information of the first PRACH resource and the configuration information of the second PRACH resource may be included in the system information and received.”; Moon et al.; p.2, middle of page) (“In one embodiment, a terminal may be instructed to either activate or deactivate a PRACH resource via DCI. In other words, the terminal may be instructed via DCI to either enable or disable a PRACH resource. If it is instructed to activate a PRACH resource that is in an active or inactive state, the PRACH resource may be maintained in an activated state until a predetermined condition is satisfied. The predetermined condition may include the terminal receiving a DCI instructing to deactivate the PRACH resource, the bandwidth portion (e.g., a UL bandwidth portion) for which the PRACH resource is configured being deactivated or released, the carrier for which the PRACH resource is configured being deactivated or released, the PRACH resource being released by an RRC configuration or an RRC reset, etc. If it is instructed to deactivate a PRACH resource that is in an inactive or active state, the PRACH resource may be maintained in an inactive state until a predetermined condition is satisfied. The above-described conditions may include the terminal receiving a DCI instructing the terminal to activate the PRACH resource, the bandwidth portion (e.g., the UL bandwidth portion) for which the PRACH resource is set being deactivated or released, the carrier for which the PRACH resource is set being deactivated or released, the PRACH resource being released by RRC configuration or RRC reset, etc.”; Moon et al.; p.24, top of page) (“…Alternatively, if the DCI includes activation/deactivation indication information of PRACH resources, the DCI may not include the other information listed above. That is, the DCI may be transmitted only for the purpose of PRACH adaptation indication….; Moon et al.; p.26, top of page) Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the state/adaptation capability of Moon et al. into Jiang et al. By modifying the processing/communications of Jiang et al. to include the state/adaptation capability as taught by the processing/communications of Moon et al., the benefits of reduced collisions (Jiang et al.; p.4, top of page) with improved efficiency (Moon et al.; p.14, middle of page) are achieved. As to claim 15: Jiang et al. discloses: wherein the first message comprises one or more of: a system information message and… (“Network-side devices can configure resources through RRC or SIB. Network-side devices can activate or deactivate dynamic PRACH resource configuration through paging messages, SIB, RRC release/RRC setup, DCI/MAC CE, and other messages.”; Jiang et al.; p.14, top of page) (“When the network side device wants to adjust the period of PRACH resources, it can update the RACH configuration (including parameters such as PRACH configuration index) through SIB1, but the update speed of SIB1 is too slow and the sending overhead is large. One way is to reduce the configuration parameters in the SIB, and only reconfigure the override parameters in the updated SIB (for example, only reconfigure the PRACH period parameters) to reduce SIB overhead”; Jiang et al.; p.14, top of page) As to claim 16: Jiang et al. discloses: An apparatus configured for wireless communications, comprising: one or more memories; and one or more processors coupled to the one or more memories and configured to cause the apparatus to: receive, from a network entity, a message comprising physical random access channel (PRACH) adaptation information, the PRACH adaptation information comprising: (“Network-side devices can configure resources through RRC or SIB. Network-side devices can activate or deactivate dynamic PRACH resource configuration through paging messages, SIB, RRC release/RRC setup, DCI/MAC CE, and other messages.”; Jiang et al.; p.14, top of page) (“In one specific embodiment, PRACH resource adaptation is performed, and the dynamically adjusted resources (secondary resources and/or separate RO and/or dynamic RO) are not allowed to overlap with the legacy RO, and the frequency domain starting position and frequency domain length of the dynamically adjusted resources are the same as those of the legacy RO. As shown in Figure 9, blue represents legacy RACH resources, and red represents RACH resources that can be dynamically activated or deactivated (applicable to UEs), which can be named separate PRACH resources or dynamic PRACH