DETAILED ACTION
This action is responsive to the Application filed 7/23/2024.
Accordingly, claims 1-20 are submitted for prosecution on merits.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the following 2 step analysis.
Step I: the claim is directed to a process category.
Step 2A:
Prong one:
The claim 1 recites "triggering execution of objects through packages using parallel threads execution, each package... including a defined number of objects; determining to adjust the pre-defined number of objects per package... to an adjusted number... and adjusting the execution of parallel threads to execute the second set of packages...", which, specifically, amounts to a core focus of an algorithmic rule for data management: dynamically calculating and re-sizing data batches ("packages") to be processed. The underlying concept of grouping data items, calculating an optimal batch size, and adjusting the workload distribution represents fundamental data manipulation and data organization.
Calculating, scaling and adjusting number of objects within data packages is a mathematical process. In Digitech Image Technologies, LLC v. Electronics for Imaging, Inc., 758 F.3d 1344 (Fed. Cir. 2014), the court established that gathering, organizing, and manipulating data via mathematical rules constitutes an ineligible abstract idea.
The step of "determining to adjust... to an adjusted number" relies on a conditional, logical determination that can be performed via generic mathematical scaling or standard operational logic, the determining step being an activity that can be performed by a human mind.
The claim language is directed to an Abstract Idea because it falls under the recognized groupings of Mathematical Concepts and Certain Methods of Organizing Human Activity / Mental Steps – MPEP § 2106.04.
Prong two:
The claim relies entirely on generic, functional, and results-oriented language ("triggering execution," "determining to adjust," "adjusting the execution"). It does not recite how the parallel threads are adjusted at a hardware or operating system level, nor does it disclose an improvement to the computer’s structural architecture.
The claim merely invokes conventional computer capabilities ("parallel threads execution") as a tool to execute the abstract optimization logic. Under Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016), using generic computer processing power to collect, analyze, and manipulate data according to logical rules fails to provide a practical integration. Instead, the mathematical/logical concept remains abstract because it is not restricted to a specific, improved technological process
Viewed as a whole, the method claim does not integrate the judicial exception into a practical application because it lacks any limitations that apply, relate, or bind the abstract idea to a specific technical solution to a technical problem. MPEP § 2106.04(d)
Step 2B:
The recitation of "objects" and "packages" (as additional elements) describes generic software data structures well-known in the computing arts. The recitation of "parallel threads execution" (as additional elements) is a generic, routine processing mechanism present in standard multi-core computing architectures (MPEP § 2106.05(d)). The steps recited as "determining to adjust" and "adjusting the execution" expressed in a high level of generality are viewed purely as functional instructions to "apply" the abstract batching logic using whatever conventional computing tools are available.
When viewed as an ordered combination, the steps merely describe the sequential execution of the abstract idea on a generic computer. The combination does not alter the physical operation of the processor, nor does it override conventional multi-threading protocols. It simply instructs the practitioner to perform standard load-balancing using generic parallel execution - MPEP 2106.05(a) (b) (c )
Under Alice Corp., 573 U.S. at 218, merely implementing an abstract idea on a conventional, generic computer does not supply the "significantly more" required for a concrete Accordingly, because the claim lacks an inventive concept, it fails to provide "significantly more," and is rejected under 35 U.S.C. § 101.
Accordingly, because claim 1 lacks an inventive concept, it fails to provide "significantly more," than the abstract idea; claim 1 is non-eligible under 35 U.S.C. § 101.
Claims 10 and 19 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 10 and 19 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the following 2 step analysis
A-Eligibility of claim 10
Step I: this claim is directed to a medium/product category.
Step 2a:
Prong one: the elements recited as “triggering execution of objects through packages using parallel threads execution, each package... including a defined number of objects; determining to adjust the pre-defined number of objects per package... to an adjusted number... and adjusting the execution of parallel threads to execute the second set of packages...", amount to a core algorithmic rule for data management: dynamically calculating and re-sizing data batches ("packages") to be processed, according to which, the underlying concept of grouping data items, calculating an optimal batch size, and adjusting the workload distribution represents fundamental data manipulation and data organization. That is, calculating, scaling and adjusting number of objects within data packages can be viewed as gathering, organizing, and manipulating data via mathematical rules and this constitutes an ineligible abstract idea an ineligible abstract idea.
The step of "determining to adjust... to an adjusted number" relies on a conditional, logical determination that can be performed via generic mathematical scaling or standard operational logic, the determining step being an activity that can be performed by a human mind.
The claim language is directed to an Abstract Idea because it falls under the recognized groupings of Mathematical Concepts and Certain Methods of Organizing Human Activity / Mental Steps – MPEP § 2106.04.
Prong two:
The elements recited as "triggering execution," "determining to adjust," "adjusting the execution" are viewed as expression of generic, functional, and results-oriented language, as opposed to details showing transformation being made to the computer level. As for parallel threads, there is nothing indicative of hardware being adjusted at a concrete computer structural level or operating system level, nor does it disclose an improvement to the computer’s structural architecture
The claim is viewed as a generic computer processing power to collect, analyze, and manipulate data according to general functionality or intended use, thus fails to provide a practical integration. Instead, the mathematical/logical concept remains abstract because it is not restricted to a specific, improved technological process
The medium claim does not integrate the judicial exception into a practical application because it lacks any limitations that apply, relate, or bind the abstract idea to a specific technical solution to a technical problem. MPEP § 2106.04(d)
Step 2B:
The recitation of "objects" and "packages" (as additional elements) describes generic software data structures well-known in the computing arts. The recitation of "parallel threads execution" (as additional elements) is a generic, routine processing mechanism present in standard multi-core computing architectures (MPEP § 2106.05(d)). The steps recited as "determining to adjust" and "adjusting the execution" expressed in a high level of generality are viewed purely as functional instructions to "apply" the abstract batching logic using whatever conventional computing tools are available.
When viewed as an ordered combination, the steps merely describe the sequential execution of the abstract idea on a generic computer. The combination does not alter the physical operation of the processor, nor does it override conventional multi-threading protocols. It simply instructs the practitioner to perform standard load-balancing using generic parallel execution - MPEP 2106.05(a) (b) (c )
Claim 10 can be viewed as listing of generic, conventional functionalities which cannot add significantly more to the abstract Idea.
B. Eligibility of claim 19.
This claim is directed to a system/apparatus category.
Step 2A:
Per prong one:
In light of “triggering execution of objects through packages using parallel threads execution, each package... including a defined number of objects; determining to adjust the pre-defined number of objects per package... to an adjusted number... and adjusting the execution of parallel threads to execute the second set of packages...", the claim amounts to dynamically calculating and re-sizing data batches ("packages") to be processed, according to which, the underlying concept of grouping data items, calculating an optimal batch size, and adjusting the workload distribution represents fundamental data manipulation and data organization.
Per prong two:
The language of this claim (“triggering execution," "determining to adjust," "adjusting the execution") is same as that of claim 10; accordingly, calculating, scaling and adjusting number of objects within data packages can be viewed as gathering, organizing, and manipulating data via mathematical rules and this constitutes an ineligible abstract idea.
The step of "determining to adjust... to an adjusted number" relies on a conditional, logical determination that can be performed via generic mathematical scaling or standard operational logic, the determining itself being an activity that can be performed in a human mind.
Claim 19 is directed to an Abstract Idea because it falls under the recognized groupings of Mathematical Concepts and Certain Methods of Organizing Human Activity / Mental Steps – MPEP § 2106.04.
Step 2B:
The recitation of "objects" and "packages" (as additional elements) describes generic software data structures well-known in the computing arts. The recitation of "parallel threads execution" (as additional elements) is a generic, routine processing mechanism present in standard multi-core computing architectures (MPEP § 2106.05(d)). The steps recited as "determining to adjust" and "adjusting the execution" expressed in a high level of generality are viewed purely as functional instructions to "apply" the abstract batching logic using whatever conventional computing tools are available.
When viewed as an ordered combination, the steps merely describe the sequential execution of the abstract idea on a generic computer. The combination does not alter the physical operation of the processor, nor does it override conventional multi-threading protocols. It simply instructs the practitioner to perform standard load-balancing using generic parallel execution.
MPEP 2106.05(a) (b) (c)
Claim 19 is thus viewed as listing of generic, conventional functionalities which cannot add significantly more to the abstract Idea.
Step 2B Analysis of dependent claims.
Claims 2, 11, and 20 recite defining objects to be tested, each being a source code and provided for parallel thread during execution of first or second set of packages. The provision of objects for in intended use amount to mere gathering of elements targeted for a usage, and this data gathering cannot add significantly more to the abstract Idea.
Claims 3 and 12 recite “determining” (to adjust number of objects) when a successful number threshold has been acquired; and determining can be viewed as activity by a mental process.
Claims 4 and 13 recite “determining” to adjust in terms of monitoring execution; and the monitoring act can be interpreted as activity performed mentally or via human cognitive capacity.
Claims 5 and 14 recite “obtaining” performance data related to execution, evaluating it and identifying patterns; all of which being typical activities done by a mental process with use of a generic computer to mentally derive new conclusion or patterns.
Claims 6 and 15 recite generating a configuration definition (in response to evaluating performance) where number of objects as defined is set for package execution in a sequence. The act of “generating a configuration” amounts to a extra-solution activity and configuration so that sets of package are to be executed in sequence amounts to a generic expression of a intended use, not concrete details showing how a statically generated configuration of package of objects improves or optimizes the runtime of a computer technology.
Claims 7 and 16 recite a relationship between a set of packages and number of objects and order of the package sequence, and this static description cannot be viewed as a transformation that would add significantly more to the Abstract Idea; nor can it specifically integrate the Abstract Idea into a practical application.
Claims 8 and 17 recited intended use for a generated configuration, and this cannot be viewed as a transformation that would add significantly more to the Abstract Idea, and which can integrate the Abstract Idea into a practical Application.
Claims 9 and 18 recite a field of use for the triggering of packages in response to a request and effect of having size of the package dynamically modified based on the generated configuration. A field of use for set of packages cannot amount to a novel transformation in the computer context in which the Abstract Idea operates; and the act of modifying size of a package for execution in response to a configuration can be viewed as real-time activity by a developer via use of a generic computer, in which no improvement of any sort is observed from the very high level of generality of concept recited as “ generated configuration” (defining number of objects).
In all, claims 1-20 are non-eligible under the statute of 35 § 101 statute.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4-7, 10, 13-16, 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sun Qi-shun, CN 116501499 (translation) 09-19-2023,16 pgs (herein Sun).
As per claim 1, Sun discloses a computer-implemented method for dynamic parallel execution of operations, comprising:
triggering an execution of objects through packages (batch tasks – pg. 2; all the pre-set running batch task …arrange to the thread number – pg. 2 – Note1: each preset batch task instance among other preset batch task instances – pg. 2; pre-set running batch tasks arranged to several threads – pg.6 - reads on preset first and second packages each for running with parallel threads) using parallel threads (through plurality of the threads; are executed by multiple threads on a batch running server – pg. 2) at an execution engine (e.g. running batch server; batch task can be obtained by Runtime – pg. 10), wherein each package of a first set of packages defined for the execution includes a pre-defined number of objects (parameter configuration … according to the thread number, the maximum allowable memory of each thread … batch task … arrange to the thread number of the thread – pg. 3; writing block in the batch – pg. 4; running tasks under the appointed thread number – middle, pg.7 – Note2: preset write blocks and number of threads associated with the write task reads on predefined one or more objects in each package execution);
determining to adjust the pre-defined number of objects (reducing the size of the writing block in the batch – pg. 9; reducing the size of, increasing the size of – pg. 4) per package as defined for the first set of packages at the parallel threads (see Note1) to an adjusted number of objects (reducing the size of the writing block in the batch – pg. 9; reducing the size of, increasing the size of – pg. 4) per package (refer to Note1) to define a second set of packages (Note3: tasks in batch where size of write blocks are reduced or increased reads on second set of packages configured for running with adjusted number of objects; e.g. so to control the writing frequency, pressure between running server and database server … can be balanced, sequence and safety of the running batch are ensured – pg. 9 ); and
adjusting (see reducing, increasing – pg. 4, pg. 9) the execution (see Note1 and batch task instances) at the parallel threads to execute the second set (see Note3) of packages through the execution engine (see Runtime of running server from above), wherein each package of the second set of packages includes the adjusted number of objects (see above).
As per claim 4, Sun discloses computer-implemented method of claim 1, wherein determining to adjust the pre-defined number of objects per package comprises:
monitoring execution of the first set of packages (batch running server is monitored – pg. 2, 3) at the parallel threads (monitoring module for monitoring … when all the preset batch running tasks are executed by multiple threads – pg. 4).
As per claim 5, Sun discloses computer-implemented method of claim 1, comprising:
obtaining performance data (on the basis of performance such as resource occupation and time consumption information – pg. 5; writing frequency – pg. 9; performance index … will be monitored, memory pressure – pg. 11) related to the execution of the first set of packages and the second set of packages (refer to Note1 of claim 1) using the parallel threads (refer to claim 1); and
evaluating the performance data (e.g. performance index … will be monitored, memory pressure of the running batch … is large; resource occupation information and time consumption information – pg. 11) to identify patterns in changes (resource occupation and time consumption - pg. 11; reduce the total execution time of the task – pg. 5) of execution time of the packages.
As per claim 6, Sun discloses computer-implemented method of claim 5, comprising:
in response to evaluating the performance data (refer to claim 5), generating a configuration to define a number of objects (reducing the size of the writing block in the batch – pg. 9; reducing the size of, increasing the size of – pg. 4) to be executed per package for a set of packages, wherein a plurality of sets of packages (refer to Note1 in claim 1) are defined for execution at the parallel threads (refer to claim 1), and
wherein a number of objects (writing block in the batch – pg. 9; comprises a thread number for executing a running batch … a maximum allowable memory of each thread – pg. 2) per package is associated with each respective set of the plurality of sets of packages, wherein the plurality of sets of packages (pre-set batch task and the execution sequence of each pre-set running batch task – bottom, pg. 6; execution sequence of each pre-set running batch … is used for arranging all preset running batch tasks - top pg .7) are executed in a sequence using the parallel threads (refer to claim 1).
As per claim 7, Sun discloses computer-implemented method of claim 6, wherein each set of the plurality of sets of packages in the sequence (refer to claim 6) is associated with a respective number of objects (configuration instruction … comprises a thread number for executing a running batch … a maximum allowable memory of each thread – pg. 2; execution sequence of each pre-set running batch … all preset running batch tasks… are arranged to the thread number - pg. 3) per package, wherein
numbers of objects (see above; writing block in the batch – pg. 9 ) per package per set for the plurality of sets are defined in an increasing order of the sequence (factors affecting the pre-set running batch task arrangement … wherein the task execution order is mainly to arrange the preset batch task … according to the data dependence order of the preset batch running task to … effectively finishing all preset batch running tasks under the appointed thread number – pg. 7).
As per claim 10, Sun discloses a non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform operations comprising:
triggering an execution of objects through packages using parallel threads at an execution
engine, wherein each package of a first set of packages defined for the execution includes a pre-defined number of objects;
determining to adjust the pre-defined number of objects per package as defined for the first
set of packages at the parallel threads to an adjusted number of objects per package to define a second set of packages; and
adjusting the execution at the parallel threads to execute the second set of packages through
the execution engine, wherein each package of the second set of packages includes the adjusted
number of objects.
( All of which having been addressed in claim 1)
As per claim 13, refer to claim 4
As per claim 14, refer to claim 5
As per claim 15, Sun discloses non-transitory, computer-readable medium of claim 14, further storing instructions executable by the computer system to perform operations comprising:
in response to evaluating the performance data, generating a configuration to define a
number of objects to be executed per package for a set of packages, wherein a plurality of sets of
packages are defined for execution at the parallel threads, and wherein a number of objects per
package is associated with each respective set of the plurality of sets of packages, wherein the
plurality of sets of packages are executed in a sequence using the parallel threads.
(refer to rejection of claim 6)
As per claim 16, Sun discloses non-transitory, computer-readable medium of claim 15, wherein each set of the plurality of sets of packages in the sequence is associated with a respective number of objects per package, wherein numbers of objects per package per set for the plurality of sets are defined in an increasing order of the sequence.
(refer to rejection of claim 7)
As per claim 19, Sun discloses a computer-implemented system, comprising: one or more computers; and one or more computer memory devices inter-operably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform operations comprising:
triggering an execution of objects through packages using parallel threads at an
execution engine, wherein each package of a first set of packages defined for the execution
includes a pre-defined number of objects;
determining to adjust the pre-defined number of objects per package as defined for
the first set of packages at the parallel threads to an adjusted number of objects per package to
define a second set of packages; and
adjusting the execution at the parallel threads to execute the second set of packages
through the execution engine, wherein each package of the second set of packages includes the
adjusted number of objects.
( All of which having been addressed in claim 1)
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.
Claims 2, 8-9, 11, 17-18, 20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Sun Qi-shun, CN 116501499 (translation) 09-19-2023,16 pgs (herein Sun) in view of Moorthi et al, USPubN: 2013/0152047 (herein Moorthi) and Peng, Yi-qun, CN 117422025, (translation) 01-19-2024, 31 pgs (herein Peng) and Yu dan et al, CN 114741281A, (translation) 07-12-2022, 14 pgs (herein Yu)
As per claim 2, Sun does not explicitly disclose computer-implemented method of claim 1, comprising:
defining a project comprising the objects to be tested, wherein an object of the objects
represents a source code unit at a source code repository; and
providing the objects of the project for execution at the parallel threads, wherein the objects
of the project are tested during the execution of the first set of packages and the second set of
packages.
Sun discloses providing objects for execution according to parallel thread mode during execution of first batch-test set and second batch-test set and this entails parallel thread execution for a first set of packages or a second set of packages within a batch testing environment.
Yu discloses batch software testing and use of test result report to solve any problem of the batch software testing with automatic batch adaptation to a problem (see Abstract; pg. 3) via comprehensive adaptive evaluation and decision to improve labor cost and improving efficiency of the application software (pg. 2), via an test environment according to which, each batch test processing a plurality of software items is to be tested according to requirement, environment information and to-be-tested list of software (pg. 2), where use of test report from a batch testing can be used to solve issues of automatic batch adaptation, the upgrade thereof as part of an adaptive evaluation to save cost in labor and efficiency of the application (bottom pg.5 top pg. 6; bottom pg. 6 top pg. 7); hence constructing test for software in form of batch test configuration with adaptive upgrade to the application of batch per feedback from batch test result is recognized.
Peng discloses a debug, simulation/verification under of a RISC-V architecture associated with quality regression test wherein a large program code is organized in batches to increase the number of simulations (bottom pg. 12, top pg. 13) by the RISCV architecture, where compilation and simulation of the code is associated with a VCS compilation and verification module (pg. 8, top pg. 13) according to which the testing is to be performed in batch with output of corresponding simulation log (pg. 14), based on which, a resource-flexible verification is adapted to monitor only register changing function(s), with effect of dynamically modify HW resources for occupying an area being monitored, and reducing size of a log (pg. 5) so to redirect different simulators to adaptively cover test to only functions of concerns by the target program. Hence, in association with a RISC-based compiler/verification environment, testing software program from source code control system organized in batches where feedback from simulation output log is adapted toward modifying resources associated with the batch testing is recognized.
Moorthi discloses a CLI-based test environment where a suite registration associates source code with a test suite for configuring test cases via a UI (para 0165-0167), where the testing is using results from various runs of the test batch to resolve issues or overhead (para 0274-0275) associated with tasks of executed batches where report logs from batch run to batch run (para 0267) provided by a batch run service in terms of values and HTTP responses or value-pair messages (para 0231-0232) indicative of a status result, enable test execution environment to perform automatic configuration from one test run to the next so to optimize test performance (para 0261-0262), the automated runtime configuration such as effecting a sub-optimal parallelism from turning a static allocation of fixed batch size into a rough imposing a max amount of VM allocation into each test task (para 0363), or resolving this sub-optimality with an allocation scheme that accounts only for the number of tests being run (para 0364); hence, configuration of source code for batch testing with dynamic resource adjusting from a rigid content batch size to a scheme that accounts for the number of tests achieved is recognized.
Therefore, based on Sun’s batch test configured with the parallel thread execution during execution in which a first set of packages or second set of packages are adaptively configured with size adjusting based on test reports and task arrangement via real-time judgement of resources (pg. 10), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention so that the batch execution adaptive modification can be applied to test of software program – as in Yu, Moorthi and Peng – or to test of source code maintained from repository (VCS as in Peng), where a test project associated thereof include objects to be tested, each object representing a source code unit at a source code repository (as in Peng); whereby the objects of the project are provided for execution at the parallel threads – as in Sun - wherein the objects of the project are tested during the execution of the first set of packages and the second set of packages; because
batch testing using parallel threads execution enable concurrency of test tasks to cut down on the overall execution time, obviating needlessly distribution of the test across test groups and coordination between different hardware units to achieve a same result; e.g. the concurrent thread execution increasing throughput of the test, efficient verification of code and consolidation of a software into a VCS - and
ordering batch under control of the SW or source code versioning developers via proper scheduling and registering as set forth above, will facilitate management of batch execution should a error incurred with each batch stage; e.g. enabling thereby the SW developer to halt a batch test instance in a sequence, reconfigure the software, make necessary amendment and resubmit code change back into the next scheduled batch flow without risk of error propagation across the whole project; and
enabling adaptive batch allocation or sizing along with real-time information obtained for the batch task execution as set forth above, would tie up high throughput of the testing with how availability or limitation of resources at hands is being exploited; e.g. adapting or altering the scale of data to be tested (auto-scaling of batch) dynamic with an actual HW condition, type/nature of a fault, a peak demand timing of a environment, or limiting constraint of a host architecture.
As per claim 8, Sun discloses computer-implemented method of claim 6, comprising:
providing the generated configuration (refer to claim 6) for use at a testing framework (refer to rationale of claim 2).
As per claim 9, Sun does not explicitly disclose computer-implemented method of claim 8, wherein the objects checked during the execution of the first set of packages and the second set of packages are part of a first version of a project defined for a software solution, and comprising:
receiving a request to perform a test through the testing framework, the test being performed over a new version of the project, wherein the new version of the project includes at least a portion of the objects included at the first version of the project; and
triggering execution of packages using parallel threads at an execution engine, wherein a
size of a package triggered for execution over time using the parallel threads is dynamically
modified based on the generated configuration.
However, Sun discloses batch task arrangement in accordance to thread parallel execution (refer to claim 1) mode by each pre-set running batch; where a size of a package in terms of executable units/objects triggered for execution over time using the parallel threads is dynamically
modified based on the generated configuration (refer to claim 6; obviousness in rationale of claim 2)
Maintenance of source code is shown in Peng VCS where a given program under a VCS compiler entails a given version of program under the VCS can be subjected to a verification using a compilation test RISC-C framework in which testing can be implemented via batches (bottom pg. 12, top pg. 13), according to which, pipeline of compilation test integrated with version control with provision of regression test to ensure ingestion of deployed and tested code by team members to repository (pg.13), the testing using flexible resources modification is performed in response to execution report or results, including flexible dynamic re-allocation of resources (pg. 5) so that part of resource allocation (size of log) is given to a runtime coverage directed to only functional portions of interest, diverting the resources from portions that are deemed not causing resources change under the test.
Therefore, based on batch processing of Sun via execution in threaded mode, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement flexible and dynamic size adjust of batch execution in Sun so that
objects checked during the execution of the first set of packages and the second set of packages are part of a first version of a project defined for a software solution – part the VCS environment in Peng where program code is being verified;
in which a request to perform a test through the testing framework is received from a team member intent to ingest a new version of the SW project to the VCS repository – as in Peng; wherein the new version of the project includes at least a portion of the objects included at the first version of the project to be verified, as via a regression test flow in Peng; where the test is carried out with triggering execution of packages (or batches) using parallel threads – as set forth in Sun - at an execution engine, wherein a size of a package triggered for execution over time using the parallel threads is dynamically modified – as per Sun, Yu and Moorthi per rationale A in claim 2 - based on the generated configuration (refer to claim 6); because
batch testing using parallel threads execution would enable concurrency of test tasks so to cut down on the overall execution time, obviating needlessly distribution of the test across test groups and coordination between different hardware units to achieve a same result; e.g. the concurrent thread execution increasing throughput of the test, efficient verification of code and consolidation of a software into a VCS - and
ordering batch under control of the SW or source code versioning developers via proper scheduling and registering as set forth above, will facilitate management of batch execution should a error incurred with each batch stage; e.g. enabling thereby the SW developer to halt a batch test instance in a sequence, reconfigure the software, make necessary amendment and resubmit code change back into the next scheduled batch flow without risk of error propagation across the whole project; resulting in proper verifying a project SW version before committing it to repository; and
enabling adaptive batch allocation or sizing along with real-time information obtained for the batch task execution as set forth above, would tie up high throughput of the testing with how availability or limitation of resources at hands is being exploited; e.g. adapting or altering the scale of data (number of objects per batch) to be tested (auto-scaling of batch) dynamic with an actual HW condition, type/nature of a fault, a peak demand timing of a environment, or limiting constraint of a host architecture.
As per claim 11, Sun discloses non-transitory, computer-readable medium of claim 10, further storing instructions executable by the computer system to perform operations comprising:
defining a project comprising the objects to be tested, wherein an object of the objects
represents a source code unit at a source code repository; and
providing the objects of the project for execution at the parallel threads, wherein the objects
of the project are tested during the execution of the first set of packages and the second set of
packages.
( All of which having been addressed in claim 2)
As per claim 17, refer to claim 8.
As per claim 18, refer to rationale of claim 9.
As per claim 20, refer to rationale of claim 2.
Claims 3, 12 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Sun Qi-shun, CN 116501499 (translation) 09-19-2023,16 pgs (herein Sun) in view of Cui et al, USPubN: 2020/0042362 (herein Cui) and Moorthi et al, USPubN: 2013/0152047 (herein Moorthi).
As per claim 3, Sun does not explicitly disclose computer-implemented method of claim 1, wherein determining to adjust the pre-defined number of objects is performed
when a threshold number of packages including the pre-defined number of objects have been successfully executed using the parallel threads.
Moorthi discloses configuration of source code for batch testing with dynamic resource adjusting for resolving a sub-optimal parallelism configured with rough Max VM allocation per batch size (para 0363) with an adopted scheme that only accounts for the number of test tasks being achieved (para 0364) in each batch; hence resolving an rough allocation scheme relying on a fixed number of executing units inside a batch execution causing a sub-optimal parallelism execution with a allocation scheme that accounts for the most number of test tasks achieved inside each batch entails determination to adjust allocation of objects (VMs) in a batch based on optimality of parallelism achieved by the size of objects inside a batch.
Cui discloses a similar dynamic allocation adjusting in terms of self-adaptive batch dataset partitioning control process which utilizes trained information on balancing of resources (Fig. 4) to determine optimal partition for internal mini-batch datasets among other sub-batch datasets, where partitioning each sub-dataset into a optimal batch size can minimize completion time of the intended project or service (see Abstract), including a batch size tuning effected with determining job completion time by objects in a mini-batch in accordance to a corresponding sub-task dataset, comparing deviation threshold of each mini-batch iteration in regard to such completion with a standard deviation threshold, and responsive to a determined deviation exceeding the standard value, adjusting the partition ratio so partition a next mini-batch data for a next mini-batch iteration for a next iteration among the remaining iterations (para 0005; claim 20, pg. 14) to rebalance the resources and finetune batch processing and accelerate job flow (claim 2, pg. 12) of a provisioning service; hence determining how many objects have completed jobs inside each mini-batch partitioning and using a comparison against a threshold of completion/deviation to re-partition size of the datasets into sub-dataset of the remaining mini-batches based on such comparison as part of the rebalancing of resources entails determining to adjust the pre-defined number of objects based on a pre-defined number of objects that have been successfully executed, via use of a deviation threshold reference.
Thus, as Sun’s batch test is configured with the parallel thread execution during execution in which a first set of packages or second set of packages are adaptively configured with size adjusting based on test reports, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement determination of efficiency of the parallel thread execution of batch test in Sun so that determination to adjust the pre-defined number of objects is based on a threshold number of packages associated with the batch processing in regard to percent or amount the pre-defined number of objects therein that have been successfully executed – as set forth in Cui - using the parallel threads as set forth in Moorthi scheme to address optimality of parallelism; because
a adaptive batch tuning process that make direct use of a reference metric such as completion percentage or “successfully achieved” threshold/measure in regard to evaluation each batch partitioning or execution units allocated therewith as set forth above in order to determine if the completion rate or percentage is deemed sufficient or else would trigger immediate adjust to the batch size or allocation in near real-time, so that the flow of batch processing can be rearranged with proper adjust in resources nearly in the same dynamic flow of the batch processing, without incurring delay or needless interruption of the batch processing, while utilization of resources can benefit from a measure of optimization as determination to re-allocate or rescale executable content of each batch is particularly driven from state of available resources assessed in real-time to support the batch process size tuning as set forth above, e.g. with minimal interruption of the batch processing in which parallel execution of batch jobs (test tasks) is specifically purported to gain high throughput in shortest execution time, and whose actual achievement is being assessed concurrently within the course of batch execution flow in form of dynamic batch tuning as set forth above.
As per claim 12, Sun discloses non-transitory, computer-readable medium of claim 10, wherein determining to adjust the pre-defined number of objects is performed when a threshold number of packages including the pre-defined number of objects have been successfully executed using the parallel threads.
(refer to rationale of claim 3)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
July 19, 2026
Prosecution Insights