DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed 10/20/2023.
Claims 1-20 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “API engine,” “partition engine,” “store engine,” and “invocation engine” in claims 15-20. The term “engine” is a nonce term. The nonce term is linked to and modified by the functional language “receive,” “associate,” and “store” using the phrase “configured to.” The limitations do not include sufficient structure about how the functional language is performed.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. A review of the disclosure as originally filed, hereafter "disclosure", reveals the corresponding structure stating “an “engine” can include program instructions and/or hardware, but at least includes hardware. Hardware is a physical component of a machine that enables it to perform a function. Examples of hardware can include a processing resource, a memory resource, a logic gate, etc.” (¶ [0028]). In accordance with MPEP § 2181(ll)(B), when the corresponding structure of computer implemented mean plus function limitations corresponds to a general purpose computer, an algorithm is required to transform the general purpose computer into a special purpose computer to be sufficient as corresponding structure. Upon further review of the disclosure, applicant has failed to define the algorithm for each of the claimed functions and has instead only provided either verbatim support for the claimed function (which is insufficient as a sequence of steps of a corresponding algorithm) or exemplary language that does not make clear the metes and bounds of the algorithm. As such, see rejections under 35 U.S.C. § 112(a) and (b) below.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 15-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. As explained in the claim interpretation above, claims 15-20 recite an “API engine,” “partition engine,” “store engine,” and “invocation engine” which invokes 35 U.S.C. § 112(f), and the disclosure does not recite sufficient corresponding structure (computing components and algorithm). As such, and in accordance with MPEP § 2181(ll)(B), last paragraph "When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under 35 U.S.C. 112(a)."
Claims 15-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 limitations “API engine,” “partition engine,” “store engine,” and “invocation engine” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. As explained in the claim interpretation above, the disclosure fails to disclose sufficient corresponding structure (computing components and algorithm). As such, and in accordance with MPEP § 2181(II)(B), first paragraph “For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b).” Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, an abstract idea, and it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-7 are directed to a method and falls within the statutory category of processes. Claims 8-14 are directed to a non-transitory machine-readable medium and falls within the statutory category of articles of manufacture. Claims 15-20 are directed to a system and falls within the statutory category of machine. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
Step 2A Prong 1:
Claims 1, 8, and 15: The limitations “associating the schedule with a partition” and “responsive to determining that the schedule is to be invoked within a threshold time period.” These limitations are directed to a mental process because the associating and determining steps involve observing, understanding, and judgement. Associating a schedule with a partition involves observing and understanding the schedule and partition and then forming a judgement. The determining step involves observing and understanding the schedule and threshold time period and then forming a judgement.
Therefore, Yes, claims 1, 8, and 15 recite a judicial exception. Step 2A Prong 2 will evaluate whether the claims are directed to a judicial exception.
Step 2A Prong 2:
Claims 1, 8, and 15: The judicial exception is not integrated into a practical application. Claims 1, 8, and 15 recites the following additional element – “receiving a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target,” “storing the schedule in a cache store,” and “receiving the schedule from the cache store.” These additional elements are considered insignificant extra-solution activities of data gathering/transmission (MPEP § 2106.05(g)) because they involve receiving data and storing data in memory. Additionally, claims 1, 8, and 15 recite “invoking the target responsive to the schedule becoming overdue.” This additional element is considered means to apply an exception (MPEP § 2106.05(f)) because it realizes the process of receiving the schedule, associating it with a partition, storing within a cache responsive to a determining step, and receiving the schedule from a cache. These steps are performed so that the target can be invoked. Additionally, claim 8 also recites “a non-transitory machine-readable medium having instructions stored thereon.” This additional element is considered generic computing components used to apply an exception (MPEP § 2106.05(f)). Claim 15 also recites an “API engine,” “partition engine,” “store engine,” and “invocation engine.” In light of the 112(f) interpretation and associated 112(a) and 112(b) claim rejections, the term “engine” is interpreted to be generic computing components. See claim interpretation section above. Therefore, these “engines” are additional elements of generic computing components used to apply an exception (MPEP § 2106.05(f)). These additional elements do not integrate the judicial exception into a practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception in a practical application?” No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluated the inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 8, and 15 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 8, and 15: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements only amount to insignificant extra-solution activity and means to apply an exception. When reevaluating the additional element of “receiving a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target,” no inventive concept that is other than what is well-understood, routine, and conventional was found. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well-understood, routine, and conventional computer function. Receiving the schedule is a transmission of data over a network. Additionally, the additional elements of “storing the schedule in a cache store” and “receiving the schedule from the cache store” do not contain an inventive concept that is other than what is well-understood, routine, and conventional. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well-understood, routine, and conventional computer function.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis with in the provided framework, claims 1, 8, and 15 do not recite eligible subject matter under 35 U.S.C. § 101.
With regard to claims 2, 9, and 16 it recites “wherein the target is a hypertext transfer protocol (HTTP) endpoint.” This additional element is considered field of use/technological environment (MPEP § 2106.05(h)) because it further limits what kind of endpoint the target can be. It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. Additionally, there are no other limitations that when reevaluated, alone or in combination, add an inventive concept that is significantly more. Therefore, the claims fail Step 2B. Therefore claims 2, 9, and 16 do not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claims 3, 10, and 17 it recites “wherein the partition is a hash-key configured to be associated with a plurality of schedules.” This additional element is considered field of use/technological environment (MPEP § 2106.05(h)) because it further limits what the partition is. It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. Additionally, there are no other limitations that when reevaluated, alone or in combination, add an inventive concept that is significantly more. Therefore, the claims fail Step 2B. Therefore claims 3, 10, and 17 do not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claims 4, 11, and 18 it recites “wherein the method includes updating a configuration store with a result of the invocation of the target.” This additional element is considered an insignificant extra-solution activity of mere data storage (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the additional element(s) for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function. Updating the configuration store with a result is the storing of information in memory. When reevaluating the limitations, alone or combination, no inventive concept that is significantly more was found. Therefore, the claims fail Step 2B. Therefore claims 4, 11, and 18 do not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claims 5, 12, and 19 it recites “wherein the method includes updating the configuration store with a next invocation time associated with the target according to the schedule.” This additional element is considered insignificant extra-solution activity (MPEP § 2106.05(g)) of data storage. It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the additional element(s) for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function. Updating the configuration store with a next invocation time is the storing of information in memory. When reevaluating the limitations, alone or combination, no inventive concept that is significantly more was found. Therefore, the claims fail Step 2B. Therefore claims 5, 12, and 19 do not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claims 6, 13, and 20 it recites “wherein the method includes re-invoking the target, according to a strategy defined in a configuration of the schedule, responsive to a failure to invoke the target.” This additional element is considered means to apply an exception (MPEP § 2106.05(f)) because it realizes the process of receiving the schedule, associating it with a partition, storing within a cache responsive to a determining step, and receiving the schedule from a cache. Therefore, the claims do not integrate the judicial exception into a practical application and fails Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that is significantly more was found. Therefore, the claims fail Step 2B. Therefore claims 6, 13 and 20 do not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claims 7 and 14, it recites “wherein the method includes receiving, via the REST API: a name of the schedule; a description of the schedule; a cron expression associated with the schedule; and an expiration time of the schedule.” This additional element further limits the insignificant extra-solution activity of claims 1 and 8 respectively, so it is also considered an insignificant extra-solution activity of mere data gathering/transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the additional element(s) for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well-understood, routine, and conventional computer function. Therefore claims 7 and 14 do not recite patent eligible subject matter under 35 U.S.C. 101.
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.
Claim(s) 1-4, 6-11, 13- 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beyer et al. Pat. No. US 20200097327 A1 (hereafter Beyer) in view of Busjaeger et al. Pat. No. US 20230060046 (hereafter Busjaeger) and further in view of Moyer Pat. No. US 20180143911 A1 (hereafter Moyer).
With regard to claim 1, Beyer teaches a method, comprising (¶ [0008] states “Embodiments according to the invention are in particular disclosed in the attached claims directed to a method”):
receiving a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” ¶ [0006] states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system, and commands to be delivered to the worker system.” ¶ [0019] states “Each of the server nodes 108, 118 may use the hypervisor to execute virtual machines (VMs).” See 1A and 1B for virtualized environment. Examiner’s Note: The request that is received by the system includes the job, or task, and the schedule. The communication endpoint is the target);
associating the schedule with a partition (¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job.” Examiner’s Note: the job includes a schedule);
storing the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0041] states “The method may begin at step 510, where the job scheduler 201 may receive a request to perform a job from a second computing device, wherein the job comprises one or more steps to be completed in a period”);
and receiving the schedule from the cache store and invoking the target responsive to the schedule becoming overdue (¶ [0005] states “a computing device associated with a distributed job scheduling system may maintain one or more jobs, each job comprising one or more steps, and triggering each of the one or more steps for each job at a time instance specified in job descriptions”).
Beyer does not explicitly teach a REST API and associating the schedule with a partition.
However, in an analogous art, Busjaeger teaches receiving a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0054] states “The API/WS 32 may be any suitable API/WS 32, such as those discussed herein. In one example, a RESTful API 32 may be used, where a REST API endpoint accepts event messages with event data in a JSON payload”);
associating the schedule with a partition (¶ [0051] states “non-relational datastore (NRDS).” ¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables.” ¶ [0094] states “the NRDS 410 distributes portions of the single table uniformly across one or more database clusters or storage nodes. The individual portions of the table may be referred to as “shards” or “partitions.”” Examiner’s Note: when the NRDS stores a key-value pair, it distributes, or associates, the key-value pair with a partition);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the REST API and associating key-value pairs with a partition in a non-relational datastore of Busjaeger with the method of receiving and invoking of a time-based job of Beyer. A person having ordinary skill in the art would have been motivated to make this combination because “Key-value databases are highly partitionable and enable scaling that other types of databases, such as relational databases, cannot achieve” (¶ [0093]). Additionally, “By uniformly distributing the event table across multiple storage nodes as reservation volume increases, allows the system 16 to be scalable since the number and size of physical hardware resources is the only limit to the number of shards that can be inserted” (¶ [0094]). Using APIs allows communication between user systems and application servers (¶ [0021] states “reservations are submitted by users of an external platform through the web tier” and FIG. 1B) and is required to achieve “scalability through the uniform distribution of the reservations across all nodes in the non-relational datastore” (¶ [0021]).
Beyer and Busjaeger do not explicitly teach storing and retrieving the schedule from a cache.
However, in an analogous art, Moyer teaches storing the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0013] states “As used herein, the terms “software hint policy” and “hint policy” refer to whether software hints associated with data are followed or ignored by the cache controller” and “a software hint may be to prefetch data associated with the software hint to the cache based on a prediction that the data will be subsequently requested by the processor core within a threshold period of time”).
and receiving the schedule from the cache store and invoking the target responsive to the schedule becoming overdue (¶ [0019] states “the cache controller 105 indicates a cache hit and satisfies the memory access request at the identified entry, either by storing data at the entry (in the case of a store operation) or by providing the data at the identified entry to the processor core 102 (in the case of a load operation).” Examiner’s Note: the processor receives data from the cache when the cache controller provides the data)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the software hints instructing a cache controller to prefetch data to a cache of Moyer with the computing environment of receiving and invoking jobs with schedules and associating jobs with partitions of Beyer and Busjaeger. As a result, the computing system can prefetch jobs to a cache based, not on a prediction of when the data will be used of Moyer, but on the explicit schedule in the job of Beyer. Prefetching data to a cache is analogous to storing the schedule in the cache before it is to be invoked. A person having ordinary skill in the art would have been motivated to make this combination because “By selecting a software hint policy for the non-test portion of the cache based on access metrics for the different test regions, the cache dynamically changes the software hint policy to the more efficient policy for the pattern of instructions currently executing at a processor, thereby improving processing efficiency” (¶ [0011]). One of ordinary skill in the art would recognizes the benefit of efficient cache policies for improved processing efficiency and improved speed of accessing data in a cache.
With regard to claim 2, Beyer, Busjaeger, and Moyer teach the method of claim 1. Beyer additionally teaches wherein the target is a hypertext transfer protocol (HTTP) endpoint (¶ [0033] and [0034] state “The REST API the job scheduler 201 may use to send the commands to the worker system 203 may be: POST http://resource-init manager:80/api/v1/provision/djs-job-step/hosts-connectivity-data.” Examiner’s Note: the POST request uses HTTP. The example URI uses an HTTP scheme).
With regard to claim 3, Beyer, Busjaeger, and Moyer teach the method of claim 1. Beyer additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0005] states “Each of the one or more job schedulers in the distributed job scheduling system may manage one or more jobs” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” Examiner’s Note: there are a plurality of jobs with schedules).
Busjaeger additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables” and “Any type of data (e.g., characters, numbers, strings, etc.) can be used as keys and values can be any type of data”).
With regard to claim 4, Beyer, Busjaeger, and Moyer teach the method of claim 1. Beyer additionally teaches wherein the method includes updating a configuration store with a result of the invocation of the target (¶ [0006] states “The job scheduler may receive a status update comprising results for the commands from the corresponding worker system. The job scheduler may store the status update to the data store”).
With regard to claim 6, Beyer, Busjaeger, and Moyer teach the method of claim 1. Beyer additionally teaches wherein the method includes re-invoking the target, according to a strategy defined in a configuration of the schedule, responsive to a failure to invoke the target (¶ [0032] states “The step description 302 may also optionally comprise a description of the step, a timeout value for the step, a retry count and a sleep duration between executions of the step. The retry count may indicate a number of retries that the job scheduler 201 needs to try to perform the step when tries are not successful before the job scheduler 201 finally determines that triggering the step to be performed is failed.” Examiner’s Note: the step description is part of the configuration of the schedule. The retry count is the strategy).
With regard to claim 7, Beyer, Busjaeger, and Moyer teach the method of claim 1. Beyer additionally teaches wherein the method includes receiving, via the REST API: a name of the schedule; a description of the schedule (¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps”);
a cron expression associated with the schedule (¶ [0028] states “The schedule filed may indicate periodic schedule using the cron schedule format if the frequency is “Periodic.”” See FIG. 3A);
and an expiration time of the schedule (¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps”).
Busjaeger additionally teaches wherein the method includes receiving, via the REST API (¶ [0054] states “The API/WS 32 may be any suitable API/WS 32, such as those discussed herein. In one example, a RESTful API 32 may be used, where a REST API endpoint accepts event messages with event data in a JSON payload”).
With regard to claim 8, Beyer teaches a non-transitory machine-readable medium having instructions stored thereon which, when executed by a processor, cause the processor to (¶ [0008] states “Embodiments according to the invention are in particular disclosed in the attached claims directed to a method, a storage medium, a system and a computer program product.” ¶ [0051] states “Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits.” ¶ [0045] states “processor 602 includes hardware for executing instructions, such as those making up a computer program.” ¶ [0046] states “memory 604 includes main memory for storing instructions for processor 602 to execute or data for processor 602 to operate on.” See FIG. 6):
receive a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” ¶ [0006] states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system, and commands to be delivered to the worker system.” ¶ [0019] states “Each of the server nodes 108, 118 may use the hypervisor to execute virtual machines (VMs).” See 1A and 1B for virtualized environment. Examiner’s Note: The request that is received by the system includes the job, or task, and the schedule. The communication endpoint is the target);
associate the schedule with a partition (¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job.” Examiner’s Note: the job includes a schedule);
store the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0041] states “The method may begin at step 510, where the job scheduler 201 may receive a request to perform a job from a second computing device, wherein the job comprises one or more steps to be completed in a period”);
and receive the schedule from the cache store and invoke the target responsive to the schedule becoming overdue (¶ [0005] states “a computing device associated with a distributed job scheduling system may maintain one or more jobs, each job comprising one or more steps, and triggering each of the one or more steps for each job at a time instance specified in job descriptions”).
Beyer does not explicitly teach a REST API and associating the schedule with a partition.
However, in an analogous art, Busjaeger teaches receive a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0054] states “The API/WS 32 may be any suitable API/WS 32, such as those discussed herein. In one example, a RESTful API 32 may be used, where a REST API endpoint accepts event messages with event data in a JSON payload”);
associate the schedule with a partition (¶ [0051] states “non-relational datastore (NRDS).” ¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables.” ¶ [0094] states “the NRDS 410 distributes portions of the single table uniformly across one or more database clusters or storage nodes. The individual portions of the table may be referred to as “shards” or “partitions.”” Examiner’s Note: when the NRDS stores a key-value pair, it distributes, or associates, the key-value pair with a partition);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the REST API and associating key-value pairs with a partition in a non-relational datastore of Busjaeger with the method of receiving and invoking of a time-based job of Beyer. A person having ordinary skill in the art would have been motivated to make this combination because “Key-value databases are highly partitionable and enable scaling that other types of databases, such as relational databases, cannot achieve” (¶ [0093]). Additionally, “By uniformly distributing the event table across multiple storage nodes as reservation volume increases, allows the system 16 to be scalable since the number and size of physical hardware resources is the only limit to the number of shards that can be inserted” (¶ [0094]). Using APIs allows communication between user systems and application servers (¶ [0021] states “reservations are submitted by users of an external platform through the web tier” and FIG. 1B) and is required to achieve “scalability through the uniform distribution of the reservations across all nodes in the non-relational datastore” (¶ [0021]).
Beyer and Busjaeger do not explicitly teach storing and retrieving the schedule from a cache.
However, in an analogous art, Moyer teaches store the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0013] states “As used herein, the terms “software hint policy” and “hint policy” refer to whether software hints associated with data are followed or ignored by the cache controller” and “a software hint may be to prefetch data associated with the software hint to the cache based on a prediction that the data will be subsequently requested by the processor core within a threshold period of time”);
and receive the schedule from the cache store and invoke the target responsive to the schedule becoming overdue (¶ [0019] states “the cache controller 105 indicates a cache hit and satisfies the memory access request at the identified entry, either by storing data at the entry (in the case of a store operation) or by providing the data at the identified entry to the processor core 102 (in the case of a load operation).” Examiner’s Note: the processor receives data from the cache when the cache controller provides the data).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the software hints instructing a cache controller to prefetch data to a cache with the computing environment of receiving and invoking jobs with schedules and associating jobs with partitions of Beyer and Busjaeger. As a result, the computing system can prefetch jobs to a cache based, not on a prediction of when the data will be used of Moyer, but on the explicit schedule in the job of Beyer. Prefetching data to a cache is analogous to storing the schedule in the cache before it is to be invoked. A person having ordinary skill in the art would have been motivated to make this combination because “By selecting a software hint policy for the non-test portion of the cache based on access metrics for the different test regions, the cache dynamically changes the software hint policy to the more efficient policy for the pattern of instructions currently executing at a processor, thereby improving processing efficiency” (¶ [0011]). One of ordinary skill in the art would recognizes the benefit of efficient cache policies for improved processing efficiency and improved speed of accessing data in a cache.
With regard to claim 9, Beyer, Busjaeger, and Moyer teach the medium of claim 8. Beyer additionally teaches wherein the target is a hypertext transfer protocol (HTTP) endpoint (¶ [0033] and [0034] state “The REST API the job scheduler 201 may use to send the commands to the worker system 203 may be: POST http://resource-init manager:80/api/v1/provision/djs-job-step/hosts-connectivity-data.” Examiner’s Note: the POST request uses HTTP. The example URI uses an HTTP scheme).
With regard to claim 10, Beyer, Busjaeger, and Moyer teach the medium of claim 8. Beyer additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0005] states “Each of the one or more job schedulers in the distributed job scheduling system may manage one or more jobs” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” Examiner’s Note: there are a plurality of jobs with schedules).
Busjaeger additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables” and “Any type of data (e.g., characters, numbers, strings, etc.) can be used as keys and values can be any type of data”).
With regard to claim 11, Beyer, Busjaeger, and Moyer teach the medium of claim 8. Beyer additionally teaches including instructions to update a configuration store with a result of the invocation of the target (¶ [0006] states “The job scheduler may receive a status update comprising results for the commands from the corresponding worker system. The job scheduler may store the status update to the data store”).
With regard to claim 13, Beyer, Busjaeger, and Moyer teach the medium of claim 8. Beyer additionally teaches including instructions to re-invoke the target, according to a strategy defined in a configuration of the schedule, responsive to a failure to invoke the target (¶ [0032] states “The step description 302 may also optionally comprise a description of the step, a timeout value for the step, a retry count and a sleep duration between executions of the step. The retry count may indicate a number of retries that the job scheduler 201 needs to try to perform the step when tries are not successful before the job scheduler 201 finally determines that triggering the step to be performed is failed.” Examiner’s Note: the step description is part of the configuration of the schedule. The retry count is the strategy).
With regard to claim 14, Beyer, Busjaeger, and Moyer teach the medium of claim 8. Beyer additionally teaches including instructions to receive, via the REST API: a name of the schedule; a description of the schedule (¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps”);
a cron expression associated with the schedule (¶ [0028] states “The schedule filed may indicate periodic schedule using the cron schedule format if the frequency is “Periodic.”” See FIG. 3A);
and an expiration time of the schedule (¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps”).
Busjaeger additionally teaches including instructions to receive, via the REST API (¶ [0054] states “The API/WS 32 may be any suitable API/WS 32, such as those discussed herein. In one example, a RESTful API 32 may be used, where a REST API endpoint accepts event messages with event data in a JSON payload”).
With regard to claim 15, Beyer teaches a system, comprising (¶ [0005] states “a computing device associated with a distributed job scheduling system may maintain one or more jobs”):
an API engine configured to receive a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0044] states “In particular embodiments, computer system 600 includes a processor 602, memory 604, storage 606, an input/output (I/O) interface 608, a communication interface 610, and a bus 612.” ¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” ¶ [0006] states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system, and commands to be delivered to the worker system.” ¶ [0019] states “Each of the server nodes 108, 118 may use the hypervisor to execute virtual machines (VMs).” See 1A and 1B for virtualized environment. Examiner’s Note: The request that is received by the system includes the job, or task, and the schedule. The communication endpoint is the target. In light of the 112(f) claim interpretation and associated 112(a) and 112(b) claim rejections, the term “engine” will be understood to mean generic computing components such as a processor and memory. See claim interpretation section above. Subsequent mentions to “engine” will be treated the same);
a partition engine configured to associate the schedule with a partition (¶ [0044] states “In particular embodiments, computer system 600 includes a processor 602, memory 604, storage 606, an input/output (I/O) interface 608, a communication interface 610, and a bus 612.” ¶ [0005] states “A job scheduler associated with a distributed job scheduling system may receive a request to perform a job from a client computing device” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job.” Examiner’s Note: the job includes a schedule);
a store engine configured to store the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0044] states “In particular embodiments, computer system 600 includes a processor 602, memory 604, storage 606, an input/output (I/O) interface 608, a communication interface 610, and a bus 612.” ¶ [0041] states “The method may begin at step 510, where the job scheduler 201 may receive a request to perform a job from a second computing device, wherein the job comprises one or more steps to be completed in a period”);
and an invocation engine configured to receive the schedule from the cache store and invoke the target responsive to the schedule becoming overdue (¶ [0044] states “In particular embodiments, computer system 600 includes a processor 602, memory 604, storage 606, an input/output (I/O) interface 608, a communication interface 610, and a bus 612.” ¶ [0005] states “a computing device associated with a distributed job scheduling system may maintain one or more jobs, each job comprising one or more steps, and triggering each of the one or more steps for each job at a time instance specified in job descriptions”).
Beyer does not explicitly teach a REST API and associating the schedule with a partition.
However, in an analogous art, Busjaeger teaches an API engine configured to receive a schedule associated with an automation task to be performed in a virtualized environment via a REST API, wherein the task is associated with a target (¶ [0054] states “The API/WS 32 may be any suitable API/WS 32, such as those discussed herein. In one example, a RESTful API 32 may be used, where a REST API endpoint accepts event messages with event data in a JSON payload”).
a partition engine configured to associate the schedule with a partition (¶ [0051] states “non-relational datastore (NRDS).” ¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables.” ¶ [0094] states “the NRDS 410 distributes portions of the single table uniformly across one or more database clusters or storage nodes. The individual portions of the table may be referred to as “shards” or “partitions.”” Examiner’s Note: when the NRDS stores a key-value pair, it distributes, or associates, the key-value pair with a partition).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the REST API and associating key-value pairs with a partition in a non-relational datastore of Busjaeger with the method of receiving and invoking of a time-based job of Beyer. A person having ordinary skill in the art would have been motivated to make this combination because “Key-value databases are highly partitionable and enable scaling that other types of databases, such as relational databases, cannot achieve” (¶ [0093]). Additionally, “By uniformly distributing the event table across multiple storage nodes as reservation volume increases, allows the system 16 to be scalable since the number and size of physical hardware resources is the only limit to the number of shards that can be inserted” (¶ [0094]). Using APIs allows communication between user systems and application servers (¶ [0021] states “reservations are submitted by users of an external platform through the web tier” and FIG. 1B) and is required to achieve “scalability through the uniform distribution of the reservations across all nodes in the non-relational datastore” (¶ [0021]).
Beyer and Busjaeger do not explicitly teach storing and retrieving the schedule from a cache.
However, in an analogous art, Moyer teaches a store engine configured to store the schedule in a cache store responsive to determining that the schedule is to be invoked within a threshold time period (¶ [0013] states “As used herein, the terms “software hint policy” and “hint policy” refer to whether software hints associated with data are followed or ignored by the cache controller” and “a software hint may be to prefetch data associated with the software hint to the cache based on a prediction that the data will be subsequently requested by the processor core within a threshold period of time”);
and an invocation engine configured to receive the schedule from the cache store and invoke the target responsive to the schedule becoming overdue (¶ [0019] states “the cache controller 105 indicates a cache hit and satisfies the memory access request at the identified entry, either by storing data at the entry (in the case of a store operation) or by providing the data at the identified entry to the processor core 102 (in the case of a load operation).” Examiner’s Note: the processor receives data from the cache when the cache controller provides the data).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the software hints instructing a cache controller to prefetch data to a cache with the computing environment of receiving and invoking jobs with schedules and associating jobs with partitions of Beyer and Busjaeger. As a result, the computing system can prefetch jobs to a cache based, not on a prediction of when the data will be used of Moyer, but on the explicit schedule in the job of Beyer. Prefetching data to a cache is analogous to storing the schedule in the cache before it is to be invoked. A person having ordinary skill in the art would have been motivated to make this combination because “By selecting a software hint policy for the non-test portion of the cache based on access metrics for the different test regions, the cache dynamically changes the software hint policy to the more efficient policy for the pattern of instructions currently executing at a processor, thereby improving processing efficiency” (¶ [0011]). One of ordinary skill in the art would recognizes the benefit of efficient cache policies for improved processing efficiency and improved speed of accessing data in a cache.
With regard to claim 16, Beyer, Busjaeger, and Moyer teach the system of claim 15. Beyer additionally teaches wherein the target is a hypertext transfer protocol (HTTP) endpoint (¶ [0033] and [0034] state “The REST API the job scheduler 201 may use to send the commands to the worker system 203 may be: POST http://resource-init manager:80/api/v1/provision/djs-job-step/hosts-connectivity-data.” Examiner’s Note: the POST request uses HTTP. The example URI uses an HTTP scheme).
With regard to claim 17, Beyer, Busjaeger, and Moyer teach the system of claim 15. Beyer additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0005] states “Each of the one or more job schedulers in the distributed job scheduling system may manage one or more jobs” and “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps.” Examiner’s Note: there are a plurality of jobs with schedules).
Busjaeger additionally teaches wherein the partition is a hash-key configured to be associated with a plurality of schedules (¶ [0093] states “the NRDS 410 may be a key-value datastore that stores and manages associative arrays or hash tables” and “Any type of data (e.g., characters, numbers, strings, etc.) can be used as keys and values can be any type of data”).
With regard to claim 18, Beyer, Busjaeger, and Moyer teach the system of claim 15. Beyer additionally teaches wherein the invocation engine is configured to update a configuration store with a result of the invocation of the target (¶ [0006] states “The job scheduler may receive a status update comprising results for the commands from the corresponding worker system. The job scheduler may store the status update to the data store”).
With regard to claim 20, Beyer, Busjaeger, and Moyer teach the system of claim 15. Beyer additionally teaches wherein the invocation engine is configured to re-invoke the target, according to a strategy defined in a configuration of the schedule, responsive to a failure to invoke the target (¶ [0032] states “The step description 302 may also optionally comprise a description of the step, a timeout value for the step, a retry count and a sleep duration between executions of the step. The retry count may indicate a number of retries that the job scheduler 201 needs to try to perform the step when tries are not successful before the job scheduler 201 finally determines that triggering the step to be performed is failed.” Examiner’s Note: the step description is part of the configuration of the schedule. The retry count is the strategy).
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beyer in view of Busjaeger and Moyer and further in view of Else et al. Pat. No. US 20200104165 A1 (hereafter Else).
With regard to claim 5, Beyer, Busjaeger, and Moyer teach the method of claim 4. Beyer additionally teaches wherein the method includes updating the configuration store with a next invocation time associated with the target according to the schedule (¶ [0006] states “The job scheduler may store the status update to the data store.” ¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps." ¶ [0006] further states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system.” ¶ [0028] states “The schedule filed may indicate periodic schedule using the cron schedule format if the frequency is “Periodic.” For example, a schedule field value */5**** may indicate that the job needs to be executed in every 5 minutes”).
Beyer, Busjaeger, and Moyer do not explicitly teach updating a configuration store with a next invocation time.
However, in an analogous art, Else teaches wherein the method includes updating the configuration store with a next invocation time associated with the target according to the schedule (¶ [0096] states “the task descriptors may be stored in a task descriptor database.” ¶ [0096] additionally states “if the test was successfully executed, the task management system 204 updates the test start time to the subsequent time the test needs to be executed (based on its frequency) and reorders the task descriptor in the queue”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the updating a subsequent start time of a task of Elise with the computing system of receiving jobs, associating jobs with a partition, caching jobs, and invoking jobs of Beyer, Busjaeger, and Moyer. As a result, the system can store a subsequent invocation time of the task based on the cron schedule associated with the periodic task. A person having ordinary skill in the art would have been motivated to make this combination because “the presently disclosed systems and methods can avoid bottlenecks that arise when a single task scheduler is utilized to schedule and assign tasks to the correct processing node. Further, by employing distributed task schedulers that can automatically recalibrate and assign tasks to their own processing nodes, the presently disclosed systems and methods can be tolerant of individual node failure” (¶ [0028]). Creating tasks is required to realize the benefits of avoiding bottlenecks and failure tolerance.
With regard to claim 12, Beyer, Busjaeger, and Moyer teach the medium of claim 11. Beyer additionally teaches including instructions to update the configuration store with a next invocation time associated with the target according to the schedule (¶ [0006] states “The job scheduler may store the status update to the data store.” ¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps." ¶ [0006] further states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system.” ¶ [0028] states “The schedule filed may indicate periodic schedule using the cron schedule format if the frequency is “Periodic.” For example, a schedule field value */5**** may indicate that the job needs to be executed in every 5 minutes”).
Beyer, Busjaeger, and Moyer do not explicitly teach updating a configuration store with a next invocation time.
including instructions to update the configuration store with a next invocation time associated with the target according to the schedule (¶ [0096] states “the task descriptors may be stored in a task descriptor database.” ¶ [0096] additionally states “if the test was successfully executed, the task management system 204 updates the test start time to the subsequent time the test needs to be executed (based on its frequency) and reorders the task descriptor in the queue”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the updating a subsequent start time of a task of Elise with the computing system of receiving jobs, associating jobs with a partition, caching jobs, and invoking jobs of Beyer, Busjaeger, and Moyer. As a result, the system can store a subsequent invocation time of the task based on the cron schedule associated with the periodic task. A person having ordinary skill in the art would have been motivated to make this combination because “the presently disclosed systems and methods can avoid bottlenecks that arise when a single task scheduler is utilized to schedule and assign tasks to the correct processing node. Further, by employing distributed task schedulers that can automatically recalibrate and assign tasks to their own processing nodes, the presently disclosed systems and methods can be tolerant of individual node failure” (¶ [0028]). Creating tasks is required to realize the benefits of avoiding bottlenecks and failure tolerance.
With regard to claim 19, Beyer, Busjaeger, and Moyer teach the system of claim 18. Beyer additionally teaches wherein the invocation engine is configured to update the configuration store with a next invocation time associated with the target according to the schedule (¶ [0006] states “The job scheduler may store the status update to the data store.” ¶ [0005] states “The request may comprise a job description for the job comprising a name of the job, a schedule to perform the job, a timeout, and a step description for each of the one or more steps." ¶ [0006] further states “The step description may comprise a name of the step, a communication endpoint for a corresponding worker system.” ¶ [0028] states “The schedule filed may indicate periodic schedule using the cron schedule format if the frequency is “Periodic.” For example, a schedule field value */5**** may indicate that the job needs to be executed in every 5 minutes”).
Beyer, Busjaeger, and Moyer do not explicitly teach updating a configuration store with a next invocation time.
However, in an analogous art, Else teaches wherein the invocation engine is configured to update the configuration store with a next invocation time associated with the target according to the schedule (¶ [0096] states “the task descriptors may be stored in a task descriptor database.” ¶ [0096] additionally states “if the test was successfully executed, the task management system 204 updates the test start time to the subsequent time the test needs to be executed (based on its frequency) and reorders the task descriptor in the queue”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the updating a subsequent start time of a task of Elise with the computing system of receiving jobs, associating jobs with a partition, caching jobs, and invoking jobs of Beyer, Busjaeger, and Moyer. As a result, the system can store a subsequent invocation time of the task based on the cron schedule associated with the periodic task. A person having ordinary skill in the art would have been motivated to make this combination because “the presently disclosed systems and methods can avoid bottlenecks that arise when a single task scheduler is utilized to schedule and assign tasks to the correct processing node. Further, by employing distributed task schedulers that can automatically recalibrate and assign tasks to their own processing nodes, the presently disclosed systems and methods can be tolerant of individual node failure” (¶ [0028]). Creating tasks is required to realize the benefits of avoiding bottlenecks and failure tolerance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200356403 A1
teaches
METHODS AND SYSTEMS THAT VERIFY ENDPOINTS AND EXTERNAL TASKS IN RELEASE-PIPELINE PRIOR TO EXECUTION
US 20180157535 A1
teaches
METHODS, SYSTEMS AND APPARATUSES FOR MANAGING PRIORITIZATION OF TIME-BASED PROCESSES
US 11036762 B1
teaches
Compound Partition And Clustering Keys
US 7716425 B1
teaches
Prefetching Data In Distributed Storage Systems
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights