Prosecution Insights
Last updated: April 19, 2026
Application No. 18/362,155

SECURITY PARAMETER OBTAINING METHOD, APPARATUS, AND SYSTEM

Non-Final OA §103§112
Filed
Jul 31, 2023
Examiner
WILLIAMS, JEFFERY L
Art Unit
2495
Tech Center
2400 — Computer Networks
Assignee
Huawei Technologies Co., Ltd.
OA Round
3 (Non-Final)
68%
Grant Probability
Favorable
3-4
OA Rounds
3y 7m
To Grant
88%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allow Rate
341 granted / 498 resolved
+10.5% vs TC avg
Strong +19% interview lift
Without
With
+19.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
27 currently pending
Career history
525
Total Applications
across all art units

Statute-Specific Performance

§101
8.6%
-31.4% vs TC avg
§103
34.6%
-5.4% vs TC avg
§102
23.6%
-16.4% vs TC avg
§112
30.1%
-9.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 498 resolved cases

Office Action

§103 §112
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 . DETAILED ACTION This action is in response to the communication filed on 2/18/26. Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication. All objections and rejections not set forth below have been withdrawn. Claims 1 – 20 are pending. Claims 1 – 8 and 14 – 20 are rejected. Claims 9 – 13 are withdrawn. 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 2/18/26 has been entered. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1 – 8 and 14 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Specifically, regarding claims 1 and 14, the applicant’s original disclosure fails to adequately disclose the recitations “…generating, by the network element of the private network, a first security parameter of the terminal device based on the root key of the private network…” (e.g. claim 1), and “… generate a first security parameter of the terminal device based on the root key of the private network …” (e.g. claim 14. The examiner notes that the applicant’s originally filed specification fails to disclose specifically how (i.e. by algorithm, formula, or sequence of steps) that a “security parameter” is to be generated. Simply restating the function recited in the claim is not sufficient (e.g. see MPEP 2161.01). Furthermore, the applicant’s disclosure also fails to clearly disclose the specific nature of the term “security parameter”. As this term fails to comprise any standardized meaning within the art, it is incumbent upon the applicant to clearly disclose what subject matter is meant to fall within the scope of the claim term. However, the applicant fails to define the term by any specific structure (e.g. is it a numerical value?, logical value?, a composition of values?, a message?, data structure?, etc). Depending claims are rejected by virtue of dependency. The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 1 – 8 and 14 – 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding claims 1 and 14, the recitations “…generating, by the network element of the private network, a first security parameter of the terminal device based on the root key of the private network…” (e.g. claim 1), and “… generate a first security parameter of the terminal device based on the root key of the private network …” (e.g. claim 14) render the scope of the claims indefinite. Specifically, the examiner notes that the term “security parameter” fails to comprise any standardized meaning within the art. Furthermore, the applicant’s disclosure fails to clearly define the meaning of this term. Thus the structure or nature of the term “security parameter” is indefinite in scope. For example, one of ordinary skill in the art is unclear as to whether or not the term “security parameter” is intended to represent a numerical value, or a logical value, or a composition of values, or a composition derived from one or more values, or a message, or a data structure, or something else entirely. Additionally, while the applicant does appear to disclose and claim that the term “security parameter” “includes” an intermediate key, “…… the intermediate key is keNodeB…” (e.g. see Specification, par. 176, 177, 305, 437; see claim 1 and 14), such claim and disclosure is indefinite because it appears to merely to be a vague and open-ended example. For example, a “widget” could be described as including a “wheel”, however such disclosure alone does not clearly define the ‘widget’ to be a “wheel”, nor does the disclosure clearly specify the scope of the term “widget” (i.e. is the widget an automobile?, an airplane?, a shopping cart?, a mechanical pulley?, an amusement park ride?, etc…). Likewise, the examiner notes that the applicant merely describes information that may be “included” or considered to be a portion of or within “a security parameter”, however, the applicant fails to clearly define the scope or boundaries of the term “security parameter”. Additionally, the applicant’s disclosure fails to disclose specifically “how” to generate a security parameter or provide any form of algorithm for generating the “security parameter”. Thus, again, one of ordinary skill in the art is left without clear understanding as to the exact nature of the claimed term. Thus, the scope of the claims are indefinite. Depending claims are rejected by virtue of dependency. 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 – 8 and 14 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wu et al. (Wu), US 2019/0297494 A1 in view of ETSI, “ETSI TS 133 501, V16.3.0”. Regarding claim 1, Wu discloses: A security parameter obtaining method (e.g. Wu, abstract), comprising: obtaining, by a network element …(e.g. Wu, fig. 21:730,710,720; par. 25), a root key … of a terminal device (e.g. Wu, par. 9, 68, 81; fig. 1:step 6, “K asme“ and/or fig. 7: UE generates anchor key – e.g. “emsk”) for setting up a control plane connection to a network element of a public network (e.g. Wu, par. 8, 81). Wu does not appear to explicitly disclose that the network element and root key are “of a private network”. However, ETSI teaches that the public networks should be integrated with private networks, and that the known authentication teachings applicable to public networks should also apply to the network elements within private networks (e.g. ETSI, pg. 224, “Annex I”; pg. 226, “I.6”). It would have been obvious to one of ordinary skill in the art to recognize the teachings that the network element and root key of the network element may be from “a private network” as taught by ETSI because one of ordinary skill in the art would have been motivated by the teachings that the authentication procedures of network elements should occur within integrated public and private (i.e. non-public) networks (e.g. ETSI, pg. 226, “I.6”). Furthermore, does not appear to explicitly teach “…wherein the network element is not shared with the public network…”. However, the examiner notes that Wu teaches that the UE (comprising the network element) may be a device of the user, such as wristwatch, smartphone, or tablet (e.g. Wu, par. 68). Thus, it would have been obvious to one of ordinary skill in the art to recognize the UE (comprising the network element) to be a private device (i.e. a device not shared with the public or a public network) because one of ordinary skill in the art generally regards personal devices such as wristwatches, smartphones, and/or tablets to be private and exclusive to the individual owning the personal device. Thus, the combination enables: generating, by the network element of the private network, a first security parameter of the terminal device based on the root key of the private network (e.g. Wu, fig. 1:step 6; par. 9, “IK” and/or “CK” and/or “intermediate key” and/or “user plane cipher key”, and/or “control plane cipher key”, and/or “control plane integrity key” and/or “KeNB“), wherein the first security parameter includes an intermediate key, the intermediate is keNodeB (e.g. Wu, par. 9, fig. 1:step 6 – “security parameter” includes a “KeNB“, also known as a keNodeB ; or see also Wu, par. 7, par. 7 - “KeNB“ ), and the first security parameter is usable to derive an air interface user plane key of the private network of the terminal device (e.g. Wu, par. 9, 107, 117, 118); and sending, by the network element of the private network, the first security parameter to an access network device of the terminal device (e.g. Wu, fig. 5). Regarding claim 2, Wu discloses: wherein the obtaining the root key of the private network of a terminal device comprises: obtaining the root key of the private network based on an identifier of the terminal device (e.g. Wu, par. 79-83); or obtaining the root key of the private network based on a service identifier of the terminal device (e.g. Wu, par. 79-83). Regarding claim 3, Wu discloses: wherein the method further comprises: receiving first parameter information (e.g. Wu, par. 82), wherein the first parameter information indicates to generate the first security parameter by using the root key of the private network (e.g. Wu, 82, 83, 86); and the obtaining a root key of the private network of a terminal device comprises: obtaining the root key of the private network based on the first parameter information (e.g. Wu, par. 94-97). Regarding claim 4, Wu discloses: wherein the method further comprises: receiving second parameter information indicating that the air interface control plane key and the air interface user plane key of the terminal device are separated from each other (e.g. Wu, par. 115, 116); and the obtaining the root key of the private network of a terminal device comprises: obtaining the root key of the private network based on the second parameter information (e.g. Wu, 84- 89, 96, 97, 105). Regarding claim 5, Wu discloses: wherein the method further comprises: obtaining a security parameter key (e.g. Wu, par. 9, “IK” and/or “CK” and/or “intermediate key” and/or “user plane cipher key”, and/or “control plane cipher key”, and/or “control plane integrity key”; see also par. 107); and the sending the first security parameter to the access network device of the terminal device comprises: encrypting the first security parameter using the security parameter key (e.g. Wu, par. 96, 97), and sending the encrypted first security parameter to the access network device (e.g. Wu, fig. 5, 6a, 6b). Regarding claim 6, Wu does not, but ETSI does disclose setting up a security tunnel (e.g. ETSI, pg. 18, IPsec tunnel). It would have been obvious to one of ordinary skill in the art to employ the IPsec teachings of ETSI within the system of Wu, because one of ordinary skill in the art would have been motivated by the teachings that IPSec tunnels flexibly allow non-3GPP access to the core 5G network (e.g. ETSI, pg. 110, sect. 7.1). Thus, the combination enables: wherein the obtaining the security parameter key comprises: setting up a security tunnel to the access network device (e.g. Wu, par. 107; ETSI, pg. 110), wherein the security parameter key is a key of the security tunnel (e.g. Wu, par. 107; pg. 74, sect. 6.8.1.2.3; pg. 53, sect. 6.2.3.1); and sending the encrypted first security parameter to the access network device through the security tunnel (e.g. Wu, fig. 5, 6a, 6b; ETSI, pg. 110). Regarding claim 7, Wu discloses: wherein the setting up the security tunnel to the access network device comprises: sending a request message to the control plane network element of the public network, wherein the request message is usable to request to set up the security tunnel to the access network device (e.g. e.g. ETSI, fig. 7.2.1-1 – IKE and EAP request); and receiving a response message from the control plane network element of the public network, wherein the response message is usable to respond to completion of setup of the security tunnel (e.g. Wu, abstract; e.g. ETSI, fig. 7.2.1-1 – IKE and EAP response); and the sending the encrypted first security parameter to the access network device through the security tunnel comprises: sending the encrypted first security parameter to the control plane network element of the public network (e.g. ETSI, fig. 7.2.1-1). Regarding claim 8, Wu discloses: wherein the setting up the security tunnel to the access network device comprises: sending address information of the network element of the private network to the access network device, wherein the address information of the network element of the private network enables the access network device to request to set up the security tunnel (e.g. ETSI, fig. 7.2.1-1 – IP address). Regarding claims 14 – 20, they are apparatus claims, essentially corresponding to the claims above, and they are rejected, at least, for the same reasons. And furthermore because: Regarding claim 14, Wu discloses: A communication apparatus of a private network, comprising: at least one processor; and at least one memory configured to store instructions, wherein the at least one processor is configured to execute the instructions to … (e.g. Wu, claim 1, claim 26). Response to Arguments Applicant's arguments filed 2/18/26 have been fully considered but they are not persuasive. Applicant argues or alleges essentially that: … … This is improper burden shifting to the Applicant because according to MPEP 804, the showing of a serious burden is a requirement on the Office for making a proper Restriction Requirement, not for Applicant to avoid a Restriction Requirement. … (Remarks, pg. 8) Examiner respectfully responds: This argument is essentially similar to applicant’s prior argument, and the examiner respectfully disagrees, at least for the reasons already noted of record Applicant argues or alleges essentially that: … … This claim language provides concrete structural definition, i.e., the first security parameter includes keNodeB, which one of ordinary skill in the art would recognize as a well-known intermediate key in LTE/4G security architecture. To the extent that the Office disagrees, Applicant respectfully requests that the Office clarify why one of ordinary skill in the art would not understand the meaning of keNodeB. The claim language does not leave the structure of the security parameter undefined; rather, the claim language explicitly ident includes keNodeB and recites the specific functional purpose. … These disclosures, as understood by one of ordinary skill in the art, establish that the first security parameter is not an undefined abstraction, but rather a concrete cryptographic element, i.e., an intermediate key (keNodeB or Knpn) that is used to derive air interface user plane keys. … (Remarks, pg. 9) Examiner respectfully responds: The examiner notes that the applicant’s remarks are unpersuasive, at least, for the reason that they represent mischaracterizations of both the claim language and the office action. First, the examiner notes that the applicant mischaracterizes the claim language by alleging that the claims recite the “security parameter” as being the KeNodeB “(i.e. “the first security parameter is not an undefined abstraction, but rather a concrete cryptographic element, i.e., an intermediate key (keNodeB or Knpn)”). This assertion is unpersuasive because the claims do not equate the “security parameter” to the KeNodeB (e.g. “security parameter is… a KeNodeB“) but instead broadly recites that the “security parameter includes…” a KeNodeB . Second, the examiner notes that the applicant mischaracterized the position taken by the office action by alleging that the Office raises issue as to the meaning of the term “KeNodeB “. However, the examiner respectfully points out that the applicant is mistaken because the office action had clearly called into question the adequacy of disclosure and the meaning of the claimed term “security parameter”. The examiner again notes that the claimed “security parameter” is neither disclosed nor claimed by the applicant to be equivalent in scope to that of a KeNodeB. Applicant argues or alleges essentially that: … Regarding the generation process … … The position that the specification must disclose a specific algorithm or formula is overly stringent. The claims recite that the intermediate key is keNodeB, which is a standardized key defined in 3GPP specifications for LTE systems. … (Remarks, pg. 9, 10) Examiner respectfully responds: The examiner respectfully disagrees, at least, for the reason that the claims do not recite that the “security parameter” is the keNodeB. Thus, the examiner respectfully notes that the Applicant’s arguments directed towards the meaning of the keNodeB or as to how one of ordinary skill in the art would understand it to be generated, fails to address the issues noted by the office action. Applicant argues or alleges essentially that: … The Office asserted that the term "security parameter" renders the claims indefinite because the term allegedly lacks a standardized meaning within the art and the specification fails to clearly define the meaning of the term. … … These describes, read in conjunction with the claim language, allow one of ordinary skill in the art to reasonably understand that the first security parameter relates to cryptographic key material, e.g., an intermediate key (keNodeB orKnpn),used in a key derivation hierarchy to generate air interface user plane keys. One of ordinary skill in the art of telecommunications security would understand the scope of the term "first security parameter" as recited in the claims. … The Office expressed concern that the use of "includes" renders the scope of "security parameter" indefinite because the term "includes" is open-ended. However, the use of "includes" or "comprising" language is standard claim drafting practice and does not render a claim indefinite. Open-ended claim language is permissible and widely used in patent claims. The relevant inquiry is whether one of ordinary skill in the art can ascertain the boundaries of the claim with reasonable certainty. (Remarks, pg. 10 - 12) Examiner respectfully responds: The examiner respectfully finds these arguments to be unpersuasive for reasons already noted of record. The examiner maintains that the applicant is asserting a false equivalency between the claimed “security parameter” and a KeNodeB. The applicant appears to incorrectly argue that the term “includes” should be interpreted as synonymous with the term “is” or “to be”. This is mistaken. Just as an “airplane” including a “wheel” does not define an airplane to be a wheel, neither does applicant’s claimed “security parameter” as including an intermediate key define the “security parameter” to be the KeNodeB. Applicant argues or alleges essentially that: … Even if Wu's authentication procedures were applied to a private network context as suggested by ETSI, the combination would not result in a network element that is "not shared with the public network." Applying Wu's procedures to a private network context would still involve shared network elements performing the authentication and key generation functions. … (Remarks, pg. 10 - 12) Examiner respectfully responds: The examiner respectfully disagrees, at least, for the reason that the “network element” of the terminal device, i.e. the UE of Wu, is a personal device and is not shared with the public network. The balance of applicant’s arguments are essentially based upon the above and are found to be unpersuasive for the reasons already noted of record. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached 7:30 am - 4:00 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 571-272-3739. 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. /JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Read full office action

Prosecution Timeline

Jul 31, 2023
Application Filed
Aug 15, 2023
Response after Non-Final Action
Jul 24, 2025
Non-Final Rejection — §103, §112
Oct 24, 2025
Response Filed
Nov 14, 2025
Final Rejection — §103, §112
Jan 12, 2026
Response after Non-Final Action
Feb 18, 2026
Request for Continued Examination
Mar 01, 2026
Response after Non-Final Action
Mar 06, 2026
Non-Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12592824
SECURE APPARATUS TO SHARE AND DEPLOY MACHINE BUILD PROGRAMS UTILIZING UNIQUE HASH TOKENS
2y 5m to grant Granted Mar 31, 2026
Patent 12591689
ANALYZING RISK FOR DEVICES WITHIN A MANAGED ENVIRONMENT
2y 5m to grant Granted Mar 31, 2026
Patent 12580774
DIGITAL SIGNATURES OF MESSAGES USING SIGNATURE SHARES
2y 5m to grant Granted Mar 17, 2026
Patent 12572630
USER-TRUSTED EXECUTABLE EXECUTION ENVIRONMENT
2y 5m to grant Granted Mar 10, 2026
Patent 12574258
PUBLICLY VERIFIABLE ENCRYPTION
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
68%
Grant Probability
88%
With Interview (+19.0%)
3y 7m
Median Time to Grant
High
PTA Risk
Based on 498 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month