Prosecution Insights
Last updated: October 02, 2026
Application No. 17/218,035

TRAINING AND SCORING FOR LARGE NUMBER OF PERFORMANCE MODELS

Non-Final OA §103§112
Filed
Mar 30, 2021
Examiner
NGUYEN, HENRY K
Art Unit
2121
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
5 (Non-Final)
59%
Grant Probability
Moderate
5-6
OA Rounds
0m
Est. Remaining
86%
With Interview

Examiner Intelligence

Grants 59% of resolved cases
59%
Career Allowance Rate
99 granted / 167 resolved
+4.3% vs TC avg
Strong +26% interview lift
Without
With
+26.5%
Interview Lift
resolved cases with interview
Typical timeline
4y 6m
Avg Prosecution
17 currently pending
Career history
189
Total Applications
across all art units

Statute-Specific Performance

§101
21.1%
-18.9% vs TC avg
§103
53.6%
+13.6% vs TC avg
§102
7.8%
-32.2% vs TC avg
§112
12.8%
-27.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 167 resolved cases

Office Action

§103 §112
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 . In view of the appeal brief filed on 04/17/2026, PROSECUTION IS HEREBY REOPENED. A new grounds of rejection is set forth below. To avoid abandonment of the application, appellant must exercise one of the following two options: (1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or, (2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid. A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below: /Li B. Zhen/ Supervisory Patent Examiner, Art Unit 2121 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 1-4, 6-11, 13-18, and 20 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. Claim 1 recites “storing a group of the performance models in a computing pod” and “determining a computing pod that has a smallest change in resource usage among a plurality of computing pods containing performance models in the group”. It is unclear if the performance models are stored in a single computing pod or each model is stored in a corresponding pod. For examination purposes, Examiner interprets the claim as the latter. Claims 8 and 15 are substantially similar to claim 1 and are rejected for the same reasons. Claims 2-4, 6-7, 9-11, 13-14, 16-18, and 20 are dependent claims that do not cure the deficiencies and are rejected for the same reasons. 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. Claim(s) 1-2, 8-9, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Slinger et al. (US-20210383271-A1) in view of Cao et al. (US-20210357256-A1), Zheng et al. ("Efficient resource management for deep learning applications with virtual containers"), and El Haj Ahmed et al. (“KubCG: A dynamic Kubernetes scheduler for heterogeneous clusters.”). Regarding Claim 1, Slinger teaches a computer-implemented method of training a monitoring system for detection of anomalies in computing operations comprising: receiving details regarding a plurality of performance models to be used in detecting the anomalies including a number of the performance models (para [0026] “Then, a real time system performance may be tracked, and subsets of the set of models may be dynamically selected and combined to provide collective, optimal anomaly predictions that are highly specific and tailored to existing conditions.”), types of the performance models (para [0069] Types of predictions (i.e. model type).), and metrics used for each of the performance models (para [0027] “System performance in a technology landscape, such as within a computer or mainframe system, may be tracked and measured using performance metrics. For example, some performance metrics may include performance metrics commonly referred to as key performance indicators, or KPIs. For example, KPIs may include a percentage of central processing unit (CPU) resources in use at a given time, an amount of memory in use, and data transfer rates between system components.”); storing a group of the performance models (para [0033] “In FIG. 1, a plurality of predictive models may be stored in a model store 108.”) wherein the group is a subset of the performance models that contains fewer than a total number of the performance models (para [0065] “Then, the model selector 135 may select a subset of performance prediction models, based at least on the performance metrics 106. For example, as referenced above, the model selector 135 may utilize the model control file 128 to select a current subset of performance prediction models.”); performing an initial training of the performance models in the group (para [0064] “From a plurality of performance prediction models and based on the performance metrics, a subset of performance prediction models may be selected (204). For example, the training interface 132 may define and train the plurality of models in the model store 108, based on the training data 112. Each performance prediction model may be trained using a single performance metric, or, as just referenced, using a group of performance metrics (e.g., KPIs).”); Slinger does not explicitly disclose storing a group of the performance models in a computing pod determining a computing pod that has a smallest change in resource usage among a plurality of computing containing performance models in the group, over a first period of time before the initial training compared to a second period of time after the initial training; performing further training of a particular one of the performance models in the group, the particular one of the performance models being stored in the determined computing pod; and applying said further training to remaining performance models in the group. However, Cao (US 20210357256 A1) teaches storing a group of the performance models in a computing pod… (para [0021] and para [0025].) Slinger and Cao are analogous because they are both directed to the same field of endeavor of training a machine learning model. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the training of Sling with the resource optimization of Cao. Doing so would allow for optimizing resource allocation in accordance with a criteria and a degree of optimization depending on the users needs/desires (Cao para [0015]). Zheng (Efficient Resource Management for Deep Learning Applications with Virtual Containers) teaches performing an initial training of the performance models in the group (pg. 2; “Many cloud computing service providers such as Microsoft and AWS provide a large scale of sharing computing resources, and users are able to create traditional virtual machines or/and virtual containers and run deep learning training jobs inside the virtual machines. In the cloud environment, various jobs are able to run concurrently and compete for computing resources like CPUs and Memories.”); determining a computing pod that has a change in resource usage among a plurality of computing containing performance models in the group (pg. 3; “After a rapid decline phase, the loss will converge to a relatively stable number and the efficiency of the training process decreased. It turns out that although the resource usage stays the same for each unit of the training process, the gain varies over time. While the computing resources usage remains the same, the reduction of loss is very slow after the training converged, and this is a waste of computing resources.”), over a first period of time before the initial training compared to a second period of time after the initial training (pg. 18, section 4.1.3; “Given a system with a set of running containers, {cid}, each container uses its own evaluation function to assess its machine learning model (e.g., loss reduction and inception score) Ecid (t). For each model, based on its E(t), we define the progress score for the container cid below, where ti − ti−1 is the measurement interval, the value Pcid (ti) is called per-second progress within the interval. Pcid (ti) = |Ecid (ti) − Ecid (ti−1)| ti − ti−1 (4.1) Here, Pcid (ti) reflects the model training progress over a given time interval. In order to account for the resources used towards the progress, we propose the growth efficiency for each container cid with an active deep learning job. Gcid,ri (ti) in Eq. 4.2 represents growth efficiency with respect to different types of resources (e.g., CPU, memory, network I/O and block I/O), denoted by ri . The denominator Rcid,ri (ti), is a function that returns average resource ri usage of cid within interval [ti − ti−1]. Gcid,ri (ti) = Pcid (ti) Rcid,ri (ti) (4.2) FlowCon aims to maximize the sum of growth efficiency for the whole system in each interval, where each learning model has its own evaluation function and can be calculated in real-time.” A change in resource usage is determined for multiple time intervals (including a time period for initial training) and determining which container (i.e., pod) has the smallest resource change. “pg. 27, table 5.1; “ PNG media_image1.png 135 647 media_image1.png Greyscale ” Container (i.e., pod). pg. 30; “At time tm, it reads the current value of the evaluation function and calculates the gain during the previous categorization interval, tm − tm−1 (Line 3-5). If the gain is less than the previous round and the threshold α, SpeCon updates the category of this container based on the following condition (Line 6-16).” Pg. 34; “Then, the algorithm finds the cj with the smallest dcj and, in the meanwhile, cj runs on a worker wj such that wj ∈/ T (Line 23-25). It basically avoids the scenario that cj assigns to its current host.”); performing further training of a particular one of the performance models in the group, the particular one of the performance models being stored in the determined computing pod (pg. 13; “The experiments are conducted under Tensorflow[52] and Pytorch[53], where the training jobs are running inside a Kubernetes container. Fig. 3.2 shows the experiments of training a VAE model, where we save the model at a given percentage according to the total number of iterations and resume it immediately after saving completes.”); and applying said further training to remaining performance models in the group (pg. 28, section 5.2.1; “In our problem setting, training jobs are running inside containers, where each container hosts one specific job. Consequently, each container, ci , can be seen as one particular training job in our setting. As analyzed in the previous sections, each job has a predefined evaluation function. During the whole training process, the value of the function forms a time series. When queried in the middle of an iteration, the previous value will be returned. Based on the query time, Equation 5.1 presents the growth of the training job in a given interval, t2 − t1.”). Slinger and Zheng are analogous because they are directed towards training machine learning models in containers. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the training of Slinger with the resource utilization of Zheng. Doing so would improve the efficiency of multiple deep learning training applications running on the containerized cloud environment and accelerate the overall makespan for the system by real-time resource allocation on a single machine (Zheng pg. 3). El Haj Ahmed (“KubCG: A dynamic Kubernetes scheduler for heterogeneous clusters”) teaches determining a computing pod that has a smallest change in resource usage among a plurality of computing containing performance models in the group (pg. 224; algorithm 3.), It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning model of Slinger with the method of selecting a pod for completing a task. Doing so would allow for selecting a pod to complete a task within the shortest duration of time (El Haj Ahmed pg. 224;). Regarding Claim 2, Slinger, Cao, Zheng, and El Haj Ahmed teach the computer-implemented method of claim 1. Slinger further teaches wherein the performance models in the group are trained using machine learning (para [0026] “Described techniques use artificial intelligence or machine learning to process existing training data and construct a set of predictive models.”). Regarding Claim 8, Claim 8 is the system corresponding the method of claim 1. Claim 8 is substantially similar to claim 1 and is rejected on the same grounds. Regarding Claim 9, Claim 9 is the system corresponding the method of claim 2. Claim 9 is substantially similar to claim 2 and is rejected on the same grounds. Regarding Claim 15, Claim 15 is the computer program product corresponding the method of claim 1. Claim 15 is substantially similar to claim 1 and is rejected on the same grounds. Regarding Claim 16, Claim 16 is the computer program product corresponding the method of claim 2. Claim 16 is substantially similar to claim 2 and is rejected on the same grounds. Claim(s) 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Slinger/Cao/Zheng/El Haj Ahmed , as applied above, and further in view of Plumbey et al. (US-20210117869-A1). Regarding Claim 3, Slinger, Cao, Zheng, and El Haj Ahmed teach the computer-implemented method of claim 1. Slinger, Cao, Zheng, and El Haj Ahmed do not explicitly disclose wherein each of the performance models in the group has the same model type. However, Plumbley (US 20210117869 A1) teaches wherein each of the performance models in the group has the same model type (para [0092] “The models in each group may be of the same model type but may differ based on the selection of hyperparameters used to configure each model and/or based on the labelled dataset used to train that model.”). Slinger, Cao, Zheng, El Haj Ahmed , and Plumbey are analogous because they are both directed to the same field of endeavor of training a machine learning model. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning model of Slinger, Cao, Zheng, and El Haj Ahmed with the training of Plumbey. Doing so would allow for improving the selection of ML techniques and making improved models that are more accurate and can make full use of the available datasets (Plumbey para [0007]). Regarding Claim 10, Claim 10 is the system corresponding the method of claim 3. Claim 10 is substantially similar to claim 3 and is rejected on the same grounds. Regarding Claim 17, Claim 17 is the computer program product corresponding the method of claim 3. Claim 17 is substantially similar to claim 3 and is rejected on the same grounds. Claim(s) 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Slinger/Cao/Zheng/El Haj Ahmed , as applied above, and further in view of Mahadik et al. (US-20220092480-A1). Regarding Claim 4, Slinger, Cao, Zheng, and El Haj Ahmed teach the computer-implemented method of claim 1. Slinger, Cao, Zheng, and El Haj Ahmed do not explicitly disclose wherein: at least some of the performance models in the group are embodied in respective computing containers in a particular one of the plurality of computing pods which provide shared storage, shared network resources and a shared context for all containers within a given computing pod; the particular computing pod contains a training service that carries out said training. However, Mahadik (US 20220092480 A1) teaches at least some of the performance models in the group are embodied in respective computing containers (para [0031] “Indeed, the serverless management system can support continuous training loops of the machine-learning model by utilizing the shared storage to persist the machine learning model parameters of intermediary training iterations across multiple serverless execution containers.”) in the particular one of a plurality of computing pods (para [0021] “As noted above, in several implementations, the serverless management system improves accuracy and efficiency of computing devices by intelligently selecting the number of provisioned serverless execution containers in a serverless execution container pool (or simply “container pool”) based on arrival patterns of incoming data, computing costs, and computing latency. And para [0053] In various implementations, the cloud computing device 112 includes one or more pools of warmed serverless execution containers (e.g., the serverless execution containers 114 form a container pool).” Pool (i.e. pod).) which provide shared storage (para [0031] “Indeed, the serverless management system can support continuous training loops of the machine-learning model by utilizing the shared storage to persist the machine learning model parameters of intermediary training iterations across multiple serverless execution containers.”), shared network resources and (para [0177] “In some implementations, the act 1010 can involve communicating with a cloud computing device and/or a cloud computing system to allocate a pool of serverless execution containers that includes the first number of serverless execution containers.” Cloud (i.e. shared network resource).) a shared context for all containers within a given computing pod (para [0151] “Then, the serverless management system 106 can provide, or the serverless execution container 700 can access more recent machine-learning model parameters 706 (or simply “model parameters 706”) from the shared storage 702.” Parameters (i.e., shared context).); the particular computing pod contains a training service that carries out said training para [0018] “For instance, in various implementations, the serverless computing management system (or simply “serverless management system”) utilizes an online learning model that intelligently selects a number of provisioned (e.g., warmed) serverless execution containers to utilize within a serverless execution container pool for continuously training online machine-learning models.”). Slinger, Cao, Zheng, El Haj Ahmed , and Mahadik are analogous because they are both directed to the same field of endeavor of training a machine learning model in containers. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning model of Slinger, Cao, and Zheng with the containers of Mahadik. Doing so improves accuracy and efficiency of computing devices by intelligently selecting the number of provisioned serverless execution containers in a serverless execution container pool (or simply “container pool”) based on arrival patterns of incoming data, computing costs, and computing latency (Mahadik para [0018]). Regarding Claim 11, Claim 11 is the system corresponding the method of claim 4. Claim 11 is substantially similar to claim 4 and is rejected on the same grounds. Regarding Claim 18, Claim 18 is the computer program product corresponding the method of claim 4. Claim 18 is substantially similar to claim 4 and is rejected on the same grounds. Claim(s) 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Slinger/Cao/Zheng/El Haj Ahmed /Mahadik, as applied above, and further in view of Swan et al. (US-20200311617-A1) and Luciano et al. (US-11307885-B1). Regarding Claim 6, Slinger, Cao, Zheng, El Haj Ahmed , and Mahadik teach the computer-implemented method of claim 4. Slinger, Cao, Zheng, El Haj Ahmed , and Mahadik do not explicitly disclose further comprising: beginning initial scoring of trained performance models in certain computing pods; monitoring resource usages of the certain computing pods during the initial scoring; selecting a specific computing pod other than the particular computing pod for continued scoring based on the resource usages; and completing scoring of at least one performance model using a scoring service contained in the specific computing pod. However, Swan (US 20200311617 A1) teaches beginning initial scoring of trained performance models in certain computing pods (fig. 1; para [0053] “In some embodiments, the model hosting system 140 uses one or more container images included in a deployment request (or a container image retrieved from the container data store 170 in response to a received deployment request) to create and initialize a ML scoring container 150 in a virtual machine instance 142.” The VM instance (i.e., pod) contains one or more ML scoring containers. Para [0051] “The code 156 can also include model data that represent characteristics of the defined machine learning model, as described in greater detail below. The OS 152 and/or runtime 154 are configured to execute the code 156 in response to an instruction to begin execution of a machine learning model.” The ML scoring container stores a ML model (i.e., performance model). Para [0094] “The virtual machine instance 142 can further store the model data in the ML scoring container (e.g., in a location that is the same as the location in which the model data is stored in an ML training container 130 when a machine learning model is trained) at (7).”); monitoring resource usages of the certain computing pods during the initial scoring (para [0050] “The ML scoring containers 150 are similar to the ML training containers 130 in that the ML scoring containers 150 are logical units created within a virtual machine instance using the resources available on that instance, and can be utilized to isolate execution of a task from other processes (e.g., task executions) occurring in the instance.”); selecting a specific computing pod other than the particular computing pod for continued scoring (para [0062] Second container (i.e., specific computing pod). Other than the particular computing pod.). completing scoring of at least one performance model using a scoring service contained in the specific computing pod (para [0062] “The virtual machine instance 142 that initialized the second ML scoring container 150 can then transmit the second output to the model prediction data store 180 and/or the user device 102 via the frontend 149 (e.g., if no more trained machine learning models are needed to generate an output) or transmit the second output to a third ML scoring container 150 initialized in the same or different virtual machine instance 142 (e.g., if outputs from one or more additional trained machine learning models are needed), and the above-referenced process can be repeated with respect to the third ML scoring container 150.” Second container (i.e., specific computing pod).). Slinger, Cao, Zheng, El Haj Ahmed , Mahadik, and Swan are analogous because they are both directed to the same field of endeavor of training a machine learning model in containers. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning model of Slinger, Cao, Zheng, El Haj Ahmed , and Mahadik with the ML containers of Swan. Doing so would allow for periodically evaluating models during the training process based on metrics to ensure the accuracy of the model (Swan para [0021]). Swan does not explicitly disclose selecting a pod based on resource usage. However, Luciano (US 11307885 B1) teaches monitoring resource usages of the certain computing pods during the initial scoring (col. 5 lines 12-23; “To determine if a user's workload is running on a suitable/optimized VM instance type, the service provider network may determine usage characteristics for the user's workload on the VM instance type, and compare those to the optimized usage characteristics for that VM instance type. The service provider network may determine suitability scores for one or more resource types and/or one or more metrics for each resource type. For instance, the service provider network may determine a suitability score for the CPU usage characteristics, memory usage characteristics, etc., of the workload based on a measure of deviation from the corresponding optimized usage characteristics.”); selecting a specific computing pod other than the particular computing pod for continued scoring based on the resource usages (col. 16 lines 14-27; “In light of such modifications or changes, the optimization service 106 may continually, or periodically, analyze the utilization data 140 of the workload 122 and determine if resource consumption has changed such that a new VM instance type 132 is more appropriate for the workload 122 than the current VM instance type 132 (e.g., VM instance 114). In other examples, the service provider 104 may develop and offer new VM instance type(s) 132 to increase the offerings of VM instance types 132 for users 116. The optimization service 106 may use various techniques, such as workload simulation, to determine that the new VM instance type 132 is more optimized for the workload 122 based on the suitability score than the currently utilized VM instance type 132.” Based on the resource utilization, the system can select a new VM (i.e., specific computing pod other than the particular computing pod) and compute another suitability score (i.e., continued scoring).); and Slinger, Cao, Zheng, El Haj Ahmed , and Mahadik and Luciano are analogous because they are directed towards the same field of endeavor of machine learning for resource utilization. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning models of Slinger, Cao, and Zheng with the method of determining resource usages of Luciano. Doing so would allow for determining an optimal environment for the machine learning model based on resource utilization (Luciano col. 16 lines 14-27;) Regarding Claim 13, Claim 13 is the system corresponding the method of claim 6. Claim 13 is substantially similar to claim 6 and is rejected on the same grounds. Regarding Claim 20, Claim 20 is the computer program product corresponding the method of claim 6. Claim 20 is substantially similar to claim 6 and is rejected on the same grounds. Claim(s) 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Slinger/Cao/Zheng/El Haj Ahmed /Mahadik/Swan/Luciano, as applied above, and further in view of Mao et al. ("Resource management schemes for cloud-native platforms with computing containers of docker and kubernetes."). Regarding Claim 7, Slinger, Cao, Zheng, Mahadik, El Haj Ahmed , Swan, and Luciano teach the computer-implemented method of claim 6. Slinger, Cao, Zheng, El Haj Ahmed , Mahadik, Swan, and Luciano do not explicitly disclose comprising determining that the specific computing pod has a maximum resource usage during the initial scoring among all computing pods carrying out the initial scoring. However, Mao further teaches further comprising determining that the specific computing pod has a maximum resource usage (pg. 4; “Similar to Docker, when clients specify a Pod, they can optionally specify how much CPU and memory each container needs, in terms of limits and requests. A limit is the maximum amount of resources that Kubernetes will allow the container to use”) during the initial scoring among all computing pods carrying out the initial scoring (pg. 4; “Usually, Kubernetes scheduler automatically determines an appropriate node for the pod with a scoring algorithm, which calculates a score to every worker based on multiple factors such as available resources.”). Slinger, Cao, Mao, El Haj Ahmed , Mahadik, Swan, and Luciano are analogous because they are both directed to the same field of endeavor of training a machine learning model. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the machine learning model of Slinger, Cao, El Haj Ahmed , Mahadik, Swan, and Luciano with the Kubernetes containers/pods of Mao. Doing so would allow for reducing the amount of CPU usage for training a machine learning model (pg. 6; “We can see that the container in Docker uses a bit more CPU resources, 87% on average than 83% for Kubernetes.”). Regarding Claim 14, Claim 14 is the system corresponding the method of claim 7. Claim 14 is substantially similar to claim 7 and is rejected on the same grounds. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY K NGUYEN whose telephone number is (571)272-0217. The examiner can normally be reached Mon - Fri 7:00am-4:30pm. 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, Li B Zhen can be reached at 5712723768. 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. /HENRY NGUYEN/Examiner, Art Unit 2121 /Li B. Zhen/Supervisory Patent Examiner, Art Unit 2121
Read full office action

Prosecution Timeline

Show 20 earlier events
Mar 27, 2026
Response after Non-Final Action
Mar 27, 2026
Response after Non-Final Action
Apr 15, 2026
Response after Non-Final Action
Apr 17, 2026
Response after Non-Final Action
May 13, 2026
Response after Non-Final Action
May 13, 2026
Response after Non-Final Action
Jul 24, 2026
Non-Final Rejection (signed) — §103, §112
Sep 03, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12748946
Method, System, and Computer Program Product for Efficient Content-Based Time Series Retrieval
1y 9m to grant Granted Sep 29, 2026
Patent 12718058
HYBRID NEURAL NETWORK ARCHITECTURE WITHIN CASCADING PIPELINES
5y 8m to grant Granted Aug 25, 2026
Patent 12705302
METHOD, ACCELERATOR, AND ELECTRONIC DEVICE WITH TENSOR PROCESSING
5y 9m to grant Granted Aug 11, 2026
Patent 12704841
DEEP REINFORCEMENT LEARNING-BASED TECHNIQUES FOR END TO END ROBOT NAVIGATION
5y 5m to grant Granted Aug 11, 2026
Patent 12705455
MIXTURE-OF-EXPERTS LAYER WITH SWITCHABLE PARALLEL MODES
3y 9m to grant Granted Aug 11, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

5-6
Expected OA Rounds
59%
Grant Probability
86%
With Interview (+26.5%)
4y 6m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 167 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month