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 .
Claims 1-59 are pending in this application.
Information Disclosure Statement
The IDS’s filed on 12/15/2023, 1/9/2025, 2/19/2025, 5/6/2025, 5/22/2025, and 7/18/2025 have been considered.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 5-8, 10, 13-22, 27-32, 35-38, 40, 43-52, and 57-59 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Branscome et al. (US Pub. No. 2012/0054236 A1 hereinafter Branscome *cited in IDS*).
As per claim 1, Branscome teaches a computer-implemented method comprising: selecting an execution resource from a set of execution resources of a virtual machine (VM), the execution resource for executing a VM instruction (¶ [0035]-[0036], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs. In the embodiments, a QSM may comprise a base server (herein a BSM), i.e., a general-purpose computer or server, which is configured with software to implement the QSM virtual machine.”); transforming the VM instruction into machine code for the execution resource selected (¶ [0105]-[0106], “Query and plan manager 402 analyzes and represents the parsed query received from the MySQL software 114, annotates the query, and provides an annotation graph representation of the query plan. Query reduction/rewrite module 404 breaks the query into query fragments and rewrites the query fragments into tasks. Rewrites may be needed for compressed domain rewrites and machine code database instruction operator rewrites…These modules interact with each other to determine how to execute a query, such as a SQL query from MySQL software 114…Once a parsed SQL query has been represented in this data structure (converted, for example, from MySQL), query and plan manager 402 rewrites the query such that each fragment of the query can be done entirely in MySQL software 114, in C2 software 110, or in QPM module 204. Once the final query representation is available, the rewrite module 404 goes through and breaks the graph into query fragments.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM.”); and executing the machine code via the execution resource selected, the executing furthering execution by the VM of a dataflow graph including at least one compute node (¶ [0081], “Nodes 106a-n may be any set of devices, including hardware and software that assist in the processing of queries by system 100.” ¶ [0090], “In particular, C2 software 110 may decompose a query into a set of query fragments. Each fragment comprises various tasks, which may have certain dependencies. C2 software 110 may determine which fragments and tasks are part of the fast path portion and offload them to one of the QPM module 204a-n. Appropriate tasks for the selected query fragments are sent to QPM modules 204a-n with information on the database operation dependency graph. Within the QPM modules 204a-n, tasks are further broken down into parallel/pipelined machine code operations (known as MOPs) and executed in hardware.” See also para. 0086-0087.), a compute node of the at least one compute node having a set of VM instructions including the VM instruction (¶ [0098]-[0101], “FIG. 2B illustrates a hybrid node 106n. As shown, node 106 may comprise a single BSM 202, multiple QPM modules 204a-n, and one or more QSM modules 206a-n. In some embodiments, BSM 202, QPM modules 204a-n, and QSM modules 206a-n are coupled together over a known communications interface, such as a PCIe or HyperTransport (HT) interface. As can be seen, hybrid node 106n differs from a multi-QPM node in that comprises QSM modules 206a-n. As noted, QSM modules 206a-n may be software-based modules that are coupled to hybrid node 106n. This architecture allows hybrid node 106n to handle various types of queries that are better suited for software rather than hardware acceleration. FIG. 2C illustrates a multi-QSM node. As shown, the node may comprise a single BSM and multiple QSM modules…As noted, QSM modules may be software-based modules that are coupled to the BSM. As will be recognized by those skilled in the art, any of the QSMs may be executing on the same underlying hardware platform or may be executing on different hardware platforms and coupled together via a communications interface. This architecture allows the multi-QSM node to handle various types of queries that are better suited for software rather than hardware acceleration while employing a clustered approach to these queries or tasks.”), the dataflow graph corresponding to at least a portion of a computation workload associated with a user data query (¶ [0125], “For example, in some embodiments, a QSM may run MySQL software and interface C2 software 110 in the BSM 202. In particular, C2 software 110 may decompose a query into a set of query fragments. Each fragment comprises various tasks, which may have certain dependencies. C2 software 110 may determine which fragments and tasks offloaded to one of the QPM module 204a-n or the QSM. Appropriate tasks for the selected query fragments are sent to the QSM with information on the database operation dependency graph.”), an output of the execution of the dataflow graph: (i) representing a result of processing the at least a portion of the computation workload and (ii) contributing to a response to the user data query (¶ [0111], “Answer manager 422 is responsible for compiling the results of the query fragments and providing the result to MySQL software 114 via the API 116.” ¶ [0164], “There are two ways a virtual processor is able to obtain results from the accelerator. The results can be pulled by a processor or pushed to the processor by invoking a callback. A callback may be a general-purpose abstraction for result retrieval.”).
As per claim 2, Branscome teaches the method of claim 1. Branscome also teaches wherein the selecting is based on at least one of: (i) a respective efficiency of executing the VM instruction at each execution resource of the set of execution resources and (ii) a respective availability of each execution resource of the set of execution resources (¶ [0061], “In other embodiments, query execution planning can be based on the use of multiple hardware accelerators. In some embodiments, algorithms for utilizing multiple QPMs take advantage of their bulk processing capability.” ¶ [0105], “Query reduction/rewrite module 404 breaks the query into query fragments and rewrites the query fragments into tasks. Rewrites may be needed for compressed domain rewrites and machine code database instruction operator rewrites. Optimizer 406 performs cost-based optimization to be done using cost model of resources available to C2 software 110, i.e., QPM module 204, resources of C2 software 110 itself using software operations, or MySQL software 114.” See also para. 0128.).
As per claim 5, Branscome teaches the method of claim 1. Branscome also teaches wherein selecting the resource is based on the execution resource including an accelerator (¶ [0142], “On the query processing, the RDBMS sends a QF to be executed in the accelerator based on query operation cost and types. A QF contains one or more SQL operations, structured in a dataflow graph.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM.”).
As per claim 6, Branscome teaches the method of claim 1. Branscome also teaches wherein selecting the execution resource is based on the execution resource including a programmable dataflow unit (PDU) based accelerator, a graphics processing unit (GPU) based accelerator, a tensor processing core (TPC) based accelerator, a tensor processing unit (TPU) based accelerator, a single instruction multiple data (SIMD) unit based accelerator, a central processing unit (CPU) based accelerator, another type of accelerator, or a combination thereof (¶ [0061], “In other embodiments, query execution planning can be based on the use of multiple hardware accelerators. In some embodiments, algorithms for utilizing multiple QPMs take advantage of their bulk processing capability.” ¶ [0066], “In the C2 solution, a node or appliance may comprise the host (or base) system that is combined with a query processor module (QPM). These QPMs may comprise one or more hardware accelerated reconfigurable processors (HARP). These HARPs in a QPM are specially designed to optimize the performance of database systems and its applications, especially relational database systems and read-intensive applications.”).
As per claim 7, Branscome teaches the method of claim 1. Branscome also teaches wherein the compute node is a first compute node, and wherein the computer-implemented method further comprises: processing, via the first compute node, a first data block associated with the at least a portion of the computation workload (¶ [0038], “Moreover, processing flows may be shared between multiple QPMs and QSMs. For example, the processing output of a first QPM may be fed to a second QPM or a QSM, and vice versa. In one embodiment, a system implements a shared flow among the dataflow processing elements, such that any given query processing resource, i.e., a QPM or QSM, may transmit its flow to at least one of any other query processing resource.” ¶ [0054]-[0055], “In the embodiments, the resources of the system may be pipelined. That is, processing resources, i.e., QSMs or QPMs, may be configured in a sequence, so that the output of one resource as the input of the next resource and so forth. Pipelining may occur between software resources, i.e., QSM-QSM, hardware resource, i.e., QPM-QPM, and mixed resources, such as QSM-QPM or QPM-QSM. Software system pipelining such that multiple QPMs can transfer multiple dataflows to a QSM, and/or a QSM can transfer multiple dataflows to multiple QPMs.”), the processing performed in parallel with at least one of: (i) processing, via a second compute node of the at least one compute node, a second data block associated with the at least a portion of the computation workload and (ii) transferring, via an edge of a set of edges associated with the dataflow graph, the second data block associated with the at least a portion of the computation workload (¶ [0127]-[0131], “Each node in the shown MOP plan represents a MOP, or a sub-graph of multiple MOPs. Each directed edge of the graph represents at least one flow of execution data from the producer node to at least one consumer node. Without a loss of generality, one skilled in the art will understand that a "node" may be a MOP, a collection of MOPs, a subtree of the DAG, and the like…In such parallelism, the nodes may cooperate according to producer-consumer relationships established by the data flows. That is, each consumer node receives and processes its input(s) as the data arrives from its associated producer node(s). This chaining forms a pipeline, which can maintain a high execution throughput rate.”).
As per claim 8, Branscome teaches the method of claim 1. Branscome also teaches controlling a flow of data blocks between at least two dataflow nodes of the dataflow graph, the at least two dataflow nodes including the at least one compute node, the data blocks (i) associated with the at least a portion of the computation workload and (ii) derived from a data source associated with the user data query (¶ [0038], “Moreover, processing flows may be shared between multiple QPMs and QSMs. For example, the processing output of a first QPM may be fed to a second QPM or a QSM, and vice versa. In one embodiment, a system implements a shared flow among the dataflow processing elements, such that any given query processing resource, i.e., a QPM or QSM, may transmit its flow to at least one of any other query processing resource.” ¶ [0054]-[0055], “In the embodiments, the resources of the system may be pipelined. That is, processing resources, i.e., QSMs or QPMs, may be configured in a sequence, so that the output of one resource as the input of the next resource and so forth. Pipelining may occur between software resources, i.e., QSM-QSM, hardware resource, i.e., QPM-QPM, and mixed resources, such as QSM-QPM or QPM-QSM. Software system pipelining such that multiple QPMs can transfer multiple dataflows to a QSM, and/or a QSM can transfer multiple dataflows to multiple QPMs.” See also para. 0125-0129.).
As per claim 10, Branscome teaches the method of claim 1. Branscome also teaches generating a set of edges associated with the dataflow graph, each edge of the set of edges configured to transfer data blocks between a corresponding pair of dataflow nodes of the dataflow graph, the dataflow nodes including the at least one compute node (¶ [0127]-[0131], “Each node in the shown MOP plan represents a MOP, or a sub-graph of multiple MOPs. Each directed edge of the graph represents at least one flow of execution data from the producer node to at least one consumer node. Without a loss of generality, one skilled in the art will understand that a "node" may be a MOP, a collection of MOPs, a subtree of the DAG, and the like…In such parallelism, the nodes may cooperate according to producer-consumer relationships established by the data flows. That is, each consumer node receives and processes its input(s) as the data arrives from its associated producer node(s). This chaining forms a pipeline, which can maintain a high execution throughput rate.”).
As per claim 13, Branscome teaches the method of claim 10. Branscome also teaches wherein the generating includes: configuring an edge of the set of edges to synchronize a first processing speed of a first compute node of the at least one compute node with a second processing speed of a second compute node of the at least one compute node (¶ [0127]-[0131], “Each directed edge of the graph represents at least one flow of execution data from the producer node to at least one consumer node. Without a loss of generality, one skilled in the art will understand that a "node" may be a MOP, a collection of MOPs, a subtree of the DAG, and the like…The QPMs may be connected via a network interconnect allowing any QPM to share its execution flows with at least one other QPM, in a dynamically configurable manner. This feature facilitates the flow transfer of the original MOP plan, for example, between tasks T0 and T1, T0 and T2, T1 and T4, and so on…Lastly, FIG. 7 illustrates pipelined parallelism in executing simultaneously across multiple QPMs. In such parallelism, the nodes may cooperate according to producer-consumer relationships established by the data flows. That is, each consumer node receives and processes its input(s) as the data arrives from its associated producer node(s). This chaining forms a pipeline, which can maintain a high execution throughput rate.”).
As per claim 14, Branscome teaches the method of claim 1. Branscome also teaches wherein the executing includes: performing at least one of: an input control function, a flow control function, a register control function, an output control function, a reduce function, a map function, a load function, and a generate function (¶ [0113], “In some embodiments, update manager 424 supports snapshot versioning is to support Query-While-Load operations. In snapshot versioning, logically each row has creation/deletion timestamp. This timestamp can be represented as using a snapshot version number ("svn"). An "UPDATE" operation is atomically converted into DELETE followed by INSERT.” See also Table 4 on pg. 10.).
As per claim 15, Branscome teaches the method of claim 1. Branscome also teaches wherein the executing includes: executing the VM instruction via a software-based execution unit, a hardware-based execution unit, or a combination thereof (¶ [0029], “The embodiments may then use hardware execution resources or software execution resources to process the query. The hardware execution resources, referred to as query processing modules (QPMs), may utilize database machine code instructions known as MOPs to perform a particular task of a query. The software execution resources, referred to as query software modules (QSMs), are implemented in software and may utilize software operations known as SOPs to perform their tasks of the query.”).
As per claim 16, Branscome teaches the method of claim 1. Branscome also teaches wherein the dataflow graph includes at least one input node, and wherein the computer-implemented method further comprises: obtaining, based on an input node of the at least one input node, at least one data block from a data source associated with the user data query (¶ [0131], “In such parallelism, the nodes may cooperate according to producer-consumer relationships established by the data flows. That is, each consumer node receives and processes its input(s) as the data arrives from its associated producer node(s). This chaining forms a pipeline, which can maintain a high execution throughput rate. This feature is exemplified in FIG. 7, for example, by the data flows from QPMs Q0, Q1, and Q2 to QPM Qi, where T1 executes, and to QPM Qj, where T2 executes, which have been established both to fulfill the (functional) MOP plan data flow requirements, and to establish a pipeline through which producers and consumers may work simultaneously.”).
As per claim 17, Branscome teaches the method of claim 16. Branscome also teaches wherein the obtaining includes: implementing a read protocol corresponding to the data source (¶ [0073], “For example, the C2 solution utilizes a global virtual address space for the entire database to greatly simplify and maximize efficiency of create, read, update, and delete operations of data in a database.”).
As per claim 18, Branscome teaches the method of claim 1. Branscome also teaches wherein the dataflow graph includes at least one output node, and wherein the computer-implemented method further comprises: storing, based on an output node of the at least one output node, at least one data block to a datastore (¶ [0038], “For example, the processing output of a first QPM may be fed to a second QPM or a QSM, and vice versa. In one embodiment, a system implements a shared flow among the dataflow processing elements, such that any given query processing resource, i.e., a QPM or QSM, may transmit its flow to at least one of any other query processing resource.” ¶ [0053]-[0054], “Hierarchical aggregation that permits partial aggregation of results and where the results are transferred (utilizing hardware system pipelining) from one QPM or host to another QPM or host and further aggregated so as to minimize the number of transfers required. Hardware task pipelining permits any individual QPM to execute a query plan operation over distinct portions of database data that implements STMD and MTMD. In the embodiments, the resources of the system may be pipelined. That is, processing resources, i.e., QSMs or QPMs, may be configured in a sequence, so that the output of one resource as the input of the next resource and so forth. Pipelining may occur between software resources, i.e., QSM-QSM, hardware resource, i.e., QPM-QPM, and mixed resources, such as QSM-QPM or QPM-QSM.”).
As per claim 19, Branscome teaches the method of claim 18. Branscome also teaches wherein the storing includes: implementing a write protocol corresponding to the datastore (¶ [0073], “For example, the C2 solution utilizes a global virtual address space for the entire database to greatly simplify and maximize efficiency of create, read, update, and delete operations of data in a database.” ¶ [0142], “A QF contains one or more SQL operations, structured in a dataflow graph. The second component handles bulk loading (initial load, incremental insert/delete/update), trickle updates from DML, and transaction-related operations.”).
As per claim 20, Branscome teaches the method of claim 1. Branscome also teaches spawning at least one task corresponding to at least one of: (i) the at least one compute node, (ii) at least one input node of the dataflow graph, (iii) at least one output node of the dataflow graph, and (iv) at least one edge associated with the dataflow graph (¶ [0038], “For example, the processing output of a first QPM may be fed to a second QPM or a QSM, and vice versa. In one embodiment, a system implements a shared flow among the dataflow processing elements, such that any given query processing resource, i.e., a QPM or QSM, may transmit its flow to at least one of any other query processing resource.” ¶ [0053]-[0054], “Hierarchical aggregation that permits partial aggregation of results and where the results are transferred (utilizing hardware system pipelining) from one QPM or host to another QPM or host and further aggregated so as to minimize the number of transfers required. Hardware task pipelining permits any individual QPM to execute a query plan operation over distinct portions of database data that implements STMD and MTMD. In the embodiments, the resources of the system may be pipelined. That is, processing resources, i.e., QSMs or QPMs, may be configured in a sequence, so that the output of one resource as the input of the next resource and so forth. Pipelining may occur between software resources, i.e., QSM-QSM, hardware resource, i.e., QPM-QPM, and mixed resources, such as QSM-QPM or QPM-QSM.”).
As per claim 21, Branscome teaches the method of claim 20. Branscome also teaches wherein a task of the at least one task spawned includes a thread corresponding to the compute node, and wherein the computer-implemented method further comprises: executing the set of VM instructions via the thread (¶ [0029], “The hardware execution resources, referred to as query processing modules (QPMs), may utilize database machine code instructions known as MOPs to perform a particular task of a query. The software execution resources, referred to as query software modules (QSMs), are implemented in software and may utilize software operations known as SOPs to perform their tasks of the query.” ¶ [0042]-[0043], “As shown, MOP threads may participate fairly in accessing index memory and execution. Data can be executed fairly by availability, e.g, in a non-blocking fashion. Furthermore, in some embodiments, MOP threads may prefetch with dataflow locality and MOP threads may lookahead. In various embodiments, packed nodes contain relevant RIDs and no additional index locality is required or assumed.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM. In a conventional RDBMS implementation, this query plan is a single operation (e.g., scan, join, etc.) at a time.”).
As per claim 22, Branscome teaches the method of claim 20. Branscome also teaches further comprising monitoring execution of a task of the at least one task spawned (¶ [0112], “Shared utilities 426 provide various utilities for the components of C2 software 110. For example, these shared utilities may include a performance monitor, a metadata manager, an exception handler, a compression library, a logging and recovery manager, and a bulk/incremental loader.” See also para. 0189.).
As per claim 27, Branscome teaches the method of claim 1. Branscome also teaches further comprising: generating, based on the dataflow graph, a plurality of dataflow subgraphs; and configuring at least two dataflow subgraphs of the plurality of dataflow subgraphs to, when executed via the VM, perform a data movement operation in parallel (¶ [0060], “Hardware system pipelining enables multiple live dataflow transmission from one QPM to multiple QPMs, and/or from multiple hosts to a QPM, and/or from multiple QPM to a host to implement SPSF (and MPSF or MPMF), provide partitioning/repartitioning, and dynamic distribution/redistribution of database data in a manner, which optimizes parallel query plan execution on SPMF or MPMF. “ ¶ [0127], “Each node in the shown MOP plan represents a MOP, or a sub-graph of multiple MOPs. Each directed edge of the graph represents at least one flow of execution data from the producer node to at least one consumer node. Without a loss of generality, one skilled in the art will understand that a "node" may be a MOP, a collection of MOPs, a subtree of the DAG, and the like.”).
As per claim 28, Branscome teaches the method of claim 27. Branscome also teaches wherein the VM is a first VM, and wherein the data movement operation includes at least one of: (i) streaming data from a data source associated with the user data query and (ii) transferring data to or from a second VM (¶ [0035]-[0038], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs. In the embodiments, a QSM may comprise a base server (herein a BSM), i.e., a general-purpose computer or server, which is configured with software to implement the QSM virtual machine. Of note, such a BSM or a CSM may implement multiple virtual QSMs. In addition, each BSM and CSM can have their own hardware and network connections.” ¶ [0038], “Moreover, processing flows may be shared between multiple QPMs and QSMs. For example, the processing output of a first QPM may be fed to a second QPM or a QSM, and vice versa. In one embodiment, a system implements a shared flow among the dataflow processing elements, such that any given query processing resource, i.e., a QPM or QSM, may transmit its flow to at least one of any other query processing resource. Those skilled in the art will understand that a QPM or QSM may transmit multiple flows, i.e., based on multiple SOPs or MOPS.”).
As per claim 29, it is a system claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Branscome also teaches at least one processor (¶ [0030], “A SOP is one or more instructions that are executed with software. That is, a SOP is executed by a QSM running on a general-purpose CPU, such as an x86 processor from Intel.”) and a memory with computer code instructions stored thereon (¶ [0124], “As noted, a QSM may comprise a general purpose CPU, such as a Xeon x86 processor by the Intel Corporation, and a memory, such as a dynamic random access memory.”).
As per claim 30, Branscome teaches the system of claim 29. Branscome also teaches further comprising at least one system resource set, each system resource set of the at least one system resource set associated with a respective VM of the at least one VM (¶ [0035]-[0038], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs. In the embodiments, a QSM may comprise a base server (herein a BSM), i.e., a general-purpose computer or server, which is configured with software to implement the QSM virtual machine. Of note, such a BSM or a CSM may implement multiple virtual QSMs. In addition, each BSM and CSM can have their own hardware and network connections.”).
As per claim 31, Branscome teaches the system of claim 30. Branscome also teaches wherein a system resource set of the at least one system resource set includes at least one of: a PDU resource, a GPU resource, a memory resource, a network resource, another type of resource, or a combination thereof (¶ [0124], “As noted, a QSM may comprise a general purpose CPU, such as a Xeon x86 processor by the Intel Corporation, and a memory, such as a dynamic random access memory.”).
As per claim 32, it is a system claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 35, it is a system claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 36, it is a system claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
As per claim 37, it is a system claim comprising similar limitations to claim 7, so it is rejected for similar reasons.
As per claim 38, it is a system claim comprising similar limitations to claim 8, so it is rejected for similar reasons.
As per claim 40, it is a system claim comprising similar limitations to claim 10, so it is rejected for similar reasons.
As per claim 43, it is a system claim comprising similar limitations to claim 13, so it is rejected for similar reasons.
As per claim 44, it is a system claim comprising similar limitations to claim 14, so it is rejected for similar reasons.
As per claim 45, it is a system claim comprising similar limitations to claim 15, so it is rejected for similar reasons.
As per claim 46, it is a system claim comprising similar limitations to claim 16, so it is rejected for similar reasons.
As per claim 47, it is a system claim comprising similar limitations to claim 17, so it is rejected for similar reasons.
As per claim 48, it is a system claim comprising similar limitations to claim 18, so it is rejected for similar reasons.
As per claim 49, it is a system claim comprising similar limitations to claim 19, so it is rejected for similar reasons.
As per claim 50, it is a system claim comprising similar limitations to claim 20, so it is rejected for similar reasons.
As per claim 51, it is a system claim comprising similar limitations to claim 21, so it is rejected for similar reasons.
As per claim 52, it is a system claim comprising similar limitations to claim 22, so it is rejected for similar reasons.
As per claim 57, it is a system claim comprising similar limitations to claim 27, so it is rejected for similar reasons.
As per claim 58, it is a system claim comprising similar limitations to claim 28, so it is rejected for similar reasons.
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) 3-4 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Branscome as applied to claims 1 and 29 above, and further in view of Clarkson (US Pub. No. 2025/0013646 A1).
As per claim 3, Branscome teaches the method of claim 1. Branscome teaches the VM instruction specifies a type of computation workload, wherein the computation workload includes a type of the computation workload associated with the user data query (¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM. In a conventional RDBMS implementation, this query plan is a single operation (e.g., scan, join, etc.) at a time.”).
Branscome fails to teach any compilation of the VM instruction to a lower level programming language representation.
Clarkson teaches wherein the VM instruction is specified in an instruction set architecture (ISA), wherein the ISA is compatible with at least one type of computation workload, and wherein the at least one type of computation workload includes a type of the computation workload associated with the user data query (¶ [0023], “In various embodiments, each virtual machine 114 comprises a runtime configured to execute a query based on the byte code representation of the query, as disclosed herein. In various embodiments, the byte code may be interpreted or instead compiled into machine code and executed by hardware comprising the database server 112.” ¶ [0025], “At 204, the query is decomposed into a discrete set of streaming operators define over data frames. At 206, the operators determined in step 204 are encoded into optimized byte code and/or some other intermediate (e.g., runtime interpreted and/or executable) representation. In various embodiments, the encoding generated at 206 includes and/or is supplemented by byte code representing the query and the operators into which the query was decomposed at step 204 as a data flow graph describing the relationship between the operators, in terms of the data flow between them, and the data inputs and output of each, e.g., the data frames each is configured to receive as input and provide as output.” ¶ [0032]-[0033], “Referring further to FIG. 4, in the example shown virtual machine 412 includes the following components/modules: graph metadata 416 comprising metadata describing one or more graphs and/or their content; just-in-time (JIT) compiler 418, configured to optimize and compile byte code for execution; scheduler 420, configured to use code compiled by JIT compiler 418 to create, initialize, schedule and/or queue up work for, and move data frames between instances of operators defined to perform a query; and buffer manager 422 configured to create, allocate, and/or otherwise manage resources such as memory. In various embodiments, JIT compiler 418 may use data comprising graph metadata 416 and/or the underlying graph to optimize byte code associated with a query.”).
Branscome and Clarkson are considered to be analogous to the claimed invention because they are in the same field of request processing using virtual machines. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Branscome with the VM instruction compilation of Clarkson to arrive at the claimed invention. The motivation to modify Branscome with the teachings of Clarkson is that compiling the query into a representation that the VM can process allows the system to execute queries from different query languages which can result in a universal query processing system (See Clarkson para. 0020.).
As per claim 4, Branscome and Clarkson teach the method of claim 3. Branscome teaches wherein the at least one type of computation workload includes a Structured Query Language (SQL) query plan, a data ingestion pipeline, an artificial intelligence (AI) or machine learning (ML) workload, a high-performance computing (HPC) program, another type of computation workload, or a combination thereof (¶ [0081], “Nodes 106a-n may be any set of devices, including hardware and software that assist in the processing of queries by system 100. In general, nodes 106a-n are configured to support various SQL queries on relational databases (and thus may also be known as a RDBMS). Typical examples of DBMSs supported by nodes 106a-n include Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, and MySQL.”).
As per claim 33, it is a system claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
As per claim 34, it is a system claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
Claim(s) 9 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Branscome as applied to claims 1 and 29 above, and further in view of Barlew et al. (US Pub. No. 2023/0252006 A1 hereinafter Barlew).
As per claim 9, Branscome teaches the method of claim 1. Branscome teaches the dataflow graph (¶ [0146], “Ideally, for efficiency, this query plan would consist of more operations in the QF dataflow graph. The QF API should allow specifying all the dataflow operators and building the dataflow graph by specifying the connections in the graph.”).
Branscome fails to teach any validation actions being performed on the dataflow graph.
However, Barlew teaches perform validation of the dataflow graph (¶ [0032], “Validation engine 206 is configured to compare an ontological graph to a set of validation constraints to determine whether the nodes and the edges between the nodes of the graph are valid. In some embodiments, validation engine 206 is configured to compare a set of validation constraints to an ontological graph that is currently being edited/generated within the visual input area of a user interface for graph creation (e.g., an ontology editor user interface, a search query input user interface, an annotation user interface). In the event that validation engine 206 determines that a portion of the ontological graph is not valid in accordance with the set of validation constraints, then validation engine 206 presents a prompt at the user interface to cause the user to edit the graph in the visual input area in a manner that would cause the resulting graph to become valid at a subsequent check.”); responsive to the validation being unsuccessful, terminate execution of the dataflow graph (¶ [0034], “For example, a search query that comprises an ontological graph can describe complex relationships between resources that cannot be captured by a keyword-based search or by a simple database query. In some embodiments, the user-defined ontological graph-based search query is also evaluated by validation engine 206 for validity. In the event that validation engine 206 determines that the search query graph is not valid, then validation engine 206 is configured to present a corresponding prompt at the search query input user interface.”); and responsive to the validation being successful, proceed with the execution of the dataflow graph (¶ [0046]-[0047], “At 406, whether the new node or the new edge is valid is determined. In the event that the new node or the new edge is valid, control is returned to 402. Otherwise, in the event that the new node or the new edge is invalid, control is transferred to 408. The validity of the placement of the new node or the new edge within the current graph that is presented in the visual input area is checked against logic validation rules, semantic validation rules, standards-based validation rules, and/or other configured rules. For example, a validation rule can dictate whether an edge of edge type A can be placed between a first node of type B and a second node of type C. In another example, a validation rule can require that a node has to be connected to at least one other node (i.e., a node cannot be not connected to any other nodes). In yet another example, a validation rule can dictate that a relation cannot be reflexive, e.g., a node representing a child cannot also be designated as its own parent. At 408, a prompt to indicate invalidation is presented. If the placement of the new node or the new edge is not valid, then a prompt describing the invalidity (e.g., the violated validation rule) can be presented to inform the ontology editor user to edit the placement/naming of the new node/edge to remove the invalidation.”).
Branscome and Barlew are considered to be analogous to the claimed invention because they are in the same field of request/query processing. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Branscome with the graph validation functionality of Barlew to arrive at the claimed invention. The motivation to modify Branscome with the teachings of Barlew is that validating a graph prior to execution ensures a graph can be safely and correctly executed within the system.
As per claim 39, it is a system claim comprising similar limitations to claim 9, so it is rejected for similar reasons.
Claim(s) 11-12 and 41-42 are rejected under 35 U.S.C. 103 as being unpatentable over Branscome as applied to claims 10 and 40 above, and further in view of Bacthavachalu et al. (US Patent No. 8,312,037 B1 hereinafter Bacthavachalu).
As per claim 11, Branscome teaches the method of claim 10. Branscome teaches configuring an edge of the set of edges to transfer the data blocks (¶ [0127], “Each node in the shown MOP plan represents a MOP, or a sub-graph of multiple MOPs. Each directed edge of the graph represents at least one flow of execution data from the producer node to at least one consumer node. Without a loss of generality, one skilled in the art will understand that a "node" may be a MOP, a collection of MOPs, a subtree of the DAG, and the like.”).
Branscome fails to teach the transfer of data blocks being done using a first in first out (FIFO) queue.
However, Bacthavachalu teaches transfer the data blocks using a first in first out (FIFO) queue (Col. 7, lines 19-36, “The framework in one embodiment utilizes the queuing service 218 to distribute the data across the nodes. The queuing service can accept a definition for the data, and any appropriate metadata, and store that data to a queue. The queuing service then can dequeue the data one file, block, or grouping at a time. Each grouping of data can be sent to at least one node for processing and loading into the system. When a node finishes processing a group, another group can be dequeued until all the data is dequeued. In this way, each node takes data as quickly as possible which not only causes the data to be loaded more efficiently, but also helps to dynamically spread the data across the system based on factors such as load and capacity.” Col. 9, lines 22-42, “Since a cluster of nodes exists that has the data loaded as discussed above, commands such as SQL or other querying commands can be issued to execute an instance query for the distributed data on each node. The instance results can be stored locally on each node, in some embodiments, and a reference to the results can be placed in a queue service such as discussed above. Using a merge ratio or tree determination algorithm, for example, the system can determine a next set of nodes to handle the results of the instance queries.”).
Branscome and Bacthavachalu are considered to be analogous to the claimed invention because they are in the same field of request processing. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Branscome with the queue of Bacthavachalu to arrive at the claimed invention. The motivation to modify Branscome with the teachings of Bacthavachalu is that transferring data through queues allows for each node/edge of to load and process data efficiently as well as spread the data across the nodes/edges when needed (See Bacthavachalu Col. 7, lines 19-36.).
As per claim 12, Branscome and Bacthavachalu teach the method of claim 11. Bacthavachalu teaches further comprising configuring, based on a user input, a size of the FIFO queue (Col. 7, lines 19-36, “The queue in at least one embodiment is a block queue, which allows a user to decide the size or grouping of data to be distributed across the system.”).
Refer to claim 11 for motivation to combine.
As per claim 41, it is a system claim comprising similar limitations to claim 11, so it is rejected for similar reasons.
As per claim 42, it is a system claim comprising similar limitations to claim 12, so it is rejected for similar reasons.
Claim(s) 23-26 and 53-56 are rejected under 35 U.S.C. 103 as being unpatentable over Branscome as applied to claims 1 and 29 above, and further in view of Chandramouli et al. (US Pub. No. 2012/0166417 A1 hereinafter Chandramouli).
As per claim 23, Branscome teaches the method of claim 1. Branscome teaches the VM instructions (¶ [0035], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM.”).
Branscome fails to teach adapting the VM instructions based one at least one statistic associated with the computation workload.
However, Chandramouli teaches adapting the query based on at least one statistic associated with the at least a portion of the computation workload (¶ [0034], “A query optimizer, for instance, can ascertain that a structure of the old query plan 104 is no longer optimal due to, for instance, change in characteristics of the operating environment of an operator (e.g., available CPU, memory, etc.), change in workloads with respect to computing systems utilized to execute portions of the old query plan 104, the distribution of values in one or more input data streams changes, etc. and can further ascertain that the new query plan 106 will execute more efficiently in the current computing environment.”).
Branscome and Chandramouli are considered to be analogous to the claimed invention because they are in the same field of request processing. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Branscome with the query optimization functionality of Chandramouli to arrive at the claimed invention. The motivation to modify Branscome with the teachings of Chandramouli is that adapting the query instructions allows for more efficient and optimal processing of the query request within the runtime environment.
As per claim 24, Branscome and Chandramouli teach the method of claim 23. Chandramouli teaches wherein a statistic of the least one statistic includes a runtime statistical distribution of data values in a data source associated with the user data query (¶ [0034], “A query optimizer, for instance, can ascertain that a structure of the old query plan 104 is no longer optimal due to, for instance, change in characteristics of the operating environment of an operator (e.g., available CPU, memory, etc.), change in workloads with respect to computing systems utilized to execute portions of the old query plan 104, the distribution of values in one or more input data streams changes, etc. and can further ascertain that the new query plan 106 will execute more efficiently in the current computing environment.”).
Refer to claim 23 for motivation to combine.
As per claim 25, Branscome and Chandramouli teach the method of claim 24. Chandramouli also teaches wherein the adapting is responsive to identifying a mismatch between the runtime statistical distribution of the data values and an estimated statistical distribution of the data values (¶ [0034], “A query optimizer, for instance, can ascertain that a structure of the old query plan 104 is no longer optimal due to, for instance, change in characteristics of the operating environment of an operator (e.g., available CPU, memory, etc.), change in workloads with respect to computing systems utilized to execute portions of the old query plan 104, the distribution of values in one or more input data streams changes, etc. and can further ascertain that the new query plan 106 will execute more efficiently in the current computing environment.”).
Refer to claim 23 for motivation to combine.
As per claim 26, Branscome and Chandramouli teach the method of claim 23. Branscome teaches the VM instructions (¶ [0035], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM.”). Chandramouli teaches wherein the adapting includes at least one of: (i) reordering at least two query instructions of the set of query instructions, (ii) removing at least one query instruction from the set of query instructions, (iii) adding at least one query instruction to the set of query instructions, and (iv) modifying at least one query instruction of the set of query instructions (¶ [0071], “In a case where selections and projections are being moved (pushed up or down) in the new query plan, this signatures discussed above can be employed to construct the correct transformation plan. Specifically, if a selection or projection operator O appears in the oplist of a synopsis in the new plan, but does not appear in the corresponding oplist in the old plan, operation O can be performed as part of the transformation plan when migrating state from the old plan to the new plan. This ensures that the corresponding operation O is applied exactly once on every stream event. On the other hand, if operation O appears in the oplist of the old plan but not in the oplist of the new plan, there are two alternatives. First, if the operation O is invertible (e.g., if O is a projection operator that sets A=A+5, then the inverse projection operation would set A=A-5), the inverse of O can be placed as part of the transformation plan between the old plan and new plan. If operation O is not invertible, a field in the event can be added that indicates that operation O has been performed, and operation O can be modified in the new plan to perform the operation only if the field is not set, thus ensuring that operation O is applied exactly once on each event. It is to be understood that the above scenarios are illustrative in nature.” See also para. 0074.).
Refer to claim 23 for motivation to combine.
As per claim 53, it is a system claim comprising similar limitations to claim 23, so it is rejected for similar reasons.
As per claim 54, it is a system claim comprising similar limitations to claim 24, so it is rejected for similar reasons.
As per claim 55, it is a system claim comprising similar limitations to claim 25, so it is rejected for similar reasons.
As per claim 56, it is a system claim comprising similar limitations to claim 26, so it is rejected for similar reasons.
Claim(s) 59 is rejected under 35 U.S.C. 103 as being unpatentable over Branscome in view of Clarkson.
As per claim 59, Branscome teaches a computer-implemented method comprising: selecting an execution resource from a set of execution resources of a virtual machine (VM), the selecting performed as part of executing a compute node of at least one compute node of a dataflow graph being executed by the VM, the compute node including at least one VM instruction, the selecting performed on an instruction-by- instruction basis (¶ [0035]-[0036], “A QSM is a module (virtual machine) that is implemented in software and functions as an execution engine for software operations (SOPs), which provides a virtual environment in which the SOPs can execute. In some embodiments, a QSM can be viewed as a software-equivalent to a QPM. A QSM also provides a means of I/O for MOPs and SOPs. In the embodiments, a QSM may comprise a base server (herein a BSM), i.e., a general-purpose computer or server, which is configured with software to implement the QSM virtual machine.”); performing, at the compute node on the instruction-by-instruction basis, compilation of a VM instruction of the at least one VM instruction, the performing transforming the VM instruction to machine code executable by the execution resource selected (¶ [0105]-[0106], “Query and plan manager 402 analyzes and represents the parsed query received from the MySQL software 114, annotates the query, and provides an annotation graph representation of the query plan. Query reduction/rewrite module 404 breaks the query into query fragments and rewrites the query fragments into tasks. Rewrites may be needed for compressed domain rewrites and machine code database instruction operator rewrites…These modules interact with each other to determine how to execute a query, such as a SQL query from MySQL software 114…Once a parsed SQL query has been represented in this data structure (converted, for example, from MySQL), query and plan manager 402 rewrites the query such that each fragment of the query can be done entirely in MySQL software 114, in C2 software 110, or in QPM module 204. Once the final query representation is available, the rewrite module 404 goes through and breaks the graph into query fragments.” ¶ [0145], “In general, a SQL query statement goes through parsing and logical rewrite/optimization steps in the RDBMS layer. The query plan is then executed in multiple virtual processors, which subsequently pass the query plan to be executed in the accelerator, i.e., using a QPM or QSM.”); and executing the machine code by the execution resource selected, the dataflow graph corresponding to at least a portion of a computation workload associated with a user data query, the executing advancing the compute node toward producing a result, the result contributing to production of a response to the user data query (¶ [0081], “Nodes 106a-n may be any set of devices, including hardware and software that assist in the processing of queries by system 100.” ¶ [0090], “In particular, C2 software 110 may decompose a query into a set of query fragments. Each fragment comprises various tasks, which may have certain dependencies. C2 software 110 may determine which fragments and tasks are part of the fast path portion and offload them to one of the QPM module 204a-n. Appropriate tasks for the selected query fragments are sent to QPM modules 204a-n with information on the database operation dependency graph. Within the QPM modules 204a-n, tasks are further broken down into parallel/pipelined machine code operations (known as MOPs) and executed in hardware.” See also para. 0086-0087. ¶ [0111], “Answer manager 422 is responsible for compiling the results of the query fragments and providing the result to MySQL software 114 via the API 116.” ¶ [0164], “There are two ways a virtual processor is able to obtain results from the accelerator. The results can be pulled by a processor or pushed to the processor by invoking a callback. A callback may be a general-purpose abstraction for result retrieval.”).
Branscome fails to explicitly teach a just-in-time compilation of instructions.
However, Clarkson teaches the well-known technique of performing just-in-time compilation of a VM instruction, the performing transforming the VM instruction to machine code (¶ [0032]-[0033], “Referring further to FIG. 4, in the example shown virtual machine 412 includes the following components/modules: graph metadata 416 comprising metadata describing one or more graphs and/or their content; just-in-time (JIT) compiler 418, configured to optimize and compile byte code for execution; scheduler 420, configured to use code compiled by JIT compiler 418 to create, initialize, schedule and/or queue up work for, and move data frames between instances of operators defined to perform a query; and buffer manager 422 configured to create, allocate, and/or otherwise manage resources such as memory. In various embodiments, JIT compiler 418 may use data comprising graph metadata 416 and/or the underlying graph to optimize byte code associated with a query.”).
Branscome and Clarkson are considered to be analogous to the claimed invention because they are in the same field of request processing using virtual machines. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Branscome with the well-known technique of a JIT compiler as taught in Clarkson to arrive at the claimed invention. This modification would have been reasonable and yielded predictable results under MPEP § 2143 as the query processing system of Branscome can be modified by the known technique of a JIT compiler as taught by Clarkson.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199