Prosecution Insights
Last updated: August 18, 2026
Application No. 18/160,492

SYSTEM AND METHOD FOR MANAGING PODS HOSTED BY VIRTUAL MACHINES

Non-Final OA §103§112
Filed
Jan 27, 2023
Examiner
BERMAN, STEPHEN DAVID
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
Dell Products L.P.
OA Round
3 (Non-Final)
78%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allowance Rate
268 granted / 342 resolved
+23.4% vs TC avg
Strong +58% interview lift
Without
With
+58.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
23 currently pending
Career history
364
Total Applications
across all art units

Statute-Specific Performance

§101
12.9%
-27.1% vs TC avg
§103
48.1%
+8.1% vs TC avg
§102
14.8%
-25.2% vs TC avg
§112
17.5%
-22.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 342 resolved cases

Office Action

§103 §112
DETAILED ACTION Remarks The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Office Action is filed in response to Applicant’s Request for Continued Examination dated June 1, 2026. Claims 1, 4, 5, 7, 10, 13, 14, 16, and 19 are currently amended, claims 21-24 are new, and claims 1, 4-10, and 13-24 remain pending in the application and have been fully considered by Examiner. The 35 USC 101 rejections are hereby withdrawn. Applicant's arguments with respect to the prior art rejections have been considered, but are moot in view of the new grounds of rejection presented herein. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 1, 2026, has been entered. Examiner Notes Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 23 is 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. With respect to claim 23, lines 1-3 recite “The data processing system of claim 19, wherein making the attempt to reduce the magnitude of the computing resource expended by the pod comprises: restarting a portion of the pod.” However, “attempt to reduce the magnitude of the computing resource expended by the pod” is not previously recited and it is unclear what this might refer to either in claim 23 or parent claim 19. The scope of claim 23 is therefore indefinite. As the above limitation appears to reference “making an attempt to reduce a magnitude of the computing resources expended by the pod”, as recited in claim 21, Examiner has interpreted claim 19, for purposes of compact prosecution only, as reciting “The data processing system of claim 19, wherein making the attempt to reduce the magnitude of the computing resource expended by the pod comprises: restarting a portion of the pod”. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1, 4, 5, 7, 8, 10, 13, 14, 16, 17, 19, 21, 22, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller et al. US 20210232419 A1 (hereinafter Mueller) in view of Jain et al. US 20230244392 A1 (hereinafter Jain) and Baset et al. US 20130283266 A1 (hereinafter Baset). Regarding claim 1, Mueller discloses A method for providing computer implemented services on a data processing system, ([0009]: “FIG. 1 is a block diagram of a clustered container host system 100, e.g., a Kubernetes system, in which embodiments may be implemented…A virtualization software layer, also referred to herein as a hypervisor 150, is installed on top of the hardware platform. The hypervisor supports a virtual machine execution space within which multiple VMs may be concurrently instantiated and executed. As shown in FIG. 1, the VMs that are concurrently instantiated and executed in host 120-1 includes pod VMs 130,”; [0014]: “Each pod VM 130 has one or more containers 132 running therein in an execution space managed by container runtime 134.”; [0033]: “The embodiments described herein may employ various computer-implemented operations involving data stored in computer systems.” Examiner notes, Kubernetes is a container orchestration platform that provides services using containers.) the method comprising: providing, by hypervisor and to a plurality of pods virtual machine, shared access to hardware resources of the data processing system ([0011]; “VM management server 116 is a physical or virtual server that communicates with host daemon 152 running in hypervisor 150 to provision pod VMs 130 and VMs 140 from the hardware resources of hosts 120 and shared storage 170”); monitoring, by the hypervisor, the virtual machine to identify a decommissioning of the virtual machine ([0013]: “Pod VM controller 154 manages the lifecycle of pod VMs 130 and determines when to spin up or delete a pod VM 130.”; [0009]: “As shown in FIG. 1, the VMs that are concurrently instantiated and executed in host 120-1 includes pod VMs 130.”); ([0001]: “One of the features of workload management software, such as Kubernetes®, is management of workload lifecycles. This can include everything from their specification to their deployment and monitoring.”; Examiner notes, workloads, which are processing data, run in containers hosted by the pod VMs. Therefore, the clustered container host system 100 is a data processing system.) based on the monitoring: identifying a type of the decommissioning ([0003]: “upon detecting that the dummy process has been terminated, selecting one of the containers to be terminated; and terminating processes of the selected container. In one embodiment, the selected container is terminated gracefully. In another embodiment, where graceful termination is not possible, the selected container is terminated forcefully.”); identifying a of the plurality of ([0024]: “In another embodiment, each container is assigned a class of service and as among containers running in the same pod VM, the container with the lowest class of service is selected for termination first.”); adjusting access of the to the shared hardware resources based on the type of the decommissioning to manage operation of the through the (Fig. 3; [0025]: “FIG. 3 is a flow diagram illustrating the steps of a method for evicting workloads according to embodiments. The steps of FIG. 3 are carried out by a pod VM agent running in a pod VM. The method begins at step 312, where the pod VM agent continually monitors a dummy process that has been launched in the pod VM to run alongside containers in the pod VM. When the dummy process terminated as determined at step 314, the pod VM agent selects a container to be terminated at step 316. In one embodiment, the container to be terminated is selected based on a class of service assigned to all containers currently running in the pod VM. Then, at step 318, the pod VM agent terminates all processes in the selected container in an orderly manner that ensures a graceful shutdown of the selected container, e.g., according to an order that is implied by the container's internal dependencies.”; Examiner notes, “graceful shutdown” means the container is notified of a coming decommissioning, and allowed to continue operating for a segment of time to finish processing) decommissioning of the virtual machine ([0013]: “Pod VM controller 154 manages the lifecycle of pod VMs 130 and determines when to spin up or delete a pod VM 130.”; Examiner notes, shutting down a pod VM would enforce one of the types of decommissioning across the pod VM’s containers, therefore, during graceful shutdown, the containers would still be operating, as previously taught in [0003]); . Mueller does not teach hosted by a virtual machine …. identifying a pod of the plurality of pods … adjusting access of the pod … to manage operation of the pod. However, in analogous art, Jain teaches hosted by a virtual machine (e.g., Fig. 4A, particularly, virtual machine 402 and pods 404, along with associated text, e.g., Abstract, “consolidating … pods hosted in multiple virtual machines into a single virtual machine” [a plurality of pods hosted by a virtual machine]; see also [0033].) … identifying a pod of the plurality of pods (Fig. 4A - 402; [0033]: “5) utilizing unconventional and non-routine systems and techniques to assign pods to virtual machines in a manner that more efficiently consumes available IOPS and throughput of the virtual machines using a best fit bin packing mechanism;”) … adjusting access of the pod … to manage operation of the pod (e.g., Figs. 1-5 and associated text, e.g., [0029], “The vertical pod autoscaler generates and executes these recommendations to ensure proper execution of applications and to efficiently utilize resources. If resources assigned to a pod are smaller than requirements of workloads performed by applications hosted as containers of the pod, then the applications may fail due to running out of resources or will be throttled, which can result in degraded performance. If the resources assigned to the pod are much larger than the requirements of workloads, then the resources are wasted. Accordingly, the vertical pod autoscaler can generate recommendations of memory and processor allocations that meet or exceed the historic memory and processor utilization by the pod to ensure that an adequate amount of resources are assigned to the pod.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the invention of Mueller with the invention of Jain because it can “efficiently utilize resources” (see [0029]) and allow for “more efficient resource consumption by the virtual machines”, as suggested by Jain (see [0030]). Mueller as modified does not appear to disclose the following, which is taught in analogous art, Baset: detecting that a workload of the data processing system exceeds a threshold (e.g., Figs. 3-4 and associated text, e.g., [0047], “Upon an overload (that is, resource usage exceeding a threshold thrd1), a set of VMs on the overloaded hypervisor is identified that have to be migrated or quiesced to remediate the overload; In step 304, C={the VMs consuming the most resources on the overloaded hypervisor such that the rest of the VMs consume less than a threshold (for example, 85%) of physical resources}”) … to be a load balancing decommissioning (e.g., Figs. 3-4 and associated text, e.g., [0047], “Upon an overload (that is, resource usage exceeding a threshold thrd1), a set of VMs on the overloaded hypervisor is identified that have to be migrated or quiesced to remediate the overload; [0053] FIG. 3 is a flow diagram illustrating a selection algorithm for VM quiesce, according to an embodiment of the present invention. In step 302, Q = {the VMs planned to be quiesced [identifying a type of decommissioning to be a load balancing decommissioning] by this algorithm ... }.) … reducing the workload of the data processing system (e.g., Figs. 3-4 and associated text, e.g., [0053], “Step 308 includes testing to determine if the VMs in C can be migrated to other hypervisors”; [0054], “In step 312, Q = Q + {the VM with the next smallest U/R value and with acceptable quiesce cost}. Step 314 includes determining if the overload is remediated. If yes, the algorithm proceeds to step 316”.); and stopping the decommissioning of the virtual machine in response to reduction of the workload (e.g., Figs. 3-4 and associated text e.g., [0053], Q = {the VMs planned to be quiesced [decommissioning] by this algorithm; [0054], “Step 314 includes determining if the overload is remediated. If yes, the algorithm proceeds to step 316 … step 316 includes removing from Q the VMs unnecessarily added into Q by step 312.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Mueller with the invention of Baset, such that VM quiescing is stopped when the system no longer being overloaded, because “a need exists for remediating an overload in over-committed computing environments,” as suggested by Baset (see [0005]). Regarding claim 10, the limitations are equivalent to claim 1 (see the rejection of claim 1 above), except for the following limitations, which are further taught in Mueller: A non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations ([0004]: “Further embodiments include a non-transitory computer-readable storage medium comprising instructions that cause a computer system to carry out the above methods, as well as a computer system configured to carry out the above methods.”; Fig. 2 – element 160; Examiner notes, the computer system contains CPUs.) for providing computer implemented services on a data processing system, the operations comprising: ([0009]: “FIG. 1 is a block diagram of a clustered container host system 100, e.g., a Kubernetes system, in which embodiments may be implemented…A virtualization software layer, also referred to herein as a hypervisor 150, is installed on top of the hardware platform. The hypervisor supports a virtual machine execution space within which multiple VMs may be concurrently instantiated and executed. As shown in FIG. 1, the VMs that are concurrently instantiated and executed in host 120-1 includes pod VMs 130,”; [0014]: “Each pod VM 130 has one or more containers 132 running therein in an execution space managed by container runtime 134.”; Examiner notes, Kubernetes is a container orchestration platform that provides services using containers.) Regarding claim 19, the limitations are equivalent to claim 1 (see the rejection of claim 1 above), except for the following limitations, which are further taught in Mueller: A data processing system, ([0001]: “One of the features of workload management software, such as Kubernetes®, is management of workload lifecycles. This can include everything from their specification to their deployment and monitoring.”; Examiner notes, workloads, which are processing data, run in containers hosted by the pod VMs. Therefore, the clustered container host system 100 is a data processing system.) comprising: a processor; (Fig. 2 – element 160) and a memory coupled to the processor ([0009]: “System 100 includes a cluster of hosts 120 which may be constructed on a server grade hardware platform such as an x86 architecture platform. The hardware platform includes one or more central processing units (CPUs) 160, system memory, e.g., random access memory (RAM) 162…”; Examiner notes, CPUs and RAM are a part of the same hardware architecture, therefore “coupled”.) to store instructions, which when executed by the processor, cause the processor to perform operations ([0004]: “Further embodiments include a non-transitory computer-readable storage medium comprising instructions that cause a computer system to carry out the above methods, as well as a computer system configured to carry out the above methods.”; Fig. 2 – element 160; Examiner notes, the computer system contains CPUs.) for providing computer implemented services, the operations comprising: ([0009]: “FIG. 1 is a block diagram of a clustered container host system 100, e.g., a Kubernetes system, in which embodiments may be implemented…A virtualization software layer, also referred to herein as a hypervisor 150, is installed on top of the hardware platform. The hypervisor supports a virtual machine execution space within which multiple VMs may be concurrently instantiated and executed. As shown in FIG. 1, the VMs that are concurrently instantiated and executed in host 120-1 includes pod VMs 130,”; [0014]: “Each pod VM 130 has one or more containers 132 running therein in an execution space managed by container runtime 134.”; Examiner notes, Kubernetes is a container orchestration platform that provides services using containers.). Regarding claims 4, 13, and 21, Jain further teaches identifying computing resource expended by the pod (e.g., Figs. 1-5 and associated text, e.g., [0057]: “A vertical pod autoscaler 416 may be configured to monitor 418 resource consumption by the pods”.); making an attempt to reduce a magnitude of the computing resource expended by the pod (e.g., Figs. 1-5 and associated text, e.g., [0029], the vertical pod autoscaler can generate recommendations of memory and processor allocations that meet or exceed the historic memory and processor utilization by the pod to ensure that an adequate amount of resources are assigned to the pod; [0054], If the upper bound limit and/or the lower bound limit would be exceeded, then the vertical pod autoscaler 104 may implement updater functionality 106 to evict 126 the container 134, during operation 210 of method 200.); and Baset further teaches and; in an instance of the attempt where the magnitude of the computing resources expended is reduced: notifying a management entity for the virtual machine of the reduced expenditure of the computing resource (e.g., Figs. 3-4 and associated text, e.g., [0053-54], Step 308 includes testing to determine if the VMs in C can be migrated to other hypervisors … If the test is successful (as determined in step 310), then the work is carried out and the algorithm proceeds to step 316; otherwise, the algorithm proceeds to step 312. In step 312, Q=Q+{the VM with the next smallest U/R value and with acceptable quiesce cost}. Step 314 includes determining if the overload is remediated. If yes, the algorithm proceeds to step 316 … step 316 includes removing from Q the VMs unnecessarily added into Q by step 312.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine the invention of Mueller with the inventions of Jain and Baset for the same reasons set forth above. Regarding claims 5, 14, and 22, Jain further teaches wherein the method further comprises: gracefully terminating operation of the pod (e.g., Figs. 1-5 and associated text, e.g., [0042], “Thus, the pod may be evicted without breaching the upper bound limit and the lower bound limit, in some embodiments”; [0064], “the vertical pod autoscaler 416 may evict pods from a virtual machine so that the pods can be deployed upon other virtual machines and the virtual machine may be decommissioned, during operation 312 of method 300. For example, the vertical pod autoscaler 416 may evict the second pod 408 from the second virtual machine 406. The second pod 408 may be placed within the queue for scheduling by the scheduler 420. The scheduler 420 may utilize the custom filter 424 to determine that the first virtual machine 402 will have the least remaining IOPS out of virtual machines if the first virtual machine 402 would host the second pod 408. Accordingly, the scheduler 420 may deploy 426 the second pod 408 to the first virtual machine 402.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine the invention of Mueller with the invention of Jain for the same reason set forth above. Regarding claims 7, 16, and 24, Jain further teaches migrating the pod to a second virtual machine (e.g., Figs. 1-5 and associated text, e.g., [0057], “a first pod 404 may be hosted on the first virtual machine 402 and a second pod 408 may be initially hosted on the second virtual machine 406. A vertical pod autoscaler 416 may be configured to monitor 418 resource consumption by the pods, generate recommendations of how to deploy (re-host) pods on virtual machines, and evict pods from virtual machines so the pods can be deployed on different virtual machines”; [0066], “the pod may be migrated to the new node”; see also [0064].). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine the invention of Mueller with the invention of Jain for the same reason set forth above. Regarding claims 8 and 17, Mueller further teaches wherein the type of the decommissioning is based on a management action that triggered a management entity to initiate the decommissioning ([0013]: “Hypervisor 150 includes a host daemon 152 and a pod VM controller 154. As described above, host daemon 152 communicates with VM management server 116 to instantiate pod VMs 130 and VMs 140. Pod VM controller 154 manages the lifecycle of pod VMs 130 and determines when to spin up or delete a pod VM 130”). Claims 6, 15, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller in view of Jain and Baset, as applied to claims 5 and 14 above, and further in view of Gaurav et al. US 20160378563 A1 (hereinafter Gaurav). Regarding claims 6, 15, 23, Jain further teaches wherein making the attempt to reduce the magnitude of the computing resource expended by the pod comprises: It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine the invention of Mueller with the invention of Jain for the same reason set forth above. Mueller as modified does not appear to disclose the following, which is taught in analogous art, Gaurav: restarting a portion of the pod ([0040]: “…virtualization management module 130 dynamically removes memory from this VM to reset memory to mem_alloc (hot remove). In some embodiments (for example where dynamically removal is not supported), an alert may be provided to a system administrator to power off the VM and then remove memory from the VM, and then restart containers on the VM.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to further modify the invention of Muller with the restarting of the containers on a VM or resetting a VM’s memory in Gaurav because it can “optimize hardware resources by providing a correct resource allocation to host VMs by looking at the consumption of containers”, as suggested by Gaurav (see [0022]). Claims 9, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mueller in view of Jain and Baset, as applied to claims 8, 17, and 19 above, and further in view of Kondo et al. US 20190068442 A1 (Kondo). Regarding claims 9 and 18, Mueller further teaches wherein the management action is one selected from a group of management actions consisting ofand load balancing for the data processing system ([0011]: “VM management server 116 logically groups hosts 120 into a cluster to provide cluster-level functions to hosts 120, such as load balancing across hosts 120 by performing VM migration between hosts 120,”). Mueller as modified does not teach the following, which is taught in analogous art, Kondo: unscheduled maintenance of the data processing system ([0029]: “Also, for example, in a case where the current request trend follows the past request trend and the number of current requests is smaller than the number of requests in the past request trend, the processor allows the administrator to choose whether or not to immediately perform maintenance. In a case where the administrator chooses to immediately perform maintenance, the processor starts maintenance processing, for example, without performing the above-described standby.”); scheduled maintenance of the data processing system ([0029]: “Also, in a case where the administrator chooses not to immediately perform maintenance, the processor causes maintenance processing to be started after standing by, for example, until the determined maintenance time period comes.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to further modify the invention of Mueller with the invention of Kondo because maintenance can be done during a time where VMs have their least requests (see Kondo [0011]) and done in a prioritized order to decrease downtime (see Kondo [0027]). Regarding claim 20, Mueller further teaches wherein the type of the decommissioning is based on a management action that triggered a management entity to initiate the decommissioning ([0013]: “Hypervisor 150 includes a host daemon 152 and a pod VM controller 154. As described above, host daemon 152 communicates with VM management server 116 to instantiate pod VMs 130 and VMs 140. Pod VM controller 154 manages the lifecycle of pod VMs 130 and determines when to spin up or delete a pod VM 130”), and the management action is one selected from a group of management actions consisting of: and load balancing for the data processing system ([0011]: “VM management server 116 logically groups hosts 120 into a cluster to provide cluster-level functions to hosts 120, such as load balancing across hosts 120 by performing VM migration between hosts 120,”). Mueller as modified does not teach the following, which is taught in analogous art, Kondo: unscheduled maintenance of the data processing system ([0029]: “Also, for example, in a case where the current request trend follows the past request trend and the number of current requests is smaller than the number of requests in the past request trend, the processor allows the administrator to choose whether or not to immediately perform maintenance. In a case where the administrator chooses to immediately perform maintenance, the processor starts maintenance processing, for example, without performing the above-described standby.”); scheduled maintenance of the data processing system ([0029]: “Also, in a case where the administrator chooses not to immediately perform maintenance, the processor causes maintenance processing to be started after standing by, for example, until the determined maintenance time period comes.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to further modify the invention of Mueller with the invention of Kondo because maintenance can be done during a time where VMs have their least requests (see Kondo [0011]) and done in a prioritized order to decrease downtime (see Kondo [0027]). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Feng et al. 20170109211 A1 discloses a process for the dynamic decommissioning of VMs. Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern. 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, Hyung S. Sough can be reached on 571-272-6799. 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. /STEPHEN D BERMAN/ Examiner, Art Unit 2192
Read full office action

Prosecution Timeline

Jan 27, 2023
Application Filed
Jul 29, 2025
Non-Final Rejection mailed — §103, §112
Oct 29, 2025
Response Filed
Mar 03, 2026
Final Rejection mailed — §103, §112
Jun 01, 2026
Request for Continued Examination
Jun 03, 2026
Response after Non-Final Action
Jul 15, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675269
CONTAINERIZED, DECENTRALIZED, AND DISTRIBUTED WEB APPLICATIONS WITH END-TO-END ENCRYPTION
2y 9m to grant Granted Jul 07, 2026
Patent 12664069
CODE CONCIERGE MODEL (CCM) FOR PREDICTING RUNTIME ERRORS OF SOURCE CODE
3y 1m to grant Granted Jun 23, 2026
Patent 12664073
ONE REGRESSION DETECTION TESTING METHOD
2y 8m to grant Granted Jun 23, 2026
Patent 12657114
ASCERTAINING APPLICATION TEST COVERAGE
3y 8m to grant Granted Jun 16, 2026
Patent 12645566
View-Based Breakpoints For A Display System
5y 2m to grant Granted Jun 02, 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

3-4
Expected OA Rounds
78%
Grant Probability
99%
With Interview (+58.3%)
2y 8m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 342 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