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 .
Remarks
This Office Action is in response to amendment/remarks filed on 02/10/2026.
Claims 1-12, 15-17 and 19-20 are currently amended via Applicant’s amendment.
Claims 1-20 are pending.
Claims 1, 11 and 19 are independent.
This Office Action is made final.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the component" in line 8. There is insufficient antecedent basis for this limitation in the claim. if the instance of “the component” in line 8 refers to “at least one component” recited in line 4, it should be changed to “the at least one component”.
Claims 2-10 are rejected for the same reason discussed above for claim 1 based on virtue of their dependency to 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over Cai et al. (US 2025/0097117 A1; International Application PCT/SE2021/051229, filed December 10, 2021) (hereinafter Cai) in view of Rangaraju et al. (US 2016/0011911 A1) (hereinafter Rangaraju).
As per claim 1, Cai discloses (Currently Amended) A method, comprising: acquiring, by a system comprising a processor, a current value of a metric associated with components of an application (e.g. Cai: [0042] discloses collecting metrics. [0052] discloses monitoring performance metrics such as processing capacity, time to perform an operation, or similar, in each cluster of resources. [0054] discloses periodically checking the global performance metrics provided by each cluster. [0057] discloses metric server collects relevant performance metrics utilized by the auto-scaler for the autoscaling. [0062] discloses collecting performance metrics from the metric server in each cluster. [0072] discloses LHPA periodically checks the observed metrics provided by the metric server to see if there is a need to adjust the number of the replicate pods of the deployed microservice according to the rule and parameters. [0074] LHPA periodically query the metric server to get the performance metrics specified in the rule, e.g., the average CPU usage of all pods for the given microservice. [0003-0004] discloses metrics can include a CPU usage, RAM usage, average CPU utilization, average memory utilization or any other custom metric. [0006] discloses obtaining a metric value, for example current metric value is 200. Also see [0065] [0069] [0083] [0091].); determining, by the system, a target number of replicas of at least one component of the components based on the current value of the metric and a scaling policy for the components, and an average number of data shards for the at least one component (e.g. Cai: [0003] discloses HPA determines the number of pods needed based on metrics and predefined rules. [0005-0006] [0065-0067] desiredReplicates=ceil[currentReplicates*(currentMetricValue/desiredMetricValue)] discloses determining/calculating maximum number of replicate pods which can be deployed. [0042] disclose determining number of resources or pods based on scaling policy and parameter. The determination may be performed periodically and comprise checking performance metrics. [0074-0075] discloses querying the metric server to get the metric specified in the rule and calculating the desired number of the pods in cluster, and compares the current number of the pods and gets the difference of the pod number. [0001][0018][0096] discloses method according to the embodiments described herein are implemented by means of a computer program product. Also see [0056] [0071-0080] [0091] [0093]. ); and updating a configuration manifest of the application based on the target number of replicas of the component, resulting in an updated configuration manifest (e.g. Cai: [0035] discloses dynamically modifying configuration of auto-scaler based on collected performance metric. [0036] discloses determining number of replicate pods and modifying the configuration and/or parameters of the local auto-scaler. [0044] discloses modifying maximum number of the replicate pods…the local auto-scaler may then set up operation with the modified maximum number of the replicate pods, and/or the desired performance metric. [0048] discloses changing the number of total replicate pods and changing the configuration of the local auto-scaler accordingly. [0056] discloses determining number of replicate pods needed for autoscaling and modifying the configuration or parameters of the LHPA. [0085] discloses adjusting parameters of the current LHPA so that the scaling request can be fulfilled. For example, GHA may modify the maximum number of the pods. [0006] discloses if the current metric value is 200, and the desired value is 100, the number of replicate pods will be doubled. If the current value is 50, the number of replicate pods will be reduced to half. Also see [0067-0071]. Cai discloses updating configuration by modifying desired/max number of replicate pods. It is implied that the configuration changes are stored/updated in a configuration file/manifest.).
Cai does not expressly disclose determining a target number of replicas based on an average number of data shards for the at least one component. Cai’s scaling is metric-and policy-driven but lacks explicit teaching of incorporating shard count (partitions) into replica determination.
However, Rangaraju discloses determining, by the system, a target number of replicas of at least one component of components based on an average number of data shards for the at least one component (e.g. Rangaraju: [0004] discloses determining a number of different process instances to be created based on a number of distinct data partitions. In data partition process schedules, partition schedules may be used to determine a number of process instances to be created a s a set of process instances to perform the data processing tasks, and each process instance may be assigned a unique subset of data set to be processed. [0021] discloses partition schedules may identify sets of partition parameters that may be used to determine a number of different process instances to be created, and to assign each process instance a distinct partition of data set to process. [Fig. 7 and related description] discloses calculating number of process instances to create for data processing task based on number of unique data partition fields retrieved via its parameters. [Fig. 8 and related description] discloses partition parameters are determined based on data fields within the partition schedule and number of process instances are determined based on the data partition fields. Also see [0089] [0092-0093]. This data-driven instance count corresponds to the claimed shard-based replica determination, as the number of shards reflects effective partitioning density form unique data values.).
It would have been obvious to one or ordinary skill in the art before the effective filing data of the claimed invention to modify Cai’s metric/policy-based replica determination to incorporate Rangaraju’s data partition-based instance calculation, as both address scalable replication for distributed data processing tasks, and a POSITA would recognize that data sharding density (as taught by Rangaraju) provides a predictable optimization factor for replica sizing to balance load across partitions while minimizing over-provisioning—yielding the predictable result of improved scaling efficiency in shard-aware container environments like Cai’s. A POSITA, combining Cai’s container orchestration with Rangaraju’s data-driven parallelism, would be motivated to include shard count for holistic scaling that accounts for data distribution, enhancing performance without undue experimentation.
As per claim 2, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the acquiring of the current value of the metric associated with the components of the application (e.g. Cai: [0005-0006] [0065-0067]) comprises: determining a metric server based on a scaling configuration; and acquiring the current value of the metric associated with the components from the metric server (e.g. Cai: [0005-0006] [0065-0067] discloses obtaining current value of metric. [Fig. 6] [0057] [0062] discloses each cluster comprises a metric server, each metric server collect relevant performance metrics that are utilized by the local horizontal pod auto-scaler. [0072] disclose LHPA periodically checks the observed metrics (e.g., CPU usage) provided by the metric server do determine if there is a need to adjust the number of the replicate pods of the deployed microservice according to the rule and parameters.).
As per claim 3, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the scaling policy comprises a first target value of the metric and a second target value of a restriction, and the determining of the target number of replicas of the at least one component of the components comprises: determining, based on a current number of replicas of the at least one component, the current value, and the first target value of the metric, a first number of replicas that satisfies the first target value of the metric (e.g. Cai: [0005] discloses HPA operates on the ratio between desired metric value and current metric value. The desired replicate are determined based on current replicate, current metric value and desire metric value. If current metric value is 200, and the desired value is 100, the number of replicate pods will be doubles. If the current value is instead 50, the number of replicate pods will be reduced to half.); determining, based on the current number of replicas of the at least one component, the current value, and the second target value of the restriction, a second number of replicas that satisfies the second target value of the restriction (e.g. Cai: [0065-0067] discloses the CPU usage percentage is selected as the metric in the rule., and the minimum and maximum number of the total pods which can be deployed across scaling group. For cluster i, let dm.sub.i denote the desired metric value, i.e., the desired CPU usage, min.sub.i denote the minimum pod number, max.sub.i denote the maximal pod number. There are many ways to determine the initial parameters for each LHPA, for example, to distribute the min.sub.i/max.sub.i equally among the clusters of the Scaling Group, i.e., min.sub.1=min.sub.2=g_min/2=1, max.sub.1=max.sub.2=g_max/2=5, and set the desired metrics value to the same as of the GHA, i.e., dm.sub.1=dm.sub.2=g_dm=70%. It is also possible the determine these values according to other information, for example max.sub.1=3, max.sub.2=7. These values may be modified dynamically by the GHA in order to adjust the scaling behavior. [0079-0085] LHPA.sub.i will check if it is possible to do it within the current cluster, i.e., to check if nn.sub.i<=max.sub.i−cn.sub.i, which means that the number of pods after the scaling will not exceed the parameter max.sub.i., i.e., maximum number of pods of the cluster. If nn.sub.i>max.sub.i−cn.sub.i, which means that according to the current configuration, the LHPA can't fulfill the scaling, LHPA may then send a request to the GHA to ask for coordinated scaling, which can mean the scaling out is done together with other selected clusters, i.e., some new pods will be deployed in other clusters; or some scaling parameters, e.g., desired CPU usage, maximum number of pods, will be changed by the GHA for the LHPA so that the scaling can still be fulfilled by the current cluster. Also see [0044] [0050] [0063]); and determining the target number of replicas based on the first number of replicas and the second number of replicas (e.g. Cai: [0075] discloses based on designated algorithm, LHPA calculates the desired number of the pods in cluster i, denoted as dn.sub.i, and compares to the current number of the pods (cn.sub.i) and gets the difference of the pod number (nn.sub.i). Also see [0065].).
As per claim 4, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], further comprising: based on scale factors specified by the scaling policy, determining, by the system, a range of number of replicas of the at least one component; and adjusting, by the system, the target number of replicas to the range of the number of replicas (e.g. Cai: [0063] discloses providing autoscaling rules and related parameters to determine max/min number of pods for autoscaling based on the factors like CPU usage or throughput. [0065-00667] discloses calculating desired number of replicate pods and determining minimum and maximum number of the total pod based on scale factor (70% CPU usage).) .
As per claim 5, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the scaling policy further comprises an indicator as to whether at least one of downward or upward scaling is allowed, and the method further comprises: adjusting, by the system, the target number of replicas based on the indicator and a current number of replicas of the at least one component (e.g. Cai: [0006] discloses determining to increase or reduce the number of replicate pods based on current metric value. [0016] discloses providing scaling arrangement for managing resources. The scaling arrangement comprises a global auto-scaler and one or more local auto-scalers. The scaling arrangement determines to perform one or more actions based on resource information, the one or more actions comprise sending modifying request to auto-scaler, requesting to perform operations related to modified parameter. [0036] discloses distributing requested horizontal scaling to change the number of replicate pods. [0044] discloses local-auto-scaler perform an operation based on the modifying request. The auto-scaler may add and/or remove the resources. For example, modifying request may indicate modification of maximum number of the replicate pods. The local auto-scaler may then set up operation with the modified maximum number of replicate pods. [0072-0080] discloses determining if there is a need to adjust the number of replicate pods of the microservice according to the rule and determining desired number of pods. If nn.sub.i is greater than zero, it means a scaling out is needed referred to as scale out, otherwise, if nn.sub.i is less than zero, it means a scaling in is needed, referred to as scale in).
As per claim 6, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the metric associated with the components is a first metric, wherein the scaling policy for the components is a first scaling policy, wherein the acquiring, the determining and the updating to support dynamic scaling, and wherein the method further comprises: acquiring, by the system, a current value of a second metric associated with a node where the application is located (e.g. Cai: [0003-0006] discloses metrics are CPU and memory usage, but it is also possible to specify custom metrics. The controller matches the observed metrics such as average CPU utilization, average memory utilization or any other custom metric. [0042] discloses collecting one or more performance metrics and evaluating to determine if the scaling is needed. [0052] discloses LHPA may monitor the related performance metrics. [0057] discloses metric servers collect relevant performance metrics utilized by the LHPA for autoscaling. Also see [0062-0072].); and based on the current value of the second metric associated with the node and a second scaling policy for the node, determining, by the system, whether the dynamic scaling is allowed, wherein the second scaling policy for the node comprises a target value of the second metric associated with the node (e.g. Cai: [0044] discloses modifying request may indicate modification of maximum number of replicate pods, and/or a desired performance for the local auto-scaler. The local-auto scaler may then set up operation with the modified maximum number of replicate pods. [0052] discloses LHPA may monitor the related performance metrics and GHA may periodically check global performance metrics provided by each cluster. When a scaling operation is triggered based on one or more local scaling rules and parameters, the local auto-scaler may determine if further global scaling is required. The GHA may then create scaling instruction if the GHA has determined a global scaling is required. The scaling instructions may have different actions: changing the number of replicate pods in the specified cluster; modifying the configuration or parameters of the LHPA.).
As per claim 7, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the updating of the configuration manifest of the application comprises: checking a state of a node where the application is located; and updating, in response to the node being in a ready state, a number of replicas related to the at least one component in the configuration manifest to the target number of replicas (e.g. Cai: [0035-0036] discloses determining whether local scaling is possible or impossible. When local scaling is impossible to success due to shortage of resources or similar, the global scaler distributes requested horizontal scaling, i.e., change of number of replicate pods, from one local auto-scaler to other local auto-scaler; or modifying the configuration and/or parameters of the local auto-scaler. [0079-0081] discloses determining whether the current cluster is ready for scaling out by checking if it is possible to perform scaling out within the local cluster. The current cluster is considered ready, when the number of pods after the scaling will not exceed the maximum number of pods of the cluster. If it is possible to do it within the current cluster, then LHPA will execute the scaling accordingly.).
As per claim 8, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], wherein the application is a custom application managed by an open source container platform, the components are custom resources, and the configuration manifest of the application comprises a custom resource manifest (e.g. Cai: [0003-0004] discloses in a Kubernetes cluster, HPA is able to scale the number of pod in a cluster to handle computational workload requirement of an application. The HPA determines the number of pods needed based on metrics and applies the creation or deletion of pods based on rules. The HPA is implemented as a Kubernetes API resource and a controller. Also see [0009] [0011] [0013] [0036] [0065].).
As per claim 9, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 1 [See rejection to claim 1 above], further comprising: performing, by the system, dynamic scaling of the at least one component based on the updated configuration manifest (e.g. Cai: [0016] discloses scaling arrangement sends a modifying request to modify a parameter related to resources to the local auto-scaler and local auto-scaler performs operations related to the modified parameters. [0036] discloses modifying the configuration and/or parameters of one or more local auto-scaler and performing horizontal scaling, i.e., change the number of replicate pods. [0043-0044] discloses scaling arrangement sends a modifying request to a local auto-scaler, requesting to perform operations related to the modified parameter. The modifying request may request to add/remove a resource. For example, modifying request may indicate modification of maximum number of the replicate pods, and/or a desired performance metric for the local-auto scaler. The local-auto scaler may then set up operation with the modified maximum number of the replicate pods. [0048] disclose changing the configuration of the local auto-scaler and changing the number of the total replicate pods. [0079-0080] discloses LHPA performs scaling out after checking the number of pods after the scaling will not exceed the maximum number of pods of the cluster.).
As per claim 10, the combination of Cai and Rangaraju discloses (Currently Amended) The method according to claim 9 [See rejection to claim 9 above], wherein the performing of the dynamic scaling of the at least one component comprises: increasing, by a custom resource controller, a number of container sets running the at least one component (e.g. Cai: [0003-0004] discloses horizontal scaling (scale out/in), means to add more resource units (node, VM, container, etc.) into a system or remove one or more resources or resource units form the system. The controller periodically adjusts the number of replicates pods. The HPA is implemented as a Kubernetes API resource and a controller. The pod is a module of network, compute, storage, and application components that work together to deliver a networking service, and the pod is a repeatable design pattern and may also be referred to as replicates or replicate pods).
As per claims 11-18, these are device/system claims having similar limitations as cited in method claims 1-8, respectively. Thus, claims 11-18 are also rejected under the same rationale as cited in the rejection of rejected claims 1-8.
As per claim 19, this is a program product claim having similar limitations as cited in method claim 1. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
As per claim 20, it recites similar limitations as cited in method claims 9 and 10. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of rejected claims 9 and 10.
Response to Arguments
Applicant's arguments filed on 02/10/2026 have been fully considered but they are moot in view of new ground of rejection necessitated by the amendment.
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 Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
April 18, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights