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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/27/2024 and 03/05/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ishii (US 2020/0413452 A1) in view of Aminaka (US 2020/0305150 A1).
Regarding claim 1, Ishii discloses An apparatus configured for wireless communications, comprising: one or more memories, because Ishii teaches a wireless terminal with a random access procedure controller that stores and processes downlink information, necessarily implemented with memory: (Ishii, para [0050] “the terminal random access procedure controller 56, before receiving the MAC PDU, may monitor a downlink control signal to obtain resource allocation information for the downlink information that comprises the MAC PDU transmission. . . [0053] FIG. 3A shows example acts or steps specifically performed by wireless terminal 26A. The acts of FIG. 3A may be performed by terminal random access procedure controller 56, which may comprise the terminal processor 40 executing instructions stored on non-transient memory. Act 3A-1 comprises the wireless terminal 26A receiving configuration parameters broadcasted from the base station”)
Furthermore, Ishii discloses: and one or more processors coupled to the one or more memories, the one or processors being configured to cause the apparatus to: send a first signal in one or more first time-frequency resources associated with a random access channel (RACH), because Ishii teaches a wireless terminal that transmits a preamble sequence in a physical random access channel resource identified by its time and frequency location: (Ishii, para [0555] “The received preamble sequence tells the preamble index, and the PRACH resource ( time/ freq domain) where the preamble transmission was detected tells t_id and f_id.”)
Moreover, Ishii discloses: receive a random access response (RAR) indicating the first codeword, because a Random Access Response reception phase in which the terminal receives a MAC PDU carrying a MAC RAR and confirms an indication corresponding to the transmitted preamble (i.e., “codeword” as claimed): (Ishii, para [0051] “random access response checker 62 attempts to find from the downlink information the indication of successful receipt of the preamble sequence.”)
In addition, Ishii discloses: communicate with a network entity in response to receiving the RAR, because Ishii teaches upon confirming the RAR indication, the terminal completes the random access procedure and proceeds to further communication with the radio access node: (Ishii, para [0051] “then the random access response checker 62 can definitively confirm that the preamble sequence was successful sent to and received by radio access node 22A”)
Although Ishii teaches sending a preamble in identified PRACH time-frequency resources and receiving a random access response carrying an indication that confirms the transmitted preamble, then completing the procedure: (Ishii, [0050], [0051], [0555]), Ishii does not explicitly disclose multiplexing the first signal using a codeword such that the time-frequency resources together with the codeword define a preamble signature.
However, Ishii in view of Aminaka discloses wherein the first signal is multiplexed using a first codeword, the one or more first time frequency resources and the first codeword defining a first preamble signature because Aminaka teaches a mobile station selects a signature and transmits a preamble using that signature, and the base station identifies a preamble signature from the received preamble, so the code (signature) combined with the transmission resource defines the preamble signature relied upon for resource selection (Aminaka, para [0082], “The preamble identifying section 108 identifies a preamble signature from the preamble transferred from the uplink signal reception processing section 102, and sends its content to the resource configuration control section 109.” . . . [0016] “The preamble code data is generated using the preamble scrambling code emitted by the base station 10 and a preamble signature randomly selected (i.e., “the first codeword defining a first preamble signature” as claimed) by the mobile station. The base station 10 transmits a responsive notification (ACK/NACK) for the received preamble using the AICH signature state to the mobile station 20.).”)
Therefore, it would have been obvious to one of ordinary skill in the art to multiplex the preamble of Ishii using a code-based signature as taught by Aminaka, because Aminaka discloses identifying a preamble signature from a transmitted preamble to distinguish access attempts, and combining that code dimension with Ishii's time-frequency PRACH resource predictably expands the number of distinguishable preambles a base station can resolve, using known preamble-signature techniques for their established purpose.
Regarding claim 2, in spite of the fact that Ishii teaches receiving a random access response in a MAC PDU that carries the indication confirming the transmitted preamble, over Ishii's PRACH transmission combined with Aminaka's preamble signature: (Ishii, para. [0050], [0051]), Ishii does not explicitly disclose a data block partitioned into a first data portion for non codeword-based RARs and a second data portion for codeword-based RARs.
Yet, Ishii in view of Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to: receive a data block comprising a first data portion and a second data portion, the first data portion comprising one or more first RARs associated with non codeword-based RACH communications, the second data portion comprising one or more second RARs associated with codeword-based RACH communications, and the one or more second RARs comprising the RAR because a mobile station's reception processing section receives data from the base station that is separated by type, distinguishing a responsive notification in response to a preamble from a resource configuration list, showing reception of a data block having distinct portions handled differently (Aminaka, para [0090], “in a case that the data is a responsive notification in response to a preamble, it transfers the data to the responsive notification processing section 203; or in a case that the data is an E-DCH resource configuration list, it transfers the list to the resource configuration keeping section 205.”).
Moreover, Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to: receive a data block comprising a first data portion and a second data portion, the first data portion comprising one or more first RARs associated with non codeword-based RACH communications, the second data portion comprising one or more second RARs associated with codeword-based RACH communications, and the one or more second RARs comprising the RAR because the base station keeps a preamble signature list and issues responsive notifications keyed to the identified signature, so responses associated with signature (codeword) based access are grouped and returned separately from responses that are not signature specific, providing the second portion that carries the signature-indicating RAR (Aminaka, para [0084], “a preamble signature list containing prespecified information about preamble signatures available for E-RACH. The resource configuration control section 109 outputs the E-DCH resource configuration list and preamble signature list to the downlink signal transmission processing section 106”).
Thus, it would have been obvious to one of ordinary skill in the art to organize the response of Ishii into separate portions for signature-based and non-signature-based access as taught by Aminaka, because Aminaka discloses maintaining a preamble signature list and routing preamble responses by type, so partitioning the response data lets a terminal efficiently locate the response relevant to its signature-based transmission while preserving compatibility with legacy responses.
Regarding claim 3, although Ishii teaches receiving a random access response in a MAC PDU that carries an indication of the transmitted preamble, over Ishii's PRACH transmission combined with Aminaka's preamble signature: (Ishii, para. [0050], [0051], [0133]), Ishii does not explicitly disclose indicating the codeword via a field in a RAR header or bits in a RAR payload of the received data block.
Yet, Ishii in view of Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to: receive a data block comprising a RAR header and a RAR payload that is associated with the RAR header, the first codeword being indicated via at least one of (i) a field in the RAR header or (ii) one or more bits in the RAR payload because the base station transmits a responsive notification and, when a preamble signature is identified, sends an E-AICH signature and signature state, so the returned data block conveys both a header-type indicator (ACK/NACK) and an associated signature-carrying payload (Aminaka, para [0085], “a responsive notification NACK using AICH, and an E-AICH signature that is determined from an offset value between the default E-DCH resource configuration and the selected E -D CH resource configuration, and an E-AICH signature state using E-AICH are transmitted to the transmission processing section 106.”).
Moreover, Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to: receive a data block comprising a RAR header and a RAR payload that is associated with the RAR header, the first codeword being indicated via at least one of (i) a field in the RAR header or (ii) one or more bits in the RAR payload because the mobile station decodes the signature from the E-AICH signature pattern and state contained in the received response, showing that the signature (codeword) is indicated by dedicated bits carried in the response (Aminaka, para [0090], “an offset value obtained from the E-AICH signature decoded using the E-AICH signature pattern and the E-AICH signature state contained in E-AICH.”).
Consequently, it would have been obvious to one of ordinary skill in the art to indicate the signature (codeword) within the response header or payload of Ishii as taught by Aminaka, because Aminaka discloses conveying signature-specific state in the AICH/E-AICH response so the terminal can decode which signature its response corresponds to, and applying that indication to Ishii's MAC RAR predictably lets the terminal confirm its codeword-based preamble.
Regarding claim 4, which depends on claim 3, Ishii in view of Aminaka discloses wherein the field in the RAR header is associated with a random access preamble identifier (RAPID), and one or more values for the field are specific to codeword-based RACH communications, as Ishii further discloses a MAC PDU subheader carrying an E/T/RAPID field that identifies the transmitted preamble, where the RAPID field value corresponds to the particular preamble used, providing header field values keyed to the signature-based access (Ishii, para [0133] “the indication (e.g., RAPID) may be included in a subheader of a MAC PDU. The particular subheader in which the indication is included corresponds to the particular wireless terminal 26B”).
Regarding claim 5, even though Ishii teaches receiving a data block having a RAR header and associated payload that indicates the codeword, over Ishii combined with Aminaka: (Ishii, para. [0051], [0133]), Ishii does not explicitly disclose bits in the RAR payload that are specific to codeword-based RACH communications.
Yet, Ishii in view of Aminaka discloses The apparatus of claim 3, wherein the one or more bits in the RAR payload are specific to codeword-based RACH communications because the signature state is decoded from bits of the E-AICH response that are meaningful only for signature-based access, so the payload bits carrying the E-AICH signature and state are specific to codeword-based communications (Aminaka, para [0090], “an offset value obtained from the E-AICH signature decoded using the E-AICH signature pattern and the E-AICH signature state contained in E-AICH.”).
Therefore, it would have been obvious to one of ordinary skill in the art to carry signature-specific bits in the response payload of Ishii as taught by Aminaka, because Aminaka discloses that the E-AICH signature and state bits are decoded only for signature-based access, so dedicating payload bits to the codeword-based case predictably lets the terminal resolve its codeword without ambiguity.
Regarding claim 6, in spite of the fact that Ishii teaches receiving a random access response scheduled on a downlink channel, over Ishii's PRACH transmission combined with Aminaka's preamble signature: (Ishii, para. [0050], [0596]), Ishii does not explicitly disclose DCI scrambled with an RA-RNTI specific to codeword-based RACH communications that schedules the RAR.
Yet, Ishii in view of Aminaka discloses wherein the one or more processors are configured to cause the apparatus to: receive downlink control information (DCI) scrambled with a random access radio network temporary identifier (RA-RNTI) that is specific to codeword-based RACH communications because the base station keeps a per-signature preamble list and issues signature-specific responsive notifications, so scrambling the scheduling identifier to be specific to a signature (codeword) based attempt follows from tying the response identifier to the identified preamble signature (Aminaka, para [0084], “a preamble signature list containing prespecified information about preamble signatures available for E-RACH.”).
Moreover, Aminaka discloses wherein the DCI indicates scheduling for the RAR because the mobile station learns of an E-DCH resource configuration for use from the responsive notification associated with its signature, showing the response controls the resources the terminal then uses, i.e. scheduling tied to the signature-based response (Aminaka, para [0091], “determines an E-DCH resource configuration for use in E-RACH from the responsive notifications for AICH and E-AICH supplied via the responsive notification processing section 203”).
Accordingly, it would have been obvious to one of ordinary skill in the art to schedule the RAR of Ishii with a signature-specific control identifier as taught by Aminaka, because Ishii already scrambles its downlink control information with an RNTI for resource assignment and Aminaka ties responses to identified preamble signatures, so making the scheduling identifier specific to codeword-based access predictably lets the terminal find the response addressed to its signature.
Regarding claim 7, even though Ishii teaches receiving a signature-scheduled random access response, over Ishii combined with Aminaka, with Ishii teaching backoff handling in the RAR: (Ishii, para. [0295], [0330]), Ishii does not explicitly disclose a backoff value received with the RAR that is specific to codeword-based RACH communications and governs a subsequent RACH occasion.
Yet, Ishii in view of Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to receive the RAR and an indication of a backoffvalue in accordance with the scheduling, the backoff value being associated with a RACH occasion for sending a subsequent RACH preamble transmission because Ishii sets a backoff parameter value from a Backoff Indicator subheader and delays the subsequent random access transmission accordingly, while Aminaka ties the retransmission control to the identified signature so the backoff governs the next signature-based attempt (Aminaka, para [0119], “the retransmission counter M is decremented by one ( Step S310), a predetermined period of time is waited ( Step S311), and the flow goes back to the preamble transmitting step ( Step S304).”).
Moreover, Aminaka discloses wherein the backoff value is specific to codeword-based RACH communications because because the retransmission and its waiting period are driven by the signature-based E-AICH response outcome, the applied backoff period is specific to signature (codeword) based access (Aminaka, para [0090], “The responsive notifications for AICH and E-AICH are transferred to the transmission data control section 204.”).
Thus, it would have been obvious to one of ordinary skill in the art to make the backoff of Ishii specific to signature-based access as taught by Aminaka, because Aminaka governs preamble retransmission timing based on the signature-keyed response, so applying a codeword-specific backoff to Ishii's retransmission predictably tunes contention handling for signature-based access.
Regarding claim 8, although Ishii teaches receiving a MAC PDU containing a Backoff Indicator subheader and the RAR, over Ishii combined with Aminaka: (Ishii, para. [0055], [0295]), Ishii does not explicitly disclose a BI header with a BI field and additional bits that indicate a backoff value specific to codeword-based RACH communications for a subsequent RACH occasion.
Yet, Ishii in view of Aminaka discloses wherein to receive the RAR, the one or more processors are configured to cause the apparatus to receive a data block comprising a backoff indicator (BI) header and the RAR, the BI header comprising a BI field and one or more bits because Ishii's MAC PDU includes a Backoff Indicator subheader with E/T/R/R/BI fields alongside the MAC RAR, and Aminaka's signature-based responses provide the additional signature-keyed bits that accompany the backoff for codeword-based access (Aminaka, para [0085], “an E-AICH signature that is determined from an offset value between the default E-DCH resource configuration and the selected E -D CH resource configuration, and an E-AICH signature state using E-AICH are transmitted”).
Moreover, Aminaka discloses wherein the BI field and the one or more bits are associated with a RACH occasion for sending a subsequent RACH preamble transmission because the decoded signature and state control whether and when the mobile station returns to the preamble transmitting step, associating those bits with the subsequent access occasion (Aminaka, para [0119], “a predetermined period of time is waited ( Step S311), and the flow goes back to the preamble transmitting step ( Step S304).”).
Furthermore, Aminaka discloses wherein the BI field and the one or more bits indicate a backoff value that is specific to codeword-based RACH communications because since the waiting period is determined from the signature-based response outcome, the indicated backoff value is specific to signature (codeword) based access (Aminaka, para [0090], “The responsive notifications for AICH and E-AICH are transferred to the transmission data control section 204.”).
Consequently, it would have been obvious to one of ordinary skill in the art to make Ishii's Backoff Indicator bits carry a signature-specific backoff as taught by Aminaka, because Aminaka's signature-keyed response controls retransmission timing, so extending Ishii's BI subheader with codeword-specific bits predictably lets the terminal apply a backoff tuned to its signature-based access.
Regarding claim 9, even though Ishii teaches sending a preamble multiplexed with a signature that, with the resource, defines a preamble signature, over Ishii combined with Aminaka: (Ishii, para. [0555]), Ishii does not explicitly disclose the first codeword being associated with code division multiplexing.
Yet, Ishii in view of Aminaka discloses The apparatus of claim 1, wherein the first codeword is associated with code division multiplexing because the signature distinguishes among preambles transmitted on shared RACH resources, so distinct signatures let multiple access attempts coexist on the same time-frequency resource, which is code-based multiplexing of the preamble (Aminaka, para [0082], “The preamble identifying section 108 identifies a preamble signature from the preamble transferred from the uplink signal reception processing section 102”).
For these reasons, it would have been obvious to one of ordinary skill in the art to associate the signature of Aminaka with code division multiplexing of Ishii's preamble, because using distinct signatures to separate simultaneous preambles on shared resources is code-based multiplexing, predictably increasing the number of terminals that can access the same RACH resource.
Regarding claim 11, An apparatus configured for wireless communications, comprising: one or more memories; and one or more processors coupled to the one or memories, the one or more processors being configured to cause the apparatus to: obtain a first signal in one or more first time-frequency resources associated with a random access channel (RACH), wherein the first signal is multiplexed using a first codeword, the one or more first time-frequency resources and the first codeword defining a first preamble signature; send a random access response (RAR) indicating the first codeword; and communicate with a user equipment in response to sending the RAR. . Claim 11 is analogous to claim 1 and is rejected for the same reasons.
Regarding claim 12, The apparatus of claim 11, wherein to send the RAR, the one or more processors are configured to cause the apparatus to: send a data block comprising a first data portion and a second data portion, the first data portion comprising one or more first RARs associated with non-codeword-based RACH communications, the second data portion comprising one or more second RARs associated with codeword-based RACH communications, and the one or more second RARs comprising the RAR. Claim 12 is analogous to claim 2 and is rejected for the same reasons.
Regarding claim 13, The apparatus of claim 11, wherein to send the RAR, the one or more processors are configured to cause the apparatus to: send a data block comprising a RAR header and a RAR payload that is associated with the RAR header, the first codeword being indicated via at least one of (i) a field in the RAR header or (ii) one or more bits in the RAR payload. Claim 13 is analogous to claim 3 and is rejected for the same reasons.
Regarding claim 14. The apparatus of claim 13, wherein the field in the RAR header is associated with a random access preamble identifier (RAPID), and one or more values for the field are specific to codeword-based RACH communications. Claim 14 is analogous to claim 4 and is rejected for the same reasons.
Regarding claim 15. The apparatus of claim 13, wherein the one or more bits in the RAR payload are specific to codeword-based RACH communications. Claim 15 is analogous to claim 5 and is rejected for the same reasons.
Regarding claim 16. The apparatus of claim 11, wherein the one or more processors are configured to cause the apparatus to: send downlink control information (DCI) scrambled with a random access radio network temporary identifier (RA-RNTI) that is specific to codeword-based RACH communications, wherein the DCI indicates scheduling for the RAR. Claim 16 is analogous to claim 6 and is rejected for the same reasons.
Regarding claim 17. The apparatus of claim 16, wherein to send the RAR, the one or more processors are configured to cause the apparatus to send the RAR and an indication of a backoff value in accordance with the scheduling, the backoff value being associated with a RACH occasion for a user equipment to send a subsequent RACH preamble transmission, and the backoff value is specific to codeword-based RACH communications. Claim 17 is analogous to claim 7 and is rejected for the same reasons.
Regarding claim 18. The apparatus of claim 11, wherein to send the RAR, the one or more processors are configured to cause the apparatus to send a data block comprising a backoff indicator (BI) header and the RAR, the BI header comprising a BI field and one or more bits, wherein the BI field and the one or more bits are associated with a RACH occasion for a user equipment to send a subsequent RACH preamble transmission, and the BI field and the one or more bits indicate a backoff value that is specific to codeword-based RACH communications. Claim 18 is analogous to claim 8 and is rejected for the same reasons.
Regarding claim 19. The apparatus of claim 11, wherein the first codeword is associated with code division multiplexing. Claim 19 is analogous to claim 9 and is rejected for the same reasons.
Regarding claim 20, the claim recites: A method of wireless communications by an apparatus, comprising: sending a first signal in one or more first time-frequency resources associated with a random access channel (RACH), wherein the first signal is multiplexed using a first codeword, the one or more first time-frequency resources and the first codeword defining a first preamble signature; receiving a random access response (RAR) indicating the first codeword; and communicating with a network entity in response to receiving the RAR. Claim 20 is analogous to claim 1 and is rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHONGSUH PARK/Examiner, Art Unit 2478
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHONGSUH PARK/Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
Prosecution Insights