CTNF 18/718,034 CTNF 100819 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Priority Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in Application No. 18/718,034, filed on June 8, 2024. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. It is also noted that the present application is a 371 National Phase Patent Application of PCT/JP2022/038285, for which the 371(c) filing date is October 14, 2022. Information Disclosure Statement The information disclosure statement (IDS) submitted on 06/08/2024 has been considered by examiner and made of record in the application file. Preliminary Amendments Claims 5, and 10-11 amendments are acknowledged. Claims 1-15 are pending in the present application. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 07-30-05 The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: Claim 1, line 2, “a terminal communicator configured to perform radio communication” corresponding structure is the antenna (Specification, Fig.2: Antenna, paragraph [0035]) . Claim 1, line 4, “a terminal controller configured to control the terminal communicator” corresponding structure is the processor (Specification, Fig.2: Processor, paragraph [0038]) . Claim 2, line 2, “the terminal controller” corresponding structure is the processor (Specification, Fig.2: Processor, paragraph [0038]) . Claim 3, line 2-4, “a terminal operation unit…the terminal operation unit transmits” corresponding structure is icon displayed on a touch pad or a switch (Specification, Fig.2: Switch, etc., paragraph [0036], “an icon displayed on a touch pad”) . Claim 6, line 2, “a base communicator configured to perform radio communication” corresponding structure is the antenna (Specification, Fig.2: Antenna, paragraph [0044]) . Claim 6, line 4, “a base controller configured to control the base communicator” corresponding structure is the processor (Specification, Fig.2: Processor, paragraph [0047]) . Claim 7, line 2-4, “the base controller determines…” corresponding structure is the processor (Specification, Fig.2: Processor, paragraph [0047]) . Claim 8, line 2, “a base operation unit…the base operation unit transmits” corresponding structure is icon displayed on a touch pad or a switch (Specification, Fig.2: Switch, etc., paragraph [0045], “an icon displayed on a touch pad”) . Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 12-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 12-13 don’t define a memory or a non-transitory computer-readable medium, the claims state “a terminal program that is a computer-readable terminal program” or “a base program that is a computer-readable base program” embodying functional descriptive material. The claim appears to be directed towards a software embodiment. Software, alone, are not physical components and thus are not statutory since software do not define any structural and functional interrelationships between the computer programs and other claimed elements of a computer, which permit the computer's program functionality to be realized. Hence, the stated functions comprise software and is thus not directed to a hardware embodiment. Although applicant’s published specification in paragraph [0037], and [0046] define “a non-transitory tangible storage medium” the claims do not have structure to perform the functions described in the claims. In order to overcome the present rejection, the Applicant is advised to amend the claims by the following: “A terminal program that is a computer-readable terminal program embodied in a non-transitory computer readable medium ” for claim 12, and “A base program that is a computer-readable terminal program embodied in a non-transitory computer readable medium ” for claim 13. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claims 2-4, and 12-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 2 recites the limitation "in the normal state, includes the specific terminal information in the first message and causes the terminal communicator to transmit the first message to the base station," is indefinite because Claim 1 recites "wherein the terminal controller causes the terminal communicator to transmit a first message of the radio communication to the base station without including, in the first message, specific terminal information indicating that the communication terminal is a specific communication terminal use of which is possibly restricted by the base station " the limitation in claim 2 is counter to the limitation in claim 1 as claim 1 specified to not include "specific terminal information" in first message and claim 2 is reciting the "specific terminal information" is in the first message. Upon review of applicant specification, the examiner believes applicant is attempting to claim Fig.3:S1 as disclosed in claim 1, and Fig.5:S11 as disclosed in claim 2, “includes the specific terminal information in the first message”. Claim 1 correlates more to Fig.3 and having to bring Fig.5:S11 creates an indefinite situation of whether the first messages carry or does not carry "specific terminal information". Dependent claim(s) 3-4 are all further rejected under 112(b) as they do not remedy the vague and indefiniteness in the parent claims. Claim 12, line 1, recites “A terminal program that is a computer-readable terminal program for causing a computer to operate…” renders the claim indefinite because it is unclear if the claim is a system claim or a software claim as the claim also has “a terminal controller for controlling” and “a terminal communicator performing radio communication” which are parts of a system, and when combined with “terminal program” renders the claim unclear if the claim is directed towards a system claim or a software claim. Claim 13, line 1, recites “A base program that is a computer-readable terminal program for causing a computer to operate…” renders the claim indefinite because it is unclear if the claim is a system claim or a software claim as the claim also has “a base controller for controlling” and “a base communicator performing radio communication” which are parts of a system, and when combined with “base program” renders the claim unclear if the claim is directed towards a system claim or a software claim. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-20-02-aia AIA 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. 07-21-aia AIA Claim (s) 1, 5-6, 10-15 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US-20230217498-A1) . Regarding Claim 1, 3GPP'233 discloses A communication terminal comprising: a terminal communicator configured to perform radio communication with a base station (page 1, section 1. introduction, box 1, bullet 2, "Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]" (i.e., UE communicating with a network RAN2, or RAN1 by sending messages Msg1 and/or Msg3.) ) ; and a terminal controller configured to control the terminal communicator (page 1, section 2.1 Definition of RedCap UE Type, last paragraph, "RedCap UE and non-RedCap UE" (i.e., a terminal controller is inherent component of UE as the controller is needed to perform of sensing the correct message and perform all the tasks described in 3GPP'223.) ) , wherein the terminal controller causes the terminal communicator to transmit a first message of the radio communication to the base station without including, in the first message, specific terminal information indicating that the communication terminal is a specific communication terminal use of which is possibly restricted by the base station (page 2, section 2.2 Early indication of RedCap UE, paragraph below box 3, "From the above agreements, we can see that both early indication in Msg1 and Msg3 in 4-step RACH should be supported by the standard. However, early indication shall be done in either Msgl or Msg3 . It is redundant to identify RedCap UE type in both Msg1 and Msg3. The network shall also be able to configure and indicate 'no early indication for RedCap UE', even if it allows the access of RedCap UE. Therefore, the following three cases in 4-step RACH shall be supported, and one of them can be configured in the network at the same time." (i.e., sending a Msg1 without identifying if the UE is a RedCap UE, and sending the RedCap UE indication in Msg3.) ) , and includes the specific terminal information in a subsequent message that is a third message or a message subsequent to the third message as a response to the second message (page 1, section 1. introduction, box 1, bullet 2, "Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]" and page 2, section 2.2. Early indication of RedCap UE, last line, “Early indication in Msg3” (i.e., the limitation is reading as Msg3 will have an indication whether the UE is a redcap UE or a non-RedCap UE. The “as a response to the second message” will be addressed by a different reference.) ) . However, 3GPP'233 does not explicitly disclose receives a second message as a response to the first message from the base station via the terminal communicator, and includes the specific terminal information in a subsequent message that is a third message or a message subsequent to the third message as a response to the second message, and causes the terminal communicator to transmit the subsequent message to the base station. LEE’498 discloses a base station (Fig.4A) , receives a second message as a response to the first message from the base station via the terminal communicator (paragraph [0051], Fig.4A, "the BS may transmit message 2 (Msg2) corresponding to a random access response (RAR) message to the UE (see 1703 of FIG. 4(a)). A PDCCH scheduling a PDSCH carrying the RAR may be CRC masked with a random access (RA) radio network temporary identifier (RNTI) (RA-RNTI) and then transmitted." (i.e., LEE’498 explicitly discloses a base station replying to UE Msg1.) ) , and includes the specific terminal information in a subsequent message that is a third message or a message subsequent to the third message as a response to the second message (paragraph [0052], Fig.4A, "The RAR information transmitted on the PDSCH may include timing advance (TA) information for UL synchronization, an initial UL grant, and a temporary cell-RNTI (C-RNTI). The TA information may be used to control a UL signal transmission timing. The UE may transmit a UL signal over a UL shared channel as message 3 (Msg3) of the random access procedure based on the RAR information (see 1705 of FIG. 4(a))." and paragraph [0125], proposal 2, "[Proposal 2] When RedCap UE Sharing at Least Parts of RA Configurations (e.g., RO, Preamble ID, and/or Search Space) with legacy UE Transmits PRACH Preamble (Msg1), Network May Configure Msg3 Scheduling for RedCap UE Different From That of Legacy UE By Masking Additional Bits As Well As RA-RNTI to CRC of Msg2 Scheduling DCI." and paragraph [0126], "The network may provide the UE with a configuration for transmitting Msg3 in Msg2. A 24-bit CRC may be attached to DCI of Msg2," (i.e., UE receiving Msg2 that has configuration in order to sent Msg3 to indicate if the UE is a RedCap or not.) ) , and causes the terminal communicator to transmit the subsequent message to the base station (paragraph [0122], "The UE may transmit Msg3 (A108). The BS may receive Msg3 in response to Msg2. The BS may determine whether the UE that transmitted the PRACH preamble is the first type of UE or the second type of UE, based on which RA-RNTI among the plurality of RA-RNTIs Msg 3 is associated with." (i.e., subsequent message is reading as a third message .) ) . 3GPP'233 and LEE’498 are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of LEE’498 random access procedure as LEE’498 discloses of enabling the network to distinguish between RedCap UE from a normal NR UE, and additionally LEE’498 discloses of RedCap UE may share resources for random access with the legacy UE to improve efficiency of using random access resources (LEE’498, paragraph [0076], “According to one aspect of present disclosure, there is provided a method of enabling a network to distinguish a RedCap UE from a normal NR UE (or Non-RedCap UE) during a random access procedure, for example, a method for identifying/indicating that the corresponding UE is the RedCap UE. According to another aspect of the present disclosure, there is provided a method of allowing a RedCap UE to support a relaxed processing time/capability different from that of NR.” and paragraph [0082], “For example, a method of allowing the RedCap UE to perform random access by sharing resources with the legacy UE is provided. That is, the RedCap UE may share resources for random access with the legacy UE to improve the efficiency of using the random access resources.”) . Regarding Claim 5, 3GPP'233 in view of LEE’498 discloses all the limitation of claim 1. 3GPP'233 discloses wherein the specific terminal information is information indicating that a communication function of the specific communication terminal is partially restricted as compared with a communication function of a normal communication terminal that is not the specific communication terminal (page 1, section 1. Introduction, box 1, bullet 1, "Specify definition of one RedCap UE type including capabilities for RedCap UB identification and for constraining the use of those RedCap capabilities only for RedCap UEs, and preventing RedCap UEs from using capabilities not intended for RedCap UEs including at least carrier aggregation, dual connectivity and wider bandwidths. [RAN2, RAN1]" and page 1, section 1. Introduction, box 1, bullet 2, "Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]" (i.e., RedCap UE is restricted device compared to a non-RedCap UE.) ) . Regarding Claim 6, 3GPP’233 discloses wherein the base controller receives a first message of the radio communication from the communication terminal via the base communicator (page 2, section 2.2 Early indication of RedCap UE, paragraph below box 3, "From the above agreements, we can see that both early indication in Msg1 and Msg3 in 4-step RACH should be supported by the standard. However, early indication shall be done in either Msgl or Msg3 . It is redundant to identify RedCap UE type in both Msg1 and Msg3. The network shall also be able to configure and indicate 'no early indication for RedCap UE', even if it allows the access of RedCap UE. Therefore, the following three cases in 4-step RACH shall be supported, and one of them can be configured in the network at the same time." (i.e., UE sending Msg1 or Msg3 indication of RedCap UE.) ) . However, 3GPP’233 does not explicitly discloses A base station comprising: a base communicator configured to perform radio communication with a communication terminal; and a base controller configured to control the base communicator, causes the base communicator to transmit a second message to the communication terminal as a response to the first message in a case that the first message does not include specific terminal information indicating that the communication terminal is a specific communication terminal use of which is possibly restricted by the base station, receives, from the communication terminal, a subsequent message that is a third message or is a message subsequent to the third message as a response to the second message, and causes the communication terminal to use a communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message. LEE’498 further discloses A base station comprising: a base communicator configured to perform radio communication with a communication terminal (paragraph [0161], Fig.13, “Referring to FIG. 13, a first wireless device 100 and a second wireless device 200 may transmit radio signals through a variety of RATs (e.g., LTE and NR). Herein, {the first wireless device 100 and the second wireless device 200} may correspond to {the wireless device 100x and the BS 200} and/or {the wireless device 100x and the wireless device 100x} of FIG. 12.”) ; causes the base communicator to transmit a second message to the communication terminal as a response to the first message in a case that the first message does not include specific terminal information indicating that the communication terminal is a specific communication terminal use of which is possibly restricted by the base station (paragraph [0052], Fig.4A, "The RAR information transmitted on the PDSCH may include timing advance (TA) information for UL synchronization, an initial UL grant, and a temporary cell-RNTI (C-RNTI). The TA information may be used to control a UL signal transmission timing. The UE may transmit a UL signal over a UL shared channel as message 3 (Msg3) of the random access procedure based on the RAR information (see 1705 of FIG. 4(a))." and paragraph [0125], proposal 2, "[Proposal 2] When RedCap UE Sharing at Least Parts of RA Configurations (e.g., RO, Preamble ID, and/or Search Space) with legacy UE Transmits PRACH Preamble (Msg1), Network May Configure Msg3 Scheduling for RedCap UE Different From That of Legacy UE By Masking Additional Bits As Well As RA-RNTI to CRC of Msg2 Scheduling DCI." and paragraph [0126], "The network may provide the UE with a configuration for transmitting Msg3 in Msg2. A 24-bit CRC may be attached to DCI of Msg2," (i.e., Base station sending Msg2.) ) , receives, from the communication terminal, a subsequent message that is a third message or is a message subsequent to the third message as a response to the second message (paragraph [0122], "The UE may transmit Msg3 (A108). The BS may receive Msg3 in response to Msg2. The BS may determine whether the UE that transmitted the PRACH preamble is the first type of UE or the second type of UE, based on which RA-RNTI among the plurality of RA-RNTIs Msg 3 is associated with." (i.e., UE sending Msg3.) ) , and causes the communication terminal to use a communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message (paragraph [0123], "The BS may determine the type of the corresponding UE based on Msg3 (A109)." and paragraph [0124], "The BS may transmit Msg4 based on the type of the corresponding UE (A110)." and paragraph [0125], "The BS may generate/transmit SIB1 based on the type of the corresponding UE. The BS may configure a BWP based on the type of the corresponding UE." (i.e., base station configure BWP to allow the UE to transmit and allow use of communication function.) ) . 3GPP'233 and LEE’498 are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of LEE’498 random access procedure as LEE’498 discloses of enabling the network to distinguish between RedCap UE from a normal NR UE, and additionally LEE’498 discloses of RedCap UE may share resources for random access with the legacy UE to improve efficiency of using random access resources (LEE’498, paragraph [0076], “According to one aspect of present disclosure, there is provided a method of enabling a network to distinguish a RedCap UE from a normal NR UE (or Non-RedCap UE) during a random access procedure, for example, a method for identifying/indicating that the corresponding UE is the RedCap UE. According to another aspect of the present disclosure, there is provided a method of allowing a RedCap UE to support a relaxed processing time/capability different from that of NR.” and paragraph [0082], “For example, a method of allowing the RedCap UE to perform random access by sharing resources with the legacy UE is provided. That is, the RedCap UE may share resources for random access with the legacy UE to improve the efficiency of using the random access resources.”) . Regarding Claim 10, 3GPP'233 in view of LEE’498 discloses all the limitation of claim 6. LEE’498 further discloses wherein in a case that the specific terminal information is not included in the subsequent message, the base controller causes the communication terminal to use a communication function as a normal communication terminal that is not the specific communication terminal (paragraph [0122], "The UE may transmit Msg3 (A108). The BS may receive Msg3 in response to Msg2. The BS may determine whether the UE that transmitted the PRACH preamble is the first type of UE or the second type of UE, based on which RA-RNTI among the plurality of RA-RNTIs Msg 3 is associated with." and paragraph [0123], Fig.4a, "The BS may determine the type of the corresponding UE based on Msg3 (A109)." and paragraph [0124], "The BS may transmit Msg4 based on the type of the corresponding UE (A110)." (i.e., Since the UE did not use RA-RNTI B but instead used RA-RNTI A then it is determined the UE is not the specific communication terminal.) ) . The proposed combination as well as the motivations for combining the references presented in the rejection of the parent claim apply to this claim and are incorporated herein by reference. Regarding Claim 11, 3GPP'233 in view of LEE’498 discloses all the limitation of claim 6. 3GPP'233 further discloses wherein the specific terminal information is information indicating a communication terminal in which the communication function of the specific communication terminal is partially restricted as compared with a normal communication terminal that is not the specific communication terminal (page 1, section 1. Introduction, box 1, bullet 1, "Specify definition of one RedCap UE type including capabilities for RedCap UB identification and for constraining the use of those RedCap capabilities only for RedCap UEs, and preventing RedCap UEs from using capabilities not intended for RedCap UEs including at least carrier aggregation, dual connectivity and wider bandwidths. [RAN2, RAN1]" and page 1, section 1. Introduction, box 1, bullet 2, "Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]" (i.e., RedCap UE.) ) . Regarding Claim 14, 3GPP discloses a communication system comprising: a communication terminal (page 1, last paragraph, “RedCap UE and non-RedCap UE”) ; and wherein the communication terminal transmits a first message of the radio communication to the base station without including, in the first message, specific terminal information indicating that the communication terminal is a specific communication terminal use of which is possibly restricted by the base station (page 2, section 2.2 Early indication of RedCap UE, paragraph below box 3, "From the above agreements, we can see that both early indication in Msg1 and Msg3 in 4-step RACH should be supported by the standard. However, early indication shall be done in…Msg3 . It is redundant to identify RedCap UE type in both Msg1 and Msg3. The network shall also be able to configure and indicate 'no early indication for RedCap UE', even if it allows the access of RedCap UE. Therefore, the following three cases in 4-step RACH shall be supported, and one of them can be configured in the network at the same time." (i.e., UE sending Msg1) ) , includes the specific terminal information in a subsequent message that is a third message or a message subsequent to the third message as a response to the second message (page 1, section 1. introduction, box 1, bullet 2, "Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]" and page 2, section 2.2. Early indication of RedCap UE, last line, “Early indication in Msg3” (i.e., the limitation is reading as Msg3 will have an indication whether the UE is a redcap UE or a non-RedCap UE. The “as a response to the second message” will be addressed by a different reference.) ) . However, 3GPP’233 does not explicitly discloses a base station configured to perform radio communication with the communication terminal, the base station receives the first message from the communication terminal and transmits a second message to the communication terminal as a response to the first message, the communication terminal receives the second message from the base station, includes the specific terminal information in a subsequent message that is a third message or is a message subsequent to the third message as a response to the second message, and transmits the subsequent message to the base station, and the base station receives the subsequent message from the communication terminal and causes the communication terminal to use a communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message. LEE’498 discloses a base station configured to perform radio communication with the communication terminal (paragraph [0161], Fig.13) , the base station receives the first message from the communication terminal (paragraph [0047], Fig.4A, “First, the UE may transmit message 1 (Msg1) including a random access preamble on a PRACH (see 1701 of FIG. 4(a)).”) and transmits a second message to the communication terminal as a response to the first message (paragraph [0051], Fig.4A, "the BS may transmit message 2 (Msg2) corresponding to a random access response (RAR) message to the UE (see 1703 of FIG. 4(a)). A PDCCH scheduling a PDSCH carrying the RAR may be CRC masked with a random access (RA) radio network temporary identifier (RNTI) (RA-RNTI) and then transmitted." (i.e., base station sending a Msg2 which a response message to Msg1 as seen in Fig.4A.) ) , the communication terminal receives the second message from the base station (paragraph [0052], Fig.4A, "The RAR information transmitted on the PDSCH may include timing advance (TA) information for UL synchronization, an initial UL grant, and a temporary cell-RNTI (C-RNTI). The TA information may be used to control a UL signal transmission timing. The UE may transmit a UL signal over a UL shared channel as message 3 (Msg3) of the random access procedure based on the RAR information (see 1705 of FIG. 4(a))." and paragraph [0125], proposal 2, "[Proposal 2] When RedCap UE Sharing at Least Parts of RA Configurations (e.g., RO, Preamble ID, and/or Search Space) with legacy UE Transmits PRACH Preamble (Msg1), Network May Configure Msg3 Scheduling for RedCap UE Different From That of Legacy UE By Masking Additional Bits As Well As RA-RNTI to CRC of Msg2 Scheduling DCI." and paragraph [0126], "The network may provide the UE with a configuration for transmitting Msg3 in Msg2. A 24-bit CRC may be attached to DCI of Msg2," (i.e., UE receives Msg2, and UE transmitting Msg3 indicating whether the UE is RedCap or a non-RedCap UE.) ) , includes the specific terminal information in a subsequent message that is a third message or is a message subsequent to the third message as a response to the second message (paragraph [0122], Fig.4A, “The UE may transmit Msg3 (A108). The BS may receive Msg3 in response to Msg2. The BS may determine whether the UE that transmitted the PRACH preamble is the first type of UE or the second type of UE, based on which RA-RNTI among the plurality of RA-RNTIs Msg 3 is associated with.” and paragraph [0126], "The network may provide the UE with a configuration for transmitting Msg3 in Msg2. A 24-bit CRC may be attached to DCI of Msg2," (i.e., UE sending the third message to help the base station identify if the UE is RedCap or a non-RedCap.) ) , and the base station receives the subsequent message from the communication terminal and causes the communication terminal to use a communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message (paragraph [0123], "The BS may determine the type of the corresponding UE based on Msg3 (A109)." and paragraph [0124], "The BS may transmit Msg4 based on the type of the corresponding UE (A110)." and paragraph [0125], "The BS may generate/transmit SIB1 based on the type of the corresponding UE. The BS may configure a BWP based on the type of the corresponding UE." (i.e., UE communicates with base station.) ) . 3GPP'233 and LEE’498 are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of LEE’498 random access procedure as LEE’498 discloses of enabling the network to distinguish between RedCap UE from a normal NR UE, and additionally LEE’498 discloses of RedCap UE may share resources for random access with the legacy UE to improve efficiency of using random access resources (LEE’498, paragraph [0076], “According to one aspect of present disclosure, there is provided a method of enabling a network to distinguish a RedCap UE from a normal NR UE (or Non-RedCap UE) during a random access procedure, for example, a method for identifying/indicating that the corresponding UE is the RedCap UE. According to another aspect of the present disclosure, there is provided a method of allowing a RedCap UE to support a relaxed processing time/capability different from that of NR.” and paragraph [0082], “For example, a method of allowing the RedCap UE to perform random access by sharing resources with the legacy UE is provided. That is, the RedCap UE may share resources for random access with the legacy UE to improve the efficiency of using the random access resources.”) . Regarding Claim 12, which is similar in scope to claim 1, thus rejected under the same rationale. Regarding Claim 13, which is similar in scope to claim 6, thus rejected under the same rationale. Regarding Claim 15, which is similar in scope to claim 14, thus rejected under the same rationale . 07-21-aia AIA Claim (s) 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US-20230217498-A1) in further view of Ioffe (US-20220394450-A1) . Regarding Claim 2, 3GPP'233 in view of LEE’498 discloses all the limitation of claim 1. However, 3GPP'233 in view of LEE’498 does not disclose wherein the terminal controller determines whether a current state is a normal state or an emergency state different from the normal state; in the normal state, includes the specific terminal information in the first message and causes the terminal communicator to transmit the first message to the base station, and in the emergency state, includes the specific terminal information in the subsequent message and causes the terminal communicator to transmit the subsequent message to the base station. Ioffe discloses wherein the terminal controller determines whether a current state is a normal state (paragraph [0059], Fig.5A, "When an emergency is not indicated, the base station 72A proceeds to determine, at block 96," (i.e., UE terminal can decide if it’s a non-emergency state.) ) or an emergency state different from the normal state (paragraph [0056], "At block 88, the user equipment 74 may transmit a random access preamble (MSG1) with an indication of a number of RX branches and with an indication of an emergency, such as an indication of an emergency establishment cause, mps-PriornyAccess establishment cause, and/or mcs-PriornyAccess establishment cause (e.g., as defined in the 38.331 technical specification (TS38.331) of 3GPP). The indication of emergency may indicate to the base station 72A that the request is for urgent or prioritized service fulfillment," and paragraph [0059], Fig.5A, "the base station 72A proceeds to determine, at block 94, whether the random access preamble (MSG1) indicated the establishment cause of the connection request as being for an emergency or relatively high urgency. The random access preamble (MSG1) may include the indication of emergency. " (i.e., UE is in an emergency state based on the indication.) ) ; in the normal state, includes the specific terminal information in the first message and causes the terminal communicator to transmit the first message to the base station (paragraph [0058], 5A, "After receiving the random access preamble (MSG1), the base station 72A determines compatibility between the request, network 70 preferences, and/or network 70 conditions. To elaborate, at block 92, the base station 72A determines whether the indications transmitted with the random access preamble (MSG1) indicate that the user equipment 74 has a reduced number of RX branches (e.g., 1 RX branch of a RedCap NR device reduced relative to 2 RX branches or 4 RX branches of a baseline NR device). " and paragraph [0059], "As noted above, after the base station 72A determines that the user equipment 74 indicated a reduced number of RX branches, the base station 72A proceeds to determine, at block 94," and paragraph [0060], "At block 98, the base station 72A responds to the random access preamble message sent by the user equipment 74 with the UL scheduling information (MSG2) and, at block 102, the user equipment receives the UL scheduling information (MSG2). By doing so, the base station 72A determines to accept the request from the user equipment 74 and may configure its resources to settings provided by the user equipment 74 in the random access preamble message. For example, the base station 72A may configure one or more resources to the frequency subranges supported by the user equipment 74 and the base station 72A." (i.e., UE able to specify if the terminal is a RedCap UE in Msg1.) ) , and in the emergency state, includes the specific terminal information in the subsequent message and causes the terminal communicator to transmit the subsequent message to the base station (paragraph [0027], "Furthermore, if the user equipment transmits the early indication of the number of RX branches in the random access request (MSG1) or in a request to set up a radio resource control connection (e.g., an RRCSetupRequest (MSG3)) ," and paragraph [0032], "In the second example, the base station may have limited responses to the random access preamble (MSG1) while awaiting arrival of the second indication in the RRCSetupRequest (MSG3), as to avoid early termination of an emergency request. As a third example, the user equipment may connect to the base station on a frequency layer that is not permitted for RedCap devices. However, the base station may permit the user equipment to use that frequency layer to make an emergency call and ignore barring in this case." and paragraph [0066], Fig.5A, "In method 78, the base station 72A referenced the random access preamble (MSG1) for the indication of emergency. However, in method 132, the base station 72A references the RRCSetupRequest (MSG3) for the indication of emergency." (i.e., "subsequent message" is reading as "third message" in claim 1. The UE in the emergency state sent a number of RX branches which indicates the UE is a RedCap and that can be sent in MSG3.) ) . 3GPP'233 in view of LEE’498 and Ioffe are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of Ioffe in order to have the RedCap UE access communication when the RedCap UE as its required by the FCC and Ioffe method enables the system to allow RedCap UE access when the base station could prohibit redcap UE access (Ioffe, paragraph [0047], “As previously noted, the 3GPP may expand standards to permit network providers to support RedCap devices. Systems and methods that reduce a likelihood that a network provider may deny an emergency-service access request from a RedCap device without a preferred configuration may be desired, such as to comply with FCC guidelines.”) . Regarding Claim 3, 3GPP'233 in view of LEE’498 in further view of Ioffe discloses all the limitation of claim 2. Ioffe further discloses a terminal operation unit operated by a user (paragraph [0031], "As another example, an emergency responder (e.g., police, firefighter, medic) may request emergency-service access via a RedCap wearable (e.g., smart watch, a cellular-connected headset) in the absence of a cellular phone being nearby or connected." and paragraph [0037], "the display 18 may include a touch screen, which may facilitate user interaction with a user interface of the electronic device 10.") , wherein in a case that the user performs a predetermined operation, the terminal operation unit transmits, to the terminal controller, state information indicating whether the current state is the normal state or the emergency state (paragraph [0056], "At block 88, the user equipment 74 may transmit a random access preamble (MSG1) with an indication of a number of RX branches and with an indication of an emergency, such as an indication of an emergency establishment cause, mps-PriornyAccess establishment cause, and/or mcs-PriornyAccess establishment cause (e.g., as defined in the 38.331 technical specification (TS38.331) of 3GPP).") . The proposed combination as well as the motivations for combining the references presented in the rejection of the parent claim apply to this claim and are incorporated herein by reference . 07-21-aia AIA Claim (s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US-20230217498-A1) in view of Kadiri (US-20210410045-A1) in further view of Ioffe (US-20220394450-A1) . Regarding Claim 7, 3GPP'233 in view of LEE’498 discloses all the limitation of claim 6. However, 3GPP'233 in view of LEE’498 do not disclose wherein the base controller determines whether a current state is a normal state or an emergency state different from the normal state, in the normal state, causes the communication terminal to use the communication function as the specific communication terminal even in a case that the specific terminal information is included in the first message, and in the emergency state, causes the communication terminal not to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the first message, and causes the communication terminal to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message. Kadiri discloses wherein the base controller determines whether a current state is a normal state (paragraph [0110], "a quantity of one or more user equipment receiving access to the one or more multicast broadcast services through the base station is below a threshold quantity, or a data rate of data being accessed by one or more user equipment through the base station 304 is below a threshold data rate." (i.e., non-overloaded.) ) or an emergency state different from the normal state (paragraph [0058],"a base station may experience an overload condition, for example, when a quantity of UEs in the RRC connected state with the cell of the base station is greater than a threshold quantity." (i.e., "overload condition" is reading on as emergency state .) ) , in the normal state, causes the communication terminal to use the communication function as the specific communication terminal even in a case that the specific terminal information is included in the first message (paragraph [0110], Fig.3, " In operation 328, the user equipment 302 and the base station 304 may exchange random access messages based permitting the user equipment 302 to establish or resume the RRC connected state for receiving the multicast broadcast services. For example, responsive to receiving the access message, the base station 304 may identify that one or more quality of service (QoS) parameters associated with the one or more multicast broadcast services are relatively high, a quantity of one or more user equipment receiving access to the one or more multicast broadcast services through the base station is below a threshold quantity, or a data rate of data being accessed by one or more user equipment through the base station 304 is below a threshold data rate. Accordingly, the base station 304 may transmit a response message indicating that the user equipment 302 is allowed to enter the RRC connected state to receive the one or more multicast broadcast services based on the access message and subsequently allow the user equipment 302 to access to the one or more multicast broadcast services ." (i.e., when base station is operating normally, allow the UE to communicate.) ) , and in the emergency state, causes the communication terminal not to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the first message (paragraph [0107], Fig.3, "In operation 326, the base station 304 may transmit an access rejection message that indicates, to the user equipment 302, that the request to establish or resume the RRC connected state is denied based on not permitting the user equipment 302 to establish or resume the RRC connected state for receiving the multicast broadcast services. For example, the base station 304 may identify whether the user equipment is allowed to enter into the RRC connected state for receiving multicast broadcast services based on access message while the base station 304 is in an overload condition." (i.e., The UE is blocked from communication during an emergency state such as an overload.) ) , and causes the communication terminal to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message (paragraph [0105], "In certain embodiments, when the access message includes a resume cause, the base station 304 may identify that the user equipment 302 is allowed to enter the RRC connected state for receiving the multicast broadcast services regardless of whether a quantity of user equipment (UEs) camped on the base station 304 is above a threshold." (i.e., to teach that certain UE can access the base station even when the base station is overloaded.) ) . 3GPP'233 in view of LEE’498 and Kadiri are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of Kadiri in order control the state of the network device in overload condition in order to reduce the amount of time overload last as its desirable for users to maintain connection with base station in order to receive multicast broadcast services (Kadiri, paragraph [0058], “When experiencing, or to prevent, an overload condition, the base station may configure a barring factor or a barring time to delay the UE from transmitting an access message to the base station or to increase the likelihood of delaying the transmission of the access message by the UE. Delaying the UE from transmitting the access message may allow enough time for one or more other UEs to transition from the RRC connected state to the RRC idle state or the RRC inactive state, and as a result, enable the UE to enter the RRC connected state at a point in the future when the base station can maintain the quantity of UEs in the RRC connected state to below the threshold quantity, thereby alleviating congestion at the base station.”) . However, 3GPP'233 in view of LEE’498 in further view of Kadiri do not disclose causes the communication terminal to use the communication function as the specific communication terminal even in a case that the specific terminal information is included in the first message, causes the communication terminal not to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the first message in a case that the specific terminal information is included in the first message and causes the communication terminal to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message. Ioffe discloses causes the communication terminal to use the communication function as the specific communication terminal even in a case that the specific terminal information is included in the first message (paragraph [0058], “To elaborate, at block 92, the base station 72A determines whether the indications transmitted with the random access preamble (MSG1) indicate that the user equipment 74 has a reduced number of RX branches (e.g., 1 RX branch of a RedCap NR device reduced relative to 2 RX branches or 4 RX branches of a baseline NR device).” and paragraph [0059], “after the base station 72A determines that the user equipment 74 indicated a reduced number of RX branches, the base station 72A proceeds to determine, at block 94, whether the random access preamble (MSG1) indicated the establishment cause of the connection request as being for an emergency or relatively high urgency. The random access preamble (MSG1) may include the indication of emergency… However, when an emergency is indicated, the base station 72A may be barred from denying the request of the user equipment 74 and is to fulfill the request. Hence, the base station 72A may proceed to block 98 to prepare the connection with the user equipment 74 for communications via the network 70A.” (i.e., base station may allow the RedCap UE when the base station is in normal state as indicated by Kadiri, but only when the UE is under the emergency.) ) , causes the communication terminal not to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the first message in a case that the specific terminal information is included in the first message (paragraph [0027], "Furthermore, if the user equipment transmits the early indication of the number of RX branches in the random access request (MSG1)" and paragraph [0032], "In the second example, the base station may have limited responses to the random access preamble (MSG1) while awaiting arrival of the second indication in the RRCSetupRequest (MSG3), as to avoid early termination of an emergency request. As a third example, the user equipment may connect to the base station on a frequency layer that is not permitted for RedCap devices. However, the base station may permit the user equipment to use that frequency layer to make an emergency call and ignore barring in this case." and paragraph [0059], “after the base station 72A determines that the user equipment 74 indicated a reduced number of RX branches, the base station 72A proceeds to determine, at block 94, whether the random access preamble (MSG1) indicated the establishment cause of the connection request as being for an emergency or relatively high urgency. The random access preamble (MSG1) may include the indication of emergency. When an emergency is not indicated, the base station 72A proceeds to determine, at block 96, whether ending a connection with the user equipment 74 is desired” (i.e., when the RedCap UE sending in Msg1 without an indication of emergency and the state of the base station is in emergency as taught in Kadiri, the base station can block access. ) and causes the communication terminal to use the communication function as the specific communication terminal in a case that the specific terminal information is included in the subsequent message (paragraph [0027], "Furthermore, if the user equipment transmits the early indication of the number of RX branches in the random access request (MSG1) or in a request to set up a radio resource control connection (e.g., an RRCSetupRequest (MSG3)) ," and paragraph [0032], "In the second example, the base station may have limited responses to the random access preamble (MSG1) while awaiting arrival of the second indication in the RRCSetupRequest (MSG3), as to avoid early termination of an emergency request. As a third example, the user equipment may connect to the base station on a frequency layer that is not permitted for RedCap devices. However, the base station may permit the user equipment to use that frequency layer to make an emergency call and ignore barring in this case." and paragraph [0066], Fig.5A, "In method 78, the base station 72A referenced the random access preamble (MSG1) for the indication of emergency. However, in method 132, the base station 72A references the RRCSetupRequest (MSG3) for the indication of emergency." (i.e., Allow the RedCap UE to communicate when the RedCap UE indicate its an emergency and it’s a RedCap UE in Msg3.) ) . 3GPP'233 in view of LEE’498 in further view of Kadiri and Ioffe are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of Ioffe in order to have the RedCap UE access communication when the RedCap UE as its required by the FCC and Ioffe method enables the system to allow RedCap UE access when the base station could prohibit redcap UE access (Ioffe, paragraph [0047], “As previously noted, the 3GPP may expand standards to permit network providers to support RedCap devices. Systems and methods that reduce a likelihood that a network provider may deny an emergency-service access request from a RedCap device without a preferred configuration may be desired, such as to comply with FCC guidelines.”) . 07-21-aia AIA Claim (s) 4 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US- 20230217498-A1) in view of Ioffe (US-20220394450-A1) in further view of LEE'722 (US-20170171722-A1) in further view of Balasubramanian (US-20200221278-A1) . Regarding Claim 4, 3GPP'233 in view of LEE’498 in further view of Ioffe discloses all the limitation of claim 2. However, 3GPP'233 in view of LEE’498 in further view of Ioffe do not disclose wherein the terminal controller receives state information indicating whether the current state is the normal state or the emergency state from outside the communication terminal via the terminal communicator LEE’722 discloses wherein the terminal controller receives state information indicating whether the current state is the normal state or the emergency state from outside the communication terminal via the terminal communicator (paragraph [0124], Fig.4, "In an embodiment of FIG. 4, the broadcast reception device 100 includes a broadcast receiving unit 110, an internet protocol (IP) communication unit 130, and a control unit 150." and paragraph [0434], Fig.41, "The broadcast receiving device 100 may change the emergency alert state after receiving the emergency alert message including the emergency alert (DS1464). More specifically, the broadcast receiving device 100 may configure a UI for representing the emergency alert message and related supplementary information using a remote UI service after receiving the emergency alert message including the emergency alert. As another embodiment of this method, there is a method of using a remote UI service of a UPnP. The broadcast receiving device may notify the companion device that the emergency alert is generated by changing the emergency alert state." (i.e., Fig.41 shows can receive state information such as an emergency alert from outside the communication terminal.) ) . 3GPP'233 in view of LEE’498 in further view of Ioffe and LEE’722 are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of LEE’722 of having another device to indicate whether the current state is an emergency state because LEE’722 discloses of efficiently interoperating when receiving emergency information (LEE’722, paragraph [0047], “Provide is a terminal device efficiently interoperating with a broadcast reception device and efficiently receiving information from the broadcast reception device.”) . However, 3GPP'233 in view of LEE’498 in view of Ioffe in further view of LEE’722 do not explicitly disclose wherein the terminal controller receives state information indicating whether the current state is the normal state or the emergency state from outside the communication terminal via the terminal communicator. Balasubramanian discloses wherein the terminal controller receives state information indicating whether the current state is the normal state or the emergency state from outside the communication terminal via the terminal communicator (paragraph [0029], “The beacon 12 comprises, at a minimum, a unique identification for the card 15 and a current card state. The controller 65 is configured to transmit a beacon 12 identifying the current state as normal when the activation button 55 is not actuated” and paragraph [0030], “In FIG. 3, the portable (cell phone) device 20 that receives the beacon 12 from the card 15 is shown in detail. The device 20 comprises a Bluetooth receiver 80 configured to receive the beacon 12 transmitted by the card 15, a communications port 85, and a device controller 90 connected to the Bluetooth receiver 80 and to the communications port 85, wherein the device controller 90 is configured to receive and process the beacon 12, and to transmit an emergency signal 30 on the communication port 85 when the beacon 12 indicates an emergency state” and paragraph [0037], “ The controller 90 first listens for the beacon 12 from the card 15 (step 600). It then determines in step 601 whether the beacon indicates an emergency state. If the beacon 12 indicates an emergency state, the device controller 90 would bring the emergency application UI to the foreground of the device 20's operating system,”) . 3GPP'233 in view of LEE’498 in further view of Ioffe in further view of LEE’722 and Balasubramanian are considered to be analogous to the claimed invention because they are in the same field wireless communication. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of Balasubramanian as it would other devices such as a “card” in order to alert other user devices such as cellular phones that the current state of the environment is normal or an emergency as doing so would increase the chances of getting help when a plurality of people receive the state of the environment (Balasubramanian, paragraph [0003], “With a rising incidence of violence on school campuses and in densely populated areas, such as attacks, stalking, and active shooters, there is increasing need for a portable and easy-to-use emergency alert device to get help to the user's location.”) . 07-21-aia AIA Claim (s) 8 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US- 20230217498-A1) in view of Kadiri (US-20210410045-A1) in view of Ioffe (US-20220394450-A1) in further view of Horneman (US-20140119359-A1) . Regarding Claim 8, 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe discloses all the limitation of claim 7. Kadiri further discloses further comprising: a base operation unit operated by a user in a case that the user performs a predetermined operation, the base operation unit transmits, to the base controller, state information indicating whether the current state is the normal state or the emergency state (paragraph [0023], "However, too many UEs operating in an RRC connected state for receiving multicast broadcast services may cause overloading at the base station. As such, the base station may perform access overload control (or simply “access control”) to limit the number of UEs that are permitted to enter into the RRC connected state for the purpose of receiving multicast broadcast services." and paragraph [0073], "For example, the base station 304 may rely on a cellBarred-MBS/cellReservedMBS Use information elements to determine that the base station 304 is configured for providing access to the one or more multicast broadcast services. The base station 304 may transmit the one or more configured cell barring parameters to the user equipment 302 as an indication to the user equipment 302 that the base station 304 is configured for providing the user equipment 302 with access to the one or more multicast broadcast services." (i.e., base station has an access control that controls whether to permit users to RRC connection based on if the base station is overloaded or not.) ) . However, 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe do not explicitly disclose a base operation unit operated by a user in a case that the user performs a predetermined operation. Horneman discloses a base operation unit operated by a user in a case that the user performs a predetermined operation (paragraph [0050], "The interference control coordination feature may also be arranged such that it can be switched between on and off states. Switching between on and off states may be provided for various reasons and at various times. For example, a user, owner or operator of the femto node can set the state based on his/hers preferences at the time of installing the femto node, and/or later e.g. when interference is recognized as causing problems." (i.e., Explicitly discloses a user operating a base operation unit. Kadiri already discloses when a user attempts to access the base station, it would transmit to the user if the current state is normal state or emergency state.) ) . 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe and Horneman are considered to be analogous to the claimed invention because they are in the same field wireless channel access. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of Horneman of a user operating as it would allow the user to perform any fixes and maintenance “on-the-fly” thus controlling a level of interference and reducing sudden drop of traffic performance such as data rate (Horneman, paragraph [0051], “In a system where interference control cooperation between local level access nodes is enabled the control can be initiated in response to detection of a need for interference control. Detection of need for cooperation in interference control may be based on detection of at least one predefined event such as for example a local radio outage or a sudden drop of local radio traffic performance, for example effective throughput or data rate. The outage may be for example on a fixed control channel and/or on any part of a shared spectrum resource. Outages may be monitored and detected `on-the-fly` at each femto cell.”) 07-21-aia AIA Claim (s) 9 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP'233 (3GPP TSG RAN WG1 #106bis-e R1-2109233, 6 pages) (IDS, 06/08/2024) in view of LEE’498 (US-20230217498-A1) in view of Kadiri (US-20210410045-A1) in view of Ioffe (US-20220394450-A1) in further view of XU (US-20180288576-A1) . Regarding Claim 9, 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe discloses all the limitation of claim 7. However, 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe do not disclose wherein the base controller receives state information indicating whether the current state is the normal state or the emergency state, from outside the base station via the base communicator. XU discloses wherein the base controller receives state information indicating whether the current state is the normal state or the emergency state, from outside the base station via the base communicator (paragraph [0077], Fig.3, "At act S304, the predetermined network element sends, to an eNB, indication information used for indicating that the MBMS is to be suspended. The indication information is used for indicating the eNB receiving the indication information to send MSI to UE, and the MSI includes a specific value used for notifying the UE of the MBMS to be suspended." and paragraph [0078], "The problem of how to notify the eNB when the network element receives the congestion or overload indication information and selects to suspend the MBMS in the related technology is solved, and effects of timely notifying the eNB and the UE and processing the suspended service by the UE are achieved." and paragraph [0185], “At act S1404, the MCE or the OAM sends indication information to the eNB. The indication information at least includes: a recovered suspended MBSFN area ID, an MBMS ID and a timestamp.” And paragraph [0188], Fig.14, “At act S1410: whether it is needed to update the suspended MBMS or not is judged, act S1402 is executed if it is needed to update the suspended MBMS, otherwise act S1410 is executed.” and paragraph [0189], “The MCE or the OAM judges whether it is needed to update the suspended MBMS or not. The MCE or the OAM may perform judging according to any or a combination of the following conditions:… If it is needed to update the suspended MBMS (for example, an MBMS to be suspended is added), the MCE or the OAM selects a new MBMS to be suspended, otherwise the MCE or the OAM continues judging whether it is needed to update the suspended MBMS or not.” (i.e., Fig.3, Par.77-78 outside network element sending to eNB that MBMS to be suspended because of an overload. Par.185,188-189 discloses of performing the operation back to normal such as adding back the suspended MBMS and that could be due to change in number users that were counted.) ) . 3GPP'233 in view of LEE’498 in view of Kadiri in further view of Ioffe and XU are considered to be analogous to the claimed invention because they are in the same field wireless communication. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified 3GPP'233 to implement the method of XU as its trying to solve on how to notify influed UEs by the eNB when the MCE is congested or overloaded thus allowing the user device to effectively track service availability and reduce the chances of being dropped by the network (XU, paragraph [0033], “However, it is found in a researching and practising process of the related technology that the following problem exists: for how to notify an eNB by an MCE and how to notify influenced UEs by the eNB when the MCE receives congestion or overload indication information and selects to suspend an MBMS, there are yet no solutions.”) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Erkin S. Abdullaev whose telephone number is (571)272-4135. The examiner can normally be reached Monday - Friday - 8:00 am - 5: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, Wesley Kim can be reached at (571)272-7867. 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. ERKIN S. ABDULLAEV Examiner Art Unit 2648 /ERKIN ABDULLAEV/Examiner, Art Unit 2648 /WESLEY L KIM/Supervisory Patent Examiner, Art Unit 2648 Application/Control Number: 18/718,034 Page 2 Art Unit: 2648 Application/Control Number: 18/718,034 Page 3 Art Unit: 2648 Application/Control Number: 18/718,034 Page 4 Art Unit: 2648 Application/Control Number: 18/718,034 Page 5 Art Unit: 2648 Application/Control Number: 18/718,034 Page 6 Art Unit: 2648 Application/Control Number: 18/718,034 Page 7 Art Unit: 2648 Application/Control Number: 18/718,034 Page 8 Art Unit: 2648 Application/Control Number: 18/718,034 Page 9 Art Unit: 2648 Application/Control Number: 18/718,034 Page 10 Art Unit: 2648 Application/Control Number: 18/718,034 Page 11 Art Unit: 2648 Application/Control Number: 18/718,034 Page 12 Art Unit: 2648 Application/Control Number: 18/718,034 Page 13 Art Unit: 2648 Application/Control Number: 18/718,034 Page 14 Art Unit: 2648 Application/Control Number: 18/718,034 Page 15 Art Unit: 2648 Application/Control Number: 18/718,034 Page 16 Art Unit: 2648 Application/Control Number: 18/718,034 Page 17 Art Unit: 2648 Application/Control Number: 18/718,034 Page 18 Art Unit: 2648 Application/Control Number: 18/718,034 Page 19 Art Unit: 2648 Application/Control Number: 18/718,034 Page 20 Art Unit: 2648 Application/Control Number: 18/718,034 Page 21 Art Unit: 2648 Application/Control Number: 18/718,034 Page 22 Art Unit: 2648 Application/Control Number: 18/718,034 Page 23 Art Unit: 2648 Application/Control Number: 18/718,034 Page 25 Art Unit: 2648 Application/Control Number: 18/718,034 Page 26 Art Unit: 2648 Application/Control Number: 18/718,034 Page 27 Art Unit: 2648 Application/Control Number: 18/718,034 Page 28 Art Unit: 2648 Application/Control Number: 18/718,034 Page 29 Art Unit: 2648 Application/Control Number: 18/718,034 Page 30 Art Unit: 2648 Application/Control Number: 18/718,034 Page 31 Art Unit: 2648 Application/Control Number: 18/718,034 Page 32 Art Unit: 2648 Application/Control Number: 18/718,034 Page 33 Art Unit: 2648 Application/Control Number: 18/718,034 Page 34 Art Unit: 2648 Application/Control Number: 18/718,034 Page 35 Art Unit: 2648 Application/Control Number: 18/718,034 Page 36 Art Unit: 2648 Application/Control Number: 18/718,034 Page 37 Art Unit: 2648 Application/Control Number: 18/718,034 Page 38 Art Unit: 2648 Application/Control Number: 18/718,034 Page 39 Art Unit: 2648 Application/Control Number: 18/718,034 Page 40 Art Unit: 2648 Application/Control Number: 18/718,034 Page 41 Art Unit: 2648 Application/Control Number: 18/718,034 Page 42 Art Unit: 2648 Application/Control Number: 18/718,034 Page 43 Art Unit: 2648
Prosecution Insights