DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 46 and 56 have been considered but are moot because the new ground of rejection relies on one or more references not previously applied in the prior rejection of record for some teaching or matter specifically challenged in the argument.
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 the 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.
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.
Claims 46-48, 54, and 56 are rejected under 35 U.S.C. § 103 as being unpatentable over US 2019/0320316 (hereinafter, “MILDH”).
Regarding claim 46, MILDH discloses:
A method performed by a user equipment (UE) (Wireless Device 10) for UE context transitions in cell reselection (¶ 0111: [C]ell reselection is performed prior to receiving a message from the network responsive to the RRC Resume Request message), the method comprising:
obtaining plural sets of security parameters; (¶ 0143: UE reverts to its prior security context upon a failed Resume procedure. When the UE generates a new security context including new keys . . . or applies new parameters (including reset counters) such as NCC, COUNT, etc., it will consider the new context and parameters as temporary, meaning it will store old values of the parameters; ¶ 0145: UE restores a prior (stored) security context and parameters)
initiating a first Radio Resource Control (RRC) connection resume procedure using a first set of security context from among the plural sets of security parameters; and (¶ 0111: [A] method of a updating a security context. The method is performed by a wireless device operative in a wireless communication network employing a Radio Resource Control (RRC) protocol. The wireless device in RRC CONNECTED state receives from the network an RRC Suspend message including a security update parameter. In response to the RRC Suspend message, the wireless device enters an RRC INACTIVE state and stores a first security context. Upon attempting to transition to an RRC CONNECTED state, a second security context is generated using the security update parameter received in the RRC Suspend message. An RRC Resume Request message, including a security parameter from the second security context, is sent to the network. Only if any of the following events occur, the second security context is discarded and the first security context is retrieved)
initiating a second RRC connection resume procedure using a second set of security parameters from among the plural sets of security parameters. (¶ 0111: [A] method of a updating a security context. The method is performed by a wireless device operative in a wireless communication network employing a Radio Resource Control (RRC) protocol. The wireless device in RRC CONNECTED state receives from the network an RRC Suspend message including a security update parameter. In response to the RRC Suspend message, the wireless device enters an RRC INACTIVE state and stores a first security context. Upon attempting to transition to an RRC CONNECTED state, a second security context is generated using the security update parameter received in the RRC Suspend message. An RRC Resume Request message, including a security parameter from the second security context, is sent to the network. Only if any of the following events occur, the second security context is discarded and the first security context is retrieved)
While MILDH explicitly discloses “a security parameter from the second security context,” which maps to a second set of security parameters from among the plural sets of security parameters, MILDH does not explicitly disclose a first set of security parameters from among the plural sets of security parameters. As set forth above, MILDH does explicitly disclose, however, “the wireless device enters an RRC INACTIVE state and stores a first security context.” Taking into account the inferences and creative and/or routine steps that one of ordinary skill in the art would have employed, the Examiner finds a sufficient motivation to combine the related teachings of MILDH, in that MILDH’s first “security context” at least implicitly teaches or suggests a first set of “security parameters.” For example, MILDH identifies “keys” as an example of “security context,” see ¶ 0155 and ¶ 0159, which maps to “security parameters.”
Regarding claim 47, MILDH, as applied above, renders obvious the method of claim 46. MILDH further discloses:
wherein the UE obtains the plural sets of security parameters in a RRC release message. (¶ 0156: When the UE receives an . . . RRC Release message . . . , the UE considers the new security context valid)
Regarding claim 48, MILDH, as applied above, renders obvious the method of claim 47. MILDH does not explicitly disclose:
wherein each of the plural sets of security parameters comprises a Next Hop Chaining Count and a Next Hop parameter.
In the same field of endeavor, however, MILDH further discloses:
wherein each of the plural sets of security parameters comprises a Next Hop Chaining Count and a Next Hop parameter. (¶ 0040: [T]he network fetches the UE context and sends to the UE an integrity-protected RRC Connection Resume Request which contains a next Hop Chaining Count (NCC) parameter)
Regarding claim 54, MILDH, as applied above, renders obvious the method of claim 46. MILDH further discloses:
wherein the first set of security parameters are used to encrypt data in the first RRC connection resume procedure, and (¶ 0041: [T]he network can fetch the context and send a RRC Resume message that is not only integrity protected, but also encrypted, due to the fact that the UE has already refreshed the keys and initiated security)
the second set of security parameters are used to encrypt data in the second RRC connection resume procedure. (¶ 0159: The new security context (e.g., keys) is used to verify the security token included in the RRCResumeRequest message. It may also be used to encrypt and/or integrity protect the RRCResume message)
Regarding claim 56, MILDH discloses:
A user equipment (UE) (Wireless Device 10) for UE context transitions in cell reselection (¶ 0111: [C]ell reselection is performed prior to receiving a message from the network responsive to the RRC Resume Request message), comprising:
processing circuitry (processing circuitry 12) configured to cause the UE to perform the steps of:
obtaining plural sets of security parameters; (¶ 0143: UE reverts to its prior security context upon a failed Resume procedure. When the UE generates a new security context including new keys . . . or applies new parameters (including reset counters) such as NCC, COUNT, etc., it will consider the new context and parameters as temporary, meaning it will store old values of the parameters; ¶ 0145: UE restores a prior (stored) security context and parameters)
initiating a first Radio Resource Control (RRC) connection resume procedure using a first set of security context from among the plural sets of security parameters; and (¶ 0111: [A] method of a updating a security context. The method is performed by a wireless device operative in a wireless communication network employing a Radio Resource Control (RRC) protocol. The wireless device in RRC CONNECTED state receives from the network an RRC Suspend message including a security update parameter. In response to the RRC Suspend message, the wireless device enters an RRC INACTIVE state and stores a first security context. Upon attempting to transition to an RRC CONNECTED state, a second security context is generated using the security update parameter received in the RRC Suspend message. An RRC Resume Request message, including a security parameter from the second security context, is sent to the network. Only if any of the following events occur, the second security context is discarded and the first security context is retrieved)
initiating a second RRC connection resume procedure using a second set of security parameters from among the plural sets of security parameters; and (¶ 0111: [A] method of a updating a security context. The method is performed by a wireless device operative in a wireless communication network employing a Radio Resource Control (RRC) protocol. The wireless device in RRC CONNECTED state receives from the network an RRC Suspend message including a security update parameter. In response to the RRC Suspend message, the wireless device enters an RRC INACTIVE state and stores a first security context. Upon attempting to transition to an RRC CONNECTED state, a second security context is generated using the security update parameter received in the RRC Suspend message. An RRC Resume Request message, including a security parameter from the second security context, is sent to the network. Only if any of the following events occur, the second security context is discarded and the first security context is retrieved)
power supply circuitry configured to supply power to the processing circuitry. (¶ 0334: [P]ower supply circuitry configured to supply power to the wireless device)
While MILDH explicitly discloses “a security parameter from the second security context,” which maps to a second set of security parameters from among the plural sets of security parameters, MILDH does not explicitly disclose a first set of security parameters from among the plural sets of security parameters. As set forth above, MILDH does explicitly disclose, however, “the wireless device enters an RRC INACTIVE state and stores a first security context.” Taking into account the inferences and creative and/or routine steps that one of ordinary skill in the art would have employed, the Examiner finds a sufficient motivation to combine the related teachings of MILDH, in that MILDH’s first “security context” at least implicitly teaches or suggests a first set of “security parameters.” For example, MILDH identifies “keys” as an example of “security context,” see ¶ 0155 and ¶ 0159, which maps to “security parameters.”
Claims 49-53 rejected under 35 U.S.C. § 103 as being unpatentable over MILDH in view of US 2022/0304093 (hereinafter, “KIM”).
Regarding claim 49, MILDH, as applied above, renders obvious the method of claim 46. MILDH does not explicitly disclose:
wherein each of the sets of security parameters comprises a Small Data Transmission New Radio base station key (SDT_KgNB).
In the same field of endeavor, however, KIM teaches:
wherein each of the sets of security parameters comprises a Small Data Transmission New Radio base station key (SDT_KgNB). (¶ 0153: Whenever an initial AS security context needs to be established between UE and gNB/ng-eNB, AMF and the UE shall derive a KgNB and a Next Hop parameter (NH). The KgNB and the NH are derived from the KAMF. A NH Chaining Counter (NCC) is associated with each KgNB and NH parameter. Every KgNB is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the KgNB is derived directly from KAMF, and is then considered to be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is associated with the NCC value one)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify MILDH’s radio resource control (RRC) connection resume procedure to derive a KgNB parameter as taught by KIM such that every KgNB is associated with the NCC corresponding to the NH value from which it was derived, so as to establish an initial security context between UE and gNB/ng-eNB. See KIM, at ¶ 0153.
Regarding claim 50, the combination of MILDH and KIM, as applied above, renders obvious the method of claim 49. KIM further discloses:
wherein the UE obtains the SDT_KgNBs by calculating the SDT_KgNBs. (¶ 0153: Whenever an initial AS security context needs to be established between UE and gNB/ng-eNB, AMF and the UE shall derive a KgNB and a Next Hop parameter (NH))
Regarding claim 51, the combination of MILDH and KIM, as applied above, renders obvious the method of claim 50. KIM further discloses:
wherein the UE calculates the SDTKgNBs based on at least one of:
a currently active access stratum (AS) security context; (¶ 0153: Whenever an initial AS security context needs to be established between UE and gNB/ng-eNB, AMF and the UE shall derive a KgNB and a Next Hop parameter (NH))
a property of a source Next Generation Radio Access Network (NG-RAN) node;
a property of a target NG-RAN node; and
an ongoing SDT communication.
Regarding claim 52, MILDH, as applied above, renders obvious the method of claim 46. MILDH does not explicitly disclose:
wherein the security parameters comprise an authentication code.
In the same field of endeavor, however, KIM teaches:
wherein the security parameters comprise an authentication code. (¶ 0179: The authentication token (e.g., Short MAC-I) is used to allow the NG-RAN to verify the UE identity)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify MILDH’s radio resource control (RRC) connection resume procedure to provide an authentication token as taught by KIM to allow the NG-RAN to verify the UE identity, such that if the check of the authentication token is successful, then the NG-RAN decides whether to keep the UE context and resume the RRC connection instead of the setup of a new RRC connection. See KIM, at ¶ 0326.
Regarding claim 53, the combination of MILDH and KIM, as applied above, renders obvious the method of claim 52. MILDH further discloses:
wherein the authentication code is a shortResume Message Authentication Code - Integrity, MAC-I. (¶ 0041: [T]he token—equivalent to the short MAC-I in LTE—is computed based on the newly refreshed keys)
Claim 55 is rejected under 35 U.S.C. § 103 as being unpatentable over MILDH in view of US 2021/0051734 (hereinafter, “CHANG”).
Regarding claim 55, MILDH, as applied above, renders obvious the method of claim 46. MILDH does not explicitly disclose:
wherein the second RRC connection resume procedure is initiated without receiving a RRC release message in relation to the first RRC connection resume procedure.
In the same field of endeavor, however, CHANG teaches:
wherein the second RRC connection resume procedure is initiated without receiving a RRC release message in relation to the first RRC connection resume procedure. (¶ 0009: [I]n the case where the first security processing fails, if the RRC response message is the RRC connection release message, then the RRC layer initiates an RRC connection reestablishment procedure, and if the RRC response message is the RRC connection resume message, then the RRC layer performs actions upon leaving the RRC connected state; ¶ 0033: Because the UE context is stored in the UE and the eNB, this procedure can resume the RRC connection, the DRB(s), and the security of the UE and the eNB without re-setting up an RRC connection, DRB(s), and security)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify MILDH’s radio resource control (RRC) connection resume procedure to provide initiation of a subsequent RRC connection resume procedure as taught by CHANG in response to a first security processing failure, so as to solve the problem of security processing of UE switching from an RRC idle state to an RRC connected state. See CHANG, at ¶ 0003.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Garth D Richmond whose telephone number is (703)756-4559. The Examiner can normally be reached M-F 8 a.m. - 5 p.m. ET.
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, Kathy Wang-Hurst can be reached at (571)270-5371. 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.
/GARTH D RICHMOND/ Examiner, Art Unit 2644
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644