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 .
Response to Amendment
This Office action is in response to Applicant's amendment filed on 3/30/2026.
Claim 1-30 are pending. Claim 1, 11 and 21 are amended. Claim 1-30 are rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 1-2, 11-12 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Rath, Jagannathdas et al (PGPUB Document No. 20220283998), hereafter, referred to as “Rath”.
Claim 1(Currently Amended), Yan teaches A method comprising: retrieving, by at least one hardware processor in a database system, a database table, the database table comprising a plurality of partitions(Yan, para 0033 discloses identifying partitions for table in response to queries or data retrieval “metadata for each partition of a table is stored in a metadata store, and the metadata can be used to identify which partition of the table needs to be scanned to respond to a query”);
generating a plurality of batches for the database table based on a file selection task of the database system, each batch of the plurality of batches comprising a partition subset of the plurality of partitions(Yan, para 0101 discloses plurality to batches are being generated based on selection of range of the partition “The micro-batches (see 914) are generated based on the sorted order of the partitions within the candidate range. The micro-batches may be fed into a clustering worker that is configured to recluster each micro-batch”; where para 0033 further discloses partitions are on database table “Partitioning is a canonical data warehouse technique wherein a large table is divided horizontally into smaller units according to explicitly defined partitioning functions…”),the plurality of batches being stored in a batch queue(Yan, para 0117 discloses batches are being queued for execution “The database table may be added back to the queue where the existing batchset comprising one or more micro-batches (see e.g. the micro-batches determined at 914) is finished”);
and performing concurrent execution of the plurality of execution jobs to cluster the partition subset associated with each of the plurality of execution jobs(Yan, para 0086 discloses concurrently executing clustering job/task “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
But Yan does not explicitly teach determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset;
configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric,
an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
However, in the same field of endeavor of concurrent job execution Beisiegel teaches determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset(Beisiegel, para 0021 discloses determination/measurement of data size difference or skew between largest size of a shard/batch and smallest shard/batch “a metric measuring uneven data distribution over shards in an index (for example, measured as the difference between data size of the largest shard and the smallest shard)”; para 0031 further disclose “the difference between the data size of the largest shard and the smallest shard exceeding 5 GB may be a trigger event”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of determining skew between shard or group of data and partitioning index of Beisiegel into clustering of batch data of Yan to produce an expected result of making the data query run faster. The modification would be obvious because one of ordinary skill in the art would be motivated to improve search performance by portioning index in multiple indices so that the data that is most relevant at a given time is searched first (Beisiegel, para 0003-0004).
But Yan and Beisiegel don’t explicitly configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric,
an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
However, in the same field of endeavor of concurrent compression job execution in a batch Seshadri teaches configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric (Seshadri, para 0128 discloses selection of batch size based on compression ratio metric “Compressibility of data is an important metric to select the right compression mechanism and the batch size. A highly compressible record with a lower compression ratio is well suited for a smaller sub-batch aligned with the write page size. In contrast, large or more random (less compressible) data records are better suited for being written in larger batch sizes”; where Yan in para 0117 teaches selection of batches from a queue “A partition selection task will run first and select one or more micro-batches for follow-up recluster execution tasks. The database table may be added back to the queue where the existing batchset comprising one or more micro-batches”; there the limitation “ordering the batches based on the compression ratio metric” is taught by prior art Koba to be discussed later).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on compression ratio records/data of Seshadri into clustering of batch data of Yan and Beisiegel to produce an expected result of making batch selection by compression ratio .The modification would be obvious because one of ordinary skill in the art would be motivated to improve capacity savings and execution process performances (Seshadri, para 0018).
But Yan, Beisiegel and Seshadri don’t explicitly ordering the batches based on the compression ratio metric; an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of file compression Koba teaches ordering the batches based on the compression ratio metric(Koba, in para 0044 discloses ordering batches/files based on their compression ratio “the playlist creation and execution section 108 sorts all the image files designated in the selected playlists in order from the lowest compression ratio to the highest compression ratio”);
Using the broadest reasonable interpretation consistent with the specification as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “batch” to mean a collection of files which is also a file.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of ordering batches/files based on their compression ratio of Koba into clustering of batch data of Yan, Beisiegel and Seshadri to produce an expected result of executing batch files by their compression ratio. The modification would be obvious because one of ordinary skill in the art would be motivated to sort batch files by their compression ratios for convenient batch file execution management (Koba, para 0040-0044).
But Yan, Beisiegel, Seshadri and Koba don’t explicitly an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of concurrent job execution Fuller teaches an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew (Fuller, claim 1 discloses configuring/adjusting job based on size of data items/batch files to a threshold “MapReduce job, wherein said partitioning comprises changing the size of the input data based on an execution duration associated with the MapReduce job, wherein said changing comprises……. (ii) decreasing the size of the input data if said execution duration is greater than the given threshold, and wherein said partitioning comprises ensuring that the number of input data items having a size below a given size is less than a predetermined threshold number”).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0030-0031) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “the skew of batch sizes for the batch subset being below a threshold skew” to mean difference in size of files among a set or group of files below a threshold.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on batch/data size of Fuller into clustering of batch data of Yan, Beisiegel, Seshadri and Koba to produce an expected result of making the data query to run on a smaller partition/s of a table. The modification would be obvious because one of ordinary skill in the art would be motivated to achieve increasing parallelization by partitioning data (Fuller, col 2: 31-34).
Regarding claim 2 (Previously Presented), Yan, Beisiegel, Seshadri and Fuller teach all the limitations of claim 1 and Yan further wherein the compression ratio metric is a ratio of total raw bytes to total compressed bytes for the batch, and the method further comprising(as per the long standing definition, “compression ratio” is well known and understood defined as the ratio between raw or uncompressed data size/bytes to compressed data size or bytes. See paragraph 0027 of the reference ‘998 (Rath) for support): generating a plurality of clustered partition subsets based on completion of clustering of the partition subset for each of the plurality of execution jobs (Yan, para 0086 discloses generation of clustering for batches of partitions “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
Claim 11(Currently Amended), Yan teaches A system comprising: at least one hardware processor; and at least one memory storing instructions that cause the at least one hardware processor to perform operations comprising(Yan, Fig. 18 and para 0154 discloses a system comprising of processor and storages for executing operations): retrieving a database table of a database system, the database table comprising a plurality of partitions (Yan, para 0033 discloses identifying partitions for table in response to queries or data retrieval “metadata for each partition of a table is stored in a metadata store, and the metadata can be used to identify which partition of the table needs to be scanned to respond to a query”);
generating a plurality of batches for the database table based on a file selection task of the database system, each batch of the plurality of batches comprising a partition subset of the plurality of partitions (Yan, para 0101 discloses plurality to batches are being generated based on selection of range of the partition “The micro-batches (see 914) are generated based on the sorted order of the partitions within the candidate range. The micro-batches may be fed into a clustering worker that is configured to recluster each micro-batch”; where para 0033 further discloses partitions are on database table “Partitioning is a canonical data warehouse technique wherein a large table is divided horizontally into smaller units according to explicitly defined partitioning functions…”) the plurality of batches being stored in a batch queue(Yan, para 0117 discloses batches are being queued for execution “The database table may be added back to the queue where the existing batchset comprising one or more micro-batches (see e.g. the micro-batches determined at 914) is finished”);
and performing concurrent execution of the plurality of execution jobs to cluster the partition subset associated with each of the plurality of execution jobs (Yan, para 0086 discloses concurrently executing clustering job/task “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
But Yan does not explicitly teach determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset; configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric,
an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
However, in the same field of endeavor of concurrent job execution Beisiegel teaches determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset (Beisiegel, para 0021 discloses determination/measurement of data size difference or skew between largest size of a shard/batch and smallest shard/batch “a metric measuring uneven data distribution over shards in an index (for example, measured as the difference between data size of the largest shard and the smallest shard)”; para 0031 further disclose “the difference between the data size of the largest shard and the smallest shard exceeding 5 GB may be a trigger event”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of determining skew between shard or group of data and partitioning index of Beisiegel into clustering of batch data of Yan to produce an expected result of making the data query run faster. The modification would be obvious because one of ordinary skill in the art would be motivated to improve search performance by portioning index in multiple indices so that the data that is most relevant at a given time is searched first (Beisiegel, para 0003-0004).
But Yan and Beisiegel don’t explicitly teach configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric, an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
However, in the same field of endeavor of concurrent compression job execution in a batch Seshadri teaches configuring a plurality of execution jobs based on an execution management task of the database system, the execution management task the execution management task selecting batches from the batch queue and grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric (Seshadri, para 0128 discloses selection of batch size based on compression ratio metric “Compressibility of data is an important metric to select the right compression mechanism and the batch size. A highly compressible record with a lower compression ratio is well suited for a smaller sub-batch aligned with the write page size. In contrast, large or more random (less compressible) data records are better suited for being written in larger batch sizes” where Yan in para 0117 teaches selection of batches from a queue “A partition selection task will run first and select one or more micro-batches for follow-up recluster execution tasks. The database table may be added back to the queue where the existing batchset comprising one or more micro-batches”; there the limitation “ordering the batches based on the compression ratio metric” is taught by prior art Koba to be discussed later)..
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on compression ratio records/data of Seshadri into clustering of batch data of Yan and Beisiegel to produce an expected result of making batch selection by compression ratio .The modification would be obvious because one of ordinary skill in the art would be motivated to improve capacity savings and execution process performances (Seshadri, para 0018).
But Yan, Beisiegel and Seshadri don’t explicitly ordering the batches based on the compression ratio metric; an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of file compression Koba teaches ordering the batches based on the compression ratio metric(Koba, in para 0044 discloses ordering batches/files based on their compression ratio “the playlist creation and execution section 108 sorts all the image files designated in the selected playlists in order from the lowest compression ratio to the highest compression ratio”);
Using the broadest reasonable interpretation consistent with the specification as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “batch” to mean a collection of files which is also a file.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of ordering batches/files based on their compression ratio of Koba into clustering of batch data of Yan, Beisiegel and Seshadri to produce an expected result of executing batch files by their compression ratio. The modification would be obvious because one of ordinary skill in the art would be motivated to sort batch files by their compression ratios for convenient batch file execution management (Koba, para 0040-0044).
But Yan, Beisiegel, Seshadri and Koba don’t explicitly an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of concurrent job execution Fuller teaches an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew (Fuller, claim 1 discloses configuring/adjusting job based on size of data items/batch files to a threshold “MapReduce job, wherein said partitioning comprises changing the size of the input data based on an execution duration associated with the MapReduce job, wherein said changing comprises……. (ii) decreasing the size of the input data if said execution duration is greater than the given threshold, and wherein said partitioning comprises ensuring that the number of input data items having a size below a given size is less than a predetermined threshold number”).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0030-0031) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “the skew of batch sizes for the batch subset being below a threshold skew” to mean difference in size of files among a set or group of files below a threshold.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on batch/data size of Fuller into clustering of batch data of Yan, Beisiegel. Seshadri and Koba to produce an expected result of making the data query to run on a smaller partition/s of a table. The modification would be obvious because one of ordinary skill in the art would be motivated to achieve increasing parallelization by partitioning data (Fuller, col 2: 31-34).
Regarding claim 12 (Previously Presented), Yan, Beisiegel, Seshadri and Fuller teach all the limitations of claim 11 and Yan further wherein the compression ratio metric is a ratio of total raw bytes to total compressed bytes for the batch, and the operations further comprising (as per the long standing definition, “compression ratio” is well known and understood defined as the ratio between raw or uncompressed data size/bytes to compressed data size or bytes. See paragraph 0027 of the reference ‘998 (Rath) for support): generating a plurality of clustered partition subsets based on completion of clustering of the partition subset for each of the plurality of execution jobs(Yan, para 0086 discloses generation of clustering for batches of partitions “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
Claim 21(Currently Amended), Yan teaches A computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising(Yan, Fig. 18 and para 0154 discloses a system comprising of processor and storages for executing operations): retrieving a database table of a database system, the database table comprising a plurality of partitions (Yan, para 0033 discloses identifying partitions for table in response to queries or data retrieval “metadata for each partition of a table is stored in a metadata store, and the metadata can be used to identify which partition of the table needs to be scanned to respond to a query”);
generating a plurality of batches for the database table based on a file selection task of the database system, each batch of the plurality of batches comprising a partition subset of the plurality of partitions (Yan, para 0101 discloses plurality to batches are being generated based on selection of range of the partition “The micro-batches (see 914) are generated based on the sorted order of the partitions within the candidate range. The micro-batches may be fed into a clustering worker that is configured to recluster each micro-batch”; where para 0033 further discloses partitions are on database table “Partitioning is a canonical data warehouse technique wherein a large table is divided horizontally into smaller units according to explicitly defined partitioning functions…”), the plurality of batches being stored in a batch queue(Yan, para 0117 discloses batches are being queued for execution “The database table may be added back to the queue where the existing batchset comprising one or more micro-batches (see e.g. the micro-batches determined at 914) is finished”);
and performing concurrent execution of the plurality of execution jobs to cluster the partition subset associated with each of the plurality of execution jobs (Yan, para 0086 discloses concurrently executing clustering job/task “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
But Yan does not explicitly teach determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset; configuring a plurality of execution jobs based on an execution management task selecting batches from the batch queue and of the database system, the execution management task grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric,
an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
However, in the same field of endeavor of concurrent job execution Beisiegel teaches determining a skew of batch sizes for a batch subset of the plurality of batches based on a maximum difference between a size of a largest batch and a size of a smallest batch in the batch subset (Beisiegel, para 0021 discloses determination/measurement of data size difference or skew between largest size of a shard/batch and smallest shard/batch “a metric measuring uneven data distribution over shards in an index (for example, measured as the difference between data size of the largest shard and the smallest shard)”; para 0031 further disclose “the difference between the data size of the largest shard and the smallest shard exceeding 5 GB may be a trigger event”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of determining skew between shard or group of data and partitioning index of Beisiegel into clustering of batch data of Yan to produce an expected result of making the data query run faster. The modification would be obvious because one of ordinary skill in the art would be motivated to improve search performance by portioning index in multiple indices so that the data that is most relevant at a given time is searched first (Beisiegel, para 0003-0004).
But Yan and Beisiegel don’t explicitly teach configuring a plurality of execution jobs based on an execution management task selecting batches from the batch queue and of the database system, the execution management task grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric,
an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew;
Using the broadest reasonable interpretation consistent with the specification (paragraph 0030-0031) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “the skew of batch sizes for the batch subset being below a threshold skew” to mean difference in size of files among a set or group of files below a threshold.
However, in the same field of endeavor of concurrent compression job execution in a batch Seshadri teaches configuring a plurality of execution jobs based on an execution management task selecting batches from the batch queue and of the database system, the execution management task grouping batches within the batch subset based on a compression ratio metric for each batch in the batch subset by ordering the batches based on the compression ratio metric (Seshadri, para 0128 discloses selection of batch size based on compression ratio metric “Compressibility of data is an important metric to select the right compression mechanism and the batch size. A highly compressible record with a lower compression ratio is well suited for a smaller sub-batch aligned with the write page size. In contrast, large or more random (less compressible) data records are better suited for being written in larger batch sizes”; where Yan in para 0117 teaches selection of batches from a queue “A partition selection task will run first and select one or more micro-batches for follow-up recluster execution tasks. The database table may be added back to the queue where the existing batchset comprising one or more micro-batches”; there the limitation “ordering the batches based on the compression ratio metric” is taught by prior art Koba to be discussed later).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on compression ratio records/data of Seshadri into clustering of batch data of Yan and Beisiegel to produce an expected result of making batch selection by compression ratio .The modification would be obvious because one of ordinary skill in the art would be motivated to improve capacity savings and execution process performances (Seshadri, para 0018).
But Yan, Beisiegel and Seshadri don’t explicitly ordering the batches based on the compression ratio metric; an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of file compression Koba teaches ordering the batches based on the compression ratio metric(Koba, in para 0044 discloses ordering batches/files based on their compression ratio “the playlist creation and execution section 108 sorts all the image files designated in the selected playlists in order from the lowest compression ratio to the highest compression ratio”);
Using the broadest reasonable interpretation consistent with the specification as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “batch” to mean a collection of files which is also a file.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of ordering batches/files based on their compression ratio of Koba into clustering of batch data of Yan, Beisiegel and Seshadri to produce an expected result of executing batch files by their compression ratio. The modification would be obvious because one of ordinary skill in the art would be motivated to sort batch files by their compression ratios for convenient batch file execution management (Koba, para 0040-0044).
But Yan, Beisiegel, Seshadri and Koba don’t explicitly But Yan, Beisiegel, Seshadri and Koba don’t explicitly an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew.
However, in the same field of endeavor of concurrent job execution Fuller teaches an execution job of the plurality of execution jobs including the batch subset of the plurality of batches, and the skew of batch sizes for the batch subset being below a threshold skew (Fuller, claim 1 discloses configuring/adjusting job based on size of data items/batch files to a threshold “MapReduce job, wherein said partitioning comprises changing the size of the input data based on an execution duration associated with the MapReduce job, wherein said changing comprises……. (ii) decreasing the size of the input data if said execution duration is greater than the given threshold, and wherein said partitioning comprises ensuring that the number of input data items having a size below a given size is less than a predetermined threshold number”).
Using the broadest reasonable interpretation consistent with the specification (paragraph 0030-0031) as it would be interpreted by one of ordinary skill in the art, examiner is interpreting the limitation “the skew of batch sizes for the batch subset being below a threshold skew” to mean difference in size of files among a set or group of files below a threshold.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of configuring jobs based on batch/data size of Fuller into clustering of batch data of Yan, Beisiegel, Seshadri and Koba to produce an expected result of making the data query to run on a smaller partition/s of a table. The modification would be obvious because one of ordinary skill in the art would be motivated to achieve increasing parallelization by partitioning data (Fuller, col 2: 31-34).
Regarding claim 22 (Previously Presented), Yan, Beisiegel, Seshadri, Fuller and Koba teach all the limitations of claim 21 and Yan further wherein the compression ratio metric is a ratio of total raw bytes to total compressed bytes for the batch, and the operations further comprising (as per the long standing definition, “compression ratio” is well known and understood defined as the ratio between raw or uncompressed data size/bytes to compressed data size or bytes. See paragraph 0027 of the reference ‘998 (Rath) for support): generating a plurality of clustered partition subsets based on completion of clustering of the partition subset for each of the plurality of execution jobs(Yan, para 0086 discloses generation of clustering for batches of partitions “The clustering component 712 is configured to recluster a micro-batch of database partitions. The clustering execution is performed concurrently by multiple workers as opposed to a single worker”).
Claim 3-4, 7, 13-14, 17, 23-24 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in further view of Pavlov, Vladimir (PGPUB Document No. 20060053087), hereafter, referred to as “Pavlov”.
Regarding claim 3 (Original), Yan, Beisiegel, Seshadri, Fuller and Koba teach all the limitations of claim 2 but don’t explicitly teach activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table (Pavlov, para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of table/cluster locking of Pavlov into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller and Koba to produce an expected result of controlling concurrent transaction on same data. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction performance by allowing to read uncommitted reads of data so that data transaction don’t have to wait until another transaction completes (Pavlov, para 0091).
Regarding claim 4 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 3 and Pavlov further teaches further comprising: activating the clustering lock based on a number of data manipulation language (DML) locks placed on the database table by transactions in the transactional queue(Pavlov, para 0055 discloses locking of data cluster is common to table lock for transaction “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”; where para 0054 discloses that transaction operations are DML operation such as table update operations “when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Regarding claim 7(Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 4 and Pavlov further teaches wherein at least one of the transactions in the transactional queue is a user DML query placing a DML lock of the DML locks on the database table(Pavlov, where para 0054 discloses that transaction operations are DML operation such as table update operations which are to be locked for table update “…..when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Regarding claim 13(Original), Yan, Beisiegel, Seshadri, Fuller and Koba teach all the limitations of claim 12 but don’t explicitly teach the operations further comprising: activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches the operations further comprising: activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table (Pavlov, para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of table/cluster locking of Pavlov into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller and Koba to produce an expected result of controlling concurrent transaction on same data. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction performance by allowing to read uncommitted reads of data so that data transaction don’t have to wait until another transaction completes (Pavlov, para 0091).
Regarding claim 14 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 13 and Pavlov further teaches the operations further comprising: activating the clustering lock based on a number of data manipulation language (DML) locks placed on the database table by transactions in the transactional queue (Pavlov, para 0055 discloses locking of data cluster is common to table lock for transaction “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”; where para 0054 discloses that transaction operations are DML operation such as table update operations “when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Regarding claim 17(Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 14 and Pavlov further teaches wherein at least one of the transactions in the transactional queue is a user DML query placing a DML lock of the DML locks on the database table (Pavlov, where para 0054 discloses that transaction operations are DML operation such as table update operations which are to be locked for table update “…..when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Regarding claim 23 (Original), Yan, Beisiegel, Seshadri, Fuller and Koba teach all the limitations of claim 22 but don’t explicitly teach the operations further comprising: activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches the operations further comprising: activating a clustering lock on the plurality of clustered partition subsets, the clustering lock configured in a transactional queue for committing clustered data to the database table (Pavlov, para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of table/cluster locking of Pavlov into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller and Koba to produce an expected result of controlling concurrent transaction on same data. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the transaction performance by allowing to read uncommitted reads of data so that data transaction don’t have to wait until another transaction completes (Pavlov, para 0091).
Regarding claim 24(Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 23 and Pavlov further teaches the operations further comprising: activating the clustering lock based on a number of data manipulation language (DML) locks placed on the database table by transactions in the transactional queue (Pavlov, para 0055 discloses locking of data cluster is common to table lock for transaction “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”; where para 0054 discloses that transaction operations are DML operation such as table update operations “when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Regarding claim 27(Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 24 and Pavlov further teaches wherein at least one of the transactions in the transactional queue is a user DML query placing a DML lock of the DML locks on the database table (Pavlov, where para 0054 discloses that transaction operations are DML operation such as table update operations which are to be locked for table update “…..when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism”).
Claim 5, 15 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in further view of Pavlov, Vladimir (PGPUB Document No. 20060053087), hereafter, referred to as “Pavlov”, in further view of Bingli, Lun (Chinese Patent Document No. CN 113254185), hereafter, referred to as “Bingli”.
Regarding claim 5 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 4 but don’t explicitly teach further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”; where Pavlov in para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov to produce an expected result of activating cluster lock based on DML locks. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes(Bingli, para 0005).
Regarding claim 15 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 14 but don’t explicitly teach the operations further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches the operations further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”; where Pavlov in para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov to produce an expected result of activating cluster lock based on DML locks. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes(Bingli, para 0005).
Regarding claim 25 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov teach all the limitations of claim 24 but don’t explicitly teach the operations further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table.
However, in the same field of endeavor of locking data cluster and database table Pavlov teaches the operations further comprising: activating the clustering lock further based on a number of execution jobs in the plurality of execution jobs being higher than a maximum number of DML locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”; where Pavlov in para 0055 discloses locking of data cluster associated with table locking for transactions “the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Fuller, Koba and Pavlov to produce an expected result of activating cluster lock based on DML locks. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes(Bingli, para 0005).
Claim 6, 16 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in further view of Pavlov, Vladimir (PGPUB Document No. 20060053087), hereafter, referred to as “Pavlov”, in further view of Bingli, Lun (Chinese Patent Document No. CN 113254185), hereafter, referred to as “Bingli”, in further view of Wang, Miao-yu et al (Chinese Patent Document No. CN 116311620), hereafter, referred to as “Wang”.
Regarding claim 6 (Original), Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli teach all the limitations of claim 5 but don’t explicitly teach further comprising: releasing the clustering lock when the number of DML locks is below a threshold number.
However, in the same field of endeavor of locking data Wang teaches further comprising: releasing the clustering lock when the number of DML locks is below a threshold number(Wang, para 0011 discloses releasing/unlocking data access based on a threshold number of database unlock/lock “An execution module is used to release the locked state of the smart lock if the number of matches between the real-time unlocking data and the sample unlocking data in the smart lock unlocking database reaches a preset number threshold.”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of unlocking data based on a locking threshold of Wang into clustering of batch data of Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli to produce an expected result of activating cluster lock based on a locking/unlocking threshold. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of locking by acquiring unlocking data(Wang, para 0003).
Regarding claim 16(Original), Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli teach all the limitations of claim 15 but don’t explicitly teach the operations further comprising: releasing the clustering lock when the number of DML locks is below a threshold number.
However, in the same field of endeavor of locking data Wang teaches the operations further comprising: releasing the clustering lock when the number of DML locks is below a threshold number (Wang, para 0011 discloses releasing/unlocking data access based on a threshold number of database unlock/lock “An execution module is used to release the locked state of the smart lock if the number of matches between the real-time unlocking data and the sample unlocking data in the smart lock unlocking database reaches a preset number threshold.”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of unlocking data based on a locking threshold of Wang into clustering of batch data of Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli to produce an expected result of activating cluster lock based on a locking/unlocking threshold. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of locking by acquiring unlocking data(Wang, para 0003).
Regarding claim 26 (Original), Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli teach all the limitations of claim 25 but don’t explicitly teach the operations further comprising: releasing the clustering lock when the number of DML locks is below a threshold number.
However, in the same field of endeavor of locking data Wang teaches the operations further comprising: releasing the clustering lock when the number of DML locks is below a threshold number (Wang, para 0011 discloses releasing/unlocking data access based on a threshold number of database unlock/lock “An execution module is used to release the locked state of the smart lock if the number of matches between the real-time unlocking data and the sample unlocking data in the smart lock unlocking database reaches a preset number threshold.”)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of unlocking data based on a locking threshold of Wang into clustering of batch data of Yan, Beisiegel, Seshadri, Koba, Fuller, Pavlov and Bingli to produce an expected result of activating cluster lock based on a locking/unlocking threshold. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the efficiency of locking by acquiring unlocking data(Wang, para 0003).
Claim 8, 18 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in further view of Bingli, Lun (Chinese Patent Document No. CN 113254185), hereafter, referred to as “Bingli”.
Regarding claim 8 (Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 1 but don’t explicitly teach further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table.
However, in the same field of endeavor of locking database table for transaction execution Bingli teaches further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of scheduling jobs for execution. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes(Bingli, para 0005).
Regarding claim 18(Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 11 but don’t explicitly teach the operations further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table.
However, in the same field of endeavor of locking database table for transaction execution Bingli teaches the operations further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of scheduling jobs for execution. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes(Bingli, para 0005).
Regarding claim 28(Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 21 but don’t explicitly teach the operations further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table.
However, in the same field of endeavor of locking database table for transaction execution Bingli teaches the operations further comprising: selecting a number of execution jobs in the plurality of execution jobs based on a maximum number of data manipulation language (DML) locks that can be placed on the database table (Bingli, para 0053 discloses job selection for execution on the basis of DML lock “further selects a preset number of scheduling job files to be executed from the obtained scheduling job files based on the pessimistic locking mechanism of the database”; para 0055 further discloses aforementioned lock is DML lock which prevents database DML operations such as update “the terminal device can implement the row lock mechanism of the pessimistic lock mechanism of the database in advance by using the "SELECT...FOR UPDATE" statement, that is, the task scheduling node - SCHEDULER executes the "SELECT...FOR UPDATE" statement to select and execute the DAG file to avoid conflicts between multiple SCHEDULERs.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of selecting number of executable jobs based on database table lock of Bingli into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of scheduling jobs for execution. The modification would be obvious because one of ordinary skill in the art would be motivated to improve the stability of task scheduling and resource utilization by scheduling tasks in multiple nodes (Bingli, para 0005).
Claim 9-10, 19-20 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over Yan, Jiaqi et al (PGPUB Document No. 20200026695), hereafter referred as to “Yan”, in view of Beisiegel, Michael et al (PGPUB Document No. 20160171071), hereafter, referred to as “Beisiegel”, in view of Seshadri, Sangeetha et al (PGPUB Document No. 20200349108), hereafter, referred to as “Seshadri”, in view of Koba, Toshinori (PGPUB Document No. 20050158028), hereafter, referred to as “Koba”, in view of Fuller, Nicholas et al (US Patent No. 9886310), hereafter, referred to as “Fuller”, in further view of Patterson, Brian et al (PGPUB Document No. 20050154827), hereafter, referred to as “Patterson”.
Regarding claim 9 (Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 1 but don’t explicitly teach further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs.
However, in the same field of endeavor of concurrent job execution Patterson teaches further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs (Patterson, claim 5 teaches tracking of jobs and determining total number of completed jobs “determining a number of jobs received, completed, and passed on by a process; comparing the number of jobs received by the process and a sum of the number of jobs completed and passed on by the process”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of tracking job status of Patterson into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of tacking job status. The modification would be obvious because one of ordinary skill in the art would be motivated to corrective actions for any hand jobs by comparing total number of received jobs to total number of completed jobs (Patterson, abstract).
Regarding claim 10 (Original), Yan, Beisiegel, Seshadri, Koba, Fuller and Patterson teach all the limitations of claim 9 and Patterson further teaches further comprising: configuring at least one additional execution job based on the total number of completed execution jobs, the at least one additional execution job including a remaining subset of the plurality of batches (Patterson, para 0035 discloses based on the total number of job count, a new/additional job “there are more jobs being received than jobs being processed and/or passed on. Such conditions may be indicative of a hang, and the corrective action may be a reset which clears all commands and initiates a new request for jobs to be resent from the host/source (or other device) in the system that sent the original jobs”; where Yan in para 0101 teaches jobs containing subset of partitions).
Regarding claim 19 (Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 11 but don’t explicitly teach he operations further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs.
However, in the same field of endeavor of concurrent job execution Patterson teaches he operations further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs (Patterson, claim 5 teaches tracking of jobs and determining total number of completed jobs “determining a number of jobs received, completed, and passed on by a process; comparing the number of jobs received by the process and a sum of the number of jobs completed and passed on by the process”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of tracking job status of Patterson into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of tacking job status. The modification would be obvious because one of ordinary skill in the art would be motivated to corrective actions for any hand jobs by comparing total number of received jobs to total number of completed jobs (Patterson, abstract).
Regarding claim 20 (Original), Yan, Beisiegel, Seshadri, Koba, Fuller and Patterson teach all the limitations of claim 19 and Patterson further teaches the operations further comprising: configuring at least one additional execution job based on the total number of completed execution jobs, the at least one additional execution job including a remaining subset of the plurality of batches(Patterson, para 0035 discloses based on the total number of job count, a new/additional job “there are more jobs being received than jobs being processed and/or passed on. Such conditions may be indicative of a hang, and the corrective action may be a reset which clears all commands and initiates a new request for jobs to be resent from the host/source (or other device) in the system that sent the original jobs”; where Yan in para 0101 teaches jobs containing subset of partitions).
Regarding claim 29(Original), Yan, Beisiegel, Seshadri, Koba and Fuller teach all the limitations of claim 21 but don’t explicitly teach the operations further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs.
However, in the same field of endeavor of concurrent job execution Patterson teaches the operations further comprising: performing a successor check at completion of each execution job of the plurality of execution jobs to determine a total number of completed execution jobs of the plurality of execution jobs (Patterson, claim 5 teaches tracking of jobs and determining total number of completed jobs “determining a number of jobs received, completed, and passed on by a process; comparing the number of jobs received by the process and a sum of the number of jobs completed and passed on by the process”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of tracking job status of Patterson into clustering of batch data of Yan, Beisiegel, Seshadri, Koba and Fuller to produce an expected result of tacking job status. The modification would be obvious because one of ordinary skill in the art would be motivated to corrective actions for any hand jobs by comparing total number of received jobs to total number of completed jobs (Patterson, abstract).
Regarding claim 30 (Original), Yan, Beisiegel, Seshadri, Fuller, Koba and Patterson teach all the limitations of claim 29 and Patterson further teaches the operations further comprising: configuring at least one additional execution job based on the total number of completed execution jobs, the at least one additional execution job including a remaining subset of the plurality of batches (Patterson, para 0035 discloses based on the total number of job count, a new/additional job “there are more jobs being received than jobs being processed and/or passed on. Such conditions may be indicative of a hang, and the corrective action may be a reset which clears all commands and initiates a new request for jobs to be resent from the host/source (or other device) in the system that sent the original jobs”; where Yan in para 0101 teaches jobs containing subset of partitions).
Response to Arguments
Applicant’s arguments filed on 10/2/2025 have been fully considered but are
moot because the independent claim 1, 11 and 21 have been amended with newly added features which applicant’s arguments are directed towards. Since claims have been amended with new features, a new ground of rejection is presented.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 ABDULLAH A DAUD whose telephone number is (469)295-9283. The examiner can normally be reached M~F: 9:30 am~6:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amy Ng can be reached at 571-270-1698. 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.
/ABDULLAH A DAUD/Examiner, Art Unit 2164 /AMY NG/Supervisory Patent Examiner, Art Unit 2164
Prosecution Insights