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 .
Status of Application
Claim(s) 1-23 were previously pending and were rejected in the previous office action. Claim(s) 1, 11, 16, and 20 were amended. Claim(s) 2-10, 12-15, 17-19, and 21-23 were left as previously/originally presented Claim(s) 1-23 are currently pending and have been examined.
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 filed on April 14, 2026, has been entered.
Response to Arguments
Claim Interpretation
Applicant's arguments, see page 7 of Applicant’s Response, filed April 17, 2026, with respect to 35 U.S.C 112(f) have been fully considered and are persuasive for the terms “one or more business infrastructure modules,” “software components,” and “the system”.
However, applicant's arguments, see page 7 of Applicant’s Response, filed April 17, 2026, with respect to 35 U.S.C 112(f) have been fully considered but they are not persuasive.
Applicant first argues, on page 7, that Prong A of the three-prong analysis, in MPEP 2181, for interpreting 112(f) limitations is not met. Examiner, respectfully, disagrees with applicant’s arguments. Examiner, notes, that Prong A is met because the claim recites “process infrastructure container system,” which is a generic placeholder for “means.” One of ordinary skill in the art would not recognize the term “system,” in this limitation as sufficiently definite meaning of structure and the phrase “a system,” is simply a recitation of the function. No specific definition of the term “a process infrastructure container system,” is provided or recognized in the art.
Applicant also argues, on page 7, that Prong B of the three-prong analysis, in MPEP 2181, for interpreting 112(f) limitations is not met. Examiner, respectfully, disagrees with applicant’s argument. Examiner, notes, that Prong B is met because the
generic placeholder “process infrastructure container system,” is modified by functional language. Examiner, notes, that although the claim limitation will use the linking word “for,” to associate “means,” or a generic placeholder with the function it is possible to have other linking words such as “so that,” and “configured to.” (See, MPEP 2181 (I)(B)) Here, applicant’s limitation is modified by “configured to.”
Applicant also argues, on page 7, that Prong C of the three-prong analysis, in MPEP 2181, for interpreting 112(f) limitations is not met. Examiner, respectfully, disagrees with applicant’s argument. Examiner, notes, that Prong C is met because the claim, which, recites “process infrastructure container system,” is not further modified by sufficient structure or material for performing the claimed function. Therefore, as the limitation(s) are written applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 101
Applicant’s arguments, see page(s) 7-9 of Applicant’s Response and amendments, filed April 17, 2026, with respect to the rejection of Claim(s) 1-23, based on non-statutory subject matter, under 35 U.S.C. 101 has been fully considered and are persuasive.
Examiner, further, notes, that the software components are integrated together to ensure compatibility for the integrated software components where the failed validation is addressed by a software developer to debug the software component, which increases the software security against vulnerabilities, see applicant’s specification paragraph(s) 0054-0055. Therefore, 35 U.S.C. 101 rejection has been withdrawn
Claim Rejections - 35 USC § 103
Applicant’s arguments and amendments, see page(s) 9-11 of Applicant’s Response, filed April 17, 2016, with respect to Claim(s) 1-23 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Interpretation
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:
“process infrastructure container system is configured to…,” in Claim 11.
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 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1: Independent Claim 1 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Independent Claim 1 is an idea without a physical embodiment when the claim recites “A process infrastructure container system, wherein the system comprises: one or more process infrastructure modules that comprise software components….the software components are integrated…,” because the claim comprises entirely software/data. The software/data is being used rather than the intended physical embodiment to perform/cause the function(s). Therefore, Independent Claim 1 does not fall within at least one of the four categories of patent eligible subject matter.
Claim 2: Step 1: Dependent Claim 2 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 2 is an idea without a physical embodiment when the claim recites “wherein the manifest file comprises a YAML file…,” because the software (i.e., manifest file) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 2 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the YAML file. Thus, Dependent Claim 2 falls within software per se.
Claim 3: Step 1: Dependent Claim 3 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 3 is an idea without a physical embodiment when the claim recites “wherein the manifest file comprises name, description, access permissions, or combinations thereof for one or more process infrastructure modules…,” because the software (i.e., manifest file) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 3 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the YAML file. Thus, Dependent Claim 3 falls within software per se.
Claim 4: Step 1: Dependent Claim 4 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 4 is an idea without a physical embodiment when the claim recites “wherein the YMAL file comprises details of connections between one or more process infrastructure modules…,” because the software/data (i.e., YMAL file) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 4 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the YAML file. Thus, Dependent Claim 4 falls within software per se.
Claim 5: Step 1: Dependent Claim 5 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 5 is an idea without a physical embodiment when the claim recites “wherein the YMAL file comprises configurable inputs to deploy the container system on a new platform…,” because the software/data (i.e., YMAL file) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 5 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the YAML file. Thus, Dependent Claim 5 falls within software per se.
Claim 6: Step 1: Dependent Claim 6 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 6 is an idea without a physical embodiment when the claim recites “wherein the system is configured to receive the computer-readable instructions via a Typescript or JavaScript programming language…,” because the software/data rather than the intended physical embodiment is being used to perform/cause the function. Therefore, Dependent Claim 6 does not fall within at least one of the four categories of patent eligible subject matter. The claim describes only software code or data on a medium without being tied to the hardware that cause(s)/perform(s) the functions for interacting with the programming language. Thus, Dependent Claim 6 falls within software per se.
Claim 7: Step 1: Dependent Claim 7 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 7 is an idea without a physical embodiment when the claim recites “wherein the one or more process infrastructure modules comprise an automation module, commands, dashboards, webhooks, or combinations thereof,” because the software/data (i.e., automation module, commands, dashboards, webhooks..) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 7 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the automation module, commands, dashboards, webhooks, or combinations thereof. Examiner, respectfully, notes the automations, dashboards, commands, and webhooks are just software, see applicant’s specification paragraph 0003. Thus, Dependent Claim 7 falls within software per se.
Claim 8: Step 1: Dependent Claim 8 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 8 is an idea without a physical embodiment when the claim recites “the process infrastructure container system…wherein the user is configured to select one or more infrastructure modules based upon the user-desired operation…,” because the software (i.e., infrastructure modules/system) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 8 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the infrastructure modules. Thus, Dependent Claim 8 falls within software per se.
Claim 9: Step 1: Dependent Claim 9 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 9 is an idea without a physical embodiment when the claim recites “wherein a plurality of infrastructure modules is available to the user via a process infrastructure platform…,” because the software/data (i.e., infrastructure modules) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 9 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the infrastructure modules. Thus, Dependent Claim 9 falls within software per se.
Claim 10: Step 1: Dependent Claim 10 is merely software per se, which, does not fall within at least one of the four categories of patent eligible subject matter. As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories. Digitech, 758 F.3d at 1348, 111 USPQ2d at 1719. Thus, the Federal Circuit has held that a product claim to an intangible collection of information, even if created by human effort, does not fall within any statutory category. Digitech, 758 F.3d at 1350, 111 USPQ2d at 1720 (claimed "device profile" comprising two sets of data did not meet any of the categories because it was neither a process nor a tangible product). Similarly, software expressed as code or a set of instructions detached from any medium is an idea without physical embodiment. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. Another example of an intangible product that does not fall within a statutory category is a paradigm or business model for a marketing company. In re Ferguson, 558 F.3d 1359, 1364, 90 USPQ2d 1035, 1039-40 (Fed. Cir. 2009).
In this case, Dependent Claim 10 is an idea without a physical embodiment when the claim recites “wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the process infrastructure platform…,” because the software/data (i.e., infrastructure modules) rather than the intended physical embodiment (e.g., computer/processor) is being used to perform/cause the function. Therefore, Dependent Claim 10 does not fall within at least one of the four categories of patent eligible subject matter. Examiner, respectfully suggest applicant consider positively reciting that the hardware that cause(s)/perform(s) the functions for interacting with the YAML file. Thus, Dependent Claim 10 falls within software per se.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 5, 7, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lanford et al. (US 2022/0357938 A1) in view of Wang (CN-115964185-A) and further in view of “What is Integration Testing? A comprehensive Guide,” by Pritpal Singh, March 21, 2024, (hereinafter: Testing).
Regarding Claim 1, Lanford et al., teaches a business process infrastructure container system, wherein the system comprises:
one or more process infrastructure modules that comprise software components configured to perform a user-desired operation on a client platform. (Paragraph(s) 0013, 0021, and 0023)(Lanford et al. teaches a computing cluster (e.g., client platform) that includes an operator configuration module (e.g., one or more business process infrastructure modules). The operator configuration module can receive a commend (e.g., software component) from a user to deploy a target operator defined package (e.g., perform a user-desired operation))
wherein each of the one or more process infrastructure modules corresponds to a respective software component. (Paragraph 0024)(Lanford et al. teaches an operator configuration module (e.g., one or more business process infrastructure modules), which the operator configuration module receives a command (e.g., software component) and the operator configuration module can execute an automated installation process)
a manifest file, wherein the manifest file comprises details of one or more process infrastructure modules. (Paragraph(s) 0014 and 0026)(Lanford et al. teaches an operator configuration module (e.g., one or more business process infrastructure modules) can obtain a package from a local memory. The package may be a bundle format, which includes a manifest file. The manifest file can include a CluserServiceVersion (CSV file). The manifest file can define role-based access control rules (e.g., details of one or more business process infrastructure modules), dependencies, and other properties of the corresponding operator)
computer-readable instructions configured to trigger the user-desired operation via the one or more infrastructure modules and the manifest file. (Paragraph(s) 0013 and 0035-0036)(Lanford et al. teaches a user can command the system to deploy a target operator defined by a package. Lanford et al., also, teaches an automated installation process can involve deploying the target operator in the computing cluster. The operator management system can automatically trigger the deployment of the target operator in the computing clusters. The operator configuration module can automatically verify the target operator is properly deployed by accessing the manifest file of the package that the operator configuration module can automatically verify and then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. Lanford et al., also, teaches instructions can be used to perform the operations, see paragraph(s) 0044-0045)
With respect to the above limitations: while Lanford et al. teaches a system for deploying an application based on certain modules and a manifest YAML file. However, Lanford et al., doesn’t explicitly teach software components are integrated by implementing multiple process infrastructure modules, which each one or more process infrastructure modules is deployable and combinable with another process infrastructure module. Lanford et al., also, doesn’t explicitly teach validating software components that are integrated together to check for compatibility. If the software components failed the validation then the software developer will debug the software component.
But, Wang in the analogous art of software microservice management, teaches the software components are integrated by implementing multiple process infrastructure modules within the process infrastructure container system, wherein each of the one or more process infrastructure modules is deployable and combinable with another process infrastructure module. (Page 2, “The present invention provides a microservice…,” “The micro-service management system oriented to technical…,”); (Page 5, “The microservice deployment module…,” “The functions of the microservice…,” “Specifically, the microservice…,” and “The microservice orchestration module”); (Page 6, “Specifically, the microservice orchestration module 14 pulls…,); and (Page 7, “Further, the microservice deployment module 13 packages…,)(Wang teaches a business management system. The system includes a microservice deployment module that packages code (e.g., software components). The code of the microservice is containerized (e.g., integrated) so that the microservice can be isolated in its own container to move and run consistently in any environment and on any infrastructure. The microservice deployment module will then generate a deployment configuration file and automatically deploy (e.g., deployable) the containerized microservice to the cloud through the file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al., by incorporating the teachings of a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the efficiency of the microservice. (Wang: Page 1, “Purpose, the main microservice management system…,”; and Page 3, “According to the technical resource sharing-oriented…,”)
With respect to the above limitations: while Wang teaches software components are integrated by implementing multiple process infrastructure modules, which each one or more process infrastructure modules is deployable and combinable with another process infrastructure module. However, Lanford et al. and Wang, do not explicitly teach validating software components that are integrated together to check for compatibility. If the software components failed the validation then the software developer will debug the software component.
But, Testing in the analogous art of software, teaches validation is performed on software components that are integrated together to check for compatibility for integrated software components wherein a failed validation is addressed by a to debug a software component that has failed validation. (Page 8, “Executing Integration Tests,”); (Page 11, “Integration Testing,”); (Page 14, “Integration Testing in different Context,”); and (Page 18, “Developers are notified,”)(Testing teaches a process of executing integration test. The test environment includes software. The system will integrate the software modules to be tested and then run the test cases and record the results, including any discrepancies or issues found (e.g., validation is performed on software components that are integrated together to check for compatibility for integrated software components). The system will then debug, fix the identified discrepancies or issues found (e.g., failed validation is addressed by a to debug a software component), and then software will be retested to ensure the software issues have been resolved. Testing, further, teaches the integration testing focuses on verifying the modules or components of a software application interact and communicate effectively. Testing, also, teaches developers are notified immediately of failed tests allowing them to address the issues)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al. and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the software products integrity, reliability, compatibility, and user experience. (Testing: Page 3: “Here are a few software products/SaaS that have benefited from integration testing.,”)
Regarding Claim 2, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 1 and wherein the manifest file comprises a YAML file. (Paragraph 0004)(Lanford et al. teaches the manifest files can be YAML files)
Regarding Claim 5, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 2 and wherein the YAML file comprises configurable inputs to deploy the container system on a new platform. (Paragraph(s) 0004, 0026, and 0036-0037)(Lanford et al. teaches the manifest files can be YAML files. Lanford et al., also, teaches that the manifest file contains dependencies and other properties of the corresponding operator. The system can also access a manifest file of the package, such as the CSV file. The manifest file can indicate a namespace scope for the target operator. The operator configuration module can then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. The operator configuration module can configure an installation policy for the target operator to prevent the operator management system from deploying another version of the target operator that is different from the particular version of the target operator defined in the package)
Regarding Claim 7, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 1 and wherein the one or more process infrastructure modules comprise an automation module, commands, dashboards, webhooks, or combinations thereof. (Paragraph 0024)(Lanford et al. teaches an operator configuration module (e.g., one or more business process infrastructure modules), which the operator configuration module receives a command and the operator configuration module can execute an automated installation process (e.g., automation module). Examiner, respectfully, notes that based on BRI the claim limitations merely require one or the modules from the above list)
Regarding Claim 20, Lanford et al./Wang/Testing, teaches a method for implementing a business process for a client platform, the method comprising:
Receiving inputs from a user of the client platform corresponding to a desired operation to be performed on the platform. (See, relevant rejection of Claim 1(a))
packaging a process infrastructure container system to perform the desired operation, wherein the process infrastructure container system comprises one or more process infrastructure modules and a corresponding manifest file with associated details of the process infrastructure modules. (See, relevant rejection of Claim 1(b))
wherein each of the one or more process infrastructure modules corresponds to a respective software component and the software components are integrated by implementing multiple process infrastructure modules within the process infrastructure container system, wherein each of the one or more process infrastructure modules is deployable and combinable with another process infrastructure module. (See, relevant rejection of Claim 1(c))
validation is performed on software components that are integrated together to check for compatibility for integrated software components wherein a failed validation is addressed by a software developer to debug a software component that has failed validation. (See, relevant rejection of Claim 1(d))
Deploying the packaged process infrastructure container system on the client platform. (See, relevant rejection of Claim 1(c and -e-f))
Claim(s) 3, 8-9, 11, 16, 18-19, and 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lanford et al. (US 2022/0357938 A1) in view of Wang (CN-115964185-A) and further in view of What is Integration Testing? A comprehensive Guide,” by Pritpal Singh, March 21, 2024, (hereinafter: Testing) and further in view of Taylor et al. (US 7,941,798 B2).
Regarding Claim 3, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 2.
However, Lanford et al./Wang/Testing, doesn’t explicitly teach wherein the YAML file comprises name description, access permissions, or combinations thereof for one or more business process infrastructure modules.
But, Taylor et al. in the analogous art of software application, wherein the YAML file comprises name description, access permissions, or combinations thereof for one or more business process infrastructure modules. (Column 7, Lines 24-47)(Taylor teaches a manifest file that includes a name and a description. Examiner, respectfully, notes that based on BRI only one of the above things from the list are required)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of an YAML file including names and descriptions of Taylor et al., with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the flexibility of customer relationship management systems. (Taylor et al.: Column 1, Lines 23-35)
Regarding Claim 8, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 7.
However, Lanford et al./Wang/Testing, doesn’t explicitly teach wherein the user is configured to select one or more infrastructure modules based upon the user-desired operation.
But, Taylor et al. in the analogous art of software application, wherein the user is configured to select one or more infrastructure modules based upon the user-desired operation. (Column 6, Lines 45-67) and (Column 7, Lines 1-8)(Taylor et al. teaches using a user interface an administrator module may include a module loader module that can be selected by an module loader tab. Taylor et al., also, teaches the module loading includes a manifest file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses modules for performing business operations of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of selecting via a user interface a module of Taylor et al., with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the flexibility of customer relationship management systems. (Taylor et al.: Column 1, Lines 23-35)
Regarding Claim 9, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 1.
However, Lanford et al./Wang, doesn’t explicitly teach wherein a plurality of infrastructure modules is available to the user via a process infrastructure platform.
But, Taylor et al. in the analogous art of software application, herein a plurality of infrastructure modules is available to the user via a process infrastructure platform. (Column 2, Lines 56-67) and (Column 3, Lines 1-28)(Taylor et al. teaches a system that has one or more modules that are components of application functionality and provide certain functionality. The modules of the CRM system may include, by way of example, a portal module, a calendar module, an activities module, a contacts module, an accounts module, a leads module, an opportunities module, a quotes module, a products module, a cases module, a bug tracker module, a documents module, an emails module, a campaigns module, a project module, an RSS module, a forecasts module, a reports module and a dashboard module. Each of these modules provides a different functionality to the system so that, for example, the calendar module provides a calendaring functionality to the CRM system that is instantiated with the system)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses modules for performing business operations of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of a system that includes multiple modules of Taylor et al., with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the flexibility of customer relationship management systems. (Taylor et al.: Column 1, Lines 23-35)
Regarding Claim 11, Lanford et al., teaches a process infrastructure platform, wherein the platform comprises:
a user interface configured to receive inputs form a user to package a process infrastructure container system, wherein the process infrastructure container system is configured to perform a desired operation for the user.(Paragraph 0024)(Lanford et al. teaches a client device is used to issue a command for installing a target operator (e.g., perform a desired operation for the user in the computing cluster. The client device can include a desktop, laptop, tablet, and/or mobile telephone (e.g., user interface))
one or more process infrastructure modules that comprise software components, wherein each of the one or more process infrastructure modules corresponds to a respective software component. (Paragraph(s) 0013, 0021, and 0023-0024)(Lanford et al. teaches a computing cluster (e.g., client platform) that includes an operator configuration module (e.g., one or more business process infrastructure modules). The operator configuration module can receive a command (e.g., software component) from a user to deploy a target operator defined package (e.g., perform a user-desired operation). Lanford et al., also, teaches the operator configuration module can execute an automated installation process))
a manifest file, wherein the manifest file comprises details of one or more infrastructure modules. (Paragraph(s) 0014 and 0026)(Lanford et al. teaches an operator configuration module (e.g., one or more business process infrastructure modules) can obtain a package from a local memory. The package may be a bundle format, which includes a manifest file. The manifest file can include a CluserServiceVersion (CSV file). The manifest file can define role-based access control rules (e.g., details of one or more business process infrastructure modules), dependencies, and other properties of the corresponding operator)
computer-readable instructions configured to trigger the user-desired operation via one or more infrastructure modules and the manifest file. (Paragraph(s) 0013 and 0035-0036)(Lanford et al. teaches a user can command the system to deploy a target operator defined by a package. Lanford et al., also, teaches an automated installation process can involve deploying the target operator in the computing cluster. The operator management system can automatically trigger the deployment of the target operator in the computing clusters. The operator configuration module can automatically verify the target operator is properly deployed by accessing the manifest file of the package that the operator configuration module can automatically verify and then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. Lanford et al., also, teaches instructions can be used to perform the operations, see paragraph(s) 0044-0045)
package the selected modules with the manifest file in a process infrastructure container system based on the inputs. (Paragraph 0026)(Lanford et al. teaches that the package information is bundled, which includes a manifest file and a metadata file. The manifest file can include a CSV file, role-based access control rules, dependencies, and other properties of the corresponding operator (e.g., package the selected modules with the manifest file).
With respect to the above limitations: while Lanford et al. teaches a system for deploying an application based on certain modules and a manifest YAML file. However, Lanford et al., doesn’t explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file. Lanford et al., also, doesn’t explicitly teach software components are integrated by implementing multiple process infrastructure modules, which each one or more process infrastructure modules is deployable and combinable with another process infrastructure module. Landford et al., also, doesn’t explicitly teach validating software components for compatibility, and if that compatibility test fails then the failed validation is addressed by a software developer to debug the software component.
But, Wang in the analogous art of software microservice management, teaches the software components are integrated by implementing multiple process infrastructure modules within the process infrastructure container system, wherein each of the one or more process infrastructure modules is deployable and combinable with another process infrastructure module. (Page 2, “The present invention provides a microservice…,” “The micro-service management system oriented to technical…,”); (Page 5, “The microservice deployment module…,” “The functions of the microservice…,” “Specifically, the microservice…,” and “The microservice orchestration module”); (Page 6, “Specifically, the microservice orchestration module 14 pulls…,); and (Page 7, “Further, the microservice deployment module 13 packages…,)(Wang teaches a business management system. The system includes a microservice deployment module that packages code (e.g., software components). The code of the microservice is containerized (e.g., integrated) so that the microservice can be isolated in its own container to move and run consistently in any environment and on any infrastructure. The microservice deployment module will then generate a deployment configuration file and automatically deploy (e.g., deployable) the containerized microservice to the cloud through the file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al., by incorporating the teachings of a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the efficiency of the microservice. (Wang: Page 1, “Purpose, the main microservice management system…,”; and Page 3, “According to the technical resource sharing-oriented…,”)
With respect to the above limitations: while Wang et al. teaches a business management system. The system can containerize the code, which the code will be packaged and deployed. However, Lanford et al. and Wang, doesn’t explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file. Lanford et al./Wang, also, do not explicitly teach validating software components for compatibility, and if that compatibility test fails then the failed validation is addressed by a software developer to debug the software component.
But, Testing in the analogous art of software, teaches validation is performed on software components that are integrated together to check for compatibility for integrated software components wherein a failed validation is addressed by a to debug a software component that has failed validation. (Page 8, “Executing Integration Tests,”); (Page 11, “Integration Testing,”); (Page 14, “Integration Testing in different Context,”); and (Page 18, “Developers are notified,”)(Testing teaches a process of executing integration test. The test environment includes software. The system will integrate the software modules to be tested and then run the test cases and record the results, including any discrepancies or issues found (e.g., validation is performed on software components that are integrated together to check for compatibility for integrated software components). The system will then debug, fix the identified discrepancies or issues found (e.g., failed validation is addressed by a to debug a software component), and then software will be retested to ensure the software issues have been resolved. Testing, further, teaches the integration testing focuses on verifying the modules or components of a software application interact and communicate effectively. Testing, also, teaches developers are notified immediately of failed tests allowing them to address the issues)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al. and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the software products integrity, reliability, compatibility, and user experience. (Testing: Page 3: “Here are a few software products/SaaS that have benefited from integration testing.,”)
With respect to the above limitations: while Testing teaches determining if the software components have issues and if the software integrating test detects there are issues with compatibility then the software will be debugged. The debugging can take place by a developer. However, Lanford et al., Wang, and Testing, do not explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file.
But, Taylor et al. in the analogous art of software application, wherein the platform is configured to select one or more process infrastructure modules. (Column 6, Lines 45-67) and (Column 7, Lines 1-8)(Taylor et al. teaches using a user interface an administrator module may include a module loader module that can be selected by an module loader tab. Taylor et al., also, teaches the module loading includes a manifest file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses modules for performing business operations of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of selecting via a user interface a module of Taylor et al., with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the flexibility of customer relationship management systems. (Taylor et al.: Column 1, Lines 23-35)
Regarding Claim 16, Lanford et al., teaches a process infrastructure platform, wherein the platform comprises:
A memory storing one or more processor-executable routines. (Paragraph(s) 0043-0044)(Lanford et al. teaches a memory that stores instructions)
A processor communicatively coupled to the memory, the process configured to execute one or more processor-executable routines to: (Paragraph(s) 0043-0044)(Lanford et al. teaches a processor that can execute instructions stored in a memory)
receive inputs from a user to package a process infrastructure container system, wherein the process infrastructure container system is configured to perform a desired operation for the user. (Paragraph 0024)(Lanford et al. teaches a client device is used to issue a command for installing a target operator (e.g., perform a desired operation for the user in the computing cluster. The client device can include a desktop, laptop, tablet, and/or mobile telephone (e.g., user interface))
(Paragraph(s) 0002 and 0026)(Lanford et al. teaches a container system can includes a manifest file)
wherein the manifest file comprises a YAML file and the process infrastructure modules comprise computer-readable instructions configured to trigger the desired operation. (Paragraph(s) 0004, 0013, and 0035-0036)(Lanford et al. teaches a user can command the system to deploy a target operator defined by a package. Lanford et al., also, teaches an automated installation process can involve deploying the target operator in the computing cluster. The operator management system can automatically trigger the deployment of the target operator in the computing clusters. The operator configuration module can automatically verify the target operator is properly deployed by accessing the manifest file of the package that the operator configuration module can automatically verify and then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. Lanford et al., also, teaches instructions can be used to perform the operations, see paragraph(s) 0044-0045. Lanford et al., also, teaches the manifest files include YAML files, see paragraph 0004)
With respect to the above limitations: while Lanford et al. teaches a system for deploying an application based on certain modules and a manifest YAML file. However, Lanford et al., doesn’t explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file. Lanford et al., also, doesn’t explicitly teach software components are integrated by implementing multiple process infrastructure modules, which each one or more process infrastructure modules is deployable and combinable with another process infrastructure module. Lanford et al., also, doesn’t explicitly teach validating software components for compatibility, and if that compatibility test fails then the failed validation is addressed by a software developer to debug the software component.
But, Wang in the analogous art of software microservice management, teaches the software components are integrated by implementing multiple process infrastructure modules within the process infrastructure container system, wherein each of the one or more process infrastructure modules is deployable and combinable with another process infrastructure module. (Page 2, “The present invention provides a microservice…,” “The micro-service management system oriented to technical…,”); (Page 5, “The microservice deployment module…,” “The functions of the microservice…,” “Specifically, the microservice…,” and “The microservice orchestration module”); (Page 6, “Specifically, the microservice orchestration module 14 pulls…,); and (Page 7, “Further, the microservice deployment module 13 packages…,)(Wang teaches a business management system. The system includes a microservice deployment module that packages code (e.g., software components). The code of the microservice is containerized (e.g., integrated) so that the microservice can be isolated in its own container to move and run consistently in any environment and on any infrastructure. The microservice deployment module will then generate a deployment configuration file and automatically deploy (e.g., deployable) the containerized microservice to the cloud through the file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al., by incorporating the teachings of a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the efficiency of the microservice. (Wang: Page 1, “Purpose, the main microservice management system…,”; and Page 3, “According to the technical resource sharing-oriented…,”)
With respect to the above limitations: while Wang teaches a business management system, which the system can containerize the code and deploy the code. However, Lanford et al. and Wang, doesn’t explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file software components are integrated by implementing multiple process. Lanford et al. and Wang, also, do not explicitly tach validating software components for compatibility, and if that compatibility test fails then the failed validation is addressed by a software developer to debug the software component.
But, Testing in the analogous art of software, teaches validation is performed on software components that are integrated together to check for compatibility for integrated software components wherein a failed validation is addressed by a software developer to debug a software component that has failed validation. (Page 8, “Executing Integration Tests,”); (Page 11, “Integration Testing,”); (Page 14, “Integration Testing in different Context,”); and (Page 18, “Developers are notified,”)(Testing teaches a process of executing integration test. The test environment includes software. The system will integrate the software modules to be tested and then run the test cases and record the results, including any discrepancies or issues found (e.g., validation is performed on software components that are integrated together to check for compatibility for integrated software components). The system will then debug, fix the identified discrepancies or issues found (e.g., failed validation is addressed by a to debug a software component), and then software will be retested to ensure the software issues have been resolved. Testing, further, teaches the integration testing focuses on verifying the modules or components of a software application interact and communicate effectively. Testing, also, teaches developers are notified immediately of failed tests allowing them to address the issues)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al. and a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, by incorporating the teachings of a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the software products integrity, reliability, compatibility, and user experience. (Testing: Page 3: “Here are a few software products/SaaS that have benefited from integration testing.,”)
With respect to the above limitations: while Testing teaches determining if the software components have issues and if the software integrating test detects there are issues with compatibility then the software will be debugged. The debugging can take place by a developer. However, Lanford et al., Wang, and Testing, do not explicitly teach selecting one or more modules based on the inputs and package the selected modules with an associated manifest file.
But, Taylor et al. in the analogous art of software application, select one or more business process infrastructure modules based upon the inputs and package the selected modules. (Column 6, Lines 45-67) and (Column 7, Lines 1-8)(Taylor et al. teaches using a user interface an administrator module may include a module loader module that can be selected by an module loader tab. Also, teaches the module loading includes a manifest file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses modules for performing business operations of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of selecting via a user interface a module of Taylor et al., with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve the flexibility of customer relationship management systems. (Taylor et al.: Column 1, Lines 23-35)
Regarding Claim 18, Lanford et al./Wang/Testing/Taylor et al., teaches all the limitations as applied to Claim 16 and wherein the YAML file comprises name description, access permissions, or combinations thereof for one or more process infrastructure modules. (See, the relevant rejection(s) of Claim(s) 3 and 16)
Regarding Claim 19, Lanford et al./Wang/Testing/Taylor et al., teaches all the limitations as applied to Claim 18 and wherein the YAML file further comprises details of connections between one or more infrastructure modules. (See, the relevant rejection(s) of Claim(s) 4 and 16)
Regarding Claim 21, Lanford et al./Wang/Testing/Taylor et al., teaches all the limitation’s as applied to Claim 20 and wherein one or more process infrastructure modules comprise computer-readable instructions configured to trigger the desired operation on the client platform. Paragraph(s) 0013 and 0035-0036)(Lanford et al. teaches a user can command the system to deploy a target operator defined by a package. Lanford et al., also, teaches an automated installation process can involve deploying the target operator in the computing cluster. The operator management system can automatically trigger the deployment of the target operator in the computing clusters. The operator configuration module can automatically verify the target operator is properly deployed by accessing the manifest file of the package that the operator configuration module can automatically verify and then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. Lanford et al., also, teaches instructions can be used to perform the operations, see paragraph(s) 0044-0045)
Regarding Claim 22, Lanford et al./Wang/Testing/Taylor et al., teaches all the limitations as applied to Claim 20 and wherein the manifest file comprises a YAML file. (See, the relevant rejection(s) of Claim(s) 2 and 16)
Regarding Claim 23, Lanford et al./Wang/Testing/Taylor et al., teaches all the limitations as applied to Claim 20 and wherein the method further comprises managing and distributing the packaged process infrastructure container system to a plurality of users. (Paragraph 0004)(Lanford et al. teaches the Kubernetes are designed to assist users in installing, updating, and managing the lifecycles of operators in the Kubernetes environment. The OLM has a user interface through which users can select operators for deployment and mange updates. The OLM can deploy the operators based on the manifest files defining properties of the operators on the user interfaces)
Claim 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lanford et al. (US 2022/0357938 A1) in view of Wang (CN-115964185-A) and “What is Integration Testing? A comprehensive Guide,” by Pritpal Singh, March 21, 2024, (hereinafter: Testing), as applied to Claim 2, and further in view of Duplys (US 2024/0104191 A1)(Foreign Application filed September 28, 2022).
Regarding Claim 4, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 2.
However, Lanford et al./Wang/Testing, doesn’t explicitly teach wherein the YAML file comprises details of connections between one or more process infrastructure modules.
But, Duplys in the analogous art of manifest files, teaches wherein the YAML file comprises details of connections between one or more process infrastructure modules. (Paragraph 0082)(Duplys teaches a manifest file, which the manifest file includes a YAML or JSON file. The manifest file includes outgoing connections and if such connections are used (e.g., details of connections))
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that uses a YAML manifest file of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of a YAML file that includes connections that are used of Duplys, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to improve security. (Duplys: Paragraph(s) 0003-0005)
Claim 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lanford et al. (US 2022/0357938 A1) in view of Wang (CN-115964185-A) and “What is Integration Testing? A comprehensive Guide,” by Pritpal Singh, March 21, 2024, (hereinafter: Testing), as applied to Claim 1, further in view of Zarn (US 2015/0339330 A1) .
Regarding Claim 6, Lanford et al./Wang/Testing, teaches all the limitations as applied to Claim 1.
However, Lanford et al./Wang/Testing, doesn’t explicitly teach wherein the system is configured to receive the computer-readable instructions via Typescript or JavaScript programming language.
But, Zarn in the analogous art of manifest file deployment, teaches wherein the system is configured to receive the computer-readable instructions via Typescript or JavaScript programming language. (Paragraph(s) 0020-0021, 0030-0031, and 0045)(Zarn teaches a processer and/or server can transmit, receive, and store the one or more versions of the metadata file, which the metadata file is a JS (e.g., JavaScript) manifest file)
It would have been prima facia obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a business infrastructure that has a manifest file that uses YAML and JSON of Lanford et al., a business management system. The system can containerize the code, which the code will be packaged and deployed of Wang, and a test environment that test the software integration with software modules to determine if the software has issues. If the software has issues then the system will then debug the software of Testing, by incorporating the teachings of a system that uses JavaScript for a manifest file of Zarn, with the motivation in the prior art that would have led one of ordinary skill to combine the prior art reference teachings to help migrate user traffic from one release of content to another in a controlled manner. (Zarn: Paragraph 0003)
Novelty/Non-Obviousness
For the reasons outlined below, Dependent Claim(s) 10, 12-15, and 17, are distinguished from the art.
Lanford et al. (US 2022/0357938 A1). Lanford et al. teaches a computing cluster that includes an operator configuration module. The operator configuration module can receive a commend from a user to deploy a target operator defined package. Lanford et al., also, teaches an operator configuration module can obtain a package from a local memory. The package may be a bundle format, which includes a manifest file. The manifest file can include a CluserServiceVersion. The manifest file can define role-based access control rules, dependencies, and other properties of the corresponding operator. Lanford et al., also, teaches a user can command the system to deploy a target operator defined by a package. Lanford et al., also, teaches an automated installation process can involve deploying the target operator in the computing cluster. The operator management system can automatically trigger the deployment of the target operator in the computing clusters. The operator configuration module can automatically verify the target operator is properly deployed by accessing the manifest file of the package that the operator configuration module can automatically verify and then transmit one or more communications to the APIs for determining whether the instance of the target operator is deployed in the computing cluster with the namespace scope specified in the manifest file . The APIs can respond to the communication by indicating to the operator configuration module whether the instance of the target operator is deployed in the computing cluster and its namespace scope. Lanford et al., also, teaches instructions can be used to perform the operations.
But, it would not be obvious to modify Lanford et al., Wang, Testing, Taylor, and Sadiq, because the limitation(s) of wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. When Lanford et al. teaches a microservice module that generates a deployment configuration file and automatically deploys the containerized microservice file. But, Wang, fails to teach wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. Thus, while different references teach different portions of the limitation it would not be obvious to combine by piecemealing the references to teach applicant’s claim limitation(s).
Wang (CN-115964185-A). Wang teaches a business management system. The system includes a microservice deployment module that packages code. The code of the microservice is containerized so that the microservice can be isolated in its own container to move and run consistently in any environment and on any infrastructure. The microservice deployment module will then generate a deployment configuration file and automatically deploy the containerized microservice to the cloud through the file.
But, it would not be obvious to modify Wang, Lanford et al., Taylor, Testing, and Sadiq, because the limitation(s) of wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. When Wang teaches a microservice module that generates a deployment configuration file and automatically deploys the containerized microservice file. But, Wang, fails to teach wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. Thus, while different references teach different portions of the limitation it would not be obvious to combine by piecemealing the references to teach applicant’s claim limitation(s).
Taylor et al. (US 7,941,798 B2). Taylor et al. teaches using a user interface an administrator module may include a module loader module that can be selected by an module loader tab. Taylor, also, teaches the module loading includes a manifest file.
But, it would not be obvious to modify Taylor et al., Lanford et al., Wang, Testing, and Sadiq, because the limitation(s) of wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. When Taylor et al. teaches loading a manifest file to the software. But, Taylor et al., fails to teach wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. Thus, while different references teach different portions of the limitation it would not be obvious to combine by piecemealing the references to teach applicant’s claim limitation(s).
“What is Integration Testing? A comprehensive Guide,” by Pritpal Singh, March 21, 2024, (hereinafter: Testing). Testing teaches a process of executing integration test. The test environment includes software. The system will integrate the software modules to be tested and then run the test cases and record the results, including any discrepancies or issues found (e.g., validation is performed on software components that are integrated together to check for compatibility for integrated software components). The system will then debug, fix the identified discrepancies or issues found (e.g., failed validation is addressed by a to debug a software component), and then software will be retested to ensure the software issues have been resolved. Testing, further, teaches the integration testing focuses on verifying the modules or components of a software application interact and communicate effectively. Testing, also, teaches developers are notified immediately of failed tests allowing them to address the issues.
But, it would not be obvious to modify Testing, Lanford et al., Wang, Taylor et al., and Sadiq, because the limitation(s) of wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. When Testing teaches validating the software based on integration testing and detecting issues with the components. The system can then debug the software. But, Testing, fails to teach wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. Thus, while different references teach different portions of the limitation it would not be obvious to combine by piecemealing the references to teach applicant’s claim limitation(s).
Sadiq (US 2004/0148184 A1). Sadiq teaches a business service is configured with a new infrastructure service, which the composer tool an modify the metadata and copies the package contents for the new infrastructure service into the appropriate directories. Sadiq, further, teaches a new version of the infrastructure service can be made available, which the composer tool copies the new package to the appropriate hosts and the binaries are copied to the appropriate directories and the business service is informed that then loads the package for that service. Sadiq, also, teaches that the packages include software modules. Sadiq, also, teaches the system architects can use the composer tool to slowly transition the deployed business services as the infrastructure services change. Sadiq, also, teaches that the system architects can use the composer tool to slowly transition the deployed business services as the infrastructure services change. The system can transition an old or obsolete module to a new module by simply removing the old plug from the business service and using drag-and-drop to configure the business service with the new plug. The system can automatically remove the older plugs and deploy a new plug for the module. The system architects can use the composer tool to slowly transition the deployed business services as the infrastructure services change. The system can transition an old or obsolete module to a new module by simply removing the old plug from the business service and using drag-and-drop to configure the business service with the new plug. The system can automatically remove the older plugs and deploy a new plug for the module. The system can transition an old or obsolete module to a new module by simply removing the old plug from the business service and using drag-and-drop to configure the business service with the new plug. The system can automatically remove the older plugs and deploy a new plug for the module.
But, it would not be obvious to modify Sadiq, Lanford et al., Wang, Taylor et al., and Testing, because the limitation(s) of wherein the plurality of infrastructure modules is automatically updated upon release of a new version of the respective infrastructure module on the business process infrastructure platform. The system will detect a version change of one or more process infrastructure modules and automatically creates and/or updates resources and processes the computer -readable instructions to update one or more process infrastructure modules. The platform can manage distribution and customization of the process infrastructure container for a plurality of users, which each process infrastructure container is configurable by the user based on their requirements. The user can provide input for the deployment of the container system on the platform. While, Sadiq teaches the above limitations it would not it would not be obvious to combine by piecemealing the references to teach applicant’s claim limitation(s).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Randimbivololona et al. (US 8,650,547 B2)(hereinafter Rand). Rand teaches a method for debugging an operational software onboard program for an aircraft. The software can be debugged by a developer.
DeBoer et al. (US 2009/0293040 A1). DeBoer et al. teaches after receiving the positive feedback from a user, a Windows application verifies that the software stored and operating within the host computer is compatible with the demonstration board. The system will perform a compatibility verification, the Windows application causes the on-chip flash memory of the target microcontroller to be erased and written with a new program. The Windows application sends data to the interface software program. The interface software program forwards the received data to a target server program. The target server program translates the received data and sends corresponding control data recognizable by the integrated development environment. The control data causes the integrated development environment to load source code for compatibility verification from the memory of the host computer, build a program from the source code, and transmit the program as target data to the debug circuitry on demonstration board. The integrated development environment also sends a control signal or parameter that causes the programming processor of the debug circuitry to erase then write the program in the on-chip flash memory of the target microcontroller.
Lin (CN-108549602-A). Lin teaches software debugging. The system can run the software and set an exception flag bit and store the exception flag but. After the software is re-run and it is determined that the abnormal flag is valid then the system will access a JTAG debugger to clear the exception flag and debug the software.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN A HEFLIN whose telephone number is (571)272-3524. The examiner can normally be reached 7:30 - 5:00 M-F.
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, Jeffrey Zimmerman can be reached at (571) 272-4602. 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.
/B.A.H./Examiner, Art Unit 3628
/JEFF ZIMMERMAN/Supervisory Patent Examiner, Art Unit 3628
Prosecution Insights