Office Action 2: Final Rejection (2023-04-20)
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: SVG {EMBED HERE} 0.16 6
cloud application executing 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 correspondinq 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\. (Currently Amended) The method of claim \[\[3\]\] 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\. (Currently Amended) The method of claim \[\[4\]\] 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\. (Currently Amended) The method of claim \[\[5\]\] 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 \[\[7\]\] 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 a resource artifact ; and
comparing the resource artifact hash with at least one repository hash, wherein a repository hash is a low-file-size representation of an artifact included in a repository.

9\. (Currently Amended) The method of claim 8, further comprising:
determining an artifact status of the resource artifact, wherein the as artifact status of the resource artifact is a descriptor indicating a status of the at resource artifact; and
determining an artifact source of the resource artifact, wherein as 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\. (Currently Amended) 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 executinq amonqst 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 SVG {EMBED HERE} 0.16 6.49 .

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: SVG {EMBED HERE} 0.16 6
application executing 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 cvber threat embedded in the code based on a comparison of each identified mismatch with one or more data features usinq at least a SVG {EMBED HERE} 0.16 6.4

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

14\. (Currently Amended) 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\. (Currently Amended) The system of claim 4-4 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\. (Currently Amended) The system of claim 4-5 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\. (Currently Amended) The system of claim 46 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 a resource artifact ; and
compare the resource artifact hash with at least one repository hash, wherein a repository hash is a low-file-size representation of an artifact included in a repository.

20\. (Currently Amended) The system of claim 19, wherein the system is further configured to:
determine an artifact status of the resource artifact, wherein the as 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 as 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.
Page 2 of 13 Page 3 of 13 Page 4 of 13 Page 5 of 13 Page 6 of 13

OFFICE ACTION:
DETAILED ACTION
This final office action is in response to applicant’s amendments filed on 03/16/2023 for response of office action mailed on 11/16/2022. Claims 1, , 4-6, 8-12, 14-17, and 19-20 are currently amended. No claim is added and cancelled. Claims 1-21 are being examined and pending.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 .
Claim Objections
Claim 8 and 19 are objected because of following minor informality:
In line 6 of claim 8 and 19, examiner suggests to replace “a repository hash” “ with - - the at least one repository hash - -.
Response to Arguments
Applicant’s amendments to claims 1, 4, 8, 11, 12, 14, and 19, filed on 03/16/2023, with respect to claim objections have been fully considered. The amendments overcame the objections, therefore the claim objections have been withdrawn.
Applicant’s amendments to claims 1, 11 and 12, filed on 03/16/2023, with respect to claim rejections under 35 U.S.C 101 have been fully considered. Claim amendments integrate a practical application. The arguments regarding the mental process for generating hash is persuasive. Therefore the claim objections under 35 U.S.C 101 have been withdrawn.
Applicant’s amendments to claims 1, 9-12 and 20-21, filed on 03/16/2023, with respect to claim rejections under 35 U.S.C 112 indefinite have been fully considered. The amendments overcame the rejection. Therefore the claim rejections to claims 1-21 under 35 U.S.C 112 have been withdrawn.
Regarding arguments on claim 1 on page 9-11, claim 1 is amended with new limitation,  ing code of at least one cloud application executing amongst a plurality computing resources in a cloud environment;  Claim 11 and 12 although are different, amended with similar limitations. The applicant’s amendments to claim 1 necessitated the new grounds of rejection presented in this office action. Hence, applicant’s arguments with respect to rejections of claim 1, 11 and 12 along with dependent claims have been considered but are moot in view of the new grounds of rejection. New prior art is introduced and all claims in claim 1, 11 and 12 are remapped.
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-6, 11-13 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Moshitzky et al. (US20210266339, hereinafter Mos) in view of Zhang et al. (US11537400, hereinafter Zhang).
Regarding claim 1, 11, and 12, Mos teaches a method for detection of cyber threats embedded in cloud applications (Mos: a crawler configured to periodically crawl platform 134 and /or site 136 (both in cloud), look for new or updated applications and detect malware like spyware and key loggers; Para. 0027, 0029 and 0037), comprising: Detecting code of at least one cloud application executing amongst a plurality computing resources in a cloud environment (Mos: receive a new sample for analysis, wherein the new sample is received by crawling platform 134 or site 136, add new sample to processing queue, Para. 0049); performing a static analysis on the code to identify a mismatch (Mos: coordinator 304 fetches an application from the processing queue 302 for static analysis to identify a mismatch; Para. 0051, 0054 and 0056); 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 (Mos: static analysis engine forms a verdict for the application as malicious or suspicious when static feature is present in the application; Para. 0055 and 0056).
Yet, Mos does not explicitly teach filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application and 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.
However, in the same field of endeavor, Zhang teaches filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application (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) and 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 (Zhang: performing a static analysis,   comparing binary executable file information against source code repositories in version control system (which stores all discovered applications), and identify a mismatch; Col. 12, line 11-12, Col. 2, line 22-26, Col. 3, line 22-29, Col. 8, line 28-31, Col. 11, line 25-31).
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 for the at least one cloud application and 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 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 claim 2 and 13, combination of Mos and Zhang teaches the method of claim 1. In addition, Mos further teaches reporting each identified potential cyber threat (Mos: Para. 0053 and 0055).
Regarding claim 5 and 16, combination of Mos and Zhang teaches the method of claim 1.
In addition, Zhang 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 (Zhang: comparing hash signature representing the source code; Col. 3, line 22-29).
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 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 claim 6 and 17, combination of Mos and Zhang teaches the method of claim 1. In addition, Mos teaches wherein the code includes any one of: binary code, executable code, and high-level programming language code (Mos: Para. 0052).
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).
Regarding claim 3 and 14, combination of Mos 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 claim 4 and 15, combination of Mos 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).
Claim 7-9 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mos in view of Zhang, and further in view of Baierlein et al. (US20200371782, hereinafter Bai).
Regarding claim 7 and 18, combination of Mos and Zhang teaches the method of claim 1.
Yet, combination  does not teach wherein the code includes artifacts, and wherein the method further comprises scanning the artifacts for cyber threats.
However, in the same field of endeavor, 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 claim 8 and 19, combination of Mos and Zhang teaches the method of claim 1.
Yet, the combination does not teach 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 repository hash is a low-file-size representation of an artifact included in a repository.
However, in the same field of endeavor, Bai 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 a 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 a 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 claim 9 and 20, combination of Mos, Zhang and Bai 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).
Claim 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Mos in view of Zhang and Bai, and further in view of  Freitag et al. (US10691810, hereinafter Frei).
Regarding claim 10 and 21, combination of Mos, Zhang and Bai 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. §101 and 35 U.S.C. §112, claims 1, 4, 8, 11, 12, 14, and 19 are objected to, claims 1-3 and 11-14 stand rejected under 35 U.S.C. §102 and claims 4-10 and 15-21 stand rejected under 35 U.S.C. §103.
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. The amendments to the already pending claims have been made for reasons of form and not to avoid prior art. No new matter has been added.
Obi
ection to Claims
Claims 1, 4, 8, 11, 12, 14, 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. Withdrawal of these objections is respectfully requested.
Rei
ection of Claims Under 35 U.S.C.
112(b)
Claims 1-21 stand rejected under 35 U.S.C. §112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
This ground of rejection is respectfully avoided. Essentially all of these rejections relate to improper introduction or antecedent basis for various elements or lack of clarity. Applicants have amended each of the rejected claims in an attempt to correct the inadvertent failures except for claims 10 and 21 which become correct due to the amendments to the claims on which they depend.
Withdrawal of this ground of rejection is respectfully requested.
Rei
ections of Claims Under 35 U.S.C.
Claims 1-21 stand rejected under 35 U.S.C. §101 as allegedly being directed to a non-statutory subject matter pursuant to the holding in Alice Corp. Pty. Ltd. v. CLS Bank
Int'l, 134 S. Ct. 2347 (2014) (hereinafter "Alice"). The two-step analysis prescribed by Alice requires (1) a determination of whether the claims are directed to an abstract idea (Alice step one), and (2) whether any element or combination of elements in the claims are sufficient to ensure that the claims amount to significantly more than the abstract idea itself (Alice step two). The Office Action decides that the claims are directed to an abstract idea and do not contain additional elements that are sufficient to amount to significantly more than the abstract idea. However, the Office Action's analysis is flawed and so Applicants respectfully traverse this ground of rejection for the following reasons.
The claims are rejected as reciting a mental process. However, regarding a mental process, the October 2019 PEG update explains that:
Claims do not recite a mental process when they do not contain limitations that can practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitations.
The human mind is
not
capable of practically performing the claimed method in toto given that, as explain in paragraph 7 of the instant specification, the code that is recited in the claim is for cloud applications and it practically relies on dozens to thousands of software packages and different versions thereof. Furthermore, each package typically contains thousands if not millions of code lines. As such, the method of the claim simply cannot be performed practically in the human mind.
Not only is the claim in toto
not
practically performable in the human mind, but it should also be appreciated that the filtering to remove a portion of the code that is non-unique for the at least one cloud application, given the large amount of code lines, is itself enough to take the claim out of the realm of being practically performed in the human mind.
Claim 5 is also eligible on its own merits. The human mind cannot practically generate the hash values of the various portions of the code in a timely manner suitable for use in cloud application development.
Claim 6 is also eligible on its own merits. It is very difficult for human to be able to find unique and non-unique code portions in high-level programming code not only due to the vast number of lines of code but also because many of them would
not
be
seen by a human because they are in code packages that would simply be invoked by a routine the human would see. Moreover, a human would
not
be able to perform the method on binary code or executable code which is much harder to understand and would be even more lines. Indeed, beyond the fact that very few people can even read and follow what is happening in binary or executable code, to perform the claim elements on such code would be practically impossible for a person even if there was a smaller amount of code.
Thus, the claim does
not
recite a mental process because the steps are
not practically
performed in the mind.
Accordingly, Applicants respectfully submit that all of the pending claims constitute patentable subject matter and request that the rejection of all claims under 35 U.S.C. §101 be withdrawn.
Rej
ection of Claims Under 35 U.S.C.
Claims 1-3 and 11-14 stand rejected under 35 U.S.C. §102 as being anticipated by U.S. Patent Publication No. 20150356451 of Gupta et al. (hereinafter "Gupta"). Applicants respectfully disagree and traverse avoid this ground of rejection for the following reasons.
Independent Claim 1 Independent claim 1 recites (emphasis added):
A method for detection of cyber threats embedded in
cloud applications
, comprising:
detecting code of at least
one cloud application
executing amongst a plurality
com
p
utin
q
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.
First, Gupta does
not
teach or suggest the detection of cyber threats embedded in
cloud applications
. Rather, Gupta is directed to detecting non-benign software in
local devices,
not cloud applications
. Even when Gupta detects malicious economic activity, e.g., sending unauthorized premium SMS message, use of the phone for denial of service (DoS), malicious software, malware, viruses, operations relating to commandeering the mobile device or utilizing the phone for spying or botnet activities, such are implemented in software that is run locally on the phone and is
not
part of any
cloud application
. As such, this is
not
teaching or suggesting what is called for in the
claim.
Second, there is
no
teaching or suggestion in Gupta of anything akin to detecting code of at least
one cloud application
executing amongst a plurality
computin
g
resources in a cloud environment
as called for in the claim. The downloaded application code from an app store that is to be run on the mobile computing device that is mentioned in paragraph 95 is
not
code that is executing amongst a plurality
computin
q
resources in a cloud environment
as called for in the claim. Analyzing such a downloadable/downloaded file is
not
what is called for by the detecting step because, again, such is
not
the code recited in the detecting step.
Third, the removal by Gupta of generic features from extracted features to produce a set of application-specific features is
not
the same as filtering to remove code that is non-unique which is what is called for in the claim. What is done in Gupta produces a set of features that is specifically related to the application, i.e., a set of application-specific features. This set of application-specific features may be used to determine a category of the application and/or to obtain a classifier model suitable for monitoring the application's behaviors and may include features that are not generic to many different applications. However, there is
no
teaching or suggestion in Gupta that the code itself that is removed is non-unique as called for in the claim. In Gupta, the code removed is feature based, e.g., generic features, as opposed to what is left, which is an application-specific. This is different from unique and nonunique code of the
claim.
Given that Gupta does
not
teach or suggest the unique and non-unique code of the claim, it cannot teach or suggest 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.
Furthermore, the lightweight binary analysis performed by Gupta performs a different type of analysis than is called for in the claim. As explained in paragraph 103 (emphasis added):
In some aspects, the lightweight binary analysis may include a static analysis of the binary file before the application is installed to identify various characteristics of the binary file, including the APIs, methods, function calls, etc. utilized in the binary file, as well as the hardware and/or other components of the mobile computing device likely to interact with the application during runtime.
In essence, by performing the li
g
htwei
ght
binary analysis, the processor executin
q
the li
q
htwei
q
ht binary analyzer may identify the capabilities of the application or other information that may indicate the expected behavior of the application
.
In other words, the purpose is to determine the capabilities of the application or other information that may indicate the expected behavior of the application. This is
not
to identify a mismatch between any unique portion of the code and its corresponding verified version stored in a code repository which is what must be performed by the static analysis of the claim. Furthermore, the analysis in Gupta is based on
features
, not on code, and specifically,
not
on each unique portion of the code. There is also
no
teaching or suggestion in Gupta of a verified version stored in a code repository as required by the claim.
As to the detecting step, again, the claim calls for 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. However, Gupta does
not
teach any code mismatches
nor
any vulnerability tool as called for in the claim. Furthermore, the behavior vector of Gupta appears to be developed by observing behaviors of the set of application-specific features, i.e., actual execution of such features, and generating the behavior vector for the application based on the observed behaviors. This is very
different
from the claim, which only requires the code itself and
not
execution of the code.
In view of the foregoing, Gupta does
not
appear to teach any of the elements of Applicants' claim 1. As such Gupta also cannot teach any of Applicants' dependent claims which depend from claim 1.
Thus, Applicants' claim 1, and claims 2 and 3 which depend thereon, are allowable over Gupta under 35 U.S.C. §102. 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 claim 14 which depends from claim 12, are likewise allowable.
Withdrawal of these rejections is respectfully requested.
Rei
ections of Claims Under 35 U.S.C.
Claim 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Vaishnavi (US20200272670, hereinafter Vai).
Claims 5-6 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Vai, and further in view of Kavi (US20180176262).
Claims 7-9 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Baierlein et al. (US20200371782, hereinafter Bai).
Claims 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of 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 rejection under 35 U.S.C. §102 in view of Gupta, these claims are allowable at least for the same reasons given hereinabove with regard Gupta as none of the additional references are cited as curing the above-described deficiencies of Gupta.
Accordingly, Applicant respectfully requests withdrawal of all of these rejections.
CONCLUSION

NEXT 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.

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]