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 .
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.
Claims 55-74 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 55, 65 and 74 recites limitation “can be” renders the claim indefinite because the term “can be” is considered as optional language and thus renders the claim indefinite because it is unclear whether the limitations following the term “can be” are part of the claimed invention (see MPEP § 2173.05(d)) since the claimed limitations following the term “can be” is optional, and thus gets no patentable weight because as a matter of linguistic precision, optional claim elements do not narrow claim limitations since they can be omitted. Dependent claims 10-15 are also rejected under the same rationale set for the for claim 9 above.
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.
Claim(s) 74 is/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 TR 33.738 V0.3.3 (2022-10)” (NPL provided by the Applicant with the IDS submission of 04/23/2025), hereinafter 3GPP.
For claim 74, 3GPP teaches that A method for an analytics data repository function (ADRF) of a communication network (3GPP teaches that (in step 1a, the NFp trains the ML model and stores the encrypted (“first security operation”) ML model in the ADRF as 3GPP teaches in page.27), the method comprising:
receiving, from a producer network function (NFp) of the communication network, a first
request to store a machine learning (ML) model that is produced, owned, and/or
maintained by the NFp (3GPP teaches that 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),
wherein the first request includes the following: an analytics 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 (3GPP teaches that 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); obtaining the ML model from the NFp using the URL associated with the NFp; and sending to the NFp a first response that includes an URL associated with the ADRF, from which the ML model can be obtained (3GPP teaches that 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). furthermore, (examiner notes that limitation “can be” renders the claim indefinite because the term “can be” is considered as optional language and thus renders the claim indefinite because it is unclear whether the limitations following the term “can be” are part of the claimed invention (see MPEP§ 2173.05(d)) since the claimed limitations following the term “can be” is optional, and thus gets no patentable weight because as a matter of linguistic precision, optional claim elements do not narrow claim limitations since they can be omitted.
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 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.
Claims 55-73 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 views of Aggarwal et al (2022/0272537).
For claim 55, 3GPP teaches that a method for a consumer network function (NFc) of a communication network (3GPP teaches that the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12), the method comprising:
sending, to a network repository function (NRF) of the communication network, a first
request for a first access token associated with a machine learning (ML) model
that is produced, owned, and/or maintained by a producer network function (NFp)
of the communication network, wherein the first request includes the following:
an analytics identifier (ID) associated with the ML model, 3GPP teaches that 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);
receiving from the NRF a first response that includes the first access token (3GPP teaches that 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 to the NFp a second request for the ML model, wherein the second request
includes the following: the first access token, the analytics ID, 3GPP teaches that 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 second 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 (3GPP teaches that 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). furthermore, (examiner notes that limitation “can be” renders the claim indefinite because the term “can be” is considered as optional language and thus renders the claim indefinite because it is unclear whether the limitations following the term “can be” are part of the claimed invention (see MPEP§ 2173.05(d)) since the claimed limitations following the term “can be” is optional, and thus gets no patentable weight because as a matter of linguistic precision, optional claim elements do not narrow claim limitations since they can be omitted.
3GPP fails to teach that a vendor
Aggarwal teaches, similar system, a vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include a vendorgenerated based on an ID of a vendor of the NFc, and possibly a policy related to an ID of the vendor of the NFp (Aggarwal, par.30).
For claim 56, 3GPP, as modified by Aggarwal, further teaches that wherein the CCA associated with the NFc is a token that includes one or more of the following: an ID associated with the NFc, an indication of an intended audience of the CCA, an indication of an expiration time for the CCA, and the vendor ID associated with the NFc ((3GPP teaches that 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).
For claim 57, 3GPP, as modified by Aggarwal, further teaches that wherein one or more of the following applies:
the indication of an intended audience is an NF type associated with the NRF; and
the indication of an expiration time is a timestamp that restricts a lifetime of the token (3GPP teaches that 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).
For claim 58, 3GPP, as modified by Aggarwal, further teaches that wherein:
the method further comprises obtaining the ML model from the second NF using the
URL and the second access token (3GPP teaches that 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); and the second NF is one of the following: the NFp, or an analytics data repository function (ADRF) of the communication network (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).
For claim 59, 3GPP, as modified by Aggarwal, further teaches that performing second security operations on the obtained ML model, wherein the second security operations correspond to first security operations performed on the ML model by the NFp (3GPP teaches that 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).
For claim 60, 3GPP, as modified by Aggarwal, further teaches that wherein:
the first security operations include encryption and/or integrity protection; and
the second security operations include decryption corresponding to the encryption and/or integrity checking corresponding to the integrity protection (3GPP teaches that 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).
For claim 61, 3GPP, as modified by Aggarwal, further teaches that registering the following with the NRF: the 3GPP teaches that 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).
3GPP fails to teach that the vendor
Aggarwal teaches, similar system, the vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include vendor
For claim 62, 3GPP, as modified by Aggarwal, further teaches that wherein one or more of the following applies:
the first response from the NRF is based on a match, correspondence, or relationship
between the
associated with the NFp and with the ML model; and
the second response from the NFp is based on a match, correspondence, or relationship between the 3GPP teaches that 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.).
3GPP fails to teach that the vendor
Aggarwal teaches, similar system, the vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include vendor
For claim 63, 3GPP, as modified by Aggarwal, further teaches that performing a discovery procedure with the NRF to identify the NFp based on the analytics ID, wherein the first request is sent responsive to the discovery procedure (3GPP teaches that 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).
For claim 64, 3GPP, as modified by Aggarwal, further teaches that 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) (3GPP teaches that 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).
For claim 65, 3GPP teaches that method for a producer network function (NFp) of a communication network (3GPP teaches that the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12), the method comprising:
receiving, from a consumer network function (NFc) of the communication network, a
second request for a machine learning (ML) model that is produced, owned,
and/or maintained by the NFp, wherein the second request includes the following:
a first access token issued by a network repository function (NRF) of the
communication network, an analytics identifier (ID) associated with the ML model,
a 3GPP teaches that 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);
based on the first access token, authorizing the NFc to access the ML model associated
with the analytics ID (3GPP teaches that 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); and based on authorizing the NFc, sending to the NFc a second response that includes a second access token and a universal resource locator (URL) associated with a second NF of the communication network, from which the ML model can be obtained (3GPP teaches that 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). furthermore, (examiner notes that limitation “can be” renders the claim indefinite because the term “can be” is considered as optional language and thus renders the claim indefinite because it is unclear whether the limitations following the term “can be” are part of the claimed invention (see MPEP§ 2173.05(d)) since the claimed limitations following the term “can be” is optional, and thus gets no patentable weight because as a matter of linguistic precision, optional claim elements do not narrow claim limitations since they can be omitted.
3GPP fails to teach that a vendor
Aggarwal teaches, similar system, a vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include a vendor
For claim 66, 3GPP, as modified by Aggarwal, further teaches that 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 (3GPP teaches that 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), wherein the first request includes the following:
the analytics ID associated with the ML model, and a 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, from which the ML model can be obtained (3GPP teaches that 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). furthermore, (examiner notes that limitation “can be” renders the claim indefinite because the term “can be” is considered as optional language and thus renders the claim indefinite because it is unclear whether the limitations following the term “can be” are part of the claimed invention (see MPEP§ 2173.05(d)) since the claimed limitations following the term “can be” is optional, and thus gets no patentable weight because as a matter of linguistic precision, optional claim elements do not narrow claim limitations since they can be omitted.
For claim 67, 3GPP, as modified by Aggarwal, further teaches that wherein providing the ML model to the ADRF
comprises verifying a third access token issued by the NRF and provided by the ADRF (3GPP teaches that 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).
For claim 68, 3GPP, as modified by Aggarwal, further teaches that wherein the second response also includes an identifier of the ADRF, at which the ML model is stored (3GPP teaches that 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).
For claim 69, 3GPP, as modified by Aggarwal, further teaches that wherein:
the second NF associated with the URL is an analytics data repository function (ADRF)
of the communication network; and the method further comprises:
based on authorizing the NFc, sending to the NRF a third request for a second
access token associated with the ML model (3GPP teaches that 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), wherein the third request includes the analytics ID associated with the ML model, the
associated with the NFc, the CCA associated with the NFc, and an ID
associated with the ADRF; and receiving from the NRF a third response that includes the second access token (3GPP teaches that 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).
3GPP fails to teach that the vendor
Aggarwal teaches, similar system, a vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include a vendor
For claim 70, 3GPP, as modified by Aggarwal, further teaches that wherein:
the second NF associated with the URL is the NFp; and the method further comprises providing the ML model to the NFc using the URL and the first access token (3GPP teaches that 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).
For claim 71, 3GPP, as modified by Aggarwal, further teaches that wherein:
the method further comprises performing first security operations on the ML model
before providing the ML model to the NFc or to the ADRF; and
the first security operations include encryption and/or integrity protection (3GPP teaches that “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).
For claim 72, 3GPP, as modified by Aggarwal, further teaches that wherein the CCA associated with the NFc is a token that includes one or more of the following:
an ID associated with the NFc, an indication of an intended audience of the CCA,
an indication of an expiration time for the CCA, and the vendor ID associated with the NFc ((3GPP teaches that 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).
For claim 73, 3GPP teaches that a method for a network repository function (NRF) of a communication network (3GPP teaches that the NF Service Consumer (NFc) – see sections 6.1.2.1 and 6.1.2.2, page 12), the method comprising:
registering the following information in
of the communication network: a first analytics identifier (ID) associated with a machine learning (ML) model that is produced, owned, and/or maintained by the NFp; and
an interoperability ID that includes or is associated with a list
to access the ML model (3GPP teaches that 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); receiving from the NFp a third request for a second access token associated with the ML model, wherein the third request includes the following:
the first analytics ID associated with the ML model,
a
communication network (3GPP teaches that 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), wherein the NFc is requesting access to the ML model, a client credentials assertion (CCA) associated with the NFc, and
an ID associated with an analytics data repository function (ADRF) of the
communication network, at which the ML model is stored (3GPP teaches that 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 that 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);
authorizing the NFc to access the ML model stored at the ADRF, based on the following: verification of the CCA associated with the NFc, and
a match, correspondence, or relationship between the
third request and the interoperability ID registered in the
NFp; and based on authorizing the NFc, sending to the NFp a third response that includes the second access token (3GPP teaches that 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).
3GPP fails to teach that a profile for a producer network function (NFp)
of the communication network, a list of vendors allowed
to access the ML model, a vendor
third request and the interoperability ID registered in the profile for the
NFp.
Aggarwal teaches, similar system, a producer network function (NFp)
of the communication network (Aggarwal teaches that verifying that the network function consumer is allowed to access the service is further based on a profile of the network function producer as Aggarwal teaches in par.8), a list of vendors allowed to access the ML model and a vendorAggarwal teaches that means for verifying by the network repository function, based at least on the identity of the vendor of the network function consumer as Aggarwal teaches in abstract and par.30) and a match, correspondence, or relationship between the vendor ID included in the third request and the interoperability ID registered in the profile for the NFp (Aggarwal teaches that NRF 120 may verify that the received vendor IDs match the information present in the NFService or the NF profile of NFc 110 as Aggarwal teaches in par.47). It would have been obvious to one ordinary skill in the art before effective filling date to modify 3GPP to include a vendor
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/ /MOEEN KHAN/ Primary Examiner, Art Unit 2436 Examiner, Art Unit 2436
Prosecution Insights