Office Action 3: Non-Final Rejection (2023-11-13)
Rejection types: 103 - Obviousness

CLAIMS:
AMENDMENTS TO THE CLAIMS

This listing of claims will replace all prior versions and listings of claims in the application:

1\. (Currently Amended) 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\. (Currently Amended) 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 \[\[a\]\] 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\. (Currently Amended) 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\. (Currently Amended) 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\. (Currently Amended) 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 \[\[a\]\] 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:
DETAILED ACTION
This non-final office action is in response to applicant’s RCE filed on 07/24/2023 for response of office action mailed on 04/20/2023. Claims 1, 8, 11, 12 and 19 are currently amended. No claim is added and cancelled. Claims 1-21 are being examined and pending.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/24/2023 has been entered.
Response to Arguments
Applicant’s amendments to claims 8 and 19, filed on 07/24/2023, with respect to claim objections have been fully considered. The amendments overcame the objections, therefore the claim objections have been withdrawn.
Applicant’s arguments  on independent claim 1 on page 9, filed on 07/24/2023, with respect to claim rejection under 35. U.S.C 103 has been considered. The argument related to prior art Zhang is not persuasive.
As provided in further detail below, applicant’s arguments regarding that the references fail to show certain features are unpersuasive in view of the grounds of rejection discussed in detail. Please note that during patent examination, the pending claims even when interpreted in view of the specification must be “given their broadest reasonable interpretation.” Phillips v. AWH Corp., 415 F.3d 1303, 1316, 75 USPQ2d 1321, 1329 (Fed. Cir. 2005), In re Am. Acad, of Sci. Tech. Ctr., 367 F.3d 1359, 1364, 70 USPQ2d 1827, 1830] (Fed. Cir. 2004). As such, although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims.
Regarding arguments on claim 1 on page 9-11, claim 1 is amended with new limitation,  detecting code of at least one cloud application that is for execution in a cloud
Regarding arguments on claim 1 regarding prior art Zhang, applicant argues that Zhang does not mention cyber threats. But new prior art Lieberman teaches threat detection for cloud native application (Abstract) through by analyzing images and comparing threat signatures before the application is deployed in the cloud (Fig. 4).
Regarding arguments on claim 1 regarding prior art Zhang, applicant argues that there is nothing about a mismatch in Zhang. But new prior art Lieberman teaches identify cyber threat for a cloud native application by matching threat signature (claim 1). In addition, Baierlein et al. (US20200371782) teaches validating cloud application by comparing hash value with the one stored in the repository, if mismatch, rejecting the deployment of the application in the cloud (Para. 0096).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary.  Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 5-9, 11-13, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over  Lieberman et al. (US10685115, hereinafter Lieberman) in view of Baierlein et al. (US20200371782, hereinafter Bai), and further in view of Zhang et al. (US11537400, hereinafter Zhang)
Regarding claim 1, 11, and 12, Lieberman teaches a method for detection of cyber threats embedded in cloud applications (Lieberman: a method for implementing cloud native application threat detection, Abstract), comprising: detecting code of at least one cloud application executing amongst a plurality computing resources in a cloud environment (Lieberman: receiving a cloud native application (CNA) image or application granularity image (AGI) through triggering event during testing stage before deployment, wherein the CNA is developed as a collaboration of microservices; Col. 2, line 40-52; Col. 5, line 38-43; Fig. 4: #424, #426, #428); performing a static analysis on the unique code to identify a mismatch (Lieberman: RIE manager scanning images to detect unique recurring bit strings or data patterns by comparing identified potential threat signature with library for match/mismatch; Col. 13, line 1-15; Fig. 4: #430, #440, #442; #444); and detecting a potential cyber threat embedded in the code based on a comparison of each identified match with one or more data features using at least a vulnerability tool (Lieberman: RIE manager (vulnerability tool) comparing identified potential threat signature (data feature) with threat signature library, identifying cyber threat based on the comparison, and preventing the deployment of the application; Col. 8, line 13-18; Claim 1; Fig. 4: #462A).
Yet, Lieberman does not teach performing static analysis on the code to identify a mismatch between the code and its verified version stored in a code repository and detecting a potential threat in the code based on a comparison of each identified mismatch with one or more data features.
However, in the same field of endeavor, Bai teaches performing static analysis on the code to identify a mismatch between the code and its verified version stored in a code repository (Bai: performing static screening of application including dependency checks by crawling images and scripts, Para. 0080; comparing the re-generated hash key with the hash key associated with the application stored in the repository 128, Para. 0092; updated/verified versions are stored in the repository 128, Para. 0063) and detecting a potential threat in the code based on a comparison of each identified mismatch with one or more data features (Bai: if no match is found based on the above comparison, the application is identified as not genuine, the deployment of application is rejected; Para. 0092 and 0096).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by Lieberman to include performing static analysis on the code to identify a mismatch between the code and its verified version stored in a code repository and detecting a potential threat in the code based on a comparison of each identified mismatch with one or more data features as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Yet, combination of Lieberman and Bai does not explicitly teach filtering the detected code to remove a portion of the code that is non-unique.
However, in the same field of endeavor, Zhang teaches filtering the detected code to remove a portion of the code that is non-unique (Zhang: filtering the decomposed application data to omit highly common packages, method names that not serve as useful identifying characteristics; Col. 12, line 16-20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by Mos to include filtering the detected code to remove a portion of the code that is non-unique as disclosed by Zhang. One of ordinary skill in the art would have been motivated to make this modification in order to reduce exposure to security vulnerabilities as suggested by Zhang (Zhang: Col. 2, line 46-47).
Regarding claims 2 and 13, combination of Lieberman, Bai and Zhang teaches the method of claim 1. In addition, Lieberman further teaches reporting each identified potential cyber threat (Lieberman: Col. 13, line 57-63).
Regarding claims 5 and 16, combination of Lieberman, Bai and Zhang teaches the method of claim 1.
In addition, Bai further teach 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 (Bai: Para. 0082, 0084, 0092, 0096).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include 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 as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Regarding claims 6 and 17, combination of Lieberman, Bai and Zhang teaches the method of claim 1. In addition, Bai teaches wherein the code includes any one of: binary code, executable code, and high-level programming language code  (Bai: Para. 0053).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include wherein the code includes any one of: binary code, executable code, and high-level programming language code as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Regarding claims 7 and 18, combination of Lieberman, Bai and Zhang teaches the method of claim 1.
In addition, Bai teaches wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats (Bai: Para. 0011, 0060, 0079-0081).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Regarding claims 8 and 19, combination of Lieberman, Bai and Zhang teaches the method of claim 7.
In addition, Bai further teaches 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 (Bai: Para. 0061, 0084); 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 (Bai: Para. 0092).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include 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  as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Regarding claims 9 and 20, combination of Lieberman, Bai and Zhang teaches the method of claim 8.
In addition, Bai teaches 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 (Bai: Para. 0026); and determining an artifact source of the resource artifact, wherein each artifact source is at least a version of software package, wherein the at least a version of software package, when executed, generates the resource artifact (Bai: Para. 0069, 0076 and 0098).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include 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 software package, wherein the at least a version of software package, when executed, generates the resource artifact  as disclosed by Bai. One of ordinary skill in the art would have been motivated to make this modification in order to monitor artifacts to detect malicious code as suggested by Bai (Bai: Para. 0072 and 0079).
Claims 3-4 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Lieberman in view of 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).
Regarding claims 3 and 14, combination of Lieberman, Bai and Zhang teaches the method of claim 1.
Yet, the combination does not teach comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities.
However, in the same field of endeavor, Duan teaches comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities (Duan: Page 2169, Abstract).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities as disclosed by Duan. One of ordinary skill in the art would have been motivated to make this modification in order to identify vulnerabilities for common codes as suggested by Duan (Duan: (Duan: Page 2169, abstract).
Regarding claims 4 and 15, combination of Lieberman, Bai and Zhang teaches the method of claim 1.
Yet, the combination does not teach 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
However, in the same field of endeavor, Duan teaches 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  (Duan: Page 2169, Abstract).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include 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 as disclosed by Duan. One of ordinary skill in the art would have been motivated to make this modification in order to identify vulnerabilities for third party codes as suggested by Duan (Duan: (Duan: Page 2169, abstract).
Claims 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Lieberman in view of Zhang and Bai, and further in view of Freitag et al. (US10691810, hereinafter Frei).
Regarding claims 10 and 21, combination of Lieberman, Bai and Zhang teaches the method of claim 9. In addition, Bai further teaches determining if the resource artifact contains vulnerabilities (Bai: monitoring artifacts to detect malicious code; Para. 0072, 0079, 0080, 0102)
Yet, the combination does not teach determining if the resource artifact contains at least one vulnerability based on the artifact status and the artifact source.
However, in the same field of endeavor, Frei teaches determining if the resource artifact contains at least one vulnerability based on the artifact status and the artifact source (Frei: Col. 7, line 38-63).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method disclosed by the combination to include determining if the resource artifact contains at least one vulnerability based on the artifact status and the artifact source  as disclosed by Frei. One of ordinary skill in the art would have been motivated to make this modification in order to detect vulnerabilities associated with a software application build as suggested by Frei (Frei: Col. 4, line 15-16).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Haghighat et al. (US20210263779): system load common code libraries, Para. 0688; calculate hash of container value, Para. 0744; comparing hash value with stored hash in the table, Para. 0749.

APPLICANT REBUTTAL: REMARKS
Claims 1-21 are pending in the application and stand rejected under 35 U.S.C. §103 while claims 8 and 19 are objected to.
By the foregoing amendments, various claims have been amended. The amendments to the claims are proper and justified and are supported by the specification and claims as originally filed. No new matter has been added.
Objection to Claims
Claims 8 and 19 are objected to for minor informalities. Applicants have amended these claims either as suggested by the Office Action or in a way that is intended to correct the informality that it appears was being identified by the Office Action. Note that the intent is to define what a repository hash is without referring back to any particular repository hash. Withdrawal of these objections is respectfully requested.
Rej
ections of Claims Under 35 U.S.C.
Claims 1-2, 5-6, 11-13 and 16-19 stand rejected under 35 U.S.C. §103 as allegedly being unpatentable over U.S. Patent Publication No. 2021026633 of Moshitzky et al. (hereinafter "Mo"), in view of U.S. Patent No. 11537400 of Zhang et al. (hereinafter "Zhang"). This ground of rejection is generally traversed for the following reasons although in the interest of advancing prosecution an amendment is also made to the independent claims.
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, as amended, requires (emphasis added):
A method for detection of cyber threats embedded in cloud
applications, comprising:
amongst a plurality computing
;
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 amendment to the claim makes further explicit what should already have been clear from the claim language as previously presented, namely, that what is being detected and analyzed for cyber threats is applications that are to be executed in the cloud itself. This is
different
from Mo, where the applications are to be run on some type of client device or endpoint, which is
not
in the cloud, e.g., per Mo, paragraphs 26-31 and 52. Note that Mo teaches that its analysis may be performed in the cloud, but performing the analysis in the cloud does
not
transform the actual application being analyzed into a cloud application
that is for execution in the cloud
amongst a plurality computing resources in a cloud environment as called for in the claim. Thus, this claim element is
lacking
from Mo.
Furthermore, this claim element is
not
taught or suggested by Zhang, which is 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 that being analyzed in Zhang is of non-cloud-based applications. Thus, this element is
lacking
from the combination as a whole.
While Mo teaches to perform a static analysis, there is
no
teaching or suggestion of identifying to detect a mismatch between any unique portion of the code and its
corresponding verified version stored in a code repository, as is called for in the claim. The only mismatch mentioned is Mo is a mismatch of a file type, e.g., the type of the file such as is indicated by its extension, such as mp3, does
not
match the contents of the file, e.g., the contents being executable code rather than an mp3 coded audio file. This is
not
the mismatch called for in the claim.
Furthermore, the "features" of Mo are actually just another name for the rules of the analysis engine per paragraph 54 of Mo. This is
different
from the data features of the claim which are related to the code itself that is being analyzed.
As such, Mo does
not
teach or suggest this claim element.
In addition, it should be appreciated that Mo does
not
actually analyze the actual source or object code directly. Rather, per paragraph 52, Mo creates a reverse engineered intermediate source code form of the object code from the object code. Such reverse engineered intermediate source code form of the object code is
not
suitable for use with the invention as claimed, because such reverse engineered intermediate source code form of the object code will
not
be found in a code repository, and certainly
not
as a verified version of the code, as it is created as part of the process of Mo. This is likely one of the reasons there is
no
mention of any code repository in Mo.
Thus, not only are these claim elements
lacking
from Mo, but they are
not,
and cannot be suggested by Mo. Furthermore, the partial claim language referenced by the Office Action in regard to these claim elements also can be seen to
not
actually be taught or suggested by Mo.
Turning back to Zhang, as noted, it 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. There is
no
mention of cyber threats in Zhang.
The version control system of Zhang is also
not
used in the manner that the code repository is used in the claim. In the claim, the code at issue is compared with the verified version of the code in the repository to find mismatches between them, i.e., to find portions of the code that are not as they should be as indicated by the code in
the repository. By contrast, the repository in Zhang contains source code that is to be matched with the executable code to discover which source code corresponds to the executable code. See, for example, Zhang, column 8, line 15 to column 10, line 67.
In addition, there is
nothing
about a mismatch in Zhang. First, while not dispositive, the word mismatch does
not
appear in Zhang based on a keyword search. Second, what the Office Action points to in this regard relates to finding matches between the executable code and the source code,
not
mismatches between any unique portion of the code and its corresponding verified version stored in a code repository. In this regard, unlike Zhang, for code to match its corresponding verified version stored in a code repository, as called for in the claim, both versions of the code must match exactly. One cannot be executable code while the other is source code.
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 Mo in front of him, would
not
look to modify Mo 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, 5-6,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-19 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 Mos in view of Zhang, and further in view of Duan et al. ("Identifying Open-Source License Violation and 1-day Security Risk at Large Scale", hereinafter Duan).
Claims 7-9 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mo in view of Zhang and further in view of Baierlein et al. (US20200371782, hereinafter Bai).
Claim 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Mo in view of Zhang and Bai 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 Mo 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 Mo 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.
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.

CITED REFERENCE SUMMARIES: Ref US20170109535A1: Claims:
An investigation apparatus comprising a processor that executes a process comprising: analyzing uniqueness of a plurality of values included in an attribute for each attribute of a table; reducing a plurality of values included in an attribute of which the analyzed uniqueness is lower than a predetermined value by a predetermined ratio with respect to an investigation original table and outputting a feature of the investigation original table; reducing a plurality of values included in an attribute of which the analyzed uniqueness is higher than a predetermined value by a predetermined ratio with respect to an investigation target table and outputting a feature of the investigation target table; and investigating similarity of the investigation target table to the investigation original table by comparing the feature of the investigation original table with the feature of the investigation target table.
analyzing uniqueness of a plurality of values included in an attribute for each attribute of a table;
reducing a plurality of values included in an attribute of which the analyzed uniqueness is lower than a predetermined value by a predetermined ratio with respect to an investigation original table and outputting a feature of the investigation original table;
reducing a plurality of values included in an attribute of which the analyzed uniqueness is higher than a predetermined value by a predetermined ratio with respect to an investigation target table and outputting a feature of the investigation target table; and
investigating similarity of the investigation target table to the investigation original table by comparing the feature of the investigation original table with the feature of the investigation target table.
The investigation apparatus according to claim 1 , the process further comprising storing the feature of the investigation original table, wherein the investigating compares the feature of the investigation original table stored in the storing with the feature of the investigation target table.
storing the feature of the investigation original table,
wherein the investigating compares the feature of the investigation original table stored in the storing with the feature of the investigation target table.
The investigation apparatus according to claim 1 , wherein the outputting reduces a plurality of the values included in the low attribute by a ratio corresponding to a ratio based on the number of unique values included in the low attribute and the number of records of the investigation original table.
The investigation apparatus according to claim 1 , wherein the outputting reduces a plurality of the values included in the high attribute by a ratio corresponding to a ratio based on the number of unique values included in the high attribute and the number of records of the investigation target table.
A non-transitory computer-readable recording medium having stored therein a program that causes a computer to execute a process comprising: analyzing uniqueness of a plurality of values included in an attribute for each attribute of a table; reducing a plurality of values included in an attribute of which the analyzed uniqueness is lower than a predetermined value by a predetermined ratio with respect to an investigation original table and outputting a feature of the investigation original table; reducing a plurality of values included in an attribute of which the analyzed uniqueness is higher than a predetermined value by a predetermined ratio with respect to an investigation target table and outputting a feature of the investigation target table; and investigating similarity of the investigation target table to the investigation original table by comparing the feature of the investigation original table with the feature of the investigation target table.
The non-transitory computer-readable recording medium according to claim 5 , the process further comprising storing the feature of the investigation original table, wherein the investigating compares the feature of the investigation original table stored in the storing with the feature of the investigation target table.
The non-transitory computer-readable recording medium according to claim 5 , wherein the outputting reduces a plurality of the values included in the low attribute by a ratio corresponding to a ratio based on the number of unique values included in the low attribute and the number of records of the investigation original table.
The non-transitory computer-readable recording medium according to claim 5 , wherein the outputting reduces a plurality of the values included in the high attribute by a ratio corresponding to a ratio based on the number of unique values included in the high attribute and the number of records of the investigation target table.
An investigation method comprising: analyzing uniqueness of a plurality of values included in an attribute for each attribute of a table by a processor; reducing a plurality of values included in an attribute of which the analyzed uniqueness is lower than a predetermined value by a predetermined ratio with respect to an investigation original table and outputting a feature of the investigation original table, by the processor; reducing a plurality of values included in an attribute of which the analyzed uniqueness is higher than a predetermined value by a predetermined ratio with respect to an investigation target table and outputting a feature of the investigation target table, by the processor; and investigating similarity of the investigation target table to the investigation original table by comparing the feature of the investigation original table with the feature of the investigation target table, by the processor.
analyzing uniqueness of a plurality of values included in an attribute for each attribute of a table by a processor;
reducing a plurality of values included in an attribute of which the analyzed uniqueness is lower than a predetermined value by a predetermined ratio with respect to an investigation original table and outputting a feature of the investigation original table, by the processor;
reducing a plurality of values included in an attribute of which the analyzed uniqueness is higher than a predetermined value by a predetermined ratio with respect to an investigation target table and outputting a feature of the investigation target table, by the processor; and
investigating similarity of the investigation target table to the investigation original table by comparing the feature of the investigation original table with the feature of the investigation target table, by the processor.
The investigation method according to claim 9 , further comprising storing the feature of the investigation original table by the processor, wherein the investigating compares the feature of the investigation original table stored in the storing with the feature of the investigation target table.
storing the feature of the investigation original table by the processor,
The investigation method according to claim 9 , wherein the outputting reduces a plurality of the values included in the low attribute by a ratio corresponding to a ratio based on the number of unique values included in the low attribute and the number of records of the investigation original table.
The investigation method according to claim 9 , wherein the outputting reduces a plurality of the values included in the high attribute by a ratio corresponding to a ratio based on the number of unique values included in the high attribute and the number of records of the investigation target table.
Ref US20150356451A1: Claims:
A method of generating data models in a mobile computing device in response to deriving a set of features specific to an application based on a lightweight binary analysis of the application, comprising: categorizing the application based on the set of application-specific features; and obtaining a classifier model based on a category of the application.
categorizing the application based on the set of application-specific features; and
obtaining a classifier model based on a category of the application.
The method of claim 1 , wherein the set of application-specific features is generated by: extracting a set of features related to the application based on the lightweight binary analysis of the application; comparing the extracted set of features with a list of generic features; and removing any feature in the set of extracted features that matches a feature in the list of generic features to produce the set of application-specific features.
extracting a set of features related to the application based on the lightweight binary analysis of the application;
comparing the extracted set of features with a list of generic features; and
removing any feature in the set of extracted features that matches a feature in the list of generic features to produce the set of application-specific features.
The method of claim 1 , wherein categorizing the application based on the set of application-specific features comprises: classifying behaviors of the application with a generic classifier model; determining whether there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model based on the classified behaviors; deriving a set of features specific to the application based on a lightweight binary analysis of the application performed in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model; and categorizing the application based on the set of application-specific features derived from the lightweight binary analysis of the application performed in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model.
classifying behaviors of the application with a generic classifier model;
determining whether there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model based on the classified behaviors;
deriving a set of features specific to the application based on a lightweight binary analysis of the application performed in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model; and
categorizing the application based on the set of application-specific features derived from the lightweight binary analysis of the application performed in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the generic classifier model.
The method of claim 1 , wherein obtaining a classifier model based on the category of the application comprises: comparing the category of the application with a list of categories associated with previously generated classifier models; determining whether the category of the application matches a category included in the list of categories; obtaining a previously generated classifier model associated with a matching category included in the list of categories in response to determining that the category of the application matches the matching category; and obtaining a new classifier model based on the set of application-specific features in response to determining that the category of the application does not match a category in the list of categories.
comparing the category of the application with a list of categories associated with previously generated classifier models;
determining whether the category of the application matches a category included in the list of categories;
obtaining a previously generated classifier model associated with a matching category included in the list of categories in response to determining that the category of the application matches the matching category; and
obtaining a new classifier model based on the set of application-specific features in response to determining that the category of the application does not match a category in the list of categories.
The method of claim 1 , further comprising: observing behaviors of the set of application-specific features; generating a behavior vector for the application based on the observed behaviors; and applying the behavior vector to the classifier model to detect non-benign behavior on the mobile computing device related to the application.
observing behaviors of the set of application-specific features;
generating a behavior vector for the application based on the observed behaviors; and
applying the behavior vector to the classifier model to detect non-benign behavior on the mobile computing device related to the application.
The method of claim 5 , further comprising: identifying features related to the application that are occurring on the mobile computing device based on the observed behaviors; determining whether there is a non-trivial difference between the features related to the application that are occurring on the mobile computing device and the set of application-specific features included in the classifier model; and obtaining a different classifier model based on the features related to the application that are occurring on the mobile computing device in response to determining that there is a non-trivial difference between the features related to the application that are occurring on the mobile computing device and the set of application-specific features included in the classifier model.
identifying features related to the application that are occurring on the mobile computing device based on the observed behaviors;
determining whether there is a non-trivial difference between the features related to the application that are occurring on the mobile computing device and the set of application-specific features included in the classifier model; and
obtaining a different classifier model based on the features related to the application that are occurring on the mobile computing device in response to determining that there is a non-trivial difference between the features related to the application that are occurring on the mobile computing device and the set of application-specific features included in the classifier model.
The method of claim 5 , wherein: applying the behavior vector to the classifier model to detect non-benign behavior on the mobile computing device related to the application comprises applying the behavior vector to the classifier model to generate a behavior classification determination and a confidence value associated with the behavior classification determination; and the method further comprises: determining whether the confidence value associated with the behavior classification determination is less than a low-confidence threshold value; determining whether there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model in response to determining that the confidence value associated with the behavior classification determination is less than the low-confidence threshold value; obtaining a refined classifier model associated with the category of the application in response to determining that there is not a consistent history of behavior classification determinations with low-confidence values associated with the classifier model; and performing an analysis of the set of application-specific features to determine a new category for the application and obtaining another classifier model based on the new category of the application in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model.
applying the behavior vector to the classifier model to detect non-benign behavior on the mobile computing device related to the application comprises applying the behavior vector to the classifier model to generate a behavior classification determination and a confidence value associated with the behavior classification determination; and
the method further comprises: determining whether the confidence value associated with the behavior classification determination is less than a low-confidence threshold value; determining whether there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model in response to determining that the confidence value associated with the behavior classification determination is less than the low-confidence threshold value; obtaining a refined classifier model associated with the category of the application in response to determining that there is not a consistent history of behavior classification determinations with low-confidence values associated with the classifier model; and performing an analysis of the set of application-specific features to determine a new category for the application and obtaining another classifier model based on the new category of the application in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model.
determining whether the confidence value associated with the behavior classification determination is less than a low-confidence threshold value;
determining whether there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model in response to determining that the confidence value associated with the behavior classification determination is less than the low-confidence threshold value;
obtaining a refined classifier model associated with the category of the application in response to determining that there is not a consistent history of behavior classification determinations with low-confidence values associated with the classifier model; and
performing an analysis of the set of application-specific features to determine a new category for the application and obtaining another classifier model based on the new category of the application in response to determining that there is a consistent history of behavior classification determinations with low-confidence values associated with the classifier model.
A mobile computing device, comprising: a memory; and a processor coupled to the memory and configured with processor-executable instructions to perform operations comprising: categorizing an application based on a set of application-specific features; and obtaining a classifier model based on a category of the application.
a processor coupled to the memory and configured with processor-executable instructions to perform operations comprising: categorizing an application based on a set of application-specific features; and obtaining a classifier model based on a category of the application.
categorizing an application based on a set of application-specific features; and
The mobile computing device of claim 8 , wherein the processor is configured with processor-executable instructions to perform operations such that the set of application-specific features is generated by: extracting a set of features related to the application based on a lightweight binary analysis of the application; comparing the set of extracted features with a list of generic features; and removing any feature in the set of extracted features that matches a feature in the list of generic features to produce the set of application-specific features.
extracting a set of features related to the application based on a lightweight binary analysis of the application;
comparing the set of extracted features with a list of generic features; and
[Truncated to input limit]