DETAILED ACTION
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 are pending.
Claims 1-20 are rejected.
Response to Arguments
Applicant's arguments filed 04/09/2026 have been fully considered but they are not persuasive.
The Remarks argue that:
The amendment clarifies that the autoscaling check is part of the “first testing sequence” run by the automated testing system in response to the API call – not a standalone check, but an integrated component of a larger, triggered workflow. The amendment further emphasizes that Lee’s autoscaling tool would need to be embedded as a sub-component within a larger orchestrated sequence, a modification neither taught nor suggested by the applied reference.
However, the Examiner respectfully disagrees. The testing sequence being part of a larger automated testing platform is taught in the JetBeans NPL (page 2, “Automated testing tools & CI/CD” section).
Additionally, the Remarks argue that:
The Office’s reliance on JetBrains is procedurally defective because of the content cited was published after the application’s filing date. Specifically:
The version of the JetBrains article that qualifies as prior art – i.e., the version publicly accessible before the application’s filing date – does not mention containers at all.
That prior-art version does not disclose: “containerized applications,” execution of a testing script “by a first containerized application,” testing of “a second containerized application, different from the first containerized application,” or any container-to-container, API-triggered testing architecture as recited in the claims.
However, the Examiner respectfully disagrees. As indicated at the top of the attached NPL, the relied upon prior art is the one archived on July 2, 2022, and thus qualifies as the prior art.
Furthermore, as evidenced in the original Office Action on 01/09/2026, the Prior Art is not relied upon to teach the containerized application but to teach a system of lifecycle management testing that involves API calls. Specifically, the original office action recites that the Jet Brains NPL is used to “[expand] on the idea of how the automated testing tool can be used in the CI/CD testing environment.” It continues: “Jet Brains NPL teaches that certain components of the automated testing system can be triggered externally. It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to implement such programmatic triggers using an API call since APIs were well-known and conventional mechanism for invoking services in distributed systems.” The Examiner maintains the rejection, and the rejection below has been amended to make this distinction clear.
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.
Claim 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.
The amended claim includes similar claim limitation as the existing claim language creating a lack of clarity as to the scope of the claim. Claim 1 is shown below. The amended claim language is underlined. The existing claim limitation that are similar to the amended claim limitation is in bold italic. The claim should be revised to remove any duplicated claim language and offer clarity on the scope of the claim.
Claim 1 recites
“…automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and checking autoscaling behavior of the second containerized application,
wherein the first testing sequence comprises:
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and
checking autoscaling behavior of the second containerized application,
wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services, and wherein
the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services.”
Claim 8 and 15 recites a similar claim limitation as claim 1 and are rejected for similar reasons. The dependent claims inherit qualities of the parent claims and thus are rejected for similar reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lee, Nate (“How to Test Autoscaling in Kubernetes,” Speed Scale, Aug 19, 2022) from henceforth referred to as Lee in view of Ahrens, Ken (“Combine load testing and observability with Speed Scale and New Relic One, Jan 18, 2022) from henceforth referred to as Ahrens in further view of Jet Brains article titled “Automated Testing for CI/CD” from its web accessible TeamCity CI/CD Guide from henceforth referred to as Jet Brains NPL.
Per claim 1 Lee teaches
the system comprising:
a memory that stores instructions; and (page 2, memories)
at least one processor configured by the instructions to perform operations comprising: (page 2, CPUs)
…testing of containerized application… (page 10)
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated)
checking autoscaling behavior of the second containerized application, wherein the first testing sequence comprises: (page 10, the report is generated showing the number of pods scaling up or down depending on CPU usage)
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated)
checking autoscaling behavior of the second containerized application, wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services, and wherein (page 10, the report is generated showing the number of pods scaling up or down depending on CPU usage)
the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services (page 10, the report is generated showing the number of pods scaling up or down depending on CPU usage)
Lee fails to explicitly teach
A system for lifecycle management testing …
executing a first testing script by a first … application thereby causing an Application Programming Interface (API) call to be issued to at least one automated testing system;
running, by the at least one automated testing system, a first testing sequence on a second … application, different from the first … application, based on the API call
However, Ahrens teach
…one automated testing system (page 2, using Speed Scale as an automated testing tool that is part of the CI environment)
It is obvious to the person of ordinary skill in the art to combine Lee in view of Ahrens because Lee teaches how Speed Scale can be used to generate traffic and test whether the pod scaling is done as expected and Ahrens show how that can then be used as part of the CI environment as an automated testing system.
Lee in view of Ahrens fails to teach
A system for lifecycle management testing …
executing a first testing script by a first … application thereby causing an Application Programming Interface (API) call to be issued to [an automated system]
running… a first testing sequence on a second … application, different from the first … application, based on the API call
However, Jet Brains NPL teaches
A system for lifecycle management testing … (page 2, “Automated testing tools & CI/CD” section)
executing a first testing script by a first … application thereby causing an Application Programming Interface (API) call to be issued to [an automated system] (page 2)
running… a first testing sequence on a second … application, different from the first … application, based on the API call (page 2)
It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teachings of Lee in view of Ahrens to that of Jet Brains NPL because it simply expands on the idea of how the automated testing tool can be used in the CI/CD testing environment. Jet Brains NPL teaches that certain components of the automated testing system can be triggered externally. It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to implement such programmatic triggers using an API call since APIs were well-known and conventional mechanism for invoking services in distributed systems.
Per claim 2, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 1, wherein the first containerized application runs in a separate container from the second containerized application (Lee, page 2, shows a second containerized application being tested as “Pod 1” for instance; in Jet Brains NPL, page 2, it indicates an external containerized application within the CI environment that would trigger the automatic testing of the second containerized application. These are in separate containers since a person of ordinary skill in the art prior to the effective filing date of the claimed invention understands that the purpose of the container is to contain all of the necessary dependencies and environment factors for that specific application to function in a modular fashion. The testing component or triggering of the said testing component is very functionally separate from the actual functioning of the component and thus would reside in a separate container)
Per claim 3, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 1, wherein the operations further comprise: running, by a second automated testing system, a second testing sequence on the second containerized application, using the testing sequence results from the first testing sequence as an input parameter (page 2, “Automated testing tools & CI/CD” section, first paragraph, “many automated testing tools support integration with CI/CD tools, so you can feed the test data into the pipeline and run the tests in stages, with results provided after each step. Depending on your CI tool, you can choose whether to move a build to the next stage based on the outcome of the tests in the previous step”)
Per claim 4, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 3, wherein the operations further comprise: running, by a third automated testing system, a third testing sequence on the second containerized application, using the testing sequence results from the first testing sequence as an input parameter. (page 2, “Automated testing tools & CI/CD” section, first paragraph, “many automated testing tools support integration with CI/CD tools, so you can feed the test data into the pipeline and run the tests in stages, with results provided after each step. Depending on your CI tool, you can choose whether to move a build to the next stage based on the outcome of the tests in the previous step”)
Per claim 5, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 1, wherein the first and second containerized applications are in different pods on a same cluster of a network (Jet Brains NPL, page 2, teaches that there are different testing component within the CI/CD environment. A person of ordinary skill in the art prior to the effective filing date of the claimed invention would understand that they are in different pods since they are functionally different and distinct and that they would still need to be in the same cluster of a network for the testing via traffic generation to occur).
Per claim 6, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 1, wherein the operations further comprise: executing a second testing script, wherein the execution of the second testing script causes the at least one automated testing system to generate a testing sequence to be used in a testing pipeline (Jet Brains NPL, page 2, teaches a testing sequence being used in a testing pipeline and a testing sequence triggering an automated testing system; Ahrens, page 3, teaches an automated testing system that derives and executes testing sequences by capturing and replaying application traffic within a CI environment).
Per claim 7, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The system of claim 1, wherein the assessment of the health of the second containerized application comprises at least one of: verifying whether the second containerized application is up and running, verifying whether the second containerized application is ready to accept traffic, verifying whether node scheduling of the second containerized application is optimized, calculating a number of copies of the second containerized application that should be scheduled, verifying a container image size of the second containerized application, or verifying node failover information associated with the second containerized application (Lee, page 8-10, teaches issuing test requests to the application in which the data is dependent on the application’s responses, therefore verifying that the application is up and running during testing)
Per claim 8, Lee teaches
the method comprising:
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated)
checking autoscaling behavior of the second containerized application, wherein the first testing sequence comprises:
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated)
checking autoscaling behavior of the second containerized application, wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its service, and (page 10, the report is generated showing the number of pods scaling up or down depending on CPU usage)
wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services (page 10, the report is generated showing the number of pods scaling up or down depending on CPU usage)
Lee fails to teach
… lifecycle management testing of containerized applications…
executing a first testing script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to at least one automated testing system;
running, by the at least one automated testing system, a first testing sequence on a second containerized application, different from the first containerized application, based on the API call;
However, Ahrens teach
…one automated testing system (page 2, using Speed Scale as an automated testing tool that is part of the CI environment)
It is obvious to the person of ordinary skill in the art to combine Lee in view of Ahrens because Lee teaches how Speed Scale can be used to generate traffic and test whether the pod scaling is done as expected and Ahrens show how that can then be used as part of the CI environment as an automated testing system.
Lee in view of Ahrens fails to teach
… lifecycle management testing of containerized applications…
executing a first testing script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to…;
running… a first testing sequence on a second containerized application, different from the first containerized application, based on the API call;
However Jet Brains NPL teaches
… lifecycle management testing of containerized applications…(page 2, “Automated testing tools & CI/CD” section)
executing a first testing script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to…; (page 2)
running… a first testing sequence on a second containerized application, different from the first containerized application, based on the API call; (page 2)
It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teachings of Lee in view of Ahrens to that of Jet Brains NPL because it simply expands on the idea of how the automated testing tool can be used in the CI/CD testing environment. Jet Brains NPL teaches that certain components of the automated testing system can be triggered externally. It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to implement such programmatic triggers using an API call since APIs were well-known and conventional mechanism for invoking services in distributed systems.
Per claims 9-14, the claims recite similar claim limitations as those of claims 2-7 and therefore are rejected for similar reasons as claims 2-7.
Per claim 15, Lee teaches
…
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated) wherein the first testing sequence comprises:
automatically displaying the first testing sequence results, wherein the first testing sequence results comprise an assessment of a health of the second containerized application; and (page 10, the report is generated)
checking autoscaling behavior of the second containerized application, wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its service, and (page 10, the report is generated showing the number of pods scaling up or down depending on cpu usage)
checking autoscaling behavior of the second containerized application, wherein the checking comprises determining whether the second containerized application replicates or deletes instances of itself in response to increased or decreased demand for its services. (page 10, the report is generated showing the number of pods scaling up or down depending on cpu usage)
Lee fails to teach
A non-transitory computer-readable medium for lifecycle management testing of containerized applications, storing instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising:
executing a test script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to at least one automated testing system;
running, by the at least one automated testing system, a first testing sequence on a second containerized application, different from the first containerized application, based on the API call;
However, Ahrens teach
one automated testing system; (page 2, using Speed Scale as an automated testing tool that is part of the CI environment)
It is obvious to the person of ordinary skill in the art to combine Lee in view of Ahrens because Lee teaches how Speed Scale can be used to generate traffic and test whether the pod scaling is done as expected and Ahrens show how that can then be used as part of the CI environment as an automated testing system.
Lee in view of Ahrens fails to teach
A non-transitory computer-readable medium for lifecycle management testing of containerized applications, storing instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising:
executing a test script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to …
running… a first testing sequence on a second containerized application, different from the first containerized application, based on the API call;
However, Jet Brains NPL teaches
A non-transitory computer-readable medium for lifecycle management testing of containerized applications, storing instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising: (page 2, “Automated testing tools & CI/CD” section)
executing a test script by a first containerized application thereby causing an Application Programming Interface (API) call to be issued to … (page 2, “Automated testing tools & CI/CD” section)
running… a first testing sequence on a second containerized application, different from the first containerized application, based on the API call; (page 2, “Automated testing tools & CI/CD” section)
It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to combine the teachings of Lee in view of Ahrens to that of Jet Brains NPL because it simply expands on the idea of how the automated testing tool can be used in the CI/CD testing environment. Jet Brains NPL teaches that certain components of the automated testing system can be triggered externally. It is obvious to a person of ordinary skill in the art prior to the effective filing date of the claimed invention to implement such programmatic triggers using an API call since APIs were well-known and conventional mechanism for invoking services in distributed systems.
Per claims 16, 17, 18, and 19, the claims recite similar claim limitations to those of claims 2, 3, 5, and 6 respectively and thus are rejected for similar reasons.
Per claim 20, Lee in view of Ahrens in further view of Jet Brains NPL teaches
The medium of claim 15, wherein the assessment of the health of the second containerized application comprises at least one of:
verifying whether the second containerized application is up and running, verifying whether the second containerized application is ready to accept traffic, verifying whether node scheduling of the second containerized application is optimized, calculating a number of copies of the second containerized application that should be scheduled, verifying a container image size of the second containerized application, or-verifying node failover information associated with the second containerized application, and wherein
in response to an increased demand for the second containerized application's services, at least one new copy of the second containerized application is made,
in response to a decreased demand for the second containerized application's services, at least one copy of the second containerized application is deleted, and
in response to the making of at least one copy of the second containerized application or the deletion of at least one copy of the second containerized application, performance of the second containerized application is measured. (Lee, page 10, showcases how Speed Scale can be used to show the success rate of the requests when artificial traffic is generated in order to test the autoscaling capabilities. It generates report so that the user can check that “the autoscaler has scaled up with the increasing load the same was as in the previous section.” A person of ordinary skill in the arts prior to the effective filing date of the claimed invention will appreciate the fact that autoscaling also works the other way around – when the traffic decreases, so does the number of pods. Using the broadest reasonable interpretation, this process does include calculating a number of copies of the second containerized application that should be scheduled, since that number is necessary in order to know whether the autoscaling is working as necessary).
Conclusion
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 KAYO LISA RUSIN whose telephone number is (703)756-1679. The examiner can normally be reached Monday-Friday 8:30 - 5:00 EST.
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, Ashish Thomas can be reached at 571-272-0631. 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.
/K.L.R./Examiner, Art Unit 2114
/ASHISH THOMAS/Supervisory Patent Examiner, Art Unit 2114
Prosecution Insights