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
Election/Restrictions
Applicant’s election without traverse of group 1 (claims 1-15) and species 1 (security context stored at a Network Data Analytics Function (NWDAF) containing a Model Training Logical Function (MTLF), claims 3-5 and 14-15 drawn to species 1) and in the reply filed on 5/19/2026 is acknowledged. As a result of the election, claims 6-11 and 16-20, drawn to the non-elected group and species, are withdrawn from consideration. Claims 1-5 and 12-15 are examined in this office action.
Claim Objections
Claim 1 is objected to because of the following informalities:
The phrase "an identifier for at least one Analytic, and, ML model file specific information" should be "an identifier for at least one Analytic and ML model file specific information." Appropriate correction is required.
Claims 13-15 are objected to because of the following informalities:
The phrase "The Network Data Analytics Function containing a Model Training logical function" should be "The Network Data Analytics Function containing the Model Training logical function." Appropriate correction is required.
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 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.
Claims 1-5 and 12-15 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1 and 12 recite “the ML model provision response message comprising: … at least one protected trained ML model file.” However, the specification only describes the response message by a Network Data Analytics Function (NWDAF) containing a Model Training logical function (MTLF) comprising one protected trained ML model file address, rather than comprising the actual ML model file (see ¶ [0061]: At step 475, the NWDAF containing MTLF 430 sends Nnwdaf_MLModelInfo_Response with the following parameters Analytics ID(s), Protected Trained ML model file address”). In fact, the specification describes that the ML model file needs to be retrieved later from a different device, ADRF, (see ¶ [0078] for step 677a of Fig.6, where ADRF620 sends a retrieval response comprising a trained ML model file). Therefore, “the ML model provision response message comprising: … at least one protected trained ML model file” is not supported by the specification. Applicant is recommended to amend the limitations to be “the ML model provision response message comprising: … at least one protected trained ML model file address”
Dependent claims have the deficiencies and thus are rejected for the same reason.
Claims 4 and 15 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 pre-AIA the applicant regards as the invention.
Independent claims 1 and 12 recite “a Network Data Analytics Function containing a Model Training logical function.” Dependent claims 4 and 15 further recite “a Network Data Analytics Function containing an Analytics logical function.” It is unclear whether they are the same or different Network Data Analytics Functions. Based on dependent claim 5 and the specification describing the former being a sender and the latter being a recipient, for examining purposes, they are interpreted to be different. Applicant is recommended to amend the limitations to be “a first Network Data Analytics Function containing a Model Training logical function” and “a second Network Data Analytics Function containing an Analytics logical function.” Claim 5 should be canceled based on this interpretation/recommendation.
Claims 14 and 15 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 pre-AIA the applicant regards as the invention.
Independent claim 12 recites “generate a protected trained ML model using a stored security context … location information of the stored security context.” Dependent claim 14 further recites “generate a security context … wherein the location information of the stored security context.” It is unclear whether “a security context” underlined is the same or different from the stored security context. In light of claim 3, for examining purposes, they are interpreted to be the same. Applicant is recommended to amend the limitations to be “generate the security context … wherein the location information of the stored security context.” Dependent claim 15 has the deficiency and thus is rejected for the same reason.
Further, dependent claim 15 further recites “select the corresponding previously generated security context … the key provision response message comprising the selected security context.” It is unclear whether “the corresponding previously generated security context” underlined is the same or different from the stored security context. In light of claim 4, for examining purposes, they are interpreted to be different. Applicant is recommended to amend the limitations to be “select a corresponding previously generated security context … the key provision response message comprising the selected security context.”
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 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-5 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TR 23.700-81 V0.3.0 (2022-05) (see IDS on 12/13/2024, hereinafter 3GPP), in view of Aggarwal (US 2023/0361989 A1).
Per claims 1 and 12, 3GPP teaches “A Network Data Analytics Function containing a Model Training logical function and comprising: at least one memory; and at least one processor coupled with the at least one memory (Page 139, This solution is solving the problem with a data producing NF or NWDAF having heavy load or performance (e.g. due to shortage of memory) to store data or that it will soon purge data for any other reason; page 122, lead to very different levels of computational load for the NWDAF containing MTLF) [Comment: the computing functionality of NWDAF-MTLF means at least one processor; the functionality of purging data at NWDAF means at least one memory.] and configured to cause the Network Data Analytics Function containing the Model Training logical function to: receive a machine learning (ML) model provision request, the ML model provision request comprising: an identifier for at least one Analytic and ML model file specific information; (Section 6.42.2.1, page 141, Fig 6.42.2.1-1: Procedure for trained ML model(s) storage in ADRF; Step 1: The NWDAF containing AnLF sends Nnwdaf_MLModellnfo_Request with the following input parameters Analytics ID(s), ML model file specific information (ML model file serialization format), Notification end point address (ADRF) to the NWDAF containing MTLF.) … and the transceiver further arranged to send, in response to the ML model provision request, an ML model provision response message, the ML model provision response message comprising: the identifier for the at least one Analytic; at least one … trained ML model file […address …]; (Section 6.42.2.1, page 141, Fig 6.42.2.1-1: Procedure for trained ML model(s) storage in ADRF; Step 5: The NWDAF containing MTLF sends Nnwdaf_MLModelInfo_Response with the following parameters Analytics ID(s), Trained ML model file address).
3GPP teaches sending the trained ML model address in the response, instead of the trained ML model. However, the Examiner takes Official Notice that it is well-known to either send a file or send an address of the file. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to substitute sending a trained ML model file address in a response of 3GPP with sending a file as a well-known practice, such that a response comprising the trained ML model file would be sent. One of ordinary skill in the art would have been motivated to do so because this is simple substitution of one known element for another to obtain predictable results (KSR(B), MPEP 2143).
Although 3GPP teaches generating and sending a trained ML model, however 3GPP does not teach protecting the trained ML model using a stored security context. Therefore, 3GPP does not teach “generate a protected trained ML model using a stored security context; … response message comprising: at least one protected trained ML model file; location information of the stored security context.”
Aggarwal teaches that a first Network Data Analytics Function (NWDAF) containing Model Training logical function (MTLF) as a NFp/NF Producer generates a protected ML model using a stored security context (¶ [0295], models being protected in the context of encryption keys, this is for brevity, and that another key may be provided for protecting the models; ¶ [0303], the ML model encryption has been performed by NFp 605. The first ML model may be encrypted using a first key, K. This key K may be a secret that is model specific. In other words, for each model identifier, a new key will be used. In other words, the key used to encrypt the model may be unique to that model; ¶ [0319-0320], an encrypted form of an ML model. The ML model may be encrypted as described above in relation to 6001 … the NFp 704 is the possessor of the encryption key, K; ¶ [0302], an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF))); ¶ [0292], a first network data analytics function (NWDAF-1) may, when acting as an NF service producer (NFp), encrypt an ML model … a second network data analytics function (NWDAF-2) may, when acting as an NF service consumer (NFc) later on request to retrieve the model … to consume the ML model). [Comment: The encryption key in Aggarwal is the claimed “security context”, see claims 2 and 4 of the instant application for such interpretation. The generated encryption key/security context must be inherently stored before being used, and therefore teaches “a stored security context”.] and provides location information of the stored security context to a second Network Data Analytics function (NWDAF) containing an Analytics logical function (AnLF) as NFc /NF consumer (Fig.7; ¶ [0317], the encryption Key K is stored only in the NF Service Producer (NFp), and the NF Service Consumer retrieves the key directly from the NFp; ¶ [0327-0330], During 7007, the NFc 701 signals the NFp 704 … The service request may comprise a public key that may be usable for the NFp 704 to encrypt any information sent back to the NFc 701 … In response to the signalling of 7007, the NFp 704 may verify whether or not the NFc 701 is allowed to access the requested service at 7008 … When the NFp 704 successfully verifies the NFc 701 during 7008, the NFp 704 signals the NFc 701 at 7009. The signalling of 7009 may comprise a service response. This service response may comprise an encrypted version (K′) of the key (K) … During 7010 … the NFc decrypts the encrypted key K′ using the NFc's 701 private key to obtain the key K, the NFc 701 downloads the ML model, and then the NFc 701 decrypts the ML model using the obtained key, K. The NFc 701 may subsequently cause the ML model to be run; ¶ [0302], NF service consumer 601 (e.g., an NWDAF Analytics logical function (AnLF)) … an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF)). [Comment: the transmitted key/security context by the NWDAF containing a MTLF necessarily has the NWDAF’s address as a source address of the transmitted key/security context, which teaches the claimed location information of the stored security context.]
Thus, given the teaching of Aggarwal, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of a NWDAF-MTLF generating a protected ML model using a stored security context and responding with the location of the stored security context as taught by Aggarwal into a NWDAF-MTLF generating a trained ML model and responding with the trained ML model information as taught by 3GPP, such that a NWDAF-MTLF would generate a protected trained ML model using a stored security context and send information of the protected trained ML model including the location of the stored security context in a response. One of ordinary skill in the art would have been motivated to do so because Aggarwal recognizes that it would have been advantageous to protect ML models from attack (¶¶ [0290-0291], Even when the ADRF is genuine and entitled to access the sensitive data, the URI being used to access and retrieve the sensitive data may be leaked and used by a potential attacker to have access to and potentially use the stolen sensitive data. From a security viewpoint, the sensitive data existing protection in this case only relies on the selected security capabilities of the selected transfer protocol (e.g., authentication and/or encryption), which may be insufficient. Aspects of the following aim to address at least one of the above-mentioned issues. In particular, the following aims to provide at least one mechanism for enabling potentially highly valuable sensitive data (such as ML models) to be stored in the ADRF using end to end confidentiality, and to only enable those NF service consumers authorized to retrieve a particular sensitive data to decrypt and/or to perform integrity protection on the retrieved sensitive data.) Additionally, one of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, incorporating known methods of ML models to yield predictable results, especially given that 3GPP and Aggarwal are in the same field of endeavor of a NWDAF-MTLF generating ML models for a NWDAF- AnLF (KSR MPEP 2143).
Per claims 2 and 13, Aggarwal further teaches “wherein the security context comprises encryption information, the encryption information relating to an encryption operation applied to the ML model file” (¶ [0295], models being protected in the context of encryption keys, this is for brevity, and that another key may be provided for protecting the models; ¶ [0303], the ML model encryption has been performed by NFp 605. The first ML model may be encrypted using a first key, K. This key K may be a secret that is model specific. In other words, for each model identifier, a new key will be used. In other words, the key used to encrypt the model may be unique to that model; ¶ [0319-0320], an encrypted form of an ML model. The ML model may be encrypted as described above in relation to 6001 … the NFp 704 is the possessor of the encryption key, K; ¶ [0327-0330], During 7007, the NFc 701 signals the NFp 704 … The service request may comprise a public key that may be usable for the NFp 704 to encrypt any information sent back to the NFc 701 … In response to the signalling of 7007, the NFp 704 may verify whether or not the NFc 701 is allowed to access the requested service at 7008 … When the NFp 704 successfully verifies the NFc 701 during 7008, the NFp 704 signals the NFc 701 at 7009. The signalling of 7009 may comprise a service response. This service response may comprise an encrypted version (K′) of the key (K) … During 7010 … the NFc decrypts the encrypted key K′ using the NFc's 701 private key to obtain the key K, the NFc 701 downloads the ML model, and then the NFc 701 decrypts the ML model using the obtained key, K. The NFc 701 may subsequently cause the ML model to be run). [Comment: The combination/motivation is the same as that of independent claim 1/12.]
Per claims 3 and 14, Aggarwal further teaches “wherein the at least one processor is further configured (¶ [0372], The above described apparatus of each of FIGS. 8 to 11 may comprise at least one processor) to cause the Network Data Analytics Function containing the Model Training logical function to generate a security context; (¶ [0304], Any known method may be used to generate the key; ¶ [0295], models being protected in the context of encryption keys, this is for brevity, and that another key may be provided for protecting the models; ¶ [0303], the ML model encryption has been performed by NFp 605. The first ML model may be encrypted using a first key, K. This key K may be a secret that is model specific. In other words, for each model identifier, a new key will be used. In other words, the key used to encrypt the model may be unique to that model; ¶ [0319-0320], an encrypted form of an ML model. The ML model may be encrypted as described above in relation to 6001 … the NFp 704 is the possessor of the encryption key, K; ¶ [0302], an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF))); ¶ [0292], a first network data analytics function (NWDAF-1) may, when acting as an NF service producer (NFp), encrypt an ML model … a second network data analytics function (NWDAF-2) may, when acting as an NF service consumer (NFc) later on request to retrieve the model … to consume the ML model). [Comment: The encryption key in Aggarwal is the claimed “security context”. Using a new key in Aggarwal is interpreted to be generating the key/security context. In fact, applying any key meets generating the key/security context (e.g., create or retrieve).] and wherein the location information of the stored security context is an address of the Network Data Analytics Function containing the Model Training logical function” (Fig.7; ¶ [0317], the encryption Key K is stored only in the NF Service Producer (NFp), and the NF Service Consumer retrieves the key directly from the NFp; ¶ [0327-0330], During 7007, the NFc 701 signals the NFp 704 … The service request may comprise a public key that may be usable for the NFp 704 to encrypt any information sent back to the NFc 701 … In response to the signalling of 7007, the NFp 704 may verify whether or not the NFc 701 is allowed to access the requested service at 7008 … When the NFp 704 successfully verifies the NFc 701 during 7008, the NFp 704 signals the NFc 701 at 7009. The signalling of 7009 may comprise a service response. This service response may comprise an encrypted version (K′) of the key (K) … During 7010 … the NFc decrypts the encrypted key K′ using the NFc's 701 private key to obtain the key K, the NFc 701 downloads the ML model, and then the NFc 701 decrypts the ML model using the obtained key, K. The NFc 701 may subsequently cause the ML model to be run; ¶ [0302], NF service consumer 601 (e.g., an NWDAF Analytics logical function (AnLF)) … an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF)). [Comment: The combination/motivation is the same as that of independent claim 1/12.]
Per claims 4 and 15, 3GPP further teaches “wherein: the at least one processor is further configured to cause the Network Data Analytics Function containing the Model Training logical function to: receive a … provision request from a Network Data Analytics Function (NWDAF) containing an Analytics logical function, the … provision request comprising the identifier for the at least one Analytic and the ML model file specific information; (Section 6.42.2.1, page 141, Fig 6.42.2.1-1: Procedure for trained ML model(s) storage in ADRF; Step 1: The NWDAF containing AnLF sends Nnwdaf_MLModellnfo_Request with the following input parameters Analytics ID(s), ML model file specific information (ML model file serialization format), Notification end point address (ADRF) to the NWDAF containing MTLF.) … and the transceiver is further arranged to send to the NWDAF containing an Analytics logical function, in response to the … provision request, a … provision response message” (Section 6.42.2.1, page 141, Fig 6.42.2.1-1: Procedure for trained ML model(s) storage in ADRF; Step 5: The NWDAF containing MTLF sends Nnwdaf_MLModelInfo_Response with the following parameters Analytics ID(s), Trained ML model file address).
Aggarwal further teaches the limitations regarding the security context/key. Specifically, Aggarwal further teaches “wherein: the at least one processor is further configured (¶ [0372], The above described apparatus of each of FIGS. 8 to 11 may comprise at least one processor) to cause the Network Data Analytics Function containing the Model Training logical function to: receive a key provision request from a Network Data Analytics Function (NWDAF) containing an Analytics logical function, (¶ [0302], NF service consumer 601 (e.g., an NWDAF Analytics logical function (AnLF)) … an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF); [0292], a first network data analytics function (NWDAF-1) may, when acting as an NF service producer (NFp), encrypt an ML model … a second network data analytics function (NWDAF-2) may, when acting as an NF service consumer (NFc) later on request to retrieve the model) … select a corresponding previously generated security context; and the transceiver is further arranged to send to the NWDAF containing an Analytics logical function, in response to the key provision request, a key provision response message, the key provision response message comprising the selected security context” (Fig.7; ¶ [0317], the encryption Key K is stored only in the NF Service Producer (NFp), and the NF Service Consumer retrieves the key directly from the NFp; ¶ [0327-0330], During 7007, the NFc 701 signals the NFp 704 … The service request may comprise a public key that may be usable for the NFp 704 to encrypt any information sent back to the NFc 701 … In response to the signalling of 7007, the NFp 704 may verify whether or not the NFc 701 is allowed to access the requested service at 7008 … When the NFp 704 successfully verifies the NFc 701 during 7008, the NFp 704 signals the NFc 701 at 7009. The signalling of 7009 may comprise a service response. This service response may comprise an encrypted version (K′) of the key (K) … During 7010 … the NFc decrypts the encrypted key K′ using the NFc's 701 private key to obtain the key K, the NFc 701 downloads the ML model, and then the NFc 701 decrypts the ML model using the obtained key, K. The NFc 701 may subsequently cause the ML model to be run; ¶ [0295], models being protected in the context of encryption keys, this is for brevity, and that another key may be provided for protecting the models; ¶ [0303], the ML model encryption has been performed by NFp 605. The first ML model may be encrypted using a first key, K. This key K may be a secret that is model specific. In other words, for each model identifier, a new key will be used. In other words, the key used to encrypt the model may be unique to that model; ¶ [0319-0320], an encrypted form of an ML model. The ML model may be encrypted as described above in relation to 6001 … the NFp 704 is the possessor of the encryption key, K). [Comment: The combination/motivation is the same as that of independent claim 1/12.]
Per claim 5, 3GPP further teaches “wherein the Network Data Analytics Function containing the Analytics logical function is an apparatus different to the Network Data Analytics Function containing the Model Training logical function” (Section 6.42.2.1, page 141, Fig 6.42.2.1-1: Procedure for trained ML model(s) storage in ADRF; Step 1: The NWDAF containing AnLF sends Nnwdaf_MLModellnfo_Request with the following input parameters Analytics ID(s), ML model file specific information (ML model file serialization format), Notification end point address (ADRF) to the NWDAF containing MTLF.)
Aggarwal also further teaches “wherein the Network Data Analytics Function containing the Analytics logical function is an apparatus different to the Network Data Analytics Function containing the Model Training logical function” (¶ [0302], NF service consumer 601 (e.g., an NWDAF Analytics logical function (AnLF)) … an NF service producer 604 (e.g., an NWDAF Model Training logical function (MtLF); [0292], a first network data analytics function (NWDAF-1) may, when acting as an NF service producer (NFp), encrypt an ML model … a second network data analytics function (NWDAF-2) may, when acting as an NF service consumer (NFc) later on request to retrieve the model). [Comment: The combination/motivation is the same as that of independent claim 1/12.]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kolekar (WO 2023/215720 A1) discloses secure ML model provisioning and sharing by NWDAF.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANNAH S. WANG whose telephone number is (571)272-9018. The examiner can normally be reached on Monday-Friday 9am-5pm EST.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANNAH S WANG/Supervisory Patent Examiner, Art Unit 2631
Prosecution Insights