DETAILED ACTION
This office action is responsive to claims 1 - 20 filed in this application Chao et al., U.S. Patent Application No. 18/655,487, (Filed May 6, 2024).
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) filed on June 7, 2026 is in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. The references listed therein have been considered, and placed in the application file.
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 the claimed invention is directed to a “Mental Processes” abstract idea without significantly more.
1. Claim 1 is 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 in response to determining that a software development project has progressed from a first orchestration platform environment to a second orchestration platform environment, binding a first version of a binary image of the software development project to a first file of a first source of truth repository; and in response to determining that the software development project has progressed from the second orchestration platform environment to a third orchestration platform environment, binding a second version of the binary image of the software development project to a second file of a second source of truth repository that differs from the first source of truth repository, 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 generic computer components and insignificant extra-solution data storage, nothing in the claim elements precludes the determining and binding steps from being performed in the mind of a developer potentially using a computer as a tool for storing the binding data. See MPEP § 2106.04(a)(2)(III)(C)(3). As drafted, the claimed process, under its broadest reasonable interpretation, covers of the limitation in the mind but for the recitation of generic computer components and insignificant extra-solution data storage, 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. See MPEP 2106.05(f). 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 courts have identified mere data gathering, displaying/outputting, transmitting, and storing, are well-understood, routine and conventional activity. See MPEP 2106.05(d).
Claims 2 - 20 contain 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 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, 2, 6 – 11, 13, 14, and 17 - 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kludy et al., United States Patent Application Publication No. 2019/0163460 (Published May 30, 2019, filed November 29, 2017) (“Kludy”) in view of Hoenzsch et al., United States Patent Application Publication No. 2022/0283801 (Published September 8, 2022, filed March 8, 2021) (“Hoenzsch”).
Claims 1, 13, and 17
With respect to claims 1, 13, and 17 Kludy teaches the invention as claimed including a device, comprising:
at least one processor; and at least one memory that stores executable instructions that, when executed by the at least one processor, facilitate performance of operations, comprising: in response to determining that a software development project has progressed from a first orchestration platform environment to a second orchestration platform environment, …binary image {An image update orchestrator holds images that are sent from a development environment to a testing environment where the images may be tested where, if validated, the image may be promoted to a production environment and, if not validated, the image may be rolled back to previous stable version. Kludy at ¶¶ 0006, 0107 – 0110, 0114, 0125, 0128; id. at fig. 7; id. at ¶ 0136 (validation error rate threshold); id. at ¶¶ 0137 & 0138 (rollback to previous version of image if validation fails).}
However, Kludy doesn’t explicitly teach the limitation:
binding a first version of a [binary image] of the software development project to a first file of a first source of truth repository; and in response to determining that the software development project has progressed from the second orchestration platform environment to a third orchestration platform environment, binding a second version of the [binary image] of the software development project to a second file of a second source of truth repository that differs from the first source of truth repository. {Hoenzsch does teach this limitation. Hoenzsch teaches an image orchestrator environment for validating images prior to promotion to the next stage of orchestration, as taught in Kludy, may include where at each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).
Kludy and Hoenzsch 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment, as taught in Kludy with using a policy for each stage as part of the validation, as taught in Hoenzsch. Hoenzsch teaches that version traceability is desired as part of a DevSecOps pipeline. Id. at ¶¶ 0001 & 0002. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment, as taught in Kludy with using a policy for each stage as part of the validation, as taught in Hoenzsch, for the purpose of using a known policy based validation mechanism for releases with a method that requires validating images prior to release.}
Claims 2 and 14
With respect to claims 2 and 14, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the first orchestration platform environment is a development environment, the second orchestration platform environment is a staging environment, and the third orchestration platform environment is a production environment. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claim 6
With respect to claim 6, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise performing an informal review procedure configured to identify potential deficiencies with the first file associated with the first source of truth or the first version of the binary image. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claim 7
With respect to claim 7, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise, in response to the informal review procedure, generating feedback relating to the potential deficiency for a developer entity for the software development project. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claim 8
With respect to claim 8, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise performing a formal review procedure configured to identify potential deficiencies with the first file associated with the first source of truth or the first version of the binary image, or, in response to no potential deficiencies being identified, certifying the second file and the second version of the binary image as approved. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claim 9
With respect to claim 9, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise, in response to the formal review procedure, generating feedback relating to the potential deficiency for a developer entity for the software development project or, in response to no potential deficiencies being identified, generating an indication of approval. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claims 10 and 18
With respect to claims 10 and 18, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise enforcing a deployment constraint that prevents the second version of the binary image from being deployed to the third orchestration platform environment unless the second version of the binary image and an associated second file have successfully passed a formal review procedure. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claims 11 and 19
With respect to claims 11 and 19, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise enforcing a deployment constraint that prevents any version of the binary image from being deployed to the third orchestration platform environment unless the binary image has been bound to the second file via an indication of formal review approval. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
Claims 3 – 5, 12, 15, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kludy in view of Hoenzsch and Geddes et al., United States Patent Application Publication No. 2022/0083450 (Published 3/14/2022, filed 9/15/2021) (“Geddes”).
Claim 3
With respect to claim 3, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the first file comprises at least one of … or a first policy file that is bound to the first version of the binary image within the second orchestration platform environment, and wherein the second file comprises at least one of … or a second policy file that is bound to the second version of the binary image within the third orchestration platform environment. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
a first application programming interface (API) specification file … a second API specification file {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
Claim 4
With respect to claim 4, Kludy, Hoenzsch, and Geddes, teach the invention as claimed including:
wherein the first API specification file and the second API specification file define a structure, an endpoint, a parameter, or a response associated with an API of the software development project, and wherein the first policy file and the second policy file comprise a configuration setting or rule that defines how the API is accessed, secured, or managed. {Code may be statically analyzing via comparing the structure of API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Claim 5
With respect to claim 5, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise utilizing a dev file that is received from a developer repository of a developer entity for the software development project within the first orchestration platform environment, {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
and wherein the dev file comprises at least one of a dev API specification file or a dev policy file. {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
Claim 12
With respect to claim 12, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise enforcing a deployment constraint that prevents any version of an [application programming interface (API)] specification file composing the second file from being deployed to an [API] gateway associated with the third orchestration platform environment unless an associated [API] specification file has successfully passed a formal review procedure. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
API {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
Claim 15
With respect to claim 15, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the first file comprises at least one of …or a first policy file that is bound to the first version of the binary image within the second orchestration platform environment, and wherein the second file comprises at least one of or a second policy file that is bound to the second version of the binary image within the third orchestration platform environment, {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
a first application programming interface (API) specification file… a second API specification file … and wherein the first API specification file and the second API specification file define a structure, an endpoint, a parameter, or a response associated with an API of the software development project, and wherein the first policy file and the second policy file comprise a configuration setting or rule that defines how the API is accessed, secured, or managed. {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
Claim 16
With respect to claim 16, Kludy and Hoenzsch, teach the invention as claimed including:
wherein the operations further comprise implementing a deployment constraint that: prevents the second version of the binary image from being deployed to the third orchestration platform environment unless the second version of the binary image and an associated second file has passed a formal review procedure; prevents any version of the binary image from being deployed to the third orchestration platform environment unless the binary image has been bound to the second file via an indication of formal review approval, or prevents any version of an [API] specification file, composing the second file, from being deployed to an [API] gateway associated with the third orchestration platform environment. {At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
API {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
Claim 20
With respect to claim 20, Kludy and Hoenzsch, teach the invention as claimed including:
further comprising, enforcing, by the device, a deployment constraint that prevents any version of an [application programming interface (API)] specification file composing the second file from being deployed to an [API] gateway associated with the third orchestration platform environment.{At each stage of an orchestration environment, such as development, pre-production staging and testing, and/or production environments, metadata such as test results of a release may be compared to requirements retrieved from a policy stored in a repository that is bound to that release for each particular stage to determine whether the release satisfies the requirements specified in the policy. Hoenzsch at ¶¶ 0052 – 0054, 0056, 0060; id. at ¶ 0091 (source of truth); id. at ¶¶ 0092 & 0093 (informal review may have proceeded prior to formal review).}
However, Kludy and Hoenzsch doesn’t explicitly teach the limitation:
API {Geddes does teach this limitation. Geddes teaches an image orchestrator environment that uses policies for validating images prior to promotion to the next stage of orchestration, as taught in Kludy and Hoenzsch, may include where the policies are for validating API usage in the images, by statically analyzing code via comparing API endpoints usage found in the code with an API/policy file such as a listing of code using the API that has been determined to be buggy. Geddes at Abstract; id. at ¶¶ 0026, 0028 – 0030, 0073, 0127; id. at ¶¶ 0056 & 0063.}
Kludy, Hoenzsch, and Geddes 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 deployment, and both are trying to solve the problem of how to validate the software.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes. Geddes teaches that code may be validated using static methods to compare the code to a specification file such as a bug code listing. Id. at ¶¶ 0056 & 0063. Therefore, one having ordinary skill in the art would have been motivated to combine an image orchestrator environment using policies for validation, as taught in Kludy and Hoenzsch with using policies for validating API usage in the images, as taught in Geddes, for the purpose of using a known policy based validation mechanism for images with a method that requires validating images that use APIs.}
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./ June 27, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights