DETAILED ACTION
This office action is in response to application filed on 2/6/2024 in which claims 1-20 are pending in the application. Claims 1, 18, and 20 are in independent form.
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 .
Priority
This application claims the benefit of U.S. Provisional Patent Application No. 63/483,587, filed February 7, 2023.
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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-19 are directed to a system and therefore is a machine which is one of the statutory categories of invention.
Step 2A, Prong 1:
Claim 1 recites the limitation “at least one master node including a processing system configured to automatedly analyze the cluster based on a plurality of measured parameters , and to use the results of the analysis to: allocate shards across the nodes; partition a workload for allocating portions thereof among the shards, and selectively allocate resources to the shards sufficient to support the workload portions.”. This limitation is a process that covers performance of the limitation in the mind.
Claim 18 recites the limitation “reallocate shards across the nodes when needed to improve performance or efficiency; allocate or reconfigure the workload portions among one or more of the shards, and selectively allocate or reconfigure resources to the shards sufficiently to support respective workload portions.”. This limitation is a process that covers performance of the limitation in the mind.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgement, and opinion).
Step 2A, Prong 2:
The judicial exception is not integrated into a practical application. The claim recites the following additional elements “master node”, “processing system”, “networked nodes” and “search engine”, this limitation amounts to no more than applying the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (see MPEP 2106.05(f)); The claims are directed to an abstract idea.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The limitations “master node”, “processing system”, “networked nodes” and “search engine” are recognized by the courts as well-understood, routine, and conventional activities when they are claimed in a merely generic manner (see MPEP 2106.05(d)(II)(iv).
Dependent claim 2 recites the limitation “wherein the processing system is configured to measure individual resource needs of the shards for selectively allocating the workload portions”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 3 recites the limitation “wherein the workload comprises indexing, searching, and aggregations.” This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 4 recites the limitation “wherein the plurality of measured parameters includes one or more of shard, node, or cluster-based”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 5 recites the limitation “the processing system is further configured to aggregate the plurality of measured parameters into statistics for use in predicting future allocations”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 6 recites the limitation “the processing system is further configured to predict future resource needs”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 7 recites the limitation “determine a target allocation of shards to the plurality of nodes in the cluster, wherein each of the shards is allocated resources from the cluster needed for the shard based on the respective workload portion.”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 8 recites the limitation “the processing system is further configured to periodically reconcile a current allocation of shards in the cluster towards the target allocation”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 9 recites the limitation “the processing system is further configured to revise the target allocation of the shards to another target allocation”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 10 recites the limitation “processing system is further configured to revise the target allocation of the shards to another target allocation”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 11 recites the limitation “the processing system is further configured to add or remove one or more of the plurality of nodes in the cluster while preserving sufficient resources for shards affected by the addition or removal”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 12 recites the limitation “the processing system is further configured to adjust the resources allocated to each node while preserving sufficient resources for shards affected by the adjustment.”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 13 recites the limitation “the processing system is further configured to adjust a strategy used to partition the workload of the cluster”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 14 recites the limitation “further comprising an orchestrator configured to auto-scale the cluster, the auto-scaling comprising adding or removing nodes based on (i) actual or anticipated storage needs of the cluster, and (ii) actual or anticipated indexing needs of the cluster”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 15 recites the limitation “the orchestrator is further configured to auto-scale the cluster based on the amount of random access memory”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 16 recites the limitation “the orchestrator is further configured to auto-scale the cluster based on a number of processors needed to manage a current workload in the cluster.”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 17 recites the limitation “wherein the resources include at least one of: one or more central processing units (CPUs) or hardware computational resources; durable storage; random access memory (RAM); cache memory; or network resources.”. This limitation is a mental process because it describes acts of observation, evaluation, judgement, selection, or opinion that can be performed in the human mind. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)).
Dependent claim 19 recites the limitation “the processing system is configured to auto-scale the cluster, the auto-scaling comprising adding or removing nodes to the cluster”. This limitation is a mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (see MPEP 2106.05(g)).
Claim Rejections - 35 USC § 102
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 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-13, and 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kai et al. (CN 113568749 B).
As per claim 1, Kai discloses a system for a distributed search engine, comprising:
a cluster comprising a plurality of networked nodes, the cluster having a workload; [Para [0020], The client and the Elasticsearch cluster are connected, meaning the client connects to each slave node server. The client can input data through other slave node servers.];
and at least one master node including a processing system configured to automatedly analyze the cluster based on a plurality of measured parameters, [Para [0022], Specifically, if the master node receives a request to create an index from a client, it constructs shard allocation rules based on the request. Optionally, the master node creates shard allocation rules based on the Elasticsearch cluster’s own Allocation strategy and user-defined rules.];
and to use results of the analysis to: allocate shards across the nodes; [Para [0022], The shard allocation rules determine which slave nodes can be allocated shards for the newly created index, and which slave nodes cannot or are not suitable for allocating shards for the newly created index.];
partition a workload for allocating portions thereof among the shards, [Para [0024], Specifically, according to the shard allocation rules, the master node can know which slave nodes are available for allocation.];
and selectively allocate resources to the shards sufficient to support the workload portions. [Para [0025], based on the CPU utilization status and memory utilization status of each allocatable slave node, calculate the weight of each allocatable slave node, and select the allocatable slave node with the smallest weight as the shard allocation node.].
As per claim 2, Kai discloses the method of claim 1, wherein the processing system is configured to measure individual resource needs of the shards for selectively allocating the workload portions of the cluster or further resources, respectively, to individuals ones of the shards. [Para [0026], creating a shard on a shard allocation node is optimal, because at this time the shard allocation node must be the one with the lowest load among all currently allocable nodes.].
As per claim 3, Kai discloses the method of claim 1, wherein the workload comprises indexing, searching, and aggregations. [Para [0030], when creating a new index, it may be necessary to create multiple shards. The number of shards created is determined by the specific index creation requirements, and this number is defined as the preset number of shards. Since the CPU utilization and memory utilization of the shard allocation node will also change after a shard is created at the shard allocation node, when creating the next shard, it is necessary to return to S400, re-obtain the CPU utilization and memory utilization of each allocatable slave node, and then calculate the weight to allocate the next shard; Para [0031] In this embodiment, when creating a new index, the master node first considers the CPU and memory status of each available slave node before allocating a new shard. This can ensure that the new shard is allocated to the available slave node with the lowest combined CPU and memory utilization, avoiding the creation of the new shard on an already heavily loaded available slave node. This makes the Elasticsearch cluster run more evenly and stably.].
As per claim 4, Kai discloses the method of claim 1, wherein the plurality of measured parameters includes one or more of shard, node, or cluster-based: durable storage use or needs; indexing data; searching data; aggregation data; random access memory use or needs; times to perform tasks; thread data; refreshes; merges; read times; write times; processor statistics; or metadata relevant to any foregoing one of the parameters. [Para [0031], This can ensure that the new shard is allocated to the available slave node with the lowest combined CPU and memory utilization, avoiding the creation of the new shard on an already heavily loaded available slave node.].
As per claim 5, Kai discloses the method of claim 1, wherein the processing system is further configured to aggregate the plurality of measured parameters into statistics for use in predicting future allocations. [Para [0123], Specifically, since there is a possibility of obstacles to shard transfer, it is necessary to determine in this step whether the shard can be moved. The determination of whether a specified shard can be moved from a specified source node to a specified slave node is also determined by the cluster’s allocation policy and the cluster’s custom policy.].
As per claim 6, Kai discloses the method of claim 1, wherein the processing system is further configured to predict future resource needs for each of the shards according to the results from the plurality of measured parameters. [Para [0129], the updated shard allocation rules are stored in the shard status metadata and distributed to each slave node; Para [0130] Specifically, this step is the same as the distribution step mentioned in the previous embodiments, in order to let each slave node know about the transfer of this shard, so that it is convenient to retrieve the shard data in the future.].
As per claim 7, Kai discloses the method of claim 1, wherein the processing system is further configured to determine a target allocation of shards to the plurality of nodes in the cluster, wherein each of the shards is allocated resources from the cluster needed for the shard based on the respective workload portion. [Para [0022], the master node creates shard allocation rules based on the Elasticsearch cluster’s own allocation strategy and user-defined rules. The shard allocation rules determine which slave nodes can be allocated shards for the newly created index, and which slave nodes cannot or are not suitable for allocating shards for the newly created index.; Para [0026] Specifically, the CPU utilization status of an allocable slave node can be its CPU utilization rate. The memory utilization status of an allocable slave node can be its memory utilization rate. Weights can be calculated based on the CPU and memory utilization rates of the allocable slave nodes. The smaller the weight of an allocable slave node, the smaller the combined CPU and memory utilization rates, and the lower the load on the allocable slave node. The master node uses the allocable slave node with the smallest weight as the shard allocation node.].
As per claim 8, Kai discloses the method of claim 7, wherein the processing system is further configured to periodically reconcile a current allocation of shards in the cluster towards the target allocation. [Para [0027], create a shard at the shard allocation node; Para [0028] Specifically, creating a shard on a shard allocation node is optimal, because at this time the shard allocation node must be the one with the lowest load among all currently allocable nodes; Para [0030] Specifically, when creating a new index, it may be necessary to create multiple shards. The number of shards created is determined by the specific index creation requirements, and this number is defined as the preset number of shards. Since the CPU utilization and memory utilization of the shard allocation node will also change after a shard is created at the shard allocation node, when creating the next shard, it is necessary to return to S400, re-obtain the CPU utilization and memory utilization of each allocatable slave node, and then calculate the weight to allocate the next shard. This process is repeated.].
As per claim 9, Kai discloses the method of claim 7, wherein the processing system is further configured to revise the target allocation of the shards to another target allocation in response to identifying changes in the resources allocated from the cluster to one or more of the shards. [Para [0030], Specifically, when creating a new index, it may be necessary to create multiple shards. The number of shards created is determined by the specific index creation requirements, and this number is defined as the preset number of shards. Since the CPU utilization and memory utilization of the shard allocation node will also change after a shard is created at the shard allocation node, when creating the next shard, it is necessary to return to S400, re-obtain the CPU utilization and memory utilization of each allocatable slave node, and then calculate the weight to allocate the next shard. This process is repeated.].
As per claim 10, Kai discloses the method of claim 7, wherein the processing system is further configured to revise the target allocation of the shards to another target allocation in response to identifying changes in a workload of the cluster. [Para [0030], Specifically, when creating a new index, it may be necessary to create multiple shards. The number of shards created is determined by the specific index creation requirements, and this number is defined as the preset number of shards. Since the CPU utilization and memory utilization of the shard allocation node will also change after a shard is created at the shard allocation node, when creating the next shard, it is necessary to return to S400, re-obtain the CPU utilization and memory utilization of each allocatable slave node, and then calculate the weight to allocate the next shard. This process is repeated.].
As per claim 11, Kai discloses the method of claim 1, wherein the processing system is further configured to add or remove one or more of the plurality of nodes in the cluster while preserving sufficient resources for shards affected by the addition or removal. [Para [0031], In this embodiment, when creating a new index, the master node first considers the CPU and memory status of each available slave node before allocating a new shard. This can ensure that the new shard is allocated to the available slave node with the lowest combined CPU and memory utilization, avoiding the creation of the new shard on an already heavily loaded available slave node. This makes the Elasticsearch cluster run more evenly and stably.].
As per claim 12, Kai discloses the method of claim 1, wherein the processing system is further configured to adjust the resources allocated to each node while preserving sufficient resources for shards affected by the adjustment. [Para [0070], After step S400, the allocatable slave node with the lowest weight has been selected as the shard allocation node, so the allocation status information needs to be updated. The most important aspect of updating the allocation status information is updating the shard allocation rules. This is done to inform other slave nodes of the shard allocation result, allowing them to know which slave node the shard will be created on, facilitating subsequent data scheduling. The master node then sends the updated allocation status information to each allocatable slave node. During the update, other information about the Elasticsearch cluster is also updated.].
As per claim 13, Kai discloses the method of claim 1, wherein the processing system is further configured to adjust a strategy used to partition the workload of the cluster when the analysis shows that a new strategy will improve performance or reduce resources needed by the cluster or the plurality of nodes located therein. [Para [0002], Shard, also known as partitioning.; Para [0022], Specifically, if the master node receives a request to create an index from a client, it constructs shard allocation rules based on the request. Optionally, the master node creates shard allocation rules based on the Elasticsearch cluster’s own Allocation strategy and user-defined rules. The shard allocation rules determine which slave nodes can be allocated shards for the newly created index, and which slave nodes cannot or are not suitable for allocating shards for the newly created index.; Para [0127], if a specified shard can be transferred to a specified slave node, then update the shard allocation rules after the shard transfer.; Para [0129], the updated shard allocation rules are stored in the shard status metadata and distributed to each slave node.];
As per claim 17, Kai discloses the method of claim 1, wherein the resources include at least one of:
one or more central processing units (CPUs) or hardware computational resources; [Para [0064], each new shard is allocated on the allocable slave node with the lowest combined CPU utilization and memory utilization.];
durable storage; [Para [0125], the shard data is stored in shared memory, so there is no need to copy the data. Only one shard data storage space is needed, which greatly saves storage space.];
random access memory (RAM); [Para [0064], each new shard is allocated on the allocable slave node with the lowest combined CPU utilization and memory utilization.];
cache memory; [Para [0066], Distribute allocation status information to each allocatable slave node. The allocation status information includes shard allocation rules.];
or network resources. [Para [0019], the master node server (hereinafter referred to as the “master node”) in the shard allocation system determines whether it has received a request to create an index from the client. An Elasticsearch cluster may include one master node server (hereinafter referred to as the “master node”) and multiple slave node servers (hereinafter referred to as “slave nodes”). The Elasticsearch cluster also includes a shared storage for storing the shard data of all nodes. Shard data is stored in the form of files.];
Claims 18 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Shah; Premal et al. (US 20170097854 A1).
As per claim 18, Shah; Premal discloses a system for a distributed search engine, comprising:
a cluster comprising a plurality of networked nodes, the cluster having a workload assigned to shards in portions across the nodes; and [Para [0010] Fig. 1, Fig. 1 is a block diagram illustrating a system for scheduling a plurality of threads for execution on a cluster of a plurality of clusters in accordance with one or more embodiments.; Para [0014], related threads may be split to execute on different processors and different clusters.];
at least one master node including a processing system configured to periodically analyze the cluster based on a plurality of measured parameters, and to use results of the analysis to: [Para [0020], computing nodes 112A-112D of cluster 110 are a first set of processors, and computing nodes 116A-116D of cluster 114 is a second set of processors. In some examples, each computing node in a given cluster shares an execution shares an execution resource with other computing nodes in the given cluster, but not with the computing nodes in another cluster.];
reallocate shards across the nodes when needed to improve performance or efficiency; allocate or reconfigure the workload portions among one or more of the shards, and selectively allocate or reconfigure resources to the shards sufficiently to support respective workload portions. [Para [0033], As shown in Fig. 1, the OS kernel 104 includes a scheduler 106 that schedules threads for execution on a plurality of clusters (e.g., cluster 110 and/or cluster 114.) In operation, the scheduler 106 receives threads from the application layer framework 109 and may determine on which cluster of the plurality of clusters to schedule the threads for execution. In an example, scheduler 106 receives the first thread 126 and the second thread 128 and determines, based on their markings, that they are related. Scheduler 106 may identify dependencies of the threads. For example, scheduler 106 may recognize that first thread 126 calls and passes data to second thread 128.].
Claims 20 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Goren; Avi et al. (US 11726827 B2).
As per claim 20, Goren; Avi discloses a method for auto-managing a cluster, comprising:
assigning a workload to shards in respective portions across a cluster, the cluster comprising a plurality of networked nodes; [Page 4, The method is hierarchical in the sense that is uses workload allocation units that may include one or more second type shards and one or more first type shards. The workload allocation process may maintain a workload allocation unit-but may change its content-for example by reallocating one or more first type shard and/or second type shard to another workload allocation unit; Page 13 A compute node 110 is configured to perform tasks related to the management of the storage nodes 120. In an embodiment, each compute node 110 interfaces with a client device 140 (or an application installed therein) via a network 150.].
initially allocating the shards across the nodes in the cluster; [Page 3, When the storage system is installed, the number of 25 second type shards is determined according to the storage system size, e.g., according to the number of central processing units or the amount of storage space of the storage system.].
periodically analyzing the cluster based on a plurality of measured parameters; [Page 4, The number of the first type shards may be determined so 30 as to fit any size of future scale out of the storage system, therefore the number of first type shard may exceed the second type shards in an initial installation, as well as in subsequent scale-out configurations.].
based on results of the analyses, auto-scaling the cluster, the auto-scaling comprising (1) reallocating the shards across the nodes when needed to improve performance or resource efficiency, (2) adding or removing one or more of the nodes when needed to correlate the cluster with the workload, and (3) allocating or reconfiguring the workload portions among one or more of the shards when needed to balance the cluster; and (4) selectively allocating or reconfiguring resources to the shards sufficient to support the respective workload portions. [Page 3, The number of workload allocation units may be correlated to the number of second type shards, and may be, as well, determined according to the storage system size, e.g., according to the number of central processing units or the amount of storage space of the storage system. When the storage system is scaled out, new compute nodes that include new compute cores (e.g., CPUs) are added.].
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:
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.
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 14, 15, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kai et al. (CN 113568749 B) and Goren; Avi et al. (US 11726827 B2)..
As per claim 14, Kai discloses the method of claim 1 as detailed above.
Kai discloses the auto-scaling comprising adding or removing nodes based on … (ii) actual or anticipated indexing needs of the cluster. [From Kai Para [0123], Specifically, since there is a possibility of obstacles to shard transfer, it is necessary to determine in this step whether the shard can be moved. The determination of whether a specified shard can be moved from a specified source node to a specified slave node is also determined by the cluster’s Allocation policy and the cluster’s custom policy.].
However, Kai does not explicitly teach the auto-scaling comprising adding or removing nodes based on (i) actual or anticipated storage needs of the cluster as required by the claim.
Goren discloses the auto-scaling comprising adding or removing nodes based on (i) actual or anticipated storage needs of the cluster as required by the claim [From Goren Page 3, The number of workload allocation units may be correlated to the number of second type shards, and may be, as well, determined according to the storage system size, e.g., according to the number of central processing units or the amount of storage space of the storage system. When the storage system is scaled out, new compute nodes that include new compute cores (e.g., CPUs) are added.].
Both Kai and Goren are in the same field of endeavor and they are both in the program control and, therefore, are combinable/modifiable.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Kai with the teachings of Goren in order to configure an orchestrator to auto-scale the cluster based on storage and indexing needs of the cluster.
Modification would optimize operation of the system because if the workload is not balanced, then some CPUs may not be assigned with workload allocation units as taught by Goren [Page 3].
As per claim 15, Kai discloses the method of claim 14, wherein the orchestrator is further configured to auto-scale the cluster based on the amount of random access memory (RAM) needed for the shards. [Para [0070], the allocatable slave node with the lowest weight has been selected as the shard allocation node, so the allocation status information needs to be updated. The most important aspect of updating the allocation status information is updating the shard allocation rules. This is done to inform other slave nodes of the shard allocation result, allowing them to know which slave node the shard will be created on, the facilitating subsequent data scheduling. The master node then sends the updated allocation status information to each allocatable slave node. During the update, other information about the Elasticsearch cluster is also updated.; Para [0071], sending allocation status information to each allocatable slave node helps other slave nodes know which slave node the shard will be created on, facilitating subsequent data scheduling by other slave nodes. Subsequently, the master node sends updated allocation status information to each allocatable slave node.; Para [0051], Wherein, WEIGHT is the CPU weight of the allocable slave node. Weight is the memory weight of the allocable slave node. RATIO is the current CPU utilization of the allocable slave node. RATIO is the current memory utilization of the allocable slave node.].
As per claim 16, the claim is rejected using the same rationale as noted above for claim 15.
As per claim 19, the claim is rejected using the same rationale as noted above for claim 14.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CN 113760446 A to Fan J et al. teaches a resource scheduling method. The method includes obtaining parameter information of resource objects based on the resource requests for creating one or more objects, then determining a first resource sequence based on the resource specifications and a cluster monitoring database.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YAZAN A ALSHOROOGI whose telephone number is (571)270-0893. The examiner can normally be reached Monday - Friday 8am-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, Stephanie Ziegle can be reached at (571) 272-4417. 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.
June 25, 2026
/YAZAN ABDELNASER ALSHOROOGI/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights