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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. CN 2022/123452, filed on 09/30/2022.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 03/06/2025, 04/30/2025, 02/04/2026, 06/05/2026 and 07/01/2026 have been considered by the Examiner. The submission is in compliance with the provisions of 37 CFR 1.97.
Claim status
Claims 1-56 have been canceled and claims 57-80 presented as new claims for the examination and remain pending in the application.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 57, 58, 60, 62-67, 69-71 and 73-80 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on security aspects of enablers for Network Automation for 5G - phase 3; (Release 18)", 3GPP DRAFT; S3-221657, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE , 7 July 2022 (2022-07-07), XP052257921, Retrieved from the Internet: URLhttps://tp.3gpp.org/tsg_sa/WG3_Security/TSGS3_107e-AdHoc/Docs/ S3-221657.zip S3-221657 TR33.738 0.2.0-rm.docx [retrieved on 2022-07-07], (hereinafter NPL).
Regarding claim 57.
NPL teaches a method for a consumer network function (NFc) of a communication network (NPL teaches on page 12, under section 6.2.1 (“introduction”), lines 1-3 “the solution…, an authorization token is used by ADRF to verify that the NFc is allowed to access the ML model), the method comprising:
sending, to a first network function (NF) of the communication network, a first request for a first access token associated with a machine learning (ML) model, wherein the first request includes at least one of the following associated with the ML model: an analytics identifier, ID, and an interoperability ID (NPL teaches on page 15, fig. 6.y.2-1 at step 5 the NRF receives a request from the NF at step 3 (i.e., NFc when requesting the access token includes at least the Model Id and/or Analytics Id for which a trained model is needed) and at step 5 (i.e., in case of valid authorization, the NRF provides the token with access token claims including the Model Id, and optionally also the Analytics Id, identifying the type of analytics that the model may be providing which sends a first network function (NF). See. Page 15, steps 1-5 and on page 16 steps 6-11. Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations except for “the request associated with the ML model: an analytics identifier”);
receiving from the first NF a first response that includes the first access token (NPL teaches on page 15, fig. 6.y.2-1, at step 5 the NRF receives a request from the NF at step 3);
sending, to a producer NF (NFp) of the communication network (NPL teaches on page 15, fig. 6.y.2-1 steps 4 and 7), a second request for the ML model, wherein the second request includes the first access token and at least one of the analytics ID and the interoperability ID (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type). Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations except for “the request associated with the ML model: an analytics identifier”); and
receiving from the NFp a second response that includes one or more of the following: the ML model, an identifier of the ML model (NPL teaches on page 15 fig. 6.y.2-1 at step 11 “ADRF after a successful verification finally initiates the model download at the NFc.”), and an address of a storage resource associated with a second NF of the communication network, from which the ML model can be obtained (NPL teaches on page 15, fig. 6.y.2-1, at step 8 “in case of successful verification ADRF provides the NFc a URI to download the model as a service response). See the screenshot of figure 6.y.2-1 bellow to clearly see the process of access request and verification to provide a token with in the NFc and the ML model.
PNG
media_image1.png
624
600
media_image1.png
Greyscale
Regarding claim 58.
NPL teaches wherein one or more of the following applies: the first NF is one of the following: a network repository function (NRF), or an analytics data repository function (ADRF),the NFc is an analytics logical function of a network data analytics function, NWDAF(AnLF); and the NFp is a model training logical function of the network data analytics function, NWDAF(MTLF) (NPL teaches on page 15, fig. 6.y.2-1 at step 2. NF producer shall also register the model specific information including the model metadata when registering its profile in the NRF. This information includes the Model Info/Analytics ID, allowed NF Type/Id and allowed NF Id per Model and further, the NPL teaches on page 16 under section “6.4.1 introduction”, lines 3-6 “the data producer (NWDAF containing MTLF) is generating a security context to protect the ML model information which is then stored protected in the ADRF with the data producer identity so that NF consumers (NWDAF containing AnLF), if authorized, can request the protected ML model information from the ADRF as well as the security context from the data producer to unprotect the ML model information for further processing. Also, see fig. 6.Y.2-1. Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 60.
NPL teaches wherein the second response includes the address of the storage resource associated with the second NF, and the method further comprises: sending, to the first NF, a third request for a second access token associated with the ML model (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type), wherein the third request includes the following: the address of the storage resource associated with the second NF, and at least one of the analytics ID and the interoperability ID; receiving from the first NF a third response that includes the second access token; and obtaining the ML model from the second NF using the second access token and the address of the storage resource associated with the second NF (NPL teaches on page 22 under section 6.6.2.1 general, lines 1-10 “the OAM or some operator defined AF…, in order to analyses the root cause of the anomaly with certain degree of confidence, more information or related data can help. Thus, NWDAF requests inputs from different entities in the system (such as OAM, NRF and NFs) for detailed analysis. Security related data for analytics can also be collected by NWDAF from the NFs (or via OAM). The final output analytics is then sent to the OAM or the AF for adequate measures.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 62.
NPL teaches wherein the address of the storage resource associated with the second NF is a universal resource locator (URL) or a fully qualified domain name (FQDN) (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. MTLF may send an ML model encrypted using a symmetric key (e.g., AES key) before the storage and at step “ADRF stores the ML model and response as per TS 23.288[5], except that the ADRF stores the ML model.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed the limitation of “NF is a universal resource locator (URL)”).
Regarding claim 63.
NPL teaches wherein the second NF is one of the following: the NFp, or an analytics data repository function (ADRF) (NPL teaches on page 15, fig. 6.y.2-1 at step 2. NF producer shall also register the model specific information including the model metadata when registering its profile in the NRF…, and further, the NPL teaches on page 16 under section “6.4.1 introduction”, lines 3-6 “the data producer (NWDAF containing MTLF) is generating a security context to protect the ML model information which is then stored protected in the ADRF with the data producer identity so that NF consumers (NWDAF containing AnLF),... Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 64.
NPL teaches method for a producer network function (NFp) of a communication network (NPL teaches on page 12, under section 6.2.1 (“introduction”), lines 1-3 “the solution…, an authorization token is used by ADRF to verify that the NFc is allowed to access the ML model), the method comprising: registering information associated with a machine learning (ML) model in a network repository function (NRF) of the communication network, wherein: ML model is produced, owned, and/or maintained by the NFp, and the registered information associated with the ML includes an analytics identifier, ID, and an interoperability ID (NPL teaches on page 15 fig. 6.y.2-1 at step 2 NF producer shall also register the model specific information including the model metadata when registering its profile in the NRF. This information includes the Model Info/Analytics ID, allowed NF Type/Id and allowed NF Id per Model); and
encrypting the ML model and sending, to an analytics data repository function (ADRF) of the communication network, a first request to store the encrypted ML model (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access the ML model from ADRF. One-time credentials may include.”), wherein the first request includes one of the following: the encrypted ML model, or a first address of a storage resource associated with the NFp, from which the ML model can be obtained (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. MTLF may send an ML model encrypted using a symmetric key (e.g., AES key) before the storage and at step “ADRF stores the ML model and response as per TS 23.288[5], except that the ADRF stores the ML model.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 65.
NPL teaches receiving, from a consumer NF (NFc) of the communication network, a second request for the ML model, wherein the second request includes a first access token and at least one of the analytics ID and the interoperability ID (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type); and
based on verifying the first access token, sending to the NFc a second response that includes one or more of the following: the ML model, an identifier of the ML model, the first address of the storage resource associated with the NFp, or a second address of a storage resource associated with the ADRF, from which the ML model can be obtained (NPL teaches on page 22 under section 6.6.2.1 general, lines 1-10 “the OAM or some operator defined AF…, in order to analyses the root cause of the anomaly with certain degree of confidence, more information or related data can help. Thus, NWDAF requests inputs from different entities in the system (such as OAM, NRF and NFs) for detailed analysis. Security related data for analytics can also be collected by NWDAF from the NFs (or via OAM). The final output analytics is then sent to the OAM or the AF for adequate measures.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 66.
NPL teaches wherein: the first address of the storage resource associated with the NFp is a first universal resource locator (URL) (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the ND_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed the limitation of “NF is a universal resource locator (URL)”); and
the second address of the storage resource associated with the ADRF is a second URL or a fully qualified domain name (FQDN) (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. MTLF may send an ML model encrypted using a symmetric key (e.g., AES key) before the storage and at step “ADRF stores the ML model and response as per TS 23.288[5], except that the ADRF stores the ML model.”).
Regarding claim 67.
NPL teaches wherein: the first request includes the first address of the storage resource associated with the NFp (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials.); and
the second response includes the first address of the storage resource associated with the NFp or the second address of the storage resource associated with the ADRF (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type).
Regarding claim 69.
receiving from the ADRF a further request for the ML model, wherein the further request includes a second access token and the first address of the storage resource associated with the NFp (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type);
based on verifying the second access token, sending the ADRF a further response that includes the encrypted ML model (NPL teaches on page 13 fig. 6.Y.2-1 at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation…, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. MTLF may send an ML model encrypted using a symmetric key (e.g., AES key) before the storage and at step “ADRF stores the ML model and response as per TS 23.288[5], except that the ADRF stores the ML model.”); and
subsequently receiving from the ADRF the second address of the storage resource associated with the ADRF (LPN teaches on page 18 in section 7a. “the ADRF sends a response back to NWDAF containing AnLF using Nadrf_MLModelManagement_Retrieval. Response with the following parameters Protected ML Model File Information (Trained ML model(s) file, ML model file serialization format, Trained ML Model ID per Analytics ID, NWDAF containing MTLF address)”).
Regarding claim 70.
NPL teaches wherein the registered information associated with the ML model also includes the first address of the storage resource associated with the NFp, and the method further comprises updating the registered information associated with the ML model in the NRF to include the received second address (NPL teaches on page 19 under section “solution details” lines 1-7 “the solution…The following example illustrates the concept of the new DataRetrieval service. Previously, the NWDAF shall have been registered in NRF with Nfprofile which includes additional information, so that different other PLMNs’s NWDAF can consume the Nnwdaf_DataRetrieval service).
Regarding claim 71.
NPL teaches wherein the second response includes the first address of the storage resource associated with the NFp, and the method further comprises: receiving, from the NFc, a third request for the ML model, wherein the third request includes the following: a third access token associated with the ML model, the first address, and at least one of the analytics ID and the interoperability ID (Note that here, the NPL teaches the claimed invention limitations except for the term “third access token”. It would have been an obvious matter of design choice to recite the term “third access token”, since applicant has not disclosed that the term “third access token” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the first, the second or the third etc. token”); and
on verifying the third access token, sending to the NFc a third response that includes the ML model (NPL teaches on page 22 under section 6.6.2.1 general, lines 1-10 “the OAM or some operator defined AF…, in order to analyses the root cause of the anomaly with certain degree of confidence, more information or related data can help. Thus, NWDAF requests inputs from different entities in the system (such as OAM, NRF and NFs) for detailed analysis. Security related data for analytics can also be collected by NWDAF from the NFs (or via OAM). The final output analytics is then sent to the OAM or the AF for adequate measures.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations). Note that here, the NPL teaches the claimed invention limitations except for the term “the third response and request”. It would have been an obvious matter of design choice to recite the term “the third response and request”, since applicant has not disclosed that the term “the third response and request” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the first, the and the second response and request”).
Regarding claim 73.
NPL teaches sending, to a network repository function (NRF) of the communication network, a fourth request for an access token associated with the ML model, wherein the fourth request includes at least one of the analytics ID and the interoperability ID; receiving the requested access token from the NRF; sending to the ADRF a fifth request for the ML model, wherein the fifth request includes the received access token and at least one of the analytics ID and the interoperability ID (Note that here, the NPL teaches the claimed invention limitations except for the term “the fifth request”. It would have been an obvious matter of design choice to recite the term “the fifth request”, since applicant has not disclosed that the term “the fifth request” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the fifth request”); and
receiving from the ADRF a fifth response that includes the ML model, which is then included in the second response to the NFc (NPL teaches the claimed invention limitations except for the term “the fifth request”. It would have been an obvious matter of design choice to recite the term “the fifth request”, since applicant has not disclosed that the term “the fifth request” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the fifth request”).
Regarding claim 74.
NPL teaches a method for an analytics data repository function (ADRF) of a communication network (LPN teaches on page 18 in section 7a. “the ADRF sends a response back to NWDAF containing AnLF using Nadrf_MLModelManagement_Retrieval Response with the following parameters Protected ML Model File Information (Trained ML model(s) file, ML model file serialization format, Trained ML Model ID per Analytics ID, NWDAF containing MTLF address)”), the method comprising:
receiving, from a producer network function (NFp) of the communication network, a first request to store an encrypted machine learning (ML) model, wherein the first request includes the encrypted ML model or a first address of a storage resource associated with the NFp, from which the encrypted ML model can be obtained (NPL teaches on page 18 at step 3b “The NWDAF containing MTLF generates a security context for protecting the ML model information. The security context is per ML model and gets removed once the ML model information is removed from the ADRF. The security context consists of an encryption key Kenc and an integrity key Kint as well as the corresponding security algorithm(s) for encryption and integrity protection. The NWDAF containing MTLF uses the encryption key Kenc and integrity key Kint. to protect the ML model and related information. The MTLF stores the security context and the related ML information for identification of the security context”);
storing the encrypted ML model in a storage resource associated with the ADRF (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access (i.e., validation) the ML model from ADRF. One-time credentials may include.”); and
sending to the NFp a first response that includes a second address of the storage resource associated with the ADRF (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type and further, NPL teaches on page 18 at step 7a “the ADRF… AnLF using Nadrf_MLModelManagement_Retrieval Response with the following parameters Protected ML Model File Information (Trained ML model(s) file, ML model file serialization format, Trained ML Model ID per Analytics ID, NWDAF containing MTLF address).).
Regarding claim 75.
NPL teaches wherein the first request includes the first address of the storage resource associated with the NFp, and the method further comprises: sending to the NFp a further request for the ML model, wherein the further request includes the first address and a second access token (NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type); and receiving from the NFp a further response that includes the encrypted ML model, which is then stored in the storage resource associated with the ADRF (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access (i.e., validation) the ML model from ADRF. One-time credentials may include.”. Note that here, the NPL teaches the claimed invention limitations except for the term “the fourth request”. It would have been an obvious matter of design choice to recite the term “the fourth request”, since applicant has not disclosed that the term “the fourth request” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the first, the second and the third requests”).).
Regarding claim 76.
NPL teaches receiving, from a first NF of the communication, a second request for the ML model, wherein the second request includes a third access token and at least one of the analytics ID and the interoperability ID NPL teaches on page 16, at steps 4, 6 and 7 the second request which include at step 4 “NRF when receiving the access token request, verifies that the NFc is authorized to retrieve the model from ADRF” and at step 6 “6. NFc now provides the access token with the model retrieval service request to the ADRF” and at step 7 “ADRF verifies the access token the ensures that the NFc is indeed authorized for the requested model by verifying the access token claims and then also updates the metadata info of the Model (received in Step 1) to also include the authorized NFc info (NFc Instance ID, NFc type). Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations except for “the request associated with the ML model: an analytics identifier”); and
based on verifying the third access token, sending to the first NF a second response that includes the ML model NPL teaches on page 22 under section 6.6.2.1 general, lines 1-10 “the OAM or some operator defined AF…, in order to analyses the root cause of the anomaly with certain degree of confidence, more information or related data can help. Thus, NWDAF requests inputs from different entities in the system (such as OAM, NRF and NFs) for detailed analysis. Security related data for analytics can also be collected by NWDAF from the NFs (or via OAM). The final output analytics is then sent to the OAM or the AF for adequate measures.” Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations). Note that here, the NPL teaches the claimed invention limitations except for the term “third access token”. It would have been an obvious matter of design choice to recite the term “third access token”, since applicant has not disclosed that the term “third access token” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the first, the second or the third etc. token”).
Regarding claim 77.
NPL teaches wherein one or more of the following applies: the first NF is the NFp or an analytics logical function of a network data analytics function, NWDAF(AnLF); and the NFp is a model training logical function of the network data analytics function, NWDAF(MTLF) (NPL teaches on page 15, fig. 6.y.2-1 at step 2. NF producer shall also register the model specific information including the model metadata when registering its profile in the NRF. This information includes the Model Info/Analytics ID, allowed NF Type/Id and allowed NF Id per Model and further, the NPL teaches on page 16 under section “6.4.1 introduction”, lines 3-6 “the data producer (NWDAF containing MTLF) is generating a security context to protect the ML model information which is then stored protected in the ADRF with the data producer identity so that NF consumers (NWDAF containing AnLF), if authorized, can request the protected ML model information from the ADRF as well as the security context from the data producer to unprotect the ML model information for further processing. Also, see fig. 6.Y.2-1. Note that here, the claim lists features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art and thus, the prior art of record NPL addressed all of the limitations).
Regarding claim 78.
Claim 78 incorporates substantively all the limitation of claim 57 in a network equipment form and is rejected under the same rationale. Furthermore, regarding the limitation of network equipment, the prior art of record NPL teaches on page 19 under section “introduction” lines 7-9 and Roth also teaches in Para. [0043] about the network device.
Regarding claim 79.
Claim 79 incorporates substantively all the limitation of claim 64 in a network equipment form and is rejected under the same rationale. Furthermore, regarding the limitation of network equipment, the prior art of record NPL teaches on page 19 under section “introduction” lines 7-9 and Roth also teaches in Para. [0043] about the network device.
Regarding claim 80.
Claim 80 incorporates substantively all the limitation of claim 74 in a network equipment form and is rejected under the same rationale. Furthermore, regarding the limitation of network equipment, the prior art of record NPL teaches on page 19 under section “introduction” lines 7-9 and Roth also teaches in Para. [0043] about the network device.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 59, 61, 68 and 72 are rejected under 35 U.S.C. 103 as being unpatentable over NPL in view of Roth et al. U.S. Pub. No. 2019/0080099 A1, (hereinafter Roth).
Regarding claim 59. NPL teaches the method of claim 57.
NPL further teaches wherein: the second response includes the ML model, which is encrypted (NPL teaches on page 13 fig. 6.Y.2-1 “secure ML model transfer” an at step 1 “The MTLF trains the ML model and sends ML Model to the ADRF by invoking the…, environment required for ML model execution, URL/link to retrieve configuration, and secrets, and/or a signing key, certificate to generate authentication credentials. MTLF may send an ML model encrypted using a symmetric key (e.g., AES key) before the storage); while NPL teaches about the second response also includes information and validation of the ML model (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access (i.e., validation) the ML model from ADRF. One-time credentials may include.”). NPL does not explicitly teach the response usable to locate keys that can be used for decryption.
However, Roth teaches the response usable to locate keys that can be used for decryption (Roth teaches in Para. [0036] a request might be received with a key that is to be used to decrypt data for use in processing a command associated with the request. That key also might include an embedded key, which is to be maintained by the cryptographic hardware inside the storage device and not exported outside the device).
Therefore, NPL and Roth are analogues arts and they are in the same field of endeavor as they both are directed to the ML model, which is encrypted and in response usable to locate keys that can be used for decryption.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the
claimed invention to modify the teachings of using the response usable to locate keys that can be used for decryption ([0036]) as taught, by Roth into the teachings of NPL invention. One would have been motivated to do so in order to the device can continue to perform as originally intended in the system without modification to existing software or hardware. The secure execution environments are provided where those environments have access to their own storage and keys that are not exported outside of the respective environment, since the storage device is turned into a hardware security module by providing the appropriate firmware.
Regarding claim 61. NPL teaches the method of claim 60.
NPL further teaches wherein the address of the storage resource is encrypted, and the second response also includes validation of the address of the storage resource (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access the ML model from ADRF. One-time credentials may include.”);
while NPL teaches about the second response also includes information and validation of the ML model (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access (i.e., validation) the ML model from ADRF. One-time credentials may include.”). NPL does not explicitly teach the response information usable to locate keys that can be used for decryption.
However, Roth teaches the response information usable to locate keys that can be used for decryption (Roth teaches in Para. [0036] a request might be received with a key that is to be used to decrypt data for use in processing a command associated with the request and further, Roth teaches in Para. [0049] where the key is usable to decrypt the stored information or a subset thereof, and is packaged with instructions as to the task(s) for which the key should be used…).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the
claimed invention to modify the teachings of using the response usable to locate keys that can be used for decryption ([0036]) as taught, by Roth into the teachings of NPL invention. One would have been motivated to do so in order to the device can continue to perform as originally intended in the system without modification to existing software or hardware. The secure execution environments are provided where those environments have access to their own storage and keys that are not exported outside of the respective environment, since the storage device is turned into a hardware security module by providing the appropriate firmware.
Regarding claim 68. NPL teaches the method of claim 67.
NPL further teaches wherein one or more of the following applies: the first address included in the first request is encrypted (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access the ML model from ADRF. One-time credentials may include.”), and the first or second address included in the second response is encrypted (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model, which is stored in ADRF. MTLF also sends one-time credentials to access (i.e., validation) the ML model from ADRF. One-time credentials may include.”).
NPL does not explicitly teach the response the first request also includes information usable to locate keys that can be used for decryption and validation of the first address; and the second response also includes information usable to locate keys that can be used for decryption and validation of the first or second address.
However, Roth teaches the first request also includes information usable to locate keys that can be used for decryption and validation of the first address (Roth teaches in Para. [0050] determining a set of keys associated with an identity or by extracting and decrypting the key from the data storage request. The data can then be stored 506 in the storage device, encrypted under the internal key and further, Roth teaches in Para. [0019] user can receive a resource identifier, specific address, or other such information that can enable the client device 102 to communicate with an allocated resource without having to communicate with the resource manager 110); and
the second response also includes information usable to locate keys that can be used for decryption and validation of the first or second address (Roth teaches in Para. [0036] a request might be received with a key that is to be used to decrypt data for use in processing a command associated with the request and further, Roth teaches in Para. [0049] where the key is usable to decrypt the stored information or a subset thereof, and is packaged with instructions as to the task(s) for which the key should be used…, and further, Roth teaches in Para. [0019] user can receive a resource identifier, specific address).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of using the response usable to locate keys that can be used for decryption and validating based on the address ([0036] and [0049]) as taught, by Roth into the teachings of NPL invention. One would have been motivated to do so in order to operate remote networks using hardware managed by other organizations, thereby reducing infrastructure costs and achieving other advantages. The existing storage device in a system can be replaced using a device with cryptographic capability, hence the device can continue to perform as originally intended in the system without modification to existing software or hardware.
Regarding claim 72.
NPL further teaches wherein the ML model included in the third response is encrypted (NPL teaches on page 13 fig. 6.Y.2-1 at step 6 “MTLF verifies the access token received in step 3. MTLF may send the encryption key used in step 1 to encrypt the ML model…). Note that here, the NPL teaches the claimed invention limitations except for the term “the third response and request”. It would have been an obvious matter of design choice to recite the term “the third response and request”, since applicant has not disclosed that the term “the third response and request” solves any stated problem or is for any particular purpose and thus, it appears that the invention would perform equally well with the other terms like “the first, the and the second response and request”).
NPL does not explicitly teach the third response also includes information usable to locate keys that can be used for decryption and validation of the ML model.
However, Roth teaches the third response also includes information usable to locate keys that can be used for decryption and validation of the ML model (Roth teaches in Para. [0042] which can authenticate the source of the request in some embodiments, such as by validating a digital signature or other such credential as discussed elsewhere herein…, and decrypt the internal key for use in processing the request).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of using the method of validating based on the address ([0049]) as taught, by Roth into the teachings of NPL invention. One would have been motivated to do so in order to operate remote networks using hardware managed by other organizations, thereby reducing infrastructure costs and achieving other advantages. The existing storage device in a system can be replaced using a device with cryptographic capability, hence the device can continue to perform as originally intended in the system without modification to existing software or hardware.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU SHITAYEWOLDETSADIK whose telephone number is (571)270-7142. The examiner can normally be reached M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise can be reached at 5712723865. 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.
/BERHANU SHITAYEWOLDETSADIK/Primary Examiner, Art Unit 2455
Prosecution Insights