Office Action 1: Non-Final Rejection (2022-11-16)
Rejection types: 101 - Patent-Eligible Subject Matter, 102 - Lack of Novelty, 103 - Obviousness, 112 - Written Description/Enablement

CLAIMS:
CLAIMS

What is claimed is:

1\. A method for detection of cyber threats embedded in cloud applications, comprising:
inspecting a plurality of computing resources to detect code of at least one cloud application executed 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 static analysis on the unique portion of the code to identify a mismatch between the unique portions of the code and its verified version stored in a code repository; and
comparing each identified mismatch with at least a vulnerability tool, wherein a mismatch is a potential cyber threat embedded in the code.

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

3\. 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\. The method of claim 3, wherein the non-unique portion includes at least: an operating system (OS) package data feature, and a third-party code library data feature.

5\. The method of claim 4, 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\. The method of claim 5, wherein the code includes any one of: binary code, executable code, and high-level programming language code.

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

8\. The method of claim 7, further comprising:
creating a resource artifact hash, wherein the resource artifact hash is a low-file- size representation of a resource artifact included in the code; and
comparing the resource artifact hash with the repository hash, wherein a repository hash is a low-file-size representation of an artifact included in a repository.

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

10\. The method of claim 9, further comprising:
determining if the resource artifact contains vulnerabilities based on the artifact status and the artifact source.

11\. 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:
inspecting a plurality of computing resources to detect code of at least one cloud application executed 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 static analysis on the unique portion of the code to identify a mismatch between the unique portions of the code and its verified version stored in a code repository; and
comparing each identified mismatch with at least a vulnerability tool, wherein a mismatch is a potential cyber threat embedded in the code.

12\. 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:
inspect a plurality of computing resources to detect code of at least one cloud application executed 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 static analysis on the unique portion of the code to identify a mismatch between the unique portions of the code and its verified version stored in a code repository; and
compare each identified mismatch with at least a vulnerability tool, wherein a mismatch is a potential cyber threat embedded in the code.

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

14\. The system of claim 1, 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\. The system of claim 14, wherein the non-unique portion includes at least: an operating system (OS) package data feature, and a third-party code library data feature.

16\. The system of claim 15, 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\. The system of claim 16, wherein the code includes any one of: binary code, executable code, and high-level programming language code.

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

19\. The system of claim 18, wherein the system is further configured to:
create a resource artifact hash, wherein the resource artifact hash is a low-file-size representation of a resource artifact included in the code; and
compare the resource artifact hash with the repository hash, wherein a repository hash is a low-file-size representation of an artifact included in a repository.

20\. The system of claim 19, wherein the system is further configured to:
determine an artifact status of the resource artifact, wherein an artifact status of the at least a resource artifact is a descriptor indicating the status of the at least a resource artifact; and
determine an artifact source of the at least a resource artifact, wherein an artifact source is at least a software package version, wherein the at least a software package version, when executed, generates the at least a resource artifact.

21\. 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 18 of 27 Page 19 of 27 Page 20 of 27 Page 21 of 27

OFFICE ACTION:
DETAILED ACTION
This non-final office action is in response to claims 1-21 filed on 02/01/2021 for examination. 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 .
Information Disclosure Statement
No information disclosure statement (IDS) is submitted.
Drawings
The drawings filed on 02/01/2021 have been accepted.
Claim Objections
Claim 1, 4, 8, 11, 12, 14, and 19 are objected because of following minor informality:
In line 8 of claim 1, examiner suggests to replace “ the unique portions “ with - - the unique portion - -. Same applies to claim 11 and 12.
In line 1 of claim 4, examiner suggests to replace “at least” with - - at least one of - -.
In line 4 of claim 8 and 19, examiner suggests to replace “ the repository hash” with - - a repository hash - - and replace “a repository hash” with - - the repository hash - -.
In line 1 of claim 14, examiner suggests to replace “the system of claim 1” with - - the system of claim 12 - -.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b)  CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA  the applicant regards as the invention
Regarding claim 1, 11 and 12, they recite “ the unique portion” in line 7. There is lack of antecedent for “the unique portion” because there is no “unique portion” recited prior. Therefore it’s not clear which unique portion that “the unique portion” refer to.
Regarding claim 9 and 20, they both recite “ the at least a resource artifact” multiple times. There is lack of antecedent for “the at least a resource artifact” because there is no “at least a resource artifact” recited prior. Therefore it’s not clear which resource artifact that “the at least a resource artifact” refer to.
Regarding claim 10 and 21, they both recite “the artifact source” in line 2. There is lack of antecedent for “the artifact source” because there are two “an artifact source” recited prior. Therefore it’s not clear which artifact source that “the artifact source” refer to.
Dependent claims 2-8 and 13-19 are rejected with same deficiencies.
Regarding claim 9 and 20, the scope of “when executed, generates the at least a resource artifact” is not clear. The claim 9 and 20 recites determining an artifact source of the at least a resource artifact, wherein an artifact source is at least a software package version, wherein the at least a software package version, therefore it’s not clear how to execute a software package version to generate a resource artifact.
Claim Rejections - 35 USC § 101 (Abstract Idea)
35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Amended claims 1-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more analyzed according to 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”). The claim recites a method for storing data using bidirectional linked blockchain.
Regarding independent claims 1, 11 and 12,
Step 1: The claims 1, 11 and 12 do fall into one of the four statutory categories of method and system. Nevertheless the claims 1, 11 and 12 still are considered as abstract idea for the following prongs and reasons.
Step 2A: Prong 1: The limitation of claims 1, 11 and 12 recite: inspecting a plurality of computing resources to detect code……; filtering the detected code to remove a portion of the code….; performing static analysis on the unique portion of the code…..; and comparing each identified mismatch……, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind and / or with pen and paper, there is nothing in the claim element precludes the step from practically being performed in the mind and with pen and paper. For example, inspecting device to detect code, filtering the detected code, perform static analysis and comparing …with mismatch…... Thus, the claims 1, 11 and 12 recite a mental process.
Prong 2: This judicial exception is not integrated into a practical application. In particular, the claims do not recite any additional element to perform beyond inspecting, filtering and comparing. The combination of those steps are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore the claims 1, 11 and 12 are directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, recited claims amount to no more than mere instructions to apply the exception using a generic computer terms. Mere instructions to apply an exception using a generic computer components cannot provide an inventive concept. The claim 1, 11 and 12 are not patent eligible. Therefore all claims 1, 11 and 12 are rejected under 35 USC 101 (abstract idea)
The dependent claims 2-10 and 13-21 have also been fully analyzed. Each of these dependent claims are mere recites additional abstract idea or an insignificant, extra-solution activity. Therefore, the dependent claims also fail to integrate the abstract idea into a practical application. Moreover, the claims have also been analyzed regarding whether they recite significantly more than the abstract idea. The dependent claims fail to add significantly more than the abstract idea. Therefore all claims 2-10 and 13-21 are rejected under 35 USC 101 (abstract idea)
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claim 1-3 and 11-14  are rejected under 35 U.S.C. 102(a)(1) as being anticipated by  Gupta et al. US20150356451, hereinafter Gupta).
Regarding claim 1, 11, and 12, Gupta teaches a method for detection of cyber threats embedded in cloud applications (Gupta: a system/method to quickly and efficiently identify software-application behaviors that are not benign; Fig. 3, cloud 118, cloud unit 302; Para. 0013 and 0028), comprising inspecting a plurality of computing resources to detect code of at least one cloud application executed in a cloud environment (Gupta: upon receiving the application binary file from an app store (on the cloud), perform binary analysis on method calls, functions to identify features/characteristics/artifact of the application; Para. 0095, 0103); filtering the detected code to remove a portion of the code that is non-unique for the at least one cloud application (Gupta: remove generic features from extracted features to produce a set of application-specific features; Fig. 5, S502 and S506, Para. 0096-0097 and 0124); performing static analysis on the unique portion of the code to identify a mismatch between the unique portions of the code and its verified version stored in a code repository (Gupta: the lightweight binary analysis includes a static analysis of the binary file, derive features specific to the application based on the analysis, generate a behavior vector for the application based on the observed behaviors, apply the generated behavior vector to the classifier model ; Fig. 4, S404, S412, Fig. 9, S906 and S908; Para. 0103, 0124 and 0117); and comparing each identified mismatch with at least a vulnerability tool, wherein a mismatch is a potential cyber threat embedded in the code (Gupta: the classifier unit 208 receives the behavior vector and compares with the classifier model to determine whether the application (related to online credit card transaction) is not benign; Fig. 4: S416; Para. 0075 and 0119).
Regarding claim 2 and 13, Gupta teaches the method of claim 1. In addition, Gupta further teaches reporting each identified potential cyber threat (Gupta: Para. 0076-0077).
Regarding claim 3 and 14, Gupta teaches the method of claim 1. In addition, Gupta further teaches comparing the non-unique code portions to a vulnerability database to determine if the non-unique portion of the code contains known vulnerabilities (Gupta: Para. 0189).
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.
Claim 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Vaishnavi (US20200272670, hereinafter Vai).
Regarding claim 4 and 15, Gupta teaches the method of claim 3.
Yet, Gupta does not teach wherein the non-unique portion includes at least: an operating system (OS) package data feature, and a third-party code library data feature
However, in the same field of endeavor, Vai teaches wherein the non-unique portion includes at least: an operating system (OS) package data feature, and a third-party code library data feature (Vai: Para. 0076 and 0111).
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 Gupta to include wherein the non-unique portion includes at least: an operating system (OS) package data feature, and a third-party code library data feature as disclosed by Vai. One of ordinary skill in the art would have been motivated to make this modification in order to identify shared/common libraries across cloud services as suggested by Vai (Vai: Para. 0076).
Claim 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).
Regarding claim 5 and 16, combination of Gupta and Vai teaches the method of claim 4.
Yet, the combination does not 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
However, in the same field of endeavor, Kavi teaches 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 (Kavi: Para. 0040).
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 Kavi. One of ordinary skill in the art would have been motivated to make this modification in order to prevent corruption of source code as suggested by Kavi (Kavi: Para. 0040).
Regarding claim 6 and 17, combination of Gupta, Vai and Kavi teaches the method of claim 5. In addition, Gupta teaches wherein the code includes any one of: binary code, executable code, and high-level programming language code (Gupta: binary, Para. 0095).
Claim 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).
Regarding claim 7 and 18, Gupta teaches the method of claim 1.
Yet, Gupta 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. 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 Gupta 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, Gupta teaches the method of claim 1.
Yet, Gupta does not teach creating a resource artifact hash, wherein the resource artifact hash is a low-file- size representation of a resource artifact included in the code; and comparing the resource artifact hash with the 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, wherein the resource artifact hash is a low-file- size representation of a resource artifact included in the code (Bai: Para. 0061, 0084); and comparing the resource artifact hash with the 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 Gupta to include creating a resource artifact hash, wherein the resource artifact hash is a low-file- size representation of a resource artifact included in the code; and comparing the resource artifact hash with the 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, Gupta teaches the method of claim 1.
Yet, Gupta does not teach determining an artifact status of the resource artifact, wherein an artifact status of the at least a resource artifact is a descriptor indicating the status of the at least a resource artifact; and determining an artifact source of the at least a resource artifact, wherein an artifact source is at least a software package version, wherein the at least a software package version, when executed, generates the at least a resource artifact.
However, in the same field of endeavor, Bai teaches determining an artifact status of the resource artifact, wherein an artifact status of the at least a resource artifact is a descriptor indicating the status of the at least a resource artifact (Bai: Para. 0026); and determining an artifact source of the at least a resource artifact, wherein an artifact source is at least a software package version, wherein the at least a software package version, when executed, generates the at least a 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 Gupta to include determining an artifact status of the resource artifact, wherein an artifact status of the at least a resource artifact is a descriptor indicating the status of the at least a resource artifact; and determining an artifact source of the at least a resource artifact, wherein an artifact source is at least a software package version, wherein the at least a software package version, when executed, generates the at least a 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 Gupta in view of Bai, and further in view of  Freitag et al. (US10691810, hereinafter Frei).
Regarding claim 10 and 21, combination of Gupta 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 vulnerabilities based on the artifact status and the artifact source.
However, in the same field of endeavor, Frei teaches determining if the resource artifact contains vulnerabilities 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 vulnerabilities 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 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.

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]