Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In regards to claim 5, applicant argues “Claims 5, 12, and 19 recite that "scaling the first dependent object is further based on a replica count of the first dependent object and a replica count of the first object." Neither Einkauf nor Ou discloses scaling a dependent object based on the relationship between the replica count of the dependent object and the replica count of the object from which it depends. The combination therefore does not render claims 5, 12, and 19 obvious.”. The examiner respectfully disagrees, OU teaches scaling a first role and a dependent role based on the number of nodes assigned to each role. For example, OU teaches that (P. 0011) “for each two nodes performing a first role… it may be desirable to have one performing a second role”. Ou also teaches increasing or decreasing the number of nodes for both the first role and the dependent role together (P.0014, 0045). Applicant’s specification explains that a replica count is simply how many instances of an object are deployed. Therefore, the number of nodes in OU corresponds to the claimed replica count. The applicants argument therefore is not persuasive.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 6-11 and 13-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over EINKAUF (US PUBLICATION 20160323377) in view of Samir “DLA: Detecting and Localizing Anomalies in Containerized Microservice Architectures Using Markov Models”
In regards to claim 1, EINKAUF teaches a method for scaling dependent objects running in a container cluster based on scaling of a first object running in the container cluster; (P.0022) “Various embodiments of methods and apparatus for implementing automatic scaling of computing resource instances in a cluster-based distributed computing system (e.g., the Apache™ Hadoop® framework) are described herein…As described in more detail herein, a client may define metrics to be monitored during execution of an application on the cluster and may define or select an auto-scaling policy that includes an auto-scaling trigger condition (e.g., a condition that is dependent on the monitored metrics). In some embodiments, the policy may define a scaling action to be taken when the condition is met, may specify an amount by which capacity in the cluster (or a subset thereof) should be increased or decreased, and may identify the portion of the cluster to which the policy applies.” (P.0027) “For example, for most of these applications, there exists the concept of a master node, and there are groups of worker nodes in the cluster. The master node behaves very differently from the worker nodes…” scaling the first object running in the container cluster (P.0064-0066) “a MapReduce cluster may in various embodiments, be configured to automatically scale up or down when triggered by one or more of the following: a metric captured by a monitoring service crossing a specified threshold for a specified time period—For example, an auto-scaling action (e.g., an action to reduce capacity) may be triggered if the number of mappers in the cluster is less than 2 for at least 60 minutes… a cluster metric (e.g., one that is published by the cluster but is not available in the monitoring service) crossing a specified threshold for a specified time period.—For example, an auto-scaling action (e.g., an action to add capacity) may be triggered if the storage-to-virtualized-computing-service throughput is greater than or equal to 100 for at least 120 minutes.” And based on a scaling value indicating that the first dependent object is to be scaled (P.0022) “the policy may define a scaling action to be taken when the condition is met, may specify an amount by which capacity in the cluster (or a subset thereof) should be increased or decreased, and may identify the portion of the cluster to which the policy applies.” Wherein scaling the first dependent object comprises changing a number of instances of the first dependent object deployed in the container cluster, a resource allocation of the first dependent object, or both (P.0023) “For example, they may be used to programmatically scale a cluster up or down based on the workload.” (P.0077-0079) “the amount or percentage of capacity (e.g., the number or percentage of resource instances) to add to or remove from the cluster (or specific instance groups thereof)—For example the policy may specify the change in resource capacity as one of the following: “5” (e.g., 5 resource instances should be added or removed) “20%” (e.g., the change should represent 20% of the current resource instances)”
EINKAUF does not teach scaling a first dependent object that depends from the first object in response to the scaling of the first object. However, Samir teaches scaling a first dependent object that depends from the first object, in response to the scaling of the first object scaling a first dependent object (Abstract, pg. 205) “the degradation of performance within a single service will cascade reducing the performance of other dependent services.”; see also pg. 206-207, IV HHMM Cusomization and pg. 210-211, Section VI. Evaluation
PNG
media_image1.png
327
482
media_image1.png
Greyscale
It would have been obvious for one of ordinary skill before the effective filing date to apply Samirs dependency modeling to Einkaufs auto-scaling framework as both are a known technique and a known method, yielding predictable results.
In regards to claim 2, Samir teaches the scaling value is based on a probabilistic graph model indicating dependencies between objects in the container cluster (Section IV, HHMM Customization, pg. 207) “the vertical transition refers to parent-child dependency between microservice/VMs/containers/services.” (See Section II, Background, pg. 206) “HHMM is identified by HHMM =. The λ is a set of parameters consisted of horizontal ξ and vertical χ transitions between states qd, d specifies the number of vertical levels in the hierarchy structure; state transition probability A; observation probability distribution B; initial transition π; state space SP at each level and the hierarchical parent-child relationship qd i , qd+1 i . The i specifies the index of horizontal levels in the hierarchy structure. The Σ consists of all possible observations O. The states in HHMM are hidden from the observer and only the observation space is visible. We expect the model to be able to: (1) efficiently analyze large amounts of data to detect potential anomalous observation in container based microservice architecture; (2) track the cause of the detected anomaly”
PNG
media_image1.png
327
482
media_image1.png
Greyscale
Refer to claim 1 for motivation to combine.
In regards to claim 3, EINKAUF teaches wherein: scaling the first object is based on a resource utilization by the first object. (P.0028) “The systems described herein may allow the operator to create an auto-scaling policy so that if utilization exceeded 80%, the system would, automatically (e.g., programmatically) add capacity on behalf of the operator.” (P.0048) “the monitoring component may be implemented in a different system on the service provider network (e.g., in a service that gathers and/or analyzes relevant metrics characterizing the behavior of the compute nodes and/or storage nodes of distributed computation system 300) and may be configured to determine if and when to add or subtract capacity.”
In regards to claim 4. EINKAUF teaches the scaling value indicates that the first dependent object is to be scaled based on whether the scaling value satisfies a threshold. (P.0022) “a client may define metrics to be monitored during execution of an application on the cluster and may define or select an auto-scaling policy that includes an auto-scaling trigger condition (e.g., a condition that is dependent on the monitored metrics).” (P.0064-0066) “a MapReduce cluster may in various embodiments, be configured to automatically scale up or down when triggered by one or more of the following: a metric captured by a monitoring service crossing a specified threshold for a specified time period—For example, an auto-scaling action (e.g., an action to reduce capacity) may be triggered if the number of mappers in the cluster is less than 2 for at least 60 minutes… a cluster metric (e.g., one that is published by the cluster but is not available in the monitoring service) crossing a specified threshold for a specified time period.—For example, an auto-scaling action (e.g., an action to add capacity) may be triggered if the storage-to-virtualized-computing-service throughput is greater than or equal to 100 for at least 120 minutes.”
In regards to claim 6, EINKAUF teaches scaling the first dependent object comprises scaling a number of instances of the first dependent object. (Abstract) “Each policy may define an expression to be evaluated during execution of a distributed application, a scaling action to take if the expression evaluates true, and an amount by which capacity should be increased or decreased.” (P.0048) “distributed computation system 300 may include a monitoring service that is employed in implementing auto-scaling for the cluster of nodes (e.g., for a MapReduce cluster).” (P.0077-0079) “the amount or percentage of capacity (e.g., the number or percentage of resource instances) to add to or remove from the cluster (or specific instance groups thereof)—For example the policy may specify the change in resource capacity as one of the following: “5” (e.g., 5 resource instances should be added or removed) “20%” (e.g., the change should represent 20% of the current resource instances)”
In regards to claim 7, EINKAUF teaches scaling the first dependent object comprises scaling a resource allocation of the first dependent object. (P.0023) “The systems and methods described herein may be used to manage computing resource instances in systems that employ both of these models. For example, they may be used to programmatically scale a cluster up or down based on the workload. In some embodiments, service provider customers who do not know how much capacity they will need may create a small cluster (e.g., one with only one or two nodes) and, by enabling auto-scaling as described herein, may allow the system to determine when and if to scale up based on the actual demand (rather than trying to size it correctly at creation based on a blind estimate).”
Claims 8 and 15 correspond to independent claim 1 and are rejected for the same reasons.
Further it is noted that claim 15 details the apparatus is a computer system comprising: one or more memories; and one or more processors configured to perform operations for scaling dependent objects running in a container cluster based on scaling of a first object running in the container cluster which is shown in EINKAUF paragraph 0194.
Claims 9 and 16 correspond to claim 2 and are rejected for the same reasons.
Claims 10 and 17 correspond to claim 3 and are rejected for the same reasons.
Claims 11 and 18 correspond to claim 4 and are rejected for the same reasons.
Claims 13 and 20 correspond to claim 6 and are rejected for the same reasons.
Claim 14 corresponds to claim 7 and is rejected for the same reasons.
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over EINKAUF (US PUBLICATION 20160323377) in view of Samir “DLA: Detecting and Localizing Anomalies in Containerized Microservice Architectures Using Markov Models” and in further view of OU (US PUBLICATION 20210263780).
In regards to claim 5, OU teaches scaling the first dependent object is further based on a replica count of the first dependent object and a replica count of the first object. (P.0011) “Additionally, there may be dependencies among the various roles. For example, for each two nodes performing a first role (e.g., data analysis), it may be desirable to have one node performing a second role (e.g., reporting).” (P.0014) “A role-based autoscaling policy may also identify one or more dependent roles that are to be scaled in tandem with the role with which the policy is associated. When one or more conditions of a role-based autoscaling policy is triggered for a particular role performed by a node of a virtual cluster, the number of nodes associated with the particular role may be increased/decreased as appropriate within the virtual cluster by a step size defined by the policy; and, in tandem, the number of nodes associated with the one or more dependent roles performed by one or more other node of the virtual cluster may also be increased/decreased…” (P.0045) “the number of nodes that perform a dependent role is increased or decreased by a second scaling factor.”
It would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to apply OU’s technique of maintaining proportional scaling relationships between a first role and its dependent role into Einkaufs autoscaling framework.
PNG
media_image2.png
752
605
media_image2.png
Greyscale
Claim 12 and 19 correspond to claim 5 and are rejected for the same reasons above.
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 SELMAN MOHAMED ABDULLAHI whose telephone number is (571)272-8556. The examiner can normally be reached 7:30-5:00 (Fri alternating).
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, LEWIS BULLOCK can be reached at (571) 272-3759. 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.
/SELMAN MOHAMED ABDULLAHI/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights