DETAILED ACTION
This action is in response to the claims filed February 17, 2026. Claims 1-6, 9-14, and 17-19 are pending. Claims 1, 11, and 19 are independent claims. Claims 1, 11, and 19 have been amended. Claims 7-8, 15-16, and 20 have been cancelled.
The claims rejections under 35 U.S.C. 101 have been withdrawn in view of applicant’s arguments and amendments to the claims.
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 .
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1-6, 9-14, and 17-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11, and 19 recite the limitation of “each build configuration comprising at least a distinct compiler version and a set of environment variables”. The subject matter is not properly described in the application as filed, since the specification only discloses “A build configuration, which may include a compiler version, for creating the second artifact 122 may be selected from an index of possible build configurations…” (Paragraph [0024]). The specification lacks disclosure on “a set of environment variables”. Because the specification does not adequately support the claimed subject matter, it would not reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 2-4, 5-6, 9-10, 12-14, and 17-18 are rejected in view of their dependency on claims 1 and 11.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 9-13, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 11057215 B1 (hereinafter “Miller”) in view of “Investigating the Reproducibility of NPM Packages” by Goswami et. al, (hereinafter “Goswami”), further in view of “Autobash: Improving Configuration Management with Operating System Causality Analysis” by Su et. al, (hereinafter “Su”), further in view of “Moving Forward with Combinatorial Interaction Testing” by Yilmaz et. al (hereinafter “Yilmaz).
Regarding claim 1, Miller discloses:
A method, comprising (Column 3, lines 39-40):
determining, by a processing device, a first code signature of a provided artifact associated with a [data repository] (Column 3, lines 40-46, “In one technique, a server receives, from a client requesting a digital signature, a signing request that includes a hash. The hash was generated based on a data item, such as compiled code or an email. The server provides a data identifier of the data item to a hash validator, which uses the data identifier to retrieve the data item from a data repository [determining, by a processing device, a first code signature of a provided artifact associated with a [data repository]”) [Examiner’s remarks: The code signature (hash) is generated from the artifact (data item).];
…
determining, by the processing device, a new code signature of the new artifact (Column 3, lines 46-47, “The hash validator generates a hash based on the retrieved data item and returns the hash to the server [determining, by the processing device, a new code signature of the new artifact]”)…
comparing, by the processing device, the first code signature to the new code signature (Column 3, lines 47-49, “The server compares (1) the hash from the client to (2) the hash from the hash validator [comparing, by the processing device, the first code signature to the new code signature]”)…
performing, by the processing device, a validation operation or an invalidation operation of the build configuration based on comparing the first code signature to the new code signature (Column 3, lines 49-51, “If the hashes match, then the hash from the client is validated; otherwise, the hash from the client is invalidated [performing, by the processing device, a validation operation or an invalidation operation of the build configuration based on comparing the first code signature to the new code signature]”), wherein:
- responsive to the new code signature matching the first code signature, the validation operation involves validating interchangeability of the provided artifact and the new artifact, saving the build configuration in a storage location, (Column 3, lines 49-51, “If the hashes match, then the hash from the client is validated; otherwise, the hash from the client is invalidated [responsive to the new code signature matching the first code signature, the validation operation involves validating interchangeability of the provided artifact and the new artifact]”; Column 5, lines 52-64, “In cases where the hash is validated (or even in cases where the hash is eventually not validated, as described in more detail herein), client 110 receives a digital signature in response to its signature request. Client 110 bundles the digital signature into a file (e.g., that includes compiled code or a file that is separate from the one whose hash is being signed) in a proprietary format and stores or transmits the file, such as to an online application store. Also, in response to a successful validation, server 120 may trigger an auditable security action, such as logging the event, sending one or more notifications, or uploading, to an online directory, the matched artifacts (e.g., a compiled binary) from which the hashes were generated [saving the build configuration in a storage location]”)…
- responsive to the new code signature not matching the first code signature, the invalidation operation involves invalidating the new artifact (Column 3, lines 49-51, “If the hashes match, then the hash from the client is validated; otherwise, the hash from the client is invalidated [responsive to the new code signature not matching the first code signature, the invalidation operation involves invalidating the new artifact]”)…
Miller does not explicitly disclose:
- …a source code repository;
determining, by the processing device, a plurality of possible build configurations of the source code repository, each build configuration comprising at least a distinct compiler version and set of environment parameters;
iteratively rebuilding, by the processing device, the source code repository to produce a new artifact for at least a subset of the plurality of build configurations, the new artifact being produced with a different compiler version from a compiler version employed to produce the provided artifact;
… for a build configuration of the plurality of build configurations;
… for the build configuration; and
…
…and stopping an iterative search process for valid build configurations, or
… and rebuilding the source code repository to produce a third artifact with a different configuration of the plurality of possible build configurations from a configuration employed to produce the new artifact.
However, Goswami discloses:
- … a source code repository (Page 677, “Among 226 most popularly used NPM packages, we first searched for their source code at GitHub [a source code repository] and tentatively rebuilt each published package version from the corresponding code version”) [Examiner’s remarks: Goswami discloses retrieving source code from a code repository for analysis. Miller discloses retrieving data from a data repository. A person of ordinary skill in the art would find it obvious to replace retrieving data from one type of repository with retrieving data from another type of repository.];
… each build configuration comprising at least a distinct compiler version Page 678, “Namely, when divergent Debian binaries are generated from the same source code due to distinct compilation environments, RepLoc uses diffoscope to compare binaries and obtains a diff log”; Page 678, “Similarly, differential testing relies on reproducible binaries to reveal faults in compilers [20], [19], [17]. These techniques send the same source code to multiple compilers, in order to cross validate the outputs by those compilers” [… each build configuration comprising at least a distinct compiler version])…;
… rebuilding, by the processing device, the source code repository to produce a new artifact for at least a subset of the plurality of build configurations, the new artifact being produced with a different compiler version from a compiler version employed to produce the provided artifact (Page 677, “Among 226 most popularly used NPM packages, we first searched for their source code at GitHub and tentatively rebuilt each published package version from the corresponding code version [rebuilding, by the processing device, the source code repository to produce a new artifact]”; Page 678, “Namely, when divergent Debian binaries are generated from the same source code due to distinct compilation environments, RepLoc uses diffoscope to compare binaries and obtains a diff log”; Page 678, “Similarly, differential testing relies on reproducible binaries to reveal faults in compilers [20], [19], [17]. These techniques send the same source code to multiple compilers, in order to cross validate the outputs by those compilers [for at least a subset of the plurality of build configurations, the new artifact being produced with a different compiler version from a compiler version employed to produce the provided artifact]”) [Examiner’s remarks: The source code repository is built using at least a subset of a plurality of build configurations (different compilers) to generate a new artifact.];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Goswami into the teachings of Miller to include “…a source code repository”, “… each build configuration comprising at least a distinct compiler version”, and “the source code repository to produce a new artifact for at least a subset of the plurality of build configurations, the new artifact being produced with a different compiler version from a compiler version employed to produce the provided artifact”. As stated in Goswami, “it is unknown whether the blindly trusted prebuild NPM packages are reproducible” (abstract). Widespread usage of code packages without knowing if they are trustworthy may result in security concerns. Recompiling source code to compare to the generated code artifact can ensure that nothing has been changed, and provide information on initial build configuration conditions. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with retrieving source code from a code repository.
The combination of Miller and Goswami does not explicitly disclose:
determining, by the processing device, a plurality of possible build configurations of the source code repository, … and set of environment parameters;
iteratively rebuilding …
… for a build configuration of the plurality of build configurations;
… for the build configuration; and
…
…and stopping an iterative search process for valid build configurations, or
… and rebuilding the source code repository to produce a third artifact with a different configuration of the plurality of possible build configurations from a configuration employed to produce the new artifact.
However Su discloses:
iteratively rebuilding, (Abstract, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem, and undoing changes to persistent and transient state when a solution fails”; Page 239, “AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [iteratively rebuilding]”) [Examiner’s remarks: Goswami disclosed rebuilding of an artifact based on different configurations. Su discloses an iterative process of searching through different configuration solutions, testing if the solution works, and undoing the solution if it doesn’t. In combination, the rebuilding using different build configurations of Goswami may be combined with the iterative testing of Su to achieve iterative rebuilding for build validation.]…
…
… for the build configuration (Abstract, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem, and undoing changes to persistent and transient state when a solution fails”; Page 239, “AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [for the build configuration]”) [Examiner’s remarks: Su discloses testing of build configurations until a predicate is reached. Miller discloses a condition (predicate) being reached being that the hashes of two builds match. One of ordinary skill in the art may combine the comparison of hashes of Miller with the iterative building of Su to achieve the present limitation.]; and
…
…and stopping an iterative search process for valid build configurations (Abstract, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem, and undoing changes to persistent and transient state when a solution fails”; Page 239, “AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [and stopping an iterative search process for valid build configurations]”), or
… and rebuilding the source code repository to produce a third artifact with a different configuration of the plurality of possible build configurations from a configuration employed to produce the new artifact (Abstract, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem, and undoing changes to persistent and transient state when a solution fails”; Page 239, “AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [and rebuilding the source code repository to produce a third artifact with a different configuration of the plurality of possible build configurations from a configuration employed to produce the new artifact]”) [Examiner’s remarks: Su discloses using multiple build configurations until it passes all predicate tests. Miller and Goswami disclose rebuilding using a different configuration and using hashing to ensure that interchangeable code is produced. The combination of Miller, Goswami, and Su may be used to teach testing a plurality of configurations until either success or failure.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Su into the combined teachings of Miller and Goswami to include “iteratively rebuilding”, “for the build configuration”, “and stopping an iterative search process for valid build configurations”, and “and rebuilding the source code repository to produce a third artifact with a different configuration of the plurality of possible build configurations from a configuration employed to produce the new artifact”. As stated in Su, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem…” (abstract). Manually testing code configuration changes may be time consuming and result in difficult to fix bugs. Automated testing allows tests to be run in the background without human intervention, saving time and ensuring better code integrity. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with automated testing.
The combination of Miller, Goswami, and Su does not explicitly disclose:
determining, by the processing device, a plurality of possible build configurations of the source code repository, … and set of environment parameters;
However, Yilmaz discloses:
determining, by the processing device, a plurality of possible build configurations of the source code repository, … and set of environment parameters (Page 37, “Modern software systems frequently offer hundreds or even thousands of configuration options. A recent version of the Apache web server, for example, has 172 user-configurable options—158 of these are binary, eight are ternary, four have four settings, one has five, and the last one has six”; Page 37, “For this reason, the testing of industrial systems will almost always involve sampling enormous input spaces and testing representative instances of a system’s behavior. In practice, this sampling is commonly performed with techniques collectively referred to as combinatorial inter action testing (CIT).1,2 CIT typically models a system under test (SUT) as a set of factors (choice points or parameters), each of which takes its values from a particular domain. Based on this model, CIT then generates a sample that meets specified coverage criteria; that is, the sample contains specified combinations of the factors and their values”; Page 39, “The SUT’s valid input space is implicitly defined by its input space model. CIT approaches systematically sample this input space, producing a set of configurations that will be tested in the next phase. The sampling is done by computing an efficient combinatorial object called a covering array, which, by its construction, satisfies a given sampling/ coverage criteria [determining, by the processing device, a plurality of possible build configurations of the source code repository, … and set of environment parameters]”) [Examiner’s remarks: Yilmaz discloses determining a plurality of possible build configurations for testing a system, including different parameters of the configuration. One of ordinary skill in the art may combine the configuration determination of Yilmaz with the build configuration testing of Miller, Goswami, and Su.];
… for a build configuration of the plurality of build configurations (Page 37, “For this reason, the testing of industrial systems will almost always involve sampling enormous input spaces and testing representative instances of a system’s behavior. In practice, this sampling is commonly performed with techniques collectively referred to as combinatorial inter action testing (CIT).1,2 CIT typically models a system under test (SUT) as a set of factors (choice points or parameters), each of which takes its values from a particular domain. Based on this model, CIT then generates a sample that meets specified coverage criteria; that is, the sample contains specified combinations of the factors and their values”; Page 39, “The SUT’s valid input space is implicitly defined by its input space model. CIT approaches systematically sample this input space, producing a set of configurations that will be tested in the next phase. The sampling is done by computing an efficient combinatorial object called a covering array, which, by its construction, satisfies a given sampling/ coverage criteria”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yilmaz into the combined teachings of Miller, Goswami, and Su to include “determining, by the processing device, a plurality of possible build configurations of the source code repository, … and set of environment parameters” and “for a build configuration of the plurality of build configurations”. As stated in Yilmaz, “Combinatorial interaction testing (CIT) is an effective failure detection method for many types of software systems” (Page 37). Determining a set of configuration parameters for testing allows for sufficient test coverage while reducing test time. Therefore, it would be obvious to one or ordinary skill in the art to combine code rebuild with determination of build parameters.
Regarding claim 2, the rejection of claim 1 is incorporated; and Miller further discloses:
- wherein the comparing employs a predetermined similarity threshold, and wherein the new code signature matches the first code signature when differences between the new code signature and the first code signature do not exceed the predetermined similarity threshold (Column 3, lines 49-51, “If the hashes match, then the hash from the client is validated; otherwise, the hash from the client is invalidated [wherein the comparing employs a predetermined similarity threshold, and wherein the new code signature matches the first code signature when differences between the new code signature and the first code signature do not exceed the predetermined similarity threshold]”) [Examiner’s remarks: The first hash and the second hash indicate code signature is valid when they are the same, where the predetermined similarity threshold is a perfect match.].
Regarding claim 3, the rejection of claim 1 is incorporated; and Miller further discloses:
- wherein the comparing employs a heuristic algorithm (Column 3, lines 49-51, “If the hashes match, then the hash from the client is validated; otherwise, the hash from the client is invalidated [wherein the comparing employs a heuristic algorithm]”).
Regarding claim 4, the rejection of claim 1 is incorporated; and Miller does not explicitly disclose:
- wherein the comparing includes prompting a human user to make or review a determination as to whether the new code signature matches the first code signature.
However, Goswami discloses:
- wherein the comparing includes prompting a human user to make or review a determination as to whether the new code signature matches the first code signature (Page 679-680, “We classified differences based on their major characteristics and conducted studies to investigate potential root causes for those observed differences. To generate category labels, we conducted open coding. In particular, three authors iteratively inspected differences to build and refine the taxonomy [wherein the comparing includes prompting a human user to make or review a determination as to whether the new code signature matches the first code signature]”) [Examiner’s remarks: When differences were found, humans reviewed the observed differences to classify causes of said differences.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Goswami into the teachings of Miller to include “wherein the comparing includes prompting a human user to make or review a determination as to whether the new code signature matches the first code signature”. As stated in Goswami, “it is unknown whether the blindly trusted prebuild NPM packages are reproducible” (abstract). Widespread usage of code packages without knowing if they are trustworthy may result in security concerns. Recompiling source code to compare to the generated code artifact can ensure that nothing has been changed, and provide information on initial build configuration conditions. Human review reduces error, and provides information on what was changed. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with human review.
Regarding claim 9, the rejection of claim 1 is incorporated; and Miller further discloses:
- further comprising notifying a user that a build has failed responsive to [possible build configurations] having been tried without the new code signature matching the first code signature (Column 3, lines 47-49, “The server compares (1) the hash from the client to (2) the hash from the hash validator [without the new code signature matching the first code signature]”; Column 5, line 65 – Column 6, line 2, “If server 120 determines that the hash received from client 110 is invalid, then server 120 performs or triggers the performance of one or more security-related actions or activities, such as logging the invalidation, notifying one or more interested parties (e.g., via text or email) [further comprising notifying a user that a build has failed responsive to [possible build configurations] having been tried]”).
The combination of Miller and Goswami does not explicitly disclose:
- …the plurality of possible build configurations…
However, Su discloses:
- …the plurality of possible build configurations (Page 239, “In its replay mode, AutoBash automatically searches for solutions to a configuration problem…AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [the plurality of possible build configurations]) [Examiner’s remarks: AutoBash attempts multiple solutions to a configuration problem including attempting different configuration states.]…
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Su into the combined teachings of Miller and Goswami to include “the plurality of possible build configurations”. As stated in Su, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem…” (abstract). Manually testing code configuration changes may be time consuming and result in difficult to fix bugs. Automated testing allows tests to be run in the background without human intervention, saving time and ensuring better code integrity. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with automated testing of different build configurations.
Regarding claim 10, the rejection of claim 1 is incorporated; and Miller discloses:
- … responsive to a failure of the rebuilding to produce the new artifact (Column 13, lines 16-21, “Fuzzing (or “fuzz testing”) is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The computer program is then monitored for exceptions, such as crashes, failing built-in code assertions, or potential memory leaks [… responsive to a failure of the rebuilding to produce the new artifact]”).
Miller does not explicitly disclose:
- further comprising rebuilding the source code repository to produce a fourth artifact with another different configuration from the configuration employed to produce the new artifact, …
However, Goswami discloses:
- further comprising rebuilding the source code repository to produce a [artifact] (Page 677, “Among 226 most popularly used NPM packages, we first searched for their source code at GitHub and tentatively rebuilt each published package version from the corresponding code version [further comprising rebuilding the source code repository to produce a [artifact]]”)…
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Goswami into the teachings of Miller to include “further comprising rebuilding the source code repository to produce a [artifact]”. As stated in Goswami, “it is unknown whether the blindly trusted prebuild NPM packages are reproducible” (abstract). Widespread usage of code packages without knowing if they are trustworthy may result in security concerns. Recompiling source code to compare to the generated code artifact can ensure that nothing has been changed, and provide information on initial build configuration conditions. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with retrieving source code from a code repository.
The combination of Miller and Goswami does not explicitly disclose:
- … fourth artifact with another different configuration from the configuration employed to produce the new artifact, …
However, Su discloses:
- … fourth artifact with another different configuration from the configuration employed to produce the new artifact, responsive to the [test failure] (Page 239, “In its replay mode, AutoBash automatically searches for solutions to a configuration problem…AutoBash speculatively executes a solution followed by predicate testing. If any predicate evaluates to false, AutoBash decides that the solution does not fix the configuration bug and rolls back that solution. AutoBash then tries the next solution in its solution database until all predicates evaluate to true [fourth artifact with another different configuration from the configuration employed to produce the new artifact, responsive to the [test failure]]”) [Examiner’s remarks: AutoBash is able to test new configuration parameters when a determination is made that a test does not pass. Miller discloses testing a code configuration to ensure that it does not crash, and outputting a result if it does. A person of ordinary skill in the art may use the output of a test with a crashing system in place of predicate tests to trigger a new build with different configurations.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Su into the combined teachings of Miller and Goswami to include “fourth artifact with another different configuration from the configuration employed to produce the new artifact, responsive to the [test failure]”. As stated in Su, “AutoBash automates many of the tedious parts of trying to fix a misconfiguration, including searching through possible solutions, testing whether a particular solution fixes a problem…” (abstract). Manually testing code configuration changes may be time consuming and result in difficult to fix bugs. Automated testing allows tests to be run in the background without human intervention, saving time and ensuring better code integrity. Therefore, it would be obvious to one or ordinary skill in the art to combine code signature verification with automated testing.
Claims 11-13, and 17-18 are system claims corresponding to the method claims hereinabove (claims 1-2, 4, and 9-10, respectively). Therefore, claims 11-13 and 17-18 are rejected for the same reasons as set forth in the rejection of claims 1-2, 4, and 9-10.
Claim 19 is a computer-readable storage medium claim corresponding to the method claims hereinabove (claim 1). Therefore, claim 19 is rejected for the same reasons as set forth in the rejection of claim 1.
Claims 5, 6, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 11057215 B1 (hereinafter “Miller”) in view of “Investigating the Reproducibility of NPM Packages” by Goswami et. al, (hereinafter “Goswami”), further in view of “Autobash: Improving Configuration Management with Operating System Causality Analysis” by Su et. al, (hereinafter “Su”), further in view of “Moving Forward with Combinatorial Interaction Testing” by Yilmaz et. al (hereinafter “Yilmaz), further in view of “Towards Build Verifiability for Java-based Systems” by Xiong et. al, (hereinafter “Xiong”).
Regarding claim 5, the rejection of claim 1 is incorporated; and the combination of Miller, Goswami, Su, and Yilmaz does not explicitly disclose:
- wherein the first code signature and the new code signature are derived from intermediate code.
However, Xiong discloses:
- wherein the first code signature and the new code signature are derived from intermediate code (Page 300, “We compare the SHA-1 checksums of DP1 and DP2. If they are identical, we consider that the build is verifiable and move on to phase 5”; “In this step, we first unpack two non-equivalent deliverable packages DP1 and DP2 to extract two lists of build artifacts. The build artifacts usually consist of a set of class files and a set of text-based files…Since the class files are in the bytecode format… [wherein the first code signature and the new code signature are derived from intermediate code]”) [Examiner’s remarks: The SHA hashes are derived from packages containing files in bytecode, which is a form of intermediate code].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Xiong into the combined teachings of Miller, Goswami, Su, and Yilmaz to include “wherein the first code signature and the new code signature are derived from intermediate code”. As stated in Xiong, “Build verifiability…is crucial for the trustworthiness of a software system” (abstract). Deriving intermediate representations of source code for hashing as they exist in the pre-built package allows for more accurate comparison between the source code and the pre-built code. Ensuring that code is accurate and what one would expect decreases security vulnerabilities. Therefore, it would be obvious to one or ordinary skill in the art to combine code verification with usage of intermediate representations.
Regarding claim 6, the rejection of claim 5 is incorporated; and the combination of Miller, Goswami, Su, and Yilmaz does not explicitly disclose:
- wherein the intermediate code is bytecode.
However, Xiong discloses:
- wherein the intermediate code is bytecode (Page 300, “We compare the SHA-1 checksums of DP1 and DP2. If they are identical, we consider that the build is verifiable and move on to phase 2”; “In this step, we first unpack two non-equivalent deliverable packages DP1 and DP2 to extract two lists of build artifacts. The build artifacts usually consist of a set of class files and a set of text-based files…Since the class files are in the bytecode format… [wherein the intermediate code is bytecode]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Xiong into the combined teachings of Miller, Goswami, Su, and Yilmaz to include “wherein the intermediate code is bytecode”. As stated in Xiong, “Build verifiability…is crucial for the trustworthiness of a software system” (abstract). Deriving intermediate representations of source code for hashing as they exist in the pre-built package allows for more accurate comparison between the source code and the pre-built code, especially when the pre-build package contains intermediate representations of code. Ensuring that code is accurate and what one would expect decreases security vulnerabilities. Therefore, it would be obvious to one or ordinary skill in the art to combine code verification with usage of bytecode representations.
Claim 14 is a system claim corresponding to the method claims hereinabove (claim 5). Therefore, claim 14 is rejected for the same reasons as set forth in the rejection of claim 5.
Response to Arguments
Applicant's arguments filed February 17, 2026 have been fully considered but they are not persuasive.
In the remarks, Applicant argues:
The cited references do not disclose or suggest these features. For example, Miller discloses validating a hash of a digital artifact but does not disclose or suggest iteratively rebuilding a source code repository across a plurality of build configurations, each with distinct compiler versions and environment parameters. Nor does Miller disclose stopping the iterative process and saving the successful build configuration upon a match. See Miller column 3, lines 46-51. Miller focuses on validating a single artifact and does not address or suggest the claimed automated iterative search and early stopping.
Similarly, Goswami describes a study of reproducibility of node package manager (NPM) packages, in which package versions are rebuilt from source code and compared for reproducibility. See Goswami, Abstract and Section III. But, Goswami does not disclose or suggest an automated, iterative process that systematically rebuilds across a plurality of build configurations, each with distinct compiler versions and environment parameters. Rather, Goswami describes a research study in which individual package versions are manually or semi- automatically rebuilt and compared, typically using a single build configuration per version. Goswami does not disclose a process in which the system automatically proceeds through multiple build configurations, nor does Goswami disclose saving the successful build configuration and stopping the process upon the match.
In addition, Su is directed to configuration management of operating systems and does not address rebuilding software artifacts from source code with varying compiler versions or environment parameters, nor does Su disclose or suggest the claimed process of code signature comparison with feedback-driven validation, build configuration saving, and early stopping. Su's process is limited to system and application configuration troubleshooting, not software build artifact verification or reproducibility.
None of the cited references, alone or in combination, disclose or suggest the claimed automated, iterative process across a plurality of build configurations, with conditional early stopping and configuration saving based on code signature validation. Accordingly, the independent claims are patentable over Miller, Goswami, and Su. The remaining cited references do not cure these deficiencies. Accordingly, the independent claims are patentable over the cited references. Withdrawal of the rejections is respectfully requested.
[See Remarks - Pages 10 - 11]
Examiner’s Response:
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 features of Miller, Goswami, and Su are used in combination to teach the invention, and thus does not recite the entirety of the invention in each reference.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights