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 Amendment
This communication is in response to the amendment filed on 6/1/2026. The Examiner acknowledges amended claims 1-20. No claims have been cancelled or added. Claims 1-20 are pending and claims 1-20 are rejected. Claims 1, 12, and 17 is/are independent.
The rejection(s) of claims under 35 U.S.C. § 112 are withdrawn in view of Applicant's amendment.
The rejection(s) of claims under 35 U.S.C. § 101 are withdrawn in view of Applicant's amendments.
The rejection(s) of claims under 35 U.S.C. § 103 have been updated based on new grounds of rejection as indicated below.
Response to Arguments
Applicant's arguments filed 6/1/2026 have been fully considered and are persuasive with respect to claims 12-20, and unpersuasive with respect to claims 1-11.
Regarding claim 1, applicant argues (see Remarks, bottom half of page 9) that:
Claim 1, as amended herein, recites, in part:
modifying the multiple scanners to enable the multiple scanners to interact with a repository scanning coordinator;
Kissel describes "Efficient Scanning of Stream Based Data" (Title). However, neither Kissel, Jennings nor Hosseini does not teach or suggest "modifying the multiple scanners to enable the multiple scanners to interact with a repository scanning coordinator" as recited in amended claim 1. This aspect of FIG. 1 is illustrated for example in FIG. 2, as described at paragraph 0050:
[0050] Each of the scanners 201-205 can comprise or can be
supplemented with a coordinator interaction component which enables the scanner to interact with the repository scanning coordinator 220. Scanner A 201 is equipped with coordinator interaction component 210A, scanner B 202 is equipped with
coordinator interaction component 210B, scanner C 203 is equipped with coordinator interaction component 210C, and scanner N 205 is equipped with
coordinator interaction component 210N.
At least this element of claim 1 would not have been obvious in view of Kissel, Jennings and Hosseini, as discussed during the interview. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 1.
Examiner respectfully disagrees. Claim 1 continues to be rejected by the combination of Kissel et al. U.S. Publication 20040158732 (hereinafter “Kissel”) in view of Jennings et al. U.S. Patent No. 11893120 (hereinafter “Jennings”), further in view of Hosseini et al. U.S. Publication 20230262085 (hereinafter “Hosseini”).
Examiner submits that repository scanning coordinator can be disclosed by the stream manager of the Kissel reference, which performs most of the functions recited in claim 1, and Jennings teaches performing updating, by the repository scanning coordinator, an availability status of a previous source code repository scanned by the scanner to indicate the previous source code repository is available for scanning by other scanners. The limitation of modifying the multiple scanners to enable the multiple scanners to interact with a repository scanning coordinator can be disclosed by Kissel describing implementing the scanners as software as part of a larger program.
Alternatively, repository scanning coordinator can also be disclosed by a processor of a computer because the processor would perform the functions if the software components are performing those functions based on the execution of the processor. Kissel does not describe processor details but the teachings of the Jennings reference can be applied to modify the Kissel system to include a processor as described in the Jennings reference to perform the functions as recited in claim 1.
Regarding claims 12 and 17 and applicant’s argument on page 10, 3rd paragraph, and page 11, 2nd to 4th paragraph, applicant’s argument is persuasive with respect to the rejections against claims 12-20. Therefore, the rejections are withdrawn with respect to claims 12-20. However, a newly cited reference McAllister et al. U.S. Publication 20200082095 (hereinafter “McAllister”) teaches that a schema translator may be configured to translate commands and data between API schemas and data schemas specific to each scanner application. The combination of Kissel, Jennings, Hosseini and McAllister discloses the limitations of independent claims 12 and 17.
Regarding applicant’s arguments with respect to the dependent claims, the dependent claims inherit the limitations of the independent claims from which the dependent claims depend and are rejected for the same reasons. Furthermore, the dependent claims do not recite additional limitations that are allowable, as indicated in the office action below.
Accordingly, Applicant's arguments/amendments have been fully considered, and are persuasive with respect to claims 12-20, and unpersuasive with respect to claims 1-11. Claims 12-20 are rejected based on new grounds of rejection. Note that this action is made FINAL. See MPEP § 706.07(a).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-5, 7, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel et al. U.S. Publication 20040158732 (hereinafter “Kissel”) in view of Jennings et al. U.S. Patent No. 11893120 (hereinafter “Jennings”), further in view of Hosseini et al. U.S. Publication 20230262085 (hereinafter “Hosseini”).
As per claim 1, Kissel discloses
A method to coordinate parallel scan operations of multiple scanners, [allows all scanners 109, 111 to scan in parallel, para. 59] comprising:
[0009] The present invention comprises methods, 1 …for utilizing a stream manager (101) to efficiently scan stream (105) based data (105).
[0059] FIG. 9 illustrates steps for efficiently scanning stream based data, according to yet other embodiments of the present invention. These embodiments leverage the fact that modify scanners 109 will often not modify data 103. In these embodiments, the stream manager 101 assumes that no modify scanner 109 will actually modify data 103, and thus allows all scanners 109, 111 to scan in parallel, in order to increase the speed of data 103 throughput. Only when a modify scanner 109 actually does modify a unit of data 103 is it necessary for that data 103 to be rescanned in order to ensure data integrity.
modifying [implementing the scanners as software as part of a larger program or as part of a plurality of separate programs, para 63] the multiple scanners [allows all scanners 109, 111 to scan in parallel, para. 59; plurality of modify scanners, para 11] to enable the multiple scanners to interact [stream manager (101) making (807) received data (103) serially available to a plurality of modify scanners (109) in a specific order, para 11] with a repository scanning coordinator;[ stream manager, para 11]
[modifying the multiple scanners is disclosed by implementing the multiple scanners as part of the larger program or separate programs that includes the stream manager as discussed in the combination of para 11 and 63]
[0011] the stream manager (101) making (807) received data (103) serially available to a plurality of modify scanners (109) in a specific order, such that data (103) is made available to a next modify scanner (109) after it has been released by a previous modify scanner (109);
[0063] the modules, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment.
for a scanner of the multiple scanners:[ scanners 109, 111, para. 38]
[for a scanner can be interpreted under broadest reasonable interpretation as performing for the scanner, and the claim does not require that all of the method steps be performed by the scanner]
para. 38 Returning to FIG. 1, in some embodiments of the present invention, the stream manager 101 stores data 103 in a cache 107 as the data 103 is received from the stream 105. The stream manager 101 then removes data 103 from the cache 107 as the data 103 is transmitted to a destination 113. By performing as much scanning in parallel as possible, and by transmitting data 103 to the destination as soon as it has been released by the scanners 109, 111, the present invention allows for the cache 107 to be kept as small as possible.
receiving, by the repository scanning coordinator,[ stream manager , para 56] a request for a scan to be performed by the scanner;
[0056] The stream manager 101 makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data 103. The stream manager 101 also makes 809 requested data 103 available in parallel to each read-only scanner 111 that requests to scan that data 103.
in response to a scan request, enabling, by the repository scanning coordinator,[ stream manager, para 56] a next source code repository [makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data 103, para. 56; malicious code in undesirable content… detect and process malicious code, para. 2; the streams can include code which means that the origin of the streams is disclosing source code repository ] to be scanned by the scanner, [next modify scanner (109), para. 11] wherein the next source code repository has an availability status [the stream manager (101) making (807) received data (103) serially available to a plurality of modify scanners (109) in a specific order, such that data (103) is made available to a next modify scanner (109) after it has been released by a previous modify scanner (109), para. 11; make the released portion 203 available to the plurality of modify scanners 109 in serial, para. 37; informs 803 each of a plurality of modify scanners 109 and each of a plurality of read-only scanners 111 that received data 103 is available for scanning, para. 55] indicating the next source code repository is available for scanning;
[the specification and the claim does not define source code repository. Also scanning source code repository under the broadest reasonable interpretation could mean simply choosing to scan a single file associated with the repository. The claim and specification does not specify the scope of the scan, for example, scan only a manifest from the source code repository, scan 5 percent of the source code repository, or scan the entire source code repository]
[0002] It is often desirable to scan data before allowing it into a computer or a computer network. Data can contain undesirable content, such as malicious code (e.g. a computer virus), or content which is not permitted within a specific computing environment (e.g. entertainment material within a business environment). Scanning an inbound stream of data prior to allowing it into a computing environment can detect undesirable content, and either block the entry of the data, or modify the data so as to remove the undesirable content. Similarly, scanning an outbound stream of data prior to allowing it to leave a computing environment can detect and process malicious code originating from that organization's computer network.
updating, by the repository scanning coordinator,[ stream manager, para 56] the availability status [“after it has been released by a previous modify scanner (109)”, para. 11; this means that in Kissel, prior to release, the data being scanned is not available for scanning by other scanners] of the next source code repository to indicate the next source code repository is unavailable [“available to the plurality of modify scanners 109 in serial” para. 37; this means in Kissel only one scanner at a time can scan the data that is made available for scanning in serial ] for scanning by the other scanners. [There are multiple scanners performing scans, such as “plurality of modify scanners 109” at para. 37]
[0037] Likewise, a read-only scanner 111 can release a portion 203 of a data packet 201, and continue to scan an unreleased portion 203. Once each read-only scanner ill has released a portion 203 of a packet 201, the stream manager 101 can make the released portion 203 available to the plurality of modify scanners 109 in serial, or can transmit the released portion 201 to a destination 113.
However, Kissel does not expressly disclose
series of scan requests for scans
in the series of scan requests
updating, by the repository scanning coordinator, an availability status of a previous source code repository scanned by the scanner to indicate the previous source code repository is available for scanning by other scanners; and
[Kissel also does not disclose multiple source code repositories (only a single data stream is disclosed in Kissel)]
Jennings discloses updating, by the repository scanning coordinator, an availability status [repository scanning coordinator can be disclosed by the processor 19:5; “processor 152 may be configured to store dependency tree 144 in software package database” 19:5-6…”storing the at least a dependency tree 144 may further include storing a scan count,”… 19:33-34; storing the scan count of a dependency tree/manifest file, which indicates that the dependency tree/manifest file has been scanned and now is available for further scanning 19:33-36] of a previous source code repository [dependency tree including APIs, libraries, 15:60-63 ] scanned [scanning the manifest file of the dependency tree 19:33-36 ] by the scanner[processor 18:64-66] to indicate the previous source code repository is available [the scan count when stored indicates the dependency tree/manifest file is available for further scanning 19:33-36] for scanning by other scanners; and
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that can be downloaded such as “actual number of downloads for a package or library” 9:22-26;
the specification and the claim does not define source code repository and does not define the scope of what it means to scan a source code repository]
9:22-26 In some cases, software package data 116 may include information involving one or more download counts, wherein a download count is an actual number of downloads for a package or library or a bucketization of download counts (the numbers broken into discrete bins).
Jennings 4:29-32 (14) With continued reference to FIG. 1, as used in this disclosure, a “software component” is a library and/or collection of files that make up an application and/or program.
4:48-61 software component 112 may include a software package comprising a collection of files that make up an application or capability, which may include binary executables, libraries, source text files, documentation files, scripts, and the like thereof, however a library may sometimes be referred to as a package in certain language directives. In another embodiment, and without limitation, software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language. In another embodiment, and without limitation, software component may include one or more system packages that may become part of the operating system resources and may be used by any script or program.
15:60-63 nodes of dependency tree 144 may further include software component 112 such as APIs, libraries, licenses, and the like thereof.
18:64-66
(39) With continued reference to FIG. 1, processor 152 is further configured to store the at least a dependency tree 144 in a database.
19:17-27 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.”
Jennings 19:33-36 storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for a processor tracking a scan count of a software package of Jennings to include updating, by the repository scanning coordinator, an availability status of a previous source code repository scanned by the scanner to indicate the previous source code repository is available for scanning by other scanners; and
One of ordinary skill in the art would have made this modification to improve the ability of the system to keep track of the progress in scanning a software package, especially when there are multiple scanners and multiple scans are required. The system of the primary reference can be modified to track a scan count for a stream in order to track how many scans have been performed on a stream. The stream may include software code as described in the primary reference at para. 2. The system of the primary reference can also be modified so that there are multiple software packages being downloaded through multiple streams, based on the teachings of this Jennings reference at 4:48-61 and 9:22-26.
The teaching of the tracking of the scan count by the processor as taught in the Jennings reference can be applied to modify the system of the primary reference. The primary reference does not explicitly discuss processors but the repository scanning coordinator can be disclosed by a processor such as that described in the Jennings reference also, and the system of the primary reference can be modified to include a processor as described in the Jennings reference to perform the functions for the reasons indicated above.
However, the combination of Kissel and Jennings does not expressly disclose
receiving a series of scan requests for scans to be performed by the scanner;
in response to a scan request in the series of scan requests, enabling a next source code repository to be scanned by the scanner, wherein the next source code repository has an availability status indicating the next source code repository is available for scanning;
Hosseini discloses receiving scan requests from a scan request queue
[0054] Turning to process 500 in greater detail, at block 505, a first scanning request can be received. The scanning request can be received at the root routing namespace 414 from the admin VCN 432. Scan workflow 110 can poll for scan requests from scan request queue 102. The scan workflow can poll for scan requests from scan request queue 102 through Admin VCN 432. The packet containing the first scanning request can be sent from admin host subnet 434 to root routing namespace 414 via VNIC-2 424 and attachment 430e. The first scanning request can identify one or more targets to be scanned in one or more different VCNs controlled by one or more customers.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for receiving scan requests from a scan request queue
of Hosseini to include
receiving a series of scan requests for scans to be performed by the scanner;
in response to a scan request in the series of scan requests, enabling a next source code repository to be scanned by the scanner, wherein the next source code repository has an availability status indicating the next source code repository is available for scanning;
One of ordinary skill in the art would have made this modification to improve the ability of the system to manage a series of scan requests, by putting the scan requests in the queue until the requests are ready to be acted upon. The system of the primary reference can be modified to utilize the queue to store a series of scan requests until the requests are each ready to be acted upon.
As per claim 3, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel and Jennings does not expressly disclose wherein the repository scanning coordinator comprises an application programming interface configured to receive the series of scan requests.
Hosseini discloses wherein the repository scanning coordinator comprises an application programming interface configured to receive the series of scan requests.
[0033] The logical cloud function 104 can include an application programming interface (API) handler 106. An API can be software that permits applications to communicate. Logical cloud function 104 can include a scanner database 108. The scanner database 108 can provide state for API requests and individual scans. Logical cloud function 104 can include a scan workflow 110. Scan workflow 110 can support parallel scans or targeted scanning using a subset of vulnerability checks.
[0042] Turning to process 300 in greater detail, at block 305 a scanning request can be received. The scanning request can be obtained by root routing namespace 214 from the admin host subnet 234 in the admin VCN 232. A scanning request can be received at the API handler 106 or the scan workflow 110 from FIG. 1, and the received scanning request can be enqueued to scanning request queue 102. The scanning request can be obtained by polling scan request queue 102 via admin host subnet 234 or admin VCN 232.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include wherein the repository scanning coordinator comprises an application programming interface configured to receive the series of scan requests.
One of ordinary skill in the art would have made this modification to improve the ability of the system to utilize APIs to facilitate sending and receiving scan requests. The system of the primary reference can be modified so that the stream manager utilizes APIs to send and receive scan requests, and to have an API handler to receive and handle the received API requests.
As per claim 4, the rejection of claim 3 is incorporated herein.
However, the combination of Kissel and Jennings does not expressly disclose wherein modifying the multiple scanners to enable the multiple scanners to interact with the repository scanning coordinator comprises configuring at least one of the multiple scanners to communicate with the application programming interface.
Hosseini discloses configuring at least one of the multiple scanners to communicate with the application programming interface.
[See Hosseini figure 1 which shows the scanner 114 communicatively connected to the API handler 106.] It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests and pass off scan requests to a scanner of Hosseini to include wherein modifying the multiple scanners to enable the multiple scanners to interact with the repository scanning coordinator comprises configuring at least one of the multiple scanners to communicate with the application programming interface.
One of ordinary skill in the art would have made this modification to improve the ability of the system to utilize APIs to facilitate sending and receiving scan requests, to facilitate scanning by the scanners. The system of the primary reference can be modified to utilize APIs to send and receive scan requests, and to have an API handler to receive and handle the received API requests, to facilitate scanning by the scanners.
As per claim 5, the rejection of claim 1 is incorporated herein.
Kissel discloses passing the address of the data to be scanned to the scanner
[0031] It will be understood by those of ordinary skill in the relevant art that making data 103 available to a scanner 109, 111 can comprise passing the address of the data 103 to the scanner 109, 111, passing a copy of the data 103 to the scanner 109, 111, or otherwise informing the scanner 109, 111 that the data 103 is available for scanning.
However, Kissel does not expressly disclose further comprising retrieving and storing multiple source code repositories in a filesystem, the multiple source code repositories including the previous source code repository and the next source code repository.
Jennings discloses downloading multiple source code repositories to a filesystem and scanning multiple trees/software packages
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that can be downloaded such as “actual number of downloads for a package or library” 9:22-26; the filesystem is disclosed because files such as executables and source text files are stored
18:47-53 multiple repositories also disclosed based on comparing first dependency tree and second dependency tree; dependency trees which correspond to software packages may be labeled as scanned or scanning progress etc. which discloses previously scanned and next to be scanned 19:17-36 ]
19:17-36 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.” In some embodiments, storing dependency tree 144 may further include storing a software package vulnerability count, wherein the software vulnerability count is a variable representing number of existing software package vulnerability 128 found in software component 112 based on manifest file 108. In some embodiments, storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
Jennings 18:47-53 comparing first dependency tree and second dependency tree may further include traversing both dependency trees using tree traversal method disclosed above.
9:22-26 In some cases, software package data 116 may include information involving one or more download counts, wherein a download count is an actual number of downloads for a package or library or a bucketization of download counts (the numbers broken into discrete bins).
4:29-32 (14) With continued reference to FIG. 1, as used in this disclosure, a “software component” is a library and/or collection of files that make up an application and/or program.
Jennings 4:48-61 software component 112 may include a software package comprising a collection of files that make up an application or capability, which may include binary executables, libraries, source text files, documentation files, scripts, and the like thereof, however a library may sometimes be referred to as a package in certain language directives. In another embodiment, and without limitation, software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language. In another embodiment, and without limitation, software component may include one or more system packages that may become part of the operating system resources and may be used by any script or program.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for downloading multiple source code repositories to a filesystem and scanning multiple trees/software packages of Jennings to include further comprising retrieving and storing multiple source code repositories in a filesystem, the multiple source code repositories including the previous source code repository and the next source code repository.
One of ordinary skill in the art would have made this modification to improve the ability of the system to scan multiple downloaded source code repositories. The system of the primary reference can be modified to include multiple source code repositories (e.g., software packages with executables, libraries, source text files, etc. 4:48-61 Jennings) being downloaded and passing the address (Kissel [0031]) of the next repository to the scanner for scanning.
As per claim 7, the rejection of claim 1 is incorporated herein.
However, Kissel does not expressly disclose
wherein the enabling the next source code repository to be scanned by the scanner comprises identifying the next source code repository from a library of source code repositories, and the method further comprising generating the library of source code repositories.
Jennings discloses creating a robust repository at 13:33-38 based on software package information and identifying the next repository to be scanned [the Jennings scan status indicating no scan or in queue indicates the next repository to be scanned 19:17-27; even having the scan number indicates that the dependency tree can be scanned 19:33-36]
[generating the library of source code repositories can be interpreted as generating portions of the repositories in order to complete the repository contents or to facilitate storing repository contents, under the broadest reasonable interpretation]
1:39-43 (4) generating, using the at least a processor, at least a dependency tree as a function of the software package data, and storing, using the at least a processor, the dependency tree in a database.
13:33-38 Further, software package database 136 may serve to create a robust repository that in part is used to assist in generating dependency tree 144. Dependency tree 144 and generation of dependency tree 144 disclosed here will be described in further detail below.
19:17-27 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.”
19:33-36 storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
15:60-63 nodes of dependency tree 144 may further include software component 112 such as APIs, libraries, licenses, and the like thereof.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for creating a robust repository based on software package information and identifying the next repository to be scanned of Jennings to include wherein the enabling the next source code repository to be scanned by the scanner comprises identifying the next source code repository from a library of source code repositories, and the method further comprising generating the library of source code repositories.
One of ordinary skill in the art would have made this modification to improve the ability of the system to determine the next source code repository to scan and facilitate generating repositories. The system of the primary reference can be modified to generate a robust repository based on software package information and determining a next repository software package/dependency tree to scan from the collection of repositories/software packages/dependency trees.
As per claim 11, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel and Jennings does not expressly disclose
receiving a registration request to register a new scanner among the multiple scanners; and
registering the new scanner in response to the registration request.
Hosseini discloses receiving a registration request to register a new scanner among the multiple scanners; and [new scanner instance is created and then has its own routing namespace, para. 30; scanner instance and a virtual network interface card (VNIC) can be generated in response to the scanning request, para. 68; the scan request can disclose a request to generate and register new scanner]
registering [creating dedicated scanner routing namespace, para. 30; configuring routing rules to a scanner instance, para. 31] the new scanner in response to the registration request.
[Hosseini discloses creating a new scanner instance with its own dedicated scanner routing namespace]
[0030] This scanner routing namespace can have one scanner instance. Additional scanner instances can exist, and each scanner instance can use its own dedicated scanner routing namespace. The scanner instances can be created during initial host configuration and can be re-used between requests.
[0068] At block 610, for at least two of the two or more scanning requests, a scanner instance and a virtual network interface card (VNIC) can be generated in response to the scanning request. A scanner instance and VNIC can be generated for two or more scanning requests identifying separate VCNs (e.g., VCN 432). The scanner instance and VNIC can include a scanning infrastructure as described above in relation to FIGS. 4 and 5. The scanning infrastructure can include one or more of a scan route table (e.g., scan route table-N 474), a root routing table (e.g., root route table 462), a routing module (e.g., routing module 460), a VNIC route table (e.g., VNIC-N route table 482), a VNIC namespace (e.g., VNIC-N namespace 458), or a VNIC (e.g., VNIC-N 466).
[0031] To perform each scan, the target address and the target network (e.g., the network containing the target address) can be used to configure route rules in the one or more routing tables to create a pipeline from the scanner instance to the target address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for creating a new scanner instance with its own dedicated scanner routing namespace of Hosseini to include receiving a registration request to register a new scanner among the multiple scanners; and
registering the new scanner in response to the registration request.
One of ordinary skill in the art would have made this modification to improve the ability of the system to create new scanners and utilize the scanners. The system of the primary reference can be modified so that when a new scanner instance is created a new namespace is also assigned to the new scanner instance.
Claims 2 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, further in view of Larsen et al. U.S. Publication 20130312096 (hereinafter “Larsen”).
As per claim 2, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
further comprising updating, by the repository scanning coordinator, a log to indicate the previous source code repository was scanned by the scanner, and wherein identifying the next source code repository to be scanned by the scanner further comprises determining that the next source code repository is unscanned by the scanner.
Larsen discloses logging items that have been scanned and determining yet to be scanned items
[0024] Note that the agent keeps a record of the current scan state information on the guest VM. The scan state information includes, for example, the scope of the scan (e.g., list of files or directories to be scanned), files with completed scans, files currently being scanned, and files yet to be scanned within the scope.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for logging items that have been scanned and determining yet to be scanned items of Larsen to include
further comprising updating, by the repository scanning coordinator, a log to indicate the previous source code repository was scanned by the scanner, and wherein identifying the next source code repository to be scanned by the scanner further comprises determining that the next source code repository is unscanned by the scanner.
One of ordinary skill in the art would have made this modification to improve the ability of the system to keep track of which repositories have been scanned and which repositories have yet to be scanned. The system of the primary reference can be modified to keep records of the current scan state of the repositories/dependency trees in order to determine the next one to be scanned.
As per claim 10, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
wherein identifying, in response to the scan request, the next source code repository to be scanned by the scanner further comprises determining that the next source code repository meets a tag criterion specified in a tag associated with the scanner.
Larsen discloses determining the state information of an object to determine whether to scan the object next
[0024] Note that the agent keeps a record of the current scan state information on the guest VM. The scan state information includes, for example, the scope of the scan (e.g., list of files or directories to be scanned), files with completed scans, files currently being scanned, and files yet to be scanned within the scope. … determines whether any scan has been previously performed on the guest VM. If so, the library provides the state information to the corresponding security application on the scanning VM, which in turn resumes the scan operation.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for determining the state information of an object to determine whether to scan the object next of Larsen to include
wherein identifying, in response to the scan request, the next source code repository to be scanned by the scanner further comprises determining that the next source code repository meets a tag criterion specified in a tag associated with the scanner.
One of ordinary skill in the art would have made this modification to improve the ability of the system to keep track of which repositories have been scanned and which repositories have yet to be scanned. The system of the primary reference can be modified to keep records of the current scan state of the repositories/dependency trees in order to determine the next one to be scanned.
Claim 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, further in view of Wang et al. U.S. Publication 20240419458 (hereinafter “Wang”).
As per claim 6, the rejection of claim 5 is incorporated herein.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
wherein retrieving the multiple source code repositories comprises one or more global information tracker (GIT) interactions to fetch the multiple source code repositories.
Wang discloses acquiring git addresses corresponding to batches of algorithms from the code storage server and acquiring the corresponding algorithm code through the git addresses
[0149] Source code management module: selecting a GIT (Global Information Tracker) and setting a corresponding GIT parameter. In an exemplary embodiment, setting the GIT parameter may be setting a GIT address that may be an SVN address for accessing the code storage server.
[0157] In an exemplary embodiment, the operation and maintenance platform acquires the corresponding algorithm code through the git address, and when the algorithms are launched or the algorithms are detected in batches, the operation and maintenance platform can acquire git addresses corresponding to batches of algorithms from the code storage server through jenkins, and acquire a plurality of corresponding algorithm codes according to the git addresses, thereby realizing the algorithm launching or the algorithm detection in batches. In an exemplary implementation, a same git address may correspond to a plurality of algorithms in a batch of algorithms, or each algorithm may correspond to one git address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for acquiring git addresses corresponding to batches of algorithms from the code storage server and acquiring the corresponding algorithm code through the git addresses of Wang to include wherein retrieving the multiple source code repositories comprises one or more global information tracker (GIT) interactions to fetch the multiple source code repositories.
One of ordinary skill in the art would have made this modification to improve the ability of the system to determine the address for acquiring source code from a server. The system of the primary reference can be modified so that the system acquires addresses corresponding to source code from a code storage server and then utilize the addresses to acquire corresponding source code.
Claim 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, further in view of Holostov et al. U.S. Publication 20080295176 (hereinafter “Holostov”).
As per claim 8, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
receiving, by the repository scanning coordinator, a repository branch scan request for a repository branch scan to be performed by the scanner; and
retrieving and storing, by the repository scanning coordinator, a repository branch in a filesystem in response to the repository branch scan request.
Holostov discloses receiving a request to download and scan a portion of an object, and retrieving and storing the portion of the object in a filesystem
[0006] Described herein are, among other things, embodiments of various technologies for use in anti-virus scanning of content. In accordance with one embodiment, client devices transmit requests for a download of content via a network gateway to a server. The requests indicate specific portions of the content to be transmitted and the order that the portions should be transmitted. The gateway receives in its memory the requecsted portions of the content. The portions are assembled into blocks and are arranged in the same sequence as when they were stored on the server. This arrangement may be different than the sequence that the portions were received via the network. The gateway scans the block with the largest contiguous number of portions for a virus as the requested portions of the file are received.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for receiving a request to download and scan a portion of an object, and retrieving and storing the portion of the object in a filesystem of Holostov to include
receiving, by the repository scanning coordinator, a repository branch scan request for a repository branch scan to be performed by the scanner; and
retrieving and storing, by the repository scanning coordinator, a repository branch in a filesystem in response to the repository branch scan request.
[repository branch is interpreted as a portion or a version of a repository, based on the specification at para. 17, 74, and 84
]
One of ordinary skill in the art would have made this modification to improve the ability of the system to perform a scan of a portion of a large object, which may be advantageous when the object is too large for memory or too large to download all at once, or when speed is required and only a portion of the repository is required to be scanned. The system of the primary reference can be modified so that the stream manager may receive a request to download and scan a portion of a repository/dependency tree and retrieve and store the portion of the repository/dependency tree in a filesystem. The filesystem is disclosed because files are downloaded and stored in Holostov.
Claim 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, further in view of Watkins et al. U.S. Publication 20150281258 (hereinafter “Watkins”).
As per claim 9, the rejection of claim 1 is incorporated herein.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose wherein the multiple scanners include multiple instances of a same scanner.
Watkins discloses multiple instances of a scanner engine
[0049] In one embodiment, MDCE 218 includes multiple scanner engines, including a continuous scanner (CS) 224 and a desktop scanner (DS) 226, and also is in communication with distributed database 212 as shown. For example, the scanner engines can be run within cloud 222 (e.g., or can be implemented using other execution environments). In some implementations, the scanner engine results can be stored in a high performance database relating to the ad content metadata, shown as ad content metadata 214, accessible by all of the instances of the scanner engines currently in operation. As also shown, ad content metadata 214 is used in conjunction with feature and behavior data 216 by CPE 220 to determine whether the ad content is in violation of a policy.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for multiple instances of a scanner engine of Watkins to include wherein the multiple scanners include multiple instances of a same scanner.
One of ordinary skill in the art would have made this modification to improve the ability of the system to create multiple instances of the same scanner. The system of the primary reference can be modified to create multiple instances of the same scanner, in order to meet scaling demand for scanner services of the same scanner type.
Claims 12-14 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, further in view of McAllister et al. U.S. Publication 20200082095 (hereinafter “McAllister”).
As per claim 12, Kissel discloses A system, comprising:
[[0009] The present invention comprises methods, systems,
]
perform actions to enable parallel scan operations of multiple scanners, the actions including:
[0009] The present invention comprises methods, systems, and computer readable media for utilizing a stream manager (101) to efficiently scan stream (105) based data
[0059] FIG. 9 illustrates steps for efficiently scanning stream based data, according to yet other embodiments of the present invention. These embodiments leverage the fact that modify scanners 109 will often not modify data 103. In these embodiments, the stream manager 101 assumes that no modify scanner 109 will actually modify data 103, and thus allows all scanners 109, 111 to scan in parallel, in order to increase the speed of data 103 throughput. Only when a modify scanner 109 actually does modify a unit of data 103 is it necessary for that data 103 to be rescanned in order to ensure data integrity.
registering multiple scanners [the stream manager allows multiple scanners to scan in parallel, para. 9] to enable the multiple scanners to perform scans of a source code repository;[ source code repository can be a stream which is the downloaded data, para. 1, 2]
[0001] This invention pertains to the use of a stream manager in order to efficiently scan stream based data by a plurality of scanners.
Kissel [0002] It is often desirable to scan data before allowing it into a computer or a computer network. Data can contain undesirable content, such as malicious code (e.g. a computer virus), or content which is not permitted within a specific computing environment (e.g. entertainment material within a business environment). Scanning an inbound stream of data prior to allowing it into a computing environment can detect undesirable content, and either block the entry of the data, or modify the data so as to remove the undesirable content. Similarly, scanning an outbound stream of data prior to allowing it to leave a computing environment can detect and process malicious code originating from that organization's computer network.
[the specification and the claim does not define source code repositories. Also scanning source code repositories under the broadest reasonable interpretation could mean simply choosing to scan a respective file associated with a respective repository. The claim and specification does not specify the scope of the scan, for example, scan only a manifest, scan 5 percent, or scan the entire of a repository from the source code repositories]
retrieving and storing [stores data 103 in a cache 107 as the data 103 is received from the stream 105, para. 38] the source code repository [receives data 103 from a data stream 105, para. 51] in a filesystem; [files are downloaded disclosing filesystem, para. 40]
[0040] FIG. 4 illustrates a high level overview of another embodiment of the present invention. A stream manager 101 receives composed data 401 from a data stream 105. Examples of composed data 401 include compressed or encoded content, such as tar or zip files.
[0038] Returning to FIG. 1, in some embodiments of the present invention, the stream manager 101 stores data 103 in a cache 107 as the data 103 is received from the stream 105. The stream manager 101 then removes data 103 from the cache 107 as the data 103 is transmitted to a destination 113. By performing as much scanning in parallel as possible, and by transmitting data 103 to the destination as soon as it has been released by the scanners 109, 111, the present invention allows for the cache 107 to be kept as small as possible.
Kissel [0051] FIG. 7 illustrates a high level overview of another embodiment of the present invention. A stream manager 101 receives data 103 from a data stream 105, and stores the data 103 in a cache 107 (or in other embodiments stores the data 103 another way).
process requests from the multiple scanners to scan the source code repository [makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data, para. 56] stored in the filesystem, wherein processing the requests enables parallel scanning [thus allows all scanners 109, 111 to scan in parallel, para. 59; performing as much scanning in parallel as possible, para. 38] of the source code repository by the multiple scanners, and wherein processing the requests prevents simultaneous scanning of [“available to the plurality of modify scanners 109 in serial” para. 37; this means in Kissel only one scanner at a time can scan the data that is made available for scanning in serial ] a single source code repository by the multiple scanners.
[0056] The stream manager 101 makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data 103. The stream manager 101 also makes 809 requested data 103 available in parallel to each read-only scanner 111 that requests to scan that data 103. It will be understood by those of ordinary skill in the relevant art that steps 807 and 809 can be performed in either order. In other words, in some embodiments step 807 is performed first, and in others step 809 is performed first.
[0059] FIG. 9 … stream manager 101 assumes that no modify scanner 109 will actually modify data 103, and thus allows all scanners 109, 111 to scan in parallel, in order to increase the speed of data 103 throughput. Only when a modify scanner 109 actually does modify a unit of data 103 is it necessary for that data 103 to be rescanned in order to ensure data integrity.
However, Kissel does not expressly disclose
a processor, and
at least one memory storing instructions executed by the processor to perform actions to enable parallel scan operations of multiple scanners, the actions including:
application programming interface requests
multiple source code repositories
supplementing the multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
retrieving and storing the multiple source code repositories in a filesystem;
generating a library comprising identifications of the multiple source code repositories; and
using the library to process application programming interface requests from the multiple scanners to scan source code repositories of the multiple source code repositories stored in the filesystem, wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners, and wherein processing the application programming interface requests prevents simultaneous scanning of a single source code repository by the multiple scanners.
Jennings discloses a processor, and
at least one memory storing instructions executed by the processor to perform actions to
1:22-32 (3) In an aspect, an apparatus for scanning vulnerabilities, wherein the apparatus includes at least a processor and a memory communicatively connected to the at least a processor, the memory containing instructions configuring the at least a processor to: access at least a manifest file, wherein the at least manifest file includes at least a direct dependency, scan the manifest file for a software package data, extract the software package data from the manifest file, generate at least a dependency tree as a function of the software package data, and store the dependency tree in a database.
multiple source code repositories [multiple software packages and/or system packages are disclosed 4:48-61; Jennings 4:29-32 ]
generating a library [multiple software packages and/or system packages are disclosed 4:48-61; Jennings 4:29-32 ] comprising identifications [(25) With continued reference to FIG. 1, scanning manifest file 108 for software package data 116 may further include identifying software package identifier 120 from software package data 116 11:20-22; when the packages are built or installed, the packages would be identified to the system operating system 4:48-61 ] of the multiple source code repositories; and [software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language 4:48-61]
Jennings 4:48-61 software component 112 may include a software package comprising a collection of files that make up an application or capability, which may include binary executables, libraries, source text files, documentation files, scripts, and the like thereof, however a library may sometimes be referred to as a package in certain language directives. In another embodiment, and without limitation, software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language. In another embodiment, and without limitation, software component may include one or more system packages that may become part of the operating system resources and may be used by any script or program.
Jennings 4:29-32 (14) With continued reference to FIG. 1, as used in this disclosure, a “software component” is a library and/or collection of files that make up an application and/or program.
using the library to [the collection of software packages is used to process requests from scanners to scan 4:48-61; 4:29-32] process requests from the multiple scanners to scan source code repositories of the multiple source code repositories stored in the filesystem, wherein processing the requests enables parallel scanning of different source code repositories by the multiple scanners, and wherein processing the requests prevents simultaneous scanning of a single source code repository by the multiple scanners.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for a processor and memory system to retrieve and store multiple software packages for scanning of Jennings to include
a processor, and
at least one memory storing instructions executed by the processor to perform actions to enable parallel scan operations of multiple scanners, the actions including:
multiple source code repositories
registering multiple scanners to enable the multiple scanners to perform scans of multiple source code repositories;
retrieving and storing the multiple source code repositories in a filesystem;
generating a library comprising identifications of the multiple source code repositories; and
using the library to process requests from the multiple scanners to scan source code repositories of the multiple source code repositories stored in the filesystem, wherein processing the requests enables parallel scanning of different source code repositories by the multiple scanners, and wherein processing the requests prevents simultaneous scanning of a single source code repository by the multiple scanners.
One of ordinary skill in the art would have made this modification to improve the ability of the system to download multiple streams of software packages for scanning. The system of the primary reference can be modified so that there are multiple software packages being downloaded through multiple streams.
However, the combination of Kissel and Jennings does not expressly disclose
supplementing the multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
application programming interface requests
Hosseini discloses application programming interface requests
Hosseini [0033] The logical cloud function 104 can include an application programming interface (API) handler 106. An API can be software that permits applications to communicate.
[0042] Turning to process 300 in greater detail, at block 305 a scanning request can be received. The scanning request can be obtained by root routing namespace 214 from the admin host subnet 234 in the admin VCN 232. A scanning request can be received at the API handler 106 or the scan workflow 110 from FIG. 1, and the received scanning request can be enqueued to scanning request queue 102.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include using the library to process application programming interface requests from the multiple scanners to scan source code repositories of the multiple source code repositories stored in the filesystem, wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners, and wherein processing the application programming interface requests prevents simultaneous scanning of a single source code repository by the multiple scanners.
One of ordinary skill in the art would have made this modification to improve the ability of the system to utilize APIs to facilitate sending and receiving scan requests. The system of the primary reference can be modified to utilize APIs to send and receive scan requests, and to have an API handler to receive and handle the received API requests.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
supplementing the multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
McAllister discloses supplementing the multiple scanners [each scanner application, para 68] with interaction components [schema translator, para 68; scanning engine 12 extensions in McAllister allow for adding new types of scanners to interact with the API] that enable the multiple scanners to interact [commands, para 68] with an application programming interface;[ between API schemas and data schemas, para 68]
[0026] As container images are submitted to be scanned, in some embodiments, a layer evaluator may break down the layers and submit detected binaries (and other resources) over to other portions of the scanning engine to be evaluated. The scanning engine, in some embodiments, examines the information to determine the most appropriate (or at least suitable) scanning engine or engines to be used for the information submitted. The scanning engine may use one or more sources for the scans to run on. Each of at least some (or all) of the scanners may use a shared scanner API, allowing the results to be reported back in a similar format despite the different scanning techniques. Once the full scan is complete, in some embodiments, the information is packaged up and may be sent over to a result engine to be formatted and reported back. Additionally, the result engine may remove commonalities, provide scoring information and mask out at least some (e.g., all) previously identified false positives.
McAllister [0068] In some embodiments, the scanning engine 12 may abstract away details of communicating with the different scanner applications from other logic of the scanning engine with the schema translator 44. This is expected to make the scanning engine 12 relatively extensible, facilitating the addition of new types of scanners as additional scanners become available. In some embodiments, the schema translator 44 may be configured to translate commands and data between API schemas and data schemas specific to each scanner application 16 (each of which may have a different API schema or data schema, which is not to suggest that an API schema may not also specify a data schema) and a unified API schema and data schema of the scanning engine 12 by which the controller 42 communicates with the schema translator 44, in some cases without regard to with which scanner application the controller 42 is communicating.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the teaching that a schema translator may be configured to translate commands and data between API schemas and data schemas specific to each scanner application of McAllister to include supplementing the multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow multiple scanners to interact with an API, to thereby allow for the scanners to access additional functionality supplied by such an API. The system of the primary reference can be modified to include a schema translator to facilitate translating commands and data between API schemas and data schemas specific to each scanner.
As per claim 13, the rejection of claim 12 is incorporated herein.
Kissel discloses passing the address of the data to be scanned to the scanner in response to a request for data to scan
para. 56 makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data,
[0031] It will be understood by those of ordinary skill in the relevant art that making data 103 available to a scanner 109, 111 can comprise passing the address of the data 103 to the scanner 109, 111, passing a copy of the data 103 to the scanner 109, 111, or otherwise informing the scanner 109, 111 that the data 103 is available for scanning.
[0032] It will further be understood by those of ordinary skill in the relevant art that a
However, Kissel does not expressly disclose wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the application programming interface requests.
Jennings discloses downloading multiple source code repositories to a filesystem and scanning multiple trees/software packages
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that can be downloaded such as “actual number of downloads for a package or library” 9:22-26; the filesystem is disclosed because files such as executables and source text files are stored
18:47-53 multiple repositories also disclosed based on comparing first dependency tree and second dependency tree; dependency trees which correspond to software packages may be labeled as scanned or scanning progress etc. which discloses previously scanned and next to be scanned 19:17-36
]
19:17-36 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.” In some embodiments, storing dependency tree 144 may further include storing a software package vulnerability count, wherein the software vulnerability count is a variable representing number of existing software package vulnerability 128 found in software component 112 based on manifest file 108. In some embodiments, storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
Jennings 18:47-53 comparing first dependency tree and second dependency tree may further include traversing both dependency trees using tree traversal method disclosed above. In some cases, comparing first dependency tree and second dependency tree may compare all nodes within first dependency tree and second dependency tree.
9:22-26 In some cases, software package data 116 may include information involving one or more download counts, wherein a download count is an actual number of downloads for a package or library or a bucketization of download counts (the numbers broken into discrete bins).
4:29-32 (14) With continued reference to FIG. 1, as used in this disclosure, a “software component” is a library and/or collection of files that make up an application and/or program.
Jennings 4:48-61 software component 112 may include a software package comprising a collection of files that make up an application or capability, which may include binary executables, libraries, source text files, documentation files, scripts, and the like thereof, however a library may sometimes be referred to as a package in certain language directives. In another embodiment, and without limitation, software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language. In another embodiment, and without limitation, software component may include one or more system packages that may become part of the operating system resources and may be used by any script or program.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for downloading multiple source code repositories to a filesystem and scanning multiple trees/software packages of Jennings to include wherein processing the requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the requests.
One of ordinary skill in the art would have made this modification to improve the ability of the system to scan multiple downloaded source code repositories. The system of the primary reference can be modified to include multiple source code repositories (e.g., software packages with executables, libraries, source text files, etc. 4:48-61 Jennings) being downloaded and passing the address of the next repository to the scanner for scanning. returning different identifications is disclosed by Kissel because of the returned address for a software package/streaming data download.
However, the combination of Kissel and Jennings does not expressly disclose
wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the application programming interface requests.
Hosseini discloses an API handler to handle receiving scan requests
[0033] The logical cloud function 104 can include an application programming interface (API) handler 106. An API can be software that permits applications to communicate. Logical cloud function 104 can include a scanner database 108. The scanner database 108 can provide state for API requests and individual scans. Logical cloud function 104 can include a scan workflow 110. Scan workflow 110 can support parallel scans or targeted scanning using a subset of vulnerability checks. Logical cloud function 104 can include the scanner interface 112. Scanner interface 112 can communicate with the scanner 114. Scanner 114 can be located in logical cloud function 104.
[0042] Turning to process 300 in greater detail, at block 305 a scanning request can be received. The scanning request can be obtained by root routing namespace 214 from the admin host subnet 234 in the admin VCN 232. A scanning request can be received at the API handler 106 or the scan workflow 110 from FIG. 1, and the received scanning request can be enqueued to scanning request queue 102. The scanning request can be obtained by polling scan request queue 102 via admin host subnet 234 or admin VCN 232. The scanning request can identify one or more target addresses, e.g., an address in host subnet 242, and a target network, e.g., a unique identifier for customer 1 VCN 236, or a unique identifier for scan subnet 244. In some circumstances, the target address can be a globally non-unique identifier. For example, the target address can be an internet protocol version 4 (IPv4) address that is repeated in different customer VCNs and on the Internet. In some circumstances, the globally non-unique target addresses may not be repeated within an individual scan request or within an individual VCN.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the application programming interface requests.
One of ordinary skill in the art would have made this modification to improve the ability of the system to utilize APIs to facilitate sending and receiving scan requests. The system of the primary reference can be modified to utilize APIs to send and receive scan requests, and to have an API handler to receive and handle the received API requests.
As per claim 14, the rejection of claim 12 is incorporated herein.
Kissel discloses only one scanner at a time can scan the data that is made available for scanning in serial
[“available to the plurality of modify scanners 109 in serial” para. 37; this means in Kissel only one scanner at a time can scan the data that is made available for scanning in serial
storing an indication that the single source code repository is unavailable for scanning by other scanners of the multiple scanners while the single source code repository is being scanned by a single scanner of the multiple scanners is disclosed because the stream manager must keep track of which scanner currently has access to the stream data, when making the data available to the modify scanners in serial ]
[0037] Likewise, a read-only scanner 111 can release a portion 203 of a data packet 201, and continue to scan an unreleased portion 203. Once each read-only scanner ill has released a portion 203 of a packet 201, the stream manager 101 can make the released portion 203 available to the plurality of modify scanners 109 in serial, or can transmit the released portion 201 to a destination 113.
However, the combination of Kissel and Jennings does not expressly disclose wherein processing the application programming interface requests prevents simultaneous scanning of the single source code repository by the multiple scanners by storing an indication that the single source code repository is unavailable for scanning by other scanners of the multiple scanners while the single source code repository is being scanned by a single scanner of the multiple scanners.
Hosseini discloses an API handler to handle receiving scan requests.
[See citation of para. 33 and 42 claim 12]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include wherein processing the application programming interface requests prevents simultaneous scanning of the single source code repository by the multiple scanners by storing an indication that the single source code repository is unavailable for scanning by other scanners of the multiple scanners while the single source code repository is being scanned by a single scanner of the multiple scanners.
One of ordinary skill in the art would have made this modification to improve the ability of the system to utilize APIs to facilitate sending and receiving scan requests. The system of the primary reference can be modified to utilize APIs to send and receive scan requests, and to have an API handler to receive and handle the received API requests.
As per claim 17, Kissel discloses
receiving requests from multiple scanners [to each modify scanner 109 that requests to scan] to scan source code; and
malicious code in undesirable content… detect and process malicious code, para. 2;
[0056] The stream manager 101 makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data 103. The stream manager 101 also makes 809 requested data 103 available in parallel to each read-only scanner 111 that requests to scan that data 103.
using an identification of the source code repository to process the requests
[Kissel discloses passing the address of the data to be scanned to the scanner, and the address discloses the identification of the source code repository]
[0031] It will be understood by those of ordinary skill in the relevant art that making data 103 available to a scanner 109, 111 can comprise passing the address of the data 103 to the scanner 109, 111, passing a copy of the data 103 to the scanner 109, 111, or otherwise informing the scanner 109, 111 that the data 103 is available for scanning.
wherein processing the requests [scanner 109, 111 that requests to scan that data 103, para. 62] enables parallel scanning [thus allows all scanners 109, 111 to scan in parallel, para. 59; performing as much scanning in parallel as possible, para. 38] of a source code repository by the multiple scanners by returning an identification of the source code repository to the multiple scanners [passing the address of the data 103 to the scanner 109, 111, para. 31] in response to the requests, and
Kissel [0059] FIG. 9 illustrates steps for efficiently scanning stream based data, according to yet other embodiments of the present invention. These embodiments leverage the fact that modify scanners 109 will often not modify data 103. In these embodiments, the stream manager 101 assumes that no modify scanner 109 will actually modify data 103, and thus allows all scanners 109, 111 to scan in parallel, in order to increase the speed of data 103 throughput. Only when a modify scanner 109 actually does modify a unit of data 103 is it necessary for that data 103 to be rescanned in order to ensure data integrity.
[0062] Under other circumstances, no modify scanner 109 will actually modify a given unit of data 103, in which case no rescanning of that unit of data 103 will be necessary. Thus, the stream manager 101, responsive to that data 103 not having been modified by any modify scanner 109, and responsive to that data 103 having been released by each scanner 109, 111 that requests to scan that data 103, transmits 515 the released data 103 to a destination 113.
wherein processing the requests prevents simultaneous scanning of a single source code repository by the multiple scanners by storing an indication that the single source code repository is unavailable for scanning by other scanners of the multiple scanners while the single source code repository is being scanned by a single scanner of the multiple scanners.
[“after it has been released by a previous modify scanner (109)”, para. 11; this means that in Kissel, prior to release, the data being scanned is not available for scanning by other scanners; the stream manager 101 can make the released portion 203 available to the plurality of modify scanners 109 in serial; storing an indication is disclosed because the Kissel system must keep track of when the stream is being scanned so the other modify scanners may not scan the same stream ]
[0037] Likewise, a read-only scanner 111 can release a portion 203 of a data packet 201, and continue to scan an unreleased portion 203. Once each read-only scanner ill has released a portion 203 of a packet 201, the stream manager 101 can make the released portion 203 available to the plurality of modify scanners 109 in serial, or can transmit the released portion 201 to a destination 113.
Kissel discloses passing the address of the data to be scanned to the scanner
[0031] It will be understood by those of ordinary skill in the relevant art that making data 103 available to a scanner 109, 111 can comprise passing the address of the data 103 to the scanner 109, 111, passing a copy of the data 103 to the scanner 109, 111, or otherwise informing the scanner 109, 111 that the data 103 is available for scanning.
However, Kissel does not expressly disclose
A computer-readable storage medium storing computer-readable instructions, that when executed by a processor, cause the processor to perform actions comprising:
supplementing multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
receiving application programming interface requests from multiple scanners to scan source code repositories; and
using a library comprising identifications of the source code repositories to process the application programming interface requests,
wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the application programming interface requests, and
application programming interface requests
Jennings discloses
A computer-readable storage medium storing computer-readable instructions, that when executed by a processor, cause the processor to perform actions comprising:
1:22-32 (3) In an aspect, an apparatus for scanning vulnerabilities, wherein the apparatus includes at least a processor and a memory communicatively connected to the at least a processor, the memory containing instructions configuring the at least a processor to: access at least a manifest file, wherein the at least manifest file includes at least a direct dependency, scan the manifest file for a software package data, extract the software package data from the manifest file, generate at least a dependency tree as a function of the software package data, and store the dependency tree in a database.
using a library [the collection of software packages is used to process requests from scanners to scan 4:48-61; 4:29-32] comprising identifications of the source code repositories to process the requests,
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that are scanned; the filesystem is disclosed because files such as executables and source text files are stored; identifications of the source code repositories is disclosed because otherwise the processor cannot scan the repository without identifying the repositories and distinguishing between the repositories ]
4:48-61 software component 112 may include a software package comprising a collection of files that make up an application or capability, which may include binary executables, libraries, source text files, documentation files, scripts, and the like thereof, however a library may sometimes be referred to as a package in certain language directives. In another embodiment, and without limitation, software component may include packages that may be built or installed by a system package manager or loaded into memory by a directive statement in a programming language. In another embodiment, and without limitation, software component may include one or more system packages that may become part of the operating system resources and may be used by any script or program.
15:60-63 nodes of dependency tree 144 may further include software component 112 such as APIs, libraries, licenses, and the like thereof.
18:64-66
(39) With continued reference to FIG. 1, processor 152 is further configured to store the at least a dependency tree 144 in a database.
19:17-27 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.”
19:33-36 storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
different source code repositories [multiple software packages and/or system packages are disclosed 4:48-61; Jennings 4:29-32 ]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for a processor and memory system to retrieve and store multiple software packages for scanning of Jennings to include
A computer-readable storage medium storing computer-readable instructions, that when executed by a processor, cause the processor to perform actions comprising:
receiving requests from multiple scanners to scan source code repositories; and
using a library comprising identifications of the source code repositories to process the requests,
wherein processing the requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the requests, and
One of ordinary skill in the art would have made this modification to improve the ability of the system to download multiple streams of software packages for scanning. The system of the primary reference can be modified so that there are multiple software packages being downloaded through multiple streams. returning different identifications of the different source code repositories disclosed by passing the addresses of the source code repositories to be scanned to the scanner.
However, the combination of Kissel and Jennings does not expressly disclose supplementing multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
application programming interface requests
Hosseini discloses application programming interface requests
[see citations of para. 33 and 42 at claim 12]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include
receiving application programming interface requests from multiple scanners to scan source code repositories; and
using a library comprising identifications of the source code repositories to process the application programming interface requests,
wherein processing the application programming interface requests enables parallel scanning of different source code repositories by the multiple scanners by returning different identifications of the different source code repositories to the multiple scanners in response to the application programming interface requests, and
wherein processing the application programming interface requests prevents simultaneous scanning of a single source code repository by the multiple scanners by storing an indication that the single source code repository is unavailable for scanning by other scanners of the multiple scanners while the single source code repository is being scanned by a single scanner of the multiple scanners.
However, the combination of Kissel, Jennings, and Hosseini does not expressly disclose
supplementing multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
McAllister discloses supplementing multiple scanners [each scanner application, para 68] with interaction components [schema translator, para 68; scanning engine 12 extensions in McAllister allow for adding new types of scanners to interact with the API] that enable the multiple scanners to interact [commands, para 68] with an application programming interface;[ between API schemas and data schemas, para 68]
[0026] Each of at least some (or all) of the scanners may use a shared scanner API, allowing the results to be reported back in a similar format despite the different scanning techniques.
[0068] In some embodiments, the scanning engine 12 may abstract away details of communicating with the different scanner applications from other logic of the scanning engine with the schema translator 44. This is expected to make the scanning engine 12 relatively extensible, facilitating the addition of new types of scanners as additional scanners become available. In some embodiments, the schema translator 44 may be configured to translate commands and data between API schemas and data schemas specific to each scanner application 16 (each of which may have a different API schema or data schema, which is not to suggest that an API schema may not also specify a data schema) and a unified API schema and data schema of the scanning engine 12 by which the controller 42 communicates with the schema translator 44, in some cases without regard to with which scanner application the controller 42 is communicating.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, and Hosseini with the technique for a schema translator may be configured to translate commands and data between API schemas and data schemas specific to each scanner application of McAllister to include supplementing multiple scanners with interaction components that enable the multiple scanners to interact with an application programming interface;
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow multiple scanners to interact with an API, to thereby allow for the scanners to access additional functionality supplied by such an API. The system of the primary reference can be modified to include a schema translator to facilitate translating commands and data between API schemas and data schemas specific to each scanner.
As per claim 18, the rejection of claim 17 is incorporated herein.
However, Kissel does not expressly disclose wherein the actions further comprise performing codebase enumeration to generate the library.
Jennings discloses buckets holding counts of software package downloads, one bucket per software package
[having one bucket for each software package discloses codebase enumeration to generate the library. Creating buckets is part of generating the library]
9:22-26 In some cases, software package data 116 may include information involving one or more download counts, wherein a download count is an actual number of downloads for a package or library or a bucketization of download counts (the numbers broken into discrete bins).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for buckets holding counts of software package downloads, one bucket per software package of Jennings to include wherein the actions further comprise performing codebase enumeration to generate the library.
One of ordinary skill in the art would have made this modification to improve the ability of the system to determine the number of software packages there are and maintain software package-specific information for each software package. The system of the primary reference can be modified to maintain specific information for each software package based on a determination of the number of software packages and/or identifying the various software packages.
As per claim 19, the rejection of claim 17 is incorporated herein.
Kissel discloses passing the address of the data to be scanned to the scanner
[0031] It will be understood by those of ordinary skill in the relevant art that making data 103 available to a scanner 109, 111 can comprise passing the address of the data 103 to the scanner 109, 111, passing a copy of the data 103 to the scanner 109, 111, or otherwise informing the scanner 109, 111 that the data 103 is available for scanning.
However, Kissel does not expressly disclose wherein the source code repositories are stored in a filesystem accessible by the multiple scanners, and wherein using the library to process the application programming interface requests comprises returning filesystem locations of source code repositories to the multiple scanners.
Jennings discloses wherein the source code repositories are stored in a filesystem accessible by the processor scanner, and wherein using the library comprising to process the requests comprises returning filesystem locations of source code repositories to the processor scanner.
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that can be downloaded such as “actual number of downloads for a package or library” 9:22-26; the filesystem is disclosed because files such as executables and source text files are stored
18:47-53 multiple repositories also disclosed based on comparing first dependency tree and second dependency tree; dependency trees which correspond to software packages may be labeled as scanned or scanning progress etc. which discloses previously scanned and next to be scanned 19:17-36
Jennings 7:13-15 processor 152 is further configured to scan manifest file 108 for a software package data 116. ]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for storing files of software packages to be accessible to scanners of Jennings to include wherein the source code repositories are stored in a filesystem accessible by the multiple scanners, and wherein using the library comprising to process the requests comprises returning filesystem locations of source code repositories to the multiple scanners.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store the multiple software packages and allowed the scanners to scan the multiple software packages. The system of the primary reference can be modified to store such multiple software packages and allow scanners to scan the multiple software packages by providing the locations of the software packages to the scanners.
However, the combination of Kissel and Jennings does not expressly disclose application programming interface requests
Hosseini discloses application programming interface requests as argued with respect to claim 12.
For the reasons discussed with respect to claim 12, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for utilizing application programming interface requests of Hosseini to include wherein the source code repositories are stored in a filesystem accessible by the multiple scanners, and wherein using the library comprising to process the application programming interface requests comprises returning filesystem locations of source code repositories to the multiple scanners.
[Jennings discloses multiple source code repositories including software packages with executables, libraries, source text files, etc. 4:48-61 that are scanned; the filesystem is disclosed because files such as executables and source text files are stored ]
As per claim 20, the rejection of claim 17 is incorporated herein.
However, Kissel does not expressly disclose
wherein the actions further comprise registering the multiple scanners to enable the multiple scanners to perform scans of the source code repositories.
Jennings discloses to enable the processor scanner to perform scans of the source code repositories. [19:17-36 discloses the scan progress of respective dependency trees which correspond to source code repositories and 18:47-53 discloses that there are multiple dependency trees]
19:17-36 storing the at least a dependency tree 144 may include further storing a flag variable, wherein the flag variable holding a scan status. In some cases, scan status may include, but is not limited to, no scan, in queue, scan in progress, fully scanned, and the like thereof. In a non-limiting example, a dependency tree 144 may be generated as a function of software package dictionary 132, wherein the dependency tree 144 may be further stored in software package databases along with a flag variable holding a scan status of “fully scanned.” In some embodiments, storing dependency tree 144 may further include storing a software package vulnerability count, wherein the software vulnerability count is a variable representing number of existing software package vulnerability 128 found in software component 112 based on manifest file 108. In some embodiments, storing the at least a dependency tree 144 may further include storing a scan count, wherein the scan count is a variable representing number of times manifest file 108 of dependency tree 144 has been scanned.
Jennings 18:47-53 comparing first dependency tree and second dependency tree may further include traversing both dependency trees using tree traversal method disclosed above. In some cases, comparing first dependency tree and second dependency tree may compare all nodes within first dependency tree and second dependency tree.
Jennings 7:13-15 processor 152 is further configured to scan manifest file 108 for a software package data 116.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for downloading multiple source code repositories to a filesystem and scanning multiple trees/software packages of Jennings to include to enable the multiple scanners to perform scans of the source code repositories.
One of ordinary skill in the art would have made this modification to improve the ability of the system to apply multiple scanners to scan multiple downloaded source code repositories. The system of the primary reference can be modified to include multiple source code repositories (e.g., software packages with executables, libraries, source text files, etc. 4:48-61 Jennings) being downloaded and passing the addresses of the repositories/dependency trees/software packages to the scanner for scanning.
However, the combination of Kissel and Jennings does not expressly disclose
wherein the actions further comprise registering the multiple scanners to enable the multiple scanners to perform scans of the source code repositories.
Hosseini discloses registering [creating dedicated scanner routing namespace, para. 30; configuring routing rules to a scanner instance, para. 31] the multiple scanners.
[Hosseini discloses creating a new scanner instance with its own dedicated scanner routing namespace]
[0030] Continuing the example, the target requests are picked up by an available logical cloud function host containing a routing namespace, and one or more (idle) scanners that can be used to run the scan as identified in the request. A namespace can be a Unix network namespace. The root routing namespace can be connected to a separate scanner specific routing namespace. This scanner routing namespace can have one scanner instance. Additional scanner instances can exist, and each scanner instance can use its own dedicated scanner routing namespace. The scanner instances can be created during initial host configuration and can be re-used between requests.
[0068] At block 610, for at least two of the two or more scanning requests, a scanner instance and a virtual network interface card (VNIC) can be generated in response to the scanning request. A scanner instance and VNIC can be generated for two or more scanning requests identifying separate VCNs (e.g., VCN 432). The scanner instance and VNIC can include a scanning infrastructure as described above in relation to FIGS. 4 and 5. The scanning infrastructure can include one or more of a scan route table (e.g., scan route table-N 474), a root routing table (e.g., root route table 462), a routing module (e.g., routing module 460), a VNIC route table (e.g., VNIC-N route table 482), a VNIC namespace (e.g., VNIC-N namespace 458), or a VNIC (e.g., VNIC-N 466).
Hosseini [0031] To perform each scan, the target address and the target network (e.g., the network containing the target address) can be used to configure route rules in the one or more routing tables to create a pipeline from the scanner instance to the target address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for creating one or more new scanner instances each with its own dedicated scanner routing namespace of Hosseini to include wherein the actions further comprise registering the multiple scanners to enable the multiple scanners to perform scans of the source code repositories.
One of ordinary skill in the art would have made this modification to improve the ability of the system to create new scanners and utilize the scanners. The system of the primary reference can be modified so that when a new scanner instance is created a new namespace is also assigned to the new scanner instance, for multiple scanner instances.
Claim 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, in view of McAllister, further in view of Larsen et al. U.S. Publication 20130312096 (hereinafter “Larsen”).
As per claim 15, the rejection of claim 12 is incorporated herein.
However, the combination of Kissel, Jennings, Hosseini and McAllister does not expressly disclose
wherein the actions further include maintaining a log to indicate which of the multiple source code repositories have been scanned by scanners of the multiple scanners.
Larsen discloses logging items that have been scanned and determining yet to be scanned items
[0024] Note that the agent keeps a record of the current scan state information on the guest VM. The scan state information includes, for example, the scope of the scan (e.g., list of files or directories to be scanned), files with completed scans, files currently being scanned, and files yet to be scanned within the scope.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, Hosseini and McAllister with the technique for logging items that have been scanned and determining yet to be scanned items of Larsen to include
wherein the actions further include maintaining a log to indicate which of the multiple source code repositories have been scanned by scanners of the multiple scanners.
One of ordinary skill in the art would have made this modification to improve the ability of the system to keep track of which repositories have been scanned and which repositories have yet to be scanned. The system of the primary reference can be modified to keep records of the current scan state of the repositories/dependency trees in order to determine the next one to be scanned.
Claim 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kissel in view of Jennings, in view of Hosseini, in view of McAllister, further in view of Munoz et al. U.S. Publication 20170223043 (hereinafter “Munoz”).
As per claim 16, the rejection of claim 12 is incorporated herein.
Kissel discloses use collected software to process requests from scanners
para. 56 makes 807 requested data 103 serially available in a specific order to each modify scanner 109 that requests to scan that data 103
However, Kissel does not expressly disclose
wherein the actions further include using the library to process application programming interface requests from the multiple scanners to repository branches associated with the multiple source code repositories stored in the filesystem.
Jennings discloses the collection of software packages [disclosing library] is used to process requests from a scanner to scan 4:48-61; 4:29-32
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kissel with the technique for the collection of software packages is used to process requests from scanners to scan of Jennings to include
wherein the actions further include using the library to process requests from the multiple scanners to the multiple source code repositories stored in the filesystem.
However, the combination of Kissel and Jennings does not expressly disclose
wherein the actions further include using the library to process application programming interface requests from the multiple scanners to repository branches associated with the multiple source code repositories stored in the filesystem.
Hosseini discloses application programming interface requests
[see citations to para. 33 and 42 in claim 12]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel and Jennings with the technique for an API handler to handle receiving scan requests of Hosseini to include wherein the actions further include using the library to process application programming interface requests from the multiple scanners to multiple source code repositories stored in the filesystem.
However, the combination of Kissel, Jennings, Hosseini and McAllister does not expressly disclose
wherein the actions further include using the library to process application programming interface requests from the multiple scanners to repository branches associated with the multiple source code repositories stored in the filesystem.
Munoz discloses scanners send requests to components [AUT] related to other components [server]
[0011] Detecting security sensitive events that occur on the server-side of an AUT is a challenging task. This can be because a consequence of the event is not reflected in the response. Black box scanners rely on the requests sent to the server/AUT and the response the scanners receive from the server/AUT in order to infer vulnerabilities in the running application modeled as a black box.
[0009] A web application vulnerability scanner is an approach for identifying vulnerabilities in a web application. A scanner starts by crawling the application under test (AUT) to identify the attack surface. A runtime agent can be installed on the application server to assist with performing a security test.
[0041] The AUT 240 can include a network interface for enabling communications between the scanner 210 and the AUT 240 through a network. The network interface exposes the attack surface of the AUT 240 and can be the same interface that would eventually be used to provide access to the AUT 240 when the AUT 240 is made available for general use. Communication between the scanner 210 and the AUT 240 over the network interface may be conducted through HTTP requests issued from the scanner 210 to the AUT 240 and HTTP responses issued from the AUT 240 to the scanner 210. Requests targeting the AUT 240 may be referred to as application requests, and responses received from the AUT 240 may be referred to as application responses. The application requests generated by the scanner 210 may be configured to expose potential vulnerabilities of the AUT 240.
para. 25 The server 140 may include the application under test 142, a runtime agent engine 144, and a network sniffer engine 146. Communications between the computing device 110 and the server 140 may be conducted using a request-response protocol such as the Hyper-Text Transfer Protocol (HTTP).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Kissel, Jennings, Hosseini and McAllister with the technique for scanners to send requests to components related to other components of Munoz to include
wherein the actions further include using the library to process application programming interface requests from the multiple scanners to repository branches associated with the multiple source code repositories stored in the filesystem.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow scanners to send requests to components related to the source code repositories, including a related portion of the repository. The system of the primary reference can be modified so that scanners can send requests to a related portion of the source code repository.
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 HOWARD H LOUIE whose telephone number is (571)272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM EST.
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, Jung W. Kim can be reached on 571-272-3804. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
1 Emphasis is additional throughout.