Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-5, 9-12 and 16-19 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 pre-AIA the applicant regards as the invention.
Regarding claims 2, 9 and 16, the claims recite “identifying a number of subprocess pods that need to be selected in order to ensure that a parent process task will successfully complete an assigned job”. There appears to be no explicit number that indicates what the number is in the specification and thus the language is deemed indefinite and therefore for the purpose of art the number is deemed to be all subprocess pods are needed for the parent process to be successful.
Regarding claims 4, 11 and 18, the claims recite “selecting a number of subprocess pods of said plurality of evicted subprocess pods based on the execution status of said subprocess pods being most complete of assigned tasks, wherein said selected number of subprocess pods corresponds to said number of subprocess pods that need to be selected in order to ensure that said parent process task will successfully complete said assigned job”. First as articulated in regard to the rejection of claim 2, there appears to be no explicit number that indicates what the number is in the specification and thus the language is deemed indefinite and therefore for the purpose of art the number is deemed to be all subprocess pods are needed for the parent process to be successful. Secondly, the language of “said subprocess pods being most complete of assigned tasks” is a relative term in that there is no degree to ascertain which pods are more complete or deemed more complete compared to others. Further the claim language does not appear to make a distinction between all pods deemed necessary and thereby all pods being evaluated on being most complete. Thus, the claims are both relative in measuring how its most complete and indefinite in its comparison as articulated above. For the purpose of prior art, the claims will be interpreted as all subprocess pods are necessary for the parent process and thereby all subprocess pods need to be extended for completion.
Regarding claims 3, 5, 10, 12, 17 and 19, dependent claims inherit the deficiencies of the respective parent claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 102(a)(1)) as being anticipated by Abdelsalam (US 20200183750 A1).
Regarding claim 1, Abdelsalam teaches:
A computer-implemented method for handling an eviction of subprocess pods of a virtualized operating system, the computer-implemented method comprising: ([0006] According to some embodiments, a method for terminating an instance associated with an instance group of a computing platform includes determining whether an instance of an instance group is identified as eligible for termination. The method further includes, in response to determining that the instance of the instance group is identified as eligible for termination, terminating the eligible instance.)
receiving, by a computing device, an indication to evict pods of a node. ([0067] In some embodiments, at the process 402, whether an instance of an instance group is identified as eligible for termination is determined. At the process 404, in response to determining that the instance of the instance group is identified as eligible for termination, the eligible instance is terminated. At the process 406, in response to a runtime of the eligible instance being equal to or larger than a predetermined maximum lifetime, the eligible instance is terminated. )
retrieving process information pertaining to said evicted pods; ([0027] In certain embodiments, the scheduler 116 is configured to a new custom resource to the computing platform 102 called Demand. For example, Demand is an expression of a demand that could not be scheduled together. In some examples, the Demand includes: an instance group label that a demand is for; a list of demand units, e.g., a standard CPU resources, a standard memory resource, a count of discrete demand units; an owner reference that points to the job that caused the demand; and a status that includes: empty (the initial stage), pending (autoscaler has seen the demand), in-progress (autoscaler has started provisioning resources for the demand), fulfilled (autoscaler has satisfied the demand), and cannot fulfill (if a single demand unit exceeds what can be provided in a single instance group increment, i.e., the default instance size).)
generating a schedule plan for selected subprocess pods of said evicted pods with a timeout that is less than a threshold value, wherein said schedule plan updates said timeout for said selected evicted subprocess pods of said evicted pods; ([0042] In certain embodiments, the termination dispatcher 114 is configured to evict each pod associated with the detached instance 202 prior to terminating the detached instance 202. In some examples, the evicting a pod by the termination dispatcher 114 includes gracefully evicting the pod from the instance associated with the pod. For example, the termination dispatcher 114 is configured to not immediately kill each container of the pods associated with the detached instance 202. In one example, gracefully evicting the pod prevents the work associated with the pod to be rescheduled by the scheduler 116. As an example, gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period. In one example, the termination dispatcher 114 is configured to kill the containers of the pod if the predetermined grace period of the pod is expired.)
and scheduling said selected subprocess pods to run on an available node according to said schedule plan. ([0063]For examples, the autoscaler 110 is configured to attempt and move capacity to deferring instances from other instance with the deferring instances including pods that are not to be killed. In certain examples, the autoscaler 110 is configured to order the filtered instances based on the following: (1) the sum of the priority field of all pods currently scheduled on an instances is computed, lower priority first, to attempt to minimize the impact to higher priority pods running across instances; and (2) ties are broken by using the creation time of the instance, preferring an older instance over a younger instance. In other examples, the autoscaler 110 is configured to, starting from the first instance in the ordered list of instances, to bin pack pods of the first instance onto other instances of the computing platform 102. For example, an instance is considered scale-down-able by the autoscaler 110, if all pods of the instance are bin packable onto other instance of the computing platform 102. In some examples, the autoscaler 110 is configured to continue this process until there are no more instances left in the ordered list or until no more instances can be removed. For example, some instances might still be below the predetermined utilization threshold targets after this process is completed due to their workload not being schedulable on other instances of the computing platform 102. In yet another example, it is likely that the instances towards the end of the ordered list, i.e., the instances with higher priorities, are the ones that most of the workload is shifted to. In this example, the autoscaler 110 is configured to not wait for an instance to actually terminate before moving on in the ordered list of instances eligible for scale down.)
Regarding claims 8 and 15 recite commensurate subject matter as claim 1. Therefore, they 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.
Claims 2-4, 7, 9-11, 14 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Abdelsalam (US 20200183750 A1), in view of “Kubernetes documentation: Workloads” hereafter Kubernetes 1 and “Kubernetes documentation: Pods” hereafter Kubernetes 2.
Regarding claim 2, Abdelsalam does not appear to explicitly teach:
The computer-implemented method as recited in claim 1 further comprising: identifying a number of subprocess pods that need to be selected in order to ensure that a parent process task will successfully complete an assigned job. (EN: based on 112 rejections, interpretation is all pods are necessary for parent process to successfully execute.)
However, Kubernetes 1 teaches: on page 1, A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of one or more running containers on your cluster. EN: Kubernetes 1 a shows a plurality of processes working together.
Accordingly, Kubernetes 1 shows before the effective filing date that an application workload may comprise several components that work together and the components of the workload are executed within a set of pods. The application workload corresponds to the parent process task, while the respective pods within the set corresponds to the subprocess pods performing portions of the parent workload.
Kubernetes 2 also teaches: Page 2. Pods that run multiple containers that need to work together. A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving data stored in a shared volume to the public, while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity together as a single unit.
Accordingly, A person of ordinary skill in art would have been motivated to apply the workload and pod teachings of Kubernetes 1 and Kubernetes 2 to Abdelsalam because Abdelsalam already performs scheduling and eviction for pods in a container orchestration environment. Kubernetes 1 and Kubernetes 2 explain the known Kubernetes organization that an application can include several cooperating components executed in a set of pods and that multiple pods or subprocesses. Applying this known Kubernetes teachings to Abdelsalam would have allowed to determine the number of subprocess pods required for a workload, e.g. all pods to successfully complete.
Regarding claim 3, Abdelsalam teaches:
The computer-implemented method as recited in claim 2 further comprising: identifying an execution status of each subprocess pod of a plurality of evicted subprocess pods… (EN: based on 112 rejections, interpretation is all pods are necessary for parent process to successfully execute. [0043] According to some embodiments, the evicting a pod by the termination dispatcher 114 includes respecting a predetermined health condition of the one or more services provided by the pod. For example, the predetermined health condition of a service includes a predetermined maximum number of disruptions related to the service. In one example, the disruptions include voluntary failures and/or voluntary disruptions. In another example, the disruptions include simultaneous failures and/or simultaneous disruptions. In certain examples, the respecting the predetermined health condition of a service includes limiting a number of failures and/or disruptions related to the service to a value that is smaller than the predetermined maximum number of disruptions. In one example, the termination dispatcher 114 is configured to evict a pod associated with the detached instance 202 if the pod is non-deferring. For example, a pod running and performing work on an instance represents a deferring pod.)
Abdelsalam does not appear to explicitly teach: …scheduled for processing tasks in connection with said parent process task.
However, Kubernetes 1 teaches: on page 1, A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of one or more running containers on your cluster. EN: Kubernetes 1 a shows a plurality of processes working together.
Kubernetes 2 also teaches: Page 2. Pods that run multiple containers that need to work together. A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving data stored in a shared volume to the public, while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity together as a single unit.
Same motivation as claim 2
Regarding claim 4, Abdelsalam teaches:
The computer-implemented method as recited in claim 3 further comprising: selecting a number of subprocess pods of said plurality of evicted subprocess pods based on the execution status of said subprocess pods being most complete of assigned tasks, wherein said selected number of subprocess pods corresponds to said number of … ([0029] According to certain embodiments, the terminator 112 is configured to identify an instance of an instance group as eligible for termination in response to the instance meeting one or more predetermined eligibility conditions. For example, the predetermined eligibility conditions allow for flexibility regarding termination of particular instances. In some examples, the one or more predetermined eligibility conditions include the condition that a software upgrade is provided by the computing platform 102 for the instance and/or the instance group. In certain examples, the one or more predetermined eligibility conditions include the condition that a runtime of the instance is equal to or larger than a predetermined maximum lifetime. For example, the runtime of the instance represents a period of time when the instance is running and that starts at a time when the instance is launched. In other examples, the one or more predetermined eligibility conditions include the condition that the instance 124.sub.1-k is detached from any instance group 118.sub.1-N of the computing platform 102. In yet other examples, the one or more predetermined eligibility conditions include the condition that the runtime of the instance is larger than a predetermined minimum lifetime. See also [0063])
Abdelsalam does not appear to explicitly teach: …subprocess pods that need to be selected in order to ensure that said parent process task will successfully complete said assigned job.
However, Kubernetes 1 teaches: on page 1, A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of one or more running containers on your cluster. EN: Kubernetes 1 a shows a plurality of processes working together.
Kubernetes 2 also teaches: Page 2. Pods that run multiple containers that need to work together. A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving data stored in a shared volume to the public, while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity together as a single unit.
Same motivation as claim 2
Regarding claim 7, Abdelsalam teaches:
The computer-implemented method as recited in claim 1 further comprising: tagging each subprocess pod of said evicted pods with a timeout that is less than said threshold value. ([0042] As an example, gracefully evicting a pod by the termination dispatcher 114 includes the termination dispatcher 114 starting a predetermined grace period and allowing the containers of the pod to run to completion and perform cleanup functions during the predetermined grace period. In one example, the termination dispatcher 114 is configured to kill the containers of the pod if the predetermined grace period of the pod is expired.)
Regarding claims 9-11, 14, and 16-18 recite commensurate subject matter as claims 2-4,and 6-7. Therefore, they are rejected for the same reasons.
Allowable Subject Matter
Claims 5-20 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sabath (US 20200153898 A1) – Teaches node updates with workload migration in a container cluster.
Thakare (US 20240160428 A1) – discusses evection application pods and redeploying them during node upgrades
Sehgal (US 20220350656 A1 ) – discusses rescheduling evited pods using scheduling data.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights