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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 2, 9-11, 13, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz (US 2021/0382912) and further in view of Giannetti (US 2020/0348918) and further in view of Govindaraju (US 9,244,669).
Regarding claim 1, Horowitz teaches: A method comprising:
receiving a deployment request to deploy a plurality of clusters across a plurality of cloud computing environments (¶ 37, “in response to a request via client 510 (e.g., via the user interfaces described herein, such as selection of “Create Cluster” interface element or “Apply Changes” interface element)”), at least some of the clusters of the plurality of clusters being multi-region clusters (¶ 23, “It is realized that enabling cross-region deployments for cloud providers allows for improved disaster recovery and fault tolerance”) and at least one of the multi-region clusters comprising differences in network reliability and network bandwidth than other multi-region clusters in the plurality of clusters (¶ 23, “Each region may include a number of independent availability zones. Availability zones consist of one or more discrete data centers, each with redundant power, networking, and connectivity, housed in separate facilities”);
configuring the plurality of clusters according to the set of standards to create a configured plurality of clusters (¶ 28, “the provisioning service can be configured to enable cross-cloud configuration options to specify the manner in which the clusters/replica set members are to be deployed across multiple cloud providers and/or geographical regions.”); and
deploying the configured plurality of clusters across the plurality of cloud computing environments (¶ 37, “provisioning service 502 can be configured to generate an instantiation of a distributed database on multiple cloud providers 504, 506, 508”).
Horowitz does not teach as clearly as Giannetti teaches: receiving a set of standards (¶ 17, “the data repository includes cluster definitions 118”) comprising one or more standardizing requirements to be applied to multiple clusters of the plurality of clusters (¶ 17, “the cluster definitions 118 are files or other data structures that include metadata defining clusters to be created on the cluster platform 106” and ¶ 13, “define configurations of clusters and reuse those definitions”) for deploying the plurality of clusters across the plurality of cloud computing environments (¶ 37, “the “common” sub-level of the service map 120 indicates services that are deployed for all clusters, regardless of the type of the clusters, such that default services or otherwise required core services are listed in the common sub-level”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of receiving a set of standards comprising one or more standardizing requirements to be applied to multiple clusters of the plurality of clusters for deploying the plurality of clusters across the plurality of cloud computing environments, as taught by Giannetti, in the same way to the plurality of clusters, as taught by Horowitz. Both inventions are in the field of deploying a plurality of clusters, and combining them would have predictably resulted in “deploying an application cluster based on a cluster definition and service templates,” as indicated by Giannetti (¶ 4).
Horowitz and Giannetti do not teach as clearly as Govindaraju teaches: configuring the plurality of clusters according to the set of standards to create a configured plurality of clusters (col. 2:15-18, “designers of cloud-deployable applications can create blueprints that can be subsequently used one or more times to deploy instances of the same application in numerous deployment environments”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of configuring the plurality of clusters according to the set of standards to create a configured plurality of clusters, as taught by Govindaraju, in the same way to the plurality of clusters, as taught by Horowitz and Giannetti. Both inventions are in the field of configuring a plurality of clusters, and combining them would have predictably resulted in “configuring a blueprint to deploy different nodes of an application across multiple deployment environments (e.g., different deployment environments of the same cloud provider or of different cloud providers),” as indicated by Govindaraju (col. 2:31-35).
Regarding claim 2, Govindaraju teaches: The method of claim 1, wherein the set of standards includes at least one of a component feature, a component dependency, a component definition, or a component property specified by the user (col. 4:18-21, “Blueprints, such as the application blueprint 108, define the structure of an application, enable the use of standardized application infrastructure components, and specify installation dependencies and default configurations”).
Regarding claim 9, Govindaraju teaches: The method of claim 1, further comprising: storing the set of standards for future cluster deployments (col. 3:57-62, “the application provisioning manager 100 also includes an example profile repository 122 to store deployment profiles such as the example deployment profile 120 for subsequent use at deployment time (e.g., a deployment phase) to deploy, for example, the application 116”); and accessing and applying the stored set of standards as a default set of standards for a future cluster deployment (col. 2:61-64, “the application deployment profile is useable at a deployment time to deploy the application across the plurality of deployment environments”).
Regarding claim 10, Govindaraju teaches: The method of claim 9, further comprising: upon the future cluster deployment, prompting the user to edit or add to the set of standards (col. 3:39-42, “The example blueprint editor 102 is provided to receive user inputs and generate an example application blueprint 108 (e.g., a user-designed application blueprint) that is based on a user-specified configuration”).
Regarding claim 11, Horowitz teaches: The method of claim 1, wherein the at least one of the multi-region clusters further comprises differences in network latency than the other multi-region clusters in the plurality of clusters (¶ 35, “Such configurations allow placement and distribution of data to be managed in compliance with the strictest policies and data redundancy requirements while minimizing read latency (e.g., by keeping the data close to the requesting end users/clients)”).
Claims 13, 19, and 20 recite commensurate subject matter as claims 1 and 9. Therefore, they are rejected for the same reasons.
Claim(s) 3, 7, 14, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, Giannetti, and Govindaraju, as applied above, and further in view of Natanzon (US 10,860,444).
Regarding claim 3, Horowitz, Giannetti, and Govindaraju do not teach; however, Natanzon teaches: each cluster of the plurality of clusters comprises a plurality of stateful sets and each stateful set of the plurality of stateful sets has a plurality of pods (col. 7:43-48, “In Kubernetes, StatefulSets are intended to be used with stateful applications and distributed systems. Pods in a StatefulSet have a unique ordinal index and a stable (“sticky”) network identity. This identity is based on a unique ordinal index that is assigned to each pod by a StatefulSet controller”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of each cluster of the plurality of clusters comprises a plurality of stateful sets and each stateful set of the plurality of stateful sets has a plurality of pods, as taught by Natanzon, in the same way to the plurality of clusters, as taught by Horowitz, Giannetti, and Govindaraju. Both inventions are in the field of deploying clusters, and combining them would have predictably resulted in “persistent volumes attached to the pod,” as indicated by Natanzon (abstract).
Regarding claim 7, Natanzon teaches: The method of claim 3, wherein each of the stateful sets comprises an ordinal index that assigns ordinals associated with a corresponding plurality of pods (col. 7:45-46, “Pods in a StatefulSet have a unique ordinal index and a stable (“sticky”) network identity”).
Claim(s) 14 and 18 recite(s) commensurate subject matter as claim(s) 3 and 7. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 4 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, Giannetti, Govindaraju, and Natanzon, as applied above, and further in view of Javadekar (US 11,275,573).
Regarding claim 4, Horowitz, Giannetti, Govindaraju, and Natanzon do not teach; however, Javadekar teaches: at least one stateful set of the plurality of stateful sets runs Apache Kafka or Kafka structured query language (col. 2:1-3, “When Kafka is running on Kubernetes®, the brokers within a cluster have their identities recorded and stored in a StatefulSet on Kubernetes®”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of at least one stateful set of the plurality of stateful sets runs Apache Kafka or Kafka structured query language, as taught by Javadekar, in the same way to the plurality of clusters, as taught by Horowitz, Giannetti, Govindaraju, and Natanzon. Both inventions are in the field of deploying clusters, and combining them would have predictably resulted in “providing guarantees about the ordering and uniqueness of each pod,” as indicated by Javadekar (col. 2:7-8).
Claim(s) 15 recite(s) commensurate subject matter as claim(s) 4. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 5 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, Giannetti, Govindaraju, and Natanzon, as applied above, and further in view of Li (US 2021/0303365).
Regarding claim 5, Horowitz, Giannetti, Govindaraju, and Natanzon do not teach; however, Li teaches: each pod of at least one stateful set of the plurality of stateful sets has their own lifecycle and a state selected from a group consisting of SETUP, RUN, DISABLED, and DELETED (¶ 41, “The lifecycle management module provides a control layer for Kubernetes resource creation and cleanup according to the benchmark's running state and user configuration. This module is also used to perform user-specified resource manipulation actions to be measured, including CREATE, GET, LIST, UPDATE, SCALE, and DELETE”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of each pod of at least one stateful set of the plurality of stateful sets has their own lifecycle and a state selected from a group consisting of SETUP, RUN, DISABLED, and DELETED, as taught by Li, in the same way to the plurality of clusters, as taught by Horowitz, Giannetti, Govindaraju, and Natanzon. Both inventions are in the field of managing cluster configurations, and combining them would have predictably resulted in “providing guarantees about the ordering and uniqueness of each pod,” as indicated by Li (col. 2:7-8).
Claim(s) 16 recite(s) commensurate subject matter as claim(s) 5. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 6 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, Govindaraju, and Natanzon, as applied above, and further in view of Zwiegincew (US 11,520,506).
Regarding claim 6, Horowitz, Govindaraju, and Natanzon do not teach; however, Zwiegincew teaches: based on all pods in at least one stateful set of the plurality of stateful sets having a RUN state, causing the at least one stateful set of the plurality of stateful sets to be fully available (col. 10:27-30, “Status 320 may further define the number of fault domains 110 that are ready—e.g., fully provisioned and all pods in a fault domain 110 have a ready condition”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of based on all pods in at least one stateful set of the plurality of stateful sets having a RUN state, causing the at least one stateful set of the plurality of stateful sets to be fully available, as taught by Zwiegincew, in the same way to the plurality of clusters, as taught by Horowitz, Giannetti, Govindaraju, and Natanzon. Both inventions are in the field of managing cluster configurations, and combining them would have predictably resulted in “dissemination of services across fault domains,” as indicated by Zwiegincew (col. 1:9-10).
Claim(s) 17 recite(s) commensurate subject matter as claim(s) 6. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, Giannetti, and Govindaraju, as applied above, and further in view of Gupta (US 11,593,180).
Regarding claim 12, Horowitz, Giannetti, and Govindaraju do not teach; however, Gupta teaches: the at least one of the multi-region clusters further comprises differences in network cost than the other multi-region clusters in the plurality of clusters (claim 3, “a plurality of clusters having a latency estimate below a latency threshold with respect to an end-user location identified in the request; and determining, by one or more processors, that the cluster has a lowest cost estimate of the plurality of clusters”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the at least one of the multi-region clusters further comprises differences in network cost than the other multi-region clusters in the plurality of clusters, as taught by Gupta, in the same way to the plurality of clusters, as taught by Horowitz, Giannetti, and Govindaraju. Both inventions are in the field of managing cluster configurations, and combining them would have predictably resulted in “dissemination of services across fault domains,” as indicated by Gupta (col. 1:9-10).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,995,478. Although the claims at issue are not identical, they are not patentably distinct from each other because the U.S. Patent No. 11,995,478 teaches or at least suggests each and every limitation of the instant application. See claim correspondence below.
Instant Application
U.S. Patent No. 11,995,478
1. A method comprising: receiving a deployment request to deploy a plurality of clusters across a plurality of cloud computing environments,
1. A method comprising: receiving a deployment request to deploy a plurality of clusters across a plurality of cloud computing environments, the deployment request relating to one or more operational actions for computing devices associated with the plurality of clusters, the plurality of clusters associated with a single application programming interface (API) and
at least some of the clusters of the plurality of clusters being multi-region clusters and at least one of the multi-region clusters comprising differences in network reliability and network bandwidth from other multi-region clusters in the plurality of clusters;
at least some of the clusters of the plurality of cluster being multi-region clusters, at least one of the multi-region clusters comprising differences in network reliability, network latency, network bandwidth, and network cost than other multi-region clusters in the plurality of clusters;
receiving a set of standards comprising one or more standardizing requirements to be applied to multiple clusters of the plurality of clusters for deploying the plurality of clusters across the plurality of cloud computing environments;
causing presentation of a user interface for specifying a set of standards for deploying the plurality of clusters across the plurality of cloud computing environments;
configuring the plurality of clusters according to the set of standards to create a configured plurality of clusters; and
configuring the plurality of clusters according to the set of standards to create a configured plurality of clusters; and
deploying the configured plurality of clusters across the plurality of cloud computing environments.
deploying the configured plurality of clusters across the plurality of cloud computing environments, each cluster of the plurality of clusters comprising a plurality of stateful sets and each stateful set of the plurality of stateful sets having a plurality of pods, at least one stateful set of the plurality of pods running Apache Kafka or Kafka structured query language and each pod of the at least one stateful set having their own lifecycle and a state selected from a group consisting of SETUP, RUN, DISABLED, and DELETED.
Allowable Subject Matter
Claim 8 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9: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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights