Patent Application 18347578 - SYSTEMS AND METHODS FOR AUTOMATING MULTIMODAL

Title: SYSTEMS AND METHODS FOR AUTOMATING MULTIMODAL COMPUTATIONAL WORKFLOWS, AND NON-TRANSITORY STORAGE MEDIUM

Application Information

Invention Title: SYSTEMS AND METHODS FOR AUTOMATING MULTIMODAL COMPUTATIONAL WORKFLOWS, AND NON-TRANSITORY STORAGE MEDIUM
Application Number: 18347578
Submission Date: 2025-05-14T00:00:00.000Z
Effective Filing Date: 2023-07-06T00:00:00.000Z
Filing Date: 2023-07-06T00:00:00.000Z
National Class: 707
National Sub-Class: 769000
Examiner Employee Number: 87075
Art Unit: 2165
Tech Center: 2100

Rejection Summary

102 Rejections: 1
103 Rejections: 2

Cited Patents

The following patents were cited in the rejection:

Office Action Text

DETAILED ACTION
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)(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.

(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) 1, 2, 4-8, 10, 11, 13-17 and 19 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Kornacker et al. (U.S. Publication No. 2015/0095308 A1, hereinafter referred to as “Kornacker”).
Zorin et al. (U.S. Publication No. 2023/0409386 A1, hereinafter referred to as “Zorin”).
Regarding claim 1, Kornacker discloses a method for automating multimodal computational workflows, which enables an analysis process of an instruction set to be performed automatically in a cloud environment, and the method for automating multimodal computational workflows comprising: (“the conversion may be fully automated between certain original formats and target formats, possibly based on specific schemas stored in the Hive metastore. For instance, every field in a CSV file can be automatically converted into a column in a Parquet file. The conversion may also be customized by an administrator or a user, who may decide to convert an input file into multiple output files in the same target format or different ones, each having select fields in the input file arranged in a specific order, for example.”)(e.g., figure 6, abstract and paragraphs [0038],[0053], [0054] and [0056])
performing a localizing step, wherein the localizing step comprises: (“a low latency (LL) query engine daemon can divide a query into fragments, which are distributed among remote nodes running additional low latency (LL) query engine daemons for execution in parallel.”)(e.g., figure 6 and paragraphs [0021] and [0029]-[0032])
configuring a loader to load a dataset into dataframes of a memory or copy the dataset to a local host file system from a data source; (“a low latency (LL) query engine daemon can divide a query into fragments, which are distributed among remote nodes running additional low latency (LL) query engine daemons for execution in parallel.”)(e.g., figure 6 and paragraphs [0021] and [0029]-[0032])
configuring a transformer to transform the dataframes of the memory into a transformed dataset so as to optimize downstream data processing; (“after a query is submitted, a query execution engine 320 on a data node which is to execute certain planned query fragments locally first transforms the files on the data node according to the schemas. Specifically, the query execution engine 320 reads a schema, which contains information on row and column endings, for example, for the files from the Hive metastore. It then reads the files from the data node, parses them in accordance with the file formats specified in the schema, and transforms the parsed data into a series of in-memory tuples according to further information in the schema. At that time, the query execution engine 320 is ready to execute the planned query fragments locally against the transformation result.”)(e.g., paragraphs [0032], [0038] and [0040])
configuring a formatter to format the transformed dataset to a formatted dataset; and (“a format conversion engine converts data to such a file format in the background to increase the efficiency of query processing at runtime. FIG. 5 contains a block diagram illustrating example components of a format conversion engine daemon installed on each data node in a Hadoop cluster.”)(e.g., paragraphs [0032]-[0036] and [0038])
configuring an executor to preprocess the formatted dataset as a managed table for a first command or save the formatted dataset to the local host file system for a second command; (“The scheduler 412 determines when to perform the format conversion based on input by an administrator or a user, and notifies the converter when the time comes. In one example, the scheduler 412 uses a timer for performing the format conversion periodically or at certain points in the future. The certain point in the future could be measured from the occurrence of an event, such as the creation, initial update, or last update of the data. In other examples, the conversion is performed when the data has been updated, searched, searched with the same queries, and so on, for a certain number of times. Accordingly, the scheduler 412 keeps a counter of the total number of updates, of all queries, of specific queries, of distinct queries, and so on, so that the format conversion can be performed when the criteria involving these numbers are met. In further examples, the status of resource utilization on the data node is taken into consideration in scheduling the format conversion.”)(e.g., paragraphs [0027], [0029] and [0036])
performing a processing step, wherein the processing step comprises configuring a workflow engine executing on multiple processors to perform a task command of the instruction set on the dataset copied by the loader, the managed table or the formatted dataset to generate command outputs according to one of the first command and the second command; and (“The installation manager 302 can automatically install, configure, manage and monitor the various engines. Alternately, the engines may be installed manually. The installation manger 302 installs four binaries including a low latency (LL) query engine daemon 304, a state store daemon 306, a low latency (LL) query engine shell 308 and a format conversion engine daemon 310. As described above, the low latency (LL) query engine daemon 304 is a service or process that plans and executes queries against HDFS and/or HBase data. It is installed on each data node in the cluster. The format conversion engine daemon is a service or process that converts data from its original format to a condensed format. It is also installed on each data node in the cluster.)(e.g., figures 3-6 and paragraph [0027])
performing a delocalizing step, wherein the delocalizing step comprises: (e.g., paragraphs [0023], [0031] and [0032])
configuring a collector to postprocess the command outputs outputted from the memory or retrieve the command outputs from the local host file system; and (“initially, data comes in and is stored in their original format on the HDFS data nodes. One or more associated schemas comprising information on file formats in which data is stored, which can be created by a user or an administrator, are saved separately in the Hive metastore 106, at the same time as the data is stored or at a later time. In one embodiment, after a query is submitted, a query execution engine 320 on a data node which is to execute certain planned query fragments locally first transforms the files on the data node according to the schemas. Specifically, the query execution engine 320 reads a schema, which contains information on row and column endings, for example, for the files from the Hive metastore. It then reads the files from the data node, parses them in accordance with the file formats specified in the schema, and transforms the parsed data into a series of in-memory tuples according to further information in the schema. At that time, the query execution engine 320 is ready to execute the planned query fragments locally against the transformation result.”)(e.g., figures 3-6 and paragraph [0032])
configuring a writer to save the command outputs to a storage; (“With the format conversion engine daemon, in one embodiment, after a query is submitted, a query planner would set up the plan fragments to indicate that converted data is available. The query execution engine on a data node then no longer needs to perform a complex transformation of the data on the data node. It can simply read the converted data from the data node, which would essentially be in a tuple form. The format conversion engine daemon therefore provides some benefits of the schema-on-write model by reducing the processing time when the data is used in query processing, without suffering some costs of the model, which requires a large processing time when the data is uploaded and updated.”)(e.g., figure 6 and paragraphs [0031] and [0040]-[0042]) wherein the first command is different from the second command. (“At step 602, a query planner receives a query. At step 603, the query planner reviews relevant schema information to identify the available file formats in which data is stored. If only data in an original format is available, at step 604, the query planner defines plan fragments for the original format. If data in a converted target format is also available, however, at step 606, the query planner defines plan fragments for the target format.”)(e.g., figures 3-6 and paragraphs [0040]-[0042])

Regarding claim 2, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein in the localizing step, the loader is configured to perform single-file read or split one file into multiple files for parallel reading. (“Each low latency (LL) query engine daemon 114a-c can receive, plan and coordinate queries received via the client's 102/104. For example, a low latency (LL) query engine daemon can divide a query into fragments, which are distributed among remote nodes running additional low latency (LL) query engine daemons for execution in parallel.”)(e.g., paragraph [0021]).

Regarding claim 4, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein in the localizing step, the formatter is configured to format the transformed dataset to the formatted dataset by converting schema, adding or deleting columns, and encoding domain specific object. (“The query planner 316 may constitute the front end of the low latency (LL) query engine daemon written in Java or another suitable language to facilitate interaction with the rest of the Hadoop environment, such as the Hive metastore, the state store, APIs, and the like. The query planner 316 can use various operators such as Scan, HashJoin, HashAggregation, Union, TopN, Exchange, and the like to construct a query plan. Each operator can either materialize or generate data or combine data in some way. In one implementation, for example, the query planner can create a lefty plan or tree of one or more operators (e.g., manually or using an optimizer).“ “the converter 414 maintains a list of one or more target formats. It converts the data on the data node to one of the target formats based on input by an administrator a user, and saves the converted data on the data node along with the original data. For example, the converter 414 may read a file in the CSV format from the data node into memory, parse the file in accordance with the CSV format, convert it into a chosen Parquet format, and saves the file in the Parquet format on the data node together with the file in the CSV format. In one embodiment, the conversion may be fully automated between certain original formats and target formats, possibly based on specific schemas stored in the Hive metastore. For instance, every field in a CSV file can be automatically converted into a column in a Parquet file. The conversion may also be customized by an administrator or a user, who may decide to convert an input file into multiple output files in the same target format or different ones, each having select fields in the input file arranged in a specific order, for example. In another embodiment, the converter 414 also deletes certain conversion results upon receiving a notification from the scheduler 412.”)(e.g., abstract and paragraphs [0025], [0029] and [0038]).

Regarding claim 5, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein in the localizing step, the executor is configured to save a plurality of the formatted datasets to the local host file system for the second command, each of the formatted datasets comprises a plurality of subparts, same subparts of the formatted datasets are paired together, and the same subparts are corresponding to the formatted datasets, respectively; (“As a target format is typically a condensed format that is conducive to relational database processing, having data ready in a target format speeds up processing of SQL-like queries. As the format conversion is performed at carefully selected time points in the background, it tends to minimize the use of resources and interference with other operations on the data nodes.” “At step 612, the query execution engine executes the collection of planned query fragments using the in-memory tuples. By virtue of these features, a user is given the flexibility of being able to experiment with datasets having different structures without incurring much overhead in data upload and update while being able to extract specific insight from the datasets in an efficient manner.”)(e.g., figure 7 and paragraphs [0021] and [0038]-[0042])
wherein the first command of the executor is a Structural Query Language (SQL) command, and the second command of the executor is an executable program. (“The queries are executed directly on the HDFS (e.g., 120a-c) and/or HBase (e.g., 122a-c).”)(e.g., paragraphs [0021], [0023], and [0025]-[0027])

Regarding claim 6, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein in the delocalizing step, in response to determining that the collector retrieves the command outputs from the local host file system, the collector is configured to compute aggregates of the command outputs. (“The query planner 316 can use various operators such as Scan, HashJoin, HashAggregation, Union, TopN, Exchange, and the like to construct a query plan. Each operator can either materialize or generate data or combine data in some way. In one implementation, for example, the query planner can create a lefty plan or tree of one or more operators (e.g., manually or using an optimizer). The scan operator allows a plan to be broken up along scan lines or boundaries. Specialized scan nodes may be present for different storage managers. For example, there may be an HDFS scan node and an HBase scan node, each of which can internally employ different processes for different file formats. Some plans combine data for hash aggregation which can fill up a hash table and then output the aggregate results.”)(e.g., paragraphs [0029] and [0030]).

Regarding claim 7, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein the instruction set comprises a plurality of tasks, each of the tasks is corresponding to the localizing step, the processing step and the delocalizing step, each of inputs of each of the tasks is partitioned into a plurality of parts, same parts of the inputs are performed by a task process, and each of the same parts is corresponding to one of the parts of each of the inputs. (“The query coordinator 318 can also perform the final aggregation or merge of data from the low latency (LL) query engine daemons on remote data nodes. In one implementation, the low latency (LL) query engine daemons may pre-aggregate some of the data, thereby distributing the aggregation across the data nodes and speeding up the query processing.”)(e.g., figure 6 and paragraphs [0021], [0023]-[0025] and [0030]).

Regarding claim 8, Kornacker discloses the method for automating multimodal computational workflows of claim 1. Kornacker further discloses wherein the dataset comprises at least one file, in response to determining that a number of the at least one file is plural, the dataset is regarded as an array of the files and corresponding to a plurality of operator pipelines; (“The HDFS name node (NN) 110 includes the details of the distribution of files across the data nodes 120a-c to optimize local reads. In one implementation, the name node 110 may include information concerning disk volumes the files sit on, on an individual node.” “Existing Hadoop platform uses a batch-oriented query engine (i.e., MapReduce) for batch processing 216 of Hadoop data. The batch processing capability of MapReduce is complemented by a real-time access component 218 in the unified Hadoop platform 212. The real-time access component 218 allows real-time, ad hoc SQL queries to be performed directly on the unified storage 220 via a distributed low latency (LL) query engine that is optimized for low-latency. The real-time access component 218 can thus support both queries and analytics on big data.”)(e.g., paragraphs [0023], [0025] and [0026])
wherein each of the operator pipelines comprises at least one of the loader, the transformer, the formatter and the executor and at least one of the collector and the writer. (“query execution engine 320 on a data node which is to execute certain planned query fragments locally first transforms the files on the data node according to the schemas. Specifically, the query execution engine 320 reads a schema, which contains information on row and column endings, for example, for the files from the Hive metastore. It then reads the files from the data node, parses them in accordance with the file formats specified in the schema, and transforms the parsed data into a series of in-memory tuples according to further information in the schema. At that time, the query execution engine 320 is ready to execute the planned query fragments locally against the transformation result.”)(e.g., figures 1, 4-6 and paragraphs [0032], [0033] and [0036]).

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.

The factual inquiries 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.
Claims 3, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kornacker in view of Asadi et al. (U.S. Publication No. 2013/0338934 A1, hereinafter referred to as “Asadi”).
Regarding claim 3, Kornacker discloses the method for automating multimodal computational workflows of claim 1. However, Kornacker does not appear to specifically disclose wherein in the localizing step, the transformer is configured to repartition the dataframes of the memory based on non-overlapping target regions in genome sequencing analysis.
On the other hand, Asadi, which relates to systems and methods for processing nucleic acid sequence data (title), does disclose wherein in the localizing step, the transformer is configured to repartition the dataframes of the memory based on non-overlapping target regions in genome sequencing analysis. (“a platform may include methods developed for structural variant calling. In one example method, the sequenced genome is divided into non-overlapping windows. The method takes as an input the number of reads centered within each window, which it can debias by taking into account the mappability and GC content. The method can then estimate the mean for each window, using a penalty which forces neighboring windows to have similar values. In some cases, this may make the read counts smoother, and may help to avoid false positives when the raw read count vector is analyzed. After estimating the mean for every bin, windows that show an anomalous read count can be tagged as variation regions. In some embodiments, the method proceeds by merging those regions and estimating the breakpoints of the duplications/deletions.”)(e.g., paragraph [0067]).
Kornacker discloses a format conversion engine for Apache Hadoop that converts data from its original format to a database-like format at certain time points for use by a low latency query engine. Abstract. In Kornacker, SQL applications provide a user interface for Hadoop to run queries or jobs, browse the HDFS, create workflows and the like. Paragraph [0020]. Kornacker discloses that the query is divided into fragments and distributed among remote nodes (e.g., paragraph [0021]; however, Kornacker does not appear to specifically disclose repartitioning the dataframes based on non-overlapping target regions in genome sequencing analysis. On the other hand, Asadi does disclose “the sequenced genome is divided into non-overlapping windows. The method takes as an input the number of reads centered within each window, which it can debias by taking into account the mappability and GC content. The method can then estimate the mean for each window, using a penalty which forces neighboring windows to have similar values.” E.g., paragraph [0067]. This provides a benefit, because “this may make the read counts smoother, and may help to avoid false positives when the raw read count vector is analyzed.” Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s claimed invention to incorporate the partitioning as disclosed in Asadi to Kornacker to further enhance the system of Kornacker to further employ the techniques to genomic data and to provide an effective manner for the data to be read.
Claim 12 has substantially similar limitations as stated in claim 3; therefore, it is rejected under the same subject matter.

Regarding claim 20, Kornacker discloses the non-transitory storage medium of claim 19. Kornacker further discloses wherein, in the localizing step, the loader is configured to perform single-file read or split one file into multiple files for parallel reading, (“Each low latency (LL) query engine daemon 114a-c can receive, plan and coordinate queries received via the client's 102/104. For example, a low latency (LL) query engine daemon can divide a query into fragments, which are distributed among remote nodes running additional low latency (LL) query engine daemons for execution in parallel.”)(e.g., paragraph [0021])
the formatter is configured to format the transformed dataset to the formatted dataset by converting schema, adding or deleting columns, and encoding domain specific object, (“The query planner 316 may constitute the front end of the low latency (LL) query engine daemon written in Java or another suitable language to facilitate interaction with the rest of the Hadoop environment, such as the Hive metastore, the state store, APIs, and the like. The query planner 316 can use various operators such as Scan, HashJoin, HashAggregation, Union, TopN, Exchange, and the like to construct a query plan. Each operator can either materialize or generate data or combine data in some way. In one implementation, for example, the query planner can create a lefty plan or tree of one or more operators (e.g., manually or using an optimizer).“ “the converter 414 maintains a list of one or more target formats. It converts the data on the data node to one of the target formats based on input by an administrator a user, and saves the converted data on the data node along with the original data. For example, the converter 414 may read a file in the CSV format from the data node into memory, parse the file in accordance with the CSV format, convert it into a chosen Parquet format, and saves the file in the Parquet format on the data node together with the file in the CSV format. In one embodiment, the conversion may be fully automated between certain original formats and target formats, possibly based on specific schemas stored in the Hive metastore. For instance, every field in a CSV file can be automatically converted into a column in a Parquet file. The conversion may also be customized by an administrator or a user, who may decide to convert an input file into multiple output files in the same target format or different ones, each having select fields in the input file arranged in a specific order, for example. In another embodiment, the converter 414 also deletes certain conversion results upon receiving a notification from the scheduler 412.”)(e.g., abstract and paragraphs [0025], [0029] and [0038]).
the executor is configured to save a plurality of the formatted datasets to the local host file system for the second command, each of the formatted datasets comprises a plurality of subparts, same subparts of the formatted datasets are paired together, the same subparts are corresponding to the formatted datasets, respectively, (“As a target format is typically a condensed format that is conducive to relational database processing, having data ready in a target format speeds up processing of SQL-like queries. As the format conversion is performed at carefully selected time points in the background, it tends to minimize the use of resources and interference with other operations on the data nodes.” “At step 612, the query execution engine executes the collection of planned query fragments using the in-memory tuples. By virtue of these features, a user is given the flexibility of being able to experiment with datasets having different structures without incurring much overhead in data upload and update while being able to extract specific insight from the datasets in an efficient manner.”)(e.g., figure 7 and paragraphs [0021] and [0038]-[0042])
the first command of the executor is a Structural Query Language (SQL) command, and the second command of the executor is an executable program; (“The queries are executed directly on the HDFS (e.g., 120a-c) and/or HBase (e.g., 122a-c).”)(e.g., paragraphs [0021], [0023], and [0025]-[0027])
and in the delocalizing step, in response to determining that the collector retrieves the command outputs from the local host file system, the collector is configured to compute aggregates of the command outputs. (“The query planner 316 can use various operators such as Scan, HashJoin, HashAggregation, Union, TopN, Exchange, and the like to construct a query plan. Each operator can either materialize or generate data or combine data in some way. In one implementation, for example, the query planner can create a lefty plan or tree of one or more operators (e.g., manually or using an optimizer). The scan operator allows a plan to be broken up along scan lines or boundaries. Specialized scan nodes may be present for different storage managers. For example, there may be an HDFS scan node and an HBase scan node, each of which can internally employ different processes for different file formats. Some plans combine data for hash aggregation which can fill up a hash table and then output the aggregate results.”)(e.g., paragraphs [0029] and [0030]).
However, Kornacker does not appear to specifically disclose the transformer is configured to repartition the dataframes of the memory based on non-overlapping target regions in genome sequencing analysis,
On the other hand, Asadi, which relates to systems and methods for processing nucleic acid sequence data (title), does disclose the transformer is configured to repartition the dataframes of the memory based on non-overlapping target regions in genome sequencing analysis, (“a platform may include methods developed for structural variant calling. In one example method, the sequenced genome is divided into non-overlapping windows. The method takes as an input the number of reads centered within each window, which it can debias by taking into account the mappability and GC content. The method can then estimate the mean for each window, using a penalty which forces neighboring windows to have similar values. In some cases, this may make the read counts smoother, and may help to avoid false positives when the raw read count vector is analyzed. After estimating the mean for every bin, windows that show an anomalous read count can be tagged as variation regions. In some embodiments, the method proceeds by merging those regions and estimating the breakpoints of the duplications/deletions.”)(e.g., paragraph [0067]).
It would have been obvious to combine Asadi with Kornacker for the same reasons as stated in claim 3, above.

Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kornacker in view of Ravid (U.S. Publication No. 2020/0278845 A1, hereinafter referred to as “Ravid”).
Regarding claim 9, Kornacker discloses the method for automating multimodal computational workflows of claim 1. However, Kornacker does not appear to specifically disclose wherein, in response to determining that the instruction set is performed automatically in the cloud environment, a cache is configured to record a state of a task, and the workflow engine confirms whether the task is executed completely through a test run; in response to determining that the task is executed completely through the test run, the task is not re-executed; and in response to determining that the task is not executed completely through the test run, the cache records a failure result, and the task is re-executed actually according to the failure result.
On the other hand, Ravid, which relates to a method and system for development wherein, in response to determining that the instruction set is performed automatically in the cloud environment, a cache is configured to record a state of a task, and the workflow engine confirms whether the task is executed completely through a test run; (“application server 96 activates business logic 98 to perform tasks without involvement of client application component 94a. This enables dealing with tasks at the application server without the need to develop a special procedure in the client application for each different task. Further, it may separate the client user interface from the business logic and thus, for example, provide a more efficient development process, task management, and/or application structure.”)(e.g., paragraph [0083])
in response to determining that the task is executed completely through the test run, the task is not re-executed; (“In some embodiments, when a certain complex 30 is at the stage of performing a task, the parameters and/or results of the task performing stage is written to non-volatile storage 38 in relation to the certain complex 30. Additionally, in some embodiments, a task may be stored in complex cache 37b of the certain complex 30, for example for runtime operations and/or for efficiency of the task operations.”)(e.g., paragraph [0083])
and in response to determining that the task is not executed completely through the test run, the cache records a failure result, and the task is re-executed actually according to the failure result. (“server 96 may obtain from cache 37b a state of task execution in order to inform component 94a about this state. For example, the state of a task execution may be obtained from cache 37b in order to enable monitoring, examination and/or displaying of the state. For example, in case of an error, application server 96 may restore the parameters and/or results of the task performing stage from storage 38 and/or cache 37b.”)(e.g., paragraph [0083])
Kornacker discloses a format conversion engine for Apache Hadoop that converts data from its original format to a database-like format at certain time points for use by a low latency query engine. Abstract. In Kornacker, SQL applications provide a user interface for Hadoop to run queries or jobs, browse the HDFS, create workflows and the like. Paragraph [0020]. Kornacker discloses that the query is divided into fragments and distributed among remote nodes (e.g., paragraph [0021]; however, Kornacker does not appear to specifically disclose the cached maintaining a status of whether execution occurred or whether the task failed. On the other hand, Ravid, which relates to workflow (e.g., paragraph [0086]), does disclose keeping state information, along with whether process failed within a cache. E.g., paragraph [0083]. This provides an effective manner to monitor the status and provide the ability to restart failed processes so that the workflow may complete and run efficiently. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s claimed invention to maintain task status and to re-execute failed processes as disclosed in Ravid to Kornacker to improve the manner in which queries are performed and to ensure the process completes so that users receive complete query results.
Claim 18 has substantially similar limitations as stated in claim 9; therefore, it is rejected under the same subject matter.

Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
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, Aleksandr Kerzhner can be reached at (571)270-1760. 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.

/RICHARD L BOWEN/ Primary Examiner, Art Unit 2165