DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on 04/30/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Objections
Claims 1-20 are objected to because of the following informality:
Claim 1 recites, “receiving by a first network function in the core network from a user equipment (UE) or a radio access network (RAN) a model update request that comprises a model identifier of an ML model” (lines 3-4). It is suggested to replace it with “receiving, by a first network function in the core network from a user equipment (UE) or a radio access network (RAN), a model update request that comprises a model identifier of an ML model” for more clarity.
Claim 1 recites, “obtaining by the first network function information for the model update on the basis of the received model update request and a communication with a second network function” (lines 4-5). It is suggested to replace it with “obtaining, by the first network function, information for the model update on the basis of: the received model update request; and a communication with a second network function” for more clarity.
Claim 1 recites, “transferring by the first network function to the UE or the RAN a model update response that comprises the information for the model update.” (lines 6-7). It is suggested to replace it with “transferring, by the first network function to the UE or the RAN, a model update response that comprises the information for the model update.” for more clarity.
Claim 4 recites, “an ADFR” (line 1). It is suggested to replace it with “an analysis data repository (ADFR)” for more clarity.
Claim 5 recites, “wherein the model management retrieve request essentially comprises at least one of an analytics identifier correlated with the model identifier and the model identifier, while optionally comprising a recommendation indicator” (lines 1-3). It is suggested to replace it with “wherein the model management retrieve request comprises: i) at least one of: an analytics identifier correlated with the model identifier or the model identifier, or ii) a recommendation indicator and the at least one of: the at least one of: the analytics identifier correlated with the model identifier or the model identifier” for more clarity. Claims 10 and 14 are objected to at least based on a similar rationale applied to claim 5.
Claim 8 recites, “wherein the model update information” (line 2). It is suggested to replace it with “wherein the information for the model update” for more clarity.
Claim 9 recites, “NWDAF” (line 1). It is suggested to replace it with “network data analysis function (NWDAF)” for more clarity.
Claim 15 recites, “the analytics identifier” (line 3). It is suggested to replace it with “an analytics identifier” for more clarity.
Claim 17 recites, “AMF” (line 1). It is suggested to replace it with “access and mobility function (AMF)” for more clarity.
Claim 18 recites, “A method where a UE performs an ML model update” (line 1). It is suggested to replace it with “A method where a user equipment (UE) performs an machine learning (ML) model update” for more clarity.
Claim 18 recites, “transmitting to a first network function of a core network a model update request which comprises a model identifier of an ML model when the model update correlated with the ML model in operation is determined to be necessary” (lines 2-4). It is suggested to replace it with “transmitting, to a first network function of a core network, a model update request which comprises a model identifier of an ML model when the model update correlated with the ML model in operation is determined to be necessary” for more clarity.
Claim 18 recites, “receiving from the first network function a model update response” (line 5). It is suggested to replace it with “receiving, from the first network function, a model update response” for more clarity.
Claim 18 recites, “receiving from the first network function a model update response” (line 5). It is suggested to replace it with “receiving, from the first network function, a model update response” for more clarity.
Claims 2-17 and 19-20 are also objected to since they are directly or indirectly dependent upon the objected claims, as set forth above.
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.
Claims 5, 10 and 14 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 5 recites, “the model management retrieve request requests the ADRF to provide the ML model recommended on the basis of the model identifier when the recommendation indicator has a value of 'true'.” (lines 5-6). The “recommendation indicator” is an optional limitation in the preceding lines of claim 5. Thus, it is unclear whether the “recommendation indicator“ is even used for determining it has a value of ‘true’ in claim 5, since the essential step regarding the model management retrieve request comprising “a recommendation indicator” does not exist in claim 5. Claims 10 and 14 are rejected at least based on a similar rationale applied to claim 5. For the sake of examination purpose only, it is interpreted as best understood.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 1, 9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Duan et al (US Publication No. 2024/0281719 A1) in view of Lutch et al (US Publication No. 2025/0350383 A1).
Regarding claim 1, Duan discloses, a method where a core network supports a machine learning (ML) model update [FIG. 14; its related descriptions; ¶0401-0408, a method where a core network including AMF and NWDAF supports a ML model update], the method comprising:
receiving by a first network function in the core network from a user equipment (UE) or a radio access network (RAN) a model update request [FIG. 14; its related descriptions; ¶0401, (S812), sending, by the UE, the first NAS message (i.e., model update request) for requesting a model update, to the AMF entity (i.e., first network function); note that the AMF receives a model update request from the UE];
obtaining by the first network function information for the model update on the basis of the received model update request and a communication with a second network function [FIG. 14; its related descriptions; ¶0403, (S813), determining, by the AMF entity, the NWDAF entity, according to the first NAS message, and sending a fifth model update request to the NWDAF entity; further see ¶0390 and ¶0403-0406; note that the AMF obtains information for the global ML model based on the first NAS message and communication with the first network function entity]; and
transferring by the first network function to the UE or the RAN a model update response that comprises the information for the model update [FIG. 14; its related descriptions; ¶0408-0409, S816, sending, by the AMF entity, the second NAS message to the UE in response to the model update. The second NAS message (i.e., model update response) includes the information on the second model file, and may also include the subscription correlation information; further see ¶0390-0392; note that the AMF sends the second NAS message to the UE].
Although Duan discloses, “receiving by a first network function in the core network from a user equipment (UE) or a radio access network (RAN) a model update request” as set forth above, Duan does not explicitly disclose (see, italicized and bold limitations), a model update request that comprises a model identifier of an ML model.
However, Lutch discloses, a model update request that comprises a model identifier of an ML model [¶0211, at 517, the WTRU sends a ML model update request to the gNB (with model ID)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by Lutch in the system of Duan in order to identify the particular ML model targeted for updating [e.g., ¶00211 of Lutch].
Regarding claim 9, Duan in view of Lutch discloses, the method of claim 1 as set forth above.
Duan discloses, wherein the second network function comprises an NWDAF [FIG. 14; its related descriptions; ¶0403, S813, determining, by the AMF entity, the NWDAF entity (i.e., second network function), according to the first NAS message, and sending a fifth model update request to the NWDAF entity], and the obtaining the information for the model update comprises of the first network function transmitting a model provision request to the NWDAF [FIG. 14; its related descriptions; ¶0403, S813, sending a fifth model update request to the NWDAF entity] and receiving from the NWDAF a model provision response [FIG. 14; its related descriptions; ¶0406, S815, sending, by the NWDAF, a model update completion notification to the AMF entity] that is the basis for obtaining the information for the model update [FIG. 14; its related descriptions; ¶0410, S817, obtaining, by the UE, the second model file, according to the information on the second model file; further see ¶0406-407, the model update completion notification includes information on the second model file].
Regarding claim 17, Duan in view of Lutch discloses, the method of claim 1 as set forth above.
Duan discloses, wherein the first network function comprises an AMF[FIG. 14; its related descriptions; ¶0401, (S812), sending, by the UE, the first NAS message for requesting a model update, to the AMF entity (i.e., first network function); note that the AMF receives a model update request from the UE].
Regarding claim 18, Duan discloses, a method where a UE performs an ML model update [FIG. 14; its related descriptions; ¶0401-0408, a method where UE perform an ML model update], the method comprising:
transmitting to a first network function of a core network a model update request [FIG. 14; its related descriptions; ¶0401, (S812), sending, by the UE, the first NAS message (i.e., model update request) for requesting a model update, to the AMF entity (i.e., first network function)] when the model update correlated with the ML model in operation is determined to be necessary [¶0215-0216, after a UE creates a local ML model and during a stage of applying the local ML model, the UE may retrain the local ML model based on local training data and update the model parameters. After the local ML model completes training, the UE sends the local model parameters to the first network function entity to implement federated learning; further see ¶0400 and 0401, the UE retrains the local ML model based on local training data (S811) and thereafter sends a first NAS message requesting a model update (S812); note that Duan teaches associates an operating ML model and a model-retraining/model-parameter-update operation with a subsequent model-update request, providing a direct operational correspondence to the claimed condition preceding transmission of the model-update request],
receiving from the first network function a model update response which comprises information for the model update [FIG. 14; its related descriptions; ¶0408-0409, S816, sending, by the AMF entity, the second NAS message to the UE in response to the model update. The second NAS message (i.e., model update response) includes the information on the second model file, and may also include the subscription correlation information; further see ¶0390-0392], and
performing the ML model update on the basis of the information for the model update [FIG. 14; its related descriptions; ¶0411, (S818) updating, by the UE, the local machine learning model, according to the second model file. That is, the UE can update the local machine learning model based on the updated global model parameter in the second model file; further see ¶0393-0394, (S805) updating the local machine learning model according to the second model file].
Duan does not explicitly disclose (see, italicized and bold limitations), a model update request which comprises a model identifier of an ML model.
However, Lutch discloses, a model update request which comprises a model identifier of an ML model [¶0211, at 517, the WTRU sends a ML model update request to the gNB (with model ID)]..
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by Lutch in the system of Duan in order to identify the particular ML model targeted for updating [e.g., ¶0294 of Lutch].
Claims 2-8, 10-13, 15-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Duan et al (US Publication No. 2024/0281719 A1) in view of Lutch et al (US Publication No. 2025/0350383 A1) and further in view of 3GPP TS 23.288 V18.2.0 (2023-06) (hereinafter, “3GPP1”).
Regarding claim 2, Duan in view of Lutch discloses, the method of claim 1 as set forth above.
Although Duan in view of Lutch discloses, wherein the model update request comprises the model identifier . . . [see supra rejections as set forth above in claim 1], and the model update request requests the first network function to provide the ML model recommended on the basis of the model identifier . . . [FIG. 14; its related descriptions; see ¶0401-0408, note that since the AMF entity provides, to the UE, the second NAS message including the updated model (i.e., ML model) based on the first NAS message, the first NAS message requests the AMF entity to provide the updated model based on the model update request; further note that the model update request including the model identifier disclosed by Lutch], Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model update request comprises a recommendation indicator, and the model update request requests the first network function to provide the ML model recommended on the basis of the model identifier when the recommendation indicator has a value of true [see section 7.6.2, Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), Requested representative ratio, ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, Inference Input Data information, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested, ML Model Interoperability Information, Time when model is needed, ML Model Monitoring Information, ML Model Accuracy Monitoring Information (including e.g. Analytics Accuracy Threshold, DataSetTag and ADRF ID); note that the ML Model filter information and use case context functionally correspond to a recommendation indicator. The use case context indicates the context in which the analytics are to be used and may be used by the NWDAF containing MTLF to “select the most relevant ML model” when multiple ML models are available. The ML model filter information likewise enables the NWDAF to select which ML model is requested. Thus, the combination of the two parameters functions as an indication for requesting/triggering selection of the relevant ML model, corresponding functionality to the claimed recommended indicator for the ML model; further note that since the ML model filter and use case context each has to a field with a particular value to indicate the ones discussed above, the particular value is considered as a “true” under the broadest reasonable interpretation].
However, the above-mentioned is well known/established in the telecommunication art as recited in 3GPP standard, i.e., 3GPP1.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide well-established standard of providing the above-mentioned well-known feature, as taught by 3GPP1 in the system of Duan in view of Lutch, so that it would provide interoperability and compatibility between telecommunication equipment vendors and service providers, thereby providing users with easier and faster seamless transition regardless where the users are located in the country/world.
Regarding claim 3, Duan in view of Lutch discloses, the method of claim 1 as set forth above.
Although Duan discloses, wherein the model update response comprises . . . a file of the ML model or an address in which the file is stored [¶0392, the second NAS message includes the information on the second model file, and the information on the second model file may include the updated global model parameter, or the second model file including the updated global model parameter, or the address information of the second model file], Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model update response comprises at least one tuple, and each of the at least one tuple comprises the model identifier of the corresponding ML model and a file of the ML model corresponding to the model identifier or an address in which the file is stored [see section 6.2B.7 and FIG. 6.2B.7-1, The NWDAF containing MTLF notifies/response to the NWDAF service consumer with the tuple Analytics ID, one or more tuples of unique ML Model identifier and ML Model Information. The ML model information may contain the ML model file address (e.g. URL or FQDN) or ADRF (Set) ID].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 4, Duan in view of Lutch discloses, the method of claim 1 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the second network function comprises an ADRF [see section FIG. 6.2B.7-1, ADRF], and the obtaining the information for the model update comprises of the first network function transmitting a model management retrieve request to the ADRF [see section FIG. 6.2B.7-1, 6. the NWDAF service consumer (i.e., first network function) may invoke the Nadrf_MLModelManagement_Retrieve Subscribe/Request (Storage Transaction Identifier or one or more unique ML Model identifier(s)) service operation to get the ML model stored in ADRF] and receiving from the ADRF a model management retrieve response that is the basis for obtaining the information for the model update [see section FIG. 6.2B.7-1, 7. The ADRF sends Nadrf_MLModelManagement_Retrieve notify/ response (ML Model identifier(s) and address(es) of Model file(s) stored in ADRF to the NWDAF service consumer].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 5, Duan in view of Lutch and 3GPP1 discloses, the method of claim 4 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model management retrieve request essentially comprises at least one of . . . and the model identifier [see section 7.6.2, Nnwdaf_MLModelProvision_Subscribe (i.e., model provision request) service operation . . . Inputs, Required: (set of) Analytics ID(s) defined in Table 7.1-2; further see section 7.5.4, the tuple (Analytics ID, one or more tuples of unique ML Model identifier and ML Model Information as defined in clause 6.2A.2; further see section 6.2A.1], and the model identifier while optionally comprising a recommendation indicator [see section 7.6.2, Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), Requested representative ratio, ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, Inference Input Data information, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested, ML Model Interoperability Information, Time when model is needed, ML Model Monitoring Information, ML Model Accuracy Monitoring Information (including e.g. Analytics Accuracy Threshold, DataSetTag and ADRF ID); note that the ML Model filter information and use case context functionally correspond to a recommendation indicator. The use case context indicates the context in which the analytics are to be used and may be used by the NWDAF containing MTLF to “select the most relevant ML model” when multiple ML models are available. The ML model filter information likewise enables the NWDAF to select which ML model is requested. Thus, the combination of the two parameters functions as an indication for requesting/triggering selection of the relevant ML model, corresponding functionality to the claimed recommended indicator for the ML model], and
the model management retrieve request requests the ADRF to provide the ML model recommended on the basis of the model identifier when the recommendation indicator has a value of true [see section 7.6.2, Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), Requested representative ratio, ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, Inference Input Data information, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested, ML Model Interoperability Information, Time when model is needed, ML Model Monitoring Information, ML Model Accuracy Monitoring Information (including e.g. Analytics Accuracy Threshold, DataSetTag and ADRF ID); note that the ML Model filter information and use case context functionally correspond to a recommendation indicator. The use case context indicates the context in which the analytics are to be used and may be used by the NWDAF containing MTLF to “select the most relevant ML model” when multiple ML models are available. The ML model filter information likewise enables the NWDAF to select which ML model is requested. Thus, the combination of the two parameters functions as an indication for requesting/triggering selection of the relevant ML model, corresponding functionality to the claimed recommended indicator for the ML model; further note that since the ML model filter and use case context each has to a field with a particular value to indicate the ones discussed above, the particular value is considered as a “true” under the broadest reasonable interpretation].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 6, Duan in view of Lutch and 3GPP1 discloses, the method of claim 4 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model management retrieve request is a request based on a Nadrf_MLModelManagement_RetrievalRequest service operation [see section FIG. 6.2B.7-1, 6. the NWDAF service consumer (i.e., first network function) may invoke the Nadrf_MLModelManagement_Retrieve Subscribe/Request (Storage Transaction Identifier or one or more unique ML Model identifier(s)) service operation to get the ML model stored in ADRF].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 7, Duan in view of Lutch and 3GPP1 discloses, the method of claim 4 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model management retrieve response comprises at least one tuple, and
each of the at least one tuple comprises the model identifier of the corresponding ML model and an address in which a file of the ML model corresponding to the model identifier is stored [see section 10.3.4 along with section 6.2B.7, Nadrf_MLModelManagement_Retrieval Request service operation, Service operation name: Nadrf_MLModelManagement_Retrieval Nadrf_MLModelManagement_Retrieval Request. Description: The consumer NF uses this service operation to request the ADRF to get the ML model(s) stored in ADRF. Inputs, Required: - Storage Transaction Identifier; or - one or more tuples of unique ML Model identifier(s). . . . Outputs (i.e., model management retrieve response) Required: - one or more tuples of unique ML Model identifiers and address (e.g. URL or FQDN) of Model file stored in ADRF].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 8, Duan in view of Lutch and 3GPP1 discloses, the method of claim 4 as set forth above.
Although Duan discloses, wherein the model update information comprises the obtained file [FIG. 14; its related descriptions; ¶0408-0409, S816, sending, by the AMF entity, the second NAS message to the UE in response to the model update. The second NAS message (i.e., model update response) includes the information on the second model file], Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, the first network function obtaining a file of at least one ML model on the basis of the model management retrieve response [see section 10.3.4 along with section 6.2B.7, Nadrf_MLModelManagement_Retrieval Request service operation, Service operation name: Nadrf_MLModelManagement_Retrieval Nadrf_MLModelManagement_Retrieval Request. Description: The consumer NF uses this service operation to request the ADRF to get the ML model(s) stored in ADRF. Inputs, Required: - Storage Transaction Identifier; or - one or more tuples of unique ML Model identifier(s). . . . Outputs (i.e., model management retrieve response) Required: - one or more tuples of unique ML Model identifiers and address (e.g. URL or FQDN) of Model file stored in ADRF].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 2.
Regarding claim 10, Duan in view of Lutch discloses, the method of claim 9 as set forth above.
Although Duan in view of Lutch discloses, the model provision request requests the NWDAF to provide the ML model recommended on the basis of the model identifier [FIG. 14; its related descriptions; see ¶0403-0406, note that since the NWDAF entity provides, to the AMF entity, the model update completion notification including the updated model (i.e., ML model) based on the fifth model update request (i.e., model provision request), the fifth model update request requests the NWDAAF entity to provide the updated model based on the model update request; further note that the model update request including the model identifier disclosed by Lutch], Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model provision request essentially comprises at least one of an analytics identifier correlated with the model identifier and the model identifier [see section 7.6.2, Nnwdaf_MLModelProvision_Subscribe (i.e., model provision request) service operation . . . Inputs, Required: (set of) Analytics ID(s) defined in Table 7.1-2; further see section 7.5.4, the tuple (Analytics ID, one or more tuples of unique ML Model identifier and ML Model Information as defined in clause 6.2A.2; further see section 6.2A.1], and the model identifier while optionally comprising a recommendation indicator [see section 7.6.2, Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), Requested representative ratio, ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, Inference Input Data information, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested, ML Model Interoperability Information, Time when model is needed, ML Model Monitoring Information, ML Model Accuracy Monitoring Information (including e.g. Analytics Accuracy Threshold, DataSetTag and ADRF ID); note that the ML Model filter information and use case context functionally correspond to a recommendation indicator. The use case context indicates the context in which the analytics are to be used and may be used by the NWDAF containing MTLF to “select the most relevant ML model” when multiple ML models are available. The ML model filter information likewise enables the NWDAF to select which ML model is requested. Thus, the combination of the two parameters functions as an indication for requesting/triggering selection of the relevant ML model, corresponding functionality to the claimed recommended indicator for the ML model], and
the model provision request requests the NWDAF to provide the ML model recommended on the basis of the model identifier when the recommendation indicator has a value of ‘true’ [see section 7.6.2, Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), Requested representative ratio, ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, Inference Input Data information, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested, ML Model Interoperability Information, Time when model is needed, ML Model Monitoring Information, ML Model Accuracy Monitoring Information (including e.g. Analytics Accuracy Threshold, DataSetTag and ADRF ID); note that the ML Model filter information and use case context functionally correspond to a recommendation indicator. The use case context indicates the context in which the analytics are to be used and may be used by the NWDAF containing MTLF to “select the most relevant ML model” when multiple ML models are available. The ML model filter information likewise enables the NWDAF to select which ML model is requested. Thus, the combination of the two parameters functions as an indication for requesting/triggering selection of the relevant ML model, corresponding functionality to the claimed recommended indicator for the ML model; further note that since the ML model filter and use case context each has to a field with a particular value to indicate the ones discussed above, the particular value is considered as a “true” under the broadest reasonable interpretation].
However, the above-mentioned is well known/established in the telecommunication art as recited in 3GPP standard, i.e., 3GPP1.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide well-established standard of providing the above-mentioned well-known feature, as taught by 3GPP1 in the system of Duan in view of Lutch, so that it would provide interoperability and compatibility between telecommunication equipment vendors and service providers, thereby providing users with easier and faster seamless transition regardless where the users are located in the country/world.
Regarding claim 11, Duan in view of Lutch discloses, the method of claim 9 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model provision request is a request based on an Nnwdaf_MLModelProvision_Subscribe service operation [see section 6.2A.1 and FIG. 6.2A.1-1, Nnwdaf_MLModelProvision_Subscribe].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 10.
Regarding claim 12, Duan in view of Lutch discloses, the method of claim 9 as set forth above. Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model provision request is a request based on an Nnwdaf_MLModelInfo_Request service operation [see section 6.2A.3 and FIG. 6.2A.3-1, Nnwdaf_MLModelInfo_Request].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 10.
Regarding claim 13, Duan in view of Lutch discloses, the method of claim 9 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, the NWDAF transmitting a model management retrieve request to the ADRF [see section 6.2B.7 and FIG. 6.2B.7-1, 3. The ADRF service consumer (NWDAF containing MTLF) requests for the ML model stored in ADRF by invoking the Nadrf_MLModelManagement_Retrieve request (Storage Transaction Identifier or one or more unique ML model Identifier(s)) service operation] on the basis of the model provision request [see section 6.2B.7 and FIG. 6.2B.7-1, 1. The NWDAF service consumer (NWDAF containing AnLF or NWDAF containing MTLF) subscribes/requests for a (set of) trained ML Model(s) associated with a/an (set of) Analytics ID(s) by invoking the Nnwdaf_MLModelProvision_Subscribe / Nnwdaf_MLModelInfo_Request service (if consumer is NWDAF containing AnLF)] and receiving from the ADRF a model management retrieve response [see section 6.2B.7 and FIG. 6.2B.7-1, 4. The ADRF sends Nadrf_MLModelManagement_Retrieve response (address(es) e.g., URL or FQDN of Model
file(s) stored in ADRF) service operation] that is the basis for generating the model provision response [see section 6.2B.7 and FIG. 6.2B.7-1, 5, The NWDAF containing MTLF notifies/ response to the NWDAF service consumer with the tuple Analytics ID, one or more tuples of unique ML Model identifier and ML Model Information].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 10.
Regarding claim 15, Duan in view of Lutch and 3GPP1 discloses, the method of claim 13 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the ADRF generates the model management retrieve response by querying all ML models correlated with the analytics identifier when the model management retrieve request comprises the analytics identifier [see section 6.2B.7 and FIG. 6.2B.7-1, 3. The ADRF service consumer (NWDAF containing MTLF) requests for the ML model stored in ADRF by invoking the Nadrf_MLModelManagement_Retrieve request (Storage Transaction Identifier or one or more unique ML model Identifier(s)) service operation. 4. The ADRF sends Nadrf_MLModelManagement_Retrieve response (address(es) e.g., URL or FQDN of Model file(s) stored in ADRF) service operation].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 10.
Regarding claim 16, Duan in view of Lutch and 3GPP1 discloses, the method of claim 13 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but 3GPP1 discloses, wherein the model management retrieve response comprises at least one tuple, and each of the at least one tuple comprises the model identifier of the corresponding ML model and an address where a file of the ML model corresponding to the model identifier is stored [see section 10.3.4 along with section 6.2B.7, Nadrf_MLModelManagement_Retrieval Request service operation, Service operation name: Nadrf_MLModelManagement_Retrieval Nadrf_MLModelManagement_Retrieval Request. Description: The consumer NF uses this service operation to request the ADRF to get the ML model(s) stored in ADRF. Inputs, Required: - Storage Transaction Identifier; or - one or more tuples of unique ML Model identifier(s). . . . Outputs (i.e., model management retrieve response) Required: - one or more tuples of unique ML Model identifiers and address (e.g. URL or FQDN) of Model file stored in ADRF].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the above-mentioned feature(s) as taught by 3GPP1 in the system of Duan in view of Lutch for similar rationales set forth above in claim 10.
Regarding claim 20, claim 20 is rejected at least based on a similar rationale applied to claim 2.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Duan et al (US Publication No. 2024/0281719 A1) in view of Lutch et al (US Publication No. 2025/0350383 A1) and further in view of Butt et al (US Publication No. 2024/0385278 A1).
Regarding claim 19, Duan in view of Lutch discloses, the method of claim 18 as set forth above.
Duan in view of Lutch does not explicitly disclose (see, italicized limitations), but Butt discloses, wherein the determining step comprises determining that the model update is necessary when a performance of the ML model in operation is evaluated and the performance of the ML model does not satisfy a predetermined criterion [FIG. 3; its related descriptions; ¶0056, in response to the number of inferences made by the UE being greater than the threshold configured by the NG-RAN, the UE transmits a ML model identifier (e.g., a version number) to the location server. in response to the number of inferences made by the UE being greater than the threshold configured by the NG-RAN, the UE transmits a ML model identifier (e.g., a version number) to the location server].
It is noted that the above-mentioned feature is a known technique in the field Applicant's endeavor, e.g., telecommunication art.
It would have been obvious to one having ordinary skill in the art before the effective filing date to combine the system of Duan in view of Lutch with "the above-mentioned known feature(s)" taught by Butt to reach the claimed invention as set forth above. Since one having ordinary skill in the art could have recognized that applying the known technique taught by Butt into the system of Duan in view of Lutch would have yield predictable results and/or resulted in the improved system, such as e.g., enabling timely ML model updates to improve model performance, such a modification (or application) would have involved the mere application of a known technique to a piece of prior art ready for improvement," the claim is unpatentable under 35 U.S.C. 103(a). Ex Parte Smith, 83 USPQ.2d 1509, 1518-19 (BPAI, 2007) (citing KSR v. Teleflex, 127 S.Ct. 1727, 1740, 82 USPQ2d 1385, 1396 (2007)).
Allowable Subject Matter
Claim 14 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b), set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon are considered pertinent to applicant's disclosure.
Estevez et al (US Publication No. 2025/0392523 A1) [see abstract]
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUN JONG KIM whose telephone number is (571)270-3216. The examiner can normally be reached on 7:30am-5:30pm(M-T).
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, Ian Moore can be reached on (571) 272-3085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SUN JONG KIM/Primary Examiner, Art Unit 2469
