DETAILED ACTION
Claims 1-9 and 12-19 are pending.
Claims 10-11 and 20-21 are canceled.
Claims 1-9 and 12-19 are rejected.
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
1. Applicant’s arguments with respect to the 35 U.S.C. 101 rejections (Remarks pp. 8-10) have been fully considered and are unpersuasive.
The applicant argues that the recited steps of “automatically create all potential variants of the master variant within the maximum number of parallel levels by expanding the master variant with parallel components”,
and “use a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result”,
do not cover performance of the steps in the human mind alone or with the aid of pen and paper, because:
“a system with 6 components and 6 maximum levels would generate 66 potential variants, or a total of 46,656 potential variants. This cannot be practically performed in the human mind (alone or with the aid of pen and paper),”
and that the claim recites more than mere instructions to apply the judicial exception using generic computer components, and any judicial exception is integrated into a practical application under Step 2A Prong 2 (“In this way, the best scenario variant for the future may be selected at 51360 and suggested to a service provider or customer. This may help a user understand the best future designs.”).
The Examiner respectfully disagrees with these statements. A system with 2 components and 2 maximum levels could generate 1-22 potential variants based on design constraints or considerations, or a total of up to 4 potential variants, which can be practically performed in the human mind (alone or with the aid of pen and paper). For example:
PNG
media_image1.png
667
323
media_image1.png
Greyscale
PNG
media_image2.png
666
621
media_image2.png
Greyscale
PNG
media_image3.png
665
629
media_image3.png
Greyscale
PNG
media_image4.png
665
629
media_image4.png
Greyscale
Here, a master variant (variant 1) is defined with an app server and a database replica. 2 possible components and a maximum of 2 levels results in four variants being added (including the master variant). It can be seen that generating these variants can be practically performed in the human mind.
Furthermore, using a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, is using a generic computer component (in this case the machine learning model). This does not integrate a judicial exception into a practical application at Step 2A. U.S.C. 101 example 47 provides a similar analysis to the independent claim’s limitation of “using a machine learning model”:
PNG
media_image5.png
287
626
media_image5.png
Greyscale
PNG
media_image6.png
523
642
media_image6.png
Greyscale
2. Applicant’s arguments with respect to the 35 U.S.C. 103 rejections (Remarks pp. 10-12) have been fully considered. The first argument that Dimitrovich does not teach creating “all potential variants of the master variant” is unpersuasive.
The applicant argues that the limitation of creating “all potential variants of the master variant” is not taught by Dimitrovich or any other reference used in the independent claim’s rejection, because Dimitrovich shows only a variant of a master variant and does not disclose automatically generating all potential variants of the master variant.
The Examiner respectfully disagrees with this statement.
PNG
media_image7.png
504
358
media_image7.png
Greyscale
PNG
media_image8.png
488
800
media_image8.png
Greyscale
The diagram on the left represents a master variant, a route from a webserver to a database. The figure shows all potential variants/route of the master variant/route based on design constraints and considerations. Thus, Dimitrovich teaches creating “all potential variants of the master variant”.
Most importantly, the Examiner’s mapping is consistent with the specification. Paragraph 51 of the present application’s specification states that “As defined by a master variant 910, A, B, and C are components connected serially forming the system design: {master variant} = A → B → C. In this example, the maximum number of allowed replications (L) is 2. The algorithm then expands nodes and identifies new variants recursively. That is, the master variant 910 is initially expanded as follows: parallel component A1 is added to form variant 920; parallel component B1 is added to form variant 930; and parallel component C1 is added to form variant 940. Further, variant 950 and variant 960 are formed by expanding variant 940 one node at a time. Since L (the maximum number of allowed possible replications) is 2, the system cannot A1 further into A2 (because A → A1 already has 2 levels). Variant 970 is formed by expanding variant 930 (any other options were already identified from variant 920). Finally, variant 980 is achieved by expanding variant 950 in the only way possible (adding C1). As can be seen, the total number of possible variants for a scenario is nm, where n is the number of parallel levels and m is the number of of nodes.” Dimitrovich’s diagrams representing routes from a webserver to a database, and the variants of the route with additional parallel components added, is consistent with paragraph 51 of the specification.
The rest of the applicant’s arguments with respect to the 35 U.S.C. 103 rejections are moot in view of the Examiner’s new ground of rejections based on added references to address applicant’s amendments.
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.
Claims 1-9 and 12-19 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.
With Respect to Claim 1:
Step 1: Claim 1 is directed to a system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites the limitations:
determine a maximum number of parallel levels for the master variant,
automatically create all potential variants of the master variant within the maximum number of parallel levels by expanding the master variant with parallel components,
determine reliability information for each component,
determine cost information for each component,
automatically calculate an overall reliability score and overall cost score for each of the automatically created potential variants,
determine an evaluation result of said calculation
predict future cloud computing design performance based on historical cloud computing design performance,
and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result.
These recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind alone or with the aid of pen and paper. The design of the cloud layout is based on a cost and benefit (reliability) analysis.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
a cloud computing design evaluation platform, including: a computer processor, and a computer memory coupled to the computer processor and storing instructions that, when executed by the computer processor, cause the cloud computing design evaluation platform to:
receive a master variant for a cloud computing design, including a sequential sequence of a set of components.
use a machine learning model to
The additional elements (a) and (c) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components, and thus do not integrate into a practical application. See MPEP § 2106.05(f). Furthermore, the additional element (b) is mere data gathering. Therefore, (b) is an insignificant extra-solution activity to the judicial exception. See MPEP § 2106.05(g).
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
a cloud computing design evaluation platform, including: a computer processor, and a computer memory coupled to the computer processor and storing instructions that, when executed by the computer processor, cause the cloud computing design evaluation platform to:
receive a master variant for a cloud computing design, including a sequential sequence of a set of components.
use a machine learning model to
The additional elements (a) and (c) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components, and thus do not amount to significantly more than the judicial exception. See MPEP § 2106.05(f). Furthermore, with regards to additional element (b), the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, and thus do not amount to significantly more than the judicial exception. See MPEP § 2106.05(d).
With Respect to Claim 2:
Under Step 2A Prong 2, Claim 2 depends on Claim 1, and it recites the following additional element:
wherein evaluation result represents an optimum design that meets a Service Level Agreement (“SLA”) while keeping an associated Total Cost of Ownership (“TCO”) to a minimum.
This judicial exception is not integrated into a practical application. The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not integrate into a practical application. See MPEP § 2106.05(h).
Under Step 2B, The claim recites the additional element:
wherein evaluation result represents an optimum design that meets a Service Level Agreement (“SLA”) while keeping an associated Total Cost of Ownership (“TCO”) to a minimum.
The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not amount to significantly more than the judicial exception in Step 2B. See MPEP § 2106.05(h).
With Respect to Claim 3:
Under Step 2A Prong 2, Claim 3 depends on Claim 1, and it recites the following additional element:
wherein at least one of the components is associated with at least one of: (i) a load balancer, (ii) a dispatcher, (iii) a database, (iv) an application server, (v) a file system, (vi) a router, (vii) memory, (viii) Network Address Translation (“NAT”), and (ix) a messaging queue.
This judicial exception is not integrated into a practical application. The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not integrate into a practical application. See MPEP § 2106.05(h).
Under Step 2B, The claim recites the additional element:
wherein at least one of the components is associated with at least one of: (i) a load balancer, (ii) a dispatcher, (iii) a database, (iv) an application server, (v) a file system, (vi) a router, (vii) memory, (viii) Network Address Translation (“NAT”), and (ix) a messaging queue.
The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not amount to significantly more than the judicial exception in Step 2B. See MPEP § 2106.05(h).
With Respect to Claim 4:
Under Step 2A Prong 2, Claim 4 depends on Claim 1, and it recites the following additional element:
wherein the reliability information is associated with a Mean Time Between Failure (“MTBF”) for each component.
This judicial exception is not integrated into a practical application. The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not integrate into a practical application. See MPEP § 2106.05(h).
Under Step 2B, The claim recites the additional element:
wherein the reliability information is associated with a Mean Time Between Failure (“MTBF”) for each component.
The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not amount to significantly more than the judicial exception in Step 2B. See MPEP § 2106.05(h).
With Respect to Claim 5:
Under Step 2A Prong 2, Claim 5 depends on Claim 4, and it recites the following additional element:
wherein the cost information is associated with a Total Cost of Ownership (“TCO”) for each component.
This judicial exception is not integrated into a practical application. The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not integrate into a practical application. See MPEP § 2106.05(h).
Under Step 2B, The claim recites the additional element:
wherein the cost information is associated with a Total Cost of Ownership (“TCO”) for each component.
The additional element (a) is not comprised of anything beyond generally linking the use of the judicial exception to a particular field of use, and does not amount to significantly more than the judicial exception in Step 2B. See MPEP § 2106.05(h).
With Respect to Claim 6:
Under Step 2A Prong 1, Claim 6 depends on Claim 5, and it recites the following limitation:
wherein potential variants of the master variant are created by expanding the master variant with parallel identical components.
These recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind alone or with the aid of pen and paper. Accordingly, the claim recites an abstract idea.
Claim 6 does not recite any additional elements.
With Respect to Claim 7:
Under Step 2A Prong 1, Claim 7 depends on Claim 5, and it recites the following limitation:
wherein at least one potential variant of the master variant is created by expanding the master variant with a parallel alternate component having a different MTBF.
These recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind alone or with the aid of pen and paper. Accordingly, the claim recites an abstract idea.
Claim 7 does not recite any additional elements.
With Respect to Claim 8:
Under Step 2A Prong 1, Claim 8 depends on Claim 5, and it recites the following limitation:
wherein the cloud computing design evaluation platform is further to determine a Service Level Agreement (“SLA”) associated with the cloud computing design and the evaluation result comprises a selection of one of the automatically created potential variants based on the SLA, the overall reliability scores, and the overall cost scores.
These recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind alone or with the aid of pen and paper. Accordingly, the claim recites an abstract idea.
Claim 8 does not recite any additional elements.
With Respect to Claim 9:
Under Step 2A Prong 2, Claim 9 depends on Claim 5, and it recites the following additional element:
wherein the cloud computing design evaluation platform continuously monitors the cloud computing design in real time based on design performance.
This judicial exception is not integrated into a practical application. The additional element (a) is mere data gathering. Under BRI, the claimed “monitoring” is interpreted to include data collecting. Therefore, (a) is an insignificant extra-solution activity to the judicial exception. See MPEP § 2106.05(g).
Under Step 2B, The claim recites the additional element:
wherein the cloud computing design evaluation platform continuously monitors the cloud computing design in real time based on design performance.
With regards to additional element (a), the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, and thus do not amount to significantly more than the judicial exception. See MPEP § 2106.05(d).
With Respect to Claim 12:
Under Step 2A Prong 2, Claim 12 depends on Claim 10, and it recites the following additional elements:
wherein all of the sequential sequence of a set of components, the maximum number of parallel levels, and a Service Level Agreement ("SLA") are received from a user
via an interactive graphical user interface
This judicial exception is not integrated into a practical application. The additional element (a) is mere data gathering. Therefore, (a) is an insignificant extra-solution activity to the judicial exception. See MPEP § 2106.05(g). Furthermore, the additional element (b) is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the judicial exception using generic computer components, and thus does not integrate into a practical application. See MPEP § 2106.05(f).
Under Step 2B, The claim recites the additional element:
wherein all of the sequential sequence of a set of components, the maximum number of parallel levels, and a Service Level Agreement ("SLA") are received from a user
via an interactive graphical user interface
With regards to additional element (a), the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, and thus do not amount to significantly more than the judicial exception. See MPEP § 2106.05(d). Furthermore, the additional element (b) is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the judicial exception using generic computer components, and thus does not amount to significantly more than the judicial exception. See MPEP § 2106.05(f).
With Respect to Claims 13-15 and 17:
Claims 13-15 and 17 are method claims corresponding to the system claims 1, 4-5 and 8. They do not recite any additional limitations or elements.
With Respect to Claims 16:
Under Step 2A Prong 1, Claim 16 depends on Claim 15, and it recites the following limitation:
wherein potential variants of the master variant are created via at least one of: (i) expanding the master variant with parallel identical components, and (ii) expanding the master variant with a parallel alternate component having a different MTBF.
These recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind alone or with the aid of pen and paper. Accordingly, the claim recites an abstract idea.
Claim 16 does not recite any additional elements.
With Respect to Claims 18-19:
Claims 18-19 are non-transitory machine-readable medium claims corresponding to the system claims 1 and 9. They recite the following additional element:
A non-transitory, machine-readable medium comprising instructions thereon that, when executed by a processor, cause the processor to execute operations to perform a method, the method comprising:
The additional element (a) is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the judicial exception using generic computer components, and thus does not does not integrate into a practical application under Step 2A Prong 2, and also does not amount to significantly more than the judicial exception under Step 2B. See MPEP § 2106.05(f).
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 1, 3, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1) and Casey (US 20210136178 A1).
Regarding Claim 1, Dimitrovich teaches a system, comprising: a cloud computing design evaluation platform, including: a computer processor, and a computer memory coupled to the computer processor and storing instructions that, when executed by the computer processor, cause the cloud computing design evaluation platform to: (
PNG
media_image9.png
453
800
media_image9.png
Greyscale
Dimitrovich teaches designing cloud architecture to achieve high availability. Title, “Architecture I: How to Get High Availability.”
Dimitrovich further explains, “If we add more bells and whistles, such as hosting our static assets in AWS Simple Storage Service (S3), serving our content through a CDN — AWS CloudFront and add the ability to scale both stateless tiers automatically (AWS Auto-Scaling), we’ll arrive at this canonical highly available web architecture,” Page 7, and “As the system grows, we often split it into tiers (also known as layers), which sets it on the path of greater scale and availability. Now every tier can be placed on its own box of the appropriate size and cost. We can choose bigger, better boxes with multiple levels of hardware redundancy for our database servers and cheaper, commodity-grade hardware for our web and application servers,” Page 1.
Dimitrovich teaches a design process based on cost & benefits (reliability) analysis. The figure shows the design result. Dimitrovich does not explicitly disclose automating the design process with a design evaluation platform. According to MPEP section 2144.04.III, automating a manual activity would have been obvious. The software platform that does the automation is mapped to the claimed “cloud computing design evaluation platform”.)
receive a master variant for a cloud computing design, including a sequential sequence of a set of components (
PNG
media_image7.png
504
358
media_image7.png
Greyscale
Dimitrovich discloses the above figure that shows a setup of a sequential sequence of a set of cloud computing components, Page 2.
The claimed “component” is mapped to the disclosed web, app, or DB server.
The claimed “sequential sequence of a set of components” is mapped to ordered sequence as depicted in the diagram.
The claimed “master variant” is mapped to the disclosed setup in the figure, which can be expanded via introducing more parallel components.),
determine a maximum number of parallel levels for the master variant, automatically create all potential variants of the master variant within the maximum number of parallel levels by expanding the master variant with parallel components (
PNG
media_image8.png
488
800
media_image8.png
Greyscale
Dimitrovich discloses the above figure on Page 6, which is a diagram that shows a maximum number of parallel levels being determined as 3, and the master variant shown in the figure on Page 2 being expanded accordingly into a potential example variant based on that maximum number of parallel levels.
PNG
media_image7.png
504
358
media_image7.png
Greyscale
PNG
media_image8.png
488
800
media_image8.png
Greyscale
The diagram on the left represents a master variant, a route from a webserver to a database. The figure shows all potential variants/route of the master variant/route based on design constraints and considerations. Thus, Dimitrovich teaches creating “all potential variants of the master variant”.
Most importantly, the Examiner’s mapping is consistent with the specification. Paragraph 51 of the present application’s specification states that “As defined by a master variant 910, A, B, and C are components connected serially forming the system design: {master variant} = A → B → C. In this example, the maximum number of allowed replications (L) is 2. The algorithm then expands nodes and identifies new variants recursively. That is, the master variant 910 is initially expanded as follows: parallel component A1 is added to form variant 920; parallel component B1 is added to form variant 930; and parallel component C1 is added to form variant 940. Further, variant 950 and variant 960 are formed by expanding variant 940 one node at a time. Since L (the maximum number of allowed possible replications) is 2, the system cannot A1 further into A2 (because A → A1 already has 2 levels). Variant 970 is formed by expanding variant 930 (any other options were already identified from variant 920). Finally, variant 980 is achieved by expanding variant 950 in the only way possible (adding C1). As can be seen, the total number of possible variants for a scenario is nm, where n is the number of parallel levels and m is the number of of nodes.” Dimitrovich’s diagrams representing routes from a webserver to a database, and the variants of the route with additional parallel components added, is consistent with paragraph 51 of the specification.),
determine reliability information for each component (
Dimitrovich discloses, “Let’s say that our business requirements call for 99.5% uptime. In other words, it is allowed to be down no more than 44 hours in any given 12-month period. The total availability of a system of sequentially connected components is the product of individual availabilities. Let’s for example assume that individual servers that host our web and application tiers have 90% availability and the server hosting our database has 99%. For simplicity’s sake, let’s also assume that these availability numbers include hardware, OS, software, and connectivity.” Page 1.
The claimed “reliability information” is mapped to the disclosed “availability” for each component. The figure shows determined reliability for each component.),
determine cost information for each component (
Dimitrovich discloses, “The cost of this tier grows linearly with every server, but availability grows logarithmically. Consequently, we will soon reach the point of diminishing returns where the value of additional availability will be less than the cost of adding another server,” Page 4.
The claimed “cost information” is mapped to the cost of each component. The cost information is estimated to arrive at the cost for each tier.).
automatically calculate an overall reliability score and (
PNG
media_image8.png
488
800
media_image8.png
Greyscale
.
Dimitrovich discloses the above figure on Page 6, which depicts the total availability of the variant that is expanded from the original master variant. Said total availability will be calculated differently for each different variant.),
determine an evaluation result of said calculation (
Dimitrovich teaches a cost and benefits (reliability) analysis, stating “The cost of this tier grows linearly with every server, but availability grows logarithmically. Consequently, we will soon reach the point of diminishing returns where the value of additional availability will be less than the cost of adding another server,” Page 4),
.
Dimitrovich does not teach to automatically calculate an overall cost score for each of the automatically created potential variants,
or to use a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result.
However, Ellsworth teaches to automatically calculate an overall cost score for each of the automatically created potential variants (
Ellsworth discloses, “In some embodiments, the cost or the total cost for each of the components corresponding to the objects 335 within the containers 333 for the period of time may be displayed via an information field included in the GUI as discussed below in relation to FIG. 4,” ¶ 0081.).
Dimitrovich and Ellsworth are both considered to be analogous to the claimed invention because they are in the same field of cloud computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich to incorporate the teachings of Ellsworth and provide to automatically calculate an overall cost score for each of the automatically created potential variants. Doing so would help provide the overall cost score to the user. (Ellsworth discloses, In some embodiments, the cost or the total cost for each of the components corresponding to the objects 335 within the containers 333 for the period of time may be displayed via an information field included in the GUI as discussed below in relation to FIG. 4,” ¶ 0081.).
Dimitrovich in view of Ellsworth does not teach to use a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result.
However, Casey teaches to use a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result (
Casey discloses, “The method includes aggregating historical request data for a plurality of requests for services to be performed by one or more edge nodes, wherein the aggregated historical request data includes performance data for the plurality of requests; training a machine learning model based on the aggregated historical request data; generating, by the machine learning model, a prediction for performance data for future requests; comparing the prediction for the performance data to a predetermined performance threshold; and based on the comparison, generating a recommendation for an alteration of hardware resources at the one or more edge nodes,” ¶ 0012.).
Dimitrovich in view of Ellsworth, and Casey are both considered to be analogous to the claimed invention because they are in the same field of computer devices. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth to incorporate the teachings of Casey and provide to use a machine learning model to predict future cloud computing design performance based on historical cloud computing design performance, and automatically generate a recommended future design based on the predicted future cloud computing design performance and the evaluation result. Doing so would allow for optimizing the design and setup of the overall cloud computing system based on the predictions. (Casey discloses, “The trained machine learning model may then be used to make predictions for future requests and computing resources may be allocated to the edge nodes accordingly. Thus, the limited capacity of each node may be used more efficiently while also maintaining low latency for processing requests and providing computing services,” ¶ 0035.).
Claims 13 and 18 are a method claim and non-transitory machine-readable medium claim, respectively, corresponding to the system Claim 1. Therefore, Claims 13 and 18 are rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 3, Dimitrovich in view of Ellsworth and Casey teaches the system of claim 1, wherein at least one of the components is associated with at least one of: (i) a load balancer, (ii) a dispatcher, (iii) a database, (iv) an application server, (v) a file system, (vi) a router, (vii) memory, (viii) Network Address Translation (“NAT”), and (ix) a messaging queue (
Dimitrovich discloses, “We can choose bigger, better boxes with multiple levels of hardware redundancy for our database servers and cheaper, commodity-grade hardware for our web and application servers,” Page 1.).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1), Casey (US 20210136178 A1), and Saha (US 20240135228 A1).
Regarding Claim 2, Dimitrovich in view of Ellsworth and Casey teaches the system of claim 1, wherein evaluation result represents an optimum design that meets a Service Level Agreement (“SLA”) while keeping an associated Total Cost of Ownership (“TCO”) reasonable (
Dimitrovich discloses, “When architecting a system, how often do you start with availability requirements or service level agreement (SLA)?” Page 1, “The cost of this tier grows linearly with every server, but availability grows logarithmically. Consequently, we will soon reach the point of diminishing returns where the value of additional availability will be less than the cost of adding another server… Thus, we have noticed the first pattern: Adding redundancy to a single component or tier leads to logarithmic increase in availability, eventually reaching the point of diminishing returns, at least from the availability standpoint,” Page 4, and “By hosting your stack on AWS, you can achieve highest levels of availability, including data center redundancy, as well as dynamic horizontal scalability in an easy and cost effective way,” Page 8.).
Dimitrovich in view of Ellsworth and Casey does not teach keeping an associated Total Cost of Ownership (“TCO”) to a minimum.
However, Saha teaches achieving optional benefits while keeping a cost to a minimum (
Saha discloses, “The ranking of remedial action recommendations takes into account the predicted benefit to the organization and its IT infrastructure versus the predicted costs so as to prioritize and focus organization and IT resources to those remedial actions that are of the most benefit with least cost,” ¶ 0033.).
Dimitrovich in view of Ellsworth and Casey, and Saha are both considered to be analogous to the claimed invention because they are in the same field of computer technology. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth and Casey to incorporate the teachings of Saha and provide wherein evaluation result represents an optimum design that meets a Service Level Agreement (“SLA”) while keeping an associated Total Cost of Ownership (“TCO”) to a minimum. Doing so would help maximize the benefits of the design while minimizing potential drawbacks (Saha discloses, “This ranking may balance the predicated impact and costs using a benefit-cost analysis tradeoff, for example,” ¶ 0028.).
Claims 4-5, 8-9, 14-15, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1), Casey (US 20210136178 A1), and Bahl (US 20210019194 A1).
Regarding Claim 4, Dimitrovich in view of Ellsworth and Casey teaches the system of claim 1. Dimitrovich in view of Ellsworth and Casey does not teach wherein the reliability information is associated with a Mean Time Between Failure (“MTBF”) for each component.
However, Bahl teaches wherein the reliability information is associated with a Mean Time Between Failure (“MTBF”) for each component (
Bahl discloses, “Cost can also refer more generally to other metrics, such as … reliability (e.g., … Mean Time Between Failure (MTBF)…),” ¶ 0069, and “The parameters of the SLA can vary depending on the capabilities of the CSP and/or customer requirements, but can include requirements regarding performance, availability, reliability, security, computing resource utilization, power consumption, and/or specific quantifiable metrics, such as … MTBF… and the like,” ¶ 0070.).
Dimitrovich in view of Ellsworth and Casey, and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer devices. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth and Casey to incorporate the teachings of Bahl and provide wherein the reliability information is associated with a Mean Time Between Failure (“MTBF”) for each component. Doing so would help provide an easily identifiable metric to measure and maintain reliability. (Bahl discloses, “The SLA can define the services provided by the CSP and/or requested by the customer and how to measure the services as agreed to by the parties, among other terms,” ¶ 0070.).
Claim 14 is a method claim corresponding to the system Claim 4. Therefore, Claim 14 is rejected for the same reasons set forth in the rejection of Claim 4.
Regarding Claim 5, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the system of claim 4, wherein the cost information is associated with a Total Cost of Ownership (“TCO”) for each component (
Bahl discloses, “The governance metering module 420 can monitor the service mesh application to ensure the application complies with any TCO constraints, SLA requirements, and other criteria for governing the provisioning, deployment, and operation of the application at various levels of granularity. The governance metering module 420 can track TCO and TCO constraints for the application and individual component-level monetary costs and constraints for the application's layers, services, and microservices to ensure the application adheres to its TCO constraints,” ¶ 0080.).
Dimitrovich in view of Ellsworth and Casey, and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer devices. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth and Casey to incorporate the teachings of Bahl and provide wherein the cost information is associated with a Total Cost of Ownership (“TCO”) for each component. Doing so would help provide an easily identifiable metric to measure and control cost. (Bahl discloses, “The governance metering module 420 can identify patterns and trends among the request metrics captured by the request metering module 416, the resource utilization metrics captured by the resource metering module 418, monetary cost metrics, the SLA KPIs, and other governance metrics captured by the governance metering module 420,” ¶ 0080.).
Claim 15 is a method claim corresponding to the system Claim 5. Therefore, Claim 15 is rejected for the same reasons set forth in the rejection of Claim 5.
Regarding Claim 8, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the system of claim 5, wherein the cloud computing design evaluation platform is further to determine a Service Level Agreement (“SLA”) associated with the cloud computing design and the evaluation result comprises a selection of one of the automatically created potential variants based on the SLA, the overall reliability scores, and the overall cost scores (
PNG
media_image8.png
488
800
media_image8.png
Greyscale
Dimitrovich discloses, “When architecting a system, how often do you start with availability requirements or service level agreement (SLA)? … Yet, we should consider eventual desired level of availability and ensure that we can grow our system into it when the time comes,” Page 1, and “By hosting your stack on AWS, you can achieve highest levels of availability, including data center redundancy, as well as dynamic horizontal scalability in an easy and cost effective way,” Page 8. This means that a potential variant will be selected based on both reliability and cost metrics, with an associated SLA that is depicted in the above figure from Page 6.).
Claim 17 is a method claim corresponding to the system Claim 8. Therefore, Claim 17 is rejected for the same reasons set forth in the rejection of Claim 8.
Regarding Claim 9, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the system of claim 5, wherein the cloud computing design evaluation platform continuously monitors the cloud computing design in real time based on design performance (
Bahl discloses, “At the activity 520, the multi-cloud service mesh orchestration platform can continuously poll and fetch or otherwise receive resource utilization and governance metrics for the microservice containers,” ¶ 0111.).
Dimitrovich in view of Ellsworth and Casey, and Bahl are both considered to be analogous to the claimed invention because they are in the same field of computer devices. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth and Casey to incorporate the teachings of Bahl and provide wherein the cloud computing design evaluation platform continuously monitors the cloud computing design in real time based on design performance. Doing so would help allow for efficiently making different decisions based on the design performance, in order to optimize the performance of the overall system promptly. (Bahl discloses, “From the activities 518, 520, and 522, the workflow 500 may proceed to the activity 524 to evaluate the request metrics, resource utilization metrics, governance metrics, and metrics regarding unreserved compute instances, and other metrics resource utilization metrics to determine whether to provision new compute instances and how and where to provision them, migrate existing microservice containers and where to migrate them, and/or hibernate or terminate currently provisioned compute instances for existing microservices,” ¶ 0114.).
Claim 19 is a non-transitory machine-readable medium claim corresponding to the system Claim 9. Therefore, Claim 19 is rejected for the same reasons set forth in the rejection of Claim 9.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1), Casey (US 20210136178 A1), Bahl (US 20210019194 A1), and Miller (US 20210256125 A1).
Regarding Claim 6, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the system of claim 5, wherein potential variants of the master variant are created by expanding the master variant with parallel (
PNG
media_image8.png
488
800
media_image8.png
Greyscale
Dimitrovich discloses the above figure on Page 6, which is a diagram that shows a maximum number of parallel levels being determined as 3, and the master variant shown in the figure on Page 2 being expanded accordingly with parallel components into a potential example variant based on that maximum number of parallel levels.).
Dimitrovich in view of Ellsworth, Casey, and Bahl does not teach the parallel components are identical.
However, Miller teaches the parallel components could be identical (
Miller discloses, “Cloud based compute system 595 can include any type of networked computing devices (e.g., a federation of homogeneous or heterogeneous storage devices) that together provide computing and data storage capabilities to one or more servers and/or clients,” ¶ 0105.).
Dimitrovich in view of Ellsworth, Casey, and Bahl, and Miller are both considered to be analogous to the claimed invention because they are in the same field of online computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth, Casey, and Bahl to incorporate the teachings of Miller and provide wherein potential variants of the master variant are created by expanding the master variant with parallel identical components. Doing so would help provide more parallelization for the system. (Miller discloses, “Thus, the present invention can take advantage of platforms such as Spark and Kubernetes which facilitate parallel computation in the cloud,” ¶ 0105.).
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1), Casey (US 20210136178 A1), Bahl (US 20210019194 A1), Miller (US 20210256125 A1), and Matena (US 20050005200 A1).
Regarding Claim 7, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the system of claim 5. Dimitrovich in view of Ellsworth, Casey, and Bahl does not teach wherein at least one potential variant of the master variant is created by expanding the master variant with a parallel alternate component having a different MTBF.
However, Miller teaches wherein at least one potential variant of the master variant is created by expanding the master variant with a parallel alternate component (
Miller discloses, “Cloud based compute system 595 can include any type of networked computing devices (e.g., a federation of homogeneous or heterogeneous storage devices) that together provide computing and data storage capabilities to one or more servers and/or clients,” ¶ 0105.).
Dimitrovich in view of Ellsworth, Casey, and Bahl, and Miller are both considered to be analogous to the claimed invention because they are in the same field of online computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth, Casey, and Bahl to incorporate the teachings of Miller and provide wherein at least one potential variant of the master variant is created by expanding the master variant with a parallel alternate component. Doing so would help provide more parallelization for the system. (Miller discloses, “Thus, the present invention can take advantage of platforms such as Spark and Kubernetes which facilitate parallel computation in the cloud,” ¶ 0105.).
Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller does not teach the parallel alternate component having a different MTBF.
However, Matena teaches alternate components having a different MTBF (
Matena discloses, “Also, the features include optimally using a distributed computer system that includes nodes with different mean-time between failures (MTBF) rating and allowing the applications and the software platform to be upgraded to a new version without stopping the applications or losing availability of the service implemented by the applications,” ¶ 0019.
After the combination of Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, with Matena, the different mean-times between failures (MTBF) from Matena can be used for the parallel components from Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, in order to make the components alternate instead of identical.).
Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, and Matena are both considered to be analogous to the claimed invention because they are in the same field of online computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller to incorporate the teachings of Matena and provide the parallel alternate component having a different MTBF. Doing so would help provide more flexibility in parallelization for the system. (Matena discloses, “Advantages of using replication constraints include the capability to control precisely how applications are replicated across the nodes of varying reliability (nodes with different MTBF),” ¶ 0350.).
Regarding Claim 16, Dimitrovich in view of Ellsworth, Casey, and Bahl teaches the method of claim 15. Dimitrovich in view of Ellsworth, Casey, and Bahl does not teach wherein potential variants of the master variant are created via at least one of: (i) expanding the master variant with parallel identical components, and (ii) expanding the master variant with a parallel alternate component having a different MTBF.
However, Miller teaches wherein potential variants of the master variant are created via at least one of:
(i) expanding the master variant with parallel identical components (
Miller discloses, “Cloud based compute system 595 can include any type of networked computing devices (e.g., a federation of homogeneous or heterogeneous storage devices) that together provide computing and data storage capabilities to one or more servers and/or clients,” ¶ 0105.
PNG
media_image8.png
488
800
media_image8.png
Greyscale
Dimitrovich already discloses the above figure on Page 6, which is a diagram that shows a maximum number of parallel levels being determined as 3, and the master variant shown in the figure on Page 2 being expanded accordingly with parallel components into a potential example variant based on that maximum number of parallel levels. After the combination of Dimitrovich in view of Ellsworth, Casey, and Bahl, with Miller, said parallel components can be homogeneous, or identical.), and
(ii) expanding the master variant with a parallel alternate component (
Miller discloses, “Cloud based compute system 595 can include any type of networked computing devices (e.g., a federation of homogeneous or heterogeneous storage devices) that together provide computing and data storage capabilities to one or more servers and/or clients,” ¶ 0105.).
Dimitrovich in view of Ellsworth, Casey, and Bahl, and Miller are both considered to be analogous to the claimed invention because they are in the same field of online computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth, Casey, and Bahl to incorporate the teachings of Miller and provide wherein potential variants of the master variant are created via at least one of: (i) expanding the master variant with parallel identical components, and (ii) expanding the master variant with a parallel alternate component. Doing so would help provide more parallelization for the system. (Miller discloses, “Thus, the present invention can take advantage of platforms such as Spark and Kubernetes which facilitate parallel computation in the cloud,” ¶ 0105.).
Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller does not teach the parallel alternate component having a different MTBF.
However, Matena teaches alternate components having a different MTBF (
Matena discloses, “Also, the features include optimally using a distributed computer system that includes nodes with different mean-time between failures (MTBF) rating and allowing the applications and the software platform to be upgraded to a new version without stopping the applications or losing availability of the service implemented by the applications,” ¶ 0019.
After the combination of Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, with Matena, the different mean-times between failures (MTBF) from Matena can be used for the parallel components from Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, in order to make the components alternate instead of identical.).
Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller, and Matena are both considered to be analogous to the claimed invention because they are in the same field of online computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth, Casey, Bahl, and Miller to incorporate the teachings of Matena and provide the parallel alternate component having a different MTBF. Doing so would help provide more flexibility in parallelization for the system. (Matena discloses, “Advantages of using replication constraints include the capability to control precisely how applications are replicated across the nodes of varying reliability (nodes with different MTBF),” ¶ 0350.).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Dimitrovich (“Architecture I: How to Get High Availability”) in view of Ellsworth (US 20210157703 A1), Casey (US 20210136178 A1), and FortiOS (Performance SLA - SLA targets).
Regarding Claim 12, Dimitrovich in view of Ellsworth and Casey teaches the system of claim 1. Dimitrovich in view of Ellsworth and Casey does not teach wherein all of the sequential sequence of a set of components, the maximum number of parallel levels, and a Service Level Agreement (“SLA”) are received from a user via an interactive graphical user interface.
However, FortiOS teaches wherein all of the sequential sequence of a set of components, the maximum number of parallel levels, and a Service Level Agreement (“SLA”) are received from a user via an interactive graphical user interface (
PNG
media_image10.png
337
996
media_image10.png
Greyscale
PNG
media_image11.png
818
1230
media_image11.png
Greyscale
Both Figures are from Page 2.
Here, the SLA is represented by SLA Targets, which are threshold parameters specified by the user.
Here, wan1 and wan2 are part of a sequence of a set of components, and both the components, and the SLA, are specified by a user via a graphical user interface.
Dimitrovich already teaches using a maximum number of parallel levels to generate potential variants. After the combination of Dimitrovich in view of Ellsworth and Casey, with FortiOS, the graphical user interface from FortiOS includes inputting the set of components from Dimitrovich as a sequence; and the maximum number of parallel levels, as specified by Dimitrovich, is also specified as a parameter in the graphical user interface from FortiOS.).
Dimitrovich in view of Ellsworth and Casey, and FortiOS are both considered to be analogous to the claimed invention because they are in the same field of cloud computing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Dimitrovich in view of Ellsworth and Casey to incorporate the teachings of FortiOS and provide wherein all of the sequential sequence of a set of components, the maximum number of parallel levels, and a Service Level Agreement (“SLA”) are received from a user via an interactive graphical user interface. Doing so would improve flexibility in the setup of the cloud computing design based on the sequence of a set of components, the maximum number of parallel levels, and the service level agreement.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gokan Khan et al. (US 20220385542 A1): Performance Modeling For Cloud Applications
Horowitz et al. (US 20170344618 A1): Systems and Methods for Managing Distributed Data Deployments
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 ANDREW SUN whose telephone number is (571)272-6735. The examiner can normally be reached Monday-Friday 8:00-5:00.
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, Aimee Li can be reached at (571) 272-4169. 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.
/ANDREW NMN SUN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights