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 .
DETAILED ACTION
This communication is responsive to Amendment, filed 07/15/2026.
Claims 1-20 are pending in this application. This action is made Final.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Claims 1-6, 8-16, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Caudy et al. (US Pat No. 10241965), in view of Mills et al. (US Pub No. 20170115976).
As to claims 1, 11, Caudy teaches a method of efficiently implementing a data pipeline comprising (i.e. the operations also include assigning a first sub-graph of a query graph to a first query processor, and assigning a second sub-graph of the query graph to a second query processor, where a result of the first sub-graph is an input to the second sub-graph. In some third implementations, the operations further include receiving a query, parsing the query, and in response to the parsing creating the query graph based on the query … the operations also include receiving, at the second query processor, an initial snapshot of the result from the first query processor, the initial snapshot being sent in response to the subscription request, and storing the initial snapshot as the replica of the result, col. 3, lines 22-34):
creating and storing a dataset dependency graph in a memory as a directed acyclic graph, the data set dependency graph including metadata representing dependencies comprising references to a set of datasets including a first dataset and one or more downstream derived datasets that depend on the first dataset (i.e. code can be converted into the in-memory data structures holding the DAG. For example, the source code of FIG. 5A gets converted into the DAG data structure in memory. The DAG connectivity can change by executing code. For example, assume a set of code CODE1 is executed. CODE1 leads to a DAG1 being created. Data can be processed through DAG1, leading to table updates, col. 9, lines 9-25’ In FIG. 5A, example code 500 defines the data sources as tables (A, B, C, and X). From the code 500 for the data sources, DAG 502 can be generated as shown by the graph in FIG. 5B. DAG 502 in FIG. 5B shows dependencies between the nodes, which correspond to table data sources, col. 8, lines 33-40; FIGS. 6A, 6B, 7, and 8 also show data source definitions and a corresponding directed acyclic graph (DAG) … where A is a primary data source, col. 8, lines 41-51; Data sources can include market data (e.g., data received via multicast distribution mechanism or through a tailer), system generated data, historical data, user input data from the remote user table server, tables programmatically generated in-memory, or something further upstream in the DAG. In general, anything represented in the data system as an object (e.g., a table) and which can refresh itself/provide data can be a data source, col. 8, line 52 to col. 9, line 8);
detecting, at a first time, a first update to the first dataset (i.e. FIG. 11 is a flowchart of an example method 1100 of connecting a query DAG through multiple remote query processors … Processing begins at 1102, where a first sub-graph of a query graph is assigned to a first query processor, col. 12, lines 49-52; At 1114, a first listener is added at the first query processor to the first sub-graph as a dependent of the result. Processing continues to 1116. At 1116, an update notification indicating an update to the result is received at the first listener. Processing continues to 1118, col. 13, lines 47-52);
determining, using the dataset dependency graph, that there are no incomplete upstream dependencies for at least one of the one or more downstream derived datasets that depend on the first data set (i.e. when a table changes, an application programming interface (API) can specify, for example, rows where add, modify, delete, or reindex (AMDR) changes were made. A reindex is a change in which a row is moved but the value contained in the row is not modified. The API can also provide a mechanism to obtain a value prior to the most recent change. When the DAG is processed during the refresh, the AMDR info on “upstream” data objects (e.g., tables, etc.) or nodes can be used to compute changes in “downstream” data objects or nodes. In some implementations, the entire DAG can be processed during the refresh cycle, col. 9, lines 26-37);
initiating, in response to detecting the first update to the first dataset and in response to determining that there is no incomplete upstream dependencies for the at least one of the one or more downstream derived dataset, a first build of the at least one of the one or more downstream derived datasets that depend on the first dataset, the first build comprising a first transformation of the first dataset (i.e. Processing begins at 1102, where a first sub-graph of a query graph is assigned to a first query processor, col. 12, lines 49-54; FIG. 6B is a diagram illustrating a DAG 610 connected through two workers 1 and 2 to calculate two results (F and I) on two different workers with only worker 1 executing a common portion (X) of the two calculations, in accordance with some implementations. In this embodiment, DAG 610 comprises subgraphs 614 and 612, col. 11, lines 22-27);
receiving a second update to the first dataset at a second time later than the first time (i.e. At 1118, the first listener sends a notification to the second query processor including an indication of the change to the result and a copy of any changed data. Processing continues to 1120. At 1120, responsive to receiving the notification at the second query processor, the replica of the result is updated at the second query processor and the changes are propagated through the second sub-graph at the second query processor. Processing continues to 1122, col. 13, lines 53-61);
determining, using the dataset dependency graph, that there are no incomplete upstream dependencies for the first data set (i.e. when a table changes, an application programming interface (API) can specify, for example, rows where add, modify, delete, or reindex (AMDR) changes were made. A reindex is a change in which a row is moved but the value contained in the row is not modified. The API can also provide a mechanism to obtain a value prior to the most recent change. When the DAG is processed during the refresh, the AMDR info on “upstream” data objects (e.g., tables, etc.) or nodes can be used to compute changes in “downstream” data objects or nodes. In some implementations, the entire DAG can be processed during the refresh cycle, col. 9, lines 26-37);
initiating, in response to determining that there are no incomplete upstream dependencies for the first dataset, a second build of the first dataset while the first build is still being implemented (i.e. FIG. 6B is a diagram illustrating a DAG 610 connected through two workers 1 and 2 to calculate two results (F and I) on two different workers with only worker 1 executing a common portion (X) of the two calculations, in accordance with some implementations. In this embodiment, DAG 610 comprises subgraphs 614 and 612, col. 11, lines 22-27; a second sub-graph of the query graph is assigned to a second query processor, a result of the first sub-graph being an input to the second sub-graph, col. 12, lines 55-58);
wherein the method is performed using one or more processors (i.e. FIG. 11 is a flowchart of an example method 1100 of connecting a query DAG through multiple remote query processors in accordance with some implementations. Processing begins at 1102, where a first sub-graph of a query graph is assigned to a first query processor. Processing continues to 1104, col. 12, lines 49-54; At 1104, a second sub-graph of the query graph is assigned to a second query processor, a result of the first sub-graph being an input to the second sub-graph. Processing continues to 1106, col. 12, lines 55-58).
Although Caudy does not seem to explicitly teach “pipeline”, Mills teaches this term (i.e. FIG. 12 is a flow diagram of method 300 for dynamically updating a continuous delivery pipeline, [0026]; In step 310, one or more changes are received to the pipeline, [0037]; In step 330, the job is passed to a build worker. Accordingly, the description of the scheduled pipeline can be passed on with the job specification to the allocated worker. This ensures that any build record produced by the pipeline can be used to visualize and reconstruct the state of the pipeline as it now stands. In step 340, build results are generated. In step 350, a pipeline blockchain is updated with the build record, [0038]).
It would have been obvious to one of ordinary skill of the art having the
teaching of Caudy, Mills before the effective filing date of the claimed invention to modify the system of Caudy to include the limitations as taught by Mills. One of ordinary skill in the art would be motivated to make this combination in order to send a job package to a first build worker in response to launching a build pipeline and, receive second results of a second job in the build pipeline performed by a second build worker in view of Mills ([0008]), as doing so would give the added benefit of updating the first build record held by the first build worker with the second results of the second job in the build pipeline performed by the second build worker, as taught by Mills ([0008]).
As to claims 2, 12, Caudy teaches:
reading configuration data specifying one or more periods for one or more datasets in the dataset dependency graph (i.e. DNs are nodes of the graph that can change. For example, DN can be data sources that update as new data comes in, DN could also be timers that trigger an event based on time intervals. In other examples, DN could also be MySQL monitors, specialized filtering criteria (e.g., update a “where” filter only when a certain event happens). Because these nodes are “sources”, they may occur as root nodes in the DAG. At the most fundamental level, DN are root DAG nodes which change (e.g., are “alive”), col. 9, lines 41-49);
wherein initiating the first build comprises determining that a current time is within a first period of the one or more periods from a fixed time of a day or a previous generation of a first intermediate derived dataset of the one or more downstream derived datasets occurred earlier than the current time less a second period of the one or more periods (i.e. A data log tailer 116 can be configured to access the sequential, row-oriented log file(s) 114 to retrieve input data logged by the data logging process. In some implementations, the data log tailer 116 can be configured to perform strict byte reading and transmission (e.g., to the data import server 120). The data import server 120 can be configured to store the input data into one or more corresponding data stores such as the periodic table data store 122 in a column-oriented configuration. The periodic table data store 122 can be used to store data that is being received within a time period (e.g., a minute, an hour, a day, etc.) and which may be later processed and stored in a data store of the long-term file server 108. For example, the periodic table data store 122 can include a plurality of data servers configured to store periodic securities trading data according to one or more characteristics of the data (e.g., a data value such as security symbol. the data source such as a given trading exchange, etc.), col. 5, lines 36-53).
As to claims 3, 13, Caudy teaches updating the configuration data to specify a certain period for a certain dataset of the one or more datasets that recursively applies to datasets with depend on the certain dataset (i.e. The controller host 204 can include a persistent query controller 216 configured to connect to a remote query dispatcher 232 and one or more remote query processors 228-230. In some implementations, the persistent query controller 216 can serve as the “primary client” for persistent queries and can request remote query processors from dispatchers, and send instructions to start persistent queries. For example, a user can submit a query to 216, and 216 starts and runs the query every day. In another example, a securities trading strategy could be a persistent query. The persistent query controller can start the trading strategy query every morning before the market opened, for instance. It will be appreciated that 216 can work on times other than days. In some implementations, the controller may require its own clients to request that queries be started, stopped. etc. This can be done manually, or by scheduled (e.g., cron jobs). Some implementations can include “advanced scheduling” (e.g., auto-start/stop/restart, time-based repeat, etc.) within the controller, col. 6, line 61 to col. 7, line 13; When query code is executed, the DAG is created or modified. As part of this process, the system records the order in which the DAG nodes were constructed in. This “construction ordering” can be used to determine the order that nodes are processed in the DAG, col. 10, lines 1-5).
As to claims 4, 14, Caudy teaches setting a period for a specific dataset depending on multiple datasets according to the dataset dependency graph to a minimum of multiple periods applied to the multiple datasets (i.e. It will be appreciated that the configuration shown in FIG. 1 is a typical example configuration that may be somewhat idealized for illustration purposes. An actual configuration may include one or more of each server and/or host type. The hosts/servers shown in FIG. 1 (e.g., 102-110, 120, 124 and 142) may each be separate or two or more servers may be combined into one or more combined server systems. Data stores can include local/remote, shared/isolated and/or redundant. Any table data may flow through optional proxies indicated by an asterisk on certain connections to the remote query processors (e.g., table data cache proxy (TDCP) 392 or 404 as shown in FIG. 3B and FIG. 4, respectively). Also, it will be appreciated that the term “periodic” is being used for illustration purposes and can include, but is not limited to, data that has been received within a given time period (e.g., millisecond, second, minute, hour, day, week, month, year, etc.) and which has not yet been stored to a long-term data store (e.g., 140), col. 6, lines 26-43; When query code is executed, the DAG is created or modified. As part of this process, the system records the order in which the DAG nodes were constructed in. This “construction ordering” can be used to determine the order that nodes are processed in the DAG, col. 10, lines 1-5; DNs are nodes of the graph that can change. For example, DN can be data sources that update as new data comes in, DN could also be timers that trigger an event based on time intervals. In other examples, DN could also be MySQL monitors, specialized filtering criteria (e.g., update a “where” filter only when a certain event happens). Because these nodes are “sources”, they may occur as root nodes in the DAG. At the most fundamental level, DN are root DAG nodes which change (e.g., are “alive”), col. 9, lines 41-49).
As to claims 5, 15, Caudy teaches the configuration data further having a declarative parameter specifying a logical branch of a plurality of logical branches of a build system (i.e. DNs are nodes of the graph that can change. For example, DN can be data sources that update as new data comes in, DN could also be timers that trigger an event based on time intervals. In other examples, DN could also be MySQL monitors, specialized filtering criteria (e.g., update a “where” filter only when a certain event happens). Because these nodes are “sources”, they may occur as root nodes in the DAG. At the most fundamental level, DN are root DAG nodes which change (e.g., are “alive”), col. 9, lines 41-49; code can be converted into the in-memory data structures holding the DAG. For example, the source code of FIG. 5A gets converted into the DAG data structure in memory. The DAG connectivity can change by executing code. For example, assume a set of code CODE1 is executed. CODE1 leads to a DAG1 being created. Data can be processed through DAG1, leading to table updates, col. 9, lines 9-25’ In FIG. 5A, example code 500 defines the data sources as tables (A, B, C, and X). From the code 500 for the data sources, DAG 502 can be generated as shown by the graph in FIG. 5B. DAG 502 in FIG. 5B shows dependencies between the nodes, which correspond to table data sources, col. 8, lines 33-40; FIGS. 6A, 6B, 7, and 8 also show data source definitions and a corresponding directed acyclic graph (DAG) … where A is a primary data source, col. 8, lines 41-51; Data sources can include market data (e.g., data received via multicast distribution mechanism or through a tailer), system generated data, historical data, user input data from the remote user table server, tables programmatically generated in-memory, or something further upstream in the DAG. In general, anything represented in the data system as an object (e.g., a table) and which can refresh itself/provide data can be a data source, col. 8, line 52 to col. 9, line 8; When query code is executed, the DAG is created or modified. As part of this process, the system records the order in which the DAG nodes were constructed in. This “construction ordering” can be used to determine the order that nodes are processed in the DAG, col. 10, lines 1-5).
As to claims 6, 16, Caudy teaches confirming that the set of datasets is associated with logical branch (i.e. Data sources can include market data (e.g., data received via multicast distribution mechanism or through a tailer), system generated data, historical data, user input data from the remote user table server, tables programmatically generated in-memory, or something further upstream in the DAG, col. 8, lines 52 to col. 9, line 8; when a table changes, an application programming interface (API) can specify, for example, rows where add, modify, delete, or reindex (AMDR) changes were made. A reindex is a change in which a row is moved but the value contained in the row is not modified. The API can also provide a mechanism to obtain a value prior to the most recent change. When the DAG is processed during the refresh, the AMDR info on “upstream” data objects (e.g., tables, etc.) or nodes can be used to compute changes in “downstream” data objects or nodes. In some implementations, the entire DAG can be processed during the refresh cycle, col. 9, lines 26-37).
As to claims 8, 18, Caudy teaches, initiating the second build comprising confirming that the first dataset is not derived from any stored dataset according to the dataset dependency graph (i.e. FIG. 12 is a diagram illustrating a DAG 1202 connected through two workers 1 and 2, in accordance with some implementations. DAG 1202 comprises DAGs 1204 and 1206 of worker 1 and DAG 1208 of worker 2, col. 4, lines 27-29).
As to claims 9, 19, Caudy teaches:
confirming, when the first transformation is complete, that a first intermediated
derived dataset of the one or more downstream derived datasets depends on only the first dataset (i.e. FIG. 6B is a diagram illustrating a DAG 610 connected through two workers 1 and 2 to calculate two results (F and I) on two different workers with only worker 1 executing a common portion (X) of the two calculations, in accordance with some implementations. In this embodiment, DAG 610 comprises subgraphs 614 and 612, col. 11, lines 22-27; a second sub-graph of the query graph is assigned to a second query processor, a result of the first sub-graph being an input to the second sub-graph, col. 12, lines 55-58);
initiating, when a final dataset of the set of datasets is not yet built in response to the first update, a third transformation to the first intermediate derived dataset (i.e. FIG. 6B is a diagram illustrating a DAG 610 connected through two workers 1 and 2 to calculate two results (F and I) on two different workers with only worker 1 executing a common portion (X) of the two calculations, in accordance with some implementations. In this embodiment, DAG 610 comprises subgraphs 614 and 612, col. 11, lines 22-27; a second sub-graph of the query graph is assigned to a second query processor, a result of the first sub-graph being an input to the second sub-graph, col. 12, lines 55-58).
As to claims 10, 20, Caudy teaches:
determining, when the first transformation is complete, that a second intermediate derived dataset that depends on the first dataset also depends on a second dataset that is undergoing a third transformation (i.e. FIG. 12 is a diagram illustrating a DAG 1202 connected through two workers 1 and 2, in accordance with implementations. DAG 1202 comprises DAGs 1204 and 1206 of worker 1 and DAG 1208 of worker 2, col. 4, lines 27-29);
waiting until the third transformation is complete to initiate a fourth
transformation of the second intermediate derived dataset (i.e. FIG. 12 is a diagram illustrating a DAG 1202 connected through two workers 1 and 2, in accordance with implementations. DAG 1202 comprises DAGs 1204 and 1206 of worker 1 and DAG 1208 of worker 2, col. 4, lines 27-29).
Claims 7, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Caudy et al. (US Pat No. 10241965), in view of Mills et al. (US Pub No. 20170115976), as applied to claims above, and further in view of Park et al. (US Pub No. 20180013692).
As per claims 7, 17, Caudy teaches:
detecting that an amount of resource used in the first transformation exceeds a threshold (i.e. A data log tailer 116 can be configured to access the sequential, row-oriented log file(s) 114 to retrieve input data logged by the data logging process. In some implementations, the data log tailer 116 can be configured to perform strict byte reading and transmission (e.g., to the data import server 120). The data import server 120 can be configured to store the input data into one or more corresponding data stores such as the periodic table data store 122 in a column-oriented configuration. The periodic table data store 122 can be used to store data that is being received within a time period (e.g., a minute, an hour, a day, etc.) and which may be later processed and stored in a data store of the long-term file server 108. For example, the periodic table data store 122 can include a plurality of data servers configured to store periodic securities trading data according to one or more characteristics of the data (e.g., a data value such as security symbol. the data source such as a given trading exchange, etc.), col. 5, lines 36-53);
in response to the detecting of exceeding the threshold, updating the configuration data to specify a period of the one or more periods (i.e. The periodic table data store 122 can be used to store data that is being received within a time period (e.g., a minute, an hour, a day, etc.) and which may be later processed and stored in a data store of the long-term file server 108. For example, the periodic table data store 122 can include a plurality of data servers configured to store periodic securities trading data according to one or more characteristics of the data (e.g., a data value such as security symbol. the data source such as a given trading exchange, etc.), col. 5, lines 36-53; DNs are nodes of the graph that can change. For example, DN can be data sources that update as new data comes in, DN could also be timers that trigger an event based on time intervals. In other examples, DN could also be MySQL monitors, specialized filtering criteria (e.g., update a “where” filter only when a certain event happens). Because these nodes are “sources”, they may occur as root nodes in the DAG. At the most fundamental level, DN are root DAG nodes which change (e.g., are “alive”), col. 9, lines 41-49).
Caudy, Mills do not seem to expressly teach “a threshold”.
However, Park teaches this term (i.e. the buffers 612, 614 may be written to their corresponding files 636, 640 when a workload capture is completed. In other cases, the buffers 612, 614 can be written periodically during workload capture. For example, each of the buffers 612 and the buffer 614 can be assigned a threshold size … the buffer 614, exceeds the threshold, the buffer can be written to its corresponding file 636, 640 and emptied. In other cases, the buffers 612, 614 can be written periodically in another manner, such as at particular time intervals or after a particular number of capture units have been added to the buffers, [0153]; save points may occur automatically, such as according to a schedule, when a threshold number of records have been changed, or when a threshold number of request for database operations have been received or executed. Similarly, storage snapshots, file system backups, data backups, and log backup operations can be captured and, optionally, replayed, [0129]).
It would have been obvious to one of ordinary skill of the art having the teaching of Caudy, Mills, Park before the effective filing date of the claimed invention to modify the system of Caudy, Mills to include the limitations as taught by Park. One of ordinary skill in the art would be motivated to make this combination in order to determine execution dependencies between the plurality of requests based on the type, access unit identifier, and chronological identifier of each of the plurality of requests, in view of Park (Abstract), as doing so would give the added benefit of determining dependencies between requests for database operations in the workload, such as to determine whether at least a portion of the requests can be executed in parallel, as taught by Park (Summary).
Response to Arguments
Applicant's arguments with respect to claims 1-20 have been considered but are
moot in view of the new ground(s) of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIRANDA LE whose telephone number is (571)272-4112. The examiner can normally be reached M-F 7AM-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, Kavita Stanley can be reached on 571-272-8352. 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.
/MIRANDA LE/ Primary Examiner, Art Unit 2153
Prosecution Insights