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 .
Claims 1-20 have been examined.
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 1-20 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.
Claim 1 recites the limitation "the source code" in line 4. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “source code”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation “a mainframe application” on line 4 of the claim, which renders the claim indefinite because it is unclear whether the mainframe application refers to the mainframe applications on line 1 of the claim or to another. Appropriate correction is required.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation "the specific needs" in line 18. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “specific needs”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation “a build process” on line 19, which renders the claim indefinite because it is unclear whether the build process refers to the build process on line 12 or to another. Appropriate correction is required.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation "the transfer process" in lines 24-25. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “transfer process”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation "the integrity" in line 25. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “integrity”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation "the versioned artifacts" in line 41. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “versioned artifacts”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation "the post-deployment process" in line 43. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “post-deployment process”.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 1 recites the limitation “integrity of artifacts” on line 54, which renders the claim indefinite because it is unclear whether the integrity of the artifacts refer to the integrity of the artifacts on line 25 or to another. Appropriate correction is required.
Claims 2-18 are rejected for dependency upon rejected base claim 1 above.
Claim 19 recites the limitation "the source code" in line 6. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “source code”.
Claim 19 recites the limitation “a mainframe application” on line 6 of the claim, which renders the claim indefinite because it is unclear whether the mainframe application refers to the mainframe applications on lines 1-2 of the claim or to another. Appropriate correction is required.
Claim 19 recites the limitation "the integrity" in line 13. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “integrity”.
Claim 19 recites the limitation “a build process” on line 24, which renders the claim indefinite because it is unclear whether the build process refers to the build process on line 9 or to another. Appropriate correction is required.
Claim 19 recites the limitation "the transfer process" in lines 30-31. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “transfer process”.
Claim 19 recites the limitation "the deployment" in line 44. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 19 recites the limitation "the post-deployment process" in line 49. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 19 recites the limitation "the results" in line 51. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 19 recites the limitation "the overall time" in line 67. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 19 recites the limitation “artifacts” on line 72, which renders the claim indefinite because it is unclear whether the artifacts refer to the artifacts on line 25 or to another. Appropriate correction is required.
Claim 19 recites the limitation "the ability" in line 74. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 19 recites the limitation "the security and the integrity" in line 75. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 20 recites the limitation "the source code" in line 5. There is insufficient antecedent basis for this limitation in the claim. Therefore, this limitation is interpreted as “source code”.
Claim 20 recites the limitation “a mainframe application” on line 5 of the claim, which renders the claim indefinite because it is unclear whether the mainframe application refers to the mainframe applications on lines 1-2 of the claim or to another. Appropriate correction is required.
Claim 20 recites the limitation “a build process” on line 24 of the claim, which renders the claim indefinite because it is unclear whether the build process refers to the build process on lines 7-8 or to another. Appropriate correction is required.
Claim 20 recites the limitation "the results" in line 59. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 20 recites the limitation "the integrity" in line 77. There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
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.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 20 appears to be a system of software alone, lacking the necessary physical components (hardware) to constitute a machine or a manufacture under 101. Since claim 20 is clearly not a process or a composition of matter, it appears to fail to fall within a statutory category and thus non-statutory.
Allowable Subject Matter
Claims 1-19 are rejected under 35 USC 112, but would be allowable if the 35 USC 112 rejection is overcome.
Claim 20 is rejected under 35 USC 112 and 35 USC 101, but would be allowable if the 35 USC 112 and 35 USC 101 rejections are overcome.
The following is a statement of reasons for the indication of allowable subject matter:
The cited prior art taken alone or in combination fail to teach, in combination with the other claimed limitations, generating, by said BEARDS, Job Control Language (JCL) scripts tailored to specific requirements of a mainframe environment, wherein the generation process involves dynamically adjusting compiler options, memory allocation, and execution parameters based on current configuration and the specific needs of the build; initiating, by said BEARDS, a build process within the mainframe environment using the generated JCL scripts to compile the source code into executable artifacts, including preprocessing steps for files not natively supported by the mainframe to ensure compatibility; performing, by said BEARDS, a validation of downloaded artifacts from the mainframe using a SHA-256 hash algorithm to generate hash values before and after the transfer process, thereby ensuring the integrity of the artifacts and verifying that they have not been altered during the transfer process; generating, by said BEARDS, YML files containing detailed deployment instructions specific to the mainframe environment, including configurations, dataset assignments, pre-deployment checks, and environment-specific parameters necessary to ensure a successful deployment; transferring, by the CI/CD process, the validated compiled artifacts to an artifact repository for secure storage and version control, wherein the transfer process includes generating a new SHA-256 hash to ensure the integrity of the artifacts during and after the transfer; deploying, by XLRelease and Ansible, the validated and versioned compiled artifacts from the artifact repository to the mainframe environment, utilizing the generated YML files to execute the deployment process while ensuring that all configurations and dataset assignments are correctly applied; validating, by said Ansible, the deployment process through automated functional and non-functional tests, including SHA-256 hash-based validation to confirm that deployed artifacts match the versioned artifacts in the repository, and updating status logs to reflect success or failure of the deployment; managing, by said XLRelease and said Ansible, the post-deployment process, including generating automated notifications to stakeholders, updating deployment status logs, and creating detailed reports that document each step of the deployment process and its outcomes; securing, by XLRelease and Ansible, the deployment process by implementing role-based access controls to restrict who can initiate, monitor, or modify deployments, and logging all actions taken during the deployment in an immutable audit trail for compliance and security verification; and scaling, by XLRelease and Ansible, the deployment process across multiple environments including development (DEV), quality assurance (QA), and production (PROD), where the scaling process involves handling parallel build and deployment tasks, ensuring consistency and integrity of artifacts across all environments, and managing large-scale deployments by retaining significant artifacts within the mainframe environment to minimize transfer overhead and enhance deployment efficiency as recited in independent claim 1; further fail to teach generating, by BEARDS, Job Control Language (JCL) jobs customized to specific requirements of the mainframe environment, where the generation process involves dynamically adjusting compiler options, memory allocations, and execution parameters based on a real-time analysis of the mainframe's resource availability, current system load, and configuration settings; initiating, by BEARDS, a build process within the mainframe environment using the generated JCL jobs to compile the source code into executable artifacts, where the build process includes preprocessing steps for files not natively supported by the mainframe to ensure compatibility, as well as integrating additional build steps tailored to optimize performance, resource usage, and error handling;5 performing, by BEARDS, a rigorous validation of downloaded artifacts using a SHA-256 hash algorithm, where hash values are generated both before and after the transfer process from the mainframe into a directory for the CI/CD process to ensure the integrity of the artifacts and verify that they have not been altered during the transfer; generating, by BEARDS, detailed YML files containing comprehensive deployment instructions specific to the mainframe environment, where the YML files include configurations, dataset assignments, pre-deployment validation checks, environment-specific parameters, and rollback procedures that are necessary to ensure a successful and optimized deployment process; securely transferring, by the CI/CD process, the validated compiled artifacts to an artifact repository that is version-controlled, such as JFrog Artifactory, where the transfer process includes generating a new SHA-256 hash post-transfer to ensure the integrity of the artifacts during storage, managing multiple versions of the artifacts, and associating each version with its respective hash value for easy retrieval, validation, and deployment; executing, by XLRelease and Ansible, the deployment of the validated and versioned compiled artifacts from the artifact repository to the mainframe environment, utilizing the generated YML files to ensure that the deployment is carried out consistently, efficiently, and securely across multiple environments, including development (DEV), quality assurance (QA), and production (PROD);managing, by XLRelease and Ansible, the post-deployment process, including automatically generating and distributing detailed deployment reports to stakeholders, which include the results of the SHA-256 hash validation, performance metrics, and any issues encountered during deployment, as well as updating deployment status logs, providing real-time feedback on deployment progress, and archiving the reports for future reference and compliance purposes; securing, by XLRelease and Ansible, the entire deployment process through encrypted communication channels, role-based access controls, and immutable audit trails, where all deployment actions are logged, digitally signed, timestamped, and stored in 6 a tamper-proof environment to ensure compliance with security policies and regulatory requirements; scaling, by XLRlease and Ansible, the deployment process across multiple environments by optimizing task parallelization, managing resource allocation to reduce bottlenecks, and retaining and caching large artifacts within the mainframe environment to minimize the need for repeated external transfers, thereby enhancing deployment speed, reducing latency, and ensuring consistent performance, particularly in high-volume, enterprise-level operations; enabling, by BEARDS, incremental builds where only modified or updated source code files are recompiled and redeployed, reducing the overall time, resource usage, and risk associated with each build, while maintaining the integrity and consistency of the deployed application across all target environments, and ensuring that subsequent builds integrate seamlessly with previous deployments; and" integrating, by BEARDS, with cloud-based services to support hybrid cloud environments, where artifacts and configurations are seamlessly transferred and deployed between on-premise mainframe systems and cloud-based infrastructure, providing flexibility, scalability, and the ability to leverage cloud resources for testing, deployment, and scaling operations, while maintaining the security and integrity of the mainframe applications as substantially recited in independent claims 19 and 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kuruganthy (US 2025/0390416) teaches a method for automating integration and deployment of mainframe applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QAMRUN NAHAR whose telephone number is (571)272-3730. The examiner can normally be reached Monday - Friday 8-4pm.
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, Lewis Bullock can be reached on (571)272-3759. 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.
/QAMRUN NAHAR/Primary Examiner, Art Unit 2199
Prosecution Insights