DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office Action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/16/2026 has been entered.
3. Applicant's amendment and response received 03/16/2026, responding to the 12/17/2025 Office Action provided in the rejections of claims 1-20, wherein at least independent claims 1, 18 and 20 have been amended. Claims 1-20 remain pending in the application; which has been fully considered by the Examiner.
Response to Arguments
4. Applicant’s arguments with respect to newly amended independent claims 1, 18 and 20 and claims 2-17 on pages 7-10 of the response have been fully considered but they are not persuasive are moot in view of the new ground(s) of rejection- see Setty (Art newly made of record) and Liljeback (Art newly made of record) as applied below, as they further teach such use.
Claim Rejections - 35 USC § 101
5. 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.
6. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claims 1, 18 and 20, the limitations “determining/determine validation status of the stack,” and “designating/designate the stack as a valid stack” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Claims 1, 18 and 20: Under Prong 2 Step 2A, the judicial exception is not integrated into a practical application. The additional elements “a cloud computing environment”, “a publication service system”, “a system”, “a memory”, “a cloud computing environment”, “a publication service system”, and “non-transitory computer-readable storage medium” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. The additional element “receiving… identification of a stack to be validated” and “retrieving with the publication service system job information” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f) and (g), respectively.
Claims 1, 18 and 20: Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements “a cloud computing environment”, “a publication service system”, “a system”, “a memory”, “a cloud computing environment”, “a publication service system”, and “a non-transitory computer-readable storage medium” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, and the additional element “receiving… identification of a stack to be validated” and “retrieving with the publication service system job information” is merely gathering data which the courts have identified as well-understood, routine conventional activity. See for example Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, MPEP 2106.05(d). Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Claims 1, 18 and 20 recite further additional elements “a cloud computing environment”, “a publication service system”, “a system”, “a memory”, “a cloud computing environment”, “a publication service system”, and “non-transitory computer-readable storage medium” These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 1, 18 and 20 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.,
Regarding claims 12 and 13, the limitations recited in these claims merely describe the “determined that the stack is valid”, “determining the validation status”, “identifying the latest one or more jobs”, and “identifying the latest one or more jobs” as in each of claims 1, 18 and 20, thus, are likewise analyzed under Prong 1 as mental process.
Regarding claims 2-11, 14-17 and 19, the additional elements of “obtaining a predetermined test-script template corresponding to the category associated with the product requirement and the receiving is enabled”, “ , one or more policies allowing access”, “allows the publication service system to read”, “receiving the stack in the customer tenancy”, “uploading the stack to the customer tenancy”, “testing the stack in the customer tenancy”, “jobs comprise at least one of: PLAN; APPLY; or DESTROY”, “receiving identification of the stack”, “retrieving the job information”, “jobs associated with the stack correspond to validation tests”, “downloading the stack”, “receiving a request”, “publishing the stack”, “the stack comprises a terraform stack”, “the stack represents definitions of a group”, “receive in the cloud computing environment policies”, “receive the stack in the customer” and “test the stack in the customer tenancy” are analyzed under Prong 2 as mere data gathering which does not integrate the judicial exception into a practical application, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claims 1, 18 and 20.
Claim Rejections - 35 USC § 103
7. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8. Claims 1-3, 6, 7, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Qadri et al., US 2019/0213104 (hereinafter Qadri) in view of Tolbert et al., US 20240272957 (hereinafter Tolbert) in view of Setty, US Patent No. 11,210,150 (hereinafter Setty).
In regards to claim 1, Qadri teaches:
A method comprising: (Abstract, see described technologies facilitate cloud validation using validation as a service (VaaS). A cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud).
determining validation status of the stack based on the retrieved job information (Fig. 4, Monitor 42 test executions, receive 414 test results, Provide 416 test results, Determine 418 validation status 420).
designating the stack as a valid stack when it is determined that the validation status indicates the stack is valid (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter), (p. 11, [0294] see receiving 414 at least one certification test result which was generated by execution of one or more certification test executable portions, and providing 416 one or more certification test results for use in making a determination 418 whether to validate the candidate cloud) and (p. 12, [0311], see Some examples include validating and certifying a private cloud by executing tests, gatherer jobs such as collecting inventory of the solution, and executing a job such as a service health validator).
Qadri doesn't explicitly teach:
retrieving with the publication service system job information from the customer tenancy relevant to the stack.
However, Tolbert teaches such use: (Abstract, see s cloud computing system has an external application program interface (API) allowing a user to access the cloud computing system and sending a job to at least one application. At least one application supervisor is provided, wherein each application supervisor monitors a specific application and deploys at least one cloud worker to the job. A database stores status information of the at least one cloud worker, job details and other telemetry data. An internal API is coupled to the database. A state machine receives the status information of the at least one cloud worker, job details and other telemetry data via the internal API. The state machine determines when servers need to be deleted, servers need to be created, when the at least one cloud worker needs to be deleted or additional cloud workers created).
Qadri and Tolbert are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri and Tolbert before him or her, to modify the system of Qadri to include the teachings of Tolbert, as a system for application cloud management, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation services, because that would provide Qadri with the ability to quickly react to load conditions, as suggested by Tolbert (Abstract, P. 4, [0035]).
Qadri and Tolbert, in particular Qadri doesn't explicitly teach:
receiving, from a customer tenancy in a cloud computing environment and at a publication service system identification of a stack to be validated; the stack having an associated stack identifier.
However, Setty teaches such use: (column 5, lines 17-24, see during the building of the cloud infrastructure system provided by the infrastructure devices 202, the user (e.g., a deployment engineer) may verify the components identified in the template by the cloud infrastructure system vendors/providers...the component dependency information may provide any details about the hardware and software components in the cloud infrastructure system and their dependencies on each other).
Qadri, Tolbert and Setty are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert and Setty before him or her, to modify the system of Qadri, and Tolbert, to include the teachings of Setty, as a cloud infrastructure system, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to synchronize backup of cloud infrastructure components, as suggested by Setty (column 10, lines 19-24, column 17, lines 4-11).
In regards to claim 2, Qadri and Tolbert, in particular Qadri doesn't explicitly teach:
the publication service system is outside the customer tenancy.
However, Setty teaches such use: (Fig. 6B, see Infrastructure Manager System 212, Network 206, TOR Switch Device 204, Infrastructure Devices 202), (Fig. 1, Input device 106, Display 110), (column 5, lines 28-31, see In an embodiment, the infrastructure manager system 212 may be provided by the IHS 100 discussed above with reference to FIG. 1) and (column 10, lines 19-24, see during the building of the cloud infrastructure system provided by the infrastructure devices 202, the user (e.g., a deployment engineer) may verify the components identified in the template by the cloud infrastructure system vendors/providers).
the receiving is enabled due to a policy associated with the customer tenancy that allows information related to the stack to be accessed by the publication service system from the customer tenancy
However, Setty teaches such use: (column 5, lines 17-24, see in the illustrated embodiment, a policy storage system (not illustrated, but which may include the storage 108 discussed above with reference to FIG. 1) may be coupled to the network 206 and may include a group policy repository database 208 (e.g., an Active Directory) that may store any permission-related and/or authentication-related information that defines which users are authorized to utilize the infrastructure backup system 200).
Qadri, Tolbert and Setty are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert and Setty before him or her, to modify the system of Qadri, and Tolbert, to include the teachings of Setty, as a cloud infrastructure system, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to synchronize backup of cloud infrastructure components, as suggested by Setty (column 10, lines 19-24, column 17, lines 4-11).
In regards to claim 3, Qadri teaches:
receiving, in the cloud computing environment, one or more policies allowing access of the customer tenancy by the publication service system, wherein the policies allowing access of the customer tenancy by the publication service system allows the publication service system to read at least one of: tenant in the customer tenancy; compartments in the customer tenancy; stacks in the customer tenancy; or jobs in the customer tenancy (Abstract, the candidate may be on the premises of an enterprise, or instead be a hosted cloud on the premises of a hoster off the premises of the entity that pays for the hosting) and (p. 13, [0318], see upon starting the on-premises agent, the user is prompted to provide its credentials, which include the tenant identifier. The on-premises agent authenticates 502 the user with a token issuing authority and receives an authentication token. The agent then sends an outgoing request to the SAS service asking for access to a specific storage resource (and optionally a specific range).
In regards to claim 6, Qadri teaches:
testing the stack in the customer tenancy by performing a plurality of jobs; and storing job information in the customer tenancy and associated with the stack (p. 17, [0366], see when a user selects Test(s) for execution, some entity will create a Task in the Task store to execute. Test Scheduler service 1102 will scan the task table and schedule tasks to be processed by sending message to the task queue 1010. Worker role 1104 will pick the request and process it by using the task execution engine. After the processing is complete the engine will update the test state in a database 1106) and (Abstract, see a cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud).
In regards to claim 7, Qadri teaches:
the plurality of jobs comprise at least one of: PLAN; APPLY; or DESTROY (p. 3, [0037], see for task processing, the service will simply create a task. Test controller will then queue the task to the worker. Test Management Service will be used for adding, removing, or updating test related content in this VaaS ecosystem) and (p. 13, [0314], see a web application or client drops tasks in the queue to execute, using a storage access token service. The storage access token service issues tokens for specific storage partitions).
In regards to claim 13, Qadri teaches:
it is determined that the stack is valid when the latest one or more jobs with operation APPLY or DESTROY have a lifecycle-state of succeeded (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter), (p. 13, [0314], see a web application or client drops tasks in the queue to execute, using a storage access token service), (p. 10, [0281], see candidate cloud operators 304 also use VaaS to validate new cloud 350 services offered to customers, to make certain the services work as expected when deployed on the integrated solution) and (p. 11, [0294] see receiving 414 at least one certification test result which was generated by execution of one or more certification test executable portions, and providing 416 one or more certification test results for use in making a determination 418 whether to validate the candidate cloud).
In regards to claim 18, Qadri teaches:
A system comprising: a memory comprising stored instructions; and a processor configured to execute the stored instructions to: (Abstract, see described technologies facilitate cloud validation using validation as a service (VaaS). A cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud).
determine validation status of the stack based on the retrieved job information (Fig. 4, Monitor 42 test executions, receive 414 test results, Provide 416 test results, Determine 418 validation status 420).
designating the stack as a valid stack when it is determined that the validation status indicates the stack is valid (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter), (p. 11, [0294] see receiving 414 at least one certification test result which was generated by execution of one or more certification test executable portions, and providing 416 one or more certification test results for use in making a determination 418 whether to validate the candidate cloud) and (p. 12, [0311], see Some examples include validating and certifying a private cloud by executing tests, gatherer jobs such as collecting inventory of the solution, and executing a job such as a service health validator).
Qadri doesn't explicitly teach:
retrieve with, the publication service system job information from the customer tenancy relevant to the stack.
However, Tolbert teaches such use: (Abstract, see s cloud computing system has an external application program interface (API) allowing a user to access the cloud computing system and sending a job to at least one application. At least one application supervisor is provided, wherein each application supervisor monitors a specific application and deploys at least one cloud worker to the job. A database stores status information of the at least one cloud worker, job details and other telemetry data. An internal API is coupled to the database. A state machine receives the status information of the at least one cloud worker, job details and other telemetry data via the internal API. The state machine determines when servers need to be deleted, servers need to be created, when the at least one cloud worker needs to be deleted or additional cloud workers created).
Qadri and Tolbert are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri and Tolbert before him or her, to modify the system of Qadri to include the teachings of Tolbert, as a system for application cloud management, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation services, because that would provide Qadri with the ability to quickly react to load conditions, as suggested by Tolbert (Abstract, P. 4, [0035]).
Qadri and Tolbert, in particular Qadri doesn't explicitly teach:
receive, from a customer tenancy in a cloud computing environment and at a publication service system identification of a stack to be validated; the stack having an associated stack identifier.
However, Setty teaches such use: (column 5, lines 17-24, see during the building of the cloud infrastructure system provided by the infrastructure devices 202, the user (e.g., a deployment engineer) may verify the components identified in the template by the cloud infrastructure system vendors/providers...the component dependency information may provide any details about the hardware and software components in the cloud infrastructure system and their dependencies on each other).
Qadri, Tolbert and Setty are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert and Setty before him or her, to modify the system of Qadri, and Tolbert, to include the teachings of Setty, as a cloud infrastructure system, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to synchronize backup of cloud infrastructure components, as suggested by Setty (column 10, lines 19-24, column 17, lines 4-11).
In regards to claim 20, Qadri teaches:
A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to: (Abstract, see described technologies facilitate cloud validation using validation as a service (VaaS). A cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud).
determine validation status of the stack based on the retrieved job information (Fig. 4, Monitor 42 test executions, receive 414 test results, Provide 416 test results, Determine 418 validation status 420).
designating the stack as a valid stack when it is determined that the validation status indicates the stack is valid (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter), (p. 11, [0294] see receiving 414 at least one certification test result which was generated by execution of one or more certification test executable portions, and providing 416 one or more certification test results for use in making a determination 418 whether to validate the candidate cloud) and (p. 12, [0311], see Some examples include validating and certifying a private cloud by executing tests, gatherer jobs such as collecting inventory of the solution, and executing a job such as a service health validator).
Qadri doesn't explicitly teach:
retrieve with, the publication service system job information from the customer tenancy relevant to the stack.
However, Tolbert teaches such use: (Abstract, see s cloud computing system has an external application program interface (API) allowing a user to access the cloud computing system and sending a job to at least one application. At least one application supervisor is provided, wherein each application supervisor monitors a specific application and deploys at least one cloud worker to the job. A database stores status information of the at least one cloud worker, job details and other telemetry data. An internal API is coupled to the database. A state machine receives the status information of the at least one cloud worker, job details and other telemetry data via the internal API. The state machine determines when servers need to be deleted, servers need to be created, when the at least one cloud worker needs to be deleted or additional cloud workers created).
Qadri and Tolbert are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri and Tolbert before him or her, to modify the system of Qadri to include the teachings of Tolbert, as a system for application cloud management, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation services, because that would provide Qadri with the ability to quickly react to load conditions, as suggested by Tolbert (Abstract, P. 4, [0035]).
Qadri and Tolbert, in particular Qadri doesn't explicitly teach:
receive, from a customer tenancy in a cloud computing environment and at a publication service system identification of a stack to be validated; the stack having an associated stack identifier.
However, Setty teaches such use: (column 5, lines 17-24, see during the building of the cloud infrastructure system provided by the infrastructure devices 202, the user (e.g., a deployment engineer) may verify the components identified in the template by the cloud infrastructure system vendors/providers...the component dependency information may provide any details about the hardware and software components in the cloud infrastructure system and their dependencies on each other).
Qadri, Tolbert and Setty are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert and Setty before him or her, to modify the system of Qadri, and Tolbert, to include the teachings of Setty, as a cloud infrastructure system, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to synchronize backup of cloud infrastructure components, as suggested by Setty (column 10, lines 19-24, column 17, lines 4-11).
9. Claims 5, 8-12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Tolbert in view of Setty in view of Chauhan et al., US 20190068445 (hereinafter Chauhan).
In regards to claims 1, 2, 4 and 18, the rejections above are incorporated accordingly.
In regards to claim 5, Qadri, Tolbert and Setty doesn't explicitly teach:
the stack is received in the customer tenancy by uploading the stack to the customer tenancy.
However, Chauhan teaches such use: (p. 11, [0072], see if cloud stack server 130 determines that the identified cloud stack configuration is optimized, then it constructs the cloud stack configuration for user device 120 at step 370. Once the cloud stack configuration is implemented at user device 120, it may continue to be analyzed and monitored (e.g., at steps 380 and 390 described below) to ensure that the cloud stack configuration continues to be the optimal configuration for the needs of the user as requested in the cloud stack request).
Qadri, Tolbert, Setty and Chauhan are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Chauhan before him or her, to modify the system of Qadri, Tolbert and Setty, to include the teachings of Chauhan, as a system for dynamic cloud stack configuration, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to remove limitations associated with stack configuration, as suggested by Chauhan (p. 6, [0004], p. 11, [0074]).
In regards to claim 8, Qadri, Tolbert and Setty doesn't explicitly teach:
receiving identification of the stack comprises receiving an artifact.
However, Chauhan teaches such use: (Abstract, see the interface receives a cloud stack request from a user device, which includes functionality parameters. The memory stores historic cloud stack configurations and each is associated with functionality parameters. The cloud stack configuration engine identifies cloud components associated with the functionality parameters) and (p. 5, [0037], see the functionality parameters may include, but are not limited to, a hardware preference, an operating system preference, a preference for open source, a performance requirement, an intended application preference for high availability, the domain to which the business or enterprise belongs, and/or any other feature relating to the operation of cloud stack that the user is requesting cloud stack server 130 to create).
Qadri, Tolbert, Setty and Chauhan are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Chauhan before him or her, to modify the system of Qadri, Tolbert and Setty, to include the teachings of Chauhan, as a system for dynamic cloud stack configuration, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to remove limitations associated with stack configuration, as suggested by Chauhan (p. 6, [0004], p. 11, [0074]).
In regards to claim 9, Qadri, Tolbert and Setty doesn't explicitly teach: :
retrieving job information from the customer tenancy relevant to the stack comprises accessing with the publication service system the customer tenancy.
However, Chauhan teaches such use: (p. 3, [0023], see as another example, an enterprise may need to set up a cloud stack for its customers or users to access files or applications (e.g., cloud-based storage, accounts of users). System 100 may receive the cloud stack request from a user, determine cloud components that meet the cloud stack request and configure the cloud stack).
Qadri, Tolbert, Setty and Chauhan are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Chauhan before him or her, to modify the system of Qadri, Tolbert and Setty, to include the teachings of Chauhan, as a system for dynamic cloud stack configuration, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to remove limitations associated with stack configuration, as suggested by Chauhan (p. 6, [0004], p. 11, [0074]).
In regards to claim 10, Qadri, Tolbert and Setty doesn't explicitly teach:
retrieving the job information from the customer tenancy relevant to the stack comprises querying the customer tenancy for a list of jobs associated with the stack.
However, Chauhan teaches such use: (p. 6, [0040], see cloud stack configuration engine 135 may further use these determined or input functionality parameters to choose among various cloud components 112 that best suit a user's needs. In some embodiments, cloud components 112 may have a list of features or functionality parameters associated with each of them. cloud stack configuration engine 135 may compare the features associated with a component (e.g., hypervisor 112-3) with the functionality parameters from the user and determine a sufficient match such that it may identify hypervisor 112-3 as a selection for the cloud stack).
Qadri, Tolbert, Setty and Chauhan are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Chauhan before him or her, to modify the system of Qadri, Tolbert and Setty, to include the teachings of Chauhan, as a system for dynamic cloud stack configuration, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to remove limitations associated with stack configuration, as suggested by Chauhan (p. 6, [0004], p. 11, [0074]).
In regards to claim 11, Qadri teaches:
at least some of the jobs associated with the stack correspond to validation tests and include at least one of: APPLY; or DESTROY (p. 3, [0037], see for task processing, the service will simply create a task. Test controller will then queue the task to the worker. Test Management Service will be used for adding, removing, or updating test related content in this VaaS ecosystem) and (p. 13, [0314], see a web application or client drops tasks in the queue to execute, using a storage access token service. The storage access token service issues tokens for specific storage partitions).
In regards to claim 12, Qadri teaches:
determining the validation status of the stack based on the retrieved job information comprises: identifying the latest one or more jobs with operation APPLY or DESTROY (p. 3, [0037], see for task processing, the service will simply create a task. Test controller will then queue the task to the worker. Test Management Service will be used for adding, removing, or updating test related content in this VaaS ecosystem) and (p. 13, [0314], see a web application or client drops tasks in the queue to execute, using a storage access token service. The storage access token service issues tokens for specific storage partitions).
determining a lifecycle-state of the latest one or 3 more jobs with operation APPLY or DESTROY (p. 18, [0388], see backend service provides an abstraction level for workers that perform any long running work, e.g., pulling work item, persisting, updating status, deferring, etc. This service uses queues to pull work items which include metadata and the type of the worker to process it. The service dynamically loads the target worker, provides it with the work item and manages its entire lifecycle).
In regards to claim 19, Qadri teaches:
receive in the cloud computing environment policies allowing access of the customer tenancy by the publication service system (p. 13, [0318], see upon starting the on-premises agent, the user is prompted to provide its credentials, which include the tenant identifier. The on-premises agent authenticates 502 the user with a token issuing authority and receives an authentication token. The agent then sends an outgoing request to the SAS service asking for access to a specific storage resource (and optionally a specific range)).
test the stack in the customer tenancy by performing a plurality of jobs; and store job information in the customer tenancy and associated with the stack (p. 17, [0366], see when a user selects Test(s) for execution, some entity will create a Task in the Task store to execute. Test Scheduler service 1102 will scan the task table and schedule tasks to be processed by sending message to the task queue 1010. Worker role 1104 will pick the request and process it by using the task execution engine. After the processing is complete the engine will update the test state in a database 1106) and (Abstract, see a cloud validation service provider acquires and securely stores certification tests developed by cloud component providers, integrated solution providers, and others. Each test's executable portion tests hardware or software of a candidate cloud).
Qadri, Tolbert and Setty doesn't explicitly teach:
receive the stack in the customer tenancy.
However, Chauhan teaches such use: (p. 11, [0072], see if cloud stack server 130 determines that the identified cloud stack configuration is optimized, then it constructs the cloud stack configuration for user device 120 at step 370. Once the cloud stack configuration is implemented at user device 120, it may continue to be analyzed and monitored (e.g., at steps 380 and 390 described below) to ensure that the cloud stack configuration continues to be the optimal configuration for the needs of the user as requested in the cloud stack request).
Qadri, Tolbert, Setty and Chauhan are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Chauhan before him or her, to modify the system of Qadri, Tolbert and Setty, to include the teachings of Chauhan, as a system for dynamic cloud stack configuration, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to remove limitations associated with stack configuration, as suggested by Chauhan (p. 6, [0004], p. 11, [0074]).
10. Claims 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Tolbert in view of Setty in view of Berger et al., US 2017/0300309 (hereinafter Berger).
In regards to claims 1 and 13, the rejections above are incorporated accordingly.
In regards to claim 14, Qadri teaches:
downloading the stack to the publication service system (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter).
Qadri, Tolbert and Setty, in particular Qadri doesn't explicitly teach:
scanning the stack for viruses.
However, Berger teaches such use: (Abstract, see a computer implemented method may include: receiving a guest application for deployment on a cloud environment; receiving the integrity constraints on the integrity of each of the plurality of host where the application is to be deployed), (p. 2, [0030], see in some implementations, an organization is enabled to certify to its customers that customer workloads are being executed in a “trusted” environment that respects geographic constraints on the customer's data and computation) and (p. 1, [0018], see the present techniques enable an application (standalone or distributed) to be deployed in a public, private, or hybrid datacenter/cloud environment in a trustworthy manner. Often, ‘trustworthy’ implies that the software stack on which the application executes and the application components are checked for integrity, i.e., checked whether they have not been maliciously modified in the deployment process and that no malicious code (like malware, spyware) is introduced between the application developer and the infrastructure (public/private/ hybrid) cloud that executes the application).
Qadri, Tolbert, Setty and Berger are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Berger before him or her, to modify the system of Qadri, Tolbert and Setty, in particular Qadri, to include the teachings of Berger, as a system for application cloud deployment, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation services, because that would provide Qadri with the ability to make it feasible to check for malware on cloud stacks, as suggested by Berger (p. 2, [0030], p. 8, [0088]).
In regards to claim 15, Qadri, Tolbert and Setty, in particular Qadri doesn't explicitly teach:
receiving a request from the customer tenancy to publish the stack.
However, Berger teaches such use: (Abstract, see a computer implemented method may include: receiving a guest application for deployment on a cloud environment; receiving the integrity constraints on the integrity of each of the plurality of host where the application is to be deployed), (p. 2, [0030], see in some implementations, an organization is enabled to certify to its customers that customer workloads are being executed in a “trusted” environment that respects geographic constraints on the customer's data and computation) and (p. 1, [0018], see the present techniques enable an application (standalone or distributed) to be deployed in a public, private, or hybrid datacenter/cloud environment in a trustworthy manner. Often, ‘trustworthy’ implies that the software stack on which the application executes and the application components are checked for integrity, i.e., checked whether they have not been maliciously modified in the deployment process and that no malicious code (like malware, spyware) is introduced between the application developer and the infrastructure (public/private/hybrid) cloud that executes the application).
Qadri, Tolbert, Setty and Berger are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Berger before him or her, to modify the system of Qadri, Tolbert and Setty, in particular Qadri, to include the teachings of Berger, as a system for application cloud deployment, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation services, because that would provide Qadri with the ability to make it feasible to check for malware on cloud stacks, as suggested by Berger (p. 2, [0030], p. 8, [0088]).
In regards to claim 16, Qadri teaches:
publishing the stack (p. 15, [0326], see the Solution, after meeting all the validation criteria, can then be published to the Azure Stack Solution Catalog ensuring customers that the system will run efficiently and stably in their datacenter).
11. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Tolbert in view of Setty in view of Peng et al., CN 107343018 hereinafter Peng) in view of Liljeback et al., US Patent No. 11,544,052 (hereinafter Liljeback).
In regards to claim 1, the rejections above are incorporated respectively.
In regards to claim 17, Qadri, Tolbert and Setty, in particular Qadri doesn't explicitly teach:
the stack comprises a terraform stack.
However, Peng teaches such use: (p. 6, 7th para., see the beneficial effect of the invention is: a PaaS cloud platform application service arranging method and system, through one simple configuration file to define the distributed application stack and dependence, by the PaaS platform in the automatic, driving of the intelligent, final layout out such as content acquisition, processing and producing content unified management and other media application, enables the user to quickly copy a complete set of environment and realize service, application, service and resource structure across the area of multiplexing).
Qadri, Tolbert, Setty and Peng are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Peng before him or her, to modify the system of Qadri, Tolbert and Setty, in particular Qadri, to include the teachings of Peng, as a system for a cloud platform application service, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to quickly copy a complete set of environment, as suggested by Peng (p. 6, 7th para., p. 5, 14th para.).
Qadri, Tolbert, Setty and Peng, in particular Qadri doesn't explicitly teach:
the stack represents definitions of a group of resources that can be acted on as a group.
However, Liljeback teaches such use: (column 9, lines 51-66, see the deployment groups 330 may include various logical single-tenant system stacks 325 associated with the nodes 320. For example, a deployment group 330-a may include logical single-tenant system stacks 325-a associated with a node 320-a, logical single-tenant system stacks 325-b associated with a node 320-b, logical single-tenant system stacks 325-c associated with a node 320-c, logical single-tenant system stacks 325-c associated with a node 320-c, and logical single-tenant system stacks 325-d associated with a node 320-d. Likewise, a deployment group 330-b may include logical single-tenant system stacks 325-e associated with a node 320-e, logical single-tenant system stacks 325-f associated with a node 320-f, logical single-tenant system stacks 325-g associated with a node 320-g, and logical single-tenant system stacks 325-h associated with a node 320-h).
Qadri, Tolbert, Setty, Peng and Liljeback are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty, Peng and Liljeback before him or her, to modify the system of Qadri, Tolbert, Setty and Peng, in particular Qadri to include the teachings of Liljeback, as a system for declarative tenant deployments, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to provide improved data privacy and security, as suggested by Liljeback (column 9, lines 51-66, column 33, lines 16-24).
12. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Tolbert in view of Setty in view of Geer, US Patent No. 10,595,204 (hereinafter Geer).
In regards to claim 1, the rejections above are incorporated respectively.
In regards to claim 4, Qadri, Tolbert and Setty, in particular Qadri doesn't explicitly teach:
before receiving the identification of the stack to be validated from the customer tenancy, receiving [[a]] the stack in the customer tenancy.
However, Geer teaches such use: (column 6, lines 55-67, see the target server 210 may transmit information about its server configuration to the testing server 205 over a communication link 215. In some cases, the target server 210 may transmit the information based on receiving a validation request from the testing server 205. In other cases, the target server 210 may automatically transmit the information following server deployment, server modification, or based on a pre-determined periodicity. The information may include parameters corresponding to the target server 210, such as server, stack, environment, or service information. For example, the parameters may include a stack identifier, a server type identifier, an application type identifier, or some combination of these or similar parameters related to the target server 210 configuration) (emphasis added).
Qadri, Tolbert, Setty and Geer are analogous art because they are from the same field of endeavor, application deployment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Qadri, Tolbert, Setty and Geer before him or her, to modify the system of Qadri, Tolbert and Setty, in particular Qadri, to include the teachings of Geer, as a system for remote server validation, and accordingly it would enhance the system of Qadri, which is focused on a cloud validation service, because that would provide Qadri with the ability to efficiently validate cloud servers, as suggested by Geer (column 6, lines 55-67, column 21, lines 32-38).
Conclusion
13. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publications
Kumar 20190068445 teaches A dynamic cloud stack configuration system includes a cloud network, which comprises cloud components. A cloud stack server is coupled to the cloud network. The cloud stack server includes an interface, a memory, and a cloud stack configuration engine implemented by a processor. The interface receives a cloud stack request from a user device, which includes functionality parameters. The memory stores historic cloud stack configurations and each is associated with functionality parameters. The cloud stack configuration engine identifies cloud components associated with the functionality parameters. The cloud stack configuration engine further determines a cloud stack configuration, and determines whether the cloud stack configuration is an optimal cloud stack.
Shirgaonkar 20100083278 teaches The present invention provides a method, system and computer program product for automatically generating message queue scripts for defining one or more Websphere® Message Queue™ (WMQ) objects on one or more queue managers. A user provides parameters corresponding to the WMQ objects as input in an input parameter file. The parameters include the name of the WMQ objects and the queue managers. Further, a message queue environment consistency check is performed on the input parameter file for validating the parameters provided. The validation is performed by using a database that stores information about the message queue environment.
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Evral Bodden whose telephone number is 571-272-3455. The examiner can normally be reached on Monday to Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automatedinterview-request-air-form.
If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EVRAL E BODDEN/Primary Examiner, Art Unit 2193
Prosecution Insights