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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/29/2025 has been entered.
Status of Claims
Claims 1-2, 4, 9, 14, 16-21, 23, 25-26, 29, 124-125, 127-132, 134-138 are pending. Claims 3, 5-8, 10-13, 15, 22, 24, 27-28, 30-123, 126, 133 are cancelled.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 4, 9, 14, 16-21, 23, 25-26, 29, 124-125, 127-132, 134-138 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huawei et al (“Security of INACTIVE to CONNECTED State Transition”, 3GPP Draft, dated 2/15/2018), and further in view of Ingale et al (PGPUB 2020/0214070).
Regarding Claims 1 and 29:
Huawei teaches a method for wireless communications by a user equipment (UE), and an apparatus for wireless communications, comprising:
a receiver configured to receive, from a first network node, a first radio resource control (RRC) Release message (page 2, Fig. 1, User Equipment (UE) receives RRCConnectionRelease message from Last serving gNB); and
a transmitter configured to transmit, to a second network node different from the first network node, an RRC Resume Request message comprising at least one portion integrity protected with a first integrity protection key (page 2, paragraph 1, Fig. 1, RRC Re-Activation Request (no encryption, integrity with old key); RRC Connection Re-Activation request kind of message protected with old integrity protection key, i.e. “at least one portion”).
Huawei does not explicitly teach the first radio resource control (RRC) Release message integrity protected with a first integrity protection key and encrypted with a first encryption key, wherein the first integrity protection key and the first encryption key are derived from a first key, and the first RRC Release message comprises information for deriving a second key different from the first key;
the receiver is further configured to receive, from the second network node, a second RRC Release message different from the first RRC Release message while a context of the UE is stored at the first network node without transfer to the second network node, the second RRC Release message being integrity protected with a second integrity protection key derived from the second key and encrypted with a second encryption key derived from the second key, the apparatus further comprising:
one or more processors collectively or individually configured to process the second RRC Release message based on the second key; and
one or more memories a memory coupled to the at least one or more processors.
However, Ingale teaches the concept of a first radio resource control (RRC) Release message integrity protected with a first integrity protection key and encrypted with a first encryption key (paragraph 170-171, the method includes receiving a release message (i.e. “first message”) on SRB1 from the RAN node 104; the release message received on the SRB1 is to transition the UE 102 to either the idle state or move back the UE to inactive state; the release message is integrity protected with a new RRC integrity security key (i.e. KRRCint) and ciphered with a new RRC encryption security key (i.e. KRRCenc)), wherein the first integrity protection key and the first encryption key are derived from a first key (paragraph 171, The UE 102 further derives the new KRRCint and new KRRCenc from the derived KgNB* (i.e. “first key”) to receive the release message sent on SRB1), and the first RRC Release message comprises information for deriving a second key different from the first key (paragraph 171, the RRC release message sent on SRB1 to move UE back to RRC inactive state includes at least a new Resume ID i.e. I-RNTI, new paging parameters and a new NCC (i.e. “information for deriving a second key different from the first key”); paragraph 161, UE 102 derives the KgNB* (i.e. “second key”) based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state; the UE 102 further derives the new KRRCint and new KRRCenc from the derived KgNB* to receive the resume message sent on SRB1);
a receiver configured to receive, from a second network node, a second RRC Release message different from the first RRC Release message while a context of the UE is stored at a first network node without transfer to the second network node (paragraph 190-193, Fig. 5A, after the data exchange between UE 102 and Serving gNB 104b, the UE 102 is sent to inactive state with the transmission of RRC release message (501a) (i.e. “first RRC Release message”); the UE is provided with Resume ID, RAN paging parameters and a NCC in the release message (501a) which is implicit indication to move to inactive state; in order to establish a security context (especially a key), a count value (n-hop forward security) and a next-hop chaining count (NCC) is received in a RRC connection release message (501a) from a serving gNB 104a; the serving gNB 104a stores the UE context and the N2/N3 connection of the UE with AMF/SMF and UPF is maintained; the UE 102 sends (506a) a connection resume request message (i.e. MSG3) on SRB0, including the Short MAC-I (or MAC-I i.e. authentication token) calculated based on existing key i.e. KRRCint associated with the last serving gNB 104a; upon reception of the resume request message (506a) the target gNB 104b transmits (508a) a request for retrieving the UE context on the Xn interface; the target gNB 104b identifies the Serving gNB 104a to retrieve the UE context based on the Resume ID included in the resume request message (506a); paragraph 169, the method includes transmitting a resume request message on SRB0 to the RAN node 104 for performing RAN paging area update; paragraph 172, the RAN node transmits a RRC release message to the UE on SRB1 to move the UE back to idle state in response to the resume request message (i.e. “second RRC Release message”); EXAMINER’S NOTE: as per paragraph 190-194, Fig. 5a, MSG 4 is sent following the Retrieve UE context Response between the Serving gNB and the Target gNB, not ; therefore, the receiver (i.e. “UE”) receives MSG 4 (i.e. “second RRC Release message”) “while” a context of the UE is stored at a first network node without transfer to the second network node (i.e. the transfer happens before this step, not during)), the second RRC Release message being integrity protected with a second integrity protection key derived from the second key and encrypted with a second encryption key derived from the second key (paragraph 170-171, the method includes receiving a release message (i.e. “second RRC Release message”) on SRB1 from the RAN node 104; the release message received on the SRB1 is to transition the UE 102 to either the idle state or move back the UE to inactive state; the release message is integrity protected with a new RRC integrity security key (i.e. KRRCint) and ciphered with a new RRC encryption security key (i.e. KRRCenc); paragraph 171, UE 102 derives the KgNB* (i.e. “second key”) based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state; the UE 102 further derives the new KRRCint and new KRRCenc from the derived KgNB* to receive the release message sent on SRB1), the apparatus further comprising:
one or more processors collectively or individually configured to process the second RRC Release message based on the second key (paragraph 111, processor executing instructions; paragraph 171, UE 102 derives the KgNB* (i.e. “second key”) based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state; the UE 102 further derives the new KRRCint and new KRRCenc from the derived KgNB* to receive the release message sent on SRB1); and
one or more memories a memory coupled to the at least one or more processors (paragraph 112, computer program instructions may also be stored in a computer usable or computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the protected first message teachings of Ingale with the key determination teachings of Huawei, in order to improve the security of the system by encrypting and integrity protecting the first message, thereby preventing interception by an attacker without the encryption key or errors/impersonation using the integrity key.
Regarding Claims 2 and 124:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 29. In addition, Ingale teaches wherein:
the second RRC Release message comprises one or more indications (paragraph 171, the RRC release message sent on SRB1 to move UE back to RRC inactive state includes at least a new Resume ID i.e. I-RNTI, new paging parameters and a new NCC);
the one or more processors are collectively or individually configured to determine the second key based in part on the one or more indications (paragraph 170-171, the method includes receiving a release message (i.e. “second RRC Release message”) on SRB1 from the RAN node 104; the release message received on the SRB1 is to transition the UE 102 to either the idle state or move back the UE to inactive state; the release message is integrity protected with a new RRC integrity security key (i.e. KRRCint) and ciphered with a new RRC encryption security key (i.e. KRRCenc); paragraph 171, UE 102 derives the KgNB* (i.e. “second key”) based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state); and
Huawei teaches the second message comprises a packet data convergence protocol (PDCP) header (page 2 paragraph 2, the new gNB can provide the NCC; in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header); and
the one or more indications comprises a count value in the PDCP header (page 2 paragraph 2, the new gNB can provide the NCC (i.e. “Next hop chaining counter”); in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header).
The rationale to combine Huawei and Ingale is the same as provided in claims 1 and 29, due to the overlapping subject matter between claims 1 and 2, 29 and 124.
Regarding Claims 4, 125:
Huawei in view of Ingale teaches the method of claim 2 and the apparatus of claim 124. In addition, Ingale teaches, wherein:
the count value is a non-initial value (paragraph 161, UE 102 derives the KgNB* based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state; EXAMINER’S NOTE: “non-initial value” can essentially be seen as any value in the absence of a definition of what is specifically meant by “non-initial”); and
the non-initial value indicates anchor non-relocation (paragraph 18-19, resume procedure; target eNB may be the same as source eNB; therefore, the count value indicates both relocation and non-relocation).
The rationale to combine Huawei and Ingale is the same as provided in claims 2 and 124, due to the overlapping subject matter between claims 2 and 4, 124 and 125.
Regarding Claims 9, 127:
Huawei in view of Ingale teaches the method of claim 2 and the apparatus of claim 124. In addition, Huawei teaches wherein:
the one or more indications comprise an indication of whether one or more parameters for deriving the second key are associated with the first network node or the second network node (page 2 paragraph 2, when receiving the RRC Connection Re-Activation message, the UE would get the new NCC and/or algorithm from PDCP or MAC in order to decipher the RRC Connection Re-Activation message; therefore, there is an “indication” that the parameters are “associated” with the second network node).
Regarding Claim 14:
Huawei in view of Ingale teaches the method of claim 9. In addition, Huawei teaches wherein:
the one or more indications are provided in a medium access control (MAC) control element (CE) (page 2 paragraph 2, in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header or MAC CE); or
the one or more indications are provided in a packet data convergence protocol (PDCP) control protocol data unit (PDU) (page 2 paragraph 2, in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header or MAC CE).
Regarding Claim 16:
Huawei in view of Ingale teaches the method of claim 9. In addition, Ingale teaches wherein the one or more parameters comprise at least one of an absolute radio frequency channel number (ARFCN) or a physical cell identifier (PCI) (paragraph 215, the Counter received in connection release message or MSG4, PCI of the camped cell, 5G NR Absolute Radio Frequency Channel Number-Down Link (5G-ARFCN-DL) of the camped cell and other possible inputs are used to derive the new key, when the UE 102 is INACTIVE state).
The rationale to combine Huawei and Ingale is the same as provided in claim 9, due to the overlapping subject matter between claims 9 and 16.
Regarding Claims 17, 128:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 29. In addition, Huawei teaches wherein the one or more processors are collectively or individually configured to at least one of:
assume that the second RRC Release message is always integrity protected and encrypted based on the second key; or
assume that one or more parameters for deriving the second key are always associated with the second network node (page 2 paragraph 2, when receiving RRC Connection Re-Activation message, UE would get the new NCC and/or algorithm from PDCP or MAC in order to decipher the RRC Connection Re-Activation message; NCC therefore associated with network node from which it is received).
Regarding Claims 18, 129:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 29. In addition, Ingale teaches wherein the one or more processors are collectively or individually configured to derive the second integrity protection key and the second encryption key from the second key (paragraph 161, UE 102 derives the KgNB* based on the NCC value provided to the UE by the last serving cell which sent the UE from connected state to inactive state; the UE 102 further derives the new KRRCint and new KRRCenc from the derived KgNB* (i.e. “second key”) to receive the resume message sent on SRB1).
The rationale to combine Huawei and Ingale is the same as provided in claims 1 and 29, due to the overlapping subject matter between claims 1 and 18, 29 and 129.
Regarding Claims 19, 130:
Huawei in view of Ingale teaches the method of claim 18 and the apparatus of claim 129. In addition, Ingale teaches wherein to process the second RRC Release message, the one or more processors are collectively or individually configured to:
decrypt the second RRC Release message using the second encryption key (paragraph 269, upon receiving MSG4 on SRB1 i.e. the release message, the UE 102 decrypts the MSG4 with new key derived from either horizontal key derivation or vertical derivation to obtain the new Resume ID, new RAN paging parameters and new NCC; since MSG4 is integrity protected so the PDCP layer computes the full MAC-I for new Gnb verification; upon integrity check pass, the UE 102 checks the contents of MSG4 which includes the indicator to stay in inactive state and may include new resume ID, RAN paging area code, RAN paging DRX cycle and new NCC); and
verify the second RRC Release message using the second integrity protection key (paragraph 269, upon receiving MSG4 on SRB1 i.e. the release message, the UE 102 decrypts the MSG4 with new key derived from either horizontal key derivation or vertical derivation to obtain the new Resume ID, new RAN paging parameters and new NCC; since MSG4 is integrity protected so the PDCP layer computes the full MAC-I for new Gnb verification; upon integrity check pass, the UE 102 checks the contents of MSG4 which includes the indicator to stay in inactive state and may include new resume ID, RAN paging area code, RAN paging DRX cycle and new NCC).
The rationale to combine Huawei and Ingale is the same as provided in claims 18 and 129, due to the overlapping subject matter between claims 18 and 19, 129 and 130.
Regarding Claims 20, 131:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 129. In addition, Ingale teaches wherein the second RRC Release message further comprises information for deriving a third key (paragraph 171, the RRC release message sent on SRB1 to move UE back to RRC inactive state includes at least a new Resume ID i.e. I-RNTI, new paging parameters and a new NCC).
The rationale to combine Huawei and Ingale is the same as provided in claims 1 and 129, due to the overlapping subject matter between claims 1 and 20, 129 and 131.
Regarding Claims 21, 132:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 29. In addition, Huawei teaches wherein:
the first network node is an anchor base station (page 2 Fig. 1, Last serving gNB); and
the second network node is a serving base station (page 2 Fig. 1, New gNB).
Regarding Claims 23, 134:
Huawei in view of Ingale teaches the method of claim 1 and the apparatus of claim 29. In addition, Huawei teaches wherein the one or more processors are collectively or individually configured to enter, based on an indication in the first RRC Release message, a first state with no dedicated resources allocated to the apparatus, wherein the RRC Resume Request message comprises a request to transition from the first state to a second state with dedicated resources allocated to the apparatus (page 2 paragraph 2, Fig. 1, RRC Connection Release and RRC Re-Activation Request (see also Applicant’s specification paragraphs [0097], [0100], [0116])).
Regarding Claim 25:
Huawei in view of Ingale teaches the method of claim 23. In addition, Huawei teaches wherein the RRC Resume Request message is sent for at least one of a radio access network (RAN) notification area (RNA) update, a location report triggered RAN paging procedure, an uplink data transmission, or a subsequent downlink data transmission (page 2 paragraph 2, Fig. 1, messages 3 and 4 can be seen as uplink/downlink transmissions).
Regarding Claim 26:
Huawei in view of Ingale teaches the method of claim 23. In addition, Huawei teaches the method, further comprising:
exiting the first state after sending the RRC Resume Request message (page 2, Fig. 1, after sending RRC Re-Activation Request, UE eventually enters connection reactivation and sends RRC Re-Activation Complete message); and
Ingale teaches reentering the first state after receiving the second RRC Release message (paragraph 170-171, the method includes receiving a release message (i.e. “second RRC Release message”) on SRB1 from the RAN node 104; the release message received on the SRB1 is to transition the UE 102 to either the idle state or move back the UE to inactive state).
The rationale to combine Huawei and Ingale is the same as provided in claim 23, due to the overlapping subject matter between claims 23 and 26.
Regarding Claim 135:
Huawei in view of Ingale teaches the method of claim 1. In addition, Ingale teaches wherein:
the RRC Resume Request message is transmitted after receiving the first RRC Release message (page 2, Fig. 1, User Equipment (UE) receives RRCConnectionRelease message from Last serving gNB (i.e. “first message”); page 2, paragraph 1, Fig. 1, RRC Re-Activation Request (no encryption, integrity with old key), transmitted following RRCConnectionRelease)); and
Ingale teaches the second RRC Release message is received after transmitting the RRC Resume Request message (paragraph 169, the method includes transmitting a resume request message on SRB0 to the RAN node 104 for performing RAN paging area update; paragraph 172, the RAN node transmits a RRC release message to the UE on SRB1 to move the UE back to idle state in response to the resume request message (i.e. “second RRC Release message”)).
The rationale to combine Huawei and Ingale is the same as provided in claim 1, due to the overlapping subject matter between claims 1 and 135.
Regarding Claim 136:
Huawei in view of Ingale teaches the apparatus of claim 127. In addition, Ingale teaches wherein the one or more parameters comprise at least one of an absolute radio frequency channel number (ARFCN) or a physical cell identifier (PCI) (paragraph 215, the Counter received in connection release message or MSG4, PCI of the camped cell, 5G NR Absolute Radio Frequency Channel Number-Down Link (5G-ARFCN-DL) of the camped cell and other possible inputs are used to derive the new key, when the UE 102 is INACTIVE state).
The rationale to combine Huawei and Ingale is the same as provided in claim 127, due to the overlapping subject matter between claims 127 and 136.
Regarding Claim 137:
Huawei in view of Ingale teaches the apparatus of claim 127. In addition, Huawei teaches wherein:
the one or more indications are provided in a medium access control (MAC) control element (CE) (page 2 paragraph 2, in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header or MAC CE); or
the one or more indications are provided in a packet data convergence protocol (PDCP) control protocol data unit (PDU) (page 2 paragraph 2, in order for such information to not be ciphered, it could be carried by L2, e.g. within PDCP header or MAC CE).
Regarding Claim 138:
Huawei in view of Ingale teaches the apparatus of claim 134. In addition, Huawei teaches wherein the RRC Resume Request message is transmitted for at least one of a radio access network (RAN) notification area (RNA) update, a location report triggered RAN paging procedure, an uplink data transmission, or a subsequent downlink data transmission (page 2 paragraph 2, Fig. 1, messages 3 and 4 can be seen as uplink/downlink transmissions).
Response to Arguments
Applicant's arguments filed 9/29/2025 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 103:
Regarding applicant’s arguments, page 11 paragraph 3-page 12 paragraph 2, the examiner responds: Applicant’s arguments are moot, as Huawei is not cited as teaching these elements specifically.
Regarding applicant’s arguments, page 12 paragraph 5-page 13 paragraph 1, the examiner responds: Examiner disagrees. The limitation “receiving… a second RRC Release message… while a context of the UE is stored at the first network node without transfer to the second network node” can be interpreted in many ways. As there is no temporal limitation, it can be seen as applying to the time at which the second RRC Release message is received; therefore, as the context transfer occurs prior to the ”receiving” step and not during, Ingale can be seen as teaching “receiving… a second RRC Release message… while a context of the UE is stored at the first network node without transfer to the second network node”, as the context is not transferred during the receiving step (e.g. Ingale, paragraph 190-194, Fig. 5a). In addition, as applicant provides no controlling definition of “context of the UE”, the context can be seen as any parameters which apply to the UE state, such as the Resume ID, which is not transferred from the first network node to the second network node, but from the second network node to the first network node (e.g. Ingale, paragraph 7, 12). Finally, Examiner notes that with regard to claim 29 specifically, “without transfer to the second network node” appears to be a recitation of intended use, as the claim is directed to the apparatus for wireless communications, i.e. the UE, and not the system including the first and second network nodes; therefore, any functions performed between the first and second network nodes do not limit the scope of the claim. For the above reasons, Huawei in view of Ingale does teach “receiving, from the second network node, a second RRC Release message different from the first RRC Release message while a context of the UE/apparatus is stored at the first network node without transfer to the second network node”, as in claims 1 and 29 as amended.
Applicant further argues that the dependent claims are allowable due to depending on an allowable independent claim. However, as shown above, the independent claims are not allowable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, Amir Mehrmanesh can be reached at (571) 270-3351. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/AMIR MEHRMANESH/Supervisory Patent Examiner, Art Unit 2491