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 6/8/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.
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 and an auxiliary parameter…” (e.g. claim 1, and similarly recited within 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 based upon a root key and “auxiliary parameter”. 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 “first 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).
Specifically, regarding claims 1 and 14, the applicant’s original disclosure fails to adequately disclose the recitations “…wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network.…” (e.g. claim 1, and similarly recited in 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) each of an “air interface user plane key” and an “air interface control plane key” are generated based upon a “first security parameter” and “second security parameter” respectively. 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 “second 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 and an auxiliary parameter…” (e.g. claim 1, and similarly claim 14) render the scope of the claims indefinite.
Furthermore, the recitations “…wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network.…” (e.g. claim 1, and similarly recited in claim 14) render the scope of the claims indefinite.
Specifically, the examiner notes that the terms “first security parameter” and “second security parameter” fail to comprise any standardized meanings within the art. Furthermore, the applicant’s disclosure fails to clearly define the meanings of these terms. 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.
Regarding claim 1, the recitation “…wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network…” renders the scope of the claims indefinite. Specifically, these recitations are not recited in the form of method steps. Thus, it is unclear as to how these recitation further define the claimed method comprising the steps of “obtaining…”, “generating…”, and/or “sending…”.
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, as best determined in view of the above noted deficiencies of clarity, Wu discloses, :
A security parameter obtaining method (e.g. Wu, abstract), comprising:
obtaining, by a session management network element …(e.g. Wu, fig. 21:730,710,720; par. 25, 31, 32 – a generation module for producing session keys for communication sessions – i.e. “session management network element”; Note – the claimed “session management network element” is not limited to the prior art SMF, see Applicant’s specification par. [121]), 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 session management network element of the private network, a first security parameter of the terminal device based on the root key of the private network and an auxiliary parameter (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 session management network element of the private network, the first security parameter to an access network device of the terminal device (e.g. Wu, fig. 5),
wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network. Note, these are not recited as method steps within the claimed method, and therefore fail to further define the claimed method over the prior art (However, for the applicant’s benefit, the examiner notes that Wu discloses that the network access device generates user plane and control plane keys based upon security parameters (i.e. “first”, “second” security parameters), e.g. Wu, par. 115 – 116).
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).
Furthermore, regarding the recitation “…wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network…”, the examiner notes that this fails to further limit the claimed “communication apparatus”. Specifically, this recitation is directed to a characterization of an “access network device” which is not part of the claimed apparatus and, thus, does not limit the claimed apparatus.
Response to Arguments
Applicant's arguments filed 6/8/26 have been fully considered but they are not persuasive.
Applicant argues or alleges essentially that:
…
… Claims 1 and 14 as amended now recite that the first security parameter is generated "based on the root key of the private network and an auxiliary parameter." This provides the concrete generation process requested by the Office. The as-filed application at paragraph [00169] states that "[t]he derivation network element of the private network may generate the first security parameter based on the root key of the private network and an auxiliary parameter." …
(Remarks, pg. 9)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, the applicant fails to provide any evidence of a specific algorithm for generating a “first security parameter” based on a “root key” and “auxiliary parameter”. At best, the applicant points only to a restatement of the claimed functionality and a black box (i.e. a “derivation network element”) supposedly for implementing said functionality.
Applicant argues or alleges essentially that:
…
… Paragraph [00173] identifies the auxiliary parameter as including "one or more of S-NSSAI, a DNN, or a downlink NAS message count (downlink NAS count, DL NAS Count)." As-Filed Application, paragraphs [00169], [00173].
Claims 1 and 14 further recite that "the first security parameter includes an intermediate key, the intermediate key is keNodeB." The term keNodeB is a well-known standardized key in 3GPP LTE security architecture. One of ordinary skill in the art would understand keNodeB and how the parameter is derived.
…
(Remarks, pg. 9)
Examiner respectfully responds:
The examiner notes that the applicant’s remarks are unpersuasive, at least, for the any one of the reasons below:
First, the examiner respectfully maintains that the applicant mischaracterizes the claim language by alleging that the claims recite the “security parameter” as being equivalent to the prior art KeNodeB . However, as was previously noted on record, 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 the applicant’s argument of record that the claimed “security parameter” is generated based upon a “auxiliary parameter” which includes "one or more of S-NSSAI, a DNN, or a downlink NAS message count (downlink NAS count, DL NAS Count)”. However, the examiner points out that none of a S-NSSAI, a DNN, or a downlink NAS message count (downlink NAS count, DL NAS Count), collectively or individually, is used by those having ordinary skill in the art to generate the standard KeNodeB. Thus, the examiner respectfully notes that applicant’s statements of record is evidence that the claimed “security parameter” is not clearly understood by one or ordinary skill in the art to the be the standard KeNodeB.
Applicant argues or alleges essentially that:
…
The Office used an analogy of a "widget" including a "wheel" to argue that stating what something "includes" does not define the scope of the term. However, unlike a generic "widget," claims 1 and 14 provide concrete structural identification (keNodeB), a concrete generation process (root key and auxiliary parameter), and concrete functional boundaries (user plane key derivation, distinct from control plane key derivation from a different source). The use of "includes" is standard claim drafting practice and does not render a claim indefinite.
… …
(Remarks, pg. 10)
Examiner respectfully responds:
The examiner respectfully maintains that applicant’s argument is unpersuasive, at least, for the reason that the applicant continues to mischaracterize the claimed “security parameter” as being equivalent to the prior art KeNodeB.
However, the applicant’s claims clearly do not state that the “security parameter” is the KeNodeB. Rather, the applicant clearly uses open ended language (i.e. “includes”) to ambiguously describe the scope of the “security parameter”. Furthermore, as shown above, those of ordinary skill in the art do not recognize the KeNodeB to be generated from a collection of values (i.e. “auxiliary parameter”) including a S-NSSAI, a DNN, and a downlink NAS message count (downlink NAS count, DL NAS Count).
Thus, the applicant fails to provide any clear and concrete definition to the claimed terminology.
Applicant argues or alleges essentially that:
…
The Office previously asserted that the UE (a personal device) of Wu constitutes a "network element not shared with the public network." See Office Action, page 8. This conflates the terminal device with the network element. …
… …
(Remarks, pg. 11)
Examiner respectfully responds:
The examiner respectfully disagrees. The office action illustrates that the “network element” (i.e. functional element[s] for generating session keys) is within the “terminal device”. The office action does not conflate the terms “network element” and “terminal device”.
Applicant argues or alleges essentially that:
…
… Claim 1 separately recites "a terminal device" and "a session management network element of a private network" as distinct entities. The session management network element performs the obtaining, generating, and sending steps. These are functions performed by network infrastructure, not by a UE or terminal device.
…
(Remarks, pg. 11)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, because the claimed scope does not preclude the network element from residing within the terminal device.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “ the obtaining, generating, and sending steps … performed by network infrastructure, not by a UE or terminal device”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues or alleges essentially that:
…
Claim 1 as amended further recites "wherein the access network device derives the air interface user plane key based on the first security parameter, and derives an air interface control plane key based on a second security parameter obtained from the network element of the public network." This recites that the user plane key and control plane key are derived from different security parameters obtained from different network elements (private versus public). Wu does not teach or suggest this separation. In Wu, the AMF/SEAF sends a single base station key (KgNB/KeNB) to the access node, and the access node derives both user plane keys and control plane keys from that single key. See Wu, paragraphs [0114]-[0117]. There is no separation of security parameters from different network elements for user plane versus control plane key derivation. …
…
(Remarks, pg. 11, 12)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, because the argued features are not recited within the claim as method steps. Thus, these features fail to define over the prior art method of Wu.
Furthermore, assuming arguendo, that the claimed features were interpreted as explicit method steps, the examiner points out that the combination of Wu and ETSI does indeed teach the separate generation of user/control plane keys - based upon their own copies of parameters (i.e. “first”, “second” security parameters) - by each of the network element within the user terminal (i.e. private side) (e.g. Wu, par. 117) and the access node (public side) (e.g. Wu, par. 115 – 116).
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights