Office Action 4: Non-Final Rejection (2024-02-29)
Rejection types: 103 - Obviousness

CLAIMS:
CLAIMS LISTING

The following is a listing of claims in the application:

1\. (Previously Presented) A method for detection of cyber threats embedded in cloud applications, comprising:
detecting code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment;
filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and
detecting a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.

2\. (Original) The method of claim 1, further comprising;
reporting each identified potential cyber threat.

3\. (Original) The method of claim 1, further comprising:
comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities.

4\. (Previously Presented) The method of claim 1, wherein the non-unique portion of the code includes at least one of: an operating system (OS) package data feature and a third-party code library data feature.

5\. (Previously Presented) The method of claim 1, wherein identifying the mismatch between the unique portion of the code and its verified version stored in the code repository further comprises:

comparing hash values of the unique portion of the code to hash values of its verified version.

6\. (Previously Presented) The method of claim 1 wherein the code includes any one of: binary code, executable code, and high-level programming language code.

7\. (Original) The method of claim 1, wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.

8\. (Previously Presented) The method of claim 1, further comprising:
creating a resource artifact hash for a resource artifact included in the code, wherein the resource artifact hash is a low-file-size representation of the resource artifact;
and comparing the resource artifact hash with at least one repository hash, wherein each of the at least one repository hash is a low-file-size representation of an artifact included in a repository.

9\. (Previously Presented) The method of claim 8, further comprising:
determining an artifact status of the resource artifact, wherein the artifact status of the resource artifact is a descriptor indicating a status of the resource artifact; and
determining an artifact source of the resource artifact, wherein each artifact source is at least a version of a software package, wherein the at least a version of the software package, when executed, generates the resource artifact.

10\. (Previously Presented) The method of claim 9, further comprising:
determining if the resource artifact contains at least one vulnerability based on the artifact status and the artifact source.

11\. (Previously Presented) A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process for detection of cyber threats embedded in cloud applications, the process comprising:

detecting code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment;
filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and
detecting a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.

12\. (Previously Presented) A system for detection of cyber threats embedded in cloud applications, comprising:
a processing circuitry; and
a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:
detect code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment;
filter the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
perform a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository; and
detect a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool.

13\. (Original) The system of claim 12, wherein the system is further configured to;
report each identified potential cyber threat.

14\. (Previously Presented) The system of claim 12, wherein the system is further configured to:

compare the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities.

15\. (Previously Presented) The system of claim 12, wherein the non-unique portion includes at least one of: an operating system (OS) package data feature and a third-party code library data feature.

16\. (Previously Presented) The system of claim 12, wherein the system is further configured to:
compare hash values of the unique portion of the code to hash values of its verified version.

17\. (Previously Presented) The system of claim 12, wherein the code includes any one of: binary code, executable code, and high-level programming language code.

18\. (Original) The system of claim 12, wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.

19\. (Previously Presented) The system of claim 18, wherein the system is further configured to:
create a resource artifact hash for a resource artifact included in the code, wherein the resource artifact hash is a low-file-size representation of the resource artifact; and
compare the resource artifact hash with at least one repository hash, wherein each of the at least one repository hash is a low-file-size representation of an artifact included in a repository.

20\. (Previously Presented) The system of claim 19, wherein the system is further configured to:
determine an artifact status of the resource artifact, wherein the artifact status of the resource artifact is a descriptor indicating a status of the resource artifact; and

determine an artifact source of the resource artifact, wherein each artifact source is at least a version of a software package, wherein the at least a version of the software package, when executed, generates the resource artifact.

21\. (Original) The system of claim 20, wherein the system is further configured to:
determine if the resource artifact contains vulnerabilities based on the artifact status and the artifact source.

OFFICE ACTION:
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 .
1.	Claims 1-21 have been examined.
Response to Arguments
2.	Applicant’s arguments, filed 01/17/2024, with respect to the rejection(s) of claim 1 under 35 USC 103 have been fully considered and are persuasive.  Therefore, the rejection has been withdrawn.  However, upon further consideration, a new ground(s) of rejection is made in view of Dalessio et al. (U.S. Patent 10,235,527), Duan et al. (U.S. Patent Application Publication 2020/0065074) and Milner et al. (U.S. Patent Application Publication 2012/0090025).
Claim Interpretation
3.	For claims 4, 6, 15 and 17, the phrases “at least one of” and “any one of” have been given the broadest, reasonable interpretation of only requiring a single element from the given list in order to satisfy the requirements of the limitation.
4.	The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
5.	In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA  to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 103
6.	Claims 1-6 and 11-17 are rejected under 35 U.S.C. 103 as being unpatentable over Dalessio et al. (U.S. Patent 10,235,527; hereafter “Dalessio”), and further in view of Duan et al. (U.S. Patent Application Publication 2020/0065074; hereafter “Duan”), and further in view of Milner et al. (U.S. Patent Application Publication 2012/0090025; hereafter “Milner”).
For claims 1 and 11-12, Dalessio teaches a method, non-transitory computer readable medium and system for detection of cyber threats embedded in cloud applications (note Abstract, monitoring of cloud based applications; service can determine security vulnerabilities), comprising:
a processing circuitry (note column 16, lines 47-55, processing unit); and
a memory, the memory containing instructions that, when executed by the processing circuitry (note column 17, lines 4-12, memory for storing computer program instructions), configure the system to:
detect code of at least one cloud application that is for execution in a cloud amongst a plurality computing resources in a cloud environment (note column 10, lines 45-54, report server obtains a list of application packages; column 2, lines 62-67, application packages are deployed in a cloud based deployment platform);
perform a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository (note column 11, lines 7-12, report server can evaluate if any bit changed for the application package since the last scan, i.e. mismatch between portion of the code and its corresponding verified version); and
detect a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool (note column 11, lines 19-28, upon determination that condition is satisfied, i.e. mismatch, report sever executes notify process; note column 11, line 65 through column 12, line 13, notify process includes detection of vulnerabilities in libraries depended on by application package).
Dalessio differs from the claimed invention in that they fail to teach:
filter the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
Duan teaches:
filter the detected code to remove a portion of the code that is non-unique for the at least one cloud application (note paragraph [0035], server may skip common functions defined in standard framework and system include files that are popular across several source third-party codes; i.e. non-unique portions of code; note paragraph [0049], server may skip sub-directories of third-party code, since they are likely to be clones of other third-party code and server may skip overly “popular” files);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the cloud application vulnerability determination system of Dalessio and the skipping of non-unique portions of code of Duan. One of ordinary skill would have been motivated to combine Dalessio and Duan because skipping common, non-unique portions of code would speed of the parsing process (note paragraph [0035] of Duan).
The combination of Dalessio and Duan differs from the claimed invention in that they fail to explicitly teach:
a mismatch between any unique portion of code and its corresponding verified version stored in a code repository
Milner teaches:
perform a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository (note paragraph [0032]-[0034], hashed versions of archival files are compared with hashed versions in white list, i.e. verified version; note paragraphs [0019], [0029] and [0037], software package and white list are stored in software repository and software repository mirrors); and
detect a potential cyber threat embedded in the code based on a comparison of each identified mismatch with one or more data features using at least a vulnerability tool (note paragraphs [0033] and [0036], if software packages do not match secure components in the white list, i.e. mismatch, software package is compared against black list that contains known vulnerabilities, i.e. detection of potential cyber threat)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio and Duan and the white and black lists of hash values of software packages stored in software repositories of Milner. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications are stored in a software repository and hash values are compared against white and black lists (Milner).
For claims 2 and 13, the combination of Dalessio, Duan and Milner teaches claims 1 and 12, wherein the system is further configured to;
report each identified potential cyber threat (note column 4, lines 46-62 of Dalessio, report server provides status information to user device including vulnerability information).
For claims 3 and 14, the combination of Dalessio, Duan and Milner teaches claims 1 and 12, wherein the system is further configured to:
compare the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities (note paragraph [0035] of Duan, server may separately index source and header files of non-unique portions of code; note paragraphs [0032]-[0034] of Milner, file names and hashes are compared against white and black list to determine if file contains known vulnerabilities).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the cloud application vulnerability determination system of Dalessio and the skipping of non-unique portions of code of Duan. One of ordinary skill would have been motivated to combine Dalessio and Duan because skipping common, non-unique portions of code would speed of the parsing process (note paragraph [0035] of Duan).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio and Duan and the white and black lists of hash values of software packages stored in software repositories of Milner. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications are stored in a software repository and hash values are compared against white and black lists (Milner).
For claims 4 and 15, the combination of Dalessio, Duan and Milner teaches claims 1 and 12, wherein the non-unique portion includes at least one of:
an operating system (OS) package data feature and a third-party code library data feature (note paragraphs [0004], [0025] and [0049], non-unique portions of code skipped by server include operating system macros and sub-directories of third party code in libraries).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the cloud application vulnerability determination system of Dalessio and the skipping of non-unique portions of code of Duan. One of ordinary skill would have been motivated to combine Dalessio and Duan because skipping common, non-unique portions of code would speed of the parsing process (note paragraph [0035] of Duan).
For claims 5 and 16, the combination of Dalessio, Duan and Milner teaches claims 1 and 12, wherein the system is further configured to:
compare hash values of the unique portion of the code to hash values of its verified version note paragraphs [0032]-[0034] of Milner, hashes of software are compared against white list version of hash).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio and Duan and the white and black lists of hash values of software packages stored in software repositories of Milner. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications are stored in a software repository and hash values are compared against white and black lists (Milner).
For claims 6 and 17, the combination of Dalessio, Duan and Milner teaches claims 1 and 12, wherein the code includes any one of:
binary code, executable code, and high-level programming language code (note column 3, lines 16-42 of Dalessio, copy of the application package can include binary code and executable code).
7.	Claims 7-10 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Dalessio, Duan and Milner teaches as applied to claims 1 and 12 above, and further in view of Baierlein et al. (U.S. Patent Application Publication 2020/0371782; hereafter “Baierlein”).
For claims 7 and 18, the combination of Dalessio, Duan and Milner teaches differs from the claimed invention in that they fail to teach:
wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.
Baierlein teaches:
wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats (note paragraphs [0011], [0060] and [0079]-[0081], software includes artifacts and artifacts are scanned for security threats).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio, Duan and Milner teaches and the scanning of artifacts of Baierlein. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications include artifacts that are validated and scanned for threats (Baierlein).
For claims 8 and 19, the combination of Dalessio, Duan, Milner and Baierlein teaches claims 1 and 18, wherein the system is further configured to:
create a resource artifact hash for a resource artifact included in the code, wherein the resource artifact hash is a low-file-size representation of the resource artifact (note paragraphs [0061] and [0084] of Baierlein, hash of artifact is created); and
compare the resource artifact hash with at least one repository hash, wherein each of the at least one repository hash is a low-file-size representation of an artifact included in a repository (note paragraph [0092] of Baierlein, artifact hash is compared with repository hash).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio, Duan and Milner teaches and the scanning of artifacts of Baierlein. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications include artifacts that are validated and scanned for threats (Baierlein).
For claims 9 and 20, the combination of Dalessio, Duan, Milner and Baierlein teaches claims 8 and 19, wherein the system is further configured to:
determine an artifact status of the resource artifact, wherein the artifact status of the resource artifact is a descriptor indicating a status of the resource artifact (note paragraph [0026] of Baierlein, artifact status is determined; and
determine an artifact source of the resource artifact, wherein each artifact source is at least a version of a software package, wherein the at least a version of the software package, when executed, generates the resource artifact (note paragraphs [0069], [0076] and [0098] of Baierlein, artifact version is determined).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Dalessio, Duan and Milner teaches and the scanning of artifacts of Baierlein. It would have been obvious because combining prior art elements according to known methods would yield the predictable results determining vulnerabilities of cloud platform applications (Dalessio) where applications include artifacts that are validated and scanned for threats (Baierlein).
For claims 10 and 21, the combination of Dalessio, Duan, Milner and Baierlein teaches claims 9 and 20, wherein the system is further configured to:
determine if the resource artifact contains vulnerabilities based on the artifact status and the artifact source (note column 4, lines 46-57 and column 12, lines 1-5 of Dalessio, vulnerabilities are determined based on application version and status).
Conclusion
8.

APPLICANT REBUTTAL: REMARKS
Claims 1-21 are pending in the application and stand rejected under 35 U.S.C. §103.
Rej
ections of Claims Under 35 U.S.C.
Claims 1-2, 5-9, 11-13, and 16-20 stand rejected under 35 U.S.C. §103 as allegedly being unpatentable over U.S. Patent No. US10685115 of Lieberman et al. (hereinafter "Lieberman"), in view of U.S. Patent Publication No. 20200371782 of Baierlein et al. (hereinafter "Bai") in further view of U.S. Patent No. 11537400 of Zhang et al. (hereinafter "Zhang"). This ground of rejection is traversed for the following reasons.
At the outset, it should be noted that it is understood that each rejection for obviousness is based on a combination of references. Any argument below citing a single reference is so presented for purposes of clarity only and should
not
be considered as arguing the reference individually. Any discussion should be considered as arguing the combination of references. To this end, note that it will be explained why the references do
not
teach all of the elements of the claim for which they are cited, thus showing that the combination as a whole is
invalid
for lack of all of the claim elements and also therefore the cited references cannot properly be used as a basis for a proper rejection. It will also be explained why there is a
lack
of motivation to make the combination, and so again the alleged combination does not support a proper rejection.
Claim 1 requires (emphasis added):
A method for detection of cyber threats embedded in cloud
applications, comprising:
amongst a plurality computing resources i
ring the detected code to remove a portion
unique for the at least one cloud application;
performing a static analysis on each unique portion of the code to
identify a mismatch between any unique portion of the code and its
corresponding verified version stored in a code repository; and
detecting a potential cyber threat embedded in the code based on a
comparison of each identified mismatch with one or more data features
using at least a vulnerability tool.
The Office Action points to Lieberman as teaching performing a static analysis on each unique portion of the code to identify a mismatch, citing Lieberman, col. 13, lines 1- 15. However, Lieberman is
not
identifying any sort of mismatch. Actually, the
op
p
osite
is true. Lieberman is finding a match between the code and known cybersecurity threats or attacks. Thus, in a sense, Lieberman is doing the
op
p
osite
of what is called for in the claim, and, as such, it is
teaching away
from the claim element. In addition, Lieberman is matching the code against known threats,
not
against a code repository that contains a verified, i.e., correct version of the code.
Moreover, to actually quasi achieve what is achieved by this claim element, Lieberman has to compare the code against all known cybersecurity threats or attacks. This can be time consuming. Should nothing be found, it may be assumed that the code is verified. However, disadvantageously, the code may not actually be verified since it may contain a previously unknown cybersecurity threat or attack, which would
not
be detected by the comparison of Lieberman. By contrast, by comparing the code against a corresponding verified version stored in a code repository per the claim it is known with one comparison and with certainty that the code is correct.
Furthermore, this teaching of Lieberman cannot be modified to actually perform what is called for in the claim, namely, to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository because Lieberman teaches only to look at unique recurring bit strings, data patterns, etc. which is
not
,
and for which there is
no
suggestion to employ, a code repository.
Thus, Lieberman does
not
teach or suggest this claim element, which is
lacking
from the combination as a whole.
Bai also does
not
teach or suggest this claim element, notwithstanding the suggestion of the Office Action to the contrary. First, at best, e.g., per paragraph 92 of Bai, cited by the office Action, the
entire
artifact is hashed to produce a
singl
e
artifact signature even when the artifact is made up of multiple files. As such, there is
no
static analysis on each unique portion of the code as called for in the claim, and, indeed, there is
no
removal of non-unique code so as to leave any portion of the code that is a unique portion as called for in the claim
It is expected that the Office Action will try to argue that Zhang teaches omitting highly common packages. However, if one were to omit highly common packages from the code being analyzed in Bai, then the signature would change, thus rendering proper operation of Bai
impossible
as the signatures would always fail to match. Failure of a reference to operate properly is the hallmark of an
impro
p
er
combination.
Second, Bai does
not
teach comparing any unique portion of the code and its corresponding verified version stored in a code repository. Indeed, Bai need only have a database of valid keys to compare against the regenerated key and so Bai need
not
have, and hence is
not
teaching, any code repository or its use as called for in the claim. Note that, notwithstanding the Office Action's suggestion to the contrary, artifact repository 128 of Bai stores the actual artifact being tested itself and is
not
a code repository that stores a
verified version
of the artifact. See Bai, paragraphs 53, 59, and 61.
Thus, Bai
fails
to teach or suggest any verified version stored in a code repository as called for in the claim.
Furthermore, paragraph 80 of Bai, cited by the Office Action, is
irrelevant
because it is teaching to check embedded files e.g., images, stylesheets, scripts, and documents against anti-virus engines and threat intelligence database,
not
a code repository, as called for in the claim. A code repository and anti-virus engines and threat intelligence databases are very
different
things.
Thus, Bai does
not
teach or suggest this claim element, and so this claim element is
lacking
from the combination as a whole.
In addition, Zhang is not a proper reference. Zhang is directed to analyzing non-cloud-based applications in the hopes of modernizing them and transforming them into cloud based applications. Thus, Zhang does
not
actually detect code of at least one cloud application
that is for execution in the cloud
because the code being analyzed in Zhang is of non-cloud-based applications. Furthermore, Zhang, is directed to analyzing binary executable files in an attempt to associate such files with corresponding source code files to enable rewriting or recompiling the source code to develop a more modern application such as may be used in a cloud environment, as explained in column 3, lines 12-35. However, there is
no
mention of cyber threats in Zhang.
In addition, the purpose of removing portions of code from Zhang is because they do not serve as useful identifying characteristics. Moreover, what is being removed appears to be part of the already complete binary executable files of the application which are the
inp
u
t
to the process of Zhang. This has
nothing
to do with the code that is to be produced by the system of Zhang so that it can be executed in the cloud. In other words, the Office Action is looking at the
wrong
thing and at the
wrong
time in the process even if, arguendo, which Applicants
deny,
Zhang was a proper reference.
Thus, this claim element is
lacking
from Zhang, and hence is
lacking
from the combination as a whole.
Thus, the Office Action's proposed combination does
not
have all of the elements of claim 1, and, as such, independent claim 1 is allowable over the proposed combination under 35 U.S.C. §103.
As to the alleged motivation for combining the references, any such motivation is
irrelevant
at least because the references do
not
teach all of the claim features. Thus, even assuming that a person having ordinary skill in the art would be motivated to combine the references, such a combination would
not
result in all of the claim features. Accordingly, the claimed invention would
not
be obvious to a person having ordinary skill in the art.
In addition, given that the purpose of Zhang has
nothing
to do with detecting cyber threats, one of ordinary skill in the art, with Lieberman and Bai in front of him, would
not
look to modify Leiberman or Bai with anything from Zhang.
For at least the reasons discussed above, it is respectfully submitted that independent claim 1 is patentably distinguishable over the cited combination under 35 U.S.C. §103. Because claims 2 and 5-9 depend from independent claim 1, they incorporate the elements of independent claim 1 and are likewise patentably distinguishable over the combination. Withdrawal of this rejection is respectfully requested.
Independent claims 11 and 12 are rejected for substantially similar reasons as is claim 1. Accordingly, the above arguments are therefore essentially repeated, mutatis mutandis, and applied to claims 11 and 12. Thus, claims 11 and 12, as well as claims 13 and 16-20 which depend from claim 12, are likewise allowable.
Withdrawal of these rejections is respectfully requested.
Rej
ection of Claims Under 35 U.S.C.
Claims 3-4 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Lieberman, Bai, and Zhang and further in view of Duan et al. ("Identifying Open- Source License Violation and 1-day Security Risk at Large Scale", hereinafter Duan).
Claim 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Lieberman, Bai, and Zhang and further in view of Freitag et al. (US10691810, hereinafter Frei).
Given that all of these rejections of dependent claims are based on the combination of Lieberman, Bai, and Zhang, these claims are allowable at least for the same reasons given hereinabove with regard to the respective independent claim from which they depend as none of the additional references are cited as curing the above-described deficiencies of Lieberman, Bai, and Zhang.
Accordingly, withdrawal of these rejections under 35 U.S.C. §103 is respectfully requested.
CONCLUSION

NEXT OFFICE ACTION: 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 .
1.	Claims 1-21 have been examined.
Allowable Subject Matter
2.	Claims 1-21 are allowed.
The following is an examiner’s statement of reasons for allowance:
For independent claims 1 and 11-12, the prior art of record, alone or in combination, fails to teach the following limitations in conjunction with the rest of the claimed limitations:
filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application;
performing a static analysis on each unique portion of the code to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee.  Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
3.	The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Borate et al. (U.S. Patent 11755420) teaches malware detection and a repository of verified clean version snapshots (note Abstract and Fig. 6).
Maya et al. (U.S. Patent Application Publication 2022/0311794) teaches monitoring a software development pipeline including identifying build dependencies of other code and libraries, then scanning the code or particular subsets of the source code (note paragraphs [0713]-[0714]).
Jarrett et al. (U.S. Patent Application Publication 2011/0225128) teaches identifying corrupted files using a clean file repository (note paragraphs [0080]-[0082]).
4.

CITED REFERENCE SUMMARIES: Ref US10235527B1: [content unavailable]
Ref US20200065074A1: Claims:
A method comprising: parsing a program to identify a plurality of features within the program; performing a first match of the plurality of features to a plurality of code files based on a hierarchical code index, the features corresponding to leaf nodes of the hierarchical code index and the code files corresponding to parent nodes of the leaf nodes; normalizing the first match results to weight against common features; performing a second match of the plurality of code files to one or more code repositories based on the hierarchical code index; normalizing the second match results to weight against common files; and identifying a code repository of the one or more code repositories as being included within the program.
parsing a program to identify a plurality of features within the program;
performing a first match of the plurality of features to a plurality of code files based on a hierarchical code index, the features corresponding to leaf nodes of the hierarchical code index and the code files corresponding to parent nodes of the leaf nodes;
normalizing the first match results to weight against common features;
performing a second match of the plurality of code files to one or more code repositories based on the hierarchical code index;
normalizing the second match results to weight against common files; and
identifying a code repository of the one or more code repositories as being included within the program.
The method of claim 1 , wherein the features comprise at least one from among string literals, function names, parameter types, class names, and name spaces.
The method of claim 1 further comprising generating a respective identifier for each of the plurality of features, wherein performing the first match comprises querying the hierarchical code index with the respective identifiers.
The method of claim 1 , wherein performing the first match comprises skipping highly linked files.
The method of claim 1 further comprising: determining a version of the identified code repository included within the program.
The method of claim 5 , wherein determining the version comprises distinguishing between a plurality of versions of the identified code repository based on co-location information of features within the hierarchical code index.
A system comprising: one or more processors; and one or more memories have stored thereon instructions that, when executed by the one or more processors, control the one or more processors to: identify files within a computer to identify a plurality of files within a program code, the program code being organized in accordance with a hierarchical structure having a root repository; generate a feature identifier for each of a plurality of respective features of each of the plurality of files; derive a file identifier for each of the plurality of files based on the identifiers for the respective features of the plurality of files; derive a node identifier for each level of the hierarchical structure based on the files included therein; and map the features, file, and node identifiers as parent-child relationships within a hierarchical index based on the hierarchical structure of the program code.
one or more processors; and
one or more memories have stored thereon instructions that, when executed by the one or more processors, control the one or more processors to: identify files within a computer to identify a plurality of files within a program code, the program code being organized in accordance with a hierarchical structure having a root repository; generate a feature identifier for each of a plurality of respective features of each of the plurality of files; derive a file identifier for each of the plurality of files based on the identifiers for the respective features of the plurality of files; derive a node identifier for each level of the hierarchical structure based on the files included therein; and map the features, file, and node identifiers as parent-child relationships within a hierarchical index based on the hierarchical structure of the program code.
identify files within a computer to identify a plurality of files within a program code, the program code being organized in accordance with a hierarchical structure having a root repository;
generate a feature identifier for each of a plurality of respective features of each of the plurality of files;
derive a file identifier for each of the plurality of files based on the identifiers for the respective features of the plurality of files;
derive a node identifier for each level of the hierarchical structure based on the files included therein; and
map the features, file, and node identifiers as parent-child relationships within a hierarchical index based on the hierarchical structure of the program code.
The system of claim 7 , wherein the plurality of features comprise at least one from among string literals, function names, parameter types, class names, and namespaces for functions within each of the plurality of files.
The system of claim 7 , wherein the instructions, when executed by the one or more processors, further control the one or more processors to separately index source files and header files from within the program code, preserving the hierarchical structure of the program code.
The system of claim 7 , wherein deriving the file identifiers and the node identifiers comprises applying a Locality Sensitive Hash the feature identifiers of features included within the respective files and levels.
The system of claim 7 , wherein the instructions, when executed by the one or more processors, further control the one or more processors to: determine a respective Hamming distance for each of the feature, file, and node identifiers to existing mappings in the hierarchical index; and in response to determining that a Hamming distance is below a threshold, skip mapping of the respective feature, file, or node and all sub-portions of the hierarchical structure of the code.
determine a respective Hamming distance for each of the feature, file, and node identifiers to existing mappings in the hierarchical index; and
in response to determining that a Hamming distance is below a threshold, skip mapping of the respective feature, file, or node and all sub-portions of the hierarchical structure of the code.
The system of claim 7 , wherein the instructions, when executed by the one or more processors, further control the one or more processors to: identify a conditional branch within the program code; derive identifiers for features, file, and nodes within the conditional branch; and mapping the conditional branch within the hierarchical index as a conditional group of extracted features.
identify a conditional branch within the program code;
derive identifiers for features, file, and nodes within the conditional branch; and
mapping the conditional branch within the hierarchical index as a conditional group of extracted features.
The system of claim 7 , wherein the instructions, when executed by the one or more processors, further control the one or more processors to: identify one or more unique feature sets within a code version of the program code; and separately index the one or more unique feature sets to distinguish between code versions.
identify one or more unique feature sets within a code version of the program code; and
separately index the one or more unique feature sets to distinguish between code versions.
The system of claim 13 , wherein the one or more unique feature sets comprises co-location information corresponding to bi-directional mapping between parents and children within the hierarchical structure of the program code.
The system of claim 7 , wherein the instructions, when executed by the one or more processors, further control the one or more processors to crawl a code repository to identify the program code.
A non-transitory computer readable medium having stored thereon instructions for performing a method comprising: parsing a program to identify a plurality of features within the program; and identifying a third-party code included within the program by: matching the plurality of features to a plurality of leaf nodes of a hierarchical index structure, recursively matching the nodes to higher level nodes within the hierarchical index structure to identify a top-level repository node match, and identifying the third-party code corresponding to the top-level repository node.
parsing a program to identify a plurality of features within the program; and
identifying a third-party code included within the program by: matching the plurality of features to a plurality of leaf nodes of a hierarchical index structure, recursively matching the nodes to higher level nodes within the hierarchical index structure to identify a top-level repository node match, and identifying the third-party code corresponding to the top-level repository node.
matching the plurality of features to a plurality of leaf nodes of a hierarchical index structure,
recursively matching the nodes to higher level nodes within the hierarchical index structure to identify a top-level repository node match, and
identifying the third-party code corresponding to the top-level repository node.
The non-transitory computer readable medium of claim 16 , wherein the method further comprises determining a version of the identified third-party code included within the program.
The non-transitory computer readable medium of claim 17 , wherein determining the version comprises determining the version based on a bi-directional between the leaf nodes and the top-level repository node.
The non-transitory computer readable medium of claim 16 , wherein identifying the third-party code further comprises normalizing matches to higher level nodes based on relative uniqueness.
The non-transitory computer readable medium of claim 19 , wherein identifying the third-party code further comprises filtering the higher level nodes based on the normalization.
Ref US20120090025A1: Claims:
A method for software security, comprising: identifying a component contained in a software package; comparing the component contained in the software package to a list of known insecure components; and classifying the software package as insecure if the compared component matches an insecure component on the list of known insecure components.
identifying a component contained in a software package;
comparing the component contained in the software package to a list of known insecure components; and
classifying the software package as insecure if the compared component matches an insecure component on the list of known insecure components.
The method of claim 1 , wherein comparing the component comprises comparing a hashed version of the component contained in the software package to hashed versions of insecure components on the list of known insecure components.
The method of claim 1 , wherein the component contained in the software package comprises an archival file contained in the software package.
The method of claim 1 , the method further comprising: preventing installation of the software package if the software package is classified as insecure.
preventing installation of the software package if the software package is classified as insecure.
The method of claim 1 , wherein the software package is a new software package added to a software repository.
The method of claim 1 , the method further comprising: preventing addition of the software package to a software repository if the software package is classified as insecure.
preventing addition of the software package to a software repository if the software package is classified as insecure.
The method of claim 1 , the method further comprising: notifying a user of the insecure component and details of the insecure component.
notifying a user of the insecure component and details of the insecure component.
A non-transitory computer readable medium comprising instructions for causing a processor to perform the method, comprising: identifying a component contained in a software package; comparing the component contained in the software package to a list of known insecure components; and classifying the software package as insecure if the compared component matches an insecure component on the list of known insecure components.
The non-transitory computer readable medium of claim 8 , wherein comparing the component comprises comparing a hashed version of the component contained in the software package to hashed versions of insecure components on the list of known insecure components.
The non-transitory computer readable medium of claim 8 , wherein the component contained in the software package comprises an archival file contained in the software package.
The non-transitory computer readable medium of claim 8 , the method further comprising: preventing installation of the software package if the software package is classified as insecure.
The non-transitory computer readable medium of claim 8 , wherein the software package is a new software package added to a software repository.
The non-transitory computer readable medium of claim 8 , the method further comprising: preventing addition of the software package to a software repository if the software package is classified as insecure.
The non-transitory computer readable medium of claim 8 , the method further comprising: notifying a user of the insecure component and details of the insecure component.
A apparatus for software security, comprising: a memory containing instructions; and a processor configured to execute the instructions to perform the method comprising: identifying a component contained in a software package; comparing the component contained in the software package to a list of known insecure components; and classifying the software package as insecure if the compared component matches an insecure component on the list of known insecure components.
a memory containing instructions; and
a processor configured to execute the instructions to perform the method comprising: identifying a component contained in a software package; comparing the component contained in the software package to a list of known insecure components; and classifying the software package as insecure if the compared component matches an insecure component on the list of known insecure components.
The apparatus of claim 15 , wherein comparing the component comprises comparing a hashed version of the component contained in the software package to hashed versions of insecure components on the list of known insecure components.
The apparatus of claim 15 , wherein the component contained in the software package comprises an archival file contained in the software package.
The apparatus of claim 15 , the method further comprising: preventing installation of the software package if the software package is classified as insecure.
The apparatus of claim 15 , wherein the software package is a new software package added to a software repository.
The apparatus of claim 15 , the method further comprising: notifying a user of the insecure component and details of the insecure component.
Ref US10235527: Claims:
1. A method, comprising:
receiving, by a report server from a user device, a command-line request to identify applications running on a cloud application platform that are installed with application packages having one or more vulnerabilities;
in response to receiving the command-line request to identify applications running on the cloud application platform that are installed with application packages having one or more vulnerabilities, querying, by the report server, a plurality of nodes of the cloud application platform that are running instances of the application specified by the request;
generating, by each of one or more nodes in the cloud application platform that is hosting an instance of the application specified by the request, application metadata for a respective application executing on the node;
providing, by each of the one or more nodes in the cloud application platform, the generated metadata to the report server;
receiving, by the report server from a distributed computing platform, a copy of an application package deployed on a distributed computing platform, the application package including an application that is dependent on one or more libraries;
extracting library identifiers from the application package, each library identifier corresponding to a respective library that the application is dependent on;
determining, based on the library identifiers and from a library index database, a respective library version of each library;
determining for each library, based on each library identifier, the corresponding library version, and from a software vulnerability database, any vulnerabilities for the library, each vulnerability being represented by a respective vulnerability identifier and a respective vulnerability severity score, each vulnerability severity score indicating a likelihood that a respective library will cause a security breach of the distributed computing platform; and
providing a notification to the user device indicating that the application package is vulnerable to one or more security breaches upon determining that a vulnerability severity score of at least one of the libraries satisfies a vulnerability threshold,
wherein the method is performed by a plurality of computers.
2. The method of claim 1, wherein extracting the library identifiers is triggered by at least one of:
a scheduled inspection time having been satisfied;
a signature of the application package having changed value; or
the software vulnerability database having been updated.
3. The method of claim 1, wherein extracting the library identifiers comprises performing a multipass scan of the application package and environment in which the application package is stored, wherein performing the multipass scan comprises:
in a first pass, extracting text strings from at least one of: an environment variable of an operating system of the application, metainformation of an operating system of the application package, a directory structure storing the application, or an inclusion path of the application;
in a second pass, determining a respect signature for each library of the application package; and
designating the text strings and the signatures as the library identifiers.
4. The method of claim 3, wherein determining the respective library version of each of the libraries comprises:
querying a library index database using the respective signatures; and
obtaining each respective library version according to a match between the respective signature in the library identifiers and a signature associated with the library version in the library index database.
5. The method of claim 1, wherein determining the respective vulnerability severity score comprises:
querying the software vulnerability database using the each library identifier and the corresponding library version; and
obtaining a list of vulnerability identifiers and the respective vulnerability severity scores from the software vulnerability database.
6. The method of claim 1, comprising determining that the vulnerability satisfies the vulnerability threshold due to obsolescence of the corresponding library or a newly-discovered form of attack.
7. The method of claim 1, wherein the vulnerability is represented by a Common Vulnerability and Exposure (CVE) identifier, the vulnerability severity score is a Common Vulnerability Scoring System (CVSS) score, and the software vulnerability database is a National Vulnerability Database (NVD).
8. The method of claim 7, wherein providing the notification to the user device indicating that the application package is vulnerable comprises:
generating a tabulated report that includes the CVE identifier, the vulnerability severity score, a rep
[Truncated to input limit]