DETAILED ACTION
This action is in response to the application filed on 9/30/2024.
Claims 1-18 are pending in this application.
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
Claims 1-18 are objected to because of the following informalities:
Claim 1:
line 1 “DEX” should be spelled out since it is first occurrence, i.e. --Dalvik EXecutable (DEX)-- . Claim 12 has a similar issue.
line 9 “ELF” should be spelled out since it is first occurrence, i.e. --Executable and linkable Format (ELF)--. Claim 12 has a similar issue.
Claim 2, line 2 “OAT” should be spelled out since it is first occurrence, i.e. --Executable and linkable Format (ELF)--.
Claim 5 line 1 “an app” should be --the app--.
Claims 3, 4, 6-11, and 13-18 do not overcome the deficiency of the base claims and, therefore, are objected for the same reasons as the base claims.
Appropriate correction is required.
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.
Claims 5-18 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 5, “the memory unit” and “the corresponding method” lack proper antecedent basis and has been interpreted as --a memory unit-- and --a corresponding method--.
Claim 6, “the execution environment” lacks proper antecedent basis and has been interpreted as --an execution environment--. Claim 16 has a similar issue. Further, “said app” in line 4 is unclear whether it refers to “an app” in line 3 or 9 of claim 1 or line 2 of claim 5. For the examination purposes, “said app” will be treated as --the said packaged app--.
Claim 7, “the AOT (Ahead-of-Time) compiler” lacks proper antecedent basis and has been interpreted as --an AOT (Ahead-of-Time) compiler--.
Claim 8 also recites “the step of executing”, which lacks proper antecedent basis and has been interpreted as --the security executing method further comprising…-- Claims 9-11 have a similar issue.
Claim 10, lines 2-3 recite “said compiled replacement machine language DEX file and ELF file”, which is unclear and has been interpreted as “an ELF file of the associated ELF files”.
Claim 11, “the location” lacks proper antecedent basis and has been interpreted as “a location”.
Claim 12, “the storage unit” lacks proper antecedent basis and has been interpreted as “a storage unit”.
Claim 13 “the methods” lack proper antecedent basis and has been interpreted as “methods”.
Claim 15 “the computer readable-instructions” lack proper antecedent basis and has been interpreted as “computer readable-instructions”. Also, lines 8-9 recite “finding said method of the protected machine language DEX file in said replacement DEX file and executing it” is unclear and has been interpreted as “executing said method”.
Claims 9, and 14 do not overcome the deficiency of the base claims and, therefore, are rejected for the same reasons as the base claims.
Claim Rejections - 35 USC § 102
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.
Claims 1-3, 5-8, 12,13, and15-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jeon et al. US Patent Application Publication 2018/0157808 A1).
As to claim 1, Jeon teaches a security providing method for protecting a DEX file, the method comprising the steps of:
extracting a DEX file from an app received from a program developing device (See e.g. Fig.3 and associated text, e.g. [0066]- The dex file 300 may be included in an Android application package (APK) developed by developers and may be transmitted and registered to a system, such as the server 150, for code protection and [0067]- Here, the server 150 may extract the dex file 300, such as a ‘classes.dex’ file from the APK uploaded through the webpage),
compiling said extracted DEX file into a machine language DEX file (See e.g. [0073]- The ART machine may convert the dex file to the OAT file using a converter called ‘dex2oat’ and may execute the converted OAT file. That is, when installing the application, the ART machine converts the application to a native application and installs the converted native application through an ahead of-time (AOT) compilation (e.g., compiling all of the classes and/or methods, etc., of the application into machine code prior to run-time and/or execution, etc.),
protecting said compiled machine language DEX file (See e.g. [0070]- the server 150 may verify a list of classes or methods through a function, such as an API call for a developer system, may retrieve a class or a method from the list of classes or methods, and may select the class or the method as a protection target class and/or a protection target method and [0072]- methods selected as protection targets in the dex file 400 of FIG. 4 are encrypted),
generating a replacement DEX file capable of executing said protected machine language DEX file (e.g. Classes.dex 620, see e.g. [0079]- the electronic device may secure native codes of the protection target class and the protection target method by executing a ‘dex2oat’ instruction, that is, an instruction for converting codes of the protection target class and the protection target method to native codes, by using, as a factor, the dex file recorded on the native module and Fig.6 , 620 and associated text, e.g. and [0081]- code included in the dex file may be converted to a native code using a converter, such as dex2oat, when installing an application. Also, as described above, a format of the dex file may be converted to an OAT file format and may include an OAT header (Oat Header) 622; the OatClass 625 provides information (OatMethodOffset) 626 capable of retrieving code corresponding to a desired method from a native code 627 through a method index. As described above, the electronic device may acquire a normal native code by converting a dex file (including codes of a protection target class and a protection target method(s) before encryption) included in decryption information using a converter. In this case, the electronic device may decrypt the encrypted protection target method by retrieving code corresponding to the encrypted protection target method from the native code 627 and by replacing the retrieved code with the normal native code) and
packaging said protected machine language DEX file, said generated replacement DEX file, and associated ELF files into an app (See e.g. [0077]- The APK that includes the dex file in which the protection target method is encrypted may be transmitted to and installed on an electronic device, for example, the electronic device 110 and Fig.6 and associated text, e.g. [0081]- The dex file loaded to a memory of the electronic device may be, for example, substantially in an Elf share object (extension “.so”) format, and may include an ELF header (Elf Header) 621 as shown in Classes.dex 620; The Classes.dex 624 may correspond to the Classes.dex 610 that is the dex file before conversion. The Dex File Meta Header 623 may include meta information associated with the Classes.dex 624).
As to claim 2, Jeon teaches the security providing method according to claim 1, wherein said step of compiling comprises compiling said extracted DLX file into an OAT file by an AOT (Ahead-of- Time) compiler (See e.g. [0073]- The ART machine may convert the dex file to the OAT file using a converter called ‘dex2oat’ and may execute the converted OAT file. That is, when installing the application, the ART machine converts the application to a native application and installs the converted native application through an ahead of-time (AOT) compilation (e.g., compiling all of the classes and/or methods, etc., of the application into machine code prior to run-time and/or execution, etc.).
As to claim 3, Jeon teaches the security providing method according to claim 1, wherein the step of protecting comprises parsing said compiled machine language DLX file to extract methods to be encrypted and performing encryption for the extracted methods on a method-by-method basis (See e.g. [0068]- corresponding classes and/or methods are selected as protection targets and [0070]- the server 150 may verify a list of classes or methods through a function, such as an API call for a developer system, may retrieve a class or a method from the list of classes or methods, and may select the class or the method as a protection target class and/or a protection target method).
As to claim 5, Jeon teaches a security executing method performed on a security executing device having an app packaged by the security providing method according to claim 1 and stored in a storage unit (See e.g. [0077]- The APK that includes the dex file in which the protection target method is encrypted may be transmitted to and installed on an electronic device, for example, the electronic device 110), the method comprises the steps of: installing said packaged app (see e.g. [0079]- the electronic device may secure native codes of the protection target class and the protection target method by executing a ‘dex2oat’ instruction, that is, an instruction for converting codes of the protection target class and the protection target method to native codes, by using, as a factor, the dex file recorded on the native module; code of an application may be converted to a native code through an AOT compilation and thereby installed when installing the application), when execution of said installed app is requested, loading a corresponding replacement DEX file from said storage unit into the memory unit (see e.g.[0081]- code included in the dex file may be converted to a native code using a converter, such as dex2oat, when installing an application. The dex file loaded to a memory of the electronic device may be, for example, substantially in an Elf share object (extension “.so”) format, and may include an ELF header (Elf Header) 621 as shown in Classes.dex 620) and when a predetermined method is called, finding and executing the corresponding method from a protected machine language DEX file in said replacement DEX file (See e.g. [0081]- the electronic device may decrypt the encrypted protection target method by retrieving code corresponding to the encrypted protection target method from the native code 627 and by replacing the retrieved code with the normal native code).
As to claim 6, Jeon teaches the security executing method according to claim 5, wherein the step of installing comprises compiling said replacement DEX file into a replacement machine language DEX file, optimized for the execution environment of said security executing device in which said app is to be executed (see e.g. [0073]- The ART machine may convert the dex file to the OAT file using a converter called ‘dex2oat’ and may execute the converted OAT file. That is, when installing the application, the ART machine converts the application to a native application and installs the converted native application through an ahead of-time (AOT) compilation (e.g., compiling all of the classes and/or methods, etc., of the application into machine code prior to run-time and/or execution, etc; An APK for Dalvik runtime and an APK for ART may be separately generated and an appropriate APK may be transmitted based on a corresponding electronic device), and the step of loading comprises loading said compiled replacement machine language DEX file from said storage unit into said memory unit (See e.g. [0081]- on the ART, code included in the dex file may be converted to a native code using a converter, such as dex2oat, when installing an application. The dex file loaded to a memory of the electronic device may be, for example, substantially in an Elf share object (extension “.so”) format, and may include an ELF header (Elf Header) 621 as shown in Classes.dex 620).
As to claim 7, Jeon teaches the security executing method according to claim 6, wherein the replacement machine language DEX file is compiled by the AOT (Ahead-of-Time) compiler (see e.g. [0073]- (see e.g. [0073]- The ART machine may convert the dex file to the OAT file using a converter called ‘dex2oat’ and may execute the converted OAT file. That is, when installing the application, the ART machine converts the application to a native application and installs the converted native application through an ahead of-time (AOT) compilation (e.g., compiling all of the classes and/or methods, etc., of the application into machine code prior to run-time and/or execution, etc).
As to claim 8, Jeon teaches the security executing method according to claim 6, wherein said protected machine language DEX file of said packaged app is encrypted for each method by way of a method-by-method basis (See e.g. [0068]- corresponding classes and/or methods are selected as protection targets and [0070]- the server 150 may verify a list of classes or methods through a function, such as an API call for a developer system, may retrieve a class or a method from the list of classes or methods, and may select the class or the method as a protection target class and/or a protection target method), the step of executing comprises, when a predetermined method is first called, finding said method in said encrypted machine language DEX file in said storage unit (See e.g. [0081]- the electronic device may decrypt the encrypted protection target method by retrieving code corresponding to the encrypted protection target method from the native code 627 and by replacing the retrieved code with the normal native code), loading said method into said memory unit, and decrypting said method of said encrypted machine language DEX file in said memory unit (See e.g. [0092]- the encrypted protection target method may be decrypted at the electronic device by decrypting code corresponding to a size of the encrypted IL code from the offset of the encrypted IL code from a dex header of the dex file loaded to a memory of the electronic device using the key and by overwriting the decrypted code on the dex header).
As to claim 12, the limitations of the claims are substantially similar to the limitations of claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 13, the limitations of the claims are substantially similar to the limitations of claim 3, and therefore, it is rejected for the reasons stated above.
As to claim 15, the limitations of the claims are substantially similar to the limitations of claim 5, and therefore, it is rejected for the reasons stated above.
As to claim 16, the limitations of the claims are substantially similar to the limitations of claim 6, and therefore, it is rejected for the reasons stated above.
As to claim 17, the limitations of the claims are substantially similar to the limitations of claim 8, and therefore, it is rejected for the reasons stated above.
Claim Rejections - 35 USC § 103
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 4, 11, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Jeon et al. US Patent Application Publication 2018/0157808 A1) in view of Salmon-Legagneur et al. (US Patent Application Publication 2016/0239671 A1).
As to claim 4, Jeon teaches the limitations of claim, 1, but does not specifically teach wherein the generated replacement DEX file is filled with dummy information or proxy information in each method of the generated replacement DEX file.
In an analogous art of protecting an application, however, Salmon-Legagneur teaches
wherein a generated replacement DEX file (e.g. protected DEX 320) is filled with dummy information or proxy information in each method of the generated replacement DEX file (See Figs.1 and 3 and associated text, e.g. [0037]- The post-build tool first extracts S102 the parts of code to protect from the code section of the original DEX file. This can be achieved in different ways. The simplest way is to consult a configuration file that lists classes and methods to be protected), [0040]- In the DEX file, each code part to be protected is replaced S108 with fake but valid Java instructions of the same size. ‘Fake’ means that these instructions are different from the original instructions. ‘Valid’ means that these functions are accepted as real Java instructions that will be accepted by the Dalvik byte code verifier and [0049]- The protected DEX code 320 includes a first set of fake instructions 322 at offset f1( ) and a second set of fake instructions 324 at offset fn( ), respectively replacing the first part 312 and the second part 314.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Jeon to incorporate/implement the limitations as taught by Salmon-Legagneur in order to provide a more efficient method of protecting an application from tampering.
As to claim 11, Jeon teaches the compiled replacement machine language DEX file (See e.g. [0073]) and the step of executing (see e.g. [0081]), but does not specifically teach contains proxy information for each method or when the predetermined method is called, accessing the location of the method in the machine language DEX file using the proxy information for the method.
In an analogous art of protecting an application, however, Salmon-Legagneur teaches a replacement DEX file that contains proxy information for each method (See Figs.1 and 3 and associated text, e.g. [0037]- The post-build tool first extracts S102 the parts of code to protect from the code section of the original DEX file. This can be achieved in different ways. The simplest way is to consult a configuration file that lists classes and methods to be protected), [0040]- In the DEX file, each code part to be protected is replaced S108 with fake but valid Java instructions of the same size. ‘Fake’ means that these instructions are different from the original instructions. ‘Valid’ means that these functions are accepted as real Java instructions that will be accepted by the Dalvik byte code verifier and [0049]- The protected DEX code 320 includes a first set of fake instructions 322 at offset f1( ) and a second set of fake instructions 324 at offset fn( ), respectively replacing the first part 312 and the second part 314) and when a predetermined method is called, accessing the location of the method in the machine language DEX file using the proxy information for the method (See e.g. Fig.4 and associated text, e.g. [0054]- The processor executes S402 code, arrives S404 at a checkpoint and calls S406 the unprotect( ), function in the protection library with the identity of the function to unprotect as a parameter. The processor then retrieves S408 information regarding the function to unprotect from the database, decrypts S410 the protected function using the retrieved information and overwrites S412 fake instructions in the code with the unprotected function).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Jeon to incorporate/implement the limitations as taught by Salmon-Legagneur in order to provide a more efficient method of protecting an application from tampering.
As to claim 14, the limitations of the claims are substantially similar to the limitations of claim 4, and therefore, it is rejected for the reasons stated above.
Claims 9, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Jeon et al. US Patent Application Publication 2018/0157808 A1) in view of Sun et al. (US Patent 9,762,385 B1).
As to claim 9, Jeon teaches decrypting the said method in said encrypted machine language DEX file (See e.g. [0092]), but does not specifically teach subsequently distributing the decrypted method by storing said decrypted method in a location different from the location of the encrypted method in said memory unit.
In an analogous art of protecting applications, however, Sun teaches decrypting the said method in said encrypted machine language DEX file (see e.g. Fig.4 and associated text, e.g. col.5 lines 16-17: decrypting the encrypted DEX program code segments 232) and subsequently distributing the decrypted method by storing said decrypted method in a location different from the location of the encrypted method in said memory unit (See e.g. col.5 lines 23-41: Each encrypted DEX program code segment 232 is read from its corresponding file in the shielded APK file 230 and then loaded in memory (step 402). The encrypted DEX program code segments 232 may be loaded into memory in the app initialization callback of the program code of the stub DEX file 231. Non-contiguous memory blocks of varying sizes are allocated (step 403) for decrypted DEX program code segments 232. In one embodiment, memory blocks of different sizes are allocated by calling the mmap API several times, e.g., more than the number of encrypted DEX program code segments 232, to ensure that the allocated blocks of memory are non-contiguous, i.e., do not have continuous memory addresses; Each encrypted DEX program code segment 232 is decrypted and the resulting decrypted DEX program code segment 232 is randomly assigned to one of the allocated memory blocks for storage (step 404).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Jeon to incorporate/implement the limitations as taught by Sun in order to provide a more efficient method of protecting an application from potential tampering.
As to claim 10, Jeon teaches said compiled replacement machine language DEX file and ELF file (See e.g. [0077]), but does not specifically teach building a trampoline scheme and when a predetermined method is called, accessing a location of said method in said encrypted machine language DEX file by said constructed trampoline scheme.
In an analogous art of protecting applications, however, Sun teaches building a trampoline scheme (e.g. pointers) and when a predetermined method is called, accessing a location of said method in said encrypted machine language DEX file by said constructed trampoline scheme (See e.g. Fig.4 and associated text, e.g. col.5 lines 10-16: The DEX shield library 233 is dynamically loaded by the Dalvik VM when the Dalvik VM initializes an instance of application. Therefore, launching the app loads the program code of the DEX shield library 233, thereby allowing the program code of the DEX shield library 233 to perform the following steps of loading the encrypted DEX program code segments in memory and col.6 lines 23-54: a mock DEX program code may be loaded (step 408) using the DexClassLoader provided by the ANDROID framework; Loading the mock DEX program code causes the DEX search list in the Dalvik VM to hold a pointer to the mock DEX program code; When the mock DEX program code is loaded, program code of the libdvm.so of the Dalvik VM parses the mock DEX program code and stores the result of the parsing in the C programming language structs DvmDex and DexFile, which are also referred to herein as “parsed mock DEX structures.” The parsed mock DEX structures may be found in the Dalvik VM (step 409) by, for example, using the reflect method from the ANDROID framework to get the DexFile JAVA object, which represents the currently loaded DEX program code in the Dalvik VM. The DexFile JAVA object has an integer member field, which is the pointer to the C struct DexOrJar. The just-mentioned pointer can be used to access the DexOrJar struct, which holds a member pointer to a DvmDex struct. The DvmDex struct, in turn, holds a member pointer to a DexFile struct. The pointer to the parsed mock DEX struct may then be set to point to the parsed DEX struct (step 410). More specifically, the member pointer to the DvmDex struct that was created by loading the mock DEX program code may be replaced by the pointer to the DvmDex struct that was created by parsing the decrypted DEX program code segments 232 (in step 406). Accordingly, the decrypted DEX program code segments 232 with non-standard format and random memory layout as in FIG. 5 are properly parsed and loaded for execution in the Dalvik VM).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Jeon to incorporate/implement the limitations as taught by Sun in order to provide a more efficient method of protecting an application from potential tampering.
As to claim 18, the limitations of the claims are substantially similar to the limitations of claim 9, and therefore, it is rejected for the reasons stated above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Huang et al. (US Patent 8,892,876 B1) discloses methods and apparatus for securing application package files for mobile computing devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights