DETAILED ACTION
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/15/2026 has been entered.
Claims 1-20 are pending with claims 1, 8 and 15 having been amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are moot because the new ground of rejection necessitated by applicant’s amendment which does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Aboukhadijeh et al (US 2024/0303334) in view of Mosby et al (US 2021/0279337).
With respect to claim 1 Aboukhadijeh teaches a method for detecting malicious software packages, the method comprising:
collecting, by a malicious detection system, information identifying one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0036 i.e. Malware determination module 335 may, responsive to receiving the identification of the ambiguous pattern, input the ambiguous pattern into a severity model. The term severity model, as used herein, may refer to a model that classifies malware types into levels of severity. That is, the question being asked is, if the file in fact includes malware, would the consequences be sufficiently catastrophic that it is worth using generative AI despite the costs of doing so? A low severity malware file might write data to disk that is needless but otherwise harmless; a high severity malware file might transmit existing data that is sensitive to an external server, thus jeopardizing data privacy and integrity. The severity model, in an embodiment, may be a supervised machine learning model that is trained using historical patterns as mapped to a level of severity. That is, training examples may be used that include patterns as labeled by a severity level (e.g., a level from 1 to 100));
collecting, by the malicious detection system, information identifying one or more known suspicious community behavior classifiers associated with the one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI);
receiving, by the malicious detection system, a software package including software components (See Aboukhadijeh figure 5 step 502-506 and paragraph 0044 i.e. Process 500 may be implemented by one or more processors executing instructions (e.g., encoded in memory of a non-transitory computer-readable medium) that cause the modules of malware detection tool 130 to operate. Process 500 begins with malware detection tool 130 receiving 502 a request to scan a package integration for a malicious dependency (e.g., using scan request module 331), the package integration comprising a plurality of dependencies, the package integration to be integrated into an application. Malware detection tool 130 determines 504, using a known package cache (e.g., known package cache 350), a subset of the plurality of dependencies that have not been previously scanned (e.g., using dependency filtering module 332). Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model);
identifying, by the malicious detection system, one or more software components from the software package as malicious based on a comparison between the software components of the software package and each of the collected one or more known malicious software component classifiers and the collected one or more known suspicious community behavior classifiers; generating, by the malicious detection system, a malicious probability for each of the identified one or more software components from the software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern); and
evaluating, by the malicious detection system, whether the software package is malicious based on the generated malicious probability for each of the identified one or more software components (Aboukhadijeh figure 5 step 514-516 and paragraphs 0045 i.e. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern, and determines 516 whether malware is present based on a response from the generative machine learning model).
Aboukhadijeh does not disclose wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages.
Mosby teaches wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages (see Mosby paragraph 0039 i.e. The method 200 may include evaluating 202 attributes of the application itself. This may include the version of the application, i.e. the version relative to the latest version for that application, time elapsed since a last update, or an average frequency of updates. This may also include evaluating software developer's kits (SDK) or third-party libraries included in the application, particularly reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Mosby to have used Mosby evaluating software developer's kits (SDK) or third-party libraries included in the application to generate a reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are (see Mosby paragraph 0039). Therefore one would have been motivated to have used community data include developer- generated information.
With respect to claim 2 Aboukhadijeh and Giokas teach the method of claim 1, wherein the software component includes software code for a file, software code for part of a file, software code spanning multiple files, and software code for one or more software functions (see Aboukhadijeh paragraph 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware. To this end, in an embodiment, each file is stored with reference to its corresponding node for the purpose of comparing the files with files of a newly requested package integration. However, storing entire files for myriad known package integrations could take huge amounts of storage space, and performing comparisons on an entire file-by-file basis is computationally very expensive. In an embodiment, files are broken into chunks according to a repeatable algorithm. For example, the files may be sliced into chunks using a rolling hash function that scans across a file, and where the function falls below a threshold value, the file is cut into a chunk and the next scanned portion of the file begins the next chunk. Each chunk may be hashed, the result forming a hash key. The hash key for each chunk may be stored in association with the node on the graph corresponding to the file. This yields an ability for malware detection tool 130 to perform a much more efficient comparison for a requested package integration).
With respect to claim 3 Aboukhadijeh and Giokas teach the method of claim 1, wherein a known suspicious community behavior of the one or more known suspicious community behavior classifiers is determined based on a time of release of a corresponding software package containing a corresponding known malicious software component of the one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI).
With respect to claim 4 Aboukhadijeh and Giokas teach the method of claim 1, wherein a known suspicious community behavior of the one or more known suspicious community behavior classifiers is determined based on a discrepancy between a registration of a software package and a corresponding deposit of source code associated with the registered software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware).
With respect to claim 5 Aboukhadijeh and Giokas teach the method of claim 1, further comprising: storing, by the malicious detection system, in a database, software packages including the evaluated software package; receiving, by the malicious detection system, a search query for identifying software packages from the stored software packages that match the search query; retrieving, by the malicious detection system, one or more matched software packages based on the received search query; and determining, by the malicious detection system, whether the one or more matched software packages is a malicious software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern).
With respect to claim 6 Aboukhadijeh and Giokas teach the method of claim 1, further comprising: including, by the malicious detection system, in a software composition analysis tool, software packages including the evaluated software package; scanning, by the malicious detection system, the software composition analysis tool with the software packages; and determining, by the malicious detection system, whether one or more of the scanned software packages is a malicious software package (see Aboukhadijeh figure 2 and paragraph 0023 i.e. F IG. 2 illustrates one embodiment of exemplary modules and databases used by the malware detection tool, in accordance with an embodiment. As depicted in FIG. 2, malware detection tool 130 includes scan request module 331, dependency filtering module 332, known dependency comparison module 333, known package cache update module 334, malware determination module 335, and malware severity module 336, as well as various databases including known package cache 350 and generative machine learning model 351. The modules and databases depicted in FIG. 2 are merely exemplary, and more or fewer modules and/or databases may be used to achieve the functionality disclosed herein. It is also reiterated that any and all functionality disclosed with respect to malware detection tool 130 may be performed local to client device 110 by application 111 and paragraph 0031 i.e. In an embodiment, malware determination module 335 determines whether malware is within the package integration using the known package cache and the results of the scan. The use of the known package cache is outputting previously known malware with respect to a previously known file of the package integration. For previously unknown portions of files within the package integration, malware determination may determine one or more patterns within the results of the scan. The patterns may be determined using any semantic pattern identification function, such as patterns of words, functions, file names, and so on being within a same file, or being within dependent files. Exemplary patterns may include a file that reads files from a disk and sends those files to a website, or files that execute code at install time that sends data to a network).
With respect to claim 8 Aboukhadijeh teaches a system comprising: one or more processors; and a memory coupled with and readable by the one or more processors and storing therein a set of instructions which, when executed by the one or more processors, causes the one or more processors to detect malicious software packages by:
collecting information identifying one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0036 i.e. Malware determination module 335 may, responsive to receiving the identification of the ambiguous pattern, input the ambiguous pattern into a severity model. The term severity model, as used herein, may refer to a model that classifies malware types into levels of severity. That is, the question being asked is, if the file in fact includes malware, would the consequences be sufficiently catastrophic that it is worth using generative AI despite the costs of doing so? A low severity malware file might write data to disk that is needless but otherwise harmless; a high severity malware file might transmit existing data that is sensitive to an external server, thus jeopardizing data privacy and integrity. The severity model, in an embodiment, may be a supervised machine learning model that is trained using historical patterns as mapped to a level of severity. That is, training examples may be used that include patterns as labeled by a severity level (e.g., a level from 1 to 100));
collecting information identifying one or more known suspicious community behavior classifiers associated with the one or more known malicious software component classifiers; receiving a software package including software components (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI);
receiving, by the malicious detection system, a software package including software components (See Aboukhadijeh figure 5 step 502-506 and paragraph 0044 i.e. Process 500 may be implemented by one or more processors executing instructions (e.g., encoded in memory of a non-transitory computer-readable medium) that cause the modules of malware detection tool 130 to operate. Process 500 begins with malware detection tool 130 receiving 502 a request to scan a package integration for a malicious dependency (e.g., using scan request module 331), the package integration comprising a plurality of dependencies, the package integration to be integrated into an application. Malware detection tool 130 determines 504, using a known package cache (e.g., known package cache 350), a subset of the plurality of dependencies that have not been previously scanned (e.g., using dependency filtering module 332). Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model);
identifying, by the malicious detection system, one or more software components from the software package as malicious based on a comparison between the software components of the software package and each of the collected one or more known malicious software component classifiers and the collected one or more known suspicious community behavior classifiers; generating, by the malicious detection system, a malicious probability for each of the identified one or more software components from the software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern); and
evaluating, by the malicious detection system, whether the software package is malicious based on the generated malicious probability for each of the identified one or more software components (Aboukhadijeh figure 5 step 514-516 and paragraphs 0045 i.e. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern, and determines 516 whether malware is present based on a response from the generative machine learning model).
Aboukhadijeh does not disclose wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages.
Mosby teaches wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages (see Mosby paragraph 0039 i.e. The method 200 may include evaluating 202 attributes of the application itself. This may include the version of the application, i.e. the version relative to the latest version for that application, time elapsed since a last update, or an average frequency of updates. This may also include evaluating software developer's kits (SDK) or third-party libraries included in the application, particularly reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Mosby to have used Mosby evaluating software developer's kits (SDK) or third-party libraries included in the application to generate a reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are (see Mosby paragraph 0039). Therefore one would have been motivated to have used community data include developer- generated information.
With respect to claim 9 Aboukhadijeh and Giokas teach the system of claim 8, wherein the software component includes software code for a file, software code for part of a file, software code spanning multiple files, and software code for one or more software functions (see paragraph 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware. To this end, in an embodiment, each file is stored with reference to its corresponding node for the purpose of comparing the files with files of a newly requested package integration. However, storing entire files for myriad known package integrations could take huge amounts of storage space, and performing comparisons on an entire file-by-file basis is computationally very expensive. In an embodiment, files are broken into chunks according to a repeatable algorithm. For example, the files may be sliced into chunks using a rolling hash function that scans across a file, and where the function falls below a threshold value, the file is cut into a chunk and the next scanned portion of the file begins the next chunk. Each chunk may be hashed, the result forming a hash key. The hash key for each chunk may be stored in association with the node on the graph corresponding to the file. This yields an ability for malware detection tool 130 to perform a much more efficient comparison for a requested package integration)..
With respect to claim 10 Aboukhadijeh and Giokas teach the system of claim 8, wherein a known suspicious community behavior of the one or more known suspicious community behavior classifiers is determined based on a time ofrelease of a corresponding software package containing a corresponding known malicious software component of the one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI).
With respect to claim 11 Aboukhadijeh and Giokas teach the system of claim 8, wherein a known suspicious community behavior of the one or more known suspicious community behavior classifiers is determined based on a discrepancy between a registration of a software package and a corresponding deposit of source code associated with the registered software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware).
With respect to claim 12 Aboukhadijeh and Giokas teach the system of claim 8, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: storing in a database, software packages including the evaluated software package; receiving a search query for identifying software packages from the stored software packages that match the search query; retrieving one or more matched software packages based on the received search query; and determining whether the one or more matched software packages is a malicious software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern).
With respect to claim 13 Aboukhadijeh and Giokas teach the system of claim 8, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: including in a software composition analysis tool, software packages including the evaluated software package; scanning the software composition analysis tool with the software packages; and determining whether one or more of the scanned software packages is a malicious software package (see Aboukhadijeh figure 2 and paragraph 0023 i.e. F IG. 2 illustrates one embodiment of exemplary modules and databases used by the malware detection tool, in accordance with an embodiment. As depicted in FIG. 2, malware detection tool 130 includes scan request module 331, dependency filtering module 332, known dependency comparison module 333, known package cache update module 334, malware determination module 335, and malware severity module 336, as well as various databases including known package cache 350 and generative machine learning model 351. The modules and databases depicted in FIG. 2 are merely exemplary, and more or fewer modules and/or databases may be used to achieve the functionality disclosed herein. It is also reiterated that any and all functionality disclosed with respect to malware detection tool 130 may be performed local to client device 110 by application 111 and paragraph 0031 i.e. In an embodiment, malware determination module 335 determines whether malware is within the package integration using the known package cache and the results of the scan. The use of the known package cache is outputting previously known malware with respect to a previously known file of the package integration. For previously unknown portions of files within the package integration, malware determination may determine one or more patterns within the results of the scan. The patterns may be determined using any semantic pattern identification function, such as patterns of words, functions, file names, and so on being within a same file, or being within dependent files. Exemplary patterns may include a file that reads files from a disk and sends those files to a website, or files that execute code at install time that sends data to a network).
With respect to claim 15 Aboukhadijeh teaches a non-transitory, computer-readable medium comprising a set of instructions stored therein which, when executed by one or more processors, cause the one or more processors to detect malicious software packages by: collecting information identifying one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0036 i.e. Malware determination module 335 may, responsive to receiving the identification of the ambiguous pattern, input the ambiguous pattern into a severity model. The term severity model, as used herein, may refer to a model that classifies malware types into levels of severity. That is, the question being asked is, if the file in fact includes malware, would the consequences be sufficiently catastrophic that it is worth using generative AI despite the costs of doing so? A low severity malware file might write data to disk that is needless but otherwise harmless; a high severity malware file might transmit existing data that is sensitive to an external server, thus jeopardizing data privacy and integrity. The severity model, in an embodiment, may be a supervised machine learning model that is trained using historical patterns as mapped to a level of severity. That is, training examples may be used that include patterns as labeled by a severity level (e.g., a level from 1 to 100));
collecting, by the malicious detection system, information identifying one or more known suspicious community behavior classifiers associated with the one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI);
receiving, by the malicious detection system, a software package including software components (See Aboukhadijeh figure 5 step 502-506 and paragraph 0044 i.e. Process 500 may be implemented by one or more processors executing instructions (e.g., encoded in memory of a non-transitory computer-readable medium) that cause the modules of malware detection tool 130 to operate. Process 500 begins with malware detection tool 130 receiving 502 a request to scan a package integration for a malicious dependency (e.g., using scan request module 331), the package integration comprising a plurality of dependencies, the package integration to be integrated into an application. Malware detection tool 130 determines 504, using a known package cache (e.g., known package cache 350), a subset of the plurality of dependencies that have not been previously scanned (e.g., using dependency filtering module 332). Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model);
identifying, by the malicious detection system, one or more software components from the software package as malicious based on a comparison between the software components of the software package and each of the collected one or more known malicious software component classifiers and the collected one or more known suspicious community behavior classifiers; generating, by the malicious detection system, a malicious probability for each of the identified one or more software components from the software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern); and
evaluating, by the malicious detection system, whether the software package is malicious based on the generated malicious probability for each of the identified one or more software components (Aboukhadijeh figure 5 step 514-516 and paragraphs 0045 i.e. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern, and determines 516 whether malware is present based on a response from the generative machine learning model).
Aboukhadijeh does not disclose wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages.
Mosby teaches wherein the one or more known malicious software component classifiers are derived from community data sources and wherein the community data sources include developer- generated information including at least one of reputation, frequency of updates, user ratings or reviews related to the software packages (see Mosby paragraph 0039 i.e. The method 200 may include evaluating 202 attributes of the application itself. This may include the version of the application, i.e. the version relative to the latest version for that application, time elapsed since a last update, or an average frequency of updates. This may also include evaluating software developer's kits (SDK) or third-party libraries included in the application, particularly reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Mosby to have used Mosby evaluating software developer's kits (SDK) or third-party libraries included in the application to generate a reputation scores indicating the reliability and security of the SDKs or libraries, or how up-to-date the versions of the SDKs or libraries are (see Mosby paragraph 0039). Therefore one would have been motivated to have used community data include developer- generated information.
With respect to claim 16 Aboukhadijeh and Giokas teach the non-transitory, computer-readable medium of claim 15, wherein a known suspicious community behavior of the one or more known suspicious community behavior classifiers is determined based on a time of release of a corresponding software package containing a corresponding known malicious software component of the one or more known malicious software component classifiers (see Aboukhadijeh paragraph 0039-0040 i.e. Given that use of the generative machine learning model 351 is expensive, prior to using generative machine learning model 351 (e.g., and in embodiments prior to even running the severity determination module but after determining that the pattern is ambiguous), malware determination module 335 may first consult known package cache 350 to determine whether the generative machine learning model 351 had previously made a determination as to whether the file is malicious. For example, in some scenarios, prior determinations by the generative machine learning model may not be readily findable using the directed graph for the known package in question, as the determination may have been done on the same pattern but for a different known package that is not currently being traversed by malware detection tool 130. To this end, malware determination module 335 may maintain a separate database of known ambiguous patterns (e.g., using known package cache 350). Malware determination module 335 may, responsive to determining that a pattern is ambiguous, query the database. Where generative AI was previously used for that pattern, an entry would appear along with a determination as to whether the pattern is associated with malware (e.g., and possibly more granularly a type of malware). Where the database returns a match, the prior decision is used, rather than again querying the generative AI. Moreover, whenever generative AI is used, the results of the query are used by malware detection module 335 to update the database to with an entry for the ambiguous pattern and the result of the generative AI).
With respect to claim 17 Aboukhadijeh and Giokas teach the non-transitory, computer-readable medium of claim 15, wherein a known suspicious community behavior of the one or more known suspicious community behaviorclassifiers is determined based on a discrepancy between a registration of a software package and a corresponding deposit of source code associated with the registered software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware).
With respect to claim 18 Aboukhadijeh and Giokas teach the non-transitory, computer-readable medium of claim 15, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: storing in a database, software packages including the evaluated software package; receiving a search query for identifying software packages from the stored software packages that match the search query; retrieving one or more matched software packages based on the received search query; and determining whether the one or more matched software packages is a malicious software package (see Aboukhadijeh figure 5 step 508-512 and paragraphs 0045 i.e. Malware detection tool 130 operates malware determination module 335, going on to input 506 content of each file of the subset into a malware detection model, and receives 508, as output from the malware detection model, an identification of an ambiguous pattern, the ambiguous pattern having at least a first threshold probability of indicating malware may be present, but less than a second threshold probability corresponding to a conclusion that malware is in fact present. Responsive to receiving the identification of the ambiguous pattern, malware detection tool 130 inputs 510 the ambiguous pattern into a severity model, and receives 512, as output from the severity model, a level of severity that the ambiguous pattern would impose on an assumption that malware is present. Responsive to determining that the level of severity is above a threshold minimum level of severity, malware detection tool 130 transmits 514 a query to a generative machine learning model (e.g., generative machine learning model 351) to determine whether malware is present in the ambiguous pattern).
With respect to claim 19 Aboukhadijeh and Giokas teach the non-transitory, computer-readable medium of claim 15, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: including in a software composition analysis tool, software packages including the evaluated software package; scanning the software composition analysis tool with the software packages; and determining whether one or more of the scanned software packages is a malicious software package (see Aboukhadijeh figure 2 and paragraph 0023 i.e. F IG. 2 illustrates one embodiment of exemplary modules and databases used by the malware detection tool, in accordance with an embodiment. As depicted in FIG. 2, malware detection tool 130 includes scan request module 331, dependency filtering module 332, known dependency comparison module 333, known package cache update module 334, malware determination module 335, and malware severity module 336, as well as various databases including known package cache 350 and generative machine learning model 351. The modules and databases depicted in FIG. 2 are merely exemplary, and more or fewer modules and/or databases may be used to achieve the functionality disclosed herein. It is also reiterated that any and all functionality disclosed with respect to malware detection tool 130 may be performed local to client device 110 by application 111 and paragraph 0031 i.e. In an embodiment, malware determination module 335 determines whether malware is within the package integration using the known package cache and the results of the scan. The use of the known package cache is outputting previously known malware with respect to a previously known file of the package integration. For previously unknown portions of files within the package integration, malware determination may determine one or more patterns within the results of the scan. The patterns may be determined using any semantic pattern identification function, such as patterns of words, functions, file names, and so on being within a same file, or being within dependent files. Exemplary patterns may include a file that reads files from a disk and sends those files to a website, or files that execute code at install time that sends data to a network).
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Aboukhadijeh et al (US 2024/0303334) in view of Mosby et al (US 2021/0279337) in view of Hewlett et al (US 2021/0019412).
With respect to claim 7 Aboukhadijeh and Mosby teach the method of claim 1, further comprising: integrating, by the malicious detection system, into a continuous integration/continuous deployment (CI/CD) pipeline, software packages including the evaluated software package; identifying, by the malicious detection system, the integrated software packages of the CI/CD pipeline; and determining, by the malicious detection system, whether one or more of the identified software packages is a malicious software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware)).
Aboukhadijeh does not disclose blocking, by the malicious detection system, download of the determined one or more of the software packages that is a malicious software package.
Hewlett teaches blocking, by the malicious detection system, download of the determined one or more of the software packages that is a malicious software package (see Hewlett paragraph 0043 i.e. In the event an application is determined to be malicious, data appliances can be configured to automatically block the file download based on the analysis result. Further, a signature can be generated for the malware and distributed (e.g., to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests to download the file determined to be malicious).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Hewlett to have blocked malicious data from being downloaded based on the analysis result as a way to protect the detected malware from causing harm (see Hewlett paragraph 0024 and 0043). Therefore one would have been motivated to have blocked malicious data from being downloaded based on the analysis result.
With respect to claim 14 Aboukhadijeh and Mosby the system of claim 8, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: integrating into a continuous integration/continuous deployment (CI/CD) pipeline, software packages including the evaluated software package; identifying the integrated software packages of the CI/CD pipeline; and determining whether one or more of the identified software packages is a malicious software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware).
Aboukhadijeh does not disclose blocking download of the determined one or more of the software packages that is a malicious software package.
Hewlett teaches blocking download of the determined one or more of the software packages that is a malicious software package (see Hewlett paragraph 0043 i.e. In the event an application is determined to be malicious, data appliances can be configured to automatically block the file download based on the analysis result. Further, a signature can be generated for the malware and distributed (e.g., to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests to download the file determined to be malicious).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Hewlett to have blocked malicious data from being downloaded based on the analysis result as a way to protect the detected malware from causing harm (see Hewlett paragraph 0024 and 0043). Therefore one would have been motivated to have blocked malicious data from being downloaded based on the analysis result.
With respect to claim 20 Aboukhadijeh and Mosby the non-transitory, computer-readable medium of claim 15, wherein the set of instructions further causes the one or more processors to detect malicious software packages by: integrating into a continuous integration/continuous deployment (CI/CD) pipeline, software packages including the evaluated software package; identifying the integrated software packages of the CI/CD pipeline; and determining whether one or more of the identified software packages is a malicious software package (see Aboukhadijeh paragraphs 0019-0020 i.e. One utility of the directed graph is for the purpose of comparing files of a requested package integration with files known to be associated with that package integration to determine whether anything has changed. That is, responsive to receiving a request to determine whether a package integration includes malware, malware detection tool determines not just whether the known package cache knows of the package integration and knows that the package integration is not associated with malware, but also determines whether there is a delta between the known version of the package integration and the one associated with the request, as the delta (e.g., from a version update or a hidden change) may include malware).
Aboukhadijeh does not disclose blocking download of the determined one or more of the software packages that is a malicious software package.
Hewlett teaches blocking download of the determined one or more of the software packages that is a malicious software package (see Hewlett paragraph 0043 i.e. In the event an application is determined to be malicious, data appliances can be configured to automatically block the file download based on the analysis result. Further, a signature can be generated for the malware and distributed (e.g., to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests to download the file determined to be malicious).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aboukhadijeh in view of Hewlett to have blocked malicious data from being downloaded based on the analysis result as a way to protect the detected malware from causing harm (see Hewlett paragraph 0024 and 0043). Therefore one would have been motivated to have blocked malicious data from being downloaded based on the analysis result.
Prior Art
Shanklin (US 2015/0074759) titled “APPLICATION TRUST-LISTING SECURITY SERVICE”.
Bogorad et al (US 8,875,292) titled “Systems And Methods For Managing Malware Signatures”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492