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 .
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 1-17 are rejected under 35 U.S.C. 103 as being unpatentable over Mwanje et al. (US 2023/0325713 A1), hereinafter “MWANJE” in view of Mwanje (US 2024/0129203 A1), hereinafter “MWANJE203” in view of Chou (US 2023/0129575 A1), hereinafter “CHOU”.
Regarding claim 1, MWANJE teaches, ‘An apparatus of a Service Based Management Architecture (SBMA) Management Service (MnS) Producer, the apparatus comprising processing circuitry coupled to storage for storing information associated with deploying machine learning (ML) models, the processing circuitry configured to:’ (Paragraph [0050]: In various example embodiments, a ML-Model training function (i.e., MLTraining) and the related services may support management and control of the training process and the related requests associated with a specific ML Model (i.e., MLModel)… In general, the MLTraining may be modelled as a managed function that is contained in either any network-related ManagedFunction, ManagementFunction or subnetwork (target inference function). The MLTraining may contain or be associated with critical subfunctions and modules needed to accomplish MLTraining, including a list of MLTraining requests, a list of MLModels either under training or to be considered for training, and a list of MLTrainingJobs: Paragraph [0068]: As an example, the MLTraining may implement an MLTraining Management Service (MLTraining MnS) that provides capabilities for requesting training and for reporting on the training (MLTraining: Service Based Management Architecture (SBMA) framework and the Management Service (MnS) Producer role); Paragraph [0104]: NE 2410 and/or UE 2420 may include at least one processor, respectively indicated as 2411 and 2421. Processors 2411 and 2421 may be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device; Paragraph [0106]: At least one memory may be provided in one or more of the devices, as indicated at 2412 and 2422… Memories 2412 and 2422 may independently be any suitable storage device, such as a non-transitory computer-readable medium; Paragraph [0109]: The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus, such as UE, to perform any of the processes described above):
‘instantiate an ML model loading process to load the ML model to the target inference function, the ML model loading process comprising a progress status attribute indicative of a progress of loading the ML model to the target inference function;’ (Paragraph [0053]: In various example embodiments, the IOC of the MLTrainingJob may represent the properties of MLTrainingJob. For each MLModel under training, a MLTrainingJob may be instantiated (i.e., the MLTrainingJob associated with exactly one MLModel); Paragraph [0055]: In certain example embodiments, the MLTrainingJob IOC may include attributes inherited from TOP IOC (such as those defined in 3GPP TS 28.622), and/or the following attributes:… ProgressStatus |M|T|T|F|T (Note: MWANJE provides the primary framework of a Service Based Management Architecture (SBMA) MnS Producer running an ML lifecycle management process (MLTrainingJob) containing a ProgressStatus attribute));
MWANJE does not explicitly teach but MWANJE203 teaches, ‘identify an ML model loading policy defining an ML model and a target inference function to which the ML model is to be loaded;’ MWANJE203 – Paragraph [0097]: The consumer may request the network function that has AI/ML Capability to update its AI/ML Capability, in the specific case of performance constrained update specifying the performance improvement that should justify the update; Paragraph [0143]: Requests for updating ML Capability of network functions may be received using MLCapabilityUpdate Provisioning Management service implemented via CRUD (Create, Read, Update, Delete) operations on the MLCapabilityUpdateRequest objects; Paragraph [0146]: The request for Updating ML Capability may indicate a performanceGainThreshold as the minimum performance gain of the network service influenced by the AI/ML that should be achieved with the said capability update; Paragraph [0177]: E.g., the AI/MLEntitys associated with MLCapabilityUpdate may be associated via a list of AI/MLEntityidentifers. The AI/MLEntityidentifers should specify the model and any specific version thereof… The AI/MLEntityidentifer may indicate the organization that created the AI/MLEntity, the intended conditions for using the AI/MLEntity (Note: MWANJE203 teaches defining specific policy constrains (performanceGainThreshold, expectedRuntimeContext) and identifying target AI/ML entities/functions (AI/MLEntity / AI/ML-enabled function) for model deployment)),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of MWANJE203 with MWANJE because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of MWANJE203 into MWANJE is that MWANJE203 provides a policy-driven update requests (MLCapabilityUpdateRequest) that specify target entities (AI/MLEntity), target runtime contexts (expectedRuntimeContext), and minimum performance thresholds (performanceGainThreshold). This ensures that model deployment/loading processes are only executed when target inference functions meet predefined performance thresholds, thereby preventing unnecessary computational overhead and avoiding performance degradation in live network nodes (See paragraph [0097], [0143], [0146], [0177] MWANJE203).
MWANJE and MWANJE203 do not explicitly teach but CHOU teaches, ‘and create a Managed Object Instance (MOI) of the ML model under an MOI of the target inference function based on completion of the loading of the ML model to the target inference function.’ (CHOU – Paragraph [0063]: Therefore, NSSI (network slice subnet instance) resource optimization function that is realized as an rAPP in a non real time RAN Intelligent Controller (Non-RT RIC) that trains the artificial intelligence (AI)/machine learning (ML) model, based on the huge volume of performance data collected over days, weeks, months from O-RAN nodes. It then uses the AI/ML model to predict the traffic demand patterns; Paragraph [0068]: NSSI resource optimization function trains to the AI/ML model, based on the huge volume of performance data… It then performs inference function on the model with input measurements; Paragraph [0067]: The goal of this use case is to ensure the resources are allocated dynamically and efficiently among multiple NSSI sharing the RAN node. Paragraphs [0072]-[0073]: d) Configure the NSSI resources at the E2 node via O1 interface. e) Receives notifications from E2 nodes indicating the resource re-configuration was done.; Paragraph [0076]: TABLE 3.6.3-1: Step 2 (M): The rApp performs the inference function on the model with input measurements data received to determine if any actions should be executed to update the NSSI resources on the E2 nodes (E2 nodes (O-CU-CP, O-CU-UP, O-DU): target inference function)… 3b: Non-RT RIC Framework uses the modify MOI (Managed Object Instance) operation to configure the MOI(s) associated with the RRC related resources at O-CU-CP via O1 interface… 4b: Non-RT RIC Framework uses the modify MOI operation to configure the MOI(s) associated with the DRB related resource at O-CU-UP via O1 interface… 4c: Non-RT RIC Framework receives a notification from O-CU-UP via O1 interface indicating the resource re-configuration was successful (completion of the loading of the ML model to the target inference function); 5b: Non-RT RIC Framework uses the modify MOI operation to configure the MOI(s) associated with the PRB related resource at O-DU via O1 interface; Paragraph [0114]: At operation 606, an NSSI resource allocation associated with the E2 node may be determined by performing the inference function of the NSSI optimization model. (Note: CHOU teaches creating/modifying Managed Object Instances (MOIs) on target network/inference nodes (O-CU-CP, O-CU-UP, O-DU) upon process completion. MWANJE teaches that the machine learning management and model objects (MLTraining, MLTrainingJob, MLModel) are name-contained by parent Information Object Classes (IOCs) representing a ManagedFunction, Management Function, or Subnetwork. This establishes the structural parent-child tree where the child Managed Object Instance (MOI) representing the ML mode/job is created and positioned directly under the parent MOI representing the target inference function (ManagedFunction). CHOU teaches the event-driven provisioning trigger (create MOI / modify MOI) executed specifically upon receiving a completion notification confirming that model loading succeeded)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of CHOU with MWANJE and MWANJE203 because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of CHOU into MWANJE and MWANJE203 is that CHOU provides a specific 3GPP/O-RAN management mechanism by teaching the use of modify MOI and create MOI operations via the O1 interface to configure/instantiate MOIs directly under target network elements and inference functions (such as O-CU-CP, O-CU-UP and O-DU) upon receiving notification of successful completion. This allows the management producer, upon completing the ML model loading process to automatically instantiate the loaded ML model’s MOI under the specific target inference function’s MOI tree, ensuring seamless object containment, visibility, and control across 3GPP and O-RAN management planes (See paragraph [0067], [0076], [0072]-[0073], [0076], CHOU).
Regarding claims 2, 8 and 14, MWANJE, MWANJE203 and CHOU teach, The apparatus of claim 1, MWANJE does not explicitly teach but MWANJE203 teaches, ‘wherein the ML model loading policy further defines a second target inference function to which the ML model is to be loaded.’ (MWANJE203 – Paragraph [0177]: The AI/MLEntityidentifers should specify the model and any specific version thereof… The AI/MLEntityidentifer may indicate the organization that created the AI/MLEntity; Paragraphs [0208]-[0211]: These models must reflect the specific contexts of the different phases: 1. To manage the NAF as part of a network (runtime context) 2. The relationship of the NAF as a management system with respect to other network functions (runtime context) 3. To document the (network) context during training (training context) of the NAF and to document the required network context that is expected by the NAF for correct inference (expected runtime context); Paragraph [0213]: Each context is associated to ManagedEntities (NetworkSlice, NetworkSliceSubnets, NetworkFunctions) to model the configuration of the network and to characterize the data provided by the Managed Entities; Paragraph [0233]: TABLE 8: AI/MLEntitysList: It indicates the list of ML Entities available at the MLCapability Update function (AI/MLEntitysList: second target inference function); expectedRuntimeContext: It describes the conditions and characteristics of the environment where the AI/MLEntity or AI/MLEntity is expected to be used for inference).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of MWANJE203 with MWANJE because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of MWANJE203 into MWANJE is that MWANJE203 provides a policy-driven update requests (MLCapabilityUpdateRequest) that specify target entities (AI/MLEntity), target runtime contexts (expectedRuntimeContext), and minimum performance thresholds (performanceGainThreshold). This ensures that model deployment/loading processes are only executed when target inference functions meet predefined performance thresholds, thereby preventing unnecessary computational overhead and avoiding performance degradation in live network nodes (See paragraph [0097], [0143], [0146], [0177] MWANJE203).
Regarding claims 3, 9 and 15, MWANJE, MWANJE203 and CHOU teach, The apparatus of claim 2, MWANJE and MWANJE203 do not explicitly teach but CHOU teaches, ‘wherein the processing circuitry is further configured to create a second MOI of the ML model under an MOI of the second target inference function based on completion of the loading of the ML model to the second target inference function.’ (CHOU – Paragraph [0076]: TABLE 3.6.3-1: 3b: Non-RT RIC Framework uses the modify MOI (Managed Object Instance) operation to configure the MOI(s) associated with the RRC related resources at O-CU-CP via O1 interface. 3c: Non-RT RIC Framework receives a notification from O-CU-CP via O1 interface indicating the resource re-configuration was successful. 4b: Non-RT RIC Framework uses the modify MOI operation to configure the MOI(s) associated with the DRB related resource at O-CU-UP via O1 interface. 4d: Non-RT RIC Framework notifies rApp via R1 interface indicating the NSSI resources in O-CU-UP have been successfully updated. 5b: Non-RT RIC Framework uses the modify MOI operation to configure the MOI(s) associated with the PRB related resource at
O-DU via O1 interface. 5c: Non-RT RIC Framework receives a notification from O-DU via O1 interface indicating the resource re-configuration was successful (Note: CHOU teaches that when resources/models are deployed or updated across multiple target network/inference functions (such as O-CU-CP, O-CU-UP and O-DU), the management framework issues operations (create MOI / modify MOI) via the O1 interface to instantiate/configure a corresponding Managed Object Instance (MOI) for each respective target node upon receiving notification that the configuration /loading was successful)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of CHOU with MWANJE and MWANJE203 because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of CHOU into MWANJE and MWANJE203 is that CHOU provides a specific 3GPP/O-RAN management mechanism by teaching the use of modify MOI and create MOI operations via the O1 interface to configure/instantiate MOIs directly under target network elements and inference functions (such as O-CU-CP, O-CU-UP and O-DU) upon receiving notification of successful completion. This allows the management producer, upon completing the ML model loading process to automatically instantiate the loaded ML model’s MOI under the specific target inference function’s MOI tree, ensuring seamless object containment, visibility, and control across 3GPP and O-RAN management planes (See paragraph [0067], [0076], [0072]-[0073], [0076], CHOU).
Regarding claims 4, 10 and 16, MWANJE, MWANJE203 and CHOU teach, The apparatus of claim 1, MWANJE further teaches, ‘wherein to instantiate the ML model loading process is in response a received ML model loading request from an MnS Consumer, and wherein the ML model loading request defines the ML model to be loaded.’ (Paragraph [0056]: In various example embodiments, the IOC may
represent the properties of MLTrainingRequest. For example, for each request to undertake training, a consumer may create a new MLTrainingRequest on the MLTraining (MnS Consumer) (i.e., MLTrainingRequest may be an IOC that is instantiated for each request for training). For example, each MLTrainingRequest may be associated with exactly one MLModel associated to the MLTraining to which the MLTrainingRequest is sent; Paragraph [0064]: In certain example embodiments, the MLTraining may instantiate an MLTrainingJob based on at least one MLTrainingRequest from consumers who may be management functions or human operators. For example, the MLTraining may instantiate an ML MLTrainingJob for each received instruction, as illustrated in FIG. 4. For example, requests for training may be received via MLTraining Provisioning Management service implemented via CRUD (Create, Read, Update, Delete) operations on the MLTrainingJob or the MLTrainingRequest objects; Paragraph [0073]: In various example embodiments, the MLTrainingRequest IOC may represent the properties of MLTrainingRequest. For each request to undertake training, a consumer may create a new MLTrainingRequest on the MLTraining… Each MLTrainingRequest may be associated to exactly one MLModel that is associated to the MLTraining to which the MLTrainingRequest is sent. The particular model may be specified using the MLModelldentifier (ML model to be loaded), an appropriate identifier of the ML model, and/or a version thereof (Note: MWANJE teaches receiving an request object (MLTrainingRequest) sent from a consumer (MnS Consumer), wherein the request defines the specific ML model to be processed using its unique model identifier (MLModelIdentifier), and wherein the producer instantiates a corresponding process (MLTrainingJob) directly in response to receiving the request)).
Regarding claims 5 and 11, MWANJE, MWANJE203 and CHOU teach, The apparatus of claim 1, MWANJE does not explicitly teach but MWANJE203 teaches, ‘wherein to instantiate the ML model loading process occurs based on the ML model loading policy without an ML model loading request from an MnS Consumer.’ (MWANJE203 – Paragraphs [0158]-[0159]: In sections 1.1 and 1.2, the AI/ML capabilities are assumed not to be available and the request for update triggers the MLCapabilityUpdate function to find the appropriate capabilities. It is possible however, that the new capabilities are made available previously, e.g. as learned through a reinforcement learning process. Thereby, the request for update may follow an indication that there are available capabilities, in which case, the sequence of actions changes as shown in FIG. 4… Subsequently, the application of the new capabilities does not require a check for specific improvement in performance (Note: In FIG. 4, block 0 states “Obtain new versions of capability” directly triggering step 2a “createMOI (MLCapabilityUpdateJob…) without requiring an incoming request from the consumer); Paragraph [0134]: Depending on their configurations, AI/ML-enabled functions may learn new characteristics even during their utilization, e.g., if they are configured to learn through reinforcement learning or if they are configured to download new versions of their AI/ML Entities. This knowledge may be available to use but the AI/ML-enabled function may not be configured to apply this knowledge by default but to only apply it when explicitly triggered (Note: MWANJE203 teaches that an update/deployment job (MLCapabilityUpdateJob) can be instantiated directly by the producer based on a policy or internal capability/performance triggers (such as autonomous reinforcement learning, internally detected network state changes, or new model version availability) without receiving an explicit request (MLCapabilityUpdateRequest) from an MnS consumer)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of MWANJE203 with MWANJE because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of MWANJE203 into MWANJE is that MWANJE203 provides a policy-driven update requests (MLCapabilityUpdateRequest) that specify target entities (AI/MLEntity), target runtime contexts (expectedRuntimeContext), and minimum performance thresholds (performanceGainThreshold). This ensures that model deployment/loading processes are only executed when target inference functions meet predefined performance thresholds, thereby preventing unnecessary computational overhead and avoiding performance degradation in live network nodes (See paragraph [0097], [0143], [0146], [0177] MWANJE203).
Regarding claims 6, 12 and 17, MWANJE, MWANJE203 and CHOU teach, The apparatus of claim 1, MWANJE does not explicitly teach but MWANJE203 teaches, ‘wherein the ML model loading policy further defines a condition for training the ML model.’ (MWANJE203 – Paragraph [0094]: In particular, the consumer of AI/ML services exposed by the AI/ML-enabled function ("consumer") may wish to define the update-trigger conditions under which the AI/ML Capability may be updated. The update-trigger conditions refer to network-related, use case-related or operations- related constraints and metrics which must be fulfilled before the update is triggered; Paragraph [0153]: The MLCapabilityUpdate may trigger retraining and testing for one or more, the retraining undertaken locally or on a separate network function; Paragraph [0137]: it may trigger one or more remote or local AI/ML-related processes (including training, testing, etc.) needed to generate the required updates (Note: MWANJE203 teaches that policy objects (MLCapabilityUpdateRequest / MLCapbilityUpdateJob) specify trigger conditions (such as performance gain thresholds or operational metrics) that dictate whether remote or local ML model training/retraining must be initiated prior to or as part of updating and deploying the model)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have known to combine the teachings of MWANJE203 with MWANJE because both are in the same/similar field of endeavor. The advantage of incorporating the above limitation(s) of MWANJE203 into MWANJE is that MWANJE203 provides a policy-driven update requests (MLCapabilityUpdateRequest) that specify target entities (AI/MLEntity), target runtime contexts (expectedRuntimeContext), and minimum performance thresholds (performanceGainThreshold). This ensures that model deployment/loading processes are only executed when target inference functions meet predefined performance thresholds, thereby preventing unnecessary computational overhead and avoiding performance degradation in live network nodes (See paragraph [0097], [0143], [0146], [0177] MWANJE203).
Regarding claims 7 and 13, the claims include features identical to the subject matter mentioned in the rejection to claim 1. The claims are mere reformulation of claim 1 in order to define the corresponding computer-readable medium (MWANJE ¶[0106], [0109]) and network node (MWANJE ¶[0104], [0106], [0109]), and the rejection to claim 1 is applied hereto.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAESHIL J CHOI whose telephone number is (703)756-5409. The examiner can normally be reached Monday thru Friday 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, Jae Y Lee can be reached on 571-270-3936. 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.
/HAESHIL JESSICA CHOI/Examiner, Art Unit 2479 /JAE Y LEE/Supervisory Patent Examiner, Art Unit 2479
Prosecution Insights