DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to applicant’s amendment filed on 07/22/2026.
Claims 1-20 are pending and examined.
Response to Arguments
Applicant's arguments filed 07/22/2026 with respect to the claim objections have been fully considered and are persuasive. The claim objections for claims 7 and 17 have been withdrawn.
Applicant's arguments filed 07/22/2026 with respect to 35 U.S.C. 101 have been fully considered but they are not persuasive. Applicant argued that “the claims, as amended, integrate any alleged abstract idea into a practical application and amount to significantly more than a judicial exception” without providing any specific arguments. The examiner respectfully disagrees, see 35 U.S.C. 101 rejections below for a detailed analysis. The previously identified step of “determining relationship links between the related configuration items to create an application model” has been amended to recite “generating, by the at least one processor, an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform,” however, this limitation still presents a mental process that covers performance of the limitation in the mind. For example, a person could reasonably review dependency or association rules defined for the containerized computing platform, establish relationship links between the related configuration items, and then generate an application model. Additionally, the ‘detecting’ limitation, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. A person could reasonably look at a UI that displays the monitored information and detect at least one of an unplanned change or a version mismatch associated with the containerized computing platform. The additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept and therefore the 35 U.S.C. 101 rejections are maintained.
Applicant's arguments filed 07/22/2026 with respect to 35 U.S.C. 102 and 103 have been fully considered but they are not persuasive. Applicant argued that “As best understood, Sobrier fails to teach or suggest generating an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform,” that Sobrier fails to teach or suggest the monitoring, initiating, generating, and triggering limitations as claimed, and that “the cited references also fail to disclose, teach or suggest "establishing the relationship links between the related configuration items to create the application model further comprises parsing, by the at least one processor, the JSON string and obtaining, by the at least one processor, therefrom application data and infrastructure data" as recited in claims 5 and 15,” without providing any specific arguments with regards to claims 5 and 15. The examiner respectfully disagrees, see 35 U.S.C. 102 and 103 rejections below for a detailed analysis. Sobrier is interpreted to disclose the limitations as amended in claim 1. With regards to the “generating an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform,” Sobrier’s processed audit log or other cloud data being used to create a data model implemented as a polygraph with nodes representing logical entities and edges representing behavioral relationships between nodes correlates to generating, by the at least one processor, an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform.
With regards to the newly amended monitoring, initiating, generating, and triggering limitations of claim 1, Sobrier is interpreted to disclose the limitations. For example, the data analysis service using the data model to monitor for security issues such as a new role binding being created correlates to continuously monitoring, by the at least one processor, the containerized computing platform using the application model to detect changes in the configuration attributes or relationships between the related configuration items. The data analysis service using the data model to detect anomalies such as a new role binding being created correlates to detecting, by the at least one processor, based on the monitoring, at least one of an unplanned change associated with the containerized computing platform.
The policies being used in various types of data models such as polygraphs to identify security issues, generate an alert, and automatically apply a remediation correlates to initiating, by the at least one processor, in response to detecting the at least one of the unplanned change or the version mismatch, an automated remedial action. The control plane detecting and responding to cluster events, which can include detected new cluster roles as a security issue, through one or more API servers correlates to generating a change request via the API. The policies being used in various types of data models such as polygraphs to automatically apply a remediation correlates to triggering, by the at least one processor, execution of a deployment or testing workflow to modify the containerized computing platform to reduce or eliminate the detected unplanned change or version mismatch.
With regards to claims 5 and 15, Sobrier alone is not interpreted to disclose the entirety of the claim. Sobrier’s audit log data and other cloud data being ingested by the data ingestion service through unpacking, buffering, processing, and preparation correlates to parsing the data and obtaining application and infrastructure data. While Sobrier does not explicitly teach that the data is a JSON string, JSON strings are a popular data format as evidenced by Gonczi’s message initially being a clear text format such as JSON format. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with Gonczi because compression provides numerous benefits to the system including improved network performance and strengthened encryption. When messages are compressed, less data is sent on the queues and therefore faster response times may be achieved. For example, where a message contains a JSON format, there is a repetitive syntax which generally includes a lot of white space for readability purposes. Compression generally reduces the size of such objects by removing or condensing the white space, where the more complex the object, the greater the return on compression.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 10 recites the limitation "the processor" in “automatically performing, by the processor, a test to determine if the API call has attenuated the differences between the reference model and the application model.” There is insufficient antecedent basis for this limitation in the claim as the term “the processor” is not referenced either earlier in claim 10 or in claim 1, and it is unclear whether “the processor” is the same as the “at least one processor” of claim 1.
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 use the word “means” or “step” and being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Such claim limitation(s) is/are: “means to access/decode/parse/determine…” in claim 20.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claims 1, 11, and 20 recite:
A computer-implemented method, comprising:
accessing, by at least one processor, a first resource from a containerized computing platform via an application programming interface (API);
decoding, by the at least one processor, the first resource into structured metadata comprising configuration attributes of the first resource;
parsing, by the at least one processor, the structured metadata into a plurality of related configuration items based on the configuration attributes;and
generating, by the at least one processor, an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform;
continuously monitoring, by the at least one processor, the containerized computing platform using the application model to detect changes in the configuration attributes or relationships between the related configuration items;
detecting, by the at least one processor, based on the monitoring, at least one of an unplanned change or a version mismatch associated with the containerized computing platform; and
initiating, by the at least one processor, in response to detecting the at least one of the unplanned change or the version mismatch, an automated remedial action, including
generating a change request via the API and
triggering, by the at least one processor, execution of a deployment or testing workflow to modify the containerized computing platform to reduce or eliminate the detected unplanned change or version mismatch.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 1 is a process.
Claim 11 is a machine.
Claim 20 is a machine.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘generating’ limitation in #4 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “generating” in the context of this claim encompasses a person analyzing, evaluating, or generating an application model by establishing relationship links between the related configuration items, including comparison or judgement.
The ‘detecting’ limitation in #6 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “detecting” in the context of this claim encompasses a person analyzing, evaluating, or detecting at least one of an unplanned change or a version mismatch associated with the containerized computing platform based on the monitoring, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘accessing’ limitation in #1 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “accessing” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The ‘decoding’ limitation in #2 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “decoding” in the context of this claim encompasses merely decoding the first resource into structured metadata. See MPEP 2106.05(f).
The ‘parsing’ limitation in #3 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “parsing” in the context of this claim encompasses merely parsing the structured metadata into a plurality of related configuration items. See MPEP 2106.05(f).
The ‘monitoring’ limitation in #5 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “monitoring” in the context of this claim encompasses merely monitoring information in memory. See MPEP 2106.05(g).
The ‘initiating’ limitation in #7 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “initiating” in the context of this claim encompasses merely initiating an automated remedial action. See MPEP 2106.05(f).
The ‘generating’ limitation in #8 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “generating” in the context of this claim encompasses merely generating a change request via the API. See MPEP 2106.05(f).
The ‘triggering’ limitation in #9 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “triggering” in the context of this claim encompasses merely triggering execution of a deployment or testing workflow. See MPEP 2106.05(f).
Additionally, one or more of the claims recite the following additional elements:
At least one processor (Claim 11)
Computer memory (Claim 11)
Instructions (Claim 11)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than components comprising mere instructions to apply the exception. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract ideas(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Claims 7 and 17 merely further describe the containerized platform of Claims 1 and 11 respectively. The claims do not include additional elements that integrate into practical application or are sufficient to amount to significantly more than the judicial exception.
Therefore, Claims 1, 7, 11, 17 and 20 are directed to (an) abstract idea(s) without significantly more.
Claims 2 and 12 recite:
wherein accessing, by the at least one processor, the first resource from the containerized computing platform comprises
Obtaining, by the at least one processor, a listing of Helm secrets returned by querying the first resource from the containerized computing platform with filters, the filters comprising "type=helm.sh/release.v1" and "status=deployed".
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 2 is a process.
Claim 12 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘obtaining’ limitation in #10 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “obtaining” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 2 and 12 are directed to (an) abstract idea(s) without significantly more.
Claims 3 and 13 recite:
wherein decoding, by the at least one processor, the first resource into structured metadata comprises
decoding, by the at least one processor, the first resource utilizing a decoding library provided with the first resource and
obtaining, by the at least one processor, as an output from the decoding library, compressed binary metadata.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 3 is a process.
Claim 13 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘decoding’ limitation in #11 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “decoding” in the context of this claim encompasses merely decoding the first resource using a decoding library. See MPEP 2106.05(f).
The ‘obtaining’ limitation in #12 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “obtaining” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 3 and 13 are directed to (an) abstract idea(s) without significantly more.
Claims 4 and 14 recite:
decompressing, by the at least one processor, the compressed binary metadata with a decompression library and
receiving, by the at least one processor, therefrom a JavaScript Object Notation string (JSON string).
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 4 is a process.
Claim 14 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘decompressing’ limitation in #13 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “decompressing” in the context of this claim encompasses merely decompressing the compressed binary metadata using a library. See MPEP 2106.05(f).
The ‘receiving’ limitation in #14 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “receiving” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 4 and 14 are directed to (an) abstract idea(s) without significantly more.
Claims 5 and 15 recite:
wherein establishing the relationship links between the related configuration items to create the application model further comprises
parsing, by the at least one processor, the JSON string and
obtaining, by the at least one processor, therefrom application data and infrastructure data.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 5 is a process.
Claim 15 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘parsing’ limitation in #15 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “parsing” in the context of this claim encompasses merely parsing a JSON string. See MPEP 2106.05(f).
The ‘obtaining’ limitation in #16 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element that is insignificant extra-solution activity. The limitation “obtaining” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 5 and 15 are directed to (an) abstract idea(s) without significantly more.
Claims 6 and 16 recite:
converting, by the at least one processor, the application data and the infrastructure data into configuration data and relationship links interconnecting the related configuration items.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 6 is a process.
Claim 16 is a machine.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘converting’ limitation in #17 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “converting” in the context of this claim encompasses a person analyzing, evaluating, or converting application and infrastructure data into relationship links interconnecting configuration items, including comparison or judgement.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
Therefore, Claims 6 and 16 are directed to (an) abstract idea(s) without significantly more.
Claims 8 and 18 recite:
comparing, by the at least one processor, the application model with a reference model to determine differences therebetween and,
upon the differences being non-null, performing, by the at least one processor, a restorative action.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 8 is a process.
Claim 18 is a machine.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes: (an) abstract idea(s).
The ‘comparing’ limitation in #18 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. The limitation “comparing” in the context of this claim encompasses a person analyzing, evaluating, or comparing the application and reference models to determine differences, including comparison or judgement.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘performing’ limitation in #19 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “performing” in the context of this claim encompasses performing a restorative action. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 8 and 18 are directed to (an) abstract idea(s) without significantly more.
Claims 9 and 19 recite:
wherein the restorative action comprises
initiating, by the at least one processor, an API call to the containerized computing platform to deploy a template to attenuate the differences between the reference model and the application model.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 9 is a process.
Claim 19 is a machine.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘initiating’ limitation in #20 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “initiating” in the context of this claim encompasses initiating an API call to the containerized platform. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claims 9 and 19 are directed to (an) abstract idea(s) without significantly more.
Claim 10 recites:
wherein the restorative action comprises
automatically performing, by the processor, a test to determine if the API call has attenuated the differences between the reference model and the application model and,
if successful, generating a new template release.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 10 is a process.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The ‘performing’ limitation in #21 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “performing” in the context of this claim encompasses performing a test to determine if the API call has attenuated the differences. See MPEP 2106.05(f).
The ‘generating’ limitation in #22 above, as claimed and under broadest reasonable interpretation (BRI), is an additional element as “apply it” that is mere instructions to apply an exception. The limitation “generating” in the context of this claim encompasses merely generating a new template release. See MPEP 2106.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than components for obtaining or gathering data and comprising mere instructions to apply the exception which is evidently seen in MPEP 2106.05(g)&(f). Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Therefore, Claim 10 is directed to (an) abstract idea(s) without significantly more.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 8, 11, 18 and 20 are rejected under 35 U.S.C. 102(a)(2) as being unpatentable by Sobrier et al. (U.S. Patent No. US 12425428 B1), hereinafter “Sobrier.”
With regards to Claim 1, Sobrier teaches:
A computer-implemented method, comprising:
accessing, by at least one processor, a first resource from a containerized computing platform via an application programming interface (API) (Col. 78, lines 22-24 and 37-41 and Col. 79, lines 5-12, “At operation 502, the data platform may obtain audit log data generated by a container orchestrator within a cloud compute environment… Events may be logged by the Kubernetes orchestrator (e.g., by the Kubernetes API server or another component described herein) and may be provided to the data platform by way of a webhook or other suitable communication mechanism… In both of these data model examples, the audit log data may be combined with other types of data obtained from the cloud compute environment (e.g., telemetry data collected by agents as described above, trail data, etc.) and/or combined with audit log data from multiple cloud compute environments (e.g., including cloud compute environments associated with different cloud service providers).” The audit log, telemetry, or trail data being obtained from the container orchestrator such as the Kubernetes API server within a cloud compute environment correlates to accessing, by at least one processor, a first resource from a containerized computing platform via an application programming interface (API));
decoding, by the at least one processor, the first resource into structured metadata comprising configuration attributes of the first resource (Col. 83, lines 42-57 and Col. 84, lines 50-66, “Before being used to generate a data model 526, implementation 530 illustrates another detail that was not explicitly shown in FIG. 5B: audit log data 522 and other cloud data 524-1 may be ingested by way of a data ingestion service 534. Data ingestion service 534 may be implemented within network 518, within data platform 520, or by a separate and standalone device or process. Data ingestion service 534 may implement communication protocols and be configured to arrange for the data 522 and 524 to be obtained in any suitable way (e.g., by requesting the data if necessary, by unpacking and buffering the data, by storing the data temporarily or persistently where it can be used for data modeling and other processes, etc.). As part of this ingestion process, data ingestion service 534 may also process and prepare the data (e.g., by altering the data) in various ways... Once processed by data ingestion service 534, audit log data 522 and other cloud data 524 (e.g., agent-collected data 532 implementing other cloud data 524-1 in this example) may be used for data modeling in the ways described herein. To illustrate, a data model 526-1 is shown that, as indicated by the reference number, represents a specific type of data model 526 used in this example. Specifically, as shown, data model 526-1 is implemented as a polygraph 536 (or other suitable graph described herein) that comprises a plurality of node points 537 (also referred to herein simply as “nodes”) connected by a plurality of edges 538. Each node point 537 (the shaded circles in polygraph 536) of the plurality of node points 537 may represent a logical entity, while each edge 538 (the arrows connecting the node points in polygraph 536) of the plurality of edges 538 may represent a behavioral relationship between node points 537 connected by the edge 538.” The audit log data and other cloud data being ingested by the data ingestion service through unpacking, buffering, processing, and preparation correlates to decoding the first resource into structured metadata. The processed data being used to create a polygraph with nodes representing logical entities would involve the processed data including configuration attributes related to the nodes and therefore correlates to decoding, by the at least one processor, the first resource into structured metadata comprising configuration attributes of the first resource);
parsing, by the at least one processor, the structured metadata into a plurality of related configuration items based on the configuration attributes (Col. 84, lines 50-66, “Once processed by data ingestion service 534, audit log data 522 and other cloud data 524 (e.g., agent-collected data 532 implementing other cloud data 524-1 in this example) may be used for data modeling in the ways described herein. To illustrate, a data model 526-1 is shown that, as indicated by the reference number, represents a specific type of data model 526 used in this example. Specifically, as shown, data model 526-1 is implemented as a polygraph 536 (or other suitable graph described herein) that comprises a plurality of node points 537 (also referred to herein simply as “nodes”) connected by a plurality of edges 538. Each node point 537 (the shaded circles in polygraph 536) of the plurality of node points 537 may represent a logical entity, while each edge 538 (the arrows connecting the node points in polygraph 536) of the plurality of edges 538 may represent a behavioral relationship between node points 537 connected by the edge 538.” The processed audit log or other cloud data being used to create a polygraph which identifies each node point as a logical entity correlates to parsing, by the at least one processor, the structured metadata into a plurality of related configuration items based on the configuration attributes); and
generating, by the at least one processor, an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform (Col. 84, lines 50-66, “Once processed by data ingestion service 534, audit log data 522 and other cloud data 524 (e.g., agent-collected data 532 implementing other cloud data 524-1 in this example) may be used for data modeling in the ways described herein. To illustrate, a data model 526-1 is shown that, as indicated by the reference number, represents a specific type of data model 526 used in this example. Specifically, as shown, data model 526-1 is implemented as a polygraph 536 (or other suitable graph described herein) that comprises a plurality of node points 537 (also referred to herein simply as “nodes”) connected by a plurality of edges 538. Each node point 537 (the shaded circles in polygraph 536) of the plurality of node points 537 may represent a logical entity, while each edge 538 (the arrows connecting the node points in polygraph 536) of the plurality of edges 538 may represent a behavioral relationship between node points 537 connected by the edge 538.” The processed audit log or other cloud data being used to create a data model implemented as a polygraph with nodes representing logical entities and edges representing behavioral relationships between nodes correlates to generating, by the at least one processor, an application model by establishing relationship links between the related configuration items according to dependency or association rules defined for the containerized computing platform);
continuously monitoring, by the at least one processor, the containerized computing platform using the application model to detect changes in the configuration attributes or relationships between the related configuration items (Col. 85, lines 19-28 and 36-48, “A data analysis service 540 implemented within data platform 520 (and using machine learning processes and/or other techniques described in more detail above) may use the data model 526-1 to monitor for security issues in any of the ways described herein. For example, the data analysis service 540 may use polygraph 536 to monitor for one or more anomalies 529-1 (i.e., anomalous behavior representing a specific type of security issue) that are associated with the activity occurring with respect to the one or more containerized applications… For example, anomalies 529-1 that may be detected using polygraph 536 include, without limitation, an API call from a new user, a new kubectl exec command being issued, a new cluster role binding being created (e.g., designated critical if associated with cluster-admin; designated high if associated with admin, edit, or system; and designated medium if associated with another role), a new role binding being created (e.g., designated with medium importance), a new namespace or workload being deployed (e.g., designated of low importance unless deployed to kube-system or kube-public, which may be designated high importance), a new registry or repository being used, and so forth.” The data analysis service using the data model to monitor for security issues such as a new role binding being created correlates to continuously monitoring, by the at least one processor, the containerized computing platform using the application model to detect changes in the configuration attributes or relationships between the related configuration items);
detecting, by the at least one processor, based on the monitoring, at least one of an unplanned change or a version mismatch associated with the containerized computing platform (Col. 85, lines 36-48, “For example, anomalies 529-1 that may be detected using polygraph 536 include, without limitation, an API call from a new user, a new kubectl exec command being issued, a new cluster role binding being created (e.g., designated critical if associated with cluster-admin; designated high if associated with admin, edit, or system; and designated medium if associated with another role), a new role binding being created (e.g., designated with medium importance), a new namespace or workload being deployed (e.g., designated of low importance unless deployed to kube-system or kube-public, which may be designated high importance), a new registry or repository being used, and so forth.” The data analysis service using the data model to detect anomalies such as a new role binding being created correlates to detecting, by the at least one processor, based on the monitoring, at least one of an unplanned change associated with the containerized computing platform); and
initiating, by the at least one processor, in response to detecting the at least one of the unplanned change or the version mismatch, an automated remedial action, including generating a change request via the API (Col. 85, lines 33-36, Col. 86, lines 37-43, Col. 87, lines 19-35, and Col. 94, lines 38-48, “Accordingly, when data analysis service 540 uses polygraph 536 to identify anomalies 529-1, meaningful and accurate alerts indicative of important and usefully categorized anomalies 529-1 may be produced... Data repository 554 may be configured such that a policy 558 that references one or more queries 560 may apply the queries 560 and perform an action (e.g., identify a security issue, generate an alert, suggest or automatically apply a remediation, etc.) based on query results 562 that the data repository 554 returns… Using policies such as policy 558 in this way, security issues 529 may be discovered that may complement the types of security issues 529 discovered using other types of data models (e.g., polygraph 536). For example, the machine learning analysis of polygraph 536 by data analysis service 540 may serve as a powerful tool for detecting anomalies and other issues that would be difficult to explicitly enumerate and search/monitor for, while the ability of policies 558 to query for particular conditions and perform specific actions when such conditions are identified enable this type of data modeling to serve as a powerful and complementary tool for identifying more specific vulnerabilities and threats (when such threats are well-defined and easier to monitor for). As a few non-limiting examples, policy 558 could help discover a forbidden registry, help identify a cluster role that allows access to secrets, or help detect a kubectl exec command to a privileged container… Control plane 616 may include various components configured to make global decisions about cluster 612 and to detect and respond to cluster events. For instance, components within control plane 616 may be configured to perform scheduling operations, to initiate a new pod when conditions may merit (e.g., upon request or when a deployment's replicas field is unsatisfied, etc.), and so forth. As shown, one or more API servers 640 (depending on traffic and demand from compute nodes within the cluster) may be included to directly interface with compute nodes of the data plane (as described in more detail below).” The policies being used in various types of data models such as polygraphs to identify security issues, generate an alert, and automatically apply a remediation correlates to initiating, by the at least one processor, in response to detecting the at least one of the unplanned change or the version mismatch, an automated remedial action. The control plane detecting and responding to cluster events, which can include detected new cluster roles as a security issue, through one or more API servers correlates to generating a change request via the API) and triggering, by the at least one processor, execution of a deployment or testing workflow to modify the containerized computing platform to reduce or eliminate the detected unplanned change or version mismatch (Col. 86, lines 37-43, Col. 87, lines 19-35, “Data repository 554 may be configured such that a policy 558 that references one or more queries 560 may apply the queries 560 and perform an action (e.g., identify a security issue, generate an alert, suggest or automatically apply a remediation, etc.) based on query results 562 that the data repository 554 returns… Using policies such as policy 558 in this way, security issues 529 may be discovered that may complement the types of security issues 529 discovered using other types of data models (e.g., polygraph 536). For example, the machine learning analysis of polygraph 536 by data analysis service 540 may serve as a powerful tool for detecting anomalies and other issues that would be difficult to explicitly enumerate and search/monitor for, while the ability of policies 558 to query for particular conditions and perform specific actions when such conditions are identified enable this type of data modeling to serve as a powerful and complementary tool for identifying more specific vulnerabilities and threats (when such threats are well-defined and easier to monitor for). As a few non-limiting examples, policy 558 could help discover a forbidden registry, help identify a cluster role that allows access to secrets, or help detect a kubectl exec command to a privileged container.” The policies being used in various types of data models such as polygraphs to automatically apply a remediation correlates to triggering, by the at least one processor, execution of a deployment or testing workflow to modify the containerized computing platform to reduce or eliminate the detected unplanned change or version mismatch).
With regards to Claims 11 and 20, the method of Claim 1 performs the same steps as the machines of Claims 11 and 20 respectively, and Claims 11 and 20 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 8, Sobrier teaches the method of Claim 1 above. Sobrier further teaches:
comparing, by the at least one processor, the application model with a reference model to determine differences there between (Col. 28, lines 4-11 and 29-31,“Each hour (or any other predetermined time interval) after bootstrap, a new snapshot is taken (i.e., data collected about a datacenter in the last hour is processed) and information from the new snapshot is merged with existing data to create and (as additional data is collected/processed) maintain a cumulative graph. The cumulative graph (also referred to herein as a cumulative PType graph and a polygraph) is a running model of how processes behave over time… Next, PType clusters in the snapshot's graph are compared against PType clusters in the cumulative graph to identify commonality.” The PType clusters in the snapshot graph being compared to the PType clusters in the cumulative graph to identify commonality, where the graphs can be polygraph models, correlates to comparing the application model with a reference model to determine differences) and, upon the differences being non-null, performing, by the at least one processor, a restorative action (Col. 61, lines 23-34,“ In some embodiments, the deployments that are analyzed, monitored, evaluated, or otherwise observed by the systems described herein (e.g., systems that include components such as the platform 12 of FIG. 1D, the data collection agents described herein, and/or other components) may be monitored to determine the extent to which a particular component has experienced “drift” relative to its associated IaC configuration. Discrepancies between how cloud resources were defined in an IaC configuration file and how they are currently configured in runtime may be identified and remediation workflows may be initiated to generate an alert, reconfigure the deployment, or take some other action.” Discrepancies between how the cloud resources were defined in a configuration file and their current state being identified correlates to the differences being non-null. The remediation workflows being initiated to reconfigure the deployment or other actions correlates to performing a restorative action).
With regards to Claim 18, the method of Claim 8 performs the same steps as the machine of Claim 18, and Claim 18 is therefore rejected using the same rationale set forth above in the rejection of Claim 8.
With regards to Claim 9, Sobrier teaches the method of Claim 8 above. Sobrier further teaches:
wherein the restorative action comprises initiating, by the at least one processor, an API call to the containerized computing platform to deploy a template to attenuate the differences between the reference model and the application model (Col. 61, lines 23-34,“ In some embodiments, the deployments that are analyzed, monitored, evaluated, or otherwise observed by the systems described herein (e.g., systems that include components such as the platform 12 of FIG. 1D, the data collection agents described herein, and/or other components) may be monitored to determine the extent to which a particular component has experienced “drift” relative to its associated IaC configuration. Discrepancies between how cloud resources were defined in an IaC configuration file and how they are currently configured in runtime may be identified and remediation workflows may be initiated to generate an alert, reconfigure the deployment, or take some other action.” The IaC configuration file correlates to a template. The remediation workflows being initiated to reconfigure the deployment, which utilizes an IaC configuration file and at least one API, correlates to the restorative action initiating an API call to deploy a template to attenuate the differences between the models).
With regards to Claim 19, the method of Claim 9 performs the same steps as the machine of Claim 19, and Claim 19 is therefore rejected using the same rationale set forth above in the rejection of Claim 9.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Sobrier in view of Alluboyina et al. (U.S. Patent No. US 20210103499 A1), hereinafter “Alluboyina.”
With regards to Claim 2, Sobrier teaches the method of Claim 1 above. Sobrier does not explicitly teach:
wherein accessing, by the at least one processor, the first resource from the containerized computing platform comprises obtaining, by the at least one processor, a listing of Helm secrets returned by querying the first resource from the containerized computing platform with filters, the filters comprising "type=helm.sh/release.v1" and "status=deployed".
However, Alluboyina teaches:
wherein accessing, by the at least one processor, the first resource from the containerized platform comprises obtaining, by the at least one processor, a listing of Helm secrets returned by querying the first resource from the containerized platform with filters (Paragraphs 344, 346, 348, “The Helm chart 3902 may further define such objects as services, service accounts, secrets, config maps, and other objects that may be used to define a stateful set 3904 and replica set 3906 as known in the art… FIG. 40 is a process flow diagram of a method 4000 for creating a snapshot of an application 3900 implemented according to a Helm chart 3902. The method 4000 may be executed by the orchestration layer 1300, i.e. a computing device executing the orchestration layer 1300, or some other module that may be executing on a different computing device… The method 4000 may include obtaining 4004 the states of all objects of the application 3900. This may include acquiring information describing some or all of the objects 3904-3914 of the application 3900. This may include, for each object, information such as the type (stateful set, replica set, pod, container, secret, config map, service, service account, etc.) of the object, an identifier of the object, configuration information for the object (identifiers of pods of a stateful or replica set, identifiers of containers managed by a pod, type of a container, identifier of an application instance executed by a container, an identifier of a computing node (e.g. a node 106, 110) hosting the object, or other information).” The orchestration layer obtaining the states of all objects in the Helm application, which include secrets, correlates to accessing the first resource from the containerized platform comprises obtaining a listing of Helm secrets. The orchestration layer obtaining the states of all objects for the particular application 3900 correlates to obtaining a listing of Helm secrets returned by querying the first resource from the containerized platform with filters), the filters comprising "type=helm.sh/release.v1" and "status=deployed" (Paragraphs 286 and 348, “Note further that a snapshot may be a partial snapshot such that the steps of the method 3100 are performed only for those objects implicated by the instruction, e.g. specific classes of objects, objects in a particular domain or workgroup, objects in some other subset of objects of the application as defined by a human operator, or objects for a single orchestrator (e.g., orchestration layer 1300 or Kubernetes installation 2600)… The method 4000 may include obtaining 4004 the states of all objects of the application 3900. This may include acquiring information describing some or all of the objects 3904-3914 of the application 3900. This may include, for each object, information such as the type (stateful set, replica set, pod, container, secret, config map, service, service account, etc.) of the object, an identifier of the object, configuration information for the object (identifiers of pods of a stateful or replica set, identifiers of containers managed by a pod, type of a container, identifier of an application instance executed by a container, an identifier of a computing node (e.g. a node 106, 110) hosting the object, or other information).” The method obtaining states of objects which include an identifier hosting the object or application instanced executed by the container requires the application to be deployed and therefore correlates to the filter comprising a deployed status. The states of objects comprising configuration information such as stateful sets and various identifiers correlates to filters comprising "type=helm.sh/release.v1").
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with wherein accessing, by the at least one processor, the first resource from the containerized computing platform comprises obtaining, by the at least one processor, a listing of Helm secrets returned by querying the first resource from the containerized computing platform with filters, the filters comprising "type=helm.sh/release.v1" and "status=deployed" as taught by Alluboyina because snapshot objects can include state information which can be stored for later use, such as on a storage node, remote storage device, or cloud storage system as a backup. These snapshots can be used to roll back an application previously created. Snapshot information can also be used to restore topologies of the application (Alluboyina: paragraphs 349 and 354).
With regards to Claim 12, the method of Claim 2 performs the same steps as the machine of Claim 12, and Claim 12 is therefore rejected using the same rationale set forth above in the rejection of Claim 2.
Claim(s) 3-6 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Sobrier in view of Gonczi et al. (U.S. Patent No. US 20200241941 A1), hereinafter “Gonczi” and O’Grady et al. (U.S. Patent No. US 20240385868 A1), hereinafter “O’Grady.”
With regards to Claim 3, Sobrier teaches the method of Claim 1 above. Sobrier does not explicitly teach:
wherein decoding, by the at least one processor, the first resource into structured metadata comprises decoding, by the at least one processor, the first resource utilizing a decoding library provided with the first resource and obtaining, by the at least one processor, as an output from the decoding library, compressed binary metadata.
However, Gonczi teaches:
wherein decoding, by the at least one processor, the first resource into structured metadata comprises decoding, by the at least one processor, the first resource utilizing a decoding library and obtaining, by the at least one processor, as an output from the decoding library, compressed binary metadata (Paragraphs 117-118, “Following the compression, in illustrative embodiments, the Z-MSG is now binary data that utilizes all 8-bits of the byte. For example, a deflate algorithm may be used to compress the message 422 into Z-MSG. Any other compression algorithm may be used to generate Z-MSG. In some embodiments, for example, an off-the-shelf compression library and algorithm to compress or decompress a message may be utilized. For example, data may be passed into the algorithm, and compressed data may be obtained as an output or vice versa. The Deflate compression algorithm is an example of a generally known, accepted, and used compression algorithm that may be utilized in illustrative embodiments.” The Z-MSG being compressed by a compression library and converted to a binary data format correlates to decoding the first resource using a decoding library and obtaining compressed binary metadata as an output).
Gonczi does not explicitly teach that the library [is] provided with the first resource. However, a library provided with the first resource is a popular method of data transfer as evidenced by O’Grady (Paragraph 45, “The blockchain engine 250 may share or provide features and resources with the client device, including data, libraries, and/or applications retrieved with blockchain engine 250 (e.g., development application 222).” The blockchain engine sharing or providing resources with the client device such as data and libraries correlates to the library being provided with the first resource).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with wherein decoding, by the at least one processor, the first resource into structured metadata comprises decoding, by the at least one processor, the first resource utilizing a decoding library and obtaining, by the at least one processor, as an output from the decoding library, compressed binary metadata as taught by Gonczi because compression provides numerous benefits to the system including improved network performance and strengthened encryption. When messages are compressed, less data is sent on the queues and therefore faster response times may be achieved (Gonczi: paragraph 119).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with a library provided with the first resource as taught by O’Grady because libraries are relevant resources associated with data for applications and allow a user to perform scripts and other routines (O’Grady: paragraph 45).
With regards to Claim 13, the method of Claim 3 performs the same steps as the machine of Claim 13, and Claim 13 is therefore rejected using the same rationale set forth above in the rejection of Claim 3.
With regards to Claim 4, Sobrier in view of Gonczi and O’Grady teaches the method of Claim 3 above. Gonczi further teaches:
decompressing, by the at least one processor, the compressed binary metadata with a decompression library and receiving, by the at least one processor, therefrom a JavaScript Object Notation string (JSON string) (Paragraphs 117 and 145, “At 410, the message 422 may be compressed prior to encryption to generate a compressed message (Z-MSG). For example, in illustrative embodiments, the message 422 may initially be in a clear text format such as, e.g., JavaScript Object Notation (JSON) format or a simple American Standard Code for Information Interchange (ASCII) text format using 7 bits of an 8-bit byte… At 630, the Z-MSG is expanded to generate the RAW MESSAGE, for example, using an INFLATE(Z-MSG) command which may, for example, be included as part of the deflate algorithm mentioned above. For example, the inflate command reverses the compression performed at step 410.” The Z-MSG being inflated to reverse the compression and generate a raw message, which includes a text JSON format, correlates to decompressing the compressed binary metadata with a decompression library and receiving a JSON string).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with decompressing, by the at least one processor, the compressed binary metadata with a decompression library and receiving, by the at least one processor, therefrom a JavaScript Object Notation string (JSON string) as taught by Gonczi because compression provides numerous benefits to the system including improved network performance and strengthened encryption. When messages are compressed, less data is sent on the queues and therefore faster response times may be achieved. For example, where a message contains a JSON format, there is a repetitive syntax which generally includes a lot of white space for readability purposes. Compression generally reduces the size of such objects by removing or condensing the white space, where the more complex the object, the greater the return on compression (Gonczi: paragraphs 119-120).
With regards to Claim 14, the method of Claim 4 performs the same steps as the machine of Claim 14, and Claim 14 is therefore rejected using the same rationale set forth above in the rejection of Claim 4.
With regards to Claim 5, Sobrier in view of Gonczi and O’Grady teaches the method of Claim 4 above. Sobrier further teaches:
wherein establishing the relationship links between the related configuration items to create the application model further comprises parsing, by the at least one processor, the data and obtaining, by the at least one processor, therefrom application data and infrastructure data (Col. 83, lines 42-57, “Before being used to generate a data model 526, implementation 530 illustrates another detail that was not explicitly shown in FIG. 5B: audit log data 522 and other cloud data 524-1 may be ingested by way of a data ingestion service 534. Data ingestion service 534 may be implemented within network 518, within data platform 520, or by a separate and standalone device or process. Data ingestion service 534 may implement communication protocols and be configured to arrange for the data 522 and 524 to be obtained in any suitable way (e.g., by requesting the data if necessary, by unpacking and buffering the data, by storing the data temporarily or persistently where it can be used for data modeling and other processes, etc.). As part of this ingestion process, data ingestion service 534 may also process and prepare the data (e.g., by altering the data) in various ways.” The audit log data and other cloud data being ingested by the data ingestion service through unpacking, buffering, processing, and preparation correlates to parsing the data and obtaining application and infrastructure data).
Sobrier does not explicitly teach that the data is a JSON string. However, JSON string[s] are a popular data format as evidenced by Gonczi above (Paragraph 117, “At 410, the message 422 may be compressed prior to encryption to generate a compressed message (Z-MSG). For example, in illustrative embodiments, the message 422 may initially be in a clear text format such as, e.g., JavaScript Object Notation (JSON) format or a simple American Standard Code for Information Interchange (ASCII) text format using 7 bits of an 8-bit byte.” The message initially being a clear text format such as JSON format correlates to the data being a JSON string)
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with parsing, by the at least one processor, the JSON string as taught by Gonczi because compression provides numerous benefits to the system including improved network performance and strengthened encryption. When messages are compressed, less data is sent on the queues and therefore faster response times may be achieved. For example, where a message contains a JSON format, there is a repetitive syntax which generally includes a lot of white space for readability purposes. Compression generally reduces the size of such objects by removing or condensing the white space, where the more complex the object, the greater the return on compression (Gonczi: paragraphs 119-120).
With regards to Claim 15, the method of Claim 5 performs the same steps as the machine of Claim 15, and Claim 15 is therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to Claim 6, Sobrier in view of Gonczi and O’Grady teaches the method of Claim 5 above. Sobrier further teaches:
converting, by the at least one processor, the application data and the infrastructure data into configuration data and relationship links interconnecting the related configuration items (Col. 84, lines 50-66, “Once processed by data ingestion service 534, audit log data 522 and other cloud data 524 (e.g., agent-collected data 532 implementing other cloud data 524-1 in this example) may be used for data modeling in the ways described herein. To illustrate, a data model 526-1 is shown that, as indicated by the reference number, represents a specific type of data model 526 used in this example. Specifically, as shown, data model 526-1 is implemented as a polygraph 536 (or other suitable graph described herein) that comprises a plurality of node points 537 (also referred to herein simply as “nodes”) connected by a plurality of edges 538. Each node point 537 (the shaded circles in polygraph 536) of the plurality of node points 537 may represent a logical entity, while each edge 538 (the arrows connecting the node points in polygraph 536) of the plurality of edges 538 may represent a behavioral relationship between node points 537 connected by the edge 538.” The processed audit log or other cloud data correlates to the application and infrastructure data. The processed data being used to create a polygraph with nodes and edges representing behavioral relationships between nodes correlates to converting application and infrastructure data into configuration data and relationship links between the related configuration items).
With regards to Claim 16, the method of Claim 6 performs the same steps as the machine of Claim 16, and Claim 16 is therefore rejected using the same rationale set forth above in the rejection of Claim 6.
Claim(s) 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sobrier in view of Jensen et al. (U.S. Patent No. US 20240028416 A1), hereinafter “Jensen” and Karr et al. (U.S. Patent No. US 20210019093 A1), hereinafter “Karr.”
With regards to Claim 7, Sobrier teaches the method of Claim 1 above. Sobrier further teaches:
wherein the containerized computing platform comprises a container orchestrator selected from a group of container orchestrators comprising Kubernetes (Col. 76, lines 22-36 and Col. 81, lines 38-41, “For instance, in examples in which the container orchestrator is a Kubernetes orchestrator, audit log data 522 may be Kubernetes audit log data that includes or represents any of the data described above… To give a few examples of such container orchestration services, Kubernetes (also abbreviated as “K8s”) orchestration service offerings include provider-managed Kubernetes orchestrators (e.g., Amazon Elastic Kubernetes Service (Amazon EKS or AWS EKS), Google Kubernetes Engine (GKE or GCP GKE), Microsoft Azure Kubernetes Service (AKS or MS AKS), IBM Cloud Kubernetes Service (IKS or IBM IKS), AKS, etc.), self-managed Kubernetes orchestrators (e.g., Kubernetes, Red Hat OpenShift, Kubernetes Operations (kOps), Rancher, etc.), and various other Kubernetes-related offerings. Other container orchestration services not based on Kubernetes may also be employed in certain cloud compute environments.” Other container orchestration services not based on Kubernetes also being employed correlates to a group of container orchestrators. The container orchestrator being a Kubernetes orchestrator correlates to the containerized platform comprising a container orchestrator using Kubernetes), OpenShift by Red Hat (Col. 76, lines 22-36, “To give a few examples of such container orchestration services, Kubernetes (also abbreviated as “K8s”) orchestration service offerings include provider-managed Kubernetes orchestrators (e.g., Amazon Elastic Kubernetes Service (Amazon EKS or AWS EKS), Google Kubernetes Engine (GKE or GCP GKE), Microsoft Azure Kubernetes Service (AKS or MS AKS), IBM Cloud Kubernetes Service (IKS or IBM IKS), AKS, etc.), self-managed Kubernetes orchestrators (e.g., Kubernetes, Red Hat OpenShift, Kubernetes Operations (kOps), Rancher, etc.), and various other Kubernetes-related offerings. Other container orchestration services not based on Kubernetes may also be employed in certain cloud compute environments.” Other container orchestration services not based on Kubernetes also being employed correlates to a group of container orchestrators. The container orchestrator being a Red Hat Openshift orchestrator correlates to the containerized platform comprising a container orchestrator using Red Hat Openshift), Docker Community Edition, Docker Enterprise Edition (Col. 80, lines 40-50, “For example, container orchestrator 514 may be implemented using systems and technologies such as Amazon EKS, self-managed Kubernetes implementations, Amazon ECS, Azure AKS, Google GKE, Docker Kubernetes or Docker Swarm, Red Hat OpenShift, Rancher, Apache Aurora, IBM Cloud Kubernetes, Pivotal Cloud Foundry or Pivotal Kubernetes Service, Nomad, or any other suitable container orchestrator (e.g., including Kubernetes-based orchestrators and non-Kubernetes-based orchestrators) as may serve a particular implementation.” The container orchestrator being implemented using Docker Kubernetes or Docker Swarm correlates to a containerized platform comprising a container orchestrator using Docker community or enterprise edition),
Sobrier does not explicitly teach:
wherein the containerized platform comprises a container orchestrator selected from a group of container orchestrators comprising Tanzu by VMware and SUSE CaaS platform.
However, Jensen teaches:
wherein the containerized platform comprises a container orchestrator selected from a group of container orchestrators comprising Tanzu by VMware (Paragraphs 6 and 8, “In one aspect, teachings set forth herein disclose a centralized Kubernetes orchestration system containing platform-specific knowledge for one or more managed Kubernetes platforms, including, without limitation, any one or more of VMware Tanzu, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Red Hat OpenShift, and Docker EE… In one aspect, the teachings herein disclose a method for managing remote Kubernetes clusters on one or more managed Kubernetes platforms, e.g. AKS, GKE, Tanzu, etc., with a central orchestrator that includes a plurality of cluster integration interfaces for a corresponding plurality of managed platforms.” The orchestrator managing one or more Kubernetes platforms such as VMware Tanzu correlates to the containerized platform comprising a container orchestrator using Tanzu by VMware).
Additionally, Karr teaches:
wherein the containerized platform comprises a container orchestrator selected from a group of container orchestrators comprising SUSE CaaS platform (Paragraph 175, “Likewise, containerized applications may be managed through the use of Kubernetes, a container-orchestration system for automating deployment, scaling and management of containerized applications. Kubernetes may execute on top of operating systems such as, for example, Red Hat Enterprise Linux, Ubuntu Server, SUSE Linux Enterprise Servers, and others.” The containerized applications being managed by a container-orchestration system with Kubernetes executing on top of SUSE Linux Enterprise Servers correlates to the containerized platform comprising a container orchestrator using SUSE CaaS platform).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with wherein the containerized computing platform comprises a container orchestrator selected from a group of container orchestrators comprising Tanzu by VMware as taught by Jensen because various Kubernetes platforms can be managed together using a Kubernetes orchestration system such as Tanzu by VMware containing platform-specific knowledge. These orchestrators allow secure communication between the managed Kubernetes platform and management of application workloads on the cluster. Platform-specific management tasks can also allow cluster infrastructure configuration tasks such as scaling nodes, updating a Kubernetes version, or modifying access or permission nodes (Jensen: paragraphs 6 and 8).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with wherein the containerized computing platform comprises a container orchestrator selected from a group of container orchestrators comprising SUSE CaaS platform as taught by Karr because Kubernetes container-orchestration systems can be used for automating deployment, scaling and management of containerized applications on top of various operating systems such as SUSE Linux Enterprise Servers to facilitate a serverless, cloud native computing deployment and management model for software applications (Karr: paragraphs 175).
With regards to Claim 17, the method of Claim 7 performs the same steps as the machine of Claim 17, and Claim 17 is therefore rejected using the same rationale set forth above in the rejection of Claim 7.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Sobrier in view of Huschle et al. (U.S. Patent No. US 20230315676 A1), hereinafter “Huschle.”
With regards to Claim 10, Sobrier teaches the method of Claim 9 above. Sobrier does not explicitly teach:
automatically performing, by the processor, a test to determine if the API call has attenuated the differences between the reference model and the application model and, if successful, generating a new template release.
However, Huschle teaches:
automatically performing, by the processor, a test to determine if the change has attenuated the differences between the reference model and the application model (Paragraphs 31, 37, “Reconfiguration program 110 determines actions needed to get to the target I/O configuration (step 204). In an embodiment, reconfiguration program 110 compares the active I/O configuration to the target I/O configuration by performing hierarchical delta calculations to determine the differences between the two configurations. Based on the calculations, reconfiguration program 110 determines the actions necessary to transform the active configuration to the target configuration. Actions may include, but are not limited to, adding, modifying, and/or deleting one or more I/O elements… In an embodiment, reconfiguration program 110 runs a simulation of the reconfiguration actions in the defined order to test the actions determined to transform the active configuration to the target configuration as a dry run, without actually changing the I/O configuration of the system. The simulation is a loop through step where, in each logical partition, reconfiguration program 110 test triggers the changes based on the different dependencies to determine potential problems, such as unavailability of devices and/or control units, channel path errors, etc.” The reconfiguration program simulating changes made to the I/O configuration of the system to determine whether the reconfiguration actions bring the active configuration to the target configuration corelates to automatically performing a test to determine if the change has attenuated the differences between the reference model and the application model) and, if successful, generating a new template release (Paragraph 40, “If reconfiguration program 110 determines the simulation does not identify a problem (“no” branch, decision block 218), then reconfiguration program 110 performs the reconfiguration actions (step 222). In an embodiment, the result of a successful simulation is a configuration profile that confirms that all changes can be applied and will be successful when reconfiguration program 110 triggers the reconfiguration actions in the identified order… In an embodiment, reconfiguration program 110 stores the configuration profile in database 118.” The reconfiguration program not finding any errors with the simulation and resulting in a configuration profile with the applied changes being saved to a database correlates to generating a new template release on success).
Huschle does not explicitly teach that the change is made through an API call. However, API call[s] are a popular method of initiating reconfiguration as evidenced by Sobrier above (Col. 61, lines 23-34,“ In some embodiments, the deployments that are analyzed, monitored, evaluated, or otherwise observed by the systems described herein (e.g., systems that include components such as the platform 12 of FIG. 1D, the data collection agents described herein, and/or other components) may be monitored to determine the extent to which a particular component has experienced “drift” relative to its associated IaC configuration. Discrepancies between how cloud resources were defined in an IaC configuration file and how they are currently configured in runtime may be identified and remediation workflows may be initiated to generate an alert, reconfigure the deployment, or take some other action.” The remediation workflows being initiated to reconfigure the deployment, which utilizes an IaC configuration file and at least one API, correlates to the restorative action initiating an API call).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Sobrier with automatically performing, by the processor, a test to determine if the change has attenuated the differences between the reference model and the application model and, if successful, generating a new template release as taught by Huschle because running live simulations of the reconfiguration actions limits the operational impact of the reconfiguration. Checking whether problems or errors occur during the simulation allows changes to runtime dependencies before the final configuration profile is saved to a database (Huschle: paragraphs 37-40).
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Henkel et al. (U.S. Patent No. US 20240073087 A1); teaching a method of leveraging a configuration framework for an orchestration platform to configure software. Abstract configuration data is translated into configuration data structured to conform to a data model for a containerized routing protocol process. Instances of the containerized routing protocol are further configured with the configuration data structured to conform to the data model.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
The publicPAIR and privatePAIR systems are no longer available. 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.
SELINA HU
Examiner
Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights