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 .
This is in response to communications filed on 5/10/24.
Claims 1-20 are pending.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Claims 1-20 recite method (claims 1-7), system (claims 8-14) and computer-readable medium (claims 15-20).
The claim(s) 1 recite(s) “generating a directed acyclic graph based at least in part on a plurality of service plans comprising the service plan, the directed acyclic graph defining a second order for executing a set of releases comprising the release, the set of releases being associated with a second process for bootstrapping the plurality of services within the cloud-computing environment” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of the generic computer component. That is, other than reciting “by a cloud infrastructure orchestration service,” nothing in the claim element precludes the step from practically being performed in the mind. The DAG generation, where DAG defines an execution order for code (i.e., releases), is a classical mathematical algorithm that can be performed in paper/pencil. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. (Step 2A prong one analysis).
This judicial exception is not integrated into a practical application. In particular, the claim recites the additional limitations – “obtaining, by the cloud infrastructure orchestration service, a service plan defining a first order for executing one or more releases as part of a first process for bootstrapping within a cloud computing environment”, “obtaining, by the cloud infrastructure orchestration service, a manifest identifying a configuration file that defines operations associated with executing a release of the one or more releases”, “executing, by the cloud infrastructure orchestration service, a subset of releases of the set of releases associated with the second process for bootstrapping the plurality of services within the cloud-computing environment, the subset of releases being executed according to the second order based at least in part on traversing the directed acyclic graph” . The “obtaining a service plan defining …” and “obtaining a manifest …manifest identifying a configuration file…” can be mere data gathering step and represent an extra solution activity. The “cloud infrastructure orchestration service” in these steps is recited at a high-level of generality (i.e., as a generic component performing obtaining plan, obtaining manifest and executing releases) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The “executing a subset of releases, the subset of releases being executed according to the second order based on traversing the DAG” is an “apply-it” type limitation, where claim recites only idea of a solution or outcome without reciting sufficient details of how the solution is obtained. The claim itself sets no further mechanism of action for executing the releases according to the second order of the graph or how the execution is performed except based on “traversing the DAG.” (MPEP 2106.04(d)(1): The application or use of the judicial exception in this manner meaningfully limits the claim by going beyond generally linking the use of the judicial exception to a particular technological environment). Therefore, the judicial exception is not into a practical application (Step 2A prong two analysis).
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional limitations – “obtaining, by the cloud infrastructure orchestration service, a service plan defining a first order for executing one or more releases as part of a first process for bootstrapping within a cloud computing environment”, “obtaining, by the cloud infrastructure orchestration service, a manifest identifying a configuration file that defines operations associated with executing a release of the one or more releases”, “executing, by the cloud infrastructure orchestration service, a subset of releases of the set of releases associated with the second process for bootstrapping the plurality of services within the cloud-computing environment, the subset of releases being executed according to the second order based at least in part on traversing the directed acyclic graph” – either individually or in combination, do not amount to significantly more. Claim does not set forth any description of how the execution of releases contributes to the bootstrapping and BRI includes obtaining plan or manifest file, which is well understood, routine and conventional routine or conventional (MPEP 2106.05(d)(II): receiving or transmitting data over a network; storing or retrieving information from memory). The execution of release according to second order based on the traversing the DAG does not meaningfully limit the claim. Mere instructions to apply an exception using a generic computer component (i.e., cloud infrastructure orchestration service) cannot provide an inventive concept (MPEP 2106.04(a)(2): "the discovery of [a mathematical formula] cannot support a patent unless there is some other inventive concept in its application. Flook, 437 U.S. at 594, 198 USPQ at 199). The claim is not patent eligible. (Step 2B analysis)
For claims 2, 9, 16, validating the service plan can be performed in mind and thus, claim is patent ineligible.
For claims 3, 10, 17, determining second set of dependencies and determining agreement between dependencies are mental steps. Obtaining static flock analysis data is a mere data gathering step. Claim is patent ineligible.
For claims 4, 11, 18, determining that the service plan is consistent based on match is a mental step. Claim is patent ineligible.
For claims 5, 12, 19, determining plans are compatible based on generating graph and detecting no cycle, adding service plan to a set of service plans, deriving a version set are mental steps. Claim is patent ineligible.
For claims 6, 13, version set including various items and other structures can be performed in paper/pencil. Claim is patent ineligible.
For claims 7, 14, 20, determining compatible plans by determining no duplicate capability publications is a mental process. Claim is not patent eligible.
For claim 8, claim recites limitations that are addressed in the analysis of claim 1. The additional elements - processors and memories storing instructions are considered generic recitations of technical elements as they are recited at a high level of generality. These elements are being used as "tools to automate the abstract idea" (see MPEP 2106.05 (f)), and do not integrate the abstract idea into a practical application. They are not recitations of a special purpose computer or transformation. Thus, the claim is directed to abstract idea.
For claim 15, the analysis provided in claim 1 applies to the ineligibility of the claim 15. The recited additional elements, "a non-transitory computer readable medium and one or more processors", beyond the judicial exception but does not integrate into practical application. The non-transitory computer readable medium and one or more processors, are recited at a high level of generality and recited so generically that they represent no more than mere instructions to apply the judicial exception on a computer.
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.
Claim 1 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7 of copending Application No. 18/661396 (reference application), in view of Vergara et al (US Patent Application Publication 2024/0345830). Although the claims at issue are not identical, they are not patentably distinct from each other because of the claim correspondence given below:
Claim 1 of the pending application
Claim 1 of the co-pending application
A computer-implemented method, comprising: obtaining, by a cloud infrastructure orchestration system, a service plan defining a first order for executing one or more releases as part of a first process for bootstrapping a service within a cloud-computing environment;
A computer-implemented method, comprising: obtaining, by a cloud infrastructure orchestration system, a service plan defining a first release execution order for executing a release of one or more releases associated with a first process for bootstrapping a service of a plurality of services at one or more execution targets of a cloud-computing environment;
generating, by the cloud infrastructure orchestration service, a directed acyclic graph based at least in part on a plurality of service plans comprising the service plan, the directed acyclic graph defining a second order for executing a set of releases comprising the release, the set of releases [[being associated with a second process]] for bootstrapping the plurality of services within the cloud-computing environment;
generating, by the cloud infrastructure orchestration system, a directed acyclic graph based at least in part on a plurality of service plans comprising the service plan, the directed acyclic graph defining a second release execution order for executing a set of releases comprising the one or more releases, the second release execution order comprising the first release execution order for executing the one or more releases associated with the first process for bootstrapping the service;
and executing, by the cloud infrastructure orchestration service, a subset of releases of the set of releases associated with the second process for bootstrapping the plurality of services within the cloud-computing environment, the subset of releases being executed according to the second order based at least in part on traversing the directed acyclic graph.
executing, by the cloud infrastructure orchestration system, the release at an execution target of the one or more execution targets as part of a second process for bootstrapping the plurality of services at the one or more execution targets of the cloud-computing environment, the release being executed according to the second release execution order;
The claim 1 of the pending application mentions “executing a subset of releases, the subset of releases being executed based on traversing the directed acyclic graph”, while the co-pending application mentions “executing the release as part of a second process for bootstrapping, the release being executed according to the second release execution order”. However, co-pending application mentions that the directed acyclic graph defining a second release execution order for executing a set of releases comprising the one or more releases. Therefore, the execution of the subset of releases (which can be one or more) based on traversing DAG, as required by the pending application, is obvious over the limitations of the co-pending application.
The co-pending application does not explicitly mention about obtaining a manifest identifying a configuration file that defines operations associated with executing a release of the one or more releases. Vergara et al teach obtaining a manifest identifying a configuration file that defines operations associated with executing a release of the one or more releases (release configuration module 222 in Fig 2, 225, Fig 7 730 and 740 mentions release configuration file; [0099]). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide a configuration file defining the operations associated with execution of the releases, since that way releases can be executed in optimal fashions (Vergara [0040] [0095] pipeline to optimize the execution).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Objections
Claims 1-7, 13 are objected to because of the following informalities:
Claim 1 recites –the plurality of services—in lines 11-12, which lacks antecedent basis.
Claims 6 and 13 recite –the version set—in line 1, which lacks antecedent basis.
Claims 2-7 depend on claim 1 and incorporate the informalities.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3,10 and 17 recite – wherein validating the service plan further comprise--. It is not clear whether validating is one of the steps or an attribute without being part of steps. It is necessary to clearly set the boundary of the limitations. For the rest of the action, it is taken that validating the service plan is a step of the series of steps (just like claim 2).
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.
Claim(s) 1-4, 6-11, 13-18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glass et al (US Patent Application Publication 20210224122) further in view of Puranic et al (US Patent 12208521).
For claim 1, Glass et al teach the following limitations: A computer-implemented method (Fig 1 – Fig 18), comprising: obtaining, by a cloud infrastructure orchestration system (CIOS 102 in Fig 1; [0042[0063][0078]), a service plan defining a first order for executing one or more releases ([0068]-[0070][0060]-[0061] [0102] mention about plan; release plan defines the release; [0077]-[0078] – initiate release planning where desired; release may include combination of tasks [0070] – CIOS can generate and display release plan; once the team is satisfied with the plan they can create a release that references the plan; release has finite steps and well-defined start and end time [0061]; thus the plan defines order for executing the release) as part of a first process for bootstrapping a service ([0069]-[0070] mention release plan approval and language used to describe desired deployment behavior; [0033] mentions that deployment includes booting) within a cloud-computing environment (Fig 1) ([0140][0145][0149][0163] ; obtaining, by the cloud infrastructure orchestration service, a manifest identifying a configuration file ([0035] [0037] configuration file) that defines operations (configuration file may be a declarative file [0035][0037]) associated with executing a release of the one or more releases ([0125]][0132] configuration file code segment is associated with release); generating, by the cloud infrastructure orchestration service, a directed acyclic graph ([0134]; Fig 9) based at least in part on a plurality of service plans comprising the service plan (plans are mentioned [0080][0100][0101][0104][0105]; there are plural plans for regions associated release); , the directed acyclic graph defining a second order for executing (the DAG in Fig 9 corresponds to release in Fig 5; [0121], [0134] DAG provides order of execution), the set of releases being associated with a second process (plural regions have plural release and releases are coordinated globally; [0069] – release is scoped to a subset of regions; [0104] – CIOS generate releases; teams approve releases – [0106]; [0074] – coordinating global releases; thus plural releases are coordinated globally by CIOS central 102) for bootstrapping the plurality of services within the cloud-computing environment (booting is explained in [0033] [0037] deployment in Fig 15 includes booting the system); and executing, by the cloud infrastructure orchestration service, a subset of releases of the set of releases ([0104]-[0106] – various releases, world-wide releases and tactical releases are mentioned; these releases are executed in corresponding regions) associated with the second process (releases are coordinated by CIOS central , which requires a second process [0074]) for bootstrapping the plurality of services within the cloud-computing environment ([0037] Fig 15 – deployment; [0033] mentions that the deployment includes booting), the subset of releases being executed according to the second order based at least in part on traversing the directed acyclic graph (Fig 9 and Fig 12 show the DAG; Fig 15 mentions the deployment based on traversing the DAG; [0152] DAG specifies tasks for booting).
Glass et al teach the DAG shown in Fig 9 and Fig 12 for one release shown in Fig 5 ([0134] – DAGs associated with the release). Glass teaches a set of releases in ([0104]-[0106]) and coordinating the releases globally ([0074]), does not explain any DAG for the plural releases comprising the set of the releases. Glass et al do not explicitly mention how the releases are coordinated in [0074]. It is understood that each release can generate its own DAG as [0134] mentions each release has corresponding DAG. Puranic et al teach a system where multiple DAGs are combined to generate a single DAG (line 36, col 39; line 56, col 40 and lines 55-62 of col 41). It would have been obvious for one ordinary skill in the art before the effective filing date of the inventions to combine the DAGs of the releases to create one aggregated DAG so that the global coordination of the releases mentioned in [0074] can be facilitated. Such an aggregated DAG shows the users the actual dependency of the resources and other capabilities.
For claims 2, 9, 16, Glass et al teaches validating, by the cloud infrastructure orchestration service, the service plan based at least in part on the manifest ([0113] – results of plan operation is validated against the approved plan).
For claims 3, 10, 17, Glass et al teach wherein validating the service plan based at least in part on the manifest further comprises: obtaining, by the cloud infrastructure orchestration service, static flock analysis data corresponding to the configuration file identified by the manifest (Fig 3 and Fig 4 are associated with flock; [0032] mentions that the infrastructure is defined by the configuration file; [0005] configuration file associated with deployment; thus flock analysis corresponds to configuration file), the static flock analysis indicating a first set of dependencies (Fig 3 and Fig 4); determining, by the cloud infrastructure orchestration service, a second set of dependencies based at least in part on the service plan (the DAGS in Fig 9 and Fig 12, the linked lists shown in Fig 6- Fig 8; Fig 10-Fig 11 mention the second set of dependencies); and determining, by the cloud infrastructure orchestration service, that the first set of dependencies agree with the second set of dependencies (the DAGs are generated based on the dependencies; ET in Fig 3 cannot disagree with ET in Fig 9; with the teachings of Puranic, the DAGS are combined together to create an aggregate DAG; the DAG can only be generated when dependencies agree with one another).
For claims 4, 11, 18, Glass et al teach the following limitations: determining, by the cloud infrastructure orchestration service, that the service plan is consistent based at least in part on determining that first data corresponding to a first component of the service plan matches a second data corresponding to a second component of the service plan (service plan must be consistent – [0105]; outage in downstream service – second data corresponds to second component does not match first component’s availability data).
For claims 6, 13, Glass teaches wherein the version set comprises a plurality of version set items, a first version set item of the plurality of version set items being associated with a corresponding service plan, and a second version set item of the plurality of version set items lacking any service plan associations ([0058] and [0104] mention release have specific version tuple including flock version, artifact versions, realm and region; artifact version is associated with particular release version/plan and realm/region are not associated with service plan as these are constant irrespective of the service plan).
For claims 7, 14, 20, Glass teaches comprising determining, by the cloud infrastructure orchestration service, that the plurality of service plans is compatible ([0113]). Glass et al further teaches generating DAGs for capability data (Fig 12) and coordinating global releases ([0074]). Glass et al in view of Puranic et al can generate single aggregated DAG for global consideration as explained above with respect to claim 1. For capability DAG generation, duplicate capability publications are deleted as DAGs are generated based on non-duplication of nodes. Thus, with the aggregated DAG for the capability, the duplicate publications between service plans do not exist.
For claim 8, Fig 1 and Fig 12 show a cloud infrastructure orchestration system including processors and memories storing instructions ([0194]-[0198]) to cause the steps performed. The steps correspond to the step disclosed in claim 1 and the rejections set forth above for claim 1 disclose all the limitations corresponds to the steps performed.
For claim 15, Fig 1 and Fig 12 show a cloud infrastructure orchestration system including processors and memories storing instructions ([0194]-[0198]) to cause the steps performed. The steps correspond to the step disclosed in claim 1 and the rejections set forth above for claim 1 disclose all the limitations corresponds to the steps performed.
Conclusion
PTO-892 cites additional references that are related to the claim embodiments, but not relied upon for rejections.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Andrew Jung can be reached at 571-270-3779. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175