DETAILED ACTION
Notice of Pre-AIA or AIA Status
This Office Action is in response to the application filed on 01/17/2025 having claims 1-14 pending.
Claims 1-14 are examined and being considered on the merits.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Oath/Declaration
The applicant’s oath/declaration has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. KR 1020240031276, filed on 03/05/2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/17/2025 and 01/15/2026 were filed after the mailing date. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The amended Specification filed on 01/17/2025 are accepted for examination purpose.
Drawings
The Drawings filed on 01/17/2025 are accepted for examination purpose.
Claim Objections
Claims 1 and 14 are objected to because of the claims recite “ … receiving an execution record in which content of code executed by the application is converted into a string format from the device …”. Specifically, the phrase “content of code executed by the application is converted into a string format” is confusing as it is unclear how the claimed content of code is executed by the application, which itself contains the code and is to be executed. In addition, it is unclear whether the claimed code content or application is converted into string format. Appropriate correction is required.
Claims 5 and 18 are objected to because of the acronym, ”API”, recited in these claims is not specified in its full name when first introduced. Appropriate correction is required.
Claims 7 and 20 are objected to because of the following informalities: Claims recite, “… a language setting, a GPS setting, a communication service provider setting, Android OS build information, an IP address, SIM card information …“. Yet, acronyms, such as “GPS”, “IP”, “OS” and “SIM”, in these claims are not specified in their full names when first introduced. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: execution control module for performing, execution record reception module for receiving and execution evaluation module for searching in independent claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. In the specification, at Parag. [0012]; “an apparatus for automatically removing anti-dynamic analysis code from an Android application according to an embodiment of the present disclosure includes an execution control module for performing control to install and execute an application in multiple devices based on an APK file, an execution record reception module for receiving an execution record in which the content of code executed by the application is converted into a string format from the device, and an execution evaluation instrumentation module for searching for a branch point of anti-dynamic analysis code based on the execution record in a string format.”
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention. Claim limitations “execution control module for performing”, “execution record reception module for receiving” and “execution evaluation module for searching” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Review of the specification does not show any corresponding structural support or description for the recited “execution control module for performing”, “execution record reception module for receiving” and “execution evaluation module for searching”. At best, parag. [0012] of the Specification describes “an apparatus for automatically removing anti-dynamic analysis code from an Android application according to an embodiment of the present disclosure includes an execution control module for performing control to install and execute an application in multiple devices based on an APK file, an execution record reception module for receiving an execution record in which the content of code executed by the application is converted into a string format from the device, and an execution evaluation instrumentation module for searching for a branch point of anti-dynamic analysis code based on the execution record in a string format.” In addition, parags. [0133]-[0134] disclose “the apparatus for automatically removing anti-dynamic analysis code from an Android application according to an embodiment may be implemented in a computer system 1000 including a computer-readable recording medium. The computer system 1000 may include one or more processors 1010, memory 1030, a user-interface input device 1040, a user-interface output device 1050, and storage 1060, which communicate with each other via a bus 1020. Also, the computer system 1000 may further include a network interface 1070 connected with a network 1080. The processor 1010 may be a central processing unit or a semiconductor device for executing a program or processing instructions stored in the memory 1030 or the storage 1060. The memory 1030 and the storage 1060 may be storage media including at least one of a volatile medium, a nonvolatile medium, a detachable medium, a non-detachable medium, a communication medium, or an information delivery medium, or a combination thereof. For example, the memory 1030 may include ROM 1031 or RAM 1032.”. Yet, none of the paragraphs/sections in the Specification of the instant application provide sufficient description for the corresponding structure or material of the recited “execution control module”, “execution record reception module for receiving” and “execution evaluation module”. Therefore, the claim is indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 2-12 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph due to their dependency to the independent claim 1.
Claims 1 and 7 (similar for claims 14 and 20) contain a trademark/trade name for the recitation, “Android”, Claims 2 and 15 contain a trademark/trade name for the recitation, “Java”, and Claims 11 and 12 contain a trademark/trade name for the recitation, “Dalvik”. The Applicant is reminded that when a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe material and/or product and, accordingly, the identification/description is indefinite.
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.
Claims 1 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot.
As per Claim 1, YI teaches an apparatus for automatically removing anti-dynamic analysis code from an Android application (YI, Parag. [0001]; “… technology that disables anti analysis techniques by instrumenting the native code of an OAT file used in ART (i.e., Android runtime) at the instruction level through process wrapping.” … Parag. [0077]; “The instrumentation tool automatically disables anti-analysis techniques based on the database generated during pre-processing and runs the application by the disabled result.”), comprising:
an execution control module for performing control to install and execute an application in multiple devices based on an Android Package Kit (APK) file (YI, Parag. [0069]; “The symbol extractor 130 extracts the OAT file of the installed target application using the oatdump tool present in the Android framework. The extracted information includes information about all the compiled Dex files. The oatdump dumps information of class in each Dex file and method inside the class, and the symbol extractor extracts only information about string and method based on the dumped information”. Parag. [0070]; “the code intended to run in the application is transferred to the execution code monitor 110 at the start of the application. The execution code monitor 110 interprets the transferred execution code, converts to the human-readable level and transfers to the anti-analysis recognizer 150 ….”. Parag. [0081]; “Referring to FIG. 2, when the application is installed using APK as input, there are an OAT file produced by compiling DEX of APK and dynamic shared libraries used in the OAT file. The OAT file contains mapping of the compiled native execution code and information of all symbols used in the corresponding code, and metadata of method and string is extracted using the OAT file according to the present disclosure.”);
[an execution record reception module for receiving an execution record] in which content of code executed by the application is converted into a string format from the device (YI, Parag. [0069]; “… The extracted information includes information about all the compiled Dex files. The oatdump dumps information of class in each Dex file and method inside the class, and the symbol extractor extracts only information about string and method based on the dumped information.” … Fig. 8 and Parag. [0126]; “FIG. 8 shows the structure of the compiled string used in OAT. This entry indicates a result value of executing the method of ART to find string ….” Parag. [0127]; “… In Android, string is managed as Unicode, not ASCII, so each character is 2 bytes, and when finding the address, offset is multiplied by 2 and added to the reference address.”); and
an execution evaluation instrumentation module for searching for a branch point of anti-dynamic analysis code based on [the execution record] in a string format (YI, Parag. [0106]; “An instrumentator module 500 plays a role in monitoring and controlling the flow of the program by instrumenting the actual code and if necessary, modifying or deleting. In this instance, the metadata created by pre-processing is used and the instrumented result is extracted in the log format.” … Parag. [0114]; “The instrumentator module 500 is a module that instruments the actual code of the app_process and the application and manages the execution flow of the program. The instrumentator module 500 is divided into 3 modules, a monitor module 510, a modifier module 530 and a logger module 550, on the basis of operation.” Parag. [0115]: “The monitor module 510 includes a code monitor module 511 and an anti-analysis recognizer module 513, and the code monitor module 511 is implemented using the VEX module of Valgrind. The code monitor module 511 performs a task of translating the native code compiled to be executed into IR and IRs are managed by the unit of Basic Block (BB).” … Parag. [0122]; “A Basic Block (BB) is based on branch, and one or more BBs form one method. In conditional statement such as iterative statement …” … Parag. [0124]; “ …. Information about the string to be used in the application and the method name to call reveals which method is being executed and which string is being used through the previously created metadata.” .… Fig. 3, element 500 and Parags. [0127]-[0128]; “… In Android, string is managed as Unicode, not ASCII, so each character is 2 bytes, and when finding the address, offset is multiplied by 2 and added to the reference address. The found result points to the actual string, and the string may be identified by reading as much as the string length stored in 12-15 bytes of string entry. The modifier module 530 is a module which inserts IR that bypasses the anti-analysis technique detected by the monitor module 510.” … Parag. [0130]; “FIG. 9 shows the translation of [cbz] instruction into IR as an example of IR modification through constant value change. The [cbz] instruction is an instruction which determines the branch by comparing with 0, and in this instance, the execution is changed by changing the value of 0 to 1.”).
YI does not expressly teach:
an execution record; and
an execution record reception module for receiving an execution record ….
However, Gagnerot teaches:
… to install and execute an application in multiple devices based on an Android Package Kit (APK) file (Gagnerot, Parag. [0013]; “Applications such as Android applications are distributed using a file called Android™ Package kit (APK) comprising code and data that the application needs to be installed in relation to an Android operating system and to properly operate);
an execution record and an execution record reception module for receiving an execution record … (Gagnerot, Parag. [0013]; “an additional Android manifest file including the name, version, access rights, and library files referenced for the application; this file is in Android binary XML that can be converted into human-readable plain text XML with dedicated tools such as AXMLPrinter2, APKTOOL, or Androguard.” … Parag. [0016]; “Each APK file has one or more program files “classes.dex”, “classesN.dex”, which contain the entire program Java code. For portability reasons, programs for Android devices are commonly written in Java and compiled to bytecode (which is contained in program.class files). The compiled bytecode is then converted from Java Virtual machine-compatible.class files to the Dalvik-compatible.dex (Dalvik Executable) file in order to enable installation on a computing device. The Java bytecode in the .class files has a binary format and represents the instructions that can be executed by a Dalvik virtual machine.” Parag. [0017]; “An APK file can be disassembled using a reverse engineering tool such as APKTOOL which produces bytecode program files called “classes” and data files arranged in directories and sub-directories called “packages” … Parag. [0025]; “According to an embodiment, the method further comprises: extracting program code files from the executable application file; and converting the program code files …..” … Parag. [0030]; “According to an embodiment, the syntactical metrics are applied to character strings of the program text files and comprise at least one of … with respect to the total number of character strings, ratio of a number of character strings having at least one Unicode character, with respect to the total number of character strings”).
YI and Gagnerot are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gagnerot system into YI system, with a motivation to provide dedicated tools, such as AXMLPrinter2, APKTOOL, or Androguard for producing bytecode program files with the corresponding syntactical metrics applied to character strings of the program file (Gagnerot, Parag. [0013], [0017] and [0030]) for ease of code analysis.
As per claim 14, it is a method claim that recites similar features as presented on independent claim 1. Therefore, claim 14 is rejected using the same rationale applied to independent claim 1.
Claims 2-5 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot, as applied to claim 1, and further in view of Jiman, et al. (KR 10-2416292-included on IDS) hereinafter Jiman and Toper (US 2021/0303283).
As per claim 2, the combination of YI and Gagnerot teaches the apparatus of claim 1, wherein the execution record reception module receives information about a function call, reflection, a Java Native Interface (JNI) function call, a branch, and a function return occurring in a process of installing and executing the application in the device in a preset string format.
The combination of YI and Gagnerot does not expressly teach:
receives information about a function call, reflection, a Java Native Interface (JNI) function call, a branch, and a function return occurring in a process of installing and executing the application in the device in a preset string format.
However, Jiman teaches:
receives information about a function call, [reflection], a Java Native Interface (JNI) function call, a branch, and a function return occurring in a process of installing and executing the application in the device in a preset string format (Jiman Page 3, Parag. 6; “Android app dynamic analysis method according to an embodiment for realizing the object of the present invention, extracting Java (java) function call information and code block information from a compressed file through dynamic analysis of the Android app step; extracting the native library call information based on the function information executed when the native library of the Android app is called; recording the extracted Java function call information, code block information, and native library call information in a log; and providing only the Android app information for dynamic analysis by removing the Android app information executed in the background task from the recorded log.” … Page 3, Parag. 9; “Android app dynamic analysis device according to an embodiment for realizing another object of the present invention, Java (java) function call information and code block information from a compressed file through dynamic analysis of the Android app a first call information extracting unit to extract; a second call information extraction unit for extracting native library call information based on function information executed when a native library of the Android app is called; a log recording unit for recording the extracted Java function call information, code block information, and native library call information in a log; and a comparative analysis unit that removes information about an Android app executed in a background task from the recorded log and provides only information on an Android app for dynamic analysis.” … Page 8, Parag. 7; “JNI implemented in AOSP provides functions that allow Android apps to use native functions defined in native libraries. When a function provided by JNI is called, the JNIEnv object maps the native function to the Java program. By monitoring the mapping information of JNIEnv, you can extract the native library call information.” … Page 10, Parag. 3; “In addition, the apparatus 10 of the present invention provides a new function of extracting code block information as shown in FIG. 9 . This function is implemented based on the fact that the BRANCH_INSTRUMENTATION() macro is always called when the IF, SWITCH, GOTO Dalvik bytecode instruction is executed and the RETURN_INSTRUMENTATION() macro is always called when the RETURN Dalvik bytecode instruction is executed.”)
YI, Gagnerot and Jiman are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jiman system into YI-Gagnerot system, with a motivation to providing a plurality of call functions available when executing an application for detecting suspected behaviors (Jiman Page 3, Parag. 6).
The combination of YI, Gagnerot and Jiman does not expressly teach:
receives information about …, reflection
However, Toper teaches:
receives information about …, reflection (Toper, Parag. [0004]; “One example is the use of reflection instructions in Java. Reflection instructions are dynamic instructions defined in an API which is used to examine or modify the behavior of methods, classes, and interfaces at runtime. Reflection gives information about the class to which an object belongs, as well as the methods of that class which can be executed by using the object. Through reflection, methods can be invoked at runtime as long as the name and parameter types of the method are known. This allows the program to be built at runtime.”).
YI, Gagnerot, Jiman and Toper are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Toper system into YI-Gagnerot-Jiman system, with a motivation to providing a plurality of call functions available when executing an application for detecting suspected behaviors in specific a reflection function (Toper, Parag. [0004]).
As per claim 3, the combination of YI, Gagnerot, Jiman and Toper teaches the apparatus of claim 2. YI teaches the preset string format (YI, Parag. [0126]; “FIG. 8 shows the structure of the compiled string used in OAT…. when Java/lang/String is returned. One entry is 24 bytes and 8-11 bytes indicate the reference address of string). Jiman further teaches wherein the preset string format includes a type of an instruction and source and destination addresses of the instruction (Jiman, Page 9, Parag. 5; “Android 8.1 has 242 Dalvik bytecodes. Each instruction of the Dalvik byte code is composed of an opcode that indicates the operation of the instruction and performs various functions such as exception handling, execution flow, and array manipulation. Among them, there are a total of 38 instructions for changing the execution flow of the Android app, and are classified into 5 types as shown in FIG. 3 . The device 10 analyzes the flow of the Android app by monitoring which instruction changes the execution flow of the Android app.” … Page 10, Parag. 1; “Referring to FIG. 8, not only the function name defined in Java, but also the address value of the current execution position (i.e., source address) and the address value of the execution position to be branched (i.e., destination address) are extracted and recorded in the log. The reason for extracting the address values of the current execution position and the execution position to be branched is that the same function name declared in another class can be distinguished by the address value.”).
As per claim 4, the combination of YI, Gagnerot, Jiman and Toper teaches the apparatus of claim 2. Toper teaches wherein the execution record includes final destination information of the reflection (Toper, Parag. [0054]; “Reflection calling reflection is performed where a dynamic instruction depends on one other dynamic instruction. In some embodiments, the first dynamic instruction is resolved, generating a new binary and then a second dynamic instruction, up to n instructions. Through reflection, methods can be invoked at runtime as long as the name and parameter types of the method are known (i.e., call is made to invoke the method (destination information) having the particular name). In some embodiments a threshold is defined, breaking infinite recursive cycles ...” … Parag. [0060]; “At step 202, the system receives a computer program consisting of code in a dynamic language. In some embodiments, a client device 120 sends a computer program in code form to one or more devices or systems configured to receive the computer program. In some embodiments, a user selects the computer program based on a prompt or request for the computer program within a user interface of the client device. Upon selecting the program, the computer program is sent to the optimization engine 102, which may be part of the client device 120 or part of some other device or system. In some embodiments, the computer program consists of code in a dynamic language, such as Python or any other suitable dynamic language. For example, “reflection” is a dynamic language feature within Java. The Java Reflection Application Programming Interface (API) allows programmers to dynamically inspect and interact with otherwise static language concepts such as classes, fields and methods, in order to, e.g., dynamically instantiate objects, set fields, invoke methods, and perform other suitable tasks within programming languages. In some examples, therefore, a user may choose an option to send a Java program containing dynamic reflection instructions to one or more elements of the system via a user interface on a client device. In some embodiments, upon the system receiving the program, a verification step is performed in order to verify that the program submitted contains one or more dynamic instructions.”).
As per claim 5, the combination of YI, Gagnerot, Jiman and Toper teaches the apparatus of claim 4. Toper teaches wherein the execution record includes an execution record in which a function call record about calling a function as a destination of a reflection API is combined with a record about a final destination function finally called through the reflection API (Toper, Parag. [0060]; “At step 202, the system receives a computer program consisting of code in a dynamic language. In some embodiments, a client device 120 sends a computer program in code form to one or more devices or systems configured to receive the computer program. In some embodiments, a user selects the computer program based on a prompt or request for the computer program within a user interface of the client device. Upon selecting the program, the computer program is sent to the optimization engine 102, which may be part of the client device 120 or part of some other device or system. In some embodiments, the computer program consists of code in a dynamic language, such as Python or any other suitable dynamic language. For example, “reflection” is a dynamic language feature within Java. The Java Reflection Application Programming Interface (API) allows programmers to dynamically inspect and interact with otherwise static language concepts such as classes, fields and methods, in order to, e.g., dynamically instantiate objects, set fields, invoke methods, and perform other suitable tasks within programming languages. In some examples, therefore, a user may choose an option to send a Java program containing dynamic reflection instructions to one or more elements of the system via a user interface on a client device. In some embodiments, upon the system receiving the program, a verification step is performed in order to verify that the program submitted contains one or more dynamic instructions.”).
As per claim 15, the rejection of claim 14 is included. In addition, it is a method claim that recites similar features as presented on claim 2. Therefore, claim 15 is rejected with the same rationale and motivation applied to dependent claim 2.
As per claim 16, the rejection of claim 15 is included. In addition, it is a method claim that recites similar features as presented on claim 3. Therefore, claim 16 is rejected with the same rationale and motivation applied to dependent claim 3.
As per claim 17, the rejection of claim 15 is included. In addition, it is a method claim that recites similar features as presented on claim 4. Therefore, claim 17 is rejected with the same rationale and motivation applied to dependent claim 4.
As per claim 18, the rejection of claim 15 is included. In addition, it is a method claim that recites similar features as presented on claim 5. Therefore, claim 18 is rejected with the same rationale and motivation applied to dependent claim 5.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot, as applied to claim 1, and further in view of Vandergeest (US 2021/0279328).
As per claim 6, the combination of YI and Gagnerot teach the apparatus of claim 1, wherein the multiple devices include a first device including an execution record module for recording the content of the code executed by the application in a string format (Gagnerot, Parag. [0013]; “an additional Android manifest file including the name, version, access rights, and library files referenced for the application; this file is in Android binary XML that can be converted into human-readable plain text XML with dedicated tools such as AXMLPrinter2, APKTOOL, or Androguard.” … Parag. [0016]; “Each APK file has one or more program files “classes.dex”, “classesN.dex”, which contain the entire program Java code. For portability reasons, programs for Android devices are commonly written in Java and compiled to bytecode (which is contained in program.class files). The compiled bytecode is then converted from Java Virtual machine-compatible.class files to the Dalvik-compatible.dex (Dalvik Executable) file in order to enable installation on a computing device. The Java bytecode in the .class files has a binary format and represents the instructions that can be executed by a Dalvik virtual machine.” Parag. [0017]; “An APK file can be disassembled using a reverse engineering tool such as APKTOOL which produces bytecode program files called “classes” and data files arranged in directories and sub-directories called “packages” … Parag. [0025]; “According to an embodiment, the method further comprises: extracting program code files from the executable application file; and converting the program code files …..” … Parag. [0030]; “According to an embodiment, the syntactical metrics are applied to character strings of the program text files and comprise at least one of … with respect to the total number of character strings, ratio of a number of character strings having at least one Unicode character, with respect to the total number of character strings”); and
a second device including the execution record module and debugging, rooting, (YI, Parag. [0057]; “To bypass the anti-analysis techniques, it is necessary to interrupt the routines that detect the rooting environment, emulator environment and debugger environment. In this instance, when detection routines are found, a task of forcibly changing to a normal program execution flow is necessary, and this task may be performed by manipulating a variable that stores a result or ignoring the routine itself. The present disclosure proposes the device of the structure shown in FIG. 1 to automatically bypass the anti-analysis techniques.” … Parag. [0077]; “Since the analysis tool works in a manner of wrapping the entire execution of the application, there is no need for any additional task for separate additional debugging module installation and rooting, emulator modification, etc.”…. Parag. [0132]; “FIG. 10 shows a part of method implementing check for “su” binary, one of rooting detection techniques.”) and [code tampering functionalities].
The combination of YI and Gagnerot does not expressly teach:
a second device including …, and code tampering functionalities.
However, Vandergeest teaches:
a second device including the …, and code tampering functionalities (Vandergeest, Parag. [0053]; “In terms of the agent's performance of integrity verification , the agent is configured to dynamically monitor ( e.g. , in memory while the software is running ) the integrity of the kernel , the secure boot components , the agent itself , and all protected applications and unprotected applications to determine if any of these items have been modified in any way at any time during the execution of the given application(s) (e.g., dynamic tampering which might be implemented using a debugger.)” Examiner submits that the claimed second device is an obvious design, the claimed functionalities could be available in a first and/or second device.).
YI, Gagnerot and Vandergeest are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Vandergeest system into YI-Gagnerot system, with a motivation to providing an OS framework that has available anti-tampering functionalities (Vandergeest, Parag. [0053]).
As per claim 19, the rejection of claim 14 is included. In addition, it is a method claim that recites similar features as presented on claim 6. Therefore, claim 19 is rejected with the same rationale and motivation applied to dependent claim 6.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot and Vandergeest (US 2021/0279328), as applied to claim 6, and further in view of Kwon et al. (US 2016/0105540) hereinafter Kwon.
As per claim 7, the combination of YI, Gagnerot and Vandergeest teach the apparatus of claim 6, wherein the execution control module sets a language setting, a GPS setting, a communication service provider setting, Android OS build information, an IP address, SIM card information, and an application install list of the first device to be different from those of the second device.
The combination of YI, Gagnerot and Vandergeest does not expressly teach:
wherein the execution control module sets a language setting, a GPS setting, a communication service provider setting, Android OS build information, an IP address, SIM card information, and an application install list of the first device to be different from those of the second device.
However, Kwon teaches:
wherein the execution control module sets a language setting, a GPS setting, a communication service provider setting, Android OS build information, an IP address, SIM card information, and an application install list of the first device to be different from those of the second device (Kwon, Parag. [0068]; “Each of the Wi-Fi module 223, the BT module 225, the GPS module 227, and the NFC module 228 may include, for example, a processor for processing data transmitted/received through the modules.” … Parag. [0070]; “The SIM card 224 may include, for example, an embedded SIM and/or a card including a user identification module, and may include unique identification information (e.g., an integrated circuit card identifier (ICCID)) or subscriber information (e.g., international mobile subscriber identity (IMSI)).” … “Parag. [0092]; “The API 360 which is, for example, a set of API programming functions may be provided in different configurations according to an operating system. For example, in the case of Android® or iOS®, one API set may be provided for each platform, and, in the case of Tizen®, at least two API sets may be provided for each platform.” … Parag. [0149]; “For example, the configuration information may include a theme, a language, or a ringtone of the electronic device.”).
YI, Gagnerot, Vandergeest and Kwon are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kwon system into YI-Gagnerot-Vandergeest system, with a motivation to providing a module/modules that allows configuring or collecting feature information from a device (Kwon, Parag. [0068], [0070] and [0092]).
As per claim 20, the rejection of claim 19 is included. In addition, it is a method claim that recites similar features as presented on claim 7. Therefore, claim 20 is rejected with the same rationale and motivation applied to dependent claim 7.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot and Vandergeest (US 2021/0279328), as applied to claim 6, and further in view of Tao, et al. (CN 108133139-included on IDS) hereinafter Tao.
As per claim 8, the combination of YI, Gagnerot and Vandergeest teaches the apparatus of claim 6, wherein the execution evaluation instrumentation module includes a function call difference detection unit for detecting a difference by comparing the execution records received from the multiple devices.
The combination of YI, Gagnerot and Vandergeest does not expressly teach:
wherein the execution evaluation instrumentation module includes a function call difference detection unit for detecting a difference by comparing the execution records received from the multiple devices.
However, Tao teaches:
wherein the execution evaluation instrumentation module includes a function call difference detection unit for detecting a difference by comparing the execution records received from the multiple devices (Tao, Page 6-7; Parag. 10-1; “… the application program is placed in the different operation environments, the application behavior dynamic capturing method is adopted, recording the specific behaviors applied in different operating environments (i.e., multiple devices), analyzing and comparing the behavior of the application program, comparing the difference of the operating behaviors of the application program in different environments, therefore, the behavior difference condition of the application program is captured, whether malicious behaviors exist is detected, and the method is suitable for identifying the environment-sensitive malicious application program which cannot be effectively detected by the existing detection technology.” … Page 12, Parag. 2; “When comparing two behavior records obtained by an application program in different operating environments, the behavior analysis comparison submodule firstly respectively calculates the similarity of system API calling sequences between corresponding threads in the two behavior records according to thread numbers in the two behavior records. In order to accurately reflect the similarity between two calling sequences, the editing distance between the two calling sequences is calculated to measure the similarity between the two calling sequences, a real number between 0 and 1 is obtained as the measure of the similarity, and the greater the similarity is, the more similar the two calling sequences are. After the similarity between each thread pair is obtained through calculation, the individual similarities are added into an overall similarity according to the proportion of the number of API call records in the system API call sequence in each thread to the total number of the API call records in the whole behavior record, and the overall similarity is used as the final result of the similarity of the two behavior records of the application program. And after the similarity comparison between all the behavior records is completed, a consistency matrix of the runtime behaviors of the application program is formed. Besides the similarity between the application program behavior records, the submodule can also count the difference between the types and the number of the specific calling system API functions between the two corresponding threads to obtain the behavior classification statistical result.”).
YI, Gagnerot, Vandergeest and Tao are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Tao system into YI-Gagnerot-Vandergeest system, with a motivation to providing for detecting a difference by comparing the execution records received from the multiple devices/environments (Tao, Page 6-7; Parag. 10-1).
As per claim 9, the combination of YI, Gagnerot, Vandergeest and Tao teaches the apparatus of claim 8. Tao teaches wherein the execution evaluation instrumentation module includes a [branch] difference detection unit for detecting [a branch point], a source of which is a same but a destination of which is different between the execution records of the multiple devices, using function call information corresponding to the difference (Jing, Page 6-7; Parag. 10-1; “… the application program is placed in the different operation environments, the application behavior dynamic capturing method is adopted, recording the specific behaviors applied in different operating environments (i.e., multiple devices), analyzing and comparing the behavior of the application program, comparing the difference of the operating behaviors of the application program in different environments, therefore, the behavior difference condition of the application program is captured, whether malicious behaviors exist is detected, and the method is suitable for identifying the environment-sensitive malicious application program which cannot be effectively detected by the existing detection technology.” … Page 12, Parag. 2; “When comparing two behavior records obtained by an application program in different operating environments, the behavior analysis comparison submodule firstly respectively calculates the similarity of system API calling sequences between corresponding threads in the two behavior records according to thread numbers in the two behavior records. In order to accurately reflect the similarity between two calling sequences, the editing distance between the two calling sequences is calculated to measure the similarity between the two calling sequences, a real number between 0 and 1 is obtained as the measure of the similarity, and the greater the similarity is, the more similar the two calling sequences are. After the similarity between each thread pair is obtained through calculation, the individual similarities are added into an overall similarity according to the proportion of the number of API call records in the system API call sequence in each thread to the total number of the API call records in the whole behavior record, and the overall similarity is used as the final result of the similarity of the two behavior records of the application program. And after the similarity comparison between all the behavior records is completed, a consistency matrix of the runtime behaviors of the application program is formed. Besides the similarity between the application program behavior records, the submodule can also count the difference between the types and the number of the specific calling system API functions between the two corresponding threads to obtain the behavior classification statistical result.”).
In addition, YI teaches:
determining a branch point (YI, Parag. [0106]; “An instrumentator module 500 plays a role in monitoring and controlling the flow of the program by instrumenting the actual code and if necessary, modifying or deleting. In this instance, the metadata created by pre-processing is used and the instrumented result is extracted in the log format.” … Parag. [0114]; “The instrumentator module 500 is a module that instruments the actual code of the app_process and the application and manages the execution flow of the program.” … Parag. [0130]; “FIG. 9 shows the translation of [cbz] instruction into IR as an example of IR modification through constant value change. The [cbz] instruction is an instruction which determines the branch by comparing with 0, and in this instance, the execution is changed by changing the value of 0 to 1.”).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot, Vandergeest (US 2021/0279328) and Tao et al. (CN 108133139-included on IDS) hereinafter Tao, as applied to claim 9, and further in view of Yasunori (JP 2011154459).
As per claim 10, the combination of YI, Gagnerot, Vandergeest and Tao teaches the apparatus of claim 9. YI teaches wherein, when the branch point YI, Parag. [0106]; “An instrumentator module 500 plays a role in monitoring and controlling the flow of the program by instrumenting the actual code and if necessary, modifying or deleting. In this instance, the metadata created by pre-processing is used and the instrumented result is extracted in the log format.” … Parag. [0114]; “The instrumentator module 500 is a module that instruments the actual code of the app_process and the application and manages the execution flow of the program.” … Parag. [0130]; “FIG. 9 shows the translation of [cbz] instruction into IR as an example of IR modification through constant value change. The [cbz] instruction is an instruction which determines the branch by comparing with 0, and in this instance, the execution is changed by changing the value of 0 to 1.”)
In addition, Tao teaches:
is executed in both the first and second devices (Tao, Page 6-7; Parag. 10-1; “… the application program is placed in the different operation environments, the application behavior dynamic capturing method is adopted, recording the specific behaviors applied in different operating environments (i.e., multiple devices), analyzing and comparing the behavior of the application program, comparing the difference of the operating behaviors of the application program in different environments, therefore, the behavior difference condition of the application program is captured, whether malicious behaviors exist is detected, and the method is suitable for identifying the environment-sensitive malicious application program which cannot be effectively detected by the existing detection technology.” … Page 12, Parag. 2; “When comparing two behavior records obtained by an application program in different operating environments, the behavior analysis comparison submodule firstly respectively calculates the similarity of system API calling sequences between corresponding threads in the two behavior records according to thread numbers in the two behavior records. In order to accurately reflect the similarity between two calling sequences, the editing distance between the two calling sequences is calculated to measure the similarity between the two calling sequences, a real number between 0 and 1 is obtained as the measure of the similarity, and the greater the similarity is, the more similar the two calling sequences are. After the similarity between each thread pair is obtained through calculation, the individual similarities are added into an overall similarity according to the proportion of the number of API call records in the system API call sequence in each thread to the total number of the API call records in the whole behavior record, and the overall similarity is used as the final result of the similarity of the two behavior records of the application program. And after the similarity comparison between all the behavior records is completed, a consistency matrix of the runtime behaviors of the application program is formed. Besides the similarity between the application program behavior records, the submodule can also count the difference between the types and the number of the specific calling system API functions between the two corresponding threads to obtain the behavior classification statistical result.”) [but a branch destination in the second device is not found in the execution record of the first device, the branch difference detection unit determines that a corresponding branch has a difference].
The combination of YI, Gagnerot, Vandergeest and Tao does not expressly teach:
a branch destination in the second device is not found in the execution record of the first device, the branch difference detection unit determines that a corresponding branch has a difference.
However, Yasunori teaches:
a branch destination in the second device is not found in the execution record of the first device, the branch difference detection unit determines that a corresponding branch has a difference (Yasunori, Page 6, Parag. 4; “the branch instruction and the branch destination address corresponding to the branch instruction are stored such that the address of the branch destination address has a predetermined positional relationship with respect to the address of the branch instruction, and the output of the program counter In response to the detection, the predetermined positional relationship between the output value of the program counter and the address of the instruction executed immediately before by the central processing unit is detected. Is compared with the data stored at the address, and an abnormality detection signal is generated when the comparison result is inconsistent.”).
YI, Gagnerot, Vandergeest, Tao and Yasunori are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yasunori system into YI-Gagnerot-Vandergeest-Tao system, with a motivation for detecting a branch difference by comparing the execution records received from the multiple devices/environments (Yasunori, Page 6, Parag. 4).
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot, Vandergeest (US 2021/0279328) and Tao et al. (CN 108133139-included on IDS) hereinafter Tao, as applied to claim 9, and further in view of Ning, et al. (“DexLego: Reassembleable Bytecode Extraction for Aiding Static Analysis”, 2018).
As per claim 11, the combination of YI, Gagnerot, Vandergeest and Tao teach the apparatus of claim 9, wherein the execution evaluation instrumentation module includes a static branch modification unit for modifying code of a Dalvik executable (DEX) file within the APK file such that branching from a branch point determined to have a difference results in jumping to a branch destination corresponding to the execution record of the first device.
The combination of YI, Gagnerot, Vandergeest and Tao does not expressly teach:
wherein the execution evaluation instrumentation module includes a static branch modification unit for modifying code of a Dalvik executable (DEX) file within the APK file such that branching from a branch point determined to have a difference results in jumping to a branch destination corresponding to the execution record of the first device.
However, Ning teaches:
wherein the execution evaluation instrumentation module includes a static branch modification unit for modifying code of a Dalvik executable (DEX) file within the APK file such that branching from a branch point determined to have a difference results in jumping to a branch destination corresponding to the execution record of the first device (Ning, Section III-A; “Figure 2 shows the JIT collection we used in DEXLEGO. During the execution of an application, ART firstly extracts the DEX file from the original APK file and passes it to the class linker. The class linker then loads and initializes the classes in the DEX file, and our JIT collection method collects the metadata of the class (e.g., super class) at this point.” … Section III-B; “After the collecting, all the output files are reassembled to a new DEX file offline following the format of a DEX file, and we replace the DEX file in the original APK file with the reassembled one. The modified APK file is finally fed to static analysis tools to study the malicious behavior. This reassembling is not trivial, and we consider this is the key contribution of this work. In the DEX file format, each method contains only one instruction array. However, due to different control flows (e.g., execution is led to different branches of a branch statement) or self-modifying code, one method may contain different instruction arrays in the collection stage.” … Section III-C; “To improve the code coverage of dynamic analysis systems, there already exists a series of tools or theories like: 1) Input generators or fuzzing tools [28]–[32], 2) Symbolic or concolic execution [23], [33]–[37] based systems, 3) Force execution [38]–[40] based systems. … To use force execution in DEXLEGO, we identify the Uncovered Conditional Branches (UCB) and calculate the path to each UCB. By monitoring and manipulating the branch instructions in the interpreter, we force the control flow to go along the calculated path to reach each UCB.”)
YI, Gagnerot, Vandergeest, Tao and Ning are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ning system into YI-Gagnerot-Vandergeest-Tao system, with a motivation for modifying code of a Dalvik executable (DEX) file within the APK file using static branch analysis (Ning, Section III).
As per claim 12, the combination of YI, Gagnerot, Vandergeest and Tao teach the apparatus of claim 9, wherein the execution evaluation instrumentation module includes a dynamic branch modification unit for performing, when code corresponding to a branch point determined to have a difference is not found in a Dalvik executable (DEX) file within the APK file, control to change a branch destination to a preset destination when the branch point is executed in the device.
The combination of YI, Gagnerot, Vandergeest and Tao does not expressly teach:
wherein the execution evaluation instrumentation module includes a dynamic branch modification unit for performing, when code corresponding to a branch point determined to have a difference is not found in a Dalvik executable (DEX) file within the APK file, control to change a branch destination to a preset destination when the branch point is executed in the device.
However, Ning teaches:
wherein the execution evaluation instrumentation module includes a dynamic branch modification unit for performing, when code corresponding to a branch point determined to have a difference is not found in a Dalvik executable (DEX) file within the APK file, control to change a branch destination to a preset destination when the branch point is executed in the device (Ning, Section III-A; “Figure 2 shows the JIT collection we used in DEXLEGO. During the execution of an application, ART firstly extracts the DEX file from the original APK file and passes it to the class linker. The class linker then loads and initializes the classes in the DEX file, and our JIT collection method collects the metadata of the class (e.g., super class) at this point.” … Section III-B; “After the collecting, all the output files are reassembled to a new DEX file offline following the format of a DEX file, and we replace the DEX file in the original APK file with the reassembled one. The modified APK file is finally fed to static analysis tools to study the malicious behavior. This reassembling is not trivial, and we consider this is the key contribution of this work. In the DEX file format, each method contains only one instruction array. However, due to different control flows (e.g., execution is led to different branches of a branch statement) or self-modifying code, one method may contain different instruction arrays in the collection stage.” … Section III-C; “To improve the code coverage of dynamic analysis systems, there already exists a series of tools or theories like: 1) Input generators or fuzzing tools [28]–[32], 2) Symbolic or concolic execution [23], [33]–[37] based systems, 3) Force execution [38]–[40] based systems. … To use force execution in DEXLEGO, we identify the Uncovered Conditional Branches (UCB) and calculate the path to each UCB. By monitoring and manipulating the branch instructions in the interpreter, we force the control flow to go along the calculated path to reach each UCB.”).
YI, Gagnerot, Vandergeest, Tao and Ning are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ning system into YI-Gagnerot-Vandergeest-Tao system, with a motivation for modifying code of a Dalvik executable (DEX) file within the APK file using dynamic branch analysis (Ning, Section III).
Claims 13 is rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 2022/0164446) hereinafter YI in view of Gagnerot et al. (US 2020/0226232) hereinafter Gagnerot, Vandergeest (US 2021/0279328) and Tao et al. (CN 108133139-included on IDS) hereinafter Tao, and Ning, et al. (“DexLego: Reassembleable Bytecode Extraction for Aiding Static Analysis”, 2018), as applied to claim 11, and further in view of Bong et al. (KR 20140027588) hereinafter Bong.
As per claim 13, the combination of YI, Gagnerot, Vandergeest, Tao and Ning teach the method of claim 11, wherein the execution evaluation instrumentation module compares an execution record acquired by again executing the modified APK file in the second device with the execution record of the first device.
The combination of YI, Gagnerot, Vandergeest, Tao and Ning does not expressly teach:
wherein the execution evaluation instrumentation module compares an execution record acquired by again executing the modified APK file in the second device with the execution record of the first device.
However, Bong teaches:
wherein the execution evaluation instrumentation module compares an execution record acquired by again executing the modified APK file in the second device with the execution record of the first device (Bong, Page 2, Parag. 1, “The present invention relates to a system for detecting whether a mobile application file has been manipulated, and more particularly, to detect whether a mobile application file has been repackaged based on whether a repackaging is performed on a mobile application file including a signature (signature information). The present invention relates to a mobile application file manipulation detection system, an apparatus, a method, and a computer-readable recording medium.” … Page 3, Parag. 3; “According to another aspect of the present invention, a method for detecting whether a mobile application file is manipulated includes: each step performed by a signature authentication server device includes: receiving a request from a user terminal; And providing a mobile application to the user terminal in response to the request, wherein the mobile application, at first execution, extracts first signature information from the mobile application and stores it in the user terminal; Extracting second signature information from the mobile application upon redo; Comparing the first signature information with the second signature information; And determining whether to execute the mobile application based on the comparison result.” … Page 12, Parag. 8; “In some embodiments, such functions (which may be implemented on the same device or on distinct devices) may be implemented in such a manner and in accordance with various aspects of the present invention, etc., and / Operations and functions, and their equivalents. In some embodiments, such processing is performed together by the first functional portion in the first device and the second functional portion in the second device.”).
YI, Gagnerot, Vandergeest, Tao, Ning and Bong are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for detecting malicious applications using dynamic analysis tools.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bong system into YI-Gagnerot-Vandergeest-Tao-Ning system, with a motivation for compare a repackage application file in different devices to verify manipulation or modification (Bong, Page 2, Parag. 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Finking et al. (US 2012/0151453) relates to system and method for automatically identifying a source of a run-time error in a computer system comprises a static analysis system (SAS), an instrumentation system (IS) and a post-execution analysis system (PEAS). The is arranged to generate static analysis data on computer program code (CPC) for the computer system, including information on possible behaviors of the CPC when executed. The IS is arranged to instrument the CPC by inserting marker triggers into the CPC that, generate a marker associated with each of a number of predetermined points in the CPC that would be reached during execution of the CPC. Each marker is, uniquely identifiable. The predetermined points are determined in dependence on the static analysis data. The PEASpost execution analysis system is arranged to processes data on a run-time error produced by execution of the instrumented CPC, wherein the generated markers and the static analysis data to identify the source of the run-time error.
Xu et al. (US 9,106,630) relates to techniques for performing static and dynamic analysis on a mobile device application are disclosed. Static analysis is performed on a mobile device application using a static analysis engine. A set of static analysis results is generated. Dynamic analysis of the application is selectively customized based at least in part on a presence of a permission in the set of static analysis results. Dynamic analysis is performed using a dynamic analysis engine. A determination of whether the application is malicious is made based at least in part on the dynamic analysis.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEX D CARRASQUILLO whose telephone number is (571)270-5045. The examiner can normally be reached Monday - Friday 9:00 am - 6:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.D.C./Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights