Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Chanler (USPN 20240111606A1).
As per claim 1, Chanler et al. discloses a system, comprising: one or more processors (paragraph 0021 – processor devices); and one or more non-transitory computer readable media storing instructions which, when executed by the one or more processors (paragraph 0021 - computer-executable instructions on a non-transitory tangible computer-readable medium), cause the one or more processors to:
receive, at a framework daemon of a workload execution framework that executes on a first node of a set of nodes assigned by a workload manger to execute a workload, an indication to begin execution of the workload, wherein the workload is divided into a plurality of execution units; access, by the framework daemon and in response to the indication, an execution context that comprises the plurality of execution units (paragraph 0038 - FIG. 2 is a functional block diagram of an example cluster 250 of nodes 240 configured to share workload tasks in a storage system, according to some embodiments. As shown in FIG. 2, in some embodiments the cluster includes a plurality of nodes 2401-240N. Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the framework daemon is the work striping process; the execution units are the workload tasks);
claim, by the framework daemon, a first execution unit of the plurality of execution units for execution by the first node by associating a first identifier of the first node with the first execution unit; execute, by the first node, the first execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster.; nodes are identified by an identifier);
determine, by the framework daemon and after the first node completes execution of the first execution unit, whether the execution context comprises a second execution unit of the plurality of execution units that is unclaimed by accessing the execution context ((paragraph 0038 - Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the unclaimed executions are the workload tasks that need to be processed);
claim, by the framework daemon and when the determination is that the execution context comprises the unclaimed second execution unit, the second execution unit for execution by the first node by associating the first identifier of the first node with the second execution unit; and execute, by the first node, the second execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster. – this is for each execution unit/workload task that needs to be processed; nodes are identified by an identifier).
As per claims 4,11,18, Chanler et al. discloses wherein execution of the workload is complete when each node of the set of nodes has entered a barrier state and each execution unit of the plurality of execution units has been executed by the set of nodes (paragraph 0061 - When a cluster is operating, and a node seeks to join the cluster, the current nodes in the cluster will have been assigning workload requests using the striping algorithm based on the previous node membership. To ensure that any outstanding previous requests that are active are drained/completed, in some embodiments the joining node sends a fence-work-request to each of the other nodes (block 610). The other nodes insert the fence work request into their local work queue and, once the other work ahead of the fence work request has been drained/completed, respond to the joining node with a fence work acknowledgment message (block 620).).
As per claims 5,12,19, Chanler et al. discloses wherein the workload execution framework further comprises a framework monitor, and execution of the instructions further causes the one or more processors to: monitor, by the framework monitor, execution of the workload on the set of nodes; and adjust, based on the monitoring, a number of nodes comprised in the set of nodes by sending a scaling request to a workload manager (paragraph 0037 - In some embodiments, the metadata services subsystem 155 is implemented using a cluster 250 of nodes 240, in which each node 240 participates as a node in the cluster 250. As workload tasks are received by the metadata services subsystem 155, the workload tasks are deterministically allocated for processing by one of the nodes of the cluster using a striping algorithm. Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events. As the cluster membership changes, a distributed cluster join management process is implemented that is configured to ensure that workload tasks are not able to be allocated to more than one cluster node for processing. Although some embodiments of the distributed cluster join management process will be described using a metadata services subsystem as a reference system, it should be understood that the distributed cluster join management process can be used in other contexts as well.).
As per claims 6,13, Chanler et al. discloses wherein the scaling request comprises an increase request (paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events.).
As per claims 7,14, Chanler et al. discloses wherein the scaling request comprises a remove request (paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events.).
As per claim 8, Chanler et al. discloses a computer-implemented method, comprising: receiving, at a framework daemon of a workload execution framework that executes on a first node of a set of nodes assigned by a workload manger to execute a workload, an indication to begin execution of the workload, wherein the workload is divided into a plurality of execution units; accessing, by the framework daemon and in response to the indication, an execution context that comprises the plurality of execution units (paragraph 0038 - FIG. 2 is a functional block diagram of an example cluster 250 of nodes 240 configured to share workload tasks in a storage system, according to some embodiments. As shown in FIG. 2, in some embodiments the cluster includes a plurality of nodes 2401-240N. Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the framework daemon is the work striping process; the execution units are the workload tasks);
claiming, by the framework daemon, a first execution unit of the plurality of execution units for execution by the first node by associating a first identifier of the first node with the first execution unit; executing, by the first node, the first execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster.; nodes are identified by an identifier);
determining, by the framework daemon and after the first node completes execution of the first execution unit, whether the execution context comprises a second execution unit of the plurality of execution units that is unclaimed by accessing the execution context ((paragraph 0038 - Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the unclaimed executions are the workload tasks that need to be processed);
claiming, by the framework daemon and when the determination is that the execution context comprises the unclaimed second execution unit, the second execution unit for execution by the first node by associating the first identifier of the first node with the second execution unit; and executing, by the first node, the second execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster. – this is for each execution unit/workload task that needs to be processed; nodes are identified by an identifier).
As per claim 15, Chanler et al. discloses a non-transitory computer-readable medium storing programming for execution by one or more processors, the programming comprising instructions (paragraph 0021 - computer-executable instructions on a non-transitory tangible computer-readable medium; processor devices) to: receive, at a framework daemon of a workload execution framework that executes on a first node of a set of nodes assigned by a workload manger to execute a workload, an indication to begin execution of the workload, wherein the workload is divided into a plurality of execution units; access, by the framework daemon and in response to the indication, an execution context that comprises the plurality of execution units (paragraph 0038 - FIG. 2 is a functional block diagram of an example cluster 250 of nodes 240 configured to share workload tasks in a storage system, according to some embodiments. As shown in FIG. 2, in some embodiments the cluster includes a plurality of nodes 2401-240N. Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the framework daemon is the work striping process; the execution units are the workload tasks);
claim, by the framework daemon, a first execution unit of the plurality of execution units for execution by the first node by associating a first identifier of the first node with the first execution unit; execute, by the first node, the first execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster.; nodes are identified by an identifier);
determine, by the framework daemon and after the first node completes execution of the first execution unit, whether the execution context comprises a second execution unit of the plurality of execution units that is unclaimed by accessing the execution context ((paragraph 0038 - Each node 240 receives workload requests from other processes executing on the storage system 100, adds the workload requests to their local workload queue, and uses a work striping process 200 to determine which active node 240 of the cluster 250 (dashed box in FIG. 2) should process the particular workload request. – the unclaimed executions are the workload tasks that need to be processed);
claim, by the framework daemon and when the determination is that the execution context comprises the unclaimed second execution unit, the second execution unit for execution by the first node by associating the first identifier of the first node with the second execution unit; and execute, by the first node, the second execution unit (paragraph 0039 - Where a node 240 determines that it should process the particular workload request, the node 240 processes the workload request. Where the node 240 determines that another node should process the workload request, it sends (arrows 260) the workload request to the node identified using the work striping process 200 and removes the work from the local workload queue. When the other node receives the workload request, adds the workload request to its local workload queue, locally runs the striping algorithm to determine if it is responsible for the workload request, and if the receiving node determines that it is responsible for the workload request, it processes the workload request. In some embodiments, the node includes an inter-node work messaging system 205 to enable workload requests to be sent between nodes of the cluster. – this is for each execution unit/workload task that needs to be processed; nodes are identified by an identifier).
As per claim 20, Chanler et al. discloses wherein the scaling request comprises at least one of: an increase request; and a remove request (paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events.).
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) 2,3,9,10,16,17 are rejected under 35 U.S.C. 103 as being unpatentable over Chanler et al. in view of Parthasarathy et al. (USPN 20200026624A1).
As per claims 2,9,16, Chanler et al. discloses send, in response to determining that the second node has failed, a second indication to respective framework daemons of non-failed nodes of the set of nodes that the second node has failed, wherein the second indication comprises a second identifier of the second node; successfully disassociate, by one framework daemon of the respective framework daemons and in response to the second indication, the second node from any execution unit comprised in the execution context (paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events. As the cluster membership changes, a distributed cluster join management process is implemented that is configured to ensure that workload tasks are not able to be allocated to more than one cluster node for processing.; paragraph 0075 - in some embodiments when a node leaves the cluster, an atomic clear bit operation will be implemented on the global cluster membership bitmap 305 (block 1000). This resets the bit for the node in the global cluster membership bitmap 305. The node that implemented the atomic clear bit operation sends an update request message to all of the remaining nodes of the cluster (block 1005). The node that implemented the atomic reset operation for the node that is leaving the cluster will also implement an update local cluster membership bitmap algorithm of FIG. 5 to update its local cluster membership bitmap 315 based on the new global cluster membership bitmap 305 (block 1010)).
Chanler et al. fails to explicitly state determine, by a framework monitor of the workload execution framework, that a second node of the set of nodes that is executing the workload has failed; by the framework monitor.
Chanler et al. does disclose in paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events. As the cluster membership changes, a distributed cluster join management process is implemented that is configured to ensure that workload tasks are not able to be allocated to more than one cluster node for processing.; paragraph 0075 - in some embodiments when a node leaves the cluster, an atomic clear bit operation will be implemented on the global cluster membership bitmap 305 (block 1000). This resets the bit for the node in the global cluster membership bitmap 305. The node that implemented the atomic clear bit operation sends an update request message to all of the remaining nodes of the cluster (block 1005). The node that implemented the atomic reset operation for the node that is leaving the cluster will also implement an update local cluster membership bitmap algorithm of FIG. 5 to update its local cluster membership bitmap 315 based on the new global cluster membership bitmap 305 (block 1010).
Parthasarathy et al. discloses determine, by a framework monitor of the workload execution framework, that a second node of the set of nodes that is executing the workload has failed; by the framework monitor (paragraph 0045 - The configuration manager tracks system resources to record certain details pertaining to each resource in resource registry 228. In one example embodiment, the configuration manager 226 within leader node 240 can employ monitoring services, such as a failure detection agent. Two or more configuration managers might run on multiple nodes in the distributed computing system to maintain high reliability access to the resource registry.; paragraph 0049 - On an ongoing basis, tasks are monitored and failures are detected. Techniques for detecting processing environment failures is shown and described as pertaining to FIG. 3A and FIG. 3B.).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include monitoring for a failure by a fault detection agent of Parthasarathy in the detecting a failure and replacing/adding nodes of Chanler. A person of ordinary skill in the art would have been motivated to make the modification because detecting an error invoked redistribution actions as disclosed in paragraph 0023.
As per claims 3,10,17, Chanler et al. send, by the one framework daemon of the respective framework daemons that successfully disassociated the second node from any execution unit comprised in the execution context, a scaling request comprising a replace request to a workload manager (paragraph 0037 - Nodes 240 can be added to the cluster 250, for example in connection with expansion events, and can also be removed from the cluster 250 temporarily, for example in connection with failure events or upgrade/maintenance events. As the cluster membership changes, a distributed cluster join management process is implemented that is configured to ensure that workload tasks are not able to be allocated to more than one cluster node for processing.; paragraph 0075 - in some embodiments when a node leaves the cluster, an atomic clear bit operation will be implemented on the global cluster membership bitmap 305 (block 1000). This resets the bit for the node in the global cluster membership bitmap 305. The node that implemented the atomic clear bit operation sends an update request message to all of the remaining nodes of the cluster (block 1005). The node that implemented the atomic reset operation for the node that is leaving the cluster will also implement an update local cluster membership bitmap algorithm of FIG. 5 to update its local cluster membership bitmap 315 based on the new global cluster membership bitmap 305 (block 1010)).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Yolanda L Wilson whose telephone number is (571)272-3653. The examiner can normally be reached M-F (7:30 am - 4 pm).
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, Bryce Bonzo can be reached at 571-272-3655. 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.
/Yolanda L Wilson/Primary Examiner, Art Unit 2113