DETAILED ACTION
This office action is responsive to request for continued examination filed on January 16, 2026 in this application Luthra et al., U.S. Patent Application No. 17/997,554 (Filed October 31, 2022) claiming priority to PCT/US2022/039513 (Filed August 5, 2022) (“Luthra”). Claims 1 – 20 were pending. Claims 1, 7, 8 – 15, 19, and 20 are amended. Claims 1 – 20 are pending.
Continued Examination Under 37 CFR 1.114
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 of on January 16, 2026 has been entered.
Response to Arguments
1. With respect to Applicant’s argument on pgs. 15 – 24 of the Applicant’s Remarks (“Remarks”) stating that the testing claimed in claim 1 amounts to a practical application and significantly more, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §101. The abstract idea embodied in the claimed testing steps is recited at a high level and does not include details of the tests that limits them to tests performed automatically by the computer rather than performed manually by the user, such as by clicking on a GUI and observing results. See MPEP § 2106.04(a)(2)(III)(C)(3). This judicial exception is not integrated into a practical application because the claims only recite insignificant pre- and post-solution data transmission and displaying. See MPEP 2106.05(g) & (h). The additional limitations of receiving and transmitting data prior to and following the testing steps fail to amount to significantly more as data transmission is a function that has been identified by courts as well-understood, routine, and convention activity that does not amount to significantly more than the judicial exception. See MPEP 2106.05(d).
Therefore, the claims remain rejected under 101.
2. With respect to Applicant’s argument on pgs. 24 - 36 of the Remarks stating that the prior art references fail to teach the amended, examiner respectfully disagrees in part. See infra § Claim Rejections - 35 USC §103, § Claim 1.
It is noted that while Applicant’s arguments identify particular limitations as well as teachings of the prior art it is unclear from the argument presented how the cited teachings of the prior art fail to teach the referenced limitations. The Arguments appear to allege each individual prior art reference fails to teach a similar set of limitations, whereas in the rejection specific limitations were mapped to specific references rather than all the limitations mapped to all the references. To the extent an individual reference has been used in the 103 rejection infra, the following references teach the following argued limitations:
Heyhoe teaches the newly added amendments directed to fetching a workflow by disclosing obtaining a vendor specification of a workflow for testing the code including the specification of the testing environment for pre-production testing. Id. at ¶¶ 0084, 0087, 0105, 0174, 0216.
Cillis is used to teach creating a service catalog entry for the application bundle at a production service catalog system by disclosing that testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105.
Wallis teaches the newly added limitations related to a notification that the application bundle did not pass the quality assurance testing by disclosing an approval release management system utilizing tickets to communicate testing failures. Wallis at ¶¶ 0043 – 0049; id. at ¶ 0032 (tickets for test failures).
Finally, prior art reference Schwan, added as necessitated by newly added limitations directed to promoting the application to a marketplace using calls, teaches that code which has successfully passed testing may be promoted to an app store using an API. Schwan at ¶¶ 0002, 0020, & 0050.
Therefore, in light of the teaching of the three previously used references and the newly added reference Schwan, the current prior art teaches the amended limitations.
Claim Objections
In light of Applicant’s amendments, the previous objections to the claims are withdrawn.
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 inventions are directed to non-statutory subject matter. The claimed inventions do not fall within a statutory category of invention because they are directed to a “Mental Processes” abstract idea without significantly more.
Claims 1, 9, and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a “Mental Processes” abstract idea without significantly more. The claim recites requesting pre-production testing of the application bundle to be performed by the pre-production system; in response to the application bundle passing the pre-production testing performed by the pre-production system, receiving an indication of approval of the application bundle from a Release management/Ticketing System; in response to receiving the indication of approval of the application bundle from the Release Management/Ticketing System, performing quality assurance testing of the application bundle by one or more systems in at least one pre-production test environment isolated from one or more systems of the production environment; in response to the application bundle passing the quality assurance testing by the one or more systems in the at least one pre-production test environment isolated from by the one or more systems of the production environment, promoting the application bundle to the one or more systems of the production environment; covers performance of the limitation that can be performed in the mind or by pen and paper, but for the recitation of generic computer components.
That is, other than reciting additional elements of generic computer components as well as pre and post-solution data transmission nothing in the claim precludes the pre-production test requesting, approval, quality assurance testing, and “promoting”, from being performed by a user using the pre-production system and Release Management/Ticketing System computer as a tool to perform the steps including, for example, the quality assurance testing step by performing user testing of a graphical user interface and also the approval, promotion, and service catalog entry steps by entering approval and promotion data by editing a text file, clicking a button, or sending a message. See MPEP § 2106.04(a)(2)(III)(C)(3). As drafted, the claimed process, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components and routine pre solution data transmission, which falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claims only recite generic computing components and pre-and post-solution data transmission. See MPEP 2106.05(g). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the identified additional elements of data transmission and displaying are functions that have been identified by courts as well-understood, routine, and convention activity that do not amount to significantly more than the judicial exception. See MPEP 2106.05(d).
Claims 2 - 20 contains the same abstract idea as claim 1 and do not contain any additional limitations that would integrate the judicial exception into a practical application or additional elements that are sufficient to amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 112(b)
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.
1. Claim 9 is rejected as being indefinite. There is a lack of antecedent basis for “the pre-production test environment.” No “pre-production test environment” has been previously introduced the claim or in a claim from which it depends.
Claims 10 - 14 are rejected as depending on claim 9.
2. Claim 9 is rejected as being indefinite. It is unclear if the various references to “at least one or more pre-production test environment” refer to the previously introduced “pre-production test environment” or to different pre-production test environments.
Claims 10 - 14 are rejected as depending on claim 9.
35 USC § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “device further being configured to”, in claim 9 - 14.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections 35 U.S.C. §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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Heyhoe et al., United States Patent Application Publication No. 2016/0077809 (Published March 17, 2016, filed September 21, 2015) (“Heyhoe”) in view of Cillis et al., United States Patent Application No. 2018/0121335 (Published May 3, 2018, filed October 27, 2016) (“Cillis”), Wallis et al., United States Patent Application No. 2022/0253297 (Published August 11, 2022, filed February 11, 2021) (“Wallis”), and Schwan et al., United States Patent Application No. 2014/0040871 (Published February 6, 2014, filed August 2, 2013) (“Schwan”).
Claims 1, 9, and 15
With respect to claims 1, 9, and 15, Heyhoe teaches the invention as claimed including a method for providing end-to-end application onboarding, comprising:
uploading an application bundle of a [vendor] to a pre-production system for storage by one or more storage devices; fetching, from a workflow database, a workflow of the application bundle, wherein the workflow is configured by the vendor; requesting pre-production testing of the application bundle to be performed by the pre-production system; in response to the application bundle passing the pre-production testing performed by the pre-production system, receiving an indication of approval of the application bundle from a [Release Management/Ticketing System]; in response to receiving the indication of approval of the application bundle from the [Release Management/Ticketing System], performing quality assurance testing of the application bundle by one or more systems in at least one pre-production test environment isolated from one or more systems of the production environment; in response to the application bundle passing the quality assurance testing by the one or more systems in the at least one pre-production test environment isolated from the one or more systems of the production environment, promoting the application bundle to the one or more systems of the production environment; and… in response to the application bundle not passing the quality assurance testing by the one or more systems in the at least one pre-production test environment isolated from the one or more systems of the production environment, …passing the application bundle to the [vendor] for editing. {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, obtaining the testing workflow for testing the the code, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure); id. at ¶¶ 0084, 0087, 0105, 0174, 0216 (testing workflow is obtained).
However, Heyhoe doesn’t explicitly teach the limitation:
vendor…creating a service catalog entry for the application bundle at a production service catalog system, {Cillis does teach this limitation. Cillis teaches that the method for testing code for deployment, as taught in Heyhoe, may include where the testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).
Heyhoe and Cillis are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software testing, and both are trying to solve the problem of how to manage the testing steps.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a method for testing code for deployment, as taught in Heyhoe, with testing vendor code/tests using a sandbox and certifying results, as taught in Cillis. Heyhoe teaches that the creation and editing of the application bundle and tests may be provided by outside developers using the system rather than the providers of the testing and deployment system itself. Id. at ¶ 0112, 0118, and 0144. Therefore, one having ordinary skill in the art would have been motivated to combine a method for testing code for deployment, as taught in Heyhoe, with testing vendor code/tests using a sandbox and certifying results, as taught in Cillis, for the purpose of using a known code testing method with a code testing method that tests vendor supplied tests in a sandbox.}
However, Heyhoe and Cillis doesn’t explicitly teach the limitation:
Release Management/Ticketing System … sending, to the vendor, a notification that the application bundle did not pass the quality assurance testing performed by the one or more systems in the at least one pre-production test environment, and {Wallis does teach this limitation. Wallis teaches that the method for testing code in pre-production environments, as taught in Heyhoe and Cillis, may include where the code is incrementally tested in multiple environments, including pre-production, and an approval release management system may be used to record passing testing scores to inform the subsequent stage the code is ready for promotion, including where the release management system may utilize tickets to communicate testing failures. Wallis at ¶¶ 0043 – 0049; id. at ¶ 0032 (tickets for test failures).
Heyhoe, Cillis, and Wallis are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software testing, and both are trying to solve the problem of how to manage the testing steps.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a method for testing code in pre-production environments, as taught in Heyhoe and Cillis, with recording test result approvals for promotions from one testing environment to another, as taught in Wallis. Wallis teaches that using automated release management to record test result approvals allows the system to automatically ensure the code passed predetermined quality thresholds before being promoted out of a pre-production testing environment. Id. at ¶ 0049. Therefore, one having ordinary skill in the art would have been motivated to combine a method for testing code in pre-production environments, as taught in Heyhoe and Cillis, with recording test result approvals for promotions from one testing environment to another, as taught in Wallis, for the purpose of using a known result tracking method with a software testing method that requires tracking test results.}
However, Heyhoe, Cillis, and Wallis doesn’t explicitly teach the limitation:
and providing production-related calls to promote the application bundle to an application marketplace, the application bundle being selected for use from the application marketplace; {Schwan does teach this limitation. Wallis teaches that the method for testing code in pre-production environments, as taught in Heyhoe, Cillis, and Wallis, may include deploying passing code to an app store using an API. Schwan at ¶¶ 0002, 0020, & 0050.
Heyhoe, Cillis, Wallis, and Schwan are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of software testing, and both are trying to solve the problem of how to manage the testing and deployment steps.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a method for testing code in pre-production environments, as taught in Heyhoe, Cillis, and Wallis, with deploying passing code to an app store, as taught in Schwan. Wallis teaches that app store deployments may be performed automatically without the need for manual user intervention requiring coordination. Id. at ¶¶ 0003, 0019, 0020. Therefore, one having ordinary skill in the art would have been motivated to combine a method testing code in pre-production environments, as taught in Heyhoe, Cillis, and Wallis, with deploying passing code to an app store, as taught in Schwan, for the purpose of using a fast automated app deployment mechanism with a method that requires deploying apps.}
Claims 2, 10, and 16
With respect to claims 2, 10, and 16, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the uploading the application bundle of the vendor to the pre-production system further includes submitting the application bundle to a service designer, wherein the service designer passes the application bundle to a pre- production artifactory. {BDE is used for storing and testing the code in a pre-production environment. Heyhoe at fig. 5; id. at ¶¶ 0113, 0119. 0121.}
Claims 3, 11, and 17
With respect to claims 3, 11, and 17, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the performing quality assurance testing of the application bundle in at least one pre-production test environment isolated from the production environment further includes one of performing [sandbox testing] and staging testing, and skipping sandbox testing and performing staging testing. {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
sandbox testing {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
Claims 4 and 12
With respect to claims 4 and 12, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the performing sandbox testing includes: creating a pre-production service catalog entry; deploying the application bundle to a sandbox environment; triggering sandbox testing for the application bundle; …requesting automated sandbox testing of the application bundle; based on the application bundle passing the automated sandbox testing, initiating self- certification of the application bundle; and in response to the approval of the self-certification, {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
setting up a deployment configuration for the application bundle;… promote the application bundle for performing staging testing. {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
Claim 5
With respect to claim 5, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the self-certification is rejected, the performing [sandbox testing] further including updating a workflow to perform one of rejecting the application bundle and returning the application bundle to the vendor. {A code development, testing, and deployment process includes an initial request for testing the code in a pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
sandbox testing {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
Claims 6 and 14
With respect to claims 6 and 14, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the performing sandbox testing includes: creating a pre-production service catalog entry; deploying the application bundle to a sandbox environment; triggering sandbox testing for the application bundle; … performing [manual] sandbox testing on the application bundle; based on the application bundle passing the [manual] sandbox testing, initiating self- certification of the application bundle; and in response to the approval of the self-certification, {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
setting up a deployment configuration for the application bundle;… manual testing…review and promote the application bundle for performing staging testing. {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing [manual testing performed by user/developer], then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
Claims 7, 13, and 19
With respect to claims 7, 13, and 19, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the performing staging testing includes: creating a release request for a pre-production release management system; receiving approval of the application bundle from the pre-production release management system; creating a pre-production service catalog entry and send to a staging testing environment; deploying the application bundle to the staging testing environment; triggering staging testing for the application bundle; setting up a deployment configuration for the application bundle; requesting automated staging testing of the application bundle; based on the application bundle passing the automated staging testing, … and in response to receiving the certification of the application bundle, promoting the application bundle to the production environment. {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
receiving certification of the application bundle from the release management system; {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
Claims 8, 14, and 20
With respect to claims 8, 14, and 20, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the promoting the application bundle to the production environment includes: promoting the application bundle to production artifactory; {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing, then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
Claim 18
With respect to claim 18, Heyhoe, Cillis, Wallis, and Schwan, teach the invention as claimed including:
wherein the performing sandbox testing includes: creating a pre-production service catalog entry; deploying the application bundle to a sandbox environment; triggering sandbox testing for the application bundle; … requesting one of automated sandbox testing and [manual] sandbox testing of the application bundle; based on the application bundle passing the one of the automated sandbox testing and the [manual] sandbox testing, initiating self-certification of the application bundle; in response to approval of the self-certification, … and in response to rejection of the self-certification, updating workflow to perform one of rejecting application and returning the application bundle to the vendor. {Testing is performed for vendor supplied tests/code that is stored a catalog that stores tests and certifications, where the quality assurance testing includes testing in a pre-production environment and/or in a sandbox and where testing success results in certification and storage of the certification in the catalog. Cillis at ¶¶ 0045, 0046, 0105; id. at ¶ 0055 (test failure).}
setting up a deployment configuration for the application bundle;… manual testing… promote the application bundle for performing staging testing {A code development, testing, and deployment process includes an initial request for testing the code in pre-production system, such as integration testing system 606, followed by approval after completing testing and transferring to a separate pre-production repository, such as versioning server, for quality assurance testing including operations acceptance testing and user acceptance testing [manual testing performed by user/developer], then once pre-production testing is successfully completed the application is deployed to a staging environment where staging testing is performed after which the application may be approved and deployed for customer view and to the production system where code that fails to pass a testing step is sent back to development for revision. Heyhoe at ¶¶ 0118 & 0119 (initial pre-production testing); id. at ¶¶ 0104 & 0120 (quality assurance testing); id. at ¶ 0161 (staging testing); ¶¶ 0080, 0111, 0185 (promote to production systems); id. at ¶¶ 0123 & 0124 and fig. 7 (test failure).}
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m..
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.
/T.H./ January 24, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199