DETAILED ACTION
This office action is in response the amendment filed December 8, 2025.
Claims 1-20 are pending.
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, see Remarks, December 8, 2025 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
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,2,4,5,7, 8, 9, 11,12,14,15,16,18,and 19 s/are rejected under 35 U.S.C. 103 as being unpatentable over “Shah” (US PG Pub 2023/0244466) in view of “Zettel” (US PG Pub 2023/0019705) and further in view of “Tahiri” (US PG Pub 2021/0405988)
Regarding Claim 1, Shah teaches:
A computer-implemented method comprising: receiving, at a computing device, a package comprising environmental metadata, at least one data module, and deployment workflows comprising tasks; (Fig. 1, 150 receiving packages 112-115 in Shah teaches a system receiving deployment packages including a deployment workflow including operations for deployment( ¶¶12,47) environmental metadata including e.g. configuration data 114, Fig 1, ¶24 images and automation data for deployment of modules as in ¶¶21, 35 for the cloud account in the server environments including e.g. deploying a database engine as in ¶47; see further processor and memories for execution of the deployment system in e.g. ¶¶56-59).
and deploying the package on a server instance of a cloud computing server system to configure a working environment (See Shah generally Figs. 1-4 and associated text for deployment workflow package based deployment of server system applications in the cloud and further detailed below) by: configuring the working environment with the environmental metadata based on one or more of the tasks of the deployment workflows, (¶¶47-49 describes configuring the environment for software deployment based on the deployment workflow including using the configuration data)
deploying the at least one data module to add data to a database of the server instance based on one or more of the tasks of the deployment workflows. (¶47 of Shah describes deploying a database engine for use in the working environment including the ability to add/remove data as described in ¶42).
Shah does not teach, but Zettel teaches:
comprising at least one database file (Zettel e.g. ¶¶123,136 teaches use of various database file formats including “XML, JSON, YAML, a flat file, or CSV” (¶136) for storing database data for importing/exporting to data modules)
from the database file (Zettel e.g. ¶¶123,136 teaches use of various database file formats including “XML, JSON, YAML, a flat file, or CSV” (¶136) for storing database data for importing/exporting to data modules)
by generating at least a portion of the data based on data shape descriptors in the data module. (¶123 “The configuration file may be a text file with content formatted in accordance with XML, JAVASCRIPT® Object Notation (JSON), Yet Another Markup Language (YAML), a flat file, comma-separated values (CSV), or some other layout.” ¶136 “These scripts may export the snapshot data into various forms, such as XML, JSON, YAML, a flat file, or CSV. Configuration data in such formats may be directly usable by source code repositories or build tools, or can be processed so that they are usable by these entities. The format of the exported data may match the requirements of the target system to which the exported data will be provided.” See e.g. ¶147 Fig. 8, ¶¶178,183-186 described providing configuration data formats for representating package related data to be imported/exported)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Shah and Zettel as each is directed to cloud deployment systems, and Zettel recognized “s networks deploy larger numbers of services, and these services become more complex, configuration data management becomes increasingly important.”(¶1).
Shah does not teach but teaches:
wherein the portion of the data generated based on the data shape descriptors is not correlated outside of itself. (Tahiri e.g. ¶¶13, 22 teaches generation of random (i.e. not correlated) data for use in cloud deployment for testing purposes). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Shah and Tahiri as each is directed to cloud deployment system and Tahiri recognized “There is therefore a need for a solution to enable a rapid, automatic and adaptative deployment of an entire cloud environment that is secure, that adapts to different hardware architecture, network architectures, cloud services, technologies and user needs, and that is easy to use.” (¶8).
Regarding Claim 2, Shah teaches:
2. The computer-implemented method of claim 1, further comprising storing the package. (Shah ¶21 teaches storing package 112 in the cloud account and computing platform 120).
Regarding Claim 4, Shah teaches:
4. The computer-implemented method of claim 1, further comprising determining, during deployment of the package on the server instance, at least one configuration setting of the server instance; (Shah ¶30 teaches configuring the deployment package as a server environment based on the configuration data, as in e.g. ¶49)
and adjusting the deployment of the package based on the at least one configuration setting of the target environment. (Shah e.g. ¶30 and ¶44 teach customizing the target cloud computing environment deployment based on the specific cloud computing platform)
Regarding Claim 5, Shah teaches:
5. The computer-implemented method of claim 1, wherein the package further comprises at least one script, and further comprising running the at least one script on the server instance based on one or more additional tasks of the deployment workflows. (Shah ¶¶12,26,35 – teaches running a script for deployment of the server instance as part of the deployment workflow package).
Regarding Claim 7, Shah teaches:
7. The computer-implemented method of claim 1, further comprising performing one or more automated tests after configuring the working environment with the environmental metadata based on one or more of the tasks of the deployment workflows.(¶¶23-25 teaches automated unit and other tests performed on the deployed server environments configurated with the configuration data 114 based on workflow as in ¶¶12,47).
Claims 8, 9, 11,12,14 are rejected on the same basis as claims 1,2,4,5,and 7 respectively above.
Claims 15,16,18,and 19 are rejected on the same basis as claims 1,2,4, and 5 respectively above.
Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Shah” (US PG Pub 2023/0244466) in view of “Zettel” (US PG Pub 2023/0019705). and “Tahiri” (US PG Pub 2021/0405988) as applied above and further in view of “Costa” (US PG Pub 2024/0015163).
1,2,4,5,7, 8, 9, 11,12,14,15,16,18,and 19
Regarding Claim 3, Shah teaches the limitations of claim 1 above, but does not further teach, while Costa teaches: 3. The computer-implemented method of claim 1, wherein the package includes a second package, and further comprising, before installing the package on the server instance: determining, based on a dependency tree, an order of deployment for the package and the second package on the server instance;
(Costa ¶¶54-56, 204-206 Fig. 2 teaches representing settings of a deployment in a tree form including representing dependencies in the tree and using those dependencies to derive a deployment plan for software packages)
and deploying the package and the second package on the server instance based on the determined order of installation. (Costa ¶¶54-56, 204-206 Fig. 2 teaches representing settings of a deployment in a tree form including representing dependencies in the tree and using those dependencies to derive a deployment plan for software packages)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Shah and Costa as each is directed to cloud deployment systems, both recognized the need to ensure needed dependencies in deployment (see Shah e.g. ¶¶11,24,49) and Costa recognized the need for a system that deploys assets in a deployment plan as a “chained sequence according to their dependencies” (206 Fig. 2).
Claims 10 and 17 are rejected on the same basis as claim 3 above.
Claim(s) 6, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Shah” (US PG Pub 2023/0244466) in view of “Zettel” (US PG Pub 2023/0019705) and “Tahiri” (US PG Pub 2021/0405988) as applied above and further in view of “Owen” (US PG Pub 2020/0057619).
Regarding Claim 6, Shah teaches the limitations of claim 1 above, but does not further teach, while Owen teaches: 6. The computer-implemented method of claim 1, further comprising performing one or more pre-deployment checks on the working environment before configuring the working environment with the environmental metadata based on one or more of the tasks of the deployment workflows. (Owen ¶¶20,81 teaches an approval process carried out before deployment in a deployment workflow for deploying a release package).
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Shah and Owen as each is directed to deployment systems and Owen recognized “It may also be desirable to obtain approvals before deploying software in a production environment.” (¶20).
Claims 13 and 20 are rejected on the same basis as claim 3 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The attached PTO-892 includes additional prior art relevant to applicant’s disclosure related to cloud package deployment workflow systems.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 MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached on 571-272-3708. 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.
MJB
1/22/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191