DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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
2. This Office Action is in response to the applicant’s response to the Non-Final rejection filed on March 26, 2026.
3. Claims 1, 3-5, 7-11, 13-15, and 17-20 are pending and have been examined.
4. Claims 1, 4-5, 7-11, 8, 10, 11, 13-15 and 17-20 are amended5. Claims 2, 6, 12, and 16 are cancelled by the applicant.
Information Disclosure Statement
6. The information disclosure statement (IDS) submitted on March 26, 2026. The submission is in compliance with the provisions of 37 CFR 1.07
Response to Arguments
7. Applicant’s arguments, see “Claim Rejection – 35 U.S.C. § 112” filed on March 26, 2026, have been carefully considered and based on the amendments along with the remarks filed on page 11, the rejection is withdrawn.8. Applicant’s arguments, see “Claim Rejections – 35 U.S.C. § 101”, filed on March 26, 2026 have been considered based on the amendments the rejection is withdrawn. Now the claims recites: runtime statistics indicate network congestion or data skewness and updated join configuration including at least a broadcast hash join, selected to reduce network congestion and improve parallelism.9. Applicant’s arguments, see “Claim Rejections – 35 U.S.C. § 103”, filed on March 26, 2026 have been carefully considered and the arguments are related to newly added limitations and they addressed in the rejection below.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
13. Claims 1, 3-5, 7-11, 13-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Babu et al. US Patent 10,983,895 B2 (hereinafter Babu) in view of Adams et al. US Patent 12,530,354 B1 (hereinafter Adams).
Regarding claim 1, Babu discloses a method comprising:
receiving, by data processing hardware and from a user, a request to execute a recurring workload including a cohort of job executions by an analytics engine at a distributed computing system, the cohort defining a serial execution order for executing each of the workloads job executions (Babu [col. 10, lines 59-65] e.g., “The goal of the probe process 420 is to find X_next, which is one or more of a setting, parameter, cluster configuration, or application configuration…”. Babu further teaches viewing trends and comparisons across multiple executions of the same application. See also [col. 2, lines 58-60] e.g., “FIG. 17 illustrates an exemplary user interface 1700 that shows trends found for an application in a session according to one embodiment”, see also [col. 2, 61-63] e.g., “FIG. 18 illustrates an exemplary user interface 1800 that shows a comparison of two different executions of the same application in a session”. Babu teaches recurring executions of the same workload and subsequent executions using updated configuration);
based on the serial execution order, executing, by the data processing hardware and using the analytics engine and the updated join configuration, a second job execution (Babu [col. 2, lines 61-63] e.g., “FIG. 18 illustrates an exemplary user interface that shows a comparison of two different executions of the same application in a session, according to one embodiment”, see also [col. 10, lines 61-65] e.g., “The goal of the probe process 420 is to find X_next, which is one or more of a setting, parameter, cluster configuration, or application configuration that is most promising toward meeting the goal identified by the user”. The system executes a subsequent execution after determining X_next. This shows first execution and second execution. Babu teaches: run application, collect statistics, determine X_next, and run application again using X_next), [the updated join configuration defining a second join operation type different from the join operation type] (Adams [col. 5, lines 19-23] e.g., “…HashJoinDecision” (or HJD) RSO indicates an operation that can be configured to determine an optimal distributed execution method for each join operator. For example, the distributed execution can be a broadcast join or a hash-partitioned hash join.”. This correspond to the claim language. Because the claim requires, a) first execution – join type # 1, b) second execution – join type # 2. Explicitly teaches alternative join execution methods. First execution, equated with hash-partitioned hash join. Second execution, equated with broadcast join) to reduce an execution time and computing resources usage of the second job execution relative to the default join configuration (Adams [col. 5, lines 19-23] e.g., “…an operation that can be configured to determine an optimal distributed execution method for each join operator”, see also [col. 10, lines 49-56] e.g., “Job optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the job”); and
returning, by the data processing hardware and to the user, results of execution of the first job execution and the second job execution (Babu [col. 2, lines 61-63] e.g., “FIG . 18 illustrates an exemplary user interface that shows a comparison of two different executions of the same application in a session”. A comparison cannot occur unless the results of both execution are available to the user. See also [col. 2, lines 58-59] e.g., “FIG. 17 illustrates an exemplary user interface that shows trends found for an application in a session”. The user interface is presenting information derived from multiple execution). Babu does not explicitly disclose: the updated join configuration defining a second join operation type different from the join operation type; based on the serial execution order, executing, by the data processing hardware and using the analytics engine and a default join configuration, a first job execution, the default join configuration defining a first join operation type to use during execution; determining, by the data processing hardware and based on runtime statistics from execution of the job execution, an updated join configuration including at least a broadcast hash join, wherein the runtime statistics indicate a network congestion or a data skewness, and the updated join configuration is selected to reduce network congestion and improve parallelism. Adams discloses the updated join configuration defining a second join operation type different from the join operation type (Adams [col. 5, lines 19-23] e.g., “…HashJoinDecision” (or HJD) RSO indicates an operation that can be configured to determine an optimal distributed execution method for each join operator. For example, the distributed execution can be a broadcast join or a hash-partitioned hash join.”. This correspond to the claim language. Because the claim requires, a) first execution – join type # 1, b) second execution – join type # 2. Explicitly teaches alternative join execution methods. First execution, equated with hash-partitioned hash join. Second execution, equated with broadcast join) to reduce an execution time and computing resources usage of the second job execution relative to the default join configuration (Adams [col. 5, lines 19-23] e.g., “…an operation that can be configured to determine an optimal distributed execution method for each join operator”, see also [col. 10, lines 49-56] e.g., “Job optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the job”; and
based on the serial execution order, executing, by the data processing hardware and using the analytics engine and a default join configuration, a first job execution, the default join configuration defining a first join operation type to use during execution (Adams [col. 5, lines 19-23] e.g., “… the distributed execution can be a broadcast join or a hash-partitioned hash join.” See also [col. 4, lines 37-49] e.g., “A broadcast join is an example of a join algorithm …”, see also [col. 4, lines 34-36] e.g., “…hash-hash joins (hash-hash joins are also commonly referred to as shuffle joins or hash-partitioned hash joins).”, see also [col. 5, lines 24-34] e.g., ““HashJoinDecision” (or HJD) RSO indicates an operation that can be configured to determine an optimal distributed execution method for each join operator”. This show, join operation type, join configuration decisions, broadcast join, and hash-hash join. Adams teaches a join operation may be configured as a broadcast join or a hash-hash join. Thus, Adams teaches a join configuration defining a join operation type for us during execution).
determining, by the data processing hardware and based on runtime statistics from execution of the job execution, an updated join configuration including at least a broadcast hash join (Adams [col. 5, lines 19-23] e.g., “…“HashJoinDecision” (or HJD) RSO indicates an operation that can be configured to determine an optimal distributed execution method for each join operator the distributed execution can be a broadcast join or a hash-partitioned hash join”. The join configuration is updated based on execution information and may select a broadcast join), wherein the runtime statistics indicate a network congestion or a data skewness (Adams [col. 5, lines 62-65] e.g., “…using a join decision manager to mitigate build-side skew …”, see also [col. 14, lines 61-62] e.g., “… skew handling techniques as disclosed herein“, see also [col. 20, line 9-11] e.g., “… FIG. 16 illustrates skew mitigation by a JDM in connection with a hash-hash join operation…”. Adams teaches built-side skew, skew handling, and skew mitigation). and the updated join configuration is selected to reduce network congestion and improve parallelism (Adams [col. 13, lines 3-14] .e.g., “Thus, the caches reduce or eliminate the bottleneck problems occurring in platforms that consistently retrieve data from remote storage systems … which is significantly faster and avoids the bottleneck problem discussed above. In some embodiments, the caches are implemented using high-speed memory devices that provide fast access to the cached data”. Loo teaches “This strategy significantly decreases network traffic…” and evaluate shuffle efficiency and shuffle cost.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify Babu’s workload optimization system to incorporate Adams’ join decision techniques because Adams teaches that selecting between broadcast joins and hash-hash joins based on execution characteristics, including data skew and relative dataset size, improves distrusted query execution efficiency and reduces resources consumption.
Claim 11 incorporate substantively all the limitations of claim 1 in a system comprising data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that when executed on the data processing hardware cause the data processing hardware to perform operations and rejected under the same rational.
Claim 2. (Canceled).
Regarding claim 3, the rejection of claim 1 is hereby incorporated by reference, Babu and Adams discloses a method, wherein the default join configuration comprises
one of:
a sort merge join;
a shuffle hash join (Adams [col. 4, lines 24-36] e.g., “shuffle joins or hash-partitioned hash joins).”);
a Cartesian join; or
a broadcasted nested loop join .
Regarding claim 4, the rejection of claim 1 is hereby incorporated by reference, Babu and Adams discloses a method, wherein executing, using the analytics engine and the updated join configuration, the second job execution comprises providing, to the analytics engine, a query hint associated with the updated join configuration (Adams [col. 5, lines 5-12] e.g., “The HJD determines a distribution method and communicates the hash-partitioned build-side data accordingly (e.g., broadcast to the HJP instance in case of a broadcast join decision or perform a local synchronization to the HJP instance in case of a hash-hash join decision”, see also [col. 5, lines 40-58] e.g., “Aspects of the present disclosure provide techniques for determining whether a join operation will be executed as a broadcast join or a hash-hash join based on, e.g., the size of build-side data and probe-side data”, see also [col. 5, lines 35-39] e.g., “In some aspects associated with configuring a broadcast join, the input link of the HJB hashes the rows to an instance, the HJB/HJD broadcasts the rows to the same instance on all servers…”. These passages clearly teach: broadcast join extension, decision-making regarding broadcast join, and monitoring information used to choose broadcast vs. hash-hash joins).
Regarding claim 5, the rejection of claim 1 is hereby incorporated by reference, Babu and Adams discloses a method, wherein determining the updated join configuration comprises determining one or more successful broadcasts of data in execution of the first job execution (Adams [col. 5, line 5-12] e.g., “The HJD determines a distribution method and communicates the hash-partitioned build-side data accordingly (e.g., broadcast to the HJP instance in case of a broadcast join decision or perform a local synchronization to the HJP instance in case of a hash-hash join decision). Determine that a prior broadcast successfully).
Claim 6. (Canceled).
Regarding claim 7, the rejection of claim 1 is hereby incorporated by reference, Babu and Adams discloses a method, wherein: the method further comprises determining, based on execution of the first job execution, an updated executor memory configuration (Babu [col. 13, lines 49-57] e.g., “As an example, the application configuration parameters of Table 2 form an application configuration parameter space that defines the setting X for a <App,Goal> session… TABLE 2 … spark.executor.memory … spark driver memory spark driver memory spark.yarn.executor.memoryOverhead…”, see also [col. 15, lines 1-11] e.g., “DOPER may use Resource utilization to understand the actual memory/CPU resources used in the cluster. For example, ‘vmRSS’ memory can be used to understand the memory utilization at the container level for the application and ‘processCPULoad’ to understand the CPU utilization at container level. … This can be used in a multiplicity of scenarios, such as configuring Container Sizing, e.g., Container Shrink or Container Expansion, and Container Packing.”); and
executing the second job execution comprises using the updated executor memory configuration, the updated executor memory configuration defining an amount of memory available to execute the second job execution (Babu [col. 15, lines 12-22] ] e.g., “Container shrink issued when the memory and/or the CPU resources are under-utilized. For an example Spark application, these may be determined as follows: a) Reduce the memory resources per container, roughly: (i) spark.executor.memory=(vmRSS memory Executor×1.2); (ii) spark.driver.memory=(vmRSS memory Driver×1.2); (iii) spark.yarn.executor.memoryOverhead=max(384 MB, 0.1×spark.executor.memory).”, see also [col. 15, lines 35-44] e.g., “Container expansion: Used when the allocated memory and/or CPU resources are over-utilized a) As a result of a bottleneck analysis, the system increases the memory/Vcores allocated per container… For memory expansion: i. If successful tasks are available… estimate new memory allocation based on successfully completed tasks. Estimate memory requirements based on input data processed versus memory used.” These passages show that, based on execution of earlier runs (firs portion), the system determines an updated executor memory configuration (updated spark.executor.memory and related memory settings) and then executes subsequent workloads with that updated configuration. This meets the claim limitations).
Regarding claim 8, the rejection of claim 7 is hereby incorporated by reference, Babu and Adams discloses a method, wherein the amount of memory defined by the updated executor memory configuration is greater than an amount of memory available when executing the first job execution (Babu [col. 15, lines 35- ] e.g., “Container expansion: Used when the allocated memory and/or CPU resources are over-utilized a) As a result of a bottleneck analysis, the system increases the memory/Vcores allocated per container…”, see also [col.16, lins47-65] e.g., “Potential uses cases for OOME include: (a) Out of memory error for Driver, (b) Out of memory error for Executor, and (c) Container killed by YARN. In such cases, the present system/intelligence platform 200 performs the following process: 1) Explores the space to see which values will not cause OOME. 2) A binary search approach is used to find the best memory settings in a small number of steps… 4) The final suggestion is meant to be safe: it takes the best settings that have been seen so far; e.g., the smallest memory allocation that did not fail the application.”. Because the OOME occurs at a lower memory setting and the final suggestion uses a higher safe memory value, the updated executor memory configuration is greater than the amount of memory available when executing the first portion, satisfying the claim requirements).
Regarding claim 9, the rejection of claim 7 is hereby incorporated by reference, Babu and Adams discloses a method, wherein the amount of memory defined by the updated executor memory configuration is less than an amount of memory available when executing the first job execution (Babu [col. 15, lines 12-18] e.g., “Container shrink issued when the memory and/or the CPU resources are under-utilized. For an example Spark application, these may be determined as follows: a) Reduce the memory resources per container, roughly: (i) spark.executor.memory=(vmRSS memory Executor×1.2); (ii) spark.driver.memory=(vmRSS memory Driver×1.2)….” This shows that, when initial execution indicates under-utilization, the system reduces executor memory for subsequent runs, so the amount of memory defined by the updated executor memory configuration is less than that available during execution of the first portion, satisfying claim requirements)..
Regarding claim 10, the rejection of claim 1 is hereby incorporated by reference, Babu and Adams discloses a method, wherein: the method further comprises determining, based on execution of the first job execution, an updated initial number of executors and an updated maximum number of executors (Babu [col. 13, lines 49-65] e.g., “As an example, the application configuration parameters of Table 2 form an application configuration parameter space that defines the setting X… TABLE 2 … spark.executor.cores; spark.executor.instances; spark.dynamicAllocation.enabled; …”, see also [col. 14, lines 36-67] e.g., “[Step 1: Find Maximum Available Parallelism] DOPER uses the total amount of resources available to an application, to compute the Maximum Available Parallelism (MAP)… The maximum number of concurrent tasks is referred to as actual parallelism (AP). Using this information, DOPER can tune parallelism for an application, as follows: a. If AP<MP, more tasks could have been executed concurrently with the same resource allocation if more partitions were available. This indicates a need to increase the number of partitions. b. If AP=MP i. If dynamic allocation was enabled, increasing the number of partitions ii. If dynamic allocation was disabled, increasing the number of containers in the first place (see Container packing). Then, increase the number of partitions to be at least the number of executors. “); and
executing the second job execution comprises using the updated initial number of executors and the updated maximum number of executors, the updated initial number of executors defining a number of executors to use when beginning execution of the second job execution, the updated maximum number of executors defining a maximum number of executors to use when executing the second job execution (Babu [col. 16, lines 23-36] e.g., “[Step 4: Compute a recommendation to satisfy a goal] … If Goal=SLA: Set spark.dynamicAllocation.enabled to false; Set spark.executor.instances=1.2×[(NP×avg_task_time)/(SLA×exec_cores)].”. These passages show that, based on execution of the first portion of the workloads (from which MAP, AP, NP, and avg_task_time are computed), DOPER determines updated values for spark.executor.instances and related executor-count parameters. These values define an updated initial number of executors and, when used with dynamic allocation, an updated maximum number of executors. The second portion of the workloads in the session is then executed using those updated executor-count values. Therefore, the limitations of the claim are met by Babu in view of Billa).
Claim 12. (Canceled).
Regarding claim 13, the rejection of claim 11 is hereby incorporated by reference, Babu and Adams discloses a method, wherein the default join configuration comprises
one of:
a sort merge join;
a shuffle hash join (Adams [col. 4, lines 24-36] e.g., “shuffle joins or hash-partitioned hash joins).”);
a Cartesian join; or
a broadcasted nested loop join.
Regarding claim 14, the rejection of claim 11 is hereby incorporated by reference, Babu and Adams discloses a system, wherein executing the instructions that cause the data processing hardware to execute, using the analytics engine and the updated join configuration, the second job execution- comprises providing further cause the data processing hardware to provide, to the analytics engine, a query hint associated with the updated join configuration ((Adams [col. 5, lines 5-12] e.g., “The HJD determines a distribution method and communicates the hash-partitioned build-side data accordingly (e.g., broadcast to the HJP instance in case of a broadcast join decision or perform a local synchronization to the HJP instance in case of a hash-hash join decision”, see also [col. 5, lines 40-58] e.g., “Aspects of the present disclosure provide techniques for determining whether a join operation will be executed as a broadcast join or a hash-hash join based on, e.g., the size of build-side data and probe-side data”, see also [col. 5, lines 35-39] e.g., “In some aspects associated with configuring a broadcast join, the input link of the HJB hashes the rows to an instance, the HJB/HJD broadcasts the rows to the same instance on all servers…”. These passages clearly teach: broadcast join extension, decision-making regarding broadcast join, and monitoring information used to choose broadcast vs. hash-hash joins).
Regarding claim 15, the rejection of claim 11 is hereby incorporated by reference, Babu and Adams discloses a system, wherein determining the
instructions that cause the data processing hardware to determine the updated join configuration comprises determining further cause the data processing hardware to determine one or more successful broadcasts of data in execution of the first job execution (Adams [col. 5, lines 5-12] e.g., “The HJD determines a distribution method and communicates the hash-partitioned build-side data accordingly (e.g., broadcast to the HJP instance in case of a broadcast join decision or perform a local synchronization to the HJP instance in case of a hash-hash join decision”, see also [col. 5, lines 40-58] e.g., “Aspects of the present disclosure provide techniques for determining whether a join operation will be executed as a broadcast join or a hash-hash join based on, e.g., the size of build-side data and probe-side data”, see also [col. 5, lines 35-39] e.g., “In some aspects associated with configuring a broadcast join, the input link of the HJB hashes the rows to an instance, the HJB/HJD broadcasts the rows to the same instance on all servers…”. These passages clearly teach: broadcast join extension, decision-making regarding broadcast join, and monitoring information used to choose broadcast vs. hash-hash joins).
Claim 16. (Canceled).
Regarding claim 17, the rejection of claim 11 is hereby incorporated by reference, Babu and Adams discloses a system, wherein:
the operations further comprise determining the instructions further cause the data processing hardware to determine, based on execution of the first in the
cohort job execution, an updated executor memory configuration (Babu [col. 13, lines 49-57] e.g., “As an example, the application configuration parameters of Table 2 form an application configuration parameter space that defines the setting X for a <App,Goal> session… TABLE 2 … spark.executor.memory … spark.driver.memory … spark.yarn.executor.memoryOverhead…”, see also [col. 15, lines 1-11] e.g., “DOPER may use Resource utilization to understand the actual memory/CPU resources used in the cluster. For example, ‘vmRSS’ memory can be used to understand the memory utilization at the container level for the application and ‘processCPULoad’ to understand the CPU utilization at container level. … This can be used in a multiplicity of scenarios, such as configuring Container Sizing, e.g., Container Shrink or Container Expansion, and Container Packing.”); and
executing the instructions that cause the data processing hardware to execute the second job execution comprises using further cause the data processing hardware to use the updated executor memory configuration, the updated executor memory configuration defining an amount of memory available to execute the second portion of
the workloads job execution (Babu [col. 15, lines 12-22] ] e.g., “Container shrink issued when the memory and/or the CPU resources are under-utilized. For an example Spark application, these may be determined as follows: a) Reduce the memory resources per container, roughly: (i) spark.executor.memory=(vmRSS memory Executor×1.2); (ii) spark.driver.memory=(vmRSS memory Driver×1.2); (iii) spark.yarn.executor.memoryOverhead=max(384 MB, 0.1×spark.executor.memory).”, see also [col. 15, lines 35-44] e.g., “Container expansion: Used when the allocated memory and/or CPU resources are over-utilized a) As a result of a bottleneck analysis, the system increases the memory/Vcores allocated per container… For memory expansion: i. If successful tasks are available… estimate new memory allocation based on successfully completed tasks. Estimate memory requirements based on input data processed versus memory used.” These passages show that, based on execution of earlier runs (firs portion), the system determines an updated executor memory configuration (updated spark.executor.memory and related memory settings) and then executes subsequent workloads with that updated configuration. This meets the claim limitations).
Regarding claim 18, the rejection of claim 17 is hereby incorporated by reference, Babu and Adams discloses a system, wherein the amount of memory defined by the updated executor memory configuration is greater than an amount of memory available when executing the first job execution (Babu [col. 15, lines 35- ] e.g., “Container expansion: Used when the allocated memory and/or CPU resources are over-utilized a) As a result of a bottleneck analysis, the system increases the memory/Vcores allocated per container…”, see also [col.16, lins47-65] e.g., “Potential uses cases for OOME include: (a) Out of memory error for Driver, (b) Out of memory error for Executor, and (c) Container killed by YARN. In such cases, the present system/intelligence platform 200 performs the following process: 1) Explores the space to see which values will not cause OOME. 2) A binary search approach is used to find the best memory settings in a small number of steps… 4) The final suggestion is meant to be safe: it takes the best settings that have been seen so far; e.g., the smallest memory allocation that did not fail the application.”. Because the OOME occurs at a lower memory setting and the final suggestion uses a higher safe memory value, the updated executor memory configuration is greater than the amount of memory available when executing the first portion, satisfying the claim requirements).
Regarding claim 19, the rejection of claim 17 is hereby incorporated by reference, Babu and Adams discloses a system, wherein the amount of memory defined by the updated executor memory configuration is less than an amount of memory available when executing the first job execution (Babu [col. 15, lines 12-18] e.g., “Container shrink issued when the memory and/or the CPU resources are under-utilized. For an example Spark application, these may be determined as follows: a) Reduce the memory resources per container, roughly: (i) spark.executor.memory=(vmRSS memory Executor×1.2); (ii) spark.driver.memory=(vmRSS memory Driver×1.2)….” This shows that, when initial execution indicates under-utilization, the system reduces executor memory for subsequent runs, so the amount of memory defined by the updated executor memory configuration is less than that available during execution of the first portion, satisfying claim requirements).
Regarding claim 20, the rejection of claim 11 is hereby incorporated by reference, Babu and Adams discloses a system, wherein:
the operations further comprise determining the instructions further cause the data processing hardware to determine, based on execution of the first in the
cohort job execution, an updated initial number of executors and an updated maximum number of executors (Babu [col. 13, lines 49-65] e.g., “As an example, the application configuration parameters of Table 2 form an application configuration parameter space that defines the setting X… TABLE 2 … spark.executor.cores; spark.executor.instances; spark.dynamicAllocation.enabled; …”, see also [col. 14, lines 36-67] e.g., “[Step 1: Find Maximum Available Parallelism] DOPER uses the total amount of resources available to an application, to compute the Maximum Available Parallelism (MAP)… The maximum number of concurrent tasks is referred to as actual parallelism (AP). Using this information, DOPER can tune parallelism for an application, as follows: a. If AP<MP, more tasks could have been executed concurrently with the same resource allocation if more partitions were available. This indicates a need to increase the number of partitions. b. If AP=MP i. If dynamic allocation was enabled, increasing the number of partitions ii. If dynamic allocation was disabled, increasing the number of containers in the first place (see Container packing). Then, increase the number of partitions to be at least the number of executors. “); and
executing the instructions that cause the data processing hardware to execute the second job execution comprises using further cause the data processing hardware to use the updated initial number of executors and the updated maximum number of executors, the updated initial number of executors defining a number of executors to use when beginning execution of the second job execution, the updated maximum number of executors defining a maximum number of executors to use when executing the second job execution (Babu [col. 16, lines 23-36] e.g., “[Step 4: Compute a recommendation to satisfy a goal] … If Goal=SLA: Set spark.dynamicAllocation.enabled to false; Set spark.executor.instances=1.2×[(NP×avg_task_time)/(SLA×exec_cores)].”. These passages show that, based on execution of the first portion of the workloads (from which MAP, AP, NP, and avg_task_time are computed), DOPER determines updated values for spark.executor.instances and related executor-count parameters. These values define an updated initial number of executors and, when used with dynamic allocation, an updated maximum number of executors. The second portion of the workloads in the session is then executed using those updated executor-count values. Therefore, the limitations of the claim are met by Babu in view of Billa).
Conclusion
14. THIS ACTION IS MADE FINAL. 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.
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Monday – Friday 8:30AM – 4:00PM.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156
Prosecution Insights