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 with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 4, 11-12, 14 and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1).
Regarding claim 1, Burrell teaches a computer-implemented method for performing automated software security scanning, the method comprising:
… per-branch instructions associated with one or more of a plurality of codebase branches included in the code repository; ( Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The instructions in the configuration file are interpreted as branch specific among a plurality of branches in a repository.).
copying one or more of the plurality of codebase branches from the code repository into a clone database; (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. To that end, the repository container 218 may pass the authorization token received in the previous step to the SCM system 104. The SCM system 104 inspects this authorization token to determine whether the repository container 218 is allowed access to the SCM repository 112. If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.).
launching a plurality of container tasks for simultaneously executing one or more scanning operations on the one or more of the codebase branches copied into the clone database, (Paragraph 19, “… build configurations—i.e., a collection of settings used to start a particular build and/or a sequence of builds (each called a build step). For each build step, the build configuration may include … list of commands that need to be executed to perform the build/test, information about files that are produced as a result of the build/test (such as reports, source code files, etc.)” Paragraph 122, “Similarly, at step 332 the controller 208 may build different build scripts corresponding to the different branches (if different build steps were defined for each branch) and store these build scripts in the memory 209. The build container 224 may subsequently retrieve source code files 221 and corresponding build scripts 220 from the memory 209 and perform the builds sequentially.” Paragraph 21, “… aspects of the present disclosure create predefined tasks for builds—each task comprises information to perform a particular build step such as … trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc…. In particular, the embodiments presented herein allow developers to add one or more predefined tasks in their build configuration.” Paragraph 115, “While executing the build script 220, the build container 224 determines whether the build script includes any tasks. If a task exists, at step 339 the build container 224 is configured to retrieve the task script for the task from the task definition repository (e.g., based on the task identifier in the build script). The build container then packages the build logic associated with that task (including the VM image, the build commands, the run parameters, and any other associated information) along with the task script into a task job description and request the launch module 212 to retrieve a VM image 225 specified for that particular task e.g., by forwarding the task job description for a task container 226 to the launch module 212.” Paragraph 117, “Next, at step 341 the task container 226 compiles the task script, retrieves the source code 221 and executes the complied task script on the source code 221. In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.” Paragraph 122, “In some embodiments, method described with reference to FIG. 2 may be used to verify source code in different branches of a repository. … At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209” Paragraph 123, “The method described with reference to FIG. 2 can be used to perform builds on multiple build containers 224. In that case, the build description may include identifiers for multiple VM images 222, and the launch module 212 may retrieve the specified build VM images 222 at steps 334 and 326. Thereafter, method steps 338-342 may be repeated for each build container 224 either simultaneously or sequentially.” The task containers are interpreted as container tasks, the tasks are interpreted as testing the source code 221 branches that are stored in the shared memory. The build containers initiating task containers is interpreted as launching a plurality of container tasks. The simultaneous scanning operations is interpreted as the steps 338-342 that can be repeated for each build container simultaneously, the step 341 is the task container being set up and performing the testing.).
wherein the one or more scanning operations are specified by the per- branch instructions; and (Paragraph 22, “At execution, the build configuration is parsed and the CI management system can automatically add the build logic (which is stored in a central repository), such as commands, artefacts, VM image, etc., associated with one or more tasks present in the build configuration. In addition, the CI management system may be configured to execute each task in a separate container.” Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches.” Paragraph 28, “The metadata of CI enabled repositories may also include build configuration files, which include, among other things, the steps for performing a build, and identifiers of one or more predefined tasks. The CI management system 106 (as described in detail below) may be configured to determine whether CI is required for a repository by inspecting the CI indicator in the metadata and, if such an indicator is present, retrieve the associated build configuration file.” The instructions in the build configuration file are interpreted as branch specific, where the tasks indicated in the configuration files are interpreted are interpreted as the code scanning operations.)
generating one or more scan results based on the one or more scanning operations executed on the plurality of codebase branches. (paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202. It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.”).
However, Burrell does not teach executing one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (i) a designation of a code repository and (ii) per-branch instructions associated with one or more … codebase branches included in the code repository.
Spektor teaches executing one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (Paragraph 20, “Code version control manager 104 r may include a number of custom hooks or scripts, generally represented by reference number 108. … According to this disclosure, a custom hook is a custom or user-defined script that may be run or launched by a code version control manager (e.g., 104) when certain important events occur. Thus custom hooks 108 may be run by code version control manager 104 when certain events occur (e.g., events that are detected by code version control manager 104).” The version control manager Custom Hooks are interpreted as scripts stored in a script database; the code version control manager interpreted as the script database.).
(i) a designation of a code repository and (paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script.).
(ii) per-branch instructions associated with one or more … codebase branches included in the code repository; (Paragraph 11, "The present disclosure describes continuous integration with reusable context aware jobs. The present disclosure describes using a single generic pipeline that can be used for all branches off a trunk of a project and/or for multiple different applications. The single generic pipeline may include multiple reusable and configurable jobs. The pipeline/lobs may be configured to be context aware for example, by wrapping the jobs with context wrappers. The pipeline jobs may be configured by head jobs, for example, one head job per context (e.g., per branch and/or per application). Such head jobs may be automatically created by custom hooks of a version control system. The present disclosure allows developers and teams to work on and test their branches, for example, and get feedback from a complete Cl cycle for their particular branch. Furthermore, because a single pipeline is used, pipeline steps are not duplicated. Thus, all the best practices may be implemented in the one pipeline, and when a step or lob of the pipeline is updated, the change is instantly ready to be used for all branches and or applications using the pipeline." Paragraph 21, “Custom hooks 108 may allow for automation in the continuous integration approach of the present disclosure. For example, when a developer pushes or commits a working copy of code (e.g., for a particular branch) to code version control manager 104, code version control manager may detect such a code push as an important event, and may launch at least one custom hook in response. Then, at least one of the launched custom hooks may interact with continuous integration manager 106. For example, as described in more detail below, a custom hook may indicate to continuous integration manager 106 that it should create a new “head” job.” Paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script. The per branch instructions is interpreted as the parameters configuring jobs of the pipeline for each head job’s context, and configured jobs are interpreted as interpreted as the specification for the software testing.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell’s CI/CD system with Spektor by enhancing Burrell’s test initialization system to automatically have the code repository run a custom hook that gives test parameter information alongside repository and branch information in response to a detected repository code push, as taught by Spektor. The motivation is to give the code storing system an active role in automatically initiating Burrell’s CI/CD system to perform testing of a branch of code in a repository through the automatic and immediate transmitting of a test configuration in response to a repository change.
Regarding claim 2, Burrell in view of Spektor teaches the computer-implemented method of claim 1. Burrell teaches wherein copying the one or more of the plurality of codebase branches further comprises copying one or more additional codebase branches included in one or more additional code repositories into the clone database (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. … If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” Paragraph 58, “Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.). The SCM repositories 112 is interpreted as the one or more additional repositories that include a plurality of codebase branches).
Regarding claim 4, Burrell in view of Spektor teaches the computer-implemented method of claim 1. However, Burrell does not teach wherein the one or more scripts specify a subset of codebase branches included in the code repository.
Spektor teaches wherein the one or more scripts specify a subset of codebase branches included in the code repository (paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The custom hook storing specific information for testing a branch is interpreted as specifying a subset of codebase branches included in the code repository, in this case the subset being at least one code branch from a repository.).
The motivation to combine Burrell with Spektor is the same as in claim 1.
Regarding claim 11, Burrell teaches one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of: (Paragraph 137 states the invention described in the reference can be carried out by a computer executing instructions on a processor from a storage media, paragraph 138 staying a storage media is nontransitory.)
… per-branch instructions associated with one or more of a plurality of codebase branches included in the code repository; ( Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The instructions in the configuration file are interpreted as branch specific among a plurality of branches in a repository.).
copying one or more of the plurality of codebase branches from the code repository into a clone database; (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. To that end, the repository container 218 may pass the authorization token received in the previous step to the SCM system 104. The SCM system 104 inspects this authorization token to determine whether the repository container 218 is allowed access to the SCM repository 112. If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.).
launching a plurality of container tasks for simultaneously executing one or more scanning operations on the one or more of the codebase branches copied into the clone database, (Paragraph 19, “… build configurations—i.e., a collection of settings used to start a particular build and/or a sequence of builds (each called a build step). For each build step, the build configuration may include … list of commands that need to be executed to perform the build/test, information about files that are produced as a result of the build/test (such as reports, source code files, etc.)” Paragraph 122, “Similarly, at step 332 the controller 208 may build different build scripts corresponding to the different branches (if different build steps were defined for each branch) and store these build scripts in the memory 209. The build container 224 may subsequently retrieve source code files 221 and corresponding build scripts 220 from the memory 209 and perform the builds sequentially.” Paragraph 21, “… aspects of the present disclosure create predefined tasks for builds—each task comprises information to perform a particular build step such as … trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc…. In particular, the embodiments presented herein allow developers to add one or more predefined tasks in their build configuration.” Paragraph 115, “While executing the build script 220, the build container 224 determines whether the build script includes any tasks. If a task exists, at step 339 the build container 224 is configured to retrieve the task script for the task from the task definition repository (e.g., based on the task identifier in the build script). The build container then packages the build logic associated with that task (including the VM image, the build commands, the run parameters, and any other associated information) along with the task script into a task job description and request the launch module 212 to retrieve a VM image 225 specified for that particular task e.g., by forwarding the task job description for a task container 226 to the launch module 212.” Paragraph 117, “Next, at step 341 the task container 226 compiles the task script, retrieves the source code 221 and executes the complied task script on the source code 221. In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.” Paragraph 122, “In some embodiments, method described with reference to FIG. 2 may be used to verify source code in different branches of a repository. … At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209” Paragraph 123, “The method described with reference to FIG. 2 can be used to perform builds on multiple build containers 224. In that case, the build description may include identifiers for multiple VM images 222, and the launch module 212 may retrieve the specified build VM images 222 at steps 334 and 326. Thereafter, method steps 338-342 may be repeated for each build container 224 either simultaneously or sequentially.” The task containers are interpreted as container tasks, the tasks are interpreted as testing the source code 221 branches that are stored in the shared memory. The build containers initiating task containers is interpreted as launching a plurality of container tasks. The simultaneous scanning operations is interpreted as the steps 338-342 that can be repeated for each build container simultaneously, the step 341 is the task container being set up and performing the testing.).
wherein the one or more scanning operations are specified by the per- branch instructions; and (Paragraph 22, “At execution, the build configuration is parsed and the CI management system can automatically add the build logic (which is stored in a central repository), such as commands, artefacts, VM image, etc., associated with one or more tasks present in the build configuration. In addition, the CI management system may be configured to execute each task in a separate container.” Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches.” Paragraph 28, “The metadata of CI enabled repositories may also include build configuration files, which include, among other things, the steps for performing a build, and identifiers of one or more predefined tasks. The CI management system 106 (as described in detail below) may be configured to determine whether CI is required for a repository by inspecting the CI indicator in the metadata and, if such an indicator is present, retrieve the associated build configuration file.” The instructions in the build configuration file are interpreted as branch specific, where the tasks indicated in the configuration files are interpreted are interpreted as the code scanning operations.)
generating one or more scan results based on the one or more scanning operations executed on the plurality of codebase branches. (paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202. It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.”).
However, Burrell does not teach executing one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (i) a designation of a code repository and (ii) per-branch instructions associated with one or more … codebase branches included in the code repository.
Spektor teaches executing one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (Paragraph 20, “Code version control manager 104 r may include a number of custom hooks or scripts, generally represented by reference number 108. … According to this disclosure, a custom hook is a custom or user-defined script that may be run or launched by a code version control manager (e.g., 104) when certain important events occur. Thus custom hooks 108 may be run by code version control manager 104 when certain events occur (e.g., events that are detected by code version control manager 104).” The version control manager Custom Hooks are interpreted as scripts stored in a script database; the code version control manager interpreted as the script database.).
(i) a designation of a code repository and (paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script.).
(ii) per-branch instructions associated with one or more … codebase branches included in the code repository; (Paragraph 11, "The present disclosure describes continuous integration with reusable context aware jobs. The present disclosure describes using a single generic pipeline that can be used for all branches off a trunk of a project and/or for multiple different applications. The single generic pipeline may include multiple reusable and configurable jobs. The pipeline/lobs may be configured to be context aware for example, by wrapping the jobs with context wrappers. The pipeline jobs may be configured by head jobs, for example, one head job per context (e.g., per branch and/or per application). Such head jobs may be automatically created by custom hooks of a version control system. The present disclosure allows developers and teams to work on and test their branches, for example, and get feedback from a complete Cl cycle for their particular branch. Furthermore, because a single pipeline is used, pipeline steps are not duplicated. Thus, all the best practices may be implemented in the one pipeline, and when a step or lob of the pipeline is updated, the change is instantly ready to be used for all branches and or applications using the pipeline." Paragraph 21, “Custom hooks 108 may allow for automation in the continuous integration approach of the present disclosure. For example, when a developer pushes or commits a working copy of code (e.g., for a particular branch) to code version control manager 104, code version control manager may detect such a code push as an important event, and may launch at least one custom hook in response. Then, at least one of the launched custom hooks may interact with continuous integration manager 106. For example, as described in more detail below, a custom hook may indicate to continuous integration manager 106 that it should create a new “head” job.” Paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script. The per branch instructions is interpreted as the parameters configuring jobs of the pipeline for each head job’s context, and configured jobs are interpreted as interpreted as the specification for the software testing.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell’s CI/CD system with Spektor by enhancing Burrell’s test initialization system to automatically have the code repository run a custom hook that gives test parameter information alongside repository and branch information in response to a detected repository code push, as taught by Spektor. The motivation is to give the code storing system an active role in automatically initiating Burrell’s CI/CD system to perform testing of a branch of code in a repository through the automatic and immediate transmitting of a test configuration in response to a repository change.
Regarding claim 12, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 11. Burrell teaches wherein copying the one or more of the plurality of codebase branches further comprises copying one or more additional codebase branches included in one or more additional code repositories into the clone database (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. … If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” Paragraph 58, “Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.). The SCM repositories 112 is interpreted as the one or more additional repositories that include a plurality of codebase branches).
Regarding claim 14, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 11. However, Burrell does not teach wherein the one or more scripts specify a subset of codebase branches included in the code repository.
Spektor teaches wherein the one or more scripts specify a subset of codebase branches included in the code repository (paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The custom hook storing specific information for testing a branch is interpreted as specifying a subset of codebase branches included in the code repository, in this case the subset being at least one code branch from a repository.).
Regarding claim 18, Burrell teaches a system comprising: one or more memories for storing instructions; and one or more processors for executing the instructions to: (Paragraph 137 states the invention described in the reference can be carried out by a computer executing instructions on a memory.).
… per-branch instructions associated with one or more of a plurality of codebase branches included in the code repository; ( Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The instructions in the configuration file are interpreted as branch specific among a plurality of branches in a repository.).
copy one or more of the plurality of codebase branches from the code repository into a clone database; (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. To that end, the repository container 218 may pass the authorization token received in the previous step to the SCM system 104. The SCM system 104 inspects this authorization token to determine whether the repository container 218 is allowed access to the SCM repository 112. If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.).
launch a plurality of container tasks for simultaneously executing one or more scanning operations on the one or more of the codebase branches copied into the clone database, (Paragraph 19, “… build configurations—i.e., a collection of settings used to start a particular build and/or a sequence of builds (each called a build step). For each build step, the build configuration may include … list of commands that need to be executed to perform the build/test, information about files that are produced as a result of the build/test (such as reports, source code files, etc.)” Paragraph 122, “Similarly, at step 332 the controller 208 may build different build scripts corresponding to the different branches (if different build steps were defined for each branch) and store these build scripts in the memory 209. The build container 224 may subsequently retrieve source code files 221 and corresponding build scripts 220 from the memory 209 and perform the builds sequentially.” Paragraph 21, “… aspects of the present disclosure create predefined tasks for builds—each task comprises information to perform a particular build step such as … trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc…. In particular, the embodiments presented herein allow developers to add one or more predefined tasks in their build configuration.” Paragraph 115, “While executing the build script 220, the build container 224 determines whether the build script includes any tasks. If a task exists, at step 339 the build container 224 is configured to retrieve the task script for the task from the task definition repository (e.g., based on the task identifier in the build script). The build container then packages the build logic associated with that task (including the VM image, the build commands, the run parameters, and any other associated information) along with the task script into a task job description and request the launch module 212 to retrieve a VM image 225 specified for that particular task e.g., by forwarding the task job description for a task container 226 to the launch module 212.” Paragraph 117, “Next, at step 341 the task container 226 compiles the task script, retrieves the source code 221 and executes the complied task script on the source code 221. In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.” Paragraph 122, “In some embodiments, method described with reference to FIG. 2 may be used to verify source code in different branches of a repository. … At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209” Paragraph 123, “The method described with reference to FIG. 2 can be used to perform builds on multiple build containers 224. In that case, the build description may include identifiers for multiple VM images 222, and the launch module 212 may retrieve the specified build VM images 222 at steps 334 and 326. Thereafter, method steps 338-342 may be repeated for each build container 224 either simultaneously or sequentially.” The task containers are interpreted as container tasks, the tasks are interpreted as testing the source code 221 branches that are stored in the shared memory. The build containers initiating task containers is interpreted as launching a plurality of container tasks. The simultaneous scanning operations is interpreted as the steps 338-342 that can be repeated for each build container simultaneously, the step 341 is the task container being set up and performing the testing.).
wherein the one or more scanning operations are specified by the per- branch instructions; and (Paragraph 22, “At execution, the build configuration is parsed and the CI management system can automatically add the build logic (which is stored in a central repository), such as commands, artefacts, VM image, etc., associated with one or more tasks present in the build configuration. In addition, the CI management system may be configured to execute each task in a separate container.” Paragraph 58, “Generally speaking, the configuration file 228 corresponding to a particular repository 112 includes instructions for building, testing, and/or deploying source code revisions from that repository 112 in one or more environments. Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches.” Paragraph 28, “The metadata of CI enabled repositories may also include build configuration files, which include, among other things, the steps for performing a build, and identifiers of one or more predefined tasks. The CI management system 106 (as described in detail below) may be configured to determine whether CI is required for a repository by inspecting the CI indicator in the metadata and, if such an indicator is present, retrieve the associated build configuration file.” The instructions in the build configuration file are interpreted as branch specific, where the tasks indicated in the configuration files are interpreted are interpreted as the code scanning operations.)
generate one or more scan results based on the one or more scanning operations executed on the plurality of codebase branches. (paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202. It will be appreciated that a build configuration may include multiple tasks and the build container 224 may be configured to initiate multiple task containers (one for each task) based on the build script 220. Each task container 226 may generate its own test results and store these in the shared memory 209. Accordingly, method steps 339-343 may be repeated for teach task in the build configuration.”).
However, Burrell does not teach a system that will execute one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (i) a designation of a code repository and (ii) per-branch instructions associated with one or more … codebase branches included in the code repository.
Spektor teaches a system that will execute one or more scripts included in a script database, wherein at least one script included in the one or more scripts includes (Paragraph 20, “Code version control manager 104 r may include a number of custom hooks or scripts, generally represented by reference number 108. … According to this disclosure, a custom hook is a custom or user-defined script that may be run or launched by a code version control manager (e.g., 104) when certain important events occur. Thus custom hooks 108 may be run by code version control manager 104 when certain events occur (e.g., events that are detected by code version control manager 104).” The version control manager Custom Hooks are interpreted as scripts stored in a script database; the code version control manager interpreted as the script database.).
(i) a designation of a code repository and (paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script.).
(ii) per-branch instructions associated with one or more … codebase branches included in the code repository; (Paragraph 11, "The present disclosure describes continuous integration with reusable context aware jobs. The present disclosure describes using a single generic pipeline that can be used for all branches off a trunk of a project and/or for multiple different applications. The single generic pipeline may include multiple reusable and configurable jobs. The pipeline/lobs may be configured to be context aware for example, by wrapping the jobs with context wrappers. The pipeline jobs may be configured by head jobs, for example, one head job per context (e.g., per branch and/or per application). Such head jobs may be automatically created by custom hooks of a version control system. The present disclosure allows developers and teams to work on and test their branches, for example, and get feedback from a complete Cl cycle for their particular branch. Furthermore, because a single pipeline is used, pipeline steps are not duplicated. Thus, all the best practices may be implemented in the one pipeline, and when a step or lob of the pipeline is updated, the change is instantly ready to be used for all branches and or applications using the pipeline." Paragraph 21, “Custom hooks 108 may allow for automation in the continuous integration approach of the present disclosure. For example, when a developer pushes or commits a working copy of code (e.g., for a particular branch) to code version control manager 104, code version control manager may detect such a code push as an important event, and may launch at least one custom hook in response. Then, at least one of the launched custom hooks may interact with continuous integration manager 106. For example, as described in more detail below, a custom hook may indicate to continuous integration manager 106 that it should create a new “head” job.” Paragraph 31, " When such a custom hook creates a new head job, the custom hook may provide certain metadata, or parameters to the head job. Such metadata parameters may include the repository where certain branch code is stored and/or various other pieces of information that can be used to configure jobs of the pipeline. Then, the created head job may pull code from the indicated repository and configure all the jobs of the pipeline, as described above. The created head job may also trigger the main pipeline." The indication of a repository where certain branch code is stored and later pulled is interpreted as a designation of a code repository in the script. The per branch instructions is interpreted as the parameters configuring jobs of the pipeline for each head job’s context, and configured jobs are interpreted as interpreted as the specification for the software testing.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell’s CI/CD system with Spektor by enhancing Burrell’s test initialization system to automatically have the code repository run a custom hook that gives test parameter information alongside repository and branch information in response to a detected repository code push, as taught by Spektor. The motivation is to give the code storing system an active role in automatically initiating Burrell’s CI/CD system to perform testing of a branch of code in a repository through the automatic and immediate transmitting of a test configuration in response to a repository change.
Regarding claim 19, Burrell in view of Spektor teaches the system of claim 18. Burrell teaches wherein copying the one or more of the plurality of codebase branches further comprises copying one or more additional codebase branches included in one or more additional code repositories into the clone database (Paragraph 106, “Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. … If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218.” Paragraph 107, “At step 324, the repository container 218 stores the source code 221 in the shared memory 209.” Paragraph 122, “a developer may define the same or different VM images for each branch and different or the same build steps for each branch in the build description. At steps 322 and 324, the repository container 218 may then retrieve source code from the specified branches and store the source code as different files in the memory 209.” Paragraph 58, “Further, in some cases, the configuration file may include different sets of testing/building instructions for different source code branches. For example, if a repository includes a master branch and a testing branch, the configuration file may include one set of instructions for testing/building source code revisions committed to the master branch and another set of instructions for testing/building source code revisions committed to the testing branch.” The storing of source code from the specified branches is interpreted as files in memory 209 is interpreted as storing one or more of a plurality of codebase branches into a clone database, where 209 is the clone database.). The SCM repositories 112 is interpreted as the one or more additional repositories that include a plurality of codebase branches).
Claim(s) 3, 8, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of Larkin (US-20240289462-A1).
Regarding claim 3, Burrell in view of Spektor teaches the computer-implemented method of claim 1. Burrell teaches wherein the one or more scan results include one or more of indications of software [test failures] associated with one of the plurality of codebase branches … (Paragraph 21, "each task comprises information to perform a particular build step such as deploying source code to AWS ECS, deploying to Google cloud, deploying to Kubemetes, sending a notification to Slack, trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc. " Paragraph 117, “In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202.”).
However, Burrell in view of Spektor does not explicitly teach wherein the one or more scan results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches.
Larkin teaches … results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches. (Paragraph 47, "The primary objective of the Vulnerability Exploitability Exchange (VEX) is to provide engineering teams with the information necessary to determine whether a product is impacted by a specific vulnerability discovered in a dependency or operating system package." Paragraph 183, " The TIAP can automatically discover and prioritize application risks across application code, dependencies, container images, and web interfaces to help developers ship secure code faster." Paragraph 187, "The TIAP's report provides a much more comprehensive view of a developer's application, from the static image to the running container." Paragraph 50, "By providing a clear and up- to-date inventory of all the third-party components used in a software project, developers can use this information to identify any known vulnerabilities in the components …" The TIAP system scans the vulnerabilities of the codebase branch being analyzed, one aspect being dependencies, which third party ones are among).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell in view of Spektor’s CI/CD system with Larkin by enhancing Burrell in view of Spektor’s security analysis tasks to include detailed testing and results for application vulnerabilities, as taught by Larkin. The motivation is to ensure that the code that’s being tested gives developers detailed results regarding security, so they can rigorously ensure an application’s security.
Regarding claim 8, Burrell in view of Spektor teaches the computer-implemented method of claim 1. Burrell teaches further comprising displaying the one or more scan results … wherein the one or more scan results include … data associated with the plurality of codebase branches. (Paragraph 33, “Returning to the client devices 102, the web browser may be utilized to, for example, view test results provided by the feedback system 108.”).
However, Burrell in view of Spektor does not explicitly teach further comprising displaying the one or more scan results via an interactive dashboard, wherein the one or more scan results include statistical data …
Larkin teaches … one or more scan results via an interactive dashboard, wherein the one or more scan results include statistical data associated with the plurality of codebase branches. (Paragraph 157, "FIG. 8 shows an illustrative block diagram of an analytics service 800 according to an embodiment. Analytics service 800 can analyze collected events 802 and provide outputs 804 based on the analysis performed thereon. Analytics service 800 enables customers to understand the behavior and vulnerabilities of their applications by enabling customers to view in real-time statistics of the execution of their applications and to receive recommended remediation steps to resolve those vulnerabilities and to improve behavior," Paragraph 167, “The components contained in SBOM/Vulnerabilities 824 may be displayed in a user interface such as that shown in FIGS. 11 and 12.” Paragraph 170, “The UI may embody a “drill-down” concept. That is, starting at the highest level, a user may continuously refine their view to embody just what they want to see (via filtering, selecting applications/component groups/instances, and selecting timeline views). The UI can remain as consistent as possible during this refinement.” Applications are interpreted as codebase branches, the analytics service capable of viewing statistics of more than one application and displaying them to the user.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell in view of Spektor’s CI/CD system with Larkin by enhancing Burrell in view of Spektor’s testing system to include detailed statistics and results on an interactive dashboard, as taught by Larkin. The motivation is to ensure that the code that’s being tested gives developers detailed results regarding security, so they can rigorously ensure an an application’s functionality, with an interactive dashboard making testing result information easier to navigate through.
Regarding claim 13, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 11. Burrell teaches wherein the one or more scan results include one or more of indications of software [test failures] associated with one of the plurality of codebase branches … (Paragraph 21, "each task comprises information to perform a particular build step such as deploying source code to AWS ECS, deploying to Google cloud, deploying to Kubemetes, sending a notification to Slack, trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc. " Paragraph 117, “In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202.”).
However, Burrell in view of Spektor does not explicitly teach wherein the one or more scan results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches.
Larkin teaches … results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches. (Paragraph 47, "The primary objective of the Vulnerability Exploitability Exchange (VEX) is to provide engineering teams with the information necessary to determine whether a product is impacted by a specific vulnerability discovered in a dependency or operating system package." Paragraph 183, " The TIAP can automatically discover and prioritize application risks across application code, dependencies, container images, and web interfaces to help developers ship secure code faster." Paragraph 187, "The TIAP's report provides a much more comprehensive view of a developer's application, from the static image to the running container." Paragraph 50, "By providing a clear and up- to-date inventory of all the third-party components used in a software project, developers can use this information to identify any known vulnerabilities in the components …" The TIAP system scans the vulnerabilities of the codebase branch being analyzed, one aspect being dependencies, which third party ones are among).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell in view of Spektor’s CI/CD system with Larkin by enhancing Burrell in view of Spektor’s security analysis tasks to include detailed testing and results for application vulnerabilities, as taught by Larkin. The motivation is to ensure that the code that’s being tested gives developers detailed results regarding security, so they can rigorously ensure an application’s security.
Regarding claim 20, Burrell in view of Spektor teaches the system of claim 18. Burrell teaches wherein the one or more scan results include one or more of indications of software [test failures] associated with one of the plurality of codebase branches … (Paragraph 21, "each task comprises information to perform a particular build step such as deploying source code to AWS ECS, deploying to Google cloud, deploying to Kubemetes, sending a notification to Slack, trigger an alert using Opsgenie or analysing the code for security vulnerabilities with SourceClear, etc. " Paragraph 117, “In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.” Paragraph 118, “At step 342, the controller 208 receives the test results from the memory 209 and passes them to the results module 204 at step 343, via the API module 202.”).
However, Burrell in view of Spektor does not explicitly teach wherein the one or more scan results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches.
Larkin teaches … results include one or more of indications of software vulnerabilities associated with one of the plurality of codebase branches, third-party software dependency errors associated with one of the plurality of codebase branches, or secret/sensitive organizational data included in one of the plurality of codebase branches. (Paragraph 47, "The primary objective of the Vulnerability Exploitability Exchange (VEX) is to provide engineering teams with the information necessary to determine whether a product is impacted by a specific vulnerability discovered in a dependency or operating system package." Paragraph 183, " The TIAP can automatically discover and prioritize application risks across application code, dependencies, container images, and web interfaces to help developers ship secure code faster." Paragraph 187, "The TIAP's report provides a much more comprehensive view of a developer's application, from the static image to the running container." Paragraph 50, "By providing a clear and up- to-date inventory of all the third-party components used in a software project, developers can use this information to identify any known vulnerabilities in the components …" The TIAP system scans the vulnerabilities of the codebase branch being analyzed, one aspect being dependencies, which third party ones are among).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrell in view of Spektor’s CI/CD system with Larkin by enhancing Burrell in view of Spektor’s security analysis tasks to include detailed testing and results for application vulnerabilities, as taught by Larkin. The motivation is to ensure that the code that’s being tested gives developers detailed results regarding security, so they can rigorously ensure an application’s security.
Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of Douglas (US-20150261658-A1).
Regarding claim 5, Burrell in view of Spektor teaches the computer-implemented method of claim 4. However, Burrell in view of Spektor does not teach wherein the specifying of the subset of codebase branches is based on one or more priority levels associated with the plurality of codebase branches.
Douglas teaches wherein the specifying of the subset of codebase branches is based on one or more priority levels associated with the plurality of codebase branches. (Paragraph 39, “As further shown in FIG. 4, process 400 may include providing the request in a queue of requests to test other software (block 420). For example, scheduling server 220 may provide the request to test the software in a queue of requests to test other software on cloud test device 240. In some implementations, the queue may include a data structure (e.g., a table, a database, a list, etc.) that stores requests to test software based on priorities assigned to the requests by users that provided the requests (e.g., the user of user device 210 or other users). For example, the user may designate a priority (e.g., low importance, medium importance, high importance, etc.) for the request to test the software, and scheduling server 220 may provide the request in the queue based on the priority. In some implementations, scheduling server 220 may arrange the requests in the queue based on when the requests are received. For example, scheduling server 220 may provide the requests in a first-in, first-out (FIFO) arrangement in the queue, where a first received request may be provided first, a second received request may be provided second, etc. in the queue. In another example, scheduling server 220 may provide the requests in a last-in, first-out (LIFO) arrangement in the queue, where a last received request may be provided first, a second to last received request may be provided second, etc. in the queue.” The designated priority to a request for testing is interpreted as specifying a subset of codebase branches based on priority levels associated with the plurality of codebase branches. The plurality of codebase branches is interpreted as the different software tests being queued.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with Douglas, by enhancing Burrel in view of Spektor’s testing system and custom hooks to include a queueing process that carries out software testing requests based on a priority value, as taught by Douglas. The motivation is to provide a means for the testing system to efficiently handle automating testing in the situation many tests are assigned for it to do, with a queue preventing system overload, as well as providing a way to prioritize the testing of certain applications over others in the case the system is busy.
Regarding claim 15, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 14. However, Burrell in view of Spektor does not teach wherein the specifying of the subset of codebase branches is based on one or more priority levels associated with the plurality of codebase branches.
Douglas teaches wherein the specifying of the subset of codebase branches is based on one or more priority levels associated with the plurality of codebase branches. (Paragraph 39, “As further shown in FIG. 4, process 400 may include providing the request in a queue of requests to test other software (block 420). For example, scheduling server 220 may provide the request to test the software in a queue of requests to test other software on cloud test device 240. In some implementations, the queue may include a data structure (e.g., a table, a database, a list, etc.) that stores requests to test software based on priorities assigned to the requests by users that provided the requests (e.g., the user of user device 210 or other users). For example, the user may designate a priority (e.g., low importance, medium importance, high importance, etc.) for the request to test the software, and scheduling server 220 may provide the request in the queue based on the priority. In some implementations, scheduling server 220 may arrange the requests in the queue based on when the requests are received. For example, scheduling server 220 may provide the requests in a first-in, first-out (FIFO) arrangement in the queue, where a first received request may be provided first, a second received request may be provided second, etc. in the queue. In another example, scheduling server 220 may provide the requests in a last-in, first-out (LIFO) arrangement in the queue, where a last received request may be provided first, a second to last received request may be provided second, etc. in the queue.” The designated priority to a request for testing is interpreted as specifying a subset of codebase branches based on priority levels associated with the plurality of codebase branches. The plurality of codebase branches is interpreted as the different software tests being queued.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with Douglas, by enhancing Burrel in view of Spektor’s testing system and custom hooks to include a queueing process that carries out software testing requests based on a priority value, as taught by Douglas. The motivation is to provide a means for the testing system to efficiently handle automating testing in the situation many tests are assigned for it to do, with a queue preventing system overload, as well as providing a way to prioritize the testing of certain applications over others in the case the system is busy.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of Maréchal (US-20200348921-A1).
Regarding claim 6, Burrell in view of Spektor teaches the computer-implemented method of claim 1. However, Burrel in view of Spektor does not explicitly teach further comprising identifying, based on the one or more scripts, one or more top-level codebase branches and one or more nested codebase branches associated with the one or more top-level codebase branches.
Maréchal teaches further comprising identifying, based on the one or more scripts, (Paragraph 33, "For example, source code management system 204 may be configured with a “webhook” that is triggered in response to receiving the push request or merge request discussed above, and that webhook may provide for the sending of a Hyper Text Transfer Protocol (HTTP) request to the build dispatcher system 206 … For example, the HTTP request that provides the microservice modification request may include and/or identify information (e.g., via a build request payload)," the webhook is interpreted as the script. The build request payload is interpreted as what will be used for identification, this being based on the script's activation.)
one or more top-level codebase branches and one or more nested codebase branches associated with the one or more top-level codebase branches. (Paragraph 35, "For example, in the event the microservice modification request (e.g., an HTTP request) includes a request header that indicates that it is associated with a merge request (e.g., the “webhook” discussed above is a merge request webhook), the build dispatcher engine 304 may operate to extract, from the build request payload, one or more source branches that include the microservice modified code provided by the developer(s), a target branch with which the source branch(es) are requested to be merged with, a git Secure SHell (SSH) Uniform Resource Locator (URL) for the source code repository" Paragraph 36, "Continuing with the example above where the microservice modification request (e.g., an HTTP request) is associated with a merge request, at block 506 the build dispatcher engine 304 in the build dispatcher system 300 may operate to create a child thread and treat the microservice modification request by, for example, cloning the source code repository and calculating the difference between the source branch(es) and the target branch using, for example, a “git diff” operation with a “name-only” flag (e.g., “—name-only”) set. As will be understood by one of skill in the art in possession of the present disclosure, the use of the git diff operation with the name-only flag in the manner described above will return a list of file path(s) which have been modified.". The top-level codebase branch is interpreted as the target branch, the nested branch associated with the top-level branch interpreted as the modified source branch. The identifying step is interpreted as the system extracting the branch information, then performing a difference calculation between the two branches).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with Maréchal by enhancing Burrel in view of Spektor’s script testing system, in the case of a merge attempt, to include indications for the target branch to be merged against, as well as the modified branch to use to merge with the target branch, and then use those indications to calculate the differences between the two indicated branches, as taught by Maréchal. The motivation is to provide a more detailed way to perform testing, since by determining the differences between the source and target branches, software tests can be focused on the specifically changed parts a developer is attempting to push.
Regarding claim 16, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 11. However, Burrel in view of Spektor does not explicitly teach further comprising identifying, based on the one or more scripts, one or more top-level codebase branches and one or more nested codebase branches associated with the one or more top-level codebase branches.
Maréchal teaches further comprising identifying, based on the one or more scripts, (Paragraph 33, "For example, source code management system 204 may be configured with a “webhook” that is triggered in response to receiving the push request or merge request discussed above, and that webhook may provide for the sending of a Hyper Text Transfer Protocol (HTTP) request to the build dispatcher system 206 … For example, the HTTP request that provides the microservice modification request may include and/or identify information (e.g., via a build request payload)," the webhook is interpreted as the script. The build request payload is interpreted as what will be used for identification, this being based on the script's activation.)
one or more top-level codebase branches and one or more nested codebase branches associated with the one or more top-level codebase branches. (Paragraph 35, "For example, in the event the microservice modification request (e.g., an HTTP request) includes a request header that indicates that it is associated with a merge request (e.g., the “webhook” discussed above is a merge request webhook), the build dispatcher engine 304 may operate to extract, from the build request payload, one or more source branches that include the microservice modified code provided by the developer(s), a target branch with which the source branch(es) are requested to be merged with, a git Secure SHell (SSH) Uniform Resource Locator (URL) for the source code repository" Paragraph 36, "Continuing with the example above where the microservice modification request (e.g., an HTTP request) is associated with a merge request, at block 506 the build dispatcher engine 304 in the build dispatcher system 300 may operate to create a child thread and treat the microservice modification request by, for example, cloning the source code repository and calculating the difference between the source branch(es) and the target branch using, for example, a “git diff” operation with a “name-only” flag (e.g., “—name-only”) set. As will be understood by one of skill in the art in possession of the present disclosure, the use of the git diff operation with the name-only flag in the manner described above will return a list of file path(s) which have been modified.". The top-level codebase branch is interpreted as the target branch, the nested branch associated with the top-level branch interpreted as the modified source branch. The identifying step is interpreted as the system extracting the branch information, then performing a difference calculation between the two branches).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with Maréchal by enhancing Burrel in view of Spektor’s script testing system, in the case of a merge attempt, to include indications for the target branch to be merged against, as well as the modified branch to use to merge with the target branch, and then use those indications to calculate the differences between the two indicated branches, as taught by Maréchal. The motivation is to provide a more detailed way to perform testing, since by determining the differences between the source and target branches, software tests can be focused on the specifically changed parts a developer is attempting to push.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of McCorkendale (US-9083527-B1).
Regarding claim 7, Burrell in view of Spektor teaches The computer-implemented method of claim 1. Burrell teaches wherein copying the plurality of codebase branches is based on one or more of authentication, identification, or permission information … (Paragraph 106, "Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. To that end, the repository container 218 may pass the authorization token received in the previous step to the SCM system 104. The SCM system 104 inspects this authorization token to determine whether the repository container 218 is allowed access to the SCM repository 112. If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218." Paragraph 73, "According to the OAuth standard, the CI enabled repositories 112 share secrets with the CI management system 106. Based on these secrets, the CI management system 106 generates authorization tokens when it performs a build for a repository." It is interpreted as using permission information with the authorization token.).
However, Burrell in view of Spektor does not explicitly teach wherein [access] is based on one or more of authentication, identification, or permission information included in a secrets database.
McCorkendale teaches wherein [access] is based on one or more of authentication, identification, or permission information included in a secrets database. (Col. 2 lines 66-67 - Col. 3 lines 1-10, "The shared secret can be used in second-factor authentication. For example, a user may request access to a VPN network and the mobile phone can perform a hash on at least a portion of the shared secret that is stored on the mobile phone to create an authorization token. The mobile phone can send the authorization token to the server. The server can perform a hash on at least a portion of the shared secret that is stored by the server to generate an authorization token. The server can determine whether the authorization token generated by the server matches the authorization token received by the mobile device." Col. 6 lines 18 – 33, "The shared secret 265 generated by the secret generator sub-module 257 in the server shared-secret module 250 can be stored in the data store 260. The shared secrets 225,265 can be strings that can be subsequently used in second-factor authentication." The data store 260’s secret 265 is interpreted as permission information information. The data store is interpreted as a secrets database.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with McCorkendale by enhancing Burrel in view of Spektor’s repository system to enhance its storage system to additionally act like a secrets database, where it stores secret information for verifying authorization information, as taught by McCorkendale. The motivation is to strengthen security by keeping certain secret data stored directly on the repository system, so it can verify authorization tokens locally.
Regarding claim 17, Burrell in view of Spektor teaches the one or more non-transitory computer-readable media of claim 11. Burrell teaches wherein copying the plurality of codebase branches is based on one or more of authentication, identification, or permission information … (Paragraph 106, "Next, at step 322, the repository container 218 communicates with the SCM system 104 to retrieve source code 221 from an SCM repository 112. To that end, the repository container 218 may pass the authorization token received in the previous step to the SCM system 104. The SCM system 104 inspects this authorization token to determine whether the repository container 218 is allowed access to the SCM repository 112. If permission is granted, the SCM system 104 retrieves the latest updated source code 221 from the SCM repository 112 and forwards it to the repository container 218." Paragraph 73, "According to the OAuth standard, the CI enabled repositories 112 share secrets with the CI management system 106. Based on these secrets, the CI management system 106 generates authorization tokens when it performs a build for a repository." It is interpreted as using permission information with the authorization token.).
However, Burrell in view of Spektor does not explicitly teach wherein [access] is based on one or more of authentication, identification, or permission information included in a secrets database.
McCorkendale teaches wherein [access] is based on one or more of authentication, identification, or permission information included in a secrets database. (Col. 2 lines 66-67 - Col. 3 lines 1-10, "The shared secret can be used in second-factor authentication. For example, a user may request access to a VPN network and the mobile phone can perform a hash on at least a portion of the shared secret that is stored on the mobile phone to create an authorization token. The mobile phone can send the authorization token to the server. The server can perform a hash on at least a portion of the shared secret that is stored by the server to generate an authorization token. The server can determine whether the authorization token generated by the server matches the authorization token received by the mobile device." Col. 6 lines 18 – 33, "The shared secret 265 generated by the secret generator sub-module 257 in the server shared-secret module 250 can be stored in the data store 260. The shared secrets 225,265 can be strings that can be subsequently used in second-factor authentication." The data store 260’s secret 265 is interpreted as permission information information. The data store is interpreted as a secrets database.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Burrel in view of Spektor’s CI/CD system with McCorkendale by enhancing Burrel in view of Spektor’s repository system to enhance its storage system to additionally act like a secrets database, where it stores secret information for verifying authorization information, as taught by McCorkendale. The motivation is to strengthen security by keeping certain secret data stored directly on the repository system, so it can verify authorization tokens locally.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of Adams (US-20210200834-A1).
Regarding claim 9, Burrel in view of Spektor teaches the computer-implemented method of claim 1. Burrel in view of Spektor does not teach further comprising assigning one of the plurality of codebase branches to one of the plurality of container tasks based on a queue of codebase branches.
Adams teaches further comprising assigning one of the plurality of codebase branches to one of the plurality of container tasks based on a queue of codebase branches. (Paragraph 2, "Embodiments described herein relate to collaborative software development environments and, in particular, to systems and methods for asynchronously performing static analysis on a clone of a given code repository in response to one or more repository event triggers." Paragraph 50, "The images or virtual machines may be discrete files or disk image files that, when accessed by a processor of the centralized repository security service, instantiate a container or virtual machine configured to perform one or more static analysis operations or tasks." Paragraph 84, "paragraph 84 respond to repository events by cloning an associated repository and pull changes that triggered each repository event; enqueue repository events received." The repository events being queued means there is a queuing up of security analysis jobs on the service for the repository/codebase branches, and since the machine uses containers to run the application, these analysis jobs are assigned to container tasks.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to enhance Burrel in view of Spektor’s CI/CD system with Adams by enhancing Burrel in view of Spektor’s testing system to incorporate a queuing system of repository events/security analysis jobs, as taught by Adams. The motivation would be to prevent an overconsumption of server resources when a codebase branch is to be analyzed for security purposes, instead allocating server resources as needed.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Burrell (US-20200201748-A1) in view of Spektor (US-20170010889-A1), in further view of Chen (US-20170010956-A1).
Regarding claim 10, Burrel in view of Spektor teaches the computer-implemented method of claim 1. Burrell teaches … one or more of the plurality of copied codebase branches from the clone database … (Paragraph 117, “Next, at step 341 the task container 226 compiles the task script, retrieves the source code 221 and executes the complied task script on the source code 221. In one embodiment, the task container 226 writes the test results and errors in a file and this file may be stored back in the shared memory 209.”).
Burrel in view of Spektor does not explicitly teach further comprising removing one or more of the [loaded code] from the clone database after execution of the one or more scanning operations.
Chen teaches further comprising removing one or more of the [loaded code] from the clone database after execution of the one or more scanning operations. (Paragraph 6, “Generally speaking, dynamic symbolic execution runs the tested software, collects path conditions while execution and generating new test cases after calculating on the path conditions. Theoretically, dynamic symbolic execution technique can test the software thoroughly because the newly generated test cases can cover all the unexecuted paths.” Paragraph 24, “the tested software and test cases are uploaded to the embedded system through the debugger and the debug agent from the host system; the concrete execution kernel module starts the tested software; the symbolic execution kernel module captures the run-time information of the tested software through the debugger;” Paragraph 52, “(5) Search the entry of the tested software and set a breakpoint at the entry; when the tested software begins to run, a TEXT_ACCESS will be triggered;” Paragraph 61, “(f) Judge whether current instruction should be symbolically executed; if yes, then symbolically execute this instruction; one thing should be indicated is that basically the code of symbolic execution for single instruction is re-used from SMAFE;” Paragraph 63, “The process for handling CTX_EXIT is rather easy, it mainly focuses on cleaning the system after finishing executing the tested software, and includes unload the tested software and release the memory space occupied by symbolic execution.” The running of the tested software with symbolic execution interpreted as a code analysis operation, where after the code is fully analyzed/tested, it unloads/removes it and everything else from the memory.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to enhance Burrel in view of Spektor’s CI/CD system with Chen by enhancing Burrel in view of Spektor’s memory management system to unload code from memory after a code analysis process is completed, as taught by Chen. The motivation is to prevent the system from getting cluttered, by making sure to remove software from memory when the testing of it is complete, since keeping the software in memory after being tested is a needless consumption of resources.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
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, Rupal Dharia can be reached at 571-272-3880. 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.
/M.H.R./Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights