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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
This office action has been issued in response to arguments/amendments filed on 12/23/2025. Claims 1 and 20 are amended. Claims 2 and 21 are cancelled. Claims 1, 3, 5-6, 8-13, 15-16, 20, 22, 24-26, and 29 are presented for examination.
Response to Arguments
Applicant's arguments see pages 1-5, filed on 12/23/2025, with respect to the rejection of claims 1, 3, 5-6, 8-13, 15-16, 20, 22, 24-26, and 29 under 35 USC § 102(a)(1) have been fully considered but they are not persuasive.
2. Applicant argues regarding the rejection of claim 1, as recited in page 3, “Though Kim describes integrity protection and verification procedure, Kim does not disclose the obtaining of configuration data including parameters for integrity protection and verification.” Examiner has considered the applicants’ argument but they are not persuasive. Examiner respectfully points out that Kim discloses in (para. [0605]) that when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive (i.e. obtained) and generate (i.e. obtained) a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification where clearly shows that ADAP layer is obtained parameters by derived and generated. Further, the claimed language does not clearly stated, parameters obtained from other entity. Therefore, the rejection is maintained.
3. Applicant argues regarding the rejection of claim 20, as recited in page 5, “Though Kim describes establishment of RRC connection or release from base station to UE, Kim does not disclose releasing of the connection between the IAB nodes in case of failure of integrity protection and verification procedure”. Examiner respectfully points out that the features upon which applicant argue (i.e., “in case of failure of integrity protection and verification procedure”) are not recited in claim 1 as filed.
Although the claims are interpreted in light of the specification, limitations (i.e., “in case of failure of integrity protection and verification procedure”) from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Further, the reference Kim clearly teaches the limitation as claimed (“performing the at least one action comprises releasing a radio resource control, RRC, connection between the IAB node and the second IAB node”) in (para. [0159]) that the when the UE configured to transmit and receive data in an RRC connected mode does not transmit or receive data due to a predefined reason or for a predefined time, a gNB may transmit an RRCConnection Release message to the UE so as to allow the UE to transit to an RRC idle mode or an RRC inactive mode. Therefore, the rejection is maintained.
4. In response to applicant’s amendment regarding the rejection of claims 1 and 20, filed on 12/23/2025 have been fully considered but they are not persuasive. The examiner-maintained rejection set forth in previous office action. Response to applicant’s argument regarding prior art will be address below for clarification.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
5. Claims 1-3, 5-6, 8-13, 15-16, 20-22, 24-26, 29 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kim et al. (US Publication No. 2020/0221329, hereinafter “Kim”).
Regarding claim 1, Kim does disclose a method performed by a first node comprising: obtaining a configuration for performing backhaul integrity protection and verification for backhaul adaptation protocol, BAP, data protocol data unit, PDU, packets transmitted and/or received over a backhaul link (Kim, (para. [0597]), the ADAP layer described in the disclosure may also be called different names including a multi-hop adaptation protocol (MAP) layer, a backhaul adaptation protocol (BAP) layer, and the like; (para. [0604]), the ciphering and deciphering algorithm or the integrity protection or verification algorithm may be configured by an upper parent radio node (a parent IAB node) or an uppermost radio node (an IAB donor), and whether to activate (or configure) each function, or a security key (e.g., a public key, a private key, an authentication key, or the like) may also be determined and configured by the upper parent radio node or the uppermost radio node);
computing a security token to be included in a BAP data PDU to be transmitted (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification);
adding the security token in the BAP data PDU (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-! field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification); and
transmitting the BAP data PDU with the security token towards a second IAB node (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification),
wherein obtaining the configuration comprises obtaining parameters for using in performing the backhaul integrity protection and verification (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification; (para. [0597]), the ADAP layer described in the disclosure may also be called different names including a multi-hop adaptation protocol (MAP) layer, a backhaul adaptation protocol (BAP) layer, and the like).
2. (Cancel)
Regarding claim 3, Kim further discloses the method of claim 2, wherein obtaining the parameters comprises obtaining one or more of: an identification, ID, of the backhaul, BH, radio link control, RLC, channel ID associated to the BAP PDU to be protected; security keys comprising a root key and/or derived keys for integrity protection; a D/C bit indicating if the PDU is a BAP Control PDU or a BAP Data PDU, one or more reserved bits, R, and a T bit to indicate presence/absence of a token field; a refresh token for providing replay protection; an IAB node destination identity of the BAP data PDU to be protected; a path identity over which the BPA data PDU to be protected is transmitted; and a security algorithm identity of a security algorithm to use for integrity protection, wherein computing a security token comprises computing the security token based on the security algorithm identity (Kim, (para. [0528]), when a transmission link is present in wireless backhaul routing configuration information configured via an RRC message, the transmission link having a destination address or a path identifier which is the same as a BAP address or a BAP path identifier which corresponds to the first data; (para. [0604]), … a procedure of establishing a security key or a security algorithm (ciphering and deciphering, or integrity protection or integrity verification), based on a hop-by-hop security association establishment procedure, may be applied and used).
4. (canceled)
Regarding claim 5, Kim further discloses the method of claim 1, wherein adding the security token in the BAP data PDU comprises: setting a field in a BAP header to indicate presence of the security token (Kim, (para. [0528, 0604]), the IAB-DU may receive the first data (e.g., the BAP PDU) and may identify a BAP address of a BAP header or a BAP path identifier. When the BAP address of the BAP header is a BAP address of the IAB-node 2 2h-2-20, the first data is to be received and processed by the IAB-node 2 2h-2-20, such that the IAB-node 2 2h-2-20 may process the data as the BAP SDU and may transfer the data to an upper layer. When the BAP address of the BAP header is not the BAP address of the IAB-node 2 2h-2-20, the IAB-node 2 2h-2-20 may transfer the first data (or the BAP SDU) to a transmission part of the IAB-node 2 2h-2-20 or the BAP layer of the IAB-MT).
Regarding claim 6, Kim further discloses the method of claim 1, further comprising responsive to receiving a BAP data PDU having a security token to be forwarded to a next IAB node: relaying the security token included in the BAP data PDU received to the next IAB node without modifying the security token, or performing integrity protection verification on the BAP data PDU received (Kim, (para. [0531]), when UL backhaul configuration information or routing information does not exist, …. The IAB-DU of the IAB-node 2 2h-2-20 may receive the second data via the MAC layer, the RLC layer (or the RLC channel) or the BAP layer. The IAB-DU may receive the first data (e.g., the BAP PDU) and may identify a BAP address of a BAP header or a BAP path identifier).
7. (canceled)
Regarding claim 8, Kim further discloses the method of claim 6 wherein the BAP data PDU has multiple security tokens and performing integrity protection verification comprises performing integrity protection verification on a security token of the multiple security tokens meant for the IAB node (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification).
Regarding claim 9, Kim further discloses the method of claim 6, wherein performing integrity protection verification comprises generating a token based on parameters associated to the BAP data PDU (Kim, (para. [0605]), when the ADAP layer applies an integrity protection or verification procedure to an upper layer header (e.g., the ADAP header or an upper layer header) or data, the ADAP layer may derive and generate a usage value of separate security/authentication code (e.g., token, a checksum field or an MAC-I field) and then may configure and transmit the usage value together with the upper layer header or the data to which integrity protection is applied, such that an ADAP layer of a receiver may perform integrity verification).
Regarding claim 10, Kim further discloses the method of claim 1, further comprising: responsive to receiving a BAP data PDU for the IAB node, performing integrity protection verification on the BAP data PDU received (Kim, (para. [0531, 0605]), when UL backhaul configuration information or routing information does not exist, …. The IAB-DU of the IAB-node 2 2h-2-20 may receive the second data via the MAC layer, the RLC layer (or the RLC channel) or the BAP layer. The IAB-DU may receive the first data (e.g., the BAP PDU) and may identify a BAP address of a BAP header or a BAP path identifier).
Regarding claim 11, Kim further discloses the method of claim 6, further comprising: responsive to the integrity protection verification results in determining that the BAP data PDU is not valid, discarding the BAP data PDU (Kim, (para. [0376]), there is a need for a method of detecting an error and verifying integrity or enhancing security, wherein the error may occur in a wireless transmission section when data is transmitted from each radio node (an integrated access backhaul (IAB) node, an IAB donor or a UE) in a network architecture supporting wireless backhaul or IAB).
Regarding claim 12, Kim further discloses the method of claim 6, further comprising: responsive to the integrity protection verification results in determining that the BAP data PDU is not valid, transmitting an indication to a central unit IAB node that the BAP data PDU has been declared as not valid due to an unsuccessful security protection verification (Kim, (para. [0605]), the ADAP layer of the receiver may perform an integrity verification procedure on the received header or received data (e.g., the receiver derives separate security/authentication code by itself) and may compare the derived separate security/authentication code with the separate security/authentication code included in the received header or received data, thereby checking whether values are equal. When the values are equal, integrity verification may be regarded to be successful, and when the values are different from each other, the integrity verification may be regarded to have failed).
Regarding claim 13, Kim further discloses the method of claim 6, further comprising: responsive to the integrity protection verification results in determining that the BAP data PDU is not valid, performing a Radio Resource Control, RRC, connection reestablishment, and wherein performing the RRC connection reestablishment comprises performing the RRC connection reestablishment to an IAB node different from the one from which the BAP data PDU received that was determined to not be valid (Kim, (para. [0607]), ADAP control data (an ADAP control PDU) may be defined such that a security key (or a part of the security key) may be shared or verified between ADAP layers (radio nodes) by using the ADAP control data, not an RRC message. The ADAP control data may indicate the security key, a radio node identifier, a security algorithm (or method), or the like, may indicate whether reception of the ADAP control data or ADAP layer data is successful, and may include an indicator to activate or inactivate a ciphering and deciphering procedure, or an integrity protection or verification procedure).
14. (canceled)
Regarding claim 15, Kim further discloses the method of claim 6, further comprising: responsive to the integrity protection verification results in determining that the BAP data PDU is not valid, keeping a log of BAP data PDUs that are not valid and informing higher layers of the BAP data PDU that has been declared as not valid due to an unsuccessful security protection verification (Kim, (para. [0606-0607]), ADAP control data (an ADAP control PDU) may be defined such that a security key (or a part of the security key) may be shared or verified between ADAP layers (radio nodes) by using the ADAP control data, not an RRC message. The ADAP control data may indicate the security key, a radio node identifier, a security algorithm (or method), or the like, may indicate whether reception of the ADAP control data or ADAP layer data is successful, and may include an indicator to activate or inactivate a ciphering and deciphering procedure, or an integrity protection or verification procedure).
Regarding claim 16, Kim further discloses the method of claim 6, further comprising: responsive to the integrity protection verification results in determining that the BAP data PDU is valid, removing the header, including the security token and forwarding content of the BAP data PDU to higher layers and to a transmitting entity if the BAP data PDU has to be relayed to a next hop (Kim, (para. [0605]), the ADAP layer of the receiver may perform an integrity verification procedure on the received header or received data (e.g., the receiver derives separate security/authentication code by itself) and may compare the derived separate security/authentication code with the separate security/authentication code included in the received header or received data, thereby checking whether values are equal. When the values are equal, integrity verification may be regarded to be successful, and when the values are different from each other, the integrity verification may be regarded to have failed).
17.-19. (canceled)
Regarding claim 20, Kim does disclose a method performed by a central unit, CU, Integrated Access and Backhaul, IAB, node comprising: receiving an indication from an IAB node; responsive to the indication being of a received invalid BAP PDU caused by a second IAB node (Kim, (PARA. [0533, 0528-0529]), in a case where a F1 interface-related message is generated in an IAB node, a BAP layer of an IAB-MT of the IAB node, when a transmission link is present in wireless backhaul routing configuration information configured via an RRC message, the transmission link having a destination address or a path identifier which is the same as a BAP address or a BAP path identifier which corresponds to second data (or a BAP PDU or a BAP SDU), the BAP layer of the IAB-MT may select the transmission link and may determine transmission via the transmission link. Also, in a case where the BAP layer of the IAB-MT receives data from an upper layer, when wireless backhaul RLC channel mapping configuration information for a BAP SDU that receives the F1 interface-related message does not exist, the BAP layer may select a default RLC channel configured based on an RRC message. When the wireless backhaul RLC channel mapping configuration information for the BAP SDU or the F1 interface-related message exists, the BAP layer may select a RLC channel based on the mapping information. Also, when wireless backhaul configuration information or routing information does not exist, the BAP layer may select a default BAP address or a default BAP path identifier which is configured based on an RRC message, may transmit the BAP PDU, and thus may transmit the F1 interface-related message to the IAB-node 2 2h-2-20 via the default RLC channel, a selected RLC channel, or a RLC layer corresponding to the default RLC channel or the selected RCL channel, and a MAC layer), performing at least one action to prevent the second IAB node from further attacks (Kim, (para. [0539]), when the UE-accessed radio node 2i-11 or the uppermost node 2i-13 receives the data, the separate upper layer may perform deciphering or integrity verification, thereby defending against an unexpected attack or checking an error of the data error or integrity of the data),
wherein performing the at least one action comprises releasing a radio resource control, RRC, connection between the IAB node and the second IAB node (Kim, (para. [0159]), when the UE configured to transmit and receive data in an RRC connected mode does not transmit or receive data due to a predefined reason or for a predefined time, a gNB may transmit an RRCConnection Release message to the UE so as to allow the UE to transit to an RRC idle mode or an RRC inactive mode).
21. (Cancel).
Regarding claim 22, Kim further discloses the method of claim 20, wherein performing the at least one CU IAB node action further comprises updating routing tables of IAB node such that the second IAB node is excluded from an IAB network topology, or releasing RRC connections and F1 connections of the second IAB node (Kim, (para. [0159]), when the UE configured to transmit and receive data in an RRC connected mode does not transmit or receive data due to a predefined reason or for a predefined time, a gNB may transmit an RRCConnectionRelease message to the UE so as to allow the UE to transit to an RRC idle mode or an RRC inactive mode (1e-01). Afterward, when the UE that is not currently configured for connection (hereinafter, also referred to as the idle-mode UE) has data to be transmitted, the UE may perform an RRC connection establishment process or an RRC connection resume procedure on the gNB; (para. [0374]), … release dual connectivity to or from the UE).
23. (canceled)
Regarding claim 24, Kim further discloses the method of claim 20, further comprising: transmitting a configuration for performing backhaul integrity protection and verification for backhaul adaptation protocol, BAP, data protocol data unit, PDU, packets transmitted and/or received over a backhaul link to the IAB node (Kim, (para. [0605]), the ADAP layer of the receiver may perform an integrity verification procedure on the received header or received data (e.g., the receiver derives separate security/authentication code by itself) and may compare the derived separate security/authentication code with the separate security/authentication code included in the received header or received data, thereby checking whether values are equal. When the values are equal, integrity verification may be regarded to be successful, and when the values are different from each other, the integrity verification may be regarded to have failed).
Regarding claim 25, Kim further discloses the method of claim 20, wherein the second IAB node comprises an attacking IAB node (Kim, (para. [0596]), the second PDCP layer configured below the ADAP layer of the radio node according to each bearer or each RLC channel receives data from a lower layer and performs integrity verification on the data, and in this regard, when the integrity verification fails, the second PDCP layer may regard the data as attack and thus may perform protection by discarding the data).
Regarding claim 26, the substance of the claimed invention is similar to that of claim 1. Accordingly, this claim is rejected under the same rationale.
27.-28. (canceled)
Regarding claim 29, the substance of the claimed invention is similar to that of claim 20. Accordingly, this claim is rejected under the same rationale.
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 extension fee 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 MORSHED MEHEDI whose telephone number is (571) 270-7640. The examiner can normally be reached on M - F, 8:00 am to 4:00 pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Linglan Edwards can be reach on (571) 270-5440. The fax number for the organization where this application or proceeding is assigned is (571) 273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from their Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (In USA or Canada) or 571-272-1000.
/MORSHED MEHEDI/Primary Examiner, Art Unit 2408