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 .
DETAILED ACTION
This action is in response to the claimed listing filed on 03/19/2024.
Claims 1-16 are pending.
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-15 are rejected under 35 U.S.C. 103 as being unpatentable over Shripad Nadgowda, “Engram: The One Security Platform for modern Software Supply Chain Risks”, 2022, ACM, pp. 7-12 (hereinafter: Nadgowda), in view of Paketo Buildpacks, “Create a Paketo Buildpack” , 2022, retrieved from /https://paketo.io/docs/howto/create-paketo-buildpack/ , 12 pages (hereinafter: Paketo).
As per Claim 1: Nadgowda discloses the limitations in bold as below:
1. A method for generating a software bill-of-material during a build process (CI Pipeline in Figure 1, p. 9) to create a binary file on a developers build system (bin/exe, by Make in Figure 1), the method comprising:
requesting a build application to perform the build process on a target file (p.9, Figure 1, a build process, Figure 3, where SBOM is built, and p.11 Listing 1, sbom: sbom: sbom-ctl://app.sbom : target file) to create the binary file;
(See Figure 1, p. 9, and see section 2 in left column in p. 8, the second para., “Figure 1 shows this sample pipeline. It starts with a 𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑒𝑟 committing some changes to the code repository, which in turn automatically triggers the CI pipeline. In the pipeline, for engram we specifically consider 𝑡ℎ𝑟𝑒𝑒 stages, namely (a) SBOM Operators (b) Build Operators and (c) Pipeline coordinators.”. See in sec. 2.2 Build Operators, in first para., “It is during 𝑚𝑎𝑘𝑒 that dependencies are finally resolved to a specific version and downloaded for use. For compiled languages, the source code is translated to machine code to generate binaries, executables or libraries.” . )
said developers build system having an operating system (Figure 3, in p. 9 ) which includes [an open-file function](*)
which had previously been wrapped by an open-detect function (p. 11, Listing 2 “if event.src.. then. <trigger CI build> end, the code in right column), such that the open-detect function is invoked with any [open-file function](**)
called by the build application, said target file comprising code necessary to create the binary file,
(See in p. 11, right column, start with “ ..currently in engram we are emulating these events by periodically scanning these platforms to detect any changes and generating corresponding events.”, and see in the same column, the code /listing 2
“if event.src in [first-order-deps] && event.type == "update" && event.change-type=="cve-fix" &&
event.change-severity=="critical"
then
<trigger CI build>
End”
And See p. 12, left column, in the first full para.: “…on the other hand provides automated control to prevent tampering of build materials and verifies the integrity of the build process from source to target. And it works by wrapping commands used in the existing build practices.”.
Note: Thus, scanning through ‘event.scr’ [scr : source] in “first-order-deps” [deps : dependencies] is wrapped [according to para. in p. 12] in “if .. then” : this is a detection by scanning through the source to find events that meet if conditions then to trigger “CI build”, i.e. with this command, it builds a target such as outputs in Listing 1, and according to Figure 1 “Build Operators”, it downloads “Deps” and compiles into “bin/exe”, i.e. ‘binary file’. The conditions meets ‘detected’, “wrapping commands” functioned as wrapped by conditions in listing 2; it invokes the detected events into to trigger command, a CI pipeline to build applications/Package according to “Build Operators” shown in Figure 1 ),
and said build application comprising code configured to open the target file during the build process utilizing [the open-file function](***) ;
(See in Figure 1, with Build Operators and code as listing 1 and listing 2, with trigger CI in listing 2)
in response to a request by the build application to open the target file, invoking the open-detect file to capture metadata relating to the target file,
(See in Figure 1, with Build Operators and code as listing 1 and listing 2, with trigger CI in listing 2, and in Listing 1, the example of builder having metadata “name”)
storing the metadata to a database.
(See Figure 1, Publish in Build Operators, that publishes the Package of new SBOM release.
The package contains Release Metadata as in figure 4, p. 10.
See in p. 8, right column, in the first text portion “…There are new specialized indexers available like DependencyTrack [30] that allows storing SBOM into relational database backends and
provides an efficient query protocols...”. In p. 11, Listing 1 in the left column referred to metadata of an SBOM being built, and within sec. 3.4, left column, third para. started with “We..”, referred to “We broadly identified 𝑡𝑤𝑜 requirements for building such system, namely – (a) maintaining a dependency map (b) standard eventing framework. For dependency map, there are solutions like
dependency-track [30] and deps.dev [20] that provides common pedigree database to store dependencies. Although, in some cases, like for an OCI image, few dependency links are flattened to capture only package-level dependencies”)
Nadgowda does not explicitly disclose the limitation of “open-file function” as noted in (*), (**) and (***) in the claim 1 above.
Nadgowda rather uses a trigger wrapped in a function to detect the change in order to trigger a SBOM build operators, then generates and releases new SBOM including binary files.
Paketo discloses the limitation of “open-file function” (See Paketo: the os.Open() function “os.Open(filepath.Join(context.CNBPath, "buildpack.toml")”; in p. 7, p. 8, and p. 9, in
func Build() packit.BuildFunc {}),
This is an OS open function and serves with the purpose for being associated with the operating system to build an application and gives programmers to control data. The os.Open()/os-open()/os_open() associated with OS is a built-in function in various programming languages. Put in a program code, it is known as a wrapper around the operating system's underlying “open()” system call, and usually used by programmers in a build process; it reads on the open file function as of the claim.
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to modify the use of trigger to a build process in generating SBOM of Nadgowda
to an OS open file function used in Paketo for a package build. The combination would yield predictable results because the open file function used in various programming languages as a built-in function serves as a wrapper around the operating system's underlying open for building files/applications/packages. It would be coded by programmers, but would be the best choice for programmers to select what is available as built-in functions.
As per claim 2: Nadgowda and combining Paketo, where
Nadgowda further discloses
2. The method according to claim 1, further comprising organizing the metadata of the database in a standard software bill-of-material format.
(See in p. 10, Figure 4, or in Figure 3, in format converter SPXD-XDX or Tar.gz)
As per claim 3: Nadgowda and combining Paketo, where
Nadgowda further discloses:
3. The method according to claim 1, further comprising delivering the database to a data repository, and processing the contents of the repository into a standard software bill-of-material format.
(See in Figure 1, Developer using Github, GitLab, and sec. 2.1 SBOM Operators in p.8, especially, the second bullet . index in the sec. 2.1. The standard format for SBOM as Tar.gz , SPXD-XDX , shown in Format converter in Figure 3 )
As per claim 4: Nadgowda and combining Paketo, where
Nadgowda further discloses:
4. The method according to claim 1, wherein the build application is selected from the group consisting of compiler, pre-compiler, assembler, linker pre-processor, and linker.
(In Figure 1, referred to Code Repository Github, GitLab, and with Repo-A, B, C…)
As per claim 5: Nadgowda and combining Paketo disclose:
5. The method according to claim 1, wherein the target file is a second build application, said second build application comprising code configured to open a second target file during the build process utilizing the open-file function.
(The claim recites the target file is a second build application, and building process is functioned the same as the application in claim 1. This second build is applied with the same rationale provided in claim 1, and combining Paketo for disclosing “utilizing the open-file function”).
As per claim 6: Regarding,
6. The method according to claim 5, wherein in response to the request by the second build application to open the second target file, the method further comprises invoking the open-detect function to capture metadata relating to the second target file, and storing the metadata relating to the metadata relating to the second target file.
(The claim recites the target file is a second build application, and building process is functioned the same as the application in claim 1. This second build is applied with the same rationale provided in claim 1).
As per claim 7: Nadgowda discloses the limitations in bold as below:
7. A method for generating a software bill-of-material during a build process to create a binary file on a developers build system, the method comprising:
assigning a library to preload when a build application is loaded into memory on the developer's build system,
(See Figure 2, in p. 9, Lib-A to pipeline as the Pipeline-A, as CI Pipeline in Figure 1, where build application is as Build Operation and as SBOM Redactor in Figure 3 and Storage Service.
Lib-A in the Figure 2, reads on a library that is preloaded before the Build Operators in the pipeline)
said developers build system having an operating system which includes an [open-file
function],
(See figure 1, Developer and Build Operator, and Figure 3, Storage Service, and referred Filesystem/OCI Registry as operating system, and the program code/listing 2 in p. 11, the listing 2 is used in the Figure 1 as trigger CI build when detects events changes referred to a SBOM.
Per above limitations, Nadgowda discloses the limitations above, but not explicitly mention “open-file function”.)
Regarding
a target file comprising code necessary to create the binary file,
said build application comprising code configured to open the target file during the build
process utilizing [the open-file function], and a library including an open-detect function;
requesting the build application to perform the build process on the target file to create the
binary file;
in response to the request to perform the build process, creating a database to store metadata
relating to the target files opened during the build application;
wrapping the open-file function within the open-detect function such that the open-detect function is invoked with any subsequent open-file function by the build application;
in response to a request by the build application to open the target file, invoking the open-detect function to capture metadata relating to the target file,
storing the metadata to the database.
The above limitations are corresponding to the limitation of claim 1.
Thus, Nadgowda discloses the claimed limitations in bold above (See rationales addressed above in claim1), but
Nadgowda does not disclose “open-file function”, and
Paketo discloses limitation of “open-file function” (See rationales addressed above in claim 1).
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to modify the use of trigger to a build process in generating SBOM of Nadgowda to an OS open file function used in Paketo for a package build. The combination would yield predictable results because the open file function used in various programming languages as a built-in function serves as a wrapper around the operating system's underlying open for building files/applications/packages. It would be coded by programmers, but would be the best choice for programmers to select what is available as built-in functions.
As per claim 8: Nadgowda and combining Paketo, where
Nadgowda further discloses the limitations in bold:
8. The method according to claim 7, wherein the creation of the database and wrapping of the open-file function occurs during a construction event of the build application.
Per above in blood limitations, see Nadgowda, in p. 11, Listing 2, “if event.src.. then. <trigger CI build> end”, the code in right column, , it shows the construction CI build is wrapped inside the event.src, but not disclose open-file function.
Paketo discloses limitation of “open-file function” (See rationales addressed above in claim 1), and applying the same rationale of the combination as in claim1/claim7 above.
As per claim 9: Nadgowda and combining Paketo, where with incorporating limitations of claim 8, Nadgowda further discloses the limitations:
9. The method according to claim 8, further comprising closing the database during a deconstruction event of the build application.
(This limitation reads on the sec. 3.4 in p. 11, including Figure 5 and listing 2 with coding “if event.src in [first-order-deps] … then <trigger CI build> end. Figure 5, and Listing handle dependency update. The code then <trigger CI build> end is wrapped in event detected for update., and the build processed is only invoked when change is detected. The Listing 2 reads the claim limitation)
As per claim 10: Nadgowda and combining Paketo, where
Nadgowda further discloses the limitations:
10. The method according to claim 7, wherein said target file is selected from the group consisting of compiler, pre-compiler, assembler, linker pre-processor, and linker.
(Figure 1, referred to Code Repository Github, GitLab, and with Repo-A, B, C…)
As per claim 11: Regarding,
11. The method according to claim 7, further comprising invoking the open-detect function in response to a second request by the build application to open a second target file, capturing additional metadata relating to the second target file, and appending the additional metadata to the database.
(The claim recites the target file is a second build application, and building process is functioned the same as the application in claim 7. This second build is applied with the same rationale provided in claim 7).
As per claim 12: Incorporating limitation of claim 11, Nadgowda and combining Paketo, where
Nadgowda further discloses the limitations:
12. The method according to claim 11, further comprising establishing a compile dependent relationship between the target file and the second target file.
(See p. 8, in sec. 2.2 Build Operators, “For compiled languages, the source code is translated to machine code to generate binaries, executables or libraries. In the next step, these compiled artifacts are 𝑝𝑎𝑐𝑘𝑎𝑔𝑒 together in different distribution formats like 𝑡𝑎𝑟 .𝑔𝑧 or 𝑂𝐶𝐼 image, which are then 𝑝𝑢𝑏𝑙𝑖𝑠ℎ in
respective software registries.”)
As per claim 13: Incorporating limitation of claim 12, Nadgowda and combining Paketo, where
Nadgowda further discloses the limitations:
13. The method according to claim 12, further comprising rewriting the database into a standard software bill of material format.
(The standard format of SBOM like tar.gz or SPDX, XDX in Figure 3)
As per claim 14: Incorporating limitation of claim 11, Nadgowda and combining Paketo, where
Nadgowda further discloses the limitations:
14. The method according to claim 11, further comprising delivering the database to a data repository, and processing the contents of the repository into a standard software bill-of-material format.
(See all three figures, 1, 2, and 3 in p. 9)
As per claim 15: Regarding,
15. A method for generating a software bill-of-material during a build process on a developers build system, the method comprising:
requesting a build application to perform the build process on a target file;
said developers build system having an operating system which includes an open-file function,
said target file having a path and comprising code necessary to create the binary file, and
said build application comprising code configured to open a target file utilizing the open-file function;
in response to the request to perform the build process,
loading the build application into memory on the developers build system;
wrapping the open-file function such that additional operations are performed when a file is opened by the build application;
The above limitations recite the claimed functionality having the same manner of the limitations that are recited in claim 1, or claim 7, and the above limitations would be addressed with the same rationales and the motivation for combining with Nadgowda and combining Paketo in the claim 1 or claim 7 above.
Nadgowda, further discloses,
opening the target file; (p. 9, Figure 1 , with the Developer connected to Github, GitLab, and the target file is such as “app.sbom”, in the path sbom-ctl://app.sbom in Listing 1)
in response to opening the target file, invoking the additional operations wherein the additional operations comprises storing in a database the dependent relationship between the build application and the path of the target file.
(per above limitations, See Nadgowda, Figure 2, with the addition of pipeline-B, C etc., and in the Listing 1 in p. 11, it includes input such as , dependencies: /deps-dir).
Allowable Subject Matter
Claim 16 is allowed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET.
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.
TTV
February 19, 2026
/Ted T. Vo/
Primary Examiner, Art Unit 2191