DETAILED ACTION
The present Office Action is in response to an application filed on 04/23/2025 wherein claims 52-76 are pending and ready for examination.
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
Domestic Application(s) for which benefit is claimed: this application is a 371 of PCT/EP2023/080572 (11/02/2023).
Foreign Applications for which priority is claimed: China PCT/CN2022/130359 (11/07/2022).
Receipt is acknowledged of certified copies of papers required by all applicable regulations.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/23/2025, 02/04/2026, 06/05/2026 and 07/01/2026 are being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities: in page 19, lines 29-32 (¶[0127] in the PG-Pub) it should say “The exemplary method also includes the operations of blocks 730-740, where the NRF receives from the NFp a request for the profile for the NFc and sends the profile for the NFc to the NFp, in response to the request”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
Claim 55 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.
Claim 55 recites the limitation "wherein the second security operations correspond to the first security operations performed on the ML model by the NFp" in lines 2-3. There is insufficient antecedent basis for this limitation in the claims. There is no mention of any “security operations” in claim 52, or in any of the preceding claims.
Claim Rejections - 35 USC § 102
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.
Claim 73 is 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 TR 33.738 V0.3.3 (2022-10)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP.
Regarding claim 73, 3GPP discloses a method for an analytics data repository function (ADRF) of a communication network, the method comprising:
receiving, from a producer network function (NFp) of the communication network, a first request to store a machine learning (ML) model, wherein the first request includes the following: a correlation identifier (ID) associated with the ML model, and a universal resource locator (URL) associated with the NFp, from which the ML model can be obtained; obtaining the ML model from the NFp using the URL associated with the NFp (in step 1a, NWDAF MtLF (NFp) requests ADRF to store Encrypted Model with metadata: Model Info/analytics Id; and NFc Type, NFc Instance ID and Interoperability indicator for authorization at the retrieval of a particular identified model (note 1: the referred metadata attributes in the solution are intended to be used in the solution for the identification of the model (Model Info/ Analytics Id(s) and NF consumer attributes used for authorization (NF Type, Instance Id and Interoperability indicator); in step 1b, ADRF, in case of successful model storage, provides a URI back to NWDAF MtLF, which may be later used to access the model – see section 6.7.2, pages 27-28; referring to section 6.4.2, if the model is not (yet) stored in the ADRF, steps 3-6 are performed: the NWDAF MTLF generates a security context for protecting the ML model information consisting 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 sends a Nnwdaf_MLModelProvision_Response with Analytics ID(s), Protected Trained ML model file(s), NWDAF containing MTLF Identity; ADRF sends Nnwdaf_MLModelTrainingUpdate_Subscribe with the input parameters Analytics ID(s), ML model file specific information (ML model file serialization format); when the ML model for which the ADRF has subscribed for ML model training update has been updated, the NWDAF MTLF sends Nnwdaf_MLModelTrainingUpdate_Notify with Analytics ID, Protected Trained ML model(s) file, Notification Correlation ID, NWDAF containing MTLF Identity – see 6.4.2, pages 16-19, Fig. 6.4.2-1; Examiner’s note: ML Model File Information includes Trained ML model(s) file, ML model file serialization format, Trained ML Model ID per Analytics ID and NWDAF MTLF address (“URL associated with the NFp”) – see step 7a, section 6.4.2, page 18);
storing the obtained ML model in association with the correlation ID; and sending to the NFp a first response including a URL associated with the ADRF, from which the ML model can be obtained (in step 1a, NF Service producer which trains the model (e.g., NWDAF MtLF), while storing the encrypted ML model in the ADRF, it also appends its metadata; in step 1b, ADRF, in case of successful model storage, provides a URI back to NWDAF MtLF, which may be later used to access the model – see section 6.7.2, pages 27-28, Fig. 6.7.2-1).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in 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 52-59 and 74 are rejected under 35 U.S.C. 103 as being unpatentable over “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 TR 33.738 V0.3.3 (2022-10)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP, in view of Aggarwal et al. (US 20220272537 A1), hereinafter Aggarwal.
Regarding claim 52, 3GPP discloses a method for a consumer network function (NFc) of a communication network (reference is made to sections 6.1, 6.2, 6.4 and 6.7 in pages 12-19 and 26-28), the method comprising:
registering the following with a network repository function (NRF) of the communication network: a (according to step 2 in section 6.7.2, the NF service producer NWDAF MtLF (NFp) registers the model specific information including the model metadata when registering its profile in the NRF, including Model Info/Analytics ID, allowed NF type, NF Instance ID and Interoperability Indicator of consumers with respect to a particular model – see section 6.7.2, Fig. 6.7.2-1, pages 27-28; according to section 6.1.2.1 the consumer (NFc) is enabled to receive a notification when an ML model matching their subscription (registration) parameters becomes available, thus enabling the consumer to request and get the model information from NWDAF MtLF (NFp), and according to section 6.1.2.2, the consumer is enabled to retrieve the ML model from the ADRF; specifically, the NWDAF MtLF (NFp) and/or ADRF can add a service operation for a specific NF type and/or specific instance ID of the consumer to register its NF profile to the NRF so that when the NRF grants an access token to the consumer it does so if the particular service operation is present for the NF type and/or instance ID of the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12; section 6.4.2, provides more details regarding consumer notifications: the NWDAF AnLF (NFc) sends information including AnalyticsID(s), ML Model Filter Info (ML model file specific info) and Target NF to subscribe for notifications – see step 1, section 6.4.2, pages 17-18; according to section 6.2.2, the metadata of the ML model includes ML model ID, analytics ID, vendor ID, MAC or SHA256 signature, and required environment – see steps 1 and 4, section 6.2.2, pages 12-14);
sending a request for the ML model to the NFp, wherein the request includes the first analytics ID and the vendor ID associated with the NFc (the NF Service Consumer (e.g., NWADAF AnLF) when requesting the access token to NRF includes at least the Model ID and/or Analytics ID for which a trained model is needed along with its Interoperability Indicator in addition to the NF type and NF Instance ID – see step 3, section 6.7.2, page 27-28; NF Service Consumer now provides the access token (including the Model ID and Analytics ID, etc. - see steps 3-5 for details on the access token) with the model retrieval service request to the NF Service Producer (e.g., NWDAF MtLF - see step 6, section 6.7.2, page 27-28; see also Fig. 6.7.2-1); and
receiving from the NFp a response that includes a universal resource locator (URL) associated with a second NF of the communication network, from which the ML model can be obtained (NWDAF MtLF (NFp) sends as a service response containing the URI to retrieve the encrypted model, the encryption key ‘K’, further encrypted using NFc public key, to NWDAF AnLF (NFc) - see step 9, section 6.7.2, page 27-28; see also Fig. 6.7.2-1; NFc sends the model retrieval request using the URI (sent by the NFp in step 9) to ADRF (“second NF”) along with the access token (from step 11) and credential information - see step 12, section 6.7.2, page 27-28; see also Fig. 6.7.2-1)
3GPP does not explicitly disclose the NFc registering a vendor identifier (ID) associated with the NFc. That is, it is not explicitly disclose that the vendor identifier (ID) associated with the NFc is included in the NF profile of the NFc.
However, Aggarwal discloses systems and methods for network functions in a cellular core network to control who can access vendor-specific services (see abstract and {0003-0023]) including the NFc registering a vendor identifier (ID) associated with the NFc with a network repository function (NRF) of the communication network (NRF 120 may also be configured to associate an ID of NFc 110, such as a NF Instance ID, with the vendor ID of NFc 110; that is, NRF 120 may link the ID of NFc 110 to the ID of the vendor of NFc 110 and store the vendor ID of NFc 110 together with the ID of NFc 110; for instance, NRF 120 may associate the ID of NFc 110 with the vendor ID of NFc 110 when NFc 110 registers to NRF 110 or upon receiving a discovery request from NFc 110 including its vendor ID – see [0046]; see also [0030], [0041-0056]).
Therefore, 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 method in 3GPP to include the NFc registering a vendor identifier (ID) associated with the NFc with a network repository function (NRF) of the communication network, as taught by Aggarwal. One would have been motivated to make such a combination because if a malicious NF tries to masquerade its vendor ID, the NRF may check if the vendor ID of the NFc, received for example in an access token request, matches the stored vendor ID of the NFc, and the NRF may reject the request upon unsuccessful verification of the access token request, thereby enabling secure sharing of vendor-specific services, as recognized by Aggarwal (see [0046]).
Regarding claim 53, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, further comprising obtaining the ML model from the second NF using the URL (ADRF verifies NFc and, after successful verification, initiates the encrypted model download at the NFc; NFc decrypts the model using encryption key ‘K’ received in step 9 - see steps 13, 14 and 15, section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
Regarding claim 54, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, wherein the second NF associated with the URL is one of the following: the NFp, or an analytics data repository function (ADRF) (NFc sends the model retrieval request using the URI (sent by the NFp in step 9) to ADRF (“second NF”) along with the access token (from step 11) and credential information - see step 12, section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
Regarding claim 55, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, further comprising performing second security operations on the ML model, wherein the second security operations correspond to the first security operations performed on the ML model by the NFp (in step 1a, the NFp trains the ML model and stores the encrypted (“first security operation”) ML model in the ADRF; in step 9, NFp sends the URI to retrieve the ML model along with encryption key ‘K’; and, in step 15 NFc decrypts (“second security operation”) the ML model using encryption key ‘K’ after retrieving it from the ADRF – see section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
Regarding claim 56, 3GPP and Aggarwal disclose all the claimed subject matter in claim 55 above. Furthermore, 3GPP discloses the method, wherein:
the first security operations include one or more of the following: encryption, and integrity protection; and the second security operations include one or more of the following: decryption corresponding to the encryption, and integrity checking corresponding to the integrity protection (in step 1a, the NFp trains the ML model and stores the encrypted (“first security operation”) ML model in the ADRF; in step 9, NFp sends the URI to retrieve the ML model along with encryption key ‘K’; and, in step 15 NFc decrypts (“second security operation”) the ML model using encryption key ‘K’ after retrieving it from the ADRF – see section 6.7.2, page 27-28; see also Fig. 6.7.2-1; in step 1, the NWDAF MtLF generates a security context for protecting the ML model information using a logical function or named network function NKGC; the MtLF may send the ML model encrypted using a symmetric key before storage; the security context consists of an encryption key Kenc, an integrity key Kint, and the corresponding security algorithms for encryption and integrity protection; the NWDAF MtLF uses the encryption key Kent and the integrity key Kint to protect the ML model and related information - see section 6.2.2, pages 12-14).
Regarding claim 57, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, wherein the response from the NFp is based on a match, correspondence, or relationship between the following: the vendor ID registered with the NRF, and the vendor ID included in the request (according to section 6.1.2.1 the consumer (NFc) is enabled to receive a notification when an ML model matching their subscription (registration) parameters becomes available, thus enabling the consumer to request and get the model information from NWDAF MtLF (NFp), and according to section 6.1.2.2, the consumer is enabled to retrieve the ML model from the ADRF; specifically, the NWDAF MtLF (NFp) and/or ADRF can add a service operation for a specific NF type and/or specific instance ID of the consumer to register its NF profile to the NRF so that when the NRF grants an access token to the consumer it does so if the particular service operation is present for the NF type and/or instance ID of the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12. Examiner’s note: as discussed in claim 52, the vendor ID is part of the NF profile of the NFc registered in the NRF and the vendor ID may also be included in the request as disclosed by Aggarwal as it is associated with the NF instance ID of the NFc.).
Regarding claim 58, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, further comprising performing a discovery procedure with the NRF to identify the NFp based on the first analytics ID, wherein the request is sent responsive to the discovery procedure (NRF uses the information present in the access token request, and verifies that the NFc can receive the particular Model/Analytics of the NFp from ADRF - see section 6.3.2, pages 14-16 and step 4 in Fig. 6.3.2-1; the NWDAF containing AnLF (NFc) sends a retrieval request including Analytics ID(s), ML Model Filter Info (ML model file specific information), and optionally Target NF (NWDAF containing MTLF or NFp) to subscribe for notifications (step 1); the ADRF determines if the ML model file for the Analytics ID(s) requested is already stored (discovery); if the ML model file for the Analytics ID(s) requested in not stored in ADRF then step 3, 4, 5, 6 are performed, before these steps, the ADRF discovers the target MTLF from the NRF optionally if it isn't informed by the AnLF in the step 1; If the ML model file for the Analytics ID(s) requested is stored in ADRF the steps 3, 4, 5, 6 are skipped (step 2, see also steps 2a and 2b in Fig. 6.4.2-1) - see section 6.4.2, pages 16-18 and Fig. 6.4.2-1; NRF uses the information present in the access token request, and verifies that the NFc can receive the particular Model/Analytics of the NFp - see section 6.7.2, pages 27-28 and step 4 in Fig. 6.7.2-1).
Regarding claim 59, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses the method, wherein one or more of the following applies: 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) (NF Service producer which trains the model (e.g., NWDAF MtLF); NF Service Consumer (e.g., NWDAF AnLF) – see steps 1-3, section 6.7.2, pages 27-28 and Fig. 6.7.2-1; see also section 6.3.2, pages 14-16 and Fig. 6.3.2-1).
Regarding claim 74, 3GPP and Aggarwal disclose all the claimed subject matter in claim 52 above. Furthermore, 3GPP discloses user equipment and 5G systems but fails to explicitly disclose any details regarding their components and/or architecture.
However, Aggarwal discloses network equipment configured to implement a consumer network function (NFc) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 52 (FIG. 3 illustrates device 300, which may be or comprise, for example, NFc 110, NRF 120 or NFp 130, or a device controlling functioning thereof, possibly when installed therein; comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core; processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor; processor 310 may be a control device; processor 310 may comprise at least one Application-Specific Integrated Circuit, ASIC; processor 310 may comprise at least one Field-Programmable Gate Array, FPGA; processor 310 may comprise an Intel Xeon processor for example; processor 310 may be means for performing method steps in device 300, such as determining, causing transmitting and causing receiving; processor 310 may be configured, at least in part by computer instructions, to perform actions; for instance, if device 300 comprises NRF 120 or NFp 130, processor 310 may be configured to verify that NFc 110 is allowed to access the service – see [0059]; see also [0060-68] and Fig. 3).
Therefore, 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 method in 3GPP to include network equipment configured to implement a consumer network function (NFc) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 52, as taught by Aggarwal. One would have been motivated to make such a combination in order to physically implement the devices performing the methods claimed, as recognized by Aggarwal (see [0059-68]).
Claims 60-69 and 70-72 are rejected under 35 U.S.C. 103 as being unpatentable over “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 TR 33.738 V0.3.3 (2022-10)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP, in view of “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study of Enablers for Network Automation for 5G System (5GS); Phase 3 (Release 18); 3GPP TR 23.700-81 V1.0.0 (2022-09)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP’2022-09.
Regarding claim 60, 3GPP discloses a method for a producer network function (NFp) of a communication network, the method comprising:
receiving, from a consumer network function (NFc) of the communication network, a request for a machine learning (ML) model produced, owned, and/or maintained by the NFp, wherein the request includes the following: a first analytics identifier (ID) associated with the ML model, and a (NF Service Consumer now provides the access token with the model retrieval service request to the NF Service Producer (e.g NWDAF MtLF); specially in indirect communication scenarios CCA may be optionally used for authentication between NF Service Consumer and Network Service Producer – see section 6.7.2, step 6, page 28; as illustrated in Fig. 6.7.2-1, step 6 includes a service request token including the Model ID, Analytics ID and (optionally) CCA authentication);
obtaining a (NF Service Consumer (e.g., NWDAF AnLF) when requesting the access token to NRF includes at least the Model Id and/or Analytics Id for which a trained model is needed, along with its Interoperability indicator in addition to the NF type and NF instance Id; NRF when receiving the access token request, verifies that the NF Service Consumer is authorized to consume the model of the NFp; 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 provide; NF Service Consumer now provides the access token with the model retrieval service request to the NF Service Producer (e.g NWDAF MtLF); specially in indirect communication scenarios CCA may be optionally used for authentication between NF Service Consumer and Network Service Producer; NFp verifies the access token and ensures that the NFc is indeed authorized for the requested model by verifying the access token claims - see section 6.7.2, steps 3-7 and Fig. 6.7.2-1; Examiner’s note: the access token is obtained from the NRF and is associated with the NFc);
authorizing the NFc to access the ML model (according to section 6.1.2.1 the consumer (NFc) is enabled to receive a notification when an ML model matching their subscription (registration) parameters becomes available, thus enabling the consumer to request and get the model information from NWDAF MtLF (NFp), and according to section 6.1.2.2, the consumer is enabled to retrieve the ML model from the ADRF; specifically, the NWDAF MtLF (NFp) and/or ADRF can add a service operation for a specific NF type and/or specific instance ID of the consumer to register its NF profile to the NRF so that when the NRF grants an access token to the consumer it does so if the particular service operation is present for the NF type and/or instance ID of the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12; NFp verifies the access token and ensures that the NFc is indeed authorized for the requested model by verifying the access token claims - see section 6.7.2, step 7 and Fig. 6.7.2-1; in the case of successful token verification, NFp initiates an update of the metadata information of the Model in ADRF (sent in Step la) to include new authorized NFc info (NFc Instance ID, NFc type) in the ADRF; ADRF sends a confirmation with the details of the NFc which is authorized to consume a particular identified model – see section 6.7.2, steps 8a-8b, page 28 and Fig. 6.7.2-1); and
based on authorizing the NFc, sending to the NFc a response that includes a universal resource locator (URL) associated with a second NF of the communication network, from which the ML model can be obtained (NWDAF MtLF (NFp) sends as a service response containing the URI to retrieve the encrypted model, the encryption key 'K', further encrypted using NFc public key, to NWDAF AnLF (NFc) – see section 6.7.2, step 9 and Fig. 6.7.2-1; NFc sends the model retrieval request using the URI (sent by the NFp in step 9) to ADRF (“second NF”) along with the access token (from step 11) and credential information - see step 12, section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
3GPP fails to teach obtaining a profile associated with the NFc and that the authorization is based on a match, correspondence, or relationship between the following: a vendor ID included in the retrieved NF profile, and the vendor ID included in the request.
However, 3GPP’2022-09 teaches key issue description, solution and evaluation/conclusion on further enhancement for network automation, covering NWDAF analytics, ML Model sharing and storage and NWFAD enhancements including obtaining a profile associated with the NFc and the authorization being based on a match, correspondence, or relationship between the following: a vendor ID included in the retrieved NF profile, and the vendor ID included in the request (the MTLF (“NFp”) will determine whether to expose the certain ML models to another provider's AnLF (“NFc”) or not...MTLF includes the support of interoperable indicator in the NF profile for the NRF registration, and the consumer (AnLF) discovers and selects the MTLF that is interoperable for an analytic ID; such Interoperable Indicator encodes the 3GPP-specific Vendor Id...[b]ased on the interoperable indicator, the MTLF determine and select the model, and then MTLF sends the model details to the AnLF - see section 6.15.1, page 61; MTLF when receiving a MLModelProvision request, can verify that the requesting AnLF instance is allowed to retrieve the ML model - see section 6.15.1, page 62; MTLF receives information (e.g. vendor ID) to determine whether the ML model can be provided to the requesting AnLF - see section 6.15.2, note 2; MTLF verifies that vendor information of AnLF as provided by AnLF in the Nnwdaf_MLModellnfo_Request or Nnwdaf_MLModelProvision_Request service requests is correct, i.e. matching the actual AnLF vendor - see section 6.15.2, note 3; MTLF determine the AnLF service provider and determine whether to expose the model or not - see section 6.15.2, step 3; MTLF registers the support of interoperability with the NRF such as Interoperable Support Indicator in the NF profile (e.g. NFProfile in NRF is extended to include a list of AnLF providers (vendors) that can access the MLModelProvision service)...MTLF when receiving a Nwdaf_MLModelProvision or Nnwdaf_MLModellnfo request will determine the AnLF vendor information from the request message to determine if the ML model can be shared with the AnLF - see section 6.15.3).
Therefore, 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 method in 3GPP to include obtaining a profile associated with the NFc and the authorization being based on a match, correspondence, or relationship between the following: a vendor ID included in the retrieved NF profile, and the vendor ID included in the request, as taught by 3GPP’2022-09. One would have been motivated to make such a combination because MTLF when receiving a MLModelProvision request, can verify that the requesting AnLF instance is allowed to retrieve the ML model; otherwise, it can reject the request, as recognized by 3GPP’2022-09 (see page 62, first sentence (b)).
Regarding claim 61, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP’2022-09 discloses the method, wherein authorizing the NFC to access the ML model is further based on a match, correspondence, or relationship between the following: the vendor ID included in the request, and an interoperability ID associated with the NFp and with the ML model (AnLF able to select the MTLF which support the interoperability, i.e. can provide a ML model to the AnLF; MTLF registers the support of interoperability with the NRF such as Interoperable Support Indicator in the NF profile (e.g. NFProfile in NRF is extended to include a list of AnLF providers (vendors) that can access the MLModelProvision service); NRF stores and filter MTLFs that support interoperability and, as a response to the Nnrf_NFDiscovery Request provide the filtered list of MTLF instances to the AnLF - see section 6.15.3, page 63; see also sections 6.15.2, page 62 and 8.5, pages 253-254).
Therefore, 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 method in 3GPP to include wherein authorizing the NFC to access the ML model is further based on a match, correspondence, or relationship between the following: the vendor ID included in the request, and an interoperability ID associated with the NFp and with the ML model, as taught by 3GPP’2022-09. One would have been motivated because each MTFL NF profile therefore has included the Interoperable Support Indicator, which indicates that the MTLF supports the interoperable models and what are the corresponding interoperability conditions, one of the conditions being a list of AnLF providers (vendors) that are allowed to retrieve ML models from the MTLF, as recognized by 3GPP’2022-09 (section 6.15.2, see page 62; see also section 6.47.1, page 160, first paragraph).
Regarding claim 62, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP discloses the method, further comprising, based on authorizing the NFc, updating an allowed network function (NF) instance list associated with the ML model to include an identifier associated with the NFc (in the case of successful token verification, NFp initiates an update of the metadata information of the Model in ADRF (sent in Step 1a) to include new authorized NFc info (NFc Instance ID, NFc type) in the ADRF – see section 6.7.2, step 8a, page 28; see also steps 7 and 8a in Fig. 6.7.2-1, page 27).
Regarding claim 63, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 62 above. Furthermore, 3GPP discloses the method, further comprising sending, to an analytics data repository function (ADRF) of the communication network, an update request that includes the following: the updated allowed NF instance list, and a correlation ID associated with the ML model (When the ML model for which the ADRF has subscribed for ML model training update has been updated, the NWDAF containing MTLF sends Nnwdaf_MLModelTrainingUpdate_Notify with the following parameters Analytics ID, Protected Trained ML model(s) file, Notification Correlation ID, NWDAF containing MTLF Identity – see section 6.4.2, pages 17-18, step 6; in the case of successful token verification, NFp initiates an update of the metadata information of the Model in ADRF (sent in Step 1a) to include new authorized NFc info (NFc Instance ID, NFc type) in the ADRF – see section 6.7.2, step 8a, page 28; see also steps 7 and 8a in Fig. 6.7.2-1, page 27; Examiner’s note: the correlation ID is used throughout and for several different steps in processes between the NFc, ADRF, NRF and NFc).
Regarding claim 64, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP discloses the method, wherein: the second NF associated with the URL is the NFp; and the method further comprises subsequently providing the ML model to the NFc using the URL associated with the NFp (NWDAF MtLF (NFp) sends as a service response containing the URI to retrieve the encrypted model, the encryption key 'K', further encrypted using NFc public key, to NWDAF AnLF (NFc) – see section 6.7.2, step 9 and Fig. 6.7.2-1; NFc sends the model retrieval request using the URI (sent by the NFp in step 9) to ADRF (“second NF”) along with the access token (from step 11) and credential information - see step 12, section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
Regarding claim 65, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 64 above. Furthermore, 3GPP’2022-09 discloses the method, wherein providing the ML model to the NFc is based on a match, correspondence, or relationship between the following: an identifier associated with the NFc, and an allowed NF instance list associated with the ML model (in the case of successful token verification, NFp initiates an update of the metadata information of the Model in ADRF (sent in Step 1a) to include new authorized NFc info (NFc Instance ID, NFc type) in the ADRF – see section 6.7.2, step 8a, page 28; see also steps 7 and 8a in Fig. 6.7.2-1, page 27; NWDAF MtLF (NFp) sends as a service response containing the URI to retrieve the encrypted model, the encryption key ‘K’, further encrypted using NFc public key, to NWDAF AnLF (NFc) - see step 9, section 6.7.2, page 27-28; see also Fig. 6.7.2-1).
Regarding claim 66, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP discloses the method, wherein: the second NF associated with the URL is an analytics data repository function (ADRF) of the communication network; and the method further comprises: sending to the ADRF a first request to store the ML model, wherein the first request includes the following: a correlation ID associated with the ML model, and an URL associated with the NFp, from which the ML model can be obtained; providing the ML model to the ADRF using the URL associated with the NFp; and receiving from the ADRF a first response including the URL associated with the ADRF, which is sent to the NFc in the response (in step 1a, NWDAF MtLF (NFp) requests ADRF to store Encrypted Model with metadata: Model Info/analytics Id; and NFc Type, NFc Instance ID and Interoperability indicator for authorization at the retrieval of a particular identified model (note 1: the referred metadata attributes in the solution are intended to be used in the solution for the identification of the model (Model Info/ Analytics Id(s) and NF consumer attributes used for authorization (NF Type, Instance Id and Interoperability indicator) in step 1b, ADRF, in case of successful model storage, provides a URI back to NWDAF MtLF, which may be later used to access the model – see section 6.7.2, pages 27-28; in step 9, NFp sends the URI to retrieve the ML model along with encryption key ‘K’; and, in step 15 NFc decrypts the ML model using encryption key ‘K’ after retrieving it from the ADRF – see section 6.7.2, page 27-28; see also Fig. 6.7.2-1; NFc sends the model retrieval request using the URI (sent by the NFp in step 9) to ADRF (“second NF”) along with the access token (from step 11) and credential information - see step 12, section 6.7.2, page 27-28; see also Fig. 6.7.2-1; ADRF verifies NFc and, after successful verification, initiates the encrypted model download at the NFc; NFc decrypts the model using encryption key ‘K’ received in step 9 - see steps 13, 14 and 15, section 6.7.2, page 27-28; see also Fig. 6.7.2-1; referring to section 6.4.2, if the model is not (yet) stored in the ADRF, steps 3-6 are performed: the NWDAF MTLF generates a security context for protecting the ML model information consisting 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 sends a Nnwdaf_MLModelProvision_Response with Analytics ID(s), Protected Trained ML model file(s), NWDAF containing MTLF Identity; ADRF sends Nnwdaf_MLModelTrainingUpdate_Subscribe with the input parameters Analytics ID(s), ML model file specific information (ML model file serialization format); when the ML model for which the ADRF has subscribed for ML model training update has been updated, the NWDAF MTLF sends Nnwdaf_MLModelTrainingUpdate_Notify with Analytics ID, Protected Trained ML model(s) file, Notification Correlation ID, NWDAF containing MTLF Identity – see 6.4.2, pages 16-19, Fig. 6.4.2-1; Examiner’s note: ML Model File Information includes Trained ML model(s) file, ML model file serialization format, Trained ML Model ID per Analytics ID and NWDAF MTLF address (“URL associated with the NFp”) – see step 7a, section 6.4.2, page 18).
Regarding claim 67, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 66 above. Furthermore, 3GPP discloses the method, wherein: the method further comprises selecting an ADRF instance for storage of the ML model; the ADRF instance is associated with an ADRF ID; the first request is sent to the ADRF instance; and providing the ML model to the ADRF is based on a match, correspondence, or relationship between the following: the ADRF ID, and the ADRF to which the ML model is provided (MTLF trains the ML model and sends ML Model to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (ML Model) service operation; consumer uses Nnwdaf_MLModelProvision service operation for ANLF receives ML model ID based on analytics ID and ADRF ID to retrieve ML model - see section 6.2.2.1, page 13-14, step 1).
3GPP’2022-09 also discloses the method further comprises selecting an ADRF instance for storage of the ML model; the ADRF instance is associated with an ADRF ID; the first request is sent to the ADRF instance; and providing the ML model to the ADRF is based on a match, correspondence, or relationship between the following: the ADRF ID, and the ADRF to which the ML model is provided (The ML Model profile may include one of the following parameters: NWDAF ID, ADRF ID, Analytics ID(s), model framework, model platform, model type, model algorithm, model compilation language, model Spatial validity, model validity period, model accuracy, model space effectiveness, etc. see section 6.43.2, page 153; data may be stored in an ADRF/NWDAF based on a request to the DCCF or NWDAF from an NWDAF or DCCF service consumer; the request may specify "ADRF Information" indicating whether the data are to be stored in an ADRF, and optionally an ADRF ID – see section 6.46.1, page 157; the NWDAF containing MTLF utilize the NRF to discover ADRF instance unless ADRF information is available by other means…[t]he ADRF then registers/updates the ML model profile to NRF using Nnrf_NFManagement_NFRegister; one or more than one of the following parameters should be included: ADRF ID, ML model ID, Spatial validity, Validity period, model performance and other related information – see section 6.61.2.1, page 203).
Regarding claim 68, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP discloses the method, further comprising performing first security operations on the ML model, wherein the first security operations include one or more of the following: encryption, and integrity protection (“first security operation”) ML model in the ADRF; in step 9, NFp sends the URI to retrieve the ML model along with encryption key ‘K’; and, in step 15 NFc decrypts (“second security operation”) the ML model using encryption key ‘K’ after retrieving it from the ADRF – see section 6.7.2, page 27-28; see also Fig. 6.7.2-1; in step 1, the NWDAF MtLF generates a security context for protecting the ML model information using a logical function or named network function NKGC; the MtLF may send the ML model encrypted using a symmetric key before storage; the security context consists of an encryption key Kenc, an integrity key Kint, and the corresponding security algorithms for encryption and integrity protection; the NWDAF MtLF uses the encryption key Kent and the integrity key Kint to protect the ML model and related information - see section 6.2.2, pages 12-14).
Regarding claim 69, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP discloses the method, wherein one or more of the following applies: 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) (NF Service producer which trains the model (e.g., NWDAF MtLF); NF Service Consumer (e.g., NWDAF AnLF) – see steps 1-3, section 6.7.2, pages 27-28 and Fig. 6.7.2-1; see also section 6.3.2, pages 14-16 and Fig. 6.3.2-1).
Regarding claim 70, 3GPP discloses a method for a network repository function (NRF) of a communication network, the method comprising:
registering the following information in a profile for a consumer network function (NFc) of the communication network: a (according to step 2 in section 6.7.2, the NF service producer NWDAF MtLF (NFp) registers the model specific information including the model metadata when registering its profile in the NRF, including Model Info/Analytics ID, allowed NF type, NF Instance ID and Interoperability Indicator of consumers with respect to a particular model – see section 6.7.2, Fig. 6.7.2-1, pages 27-28; according to section 6.1.2.1 the consumer (NFc) is enabled to receive a notification when an ML model matching their subscription (registration) parameters becomes available, thus enabling the consumer to request and get the model information from NWDAF MtLF (NFp), and according to section 6.1.2.2, the consumer is enabled to retrieve the ML model from the ADRF; specifically, the NWDAF MtLF (NFp) and/or ADRF can add a service operation for a specific NF type and/or specific instance ID of the consumer to register its NF profile to the NRF so that when the NRF grants an access token to the consumer it does so if the particular service operation is present for the NF type and/or instance ID of the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12; section 6.4.2, provides more details regarding consumer notifications: the NWDAF AnLF (NFc) sends information including AnalyticsID(s), ML Model Filter Info (ML model file specific info) and Target NF to subscribe for notifications – see step 1, section 6.4.2, pages 17-18; according to section 6.2.2, the metadata of the ML model includes ML model ID, analytics ID, vendor ID, MAC or SHA256 signature, and required environment – see steps 1 and 4, section 6.2.2, pages 12-14);
3GPP does not explicitly disclose the NFc registering a vendor identifier (ID) associated with the NFc. That is, it is not explicitly disclose that the vendor identifier (ID) associated with the NFc is included in the NF profile of the NFc.
3GPP does not disclose receiving from the NFp a request for the profile for the NFc; and sending the profile for the NFc to the NFp, in response to the request.
However, 3GPP’2022-09 teaches key issue description, solution and evaluation/conclusion on further enhancement for network automation, covering NWDAF analytics, ML Model sharing and storage and NWFAD enhancements including the NFc registering a vendor identifier (ID) associated with the NFc; receiving from the NFp a request for the profile for the NFc; and sending the profile for the NFc to the NFp, in response to the request (the MTLF (“NFp”) will determine whether to expose the certain ML models to another provider's AnLF (“NFc”) or not...MTLF includes the support of interoperable indicator in the NF profile for the NRF registration, and the consumer (AnLF) discovers and selects the MTLF that is interoperable for an analytic ID; such Interoperable Indicator encodes the 3GPP-specific Vendor Id...[b]ased on the interoperable indicator, the MTLF determine and select the model, and then MTLF sends the model details to the AnLF - see section 6.15.1, page 61; MTLF when receiving a MLModelProvision request, can verify that the requesting AnLF instance is allowed to retrieve the ML model - see section 6.15.1, page 62; MTLF receives information (e.g. vendor ID) to determine whether the ML model can be provided to the requesting AnLF - see section 6.15.2, note 2; MTLF verifies that vendor information of AnLF as provided by AnLF in the Nnwdaf_MLModellnfo_Request or Nnwdaf_MLModelProvision_Request service requests is correct, i.e. matching the actual AnLF vendor - see section 6.15.2, note 3; MTLF determine the AnLF service provider and determine whether to expose the model or not - see section 6.15.2, step 3; MTLF registers the support of interoperability with the NRF such as Interoperable Support Indicator in the NF profile (e.g. NFProfile in NRF is extended to include a list of AnLF providers (vendors) that can access the MLModelProvision service)...MTLF when receiving a Nwdaf_MLModelProvision or Nnwdaf_MLModellnfo request will determine the AnLF vendor information from the request message to determine if the ML model can be shared with the AnLF - see section 6.15.3).
Therefore, 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 method in 3GPP to include the NFc registering a vendor identifier (ID) associated with the NFc; receiving from the NFp a request for the profile for the NFc; and sending the profile for the NFc to the NFp, in response to the request, as taught by 3GPP’2022-09. One would have been motivated to make such a combination because MTLF when receiving a MLModelProvision request, can verify that the requesting AnLF instance is allowed to retrieve the ML model; otherwise, it can reject the request, as recognized by 3GPP’2022-09 (see page 62, first sentence (b)).
Regarding claim 71, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 70 above. Furthermore, 3GPP discloses the method, further comprising performing a discovery procedure with the NFc to identify the NFp based on the first analytics ID (NWDAF containing AnLF sends Nadrf_MLModelManagement_RetrievalRequest which includes Analytics ID(s), ML Model Filter Info (ML model file specific information), optionally Target NF (NWDAF containing MTLF) to subscribe for notifications – see step 1, section 6.4.2, page 17; see also Fig. 6.4.2-1; the ADRF determines if the ML model file for the Analytics ID(s) requested is already stored; if the ML model file for the Analytics ID(s) requested in not stored in ADRF then step 3, 4, 5, 6 are performed, before these steps, the ADRF discovers the target MTLF from the NRF optionally if it isn't informed by the AnLF in the step 1 - see step 2, section 6.4.2, page 17; see also Fig. 6.4.2-1).
3GPP’2022-09 also discloses performing a discovery procedure with the NFc to identify the NFp based on the first analytics ID (NRF stores and filter MTLFs that support interoperability and, as a response to the Nnrf_NFDiscovery Request provide the filtered list of MTLF instances to the AnLF - see section 6.15.3, page 63; see also sections 6.15.2, page 62 and 8.5, pages 253-254).
Regarding claim 72, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 70 above. Furthermore, 3GPP discloses the method, wherein one or more of the following applies: 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) (NF Service producer which trains the model (e.g., NWDAF MtLF); NF Service Consumer (e.g., NWDAF AnLF) – see steps 1-3, section 6.7.2, pages 27-28 and Fig. 6.7.2-1; see also section 6.3.2, pages 14-16 and Fig. 6.3.2-1).
Claims 75-76 are rejected under 35 U.S.C. 103 as being unpatentable over “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 TR 33.738 V0.3.3 (2022-10)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP, in view of “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study of Enablers for Network Automation for 5G System (5GS); Phase 3 (Release 18); 3GPP TR 23.700-81 V1.0.0 (2022-09)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP’2022-09 in further view of Aggarwal et al. (US 20220272537 A1), hereinafter Aggarwal.
Regarding claim 75, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 60 above. Furthermore, 3GPP and 3GPP’2022-09 disclose user equipment and 5G systems but fails to explicitly disclose any details regarding their components and/or architecture.
However, Aggarwal discloses systems and methods for network functions in a cellular core network to control who can access vendor-specific services (see abstract and {0003-0023]) including network equipment configured to implement a producer network function (NFp) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 60 (FIG. 3 illustrates device 300, which may be or comprise, for example, NFc 110, NRF 120 or NFp 130, or a device controlling functioning thereof, possibly when installed therein; comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core; processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor; processor 310 may be a control device; processor 310 may comprise at least one Application-Specific Integrated Circuit, ASIC; processor 310 may comprise at least one Field-Programmable Gate Array, FPGA; processor 310 may comprise an Intel Xeon processor for example; processor 310 may be means for performing method steps in device 300, such as determining, causing transmitting and causing receiving; processor 310 may be configured, at least in part by computer instructions, to perform actions; for instance, if device 300 comprises NRF 120 or NFp 130, processor 310 may be configured to verify that NFc 110 is allowed to access the service – see [0059]; see also [0060-68] and Fig. 3).
Therefore, 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 method in 3GPP to include network equipment configured to implement a producer network function (NFp) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 60, as taught by Aggarwal. One would have been motivated to make such a combination in order to physically implement the devices performing the methods claimed, as recognized by Aggarwal (see [0059-68]).
Regarding claim 76, 3GPP and 3GPP’2022-09 disclose all the claimed subject matter in claim 70 above. Furthermore, 3GPP discloses user equipment and 5G systems but fails to explicitly disclose any details regarding their components and/or architecture.
However, Aggarwal discloses systems and methods for network functions in a cellular core network to control who can access vendor-specific services (see abstract and {0003-0023]) including network equipment configured to implement network repository function (NRF) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 70 (FIG. 3 illustrates device 300, which may be or comprise, for example, NFc 110, NRF 120 or NFp 130, or a device controlling functioning thereof, possibly when installed therein; comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core; processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor; processor 310 may be a control device; processor 310 may comprise at least one Application-Specific Integrated Circuit, ASIC; processor 310 may comprise at least one Field-Programmable Gate Array, FPGA; processor 310 may comprise an Intel Xeon processor for example; processor 310 may be means for performing method steps in device 300, such as determining, causing transmitting and causing receiving; processor 310 may be configured, at least in part by computer instructions, to perform actions; for instance, if device 300 comprises NRF 120 or NFp 130, processor 310 may be configured to verify that NFc 110 is allowed to access the service – see [0059]; see also [0060-68] and Fig. 3).
Therefore, 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 method in 3GPP to include network equipment configured to implement network repository function (NRF) of a communication network, wherein the network equipment comprises: communication interface circuitry configured to communicate with network equipment that implements other network functions (NFs) of the communication network; and processing circuitry operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to perform the method of claim 70, as taught by Aggarwal. One would have been motivated to make such a combination in order to physically implement the devices performing the methods claimed, as recognized by Aggarwal (see [0059-68]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Aggarwal et al. (US 20230155832 A1) discloses an apparatus configured to process a request for an access token authorizing access for a network function consumer to a service provided by a network function producer, the request being received in the apparatus from a service communication proxy, wherein the processing comprises one or more of the following verification: verification that a credential data element comprised in the request, cryptographically signed by the network function consumer, identifies the request, the service or a type of the service, and verification with reference to a further node, or to a profile of the network function consumer, that the service communication proxy is authorized to act on behalf of the network function consumer, and transmit, responsive to at least one of the verifications being successful, the requested access token, the access token comprising an indication of the service communication proxy.
Aggarwal et al. (US 20230361989 A1) discloses a method, computer program, and an apparatus for a network function service consumer for: retrieving, from a first repository function, protected sensitive data; retrieving, from a second network function, at least one encrypted key; decrypting the retrieved at least one encrypted key using a private key associated with the network function service consumer to obtain a respective at least one key; and performing at least one of: decryption of the protected sensitive data using the at least one key to obtain sensitive data or integrity protected sensitive data; or verification of the integrity of the protected sensitive data using the at least one key.
Aggarwal et al. (US 20230353561 A1) discloses methods, systems, apparatuses, and computer program products for authorized machine learning model retrieval for a communications network. In this regard, an access token request for one or more machine learning models related to a communications network is received from a network function service consumer (NFc). The access token request includes information to identify the one or more machine learning models. The NFc is then authorized with respect to the one or more machine learning models based on the information included in the access token request. Additionally, enhanced an access token for retrieving the one or more machine learning models is provided to the NFc based on valid authorization of the NFc with respect to the one or more machine learning models.
Bega et al. (US 20230079052 A1) discloses an apparatus for use by a communication network element or communication network function configured to operate as an analytics entity and having an analytics logical function. The apparatus is caused to: receive a request, from a service consumer, for provision of a custom analytics service, process data retrieved from the request for determining whether a model for providing the requested custom analytics service is prepared, and in case the determination is negative, determine and select a model training entity having a model training logical function which is able to create a model for custom analytics and has access to data required for the requested custom analytics service, request, from the selected model training entity, to obtain a trained model capable of providing the requested custom analytics service and forward the information specifying the custom analytics service to the selected model training entity.
Bommisetty et al. (US 20240056506 A1) discloses network function validation. The first network device receives, from a second network device, a request including profile information of the second network device to be validated, obtain registered profile information of the second network device from a third network device maintaining a blockchain ledger storing the registered profile information, and validate the profile information of the second network device based on the registered profile information. The validation can be implemented via blockchain.
Kunz et al. (US 20250365212 A1) discloses a method in a Network Data Analytics Function containing a Model Training logical function. The method comprises receiving 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, and generating a protected trained ML model using a stored security context. The method further comprises sending, 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 protected trained ML model file; and location information of the stored security context.
Lee et al. (US 20220108214 A1) discloses a machine learning (ML) model management method for a network data analytics function (NWDAF) device. The NWDAF device performs at least one of an analytics logical function (AnLF) for network data and an ML model training logical function (MTLF).
Ottersten et al. (US 20210345134 A1) discloses a wireless communications system and a method therein for handling of machine learning. The system includes a central node and one or more intermediate nodes arranged between the central node and one or more leaf nodes. Further, at least one out of the nodes includes a machine learning unit. The system determines, by means of the machine learning unit and a machine learning model relating to at least one node out of the one or more intermediate nodes or the one or more leaf nodes, a prediction of a performance of the at least one node based on input data relating to the at least one node. Further, the system performs, based on the determined prediction, an operation relating to the at least one node, and communicates the determined prediction and/or information relating to the machine learning model to one or more other nodes.
Roth et al. (US 20190080099 A1) discloses a storage device can include processing and cryptographic capability enabling the device to function as a hardware security module (HSM). This includes the ability to encrypt and decrypt data using a cryptographic key, as well as to perform processing using such a key, independent of whether that processing involves data stored on the device. An internal key can be provided to the drive, whether provided before customer software access or received wrapped in another key, etc. That key enables the device to perform secure processing on behalf of a user or entity, where that key is not exposed to other components in the network or environment. A key may have specified tasks that can be performed using that key, and can be discarded after use. In some embodiments, firmware is provided that can cause a storage device to function as an HSM and/or processing device with cryptographic capability.
Srivastava et al. (US 11611626 B1) discloses a method for distributing network function (NF) high availability (HA) topology information in a core network includes, at an NF repository function (NRF) including at least one processor, receiving, from a plurality of producer NFs in an NF set, NFRegister requests including NF HA topology information for the producer NFs. The method further includes registering the producer NFs and storing the NF HA topology information for the producer NFs. The method further includes receiving, from a consumer NF or service communication proxy (SCP), an NFDiscover request containing at least one service discovery parameter that corresponds to a service provided by the producer NFs. The method further includes responding to the NFDiscover request by generating an NFDiscover response, including, in the NFDiscover response, the NF HA topology information for the producer NFs, and transmitting the NFDiscover response to the consumer NF or SCP.
Zhao et al. (US 20250373701 A1) discloses supporting API prefix in callback URI. A first first device is provided comprising at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, with the at least one processor, cause the first device at least to: receive, from a second device, a service request message, wherein the service request message comprises a first callback Uniform Resource Identifier, URI, with a first Application Programming Interface, API, prefix; in response to determining that the second device is not reachable, send, to a third device, a discovery request for discovering a further second device instance; receive, from the third device, a discovery response; determine a second callback URI based on the discovery response; and send to the further second device instance a callback request message based on the second callback URI.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights