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.
Rejections of Claims Under 35 U.S.C. §103
Claims 1-6 and 11-17 stand rejected under 35 U.S.C. §103 as allegedly being unpatentable over U.S. Patent No. 10,235,527 of Dalessio et al. (hereinafter “Dalessio”), in view of U.S. Patent Publication No. 2020/0065074 of Duan et al. (hereinafter “Duan”) in further view of U.S. Publication Patent No. 2012/0090025 of Milner et al. (hereinafter “Milner”).  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 can
not
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:
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.
The Office Action points to Dalessio as teaching performing a static analysis on each unique portion of the code to identify a mismatch, citing Dalessio, column 11, lines 7-12.  However, there is
nothing
in Dalessio that suggests isolating unique code portions, as is the upshot of the claim’s filtering element.  Thus, Dalessio is
not
identifying a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.  Furthermore, as will be shown hereinbelow, Duan does
not
teach or suggest the filtering step.
First, Dalessio is comparing the whole application package,
not
a unique portion thereof as called for in the claim.  Thus, if there is a change, it might be in a non-unique portion.  Therefore, while it is true that the change might be in a unique portion, nevertheless Dalessio does
not
know or care if that is the case,
nor
does it so determine.  Thus, Dalessio is
not
performing the step as particularly called for in the claim
nor
is it suggesting to do so.
Second, Dalessio is only comparing the current version of the application package to the prior version of itself at the time of the prior scan.  There is
no
teaching or suggestion that such prior version is a verified version
stored in a code repository
.  It is quite possible that the prior version already had a mismatch with respect to a verified version itself.
Note that the claim element is
not
merely find a mismatch between one thing and another.  Rather, it is quite specific in requiring to find a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.  Dalessio does
not
teach or suggest the claim element when all of the words are taken together properly.
Thus, Dalessio does
not
teach or suggest this claim element, which is
lacking
from the combination as a whole.
The Office Action attempts to compensate for these
failings
of Dalssio by citing Milner.  However, Milner, like Dalessio, does
not
teach that any analysis is performed on each unique code portion of the code.  There is
no
filtering of detected code to remove a portion of the code that is non-unique
so as to produce unique portions in Milner, and, as a result, of course it can
not
teach or suggest that any analysis is performed on each unique code portion of the code.  In fact, the
opposite
is true.  Milner teaches to compare the entirety of the code.  This can be seen from the fact that Milner teaches to hash over the whole version of the software package,
not
merely various unique portions thereof.  See, e.g., Milner, paragraphs 32-34.  There is simply
nothing
in Milner that suggests isolating unique code portions, as is the upshot of the claim’s filtering element.  Thus, Milner, like Dalessio, is
not
identifying a mismatch between any unique portion of the code and its corresponding verified version
stored in a code repository
.
Furthermore, the operations performed in Milner are actually performed in the code repository itself, e.g., by security tool 118.  These operations are performed, for example, when determining whether to admit a new software package into the code repository.  See Milner, at least paragraphs 28-37 and FIG. 1, where it is clear that security tool 118, which performs the various security operations on software packages. is within software repository 104.
Thus, Milner does
not
teach or suggest that for which it is cited and it suffers from at least the same defects as does Dalessio, and hence Milner can
not
modify Dalessio to create the claim elements for which Dalessio and Milner are cited.  As such, the claim elements for which Dalessio and Milner are cited are
lacking
from the proposed combination as a whole.
Turning to Duan, it is cited as teaching the claim element of
filtering the detected code to remove a portion of the code that is non-unique
for the at least one cloud application.  In particular, paragraphs 35 and 49 of Duan are cited.  However, these paragraphs do
not
teach to remove any
portion of code
as called for in the claim.  Rather, paragraph 35 appears to be teaching that certain portions of code are
not
considered for matching purposes as keeping such function bodies, common strings, and functions would slow down the system or dilute matching
results
.  Paragraph 49 of Duan relates to filtering search
results
,
not
actually
removing a portion of the code that is non-unique
as is called for in the claim.  In this regard, note that paragraph 49 starts with (emphasis added):
In some cases, server 110 may apply matching rules to improve
results
and / or filter out false positive.
The rest of paragraph 49 gives examples of doing this.  Note that the search
results
which are filtered in paragraph 49 are produced in paragraph 48 of Duan, and at least these paragraphs must be taken together.
Thus, Duan does
not
teach or suggest that for which it is cited by the Office Action, and hence it can
not
modify Dalesssio or Milner to introduce thereto the features for which Duan is cited by the Office Action, even it, arguendo, Dalessio and Milner taught that for which they are cited by the Office Action, which Applicants have shown hereinabove they do
not
.
Thus, the Office Action’s proposed combination does
not
have any 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 any 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.
Also, Applicants note that there is
no
real motivation provided to make the entire combination in toto, and furthermore, there is
no
showing by the Office Action that the proposed overall combination would solve the problem recognized by Applicants.  Also, there is
no
showing made by the Office Action as to how to combine the references to construct Applicants’ invention as claimed.  There is also
no
showing that the art has recognized the problem solved by Applicants or that one looking at the cited references would recognize such a problem and combine the references in a manner that would solve the problem.  In fact, the opposite would appear to be true, as each reference appears to believe that it has solved all the problems of the art to which it is relevant.
MPEP §2143, citing KSR, states that "[t]he key to supporting any rejection under 35 U.S.C. 103 is the clear articulation of the reason(s) why the claimed invention would have been obvious."  The Supreme Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be "made explicit" (emphasis added, see also KSR IntI Co. v. Teleflex Inc., 82 USPQ2d 1385, 1395-97 (2007)).  Thus, the provisions of MPEP §2143 require a clear articulation of reasons to support obviousness rejections under 35 U.S.C. § 103.
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-5 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-17 which depend from claim 12, are likewise allowable.
Withdrawal of these rejections is respectfully requested.
Claims 5 and 16 are also allowable on their own merits.  As explained above, Milner teaches to hash the entirety of the code,
not
just the unique portions of the code as called for in the claims.
Rejection of Claims Under 35 U.S.C. §103
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, and further in view of Baierlein et al. (U.S. Patent Application Publication 2020/0371782; hereafter “Baierlein”).
Given that all of these rejections of dependent claims are based on the combination of Dalessio, Duan, and Milner, 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 Dalessio, Duan, and Milner.
Also, there is no motivation to make the combination.
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]