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 .
Response to Arguments
Applicant’s arguments, see page(s) 12, filed 4/20/2026, with respect to the objection(s) to the abstract have been fully considered and are persuasive. The associated objection(s) to the abstract has/have been withdrawn.
Applicant’s arguments, see page(s) 12, filed 4/20/2026, with respect to the objection(s) to the specification have been fully considered. While the examples pointed out in the previous office action have been corrected, additional errors have not been addressed. This objection is maintained.
Applicant’s arguments, see page(s) 12, filed 4/20/2026, with respect to the objection(s) to the drawings have been fully considered and are persuasive. The associated objection(s) to the drawings has/have been withdrawn.
Applicant’s arguments, see page(s) 12, filed 4/20/2026, with respect to the objection(s) to claim(s) 7 and 17-19 have been fully considered and are persuasive. The associated objection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see page(s) 12, filed 4/20/2026, with respect to the rejection of claim(s) 17-19 under 35 USC 112(a) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see page(s) 12-13, filed 4/20/2026, with respect to the rejections of claim(s) 1-20 under 35 USC 112(b) have been fully considered. Examiner notes that for those rejections which are maintained, no arguments have been submitted by Applicant regarding the details of the individual rejections.
The following portions of the rejections are withdrawn:
The rejection of claims 1, 17, and 20 directed to the relationship between the “software supply chain”, “processes”, “configuration file”, and “machine-readable code”.
The rejection of claims 1, 17, and 20 directed to “… invoking … a machine-based algorithm to analyze the machine readable code to identify configuration data associated with the change …”.
The rejection of claims 1, 17, and 20 directed to “… applying a data transformation to the score to generate an identifier associated with the software container.”
The rejection of claims 1 and 20 directed to the antecedent basis of “continuous query”.
The rejections of claims 2, 3, 14, 17, and 19.
The following portions of the rejections are maintained:
The rejection of claims 1, 17, and 20 directed to the language of the limitation, “… when referenced to one or more libraries called by a platform configured to scan the software container and the source code”.
The rejection of claims 1, 17, and 20 directed to “evaluating the configuration data … to score the change, the score associated with a security tool …”.
The rejections of claims 9-11.
Applicant’s arguments, see page(s) 13, filed 4/20/2026, with respect to the rejection of claim(s) 6, 11, and 13 under 35 USC 112(d) have been fully considered.
Regarding claim 6:
The amendments sufficiently address the rejection. This rejection is withdrawn.
Regarding claims 11 and 13:
The amendments do not sufficiently address the rejections. These rejections are maintained.
Applicant’s arguments, see page(s) 13-14, filed 4/20/2026, with respect to the rejection of claim(s) 1-20 under 35 USC 101 have been fully considered but they are not persuasive.
Regarding the argument:
“… Claim 1 as amended recites, at least in part, the following: "identifying … the one or more processes including at least one … associated with the software container, …[,] parsing the source code … to identify a configuration file having machine readable code executed by a processor …”
Examiner first notes that the term “machine-readable code” has no standard definition in the art which precludes it from also being “human-readable.” For example, even high-level programming languages such as Python™ are “machine-readable.” Examiner then notes that parsing code and identifying a configuration file are well within the scope of tasks performable by a human as a mental process and with the aid of pen and paper.
“… the machine readable code … indicating whether a change at a kernel-level has occurred to the source code …[,] identifying a portion of the configuration file including configuration data for a security tool as a component in the software container ...," among other novel, non-obvious, and patent eligible subject matter. As the aforementioned claimed subject matter cannot be performed as a "mental process" or with "pen and paper," amended claim 1 and its dependent claims are thereby patent eligible. Therefore, rejections under § 101 are now moot.”
Examiner notes that the phrase, “indicating whether a change at a kernel-level has occurred to the source code”, has no known meaning in the art that could be applied to the subject matter in this limitation, and is the subject of a rejection under 35 USC 112(b), which can be found in the below section titled Claim Rejections - 35 USC § 112. Examiner has taken the most reasonable interpretation to the limitation as written, minus the indefinite portion, to teach determining whether a change has occurred to the source code. Identifying changes in code is well within the scope of tasks performable by a human as a mental process and with the aid of pen and paper. This rejection is maintained.
Applicant’s arguments, see page(s) 14-15, filed 4/20/2026, with respect to the rejection of claim(s) 1-20 under 35 USC 103 have been fully considered but they are not persuasive.
Regarding the argument:
“… Nowhere does Zerah disclose, teach, suggest, or motivate "a security tool as a component in the software container" as set forth in amended claim 1.”
Examiner respectfully disagrees. No particular definition of a “security tool” is provided in the instant application beyond an entity which calculates a score (¶ 0033, inter alia). The “score generation module” of ZERAH meets the broadest reasonable interpretation of the recited “security tool” by performing the function of the limitation which is positively claimed (score generation).
Regarding the argument:
“Nowhere does Das or any other cited reference teach, suggest, or motivate "evaluating the configuration data using the platform and a security database to score the change of one or more of the plurality of components individually to form scores, at least a portion of the scores associated with the security tool used with the software container[,] …”
In response to Applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The prior art of DAS is not mapped to the limitation in Applicant’s argument. The prior art of ZERAH is mapped to this limitation, and no argument is provided which is directed the prior art which is applied.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which Applicant may become aware in the specification.
Examiner notes that despite the lack of a complete check, numerous clerical errors were visible throughout the specification. As noted in the previous office action, the errors listed below are examples only, and Applicant is expected to perform a thorough review of the specification to locate and correct additional errors. Additional examples include:
¶ 0004 uses an incorrect plural form of “apparatus.” The correct plural form is “apparatus” or “apparatuses.”
¶ 0039 contains a misspelling of “containered.”
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claim(s) 1-16 is/are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contain(s) subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding claim(s) 1:
Claim 1 recites, “… indicating whether a change at a kernel-level has occurred to the source code of the software container …”. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. While the specification discusses performing integrity checks at a kernel level in paragraph 0038, inter alia, this does not describe identifying changes which occur at the kernel level, nor is it clear what a kernel-level change to a software container’s code would actually mean. This rejection can be overcome by amending the claim(s) such that they recite only that subject matter which is explicitly supported by the original disclosure.
Regarding claims 2-16:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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.
Claims 1-16 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim 1:
Claim 1 recites, “the machine readable code … indicating whether a change … has occurred to the source code of the software container when referenced to one or more libraries called by a platform configured to scan the software container and the source code”. The claim is indefinite because the metes and bounds of the claim are not clear. It is unclear what function is intended by the phrase, “when referenced to … libraries.” The phrase “reference to” is typically used when describing one element as referencing another (i.e. ‘A’ is a “reference to” ‘B’). Its use in the claim does not follow this convention, and the specification does not explicitly redefine the phrase. Specification ¶ 0032 appears to be related to this limitation; however, the relevant portion reads as follows: “Regardless of which type of programming schema (e.g., OSS or proprietary), platform 102, using scanning engine 106, may be configured to parse source code of software containers to identify a security tool(s) used by, with, within, or referenced for which representative data may be generated as input to one or more scoring engines such as scoring engine 107.” This sentence and the claim limitation in question are ill-formed to the degree that their meanings cannot be inferred.
Additionally, claim 1 recites, “evaluating the configuration data … to score the change, the score associated with a security tool …”. The claim is further indefinite because it is unclear how a “change,” previously described as a change to the source code of a software container, would be further associated with a “security tool.” One skilled in the art may assume that the “security tool” is meant to calculate the score associated with the change, but the specification and later recitations of the claims indicate this is not the case. This rejection can be overcome by amending the claim such that the relationship (between the change in the source code, the score, and the security tool) is made clear.
Additionally, claim 1 recites, “… score the change of one or more of the plurality of components individually …”. The claim is further indefinite because the claim previously recites, “… the source code indicating whether a change … has occurred to the source code of the software container …”. The claim is first reciting identifying changes to the source code of the software container, then refers to changes to the components. While the source code of a software container is associated with the source code of the components within the container, they are nonetheless distinct sets of code. This portion of the rejection can be overcome by amending the claim such that it is consistent in reciting the claimed changes to source code as being associated with the software container, the components, or both.
Additionally, claim 1 recites, “… the identifier being referenced to the security database to identify a security threat or compromise.” Similar to above, the claim is further indefinite because the metes and bounds of the claim are made unclear by use of the phrase, "reference to."
Regarding claim 6:
The claim recites, “…generate at least one of the scores as a function of a particular type of the security tool.” The claim is indefinite because it is incompatible with its depended-on claim. Claim 1, on which this claim depends, recites, “… using the platform and a security database to score the change of one or more of the plurality of components individually to form scores …”. The parent claim is explicit that the “platform” generates the score. It is mutually exclusive for a child claim to then recite the scores being instead generated by the “security tool,” which is a component of the software container.
Regarding claim 9:
The claim recites, “… generate at least one score … associated with the one or more processes.” The claim is indefinite because it is incompatible with its depended-on claim. Claim 1, on which this claim depends, recites, “… machine readable code … indicating whether a change … has occurred to the … software container …”. It goes on to recite, “… score the change …”. Where claim 1 scores a change associated with source code of the container, it is then incompatible with claim 9 which recites the score instead being associated with the processes.
Regarding claims 10 and 11:
Claim 10 recites, “… generate the one or more scores, at least one of the scores including a quantitative risk factor associated with the software supply chain.” Claim 11 recites similar language. The claims are indefinite for the same reason as detailed in the rejection of claim 9 above, in this case substituting “software supply chain” for “processes.”
Regarding claims 2-5, 7, 8, and 12-16:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS. — Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 11 and 13 are rejected under 35 U.S.C. 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Regarding claim 11:
The claim fails to further limit the depended-on claim because it recites identical subject matter as claim 10. The following verbiage from claim 10 ostensibly differentiates the claims:
“… using the platform … includes using a scoring engine …”.
“… associated with the software supply chain.”
Compared to the following from claim 11:
“… using the platform … includes the platform using a scoring engine …”
“… associated with an element of the software supply chain of the software container.”
These differences are superficial and do not serve to make the limitations provided by claim 10 distinct from those in claim 11.
Regarding claim 13:
The claim recites, “… the responsive data … includes an artifact, the artifact comprising the software supply chain.” The claim fails to further limit the depended-on claim because it is functionally indistinct from its depended-on claim. Specifically, claim 1, on which this claim depends, recites, “… identifying from the responsive data … a software supply chain …”. The additional recitation of an “artifact” does not serve to further limit the depended-on claim in any meaningful way, as it simply provides an alias by which the supply chain is named, and provides no distinct function to the invention.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
Claims 1, 3-6, and 8-14 are rejected under 35 U.S.C. 103 as being unpatentable over ZERAH et al (Doc ID US 20220398308 A1), and further in view of SUDHAKAR et al (Doc ID US 20230367880 A1), CRABTREE et al (Doc ID US 20210021644 A1), RENKE et al (Doc ID US 20210011984 A1), and XIA et al (Doc ID US 20240152622 A1).
Regarding claim 1:
ZERAH teaches:
the machine readable code of the source code indicating whether a change at a kernel-level has occurred to the source code of the software container when referenced to one or more libraries called by a platform configured to scan the software container and the source code ([0072] "… The identification/detection of modifications ... and associated metadata is shown as step 311.");
invoking, using the platform, a machine-based algorithm executed by the processor to analyze the machine readable code to identify the configuration data associated with the change ([0072] "... the identified/detected modifications (which includes the … metadata associated with the modifications) are provided to the score generation module 114 …");
evaluating the configuration data using the platform and a security database to score the change of one or more of the plurality of components individually to form scores, at least a portion of the scores associated with the security tool used with the software container ([0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …");
SUDHAKAR teaches the following limitations not taught by ZERAH:
A method, comprising: performing a continuous query in an environment, the continuous query being generated to request responsive data associated with a software container ([0048] "… the self-check module 104 identifies components that are associated in the associated bill-of-materials 103 in step 400.");
parsing the source code of the software container and the one or more processes including the at least one component to identify a configuration file having machine readable code executed by a processor ([0049] "... The self-check module 104 may also identify the configuration files 106 in step 400."),
Identifying changes in source code, providing the data to a tool, and creating a score for the detected change are known techniques in the art, as demonstrated by ZERAH. Further, processing a request for a software supply chain and locating configuration files of software components are known techniques in the art, as demonstrated by SUDHAKAR. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the modification scoring of ZERAH with the container data of SUDHAKAR with the motivation to identify changes to software containers and their Software Bill of Materials (SBoM). It is obvious to check for changes in the source code of the components of a container to determine if the container was tampered with.
CRABTREE teaches the following limitations not taught by the combination of ZERAH and SUDHAKAR:
identifying from the responsive data sent in response to the continuous query a software supply chain and one or more processes associated with the software container, the one or more processes including at least one component of a plurality of components associated with the software container ([0006] "… receive a software application for analysis; identify one or more software components comprising the software application …" and [0006] "… construct a cyber-physical graph of a software supply chain for the software application ..."),
the responsive data including source code ([0006] "… a system for analyzing … the software supply chain … comprising: … a software analyzer …" and [0076] "… the software analyzer 2100 comprises … a source code analyzer 2120 …");
Parsing container and SBoM data for component and source code information is/are known technique(s) in the art, as demonstrated by CRABTREE. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification detection of ZERAH and SUDHAKAR with the container data parsing of CRABTREE with the motivation to identify the data elements within the container data which can be analyzed as source code by a kernel-level program such as dm-verity.
RENKE teaches the following limitations not taught by the combination of ZERAH, SUDHAKAR, and CRABTREE:
identifying a portion of the configuration file including configuration data for a security tool as a component in the software container ([0086] "... the security component of the container image can take various forms .... In some instances, the security component includes information that identifies the security configuration profile of the container image 326 ...");
Identifying configuration data associated with a security component of a container is/are known technique(s) in the art, as demonstrated by RENKE. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification detection of ZERAH, SUDHAKAR, and CRABTREE with the security component detection of RENKE with the motivation to inform the system of the security component present so that it can be properly interfaced with or used to calculate scores.
XIA teaches the following limitations not taught by the combination of ZERAH, SUDHAKAR, CRABTREE, and RENKE:
generating an aggregate score of the software container as a function of the scores of the one or more of the plurality of components ([0023] "... At step 522, real-time alert processing service 230 determines a security risk score for the security alert based on the three scores obtained through steps 516, 518, and 520."); and
applying a data transformation to the scores to generate an identifier associated with the software container based on one or more of the scores of the plurality of components and the aggregate score ([0023] "... the two anomaly scores are summed and the threat score is applied to the sum as a multiplier. In other embodiments, weights may be applied to the prevalence anomaly score and the legitimate anomaly score prior to summing."),
the identifier being referenced to the security database to identify a security threat or compromise ([0022] "… After real-time alert processing service 230 completes the scoring, it reports the security risk score for the security alert to notification service 250 (step S406).").
Aggregating collected scores, applying a transformation to the aggregation, and reporting the result to a security service is/are known technique(s) in the art, as demonstrated by XIA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification detection of ZERAH, SUDHAKAR, CRABTREE, and RENKE with the score aggregation and security service update of XIA with the motivation to produce a single data value representative of the scoring applied to the changes so that it can be uploaded to a security service and stored for future comparison or analysis.
Regarding claim 3:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, further comprising retrieving a copy of the source code of the software container, the copy being parsed to identify a copy of the configuration file (ZERAH [0067] "… step 302, where the user 12 interacts with the CI/CD environment 14 to provide input source code …").
Regarding claim 4:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein the environment is a continuous integration software development environment (ZERAH [0067] "… step 302, where the user 12 interacts with the CI/CD environment 14 to provide input source code …").
Regarding claim 5:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, further comprising using one or more scoring engines with the platform to generate the one or more scores including the aggregate score (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …").
Regarding claim 6:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes using a scoring engine to generate at least one of the scores as a function of a particular type of the security tool (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …").
Regarding claim 8:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes using a scoring engine to generate at least one score (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …")
including a quantitative risk factor associated with the software container (ZERAH [0055] "… the artifact score is indicative of the confidence/degree of certainty that a malicious change/modification was performed on the source code during compilation.").
Regarding claim 9:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes using a scoring engine to generate at least one score (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …")
including a quantitative risk factor associated with the one or more processes (ZERAH [0055] "… the artifact score is indicative of the confidence/degree of certainty that a malicious change/modification was performed on the source code during compilation.").
Regarding claim 10:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes using a scoring engine to generate the one or more scores (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …"),
at least one of the scores including a quantitative risk factor associated with the software supply chain (ZERAH [0055] "… the artifact score is indicative of the confidence/degree of certainty that a malicious change/modification was performed on the source code during compilation.").
Regarding claim 11:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes the platform using a scoring engine to generate the one or more scores (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …"),
the scores including one or more quantitative risk factors associated with an element of the software supply chain of the software container (ZERAH [0055] "… the artifact score is indicative of the confidence/degree of certainty that a malicious change/modification was performed on the source code during compilation.").
Regarding claim 12:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein the responsive data sent in response to the continuous query includes an artifact (SUDHAKAR [0048] "… The bill-of-materials 103 may identify software components (e.g., application 102, library(s) 105, operating systems, drivers, hypervisor components, virtual machine components, container components, etc.), configuration files 106, and/or the like.").
Returning a requested type of data is a known technique in the art, as demonstrated by SUDHAKAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the “artifact” of SUDHAKAR with the motivation to ensure the correct type of data is returned for the data request.
Regarding claim 13:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein the responsive data sent in response to the continuous query includes an artifact, the artifact comprising the software supply chain (SUDHAKAR [0048] "… The bill-of-materials 103 may identify software components (e.g., application 102, library(s) 105, operating systems, drivers, hypervisor components, virtual machine components, container components, etc.), configuration files 106, and/or the like.").
Returning a requested type of data is a known technique in the art, as demonstrated by SUDHAKAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the “artifact” of SUDHAKAR with the motivation to ensure the correct type of data is returned for the data request.
Regarding claim 14:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein the responsive data sent in response to the continuous query includes an artifact, the artifact comprising a copy of the source code of the software container and the one or more processes including the at least one component (ZERAH [0067] "… step 302, where the user 12 interacts with the CI/CD environment 14 to provide input source code …").
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over ZERAH et al (Doc ID US 20220398308 A1), SUDHAKAR et al (Doc ID US 20230367880 A1), CRABTREE et al (Doc ID US 20210021644 A1), RENKE et al (Doc ID US 20210011984 A1), and XIA et al (Doc ID US 20240152622 A1) as applied to claim 1 above, and further in view of SONODA (Doc ID US 20230134937 A1).
Regarding claim 2:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1,
SONODA teaches the following limitation(s) not taught by the combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA:
The method of claim 1, further comprising generating a report identifying whether one or more security tools are invoked in the software supply chain ([0105] "… in FIG. 9 above, the search processing is executed using a checklist listing keywords indicating security functions prepared in advance for the source code and the BOM related to the web system to be inspected in security inspection.").
Identifying security tools present in source code is a known technique in the art, as demonstrated by SONODA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the security tool identification of SONODA with the motivation to take account of security present in source code in order to determine whether it is adequate.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over ZERAH et al (Doc ID US 20220398308 A1), SUDHAKAR et al (Doc ID US 20230367880 A1), CRABTREE et al (Doc ID US 20210021644 A1), RENKE et al (Doc ID US 20210011984 A1), and XIA et al (Doc ID US 20240152622 A1) as applied to claim 1 above, and further in view of SCHEITLIN et al (Doc ID US 20220405400 A1).
Regarding claim 7:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein evaluating the configuration data using the platform and the security database includes selecting a scoring engine to generate the one or more scores including the aggregate score, the selecting including identifying one or more algorithms used to run against the configuration data to generate a data result configured to initiate one or more corrective actions (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …").
SCHEITLIN teaches the following limitation(s) not taught by the combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA:
the selecting including identifying one or more algorithms used to run against the configuration data to generate a data result configured to initiate one or more corrective actions ([0149] "... the electronic device 200 ... display information ... about the vulnerability object ..., including unique identifier of the vulnerability object, name of the vulnerability, ... proposed solution to remediate the vulnerability, vulnerability risk score ...").
Identifying remedial actions to take against discovered threats is a known technique in the art, as demonstrated by SCHEITLIN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the remedial action identification of SCHEITLIN with the motivation to determine what remedial actions would correct the unauthorized changes made to the container components.
Regarding claim 15:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1, wherein the identifier is used to generate a quantitative risk value associated with the security tool and the software container (ZERAH [0075] "At step 316, the score generation module 114 compares the build output to the build input … to produce/compute an artifact score …"),
SCHEITLIN teaches the following limitation(s) not taught by the combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA:
the identifier being included in a risk assessment report machine-generated by the platform ([0149] "... the electronic device 200 optionally expands item 231-1 to display information ... about the vulnerability object ..., including unique identifier of the vulnerability object, … vulnerability risk score, …").
Including a vulnerability identifier in a risk report is a known technique in the art, as demonstrated by SCHEITLIN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the risk report of SCHEITLIN with the motivation to ensure identifier issues are annunciated to an administrator and/or user of the system.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over ZERAH et al (Doc ID US 20220398308 A1), SUDHAKAR et al (Doc ID US 20230367880 A1), CRABTREE et al (Doc ID US 20210021644 A1), RENKE et al (Doc ID US 20210011984 A1), and XIA et al (Doc ID US 20240152622 A1) as applied to claim 1 above, and further in view of NYAMARS (Doc ID US 20200310775 A1).
Regarding claim 16:
The combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA teaches:
The method of claim 1,
NYAMARS teaches the following limitation(s) not taught by the combination of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA:
The method of claim 1, wherein the responsive data sent in response to the continuous query includes an artifact, the artifact comprising further data associated with the software container formatted in JSON ([0024] "… In case of an access request received from the consumer 110, the container image accessing system 102 may present a list of container images ... by use of JavaScript Object Notation (JSON) object that may be rendered on the user interface 108.").
Utilizing data formatted in JSON is a known technique in the art, as demonstrated by NYAMARS. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the container modification scoring of ZERAH, SUDHAKAR, CRABTREE, RENKE, and XIA with the data formatting of NYAMARS with the motivation to use a language which is commonly used to represent container images.
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights