DETAILED ACTION
This action is in response to the claims filed October 30, 2025. Claims 1-3, 7-11, 15-19, and 23-29 are pending. Claims 1, 9, and 17 are independent claims. Claims 1, 7, 9, 15, 17-19, and 25 have been amended. Claims 26-29 are new claims. Claims 4-6, 12-14, and 20-22 have been cancelled.
The objections to the claims are withdrawn in view of applicant’s amendment to the claims.
The claim rejection under 35 U.S.C. 101 is withdrawn in view of applicant’s amendments to the claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 7, 9, 15, 17, and 23-26 are rejected under 35 U.S.C. 103 as being unpatentable over US 6289505 B1 (hereinafter “Goebel”), in view of “LLBT: An LLVM-based Static Binary Translator” by Shen et. al, (hereinafter “Shen”), further in view of “UQBT: Adaptable Binary Translation at Low Cost” by Cifuentes and Emmerik (hereinafter “Emmerik”) (Examiner’s remarks: The second author is used to refer to Emmerik to avoid confusion with Cifuentes references cited in previous office actions and in following rejections).
Regarding claim 1, Goebel discloses:
A code processing method, wherein the method comprises (Column 1, lines 9-12, “Specifically, this invention is a method, apparatus and computer program product for providing a high level language compiler with the capability to re-optimize a previously compiled binary executable.”):
obtaining first code, wherein the first code is code that is obtained through compilation and that is applicable to a source platform (Column 1, lines 9-12, “Specifically, this invention is a method, apparatus and computer program product for providing a high level language compiler with the capability to re-optimize a previously compiled binary executable [obtaining first code, wherein the first code is code that is obtained through compilation]”; Column 3, lines 41-46, “One aspect of the invention includes a computer controlled method for converting a first executable binary executable that executes within a first application binary interface (ABI) environment to a second binary executable that executes within a second ABI environment [and that is applicable to a source platform]”) [Examiner’s Remarks: Goebel teaches the first code that has been obtained through compilation (previously compiled binary executable) and is applicable to a source platform (first application binary interface).], …
relocating a plurality of addresses of variables associated with functions in the first code, to obtain a plurality of logical addresses of the variables (Column 7, lines 54-60, “The IR normalization process 500 initiates at a ‘start’ terminal 501 and continues to a ‘virtualize registers’ procedure 513. The ‘virtualize registers’ procedure 503 virtualizes the registers to be independent of the register limitations of the original computer system and removes register spilling instructions from the intermediate representation [relocating a plurality of addresses of variables associated with functions in the first code, to obtain a plurality of logical addresses of the variables]”) [Examiner’s Remarks: A plurality of addresses (registers) are relocated (virtualized) to obtain a plurality of logical addresses independent of the original computer system limitations.]: and
performing decompilation based on the plurality of logical addresses of the variables and the first code, to obtain second code applicable to a target platform (Column 2, lines 2-6, “During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer [performing decompilation based on the plurality of logical addresses of the variables]”; Column 3, lines 47-54, “The method includes the step of converting the first executable binary executable to an intermediate representation. Then the intermediate representation is processed to remove an architectural related optimization that depends on the first ABI environment. The method also includes the steps of optimizing the intermediate representation for the second ABI environment and of generating the second binary executable [and the first code, to obtain second code applicable to a target platform]”) [Examiner’s Remarks: Code is generated from logical addresses (virtual registers) and an intermediate representation obtained from the first code, to generate a second code optimized for a target platform (second ABI).]…
…
wherein before the performing decompilation based on the plurality of logical addresses of the variables and the first code, the method further comprises (Column 1, lines 28-41, “The intermediate code representation 104 is then optimized by an intermediate representation optimizer segment 105. The intermediate representation optimizer segment 105 operates on, and adjusts, the intermediate code representation 104 of the source information 101 to optimize the execution of a program in a variety of ways well understood in the art. The intermediate representation optimizer segment 105 generates an optimized intermediate representation 106. A code generator segment 107 consumes the optimized intermediate representation 106, performs low level optimizations, allocates physical registers and generates binary module 109 (and conditionally assembler source code) from the optimized intermediate representation 106”; Column 1, line 63 – Column 2, line 4; “As mentioned above, the code generator segment 107 performs low level optimizations and generates either (or both) binary code or assembler source code. The intermediate representation of the program generally references virtual registers. That is, the intermediate representation optimizer assumes that the target computer contains an unlimited number of registers. During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer.” [wherein before the performing decompilation based on the plurality of logical addresses of the variables and the first code, the method further comprises]) [Examiner’s remarks: Before performing the portion of decompilation based on the plurality of logical addresses of variables, the first code’s associated IR is optimized.]:
Goebel does not explicitly disclose:
… wherein the first code is machine language applicable to the source platform, and wherein the source platform runs on a first machine applied to a first instruction set architecture;
…
… wherein the target platform runs on a second machine applied to a second instruction set architecture,
wherein the target and source platforms are of different types, and wherein the first and second instruction set architectures are distinct instruction set architectures and correspond to the respective different types of platforms,
…
- adjusting, based on a difference between function calling rules of the source platform and the target platform, parameters of the functions in the first code, to change storage of the parameters from a register to a stack, or from a stack to a register.
However, Shen discloses:
… wherein the first code is machine language applicable to the source platform, and wherein the source platform runs on a first machine applied to a first instruction set architecture (Page 51 Abstract “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones”; Page 52, “In this paper, we present an LLVM-based static binary translator, LLBT, which leverages the LLVM infrastructure and translates ARM-based binaries to many different ISAs supported by LLVM, such as ARM, X86-32, X86-64, and MIPS […wherein the first code is machine language applicable to the source platform, and wherein the source platform runs on a first machine applied to a first instruction set architecture]”);
…
… wherein the target platform runs on a second machine applied to a second instruction set architecture (Page 51 Abstract “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones”; Page 52, “In this paper, we present an LLVM-based static binary translator, LLBT, which leverages the LLVM infrastructure and translates ARM-based binaries to many different ISAs supported by LLVM, such as ARM, X86-32, X86-64, and MIPS [wherein the target platform runs on a second machine applied to a second instruction set architecture]”),
wherein the target and source platforms are of different types, and wherein the first and second instruction set architectures are distinct instruction set architectures and correspond to the respective different types of platforms (Page 51 Abstract “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones”; Page 52, “In this paper, we present an LLVM-based static binary translator, LLBT, which leverages the LLVM infrastructure and translates ARM-based binaries to many different ISAs supported by LLVM, such as ARM, X86-32, X86-64, and MIPS [wherein the target and source platforms are of different types, and wherein the first and second instruction set architectures are distinct instruction set architectures and correspond to the respective different types of platforms]”),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Shen into the teachings of Goebel to include “wherein the first code is machine language applicable to the source platform, and wherein the source platform runs on a first machine applied to a first instruction set architecture”, “wherein the target platform runs on a second machine applied to a second instruction set architecture”, and “wherein the target and source platforms are of different types, and wherein the first and second instruction set architectures are distinct instruction set architectures and correspond to the respective different types of platforms”. As stated in Shen, “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones” (Abstract). While binary code is directed towards a specific instruction set architecture, it may not run on other popular architectures. Binary translations allow code to be run more flexibly, without having the source code on hand. Translation by decompiling allows for more translation flexibility. Therefore, it would be obvious to one or ordinary skill in the art to combine code decompilation and relocation with binary translation to a different platform.
The combination of Goebel and Shen does not explicitly disclose:
wherein before the performing decompilation based on the plurality of logical addresses of the variables and the first code, the method further comprises:
- adjusting, based on a difference between function calling rules of the source platform and the target platform, parameters of the functions in the first code, to change storage of the parameters from a register to a stack, or from a stack to a register.
However, Emmerik discloses:
- adjusting, based on a difference between function calling rules of the source platform and the target platform, parameters of the functions in the first code, to change storage of the parameters from a register to a stack, or from a stack to a register (Page 62, “As Figure 1 shows, decoding and encoding work with a particular machine’s RTLs. The analysis phase elevates the level of representation from MS-RTLs (RTLs for a source machine), to HRTL, and then down to MT-RTLs (RTLs for a target machine). The analysis phase removes hardware dependencies from the source machine to generate good-quality code for the target machine. For example, rather than imposing a stack calling convention on a machine that prefers passing parameters in registers, we transform the code from stack- to register-based, thus using the target machine’s native conventions”) [Examiner’s remarks: Emmerik discloses converting register to stack or stack to register based on target machine native conventions. In combination of the optimization step of Goebel as described above which takes place before decompilation via conversion of variable addresses, the optimization of Emmerik may take place during the specified optimization step of Goebel.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Emmerik into the combined teachings of Goebel and Shen to include “adjusting, based on a difference between function calling rules of the source platform and the target platform, parameters of the functions in the first code, to change storage of the parameters from a register to a stack, or from a stack to a register”. As stated in Emmerik, “For example, rather than imposing a stack calling convention on a machine that prefers passing parameters in registers, we transform the code from stack- to register-based, thus using the target machine’s native conventions” (Page 62). Using a machine’s native calling conventions tailors the code to that machine, increasing efficiency and decreasing the change of error. Therefore, it would be obvious to one or ordinary skill in the art to combine code decompilation and relocation with changing the calling convention to conform to native conventions.
Regarding claim 7, the rejection of claim 1 is incorporated; and Goebel further discloses:
wherein the adjusting parameters of the functions in the first code based on a difference between function calling rules of the source platform and the target platform (Column 1, line 65 – Column 2, line 6, “The intermediate representation of the program generally references virtual registers. That is, the intermediate representation optimizer assumes that the target computer contains an unlimited number of registers. During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer. This resource management is performed in the code generator segment 107 by a register allocation (expansion) process”; Column 3, line 64 – Column 4, line 4, “The intermediate representation, generated by the binary disassembler mechanism, is processed by an intermediate representation normalization mechanism that is configured to remove an architectural related optimization that depends on the first ABI environment. The apparatus also includes an intermediate representation optimizer mechanism that is configured to optimize the intermediate representation for the second ABI environment” [adjusting parameters of the functions in the first code based on a difference between function calling rules of the source platform and the target platform]) comprises:
- adjusting one of register information or stack information of the functions in the first code based on the difference between the function calling rules of the source platform and the target platform (Column 1, line 65 – Column 2, line 6, “The intermediate representation of the program generally references virtual registers. That is, the intermediate representation optimizer assumes that the target computer contains an unlimited number of registers. During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer. This resource management is performed in the code generator segment 107 by a register allocation (expansion) process”; Column 3, line 64 – Column 4, line 4, “The intermediate representation, generated by the binary disassembler mechanism, is processed by an intermediate representation normalization mechanism that is configured to remove an architectural related optimization that depends on the first ABI environment. The apparatus also includes an intermediate representation optimizer mechanism that is configured to optimize the intermediate representation for the second ABI environment” [adjusting parameters of the functions in the first code based on a difference between function calling rules of the source platform and the target platform]) [Examiner’s Remarks: The register information of the function is adjusted based on the physical registers of the target computer.].
Regarding claim 23, the rejection of claim 1 is incorporated; and Goebel does not explicitly disclose:
- wherein the first instruction set architecture is one of an x86 instruction set architecture and an advanced reduced instruction set machine (ARM) architecture, while the second instruction set architecture is the other of the x86 instruction set architecture and the ARM architecture.
However, Shen discloses:
- wherein the first instruction set architecture is one of an x86 instruction set architecture and an advanced reduced instruction set machine (ARM) architecture, while the second instruction set architecture is the other of the x86 instruction set architecture and the ARM architecture (Page 51 Abstract “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones”; Page 52, “In this paper, we present an LLVM-based static binary translator, LLBT, which leverages the LLVM infrastructure and translates ARM-based binaries to many different ISAs supported by LLVM, such as ARM, X86-32, X86-64, and MIPS [wherein the first instruction set architecture is one of an x86 instruction set architecture and an advanced reduced instruction set machine (ARM) architecture, while the second instruction set architecture is the other of the x86 instruction set architecture and the ARM architecture]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Shen into the teachings of Goebel to include “wherein the first instruction set architecture is one of an x86 instruction set architecture and an advanced reduced instruction set machine (ARM) architecture, while the second instruction set architecture is the other of the x86 instruction set architecture and the ARM architecture”. As stated in Shen, “Lack of applications has always been a serious concern for designing machines with a new but incompatible ISA. To address this concern, binary translation is one common technique to migrate applications from one legacy ISA to new ones” (Abstract). While binary code is directed towards a specific instruction set architecture, it may not run on other popular architectures. Binary translations allow code to be run more flexibly, without having the source code on hand. Translation by decompiling allows for more translation flexibility. Therefore, it would be obvious to one or ordinary skill in the art to combine code decompilation and relocation with binary translation to a different platform.
Regarding claim 26, the rejection of claim 17 is incorporated; and the combination of Goebel and Shen does not explicitly disclose:
- adjusting one of register information or stack information of the functions in the first code based on the difference between the function calling rules of the source platform and the target platform.
However, Emmerik discloses:
- adjusting one of register information or stack information of the functions in the first code based on the difference between the function calling rules of the source platform and the target platform (Page 62, “As Figure 1 shows, decoding and encoding work with a particular machine’s RTLs. The analysis phase elevates the level of representation from MS-RTLs (RTLs for a source machine), to HRTL, and then down to MT-RTLs (RTLs for a target machine). The analysis phase removes hardware dependencies from the source machine to generate good-quality code for the target machine. For example, rather than imposing a stack calling convention on a machine that prefers passing parameters in registers, we transform the code from stack- to register-based, thus using the target machine’s native conventions”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Emmerik into the combined teachings of Goebel and Shen to include “adjusting one of register information or stack information of the functions in the first code based on the difference between the function calling rules of the source platform and the target platform”. As stated in Emmerik, “For example, rather than imposing a stack calling convention on a machine that prefers passing parameters in registers, we transform the code from stack- to register-based, thus using the target machine’s native conventions” (Page 62). Using a machine’s native calling conventions tailors the code to that machine, increasing efficiency and decreasing the change of error. Therefore, it would be obvious to one or ordinary skill in the art to combine code decompilation and relocation with changing the calling convention to conform to native conventions.
Claims 9, 15, and 24 are apparatus claims corresponding to the method claims hereinabove (claims 1, 7, and 23 respectively). Therefore, claims 9, 15, and 24 are rejected for the same reasons as set forth in the rejection of claims 1, 7, and 23 respectively.
Claims 17 and 25 are computer-readable storage medium claims corresponding to the method claims hereinabove (claims 1 and 23 respectively). Therefore, claims 17 and 25 are rejected for the same reasons as set forth in the rejection of claims 1 and 23 respectively.
Claims 2-3, 10-11, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 6289505 B1 (hereinafter “Goebel”), in view of “LLBT: An LLVM-based Static Binary Translator” by Shen et. al, (hereinafter “Shen”), further in view of “UQBT: Adaptable Binary Translation at Low Cost” by Cifuentes and Emmerik (hereinafter “Emmerik”) (Examiner’s remarks: The second author is used to refer to Emmerik to avoid confusion with Cifuentes references cited in previous office actions and in following rejections), and further in view of “Reverse Compilation Techniques” by Cristina Cifuentes (hereinafter “Cifuentes”).
Regarding claim 2, the rejection of claim 1 is incorporated; and Goebel further discloses:
wherein the performing decompilation based on the plurality of logical addresses of the variables and the first code, to obtain second code applicable to a target platform (Column 2, lines 2-6, “During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer [performing decompilation based on the plurality of logical addresses of the variables]”; Column 3, lines 47-54, “The method includes the step of converting the first executable binary executable to an intermediate representation. Then the intermediate representation is processed to remove an architectural related optimization that depends on the first ABI environment. The method also includes the steps of optimizing the intermediate representation for the second ABI environment and of generating the second binary executable [and the first code, to obtain second code applicable to a target platform]”) comprises:
- performing decompilation based on the plurality of logical addresses of the variables and the first code, to obtain a compiler intermediate representation related to the target platform (Column 2, lines 2-6, “During the operation of the code generator segment 107, these virtual registers are assigned to the physical registers of the target computer [performing decompilation based on the plurality of logical addresses of the variables]”; Column 3, lines 47-54, “The method includes the step of converting the first executable binary executable to an intermediate representation. Then the intermediate representation is processed to remove an architectural related optimization that depends on the first ABI environment. The method also includes the steps of optimizing the intermediate representation for the second ABI environment and of generating the second binary executable [and the first code, to obtain a compiler intermediate representation related to the target platform]”), …; and
- generating the second code applicable to the target platform based on the compiler intermediate representation (Column 4, lines 4-8, “In addition, the apparatus includes a code generation mechanism that is configured to generate the second binary executable by using the intermediate representation that is optimized for the second ABI environment [generating the second code applicable to the target platform based on the compiler intermediate representation]”).
The combination of Goebel, Shen, and Emmerik does not explicitly disclose:
- …wherein the compiler intermediate representation comprises definitions of the variables, and the definitions of the variables associate symbols of the variables with the plurality of logical addresses…
However, Cifuentes discloses:
- …wherein the compiler intermediate representation comprises definitions of the variables, and the definitions of the variables associate symbols of the variables with the plurality of logical addresses (Page 40, “…let us assume the following data items are to be placed in the symbol table: cs:01F8; global variable, bp + 4; parameter, bp-6; local variable… [wherein the compiler intermediate representation comprises definitions of the variables and the definitions of the variables associate symbols of the variables with the plurality of logical addresses]”) [Examiner’s Remarks: The intermediate representation contains a symbol table with a plurality of variables (parameter and local variable) and corresponding logical addresses (bp+4 and bp-6).]…
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Cifuentes into the combined teachings of Goebel, Shen, and Emmerik to include “wherein the compiler intermediate representation comprises definitions of the variables, and the definitions of the variables associate symbols of the variables with the plurality of logical addresses”. As stated in Cifuentes, “Assembly programs have helpful data information in the form of symbolic text, such as data segments, data and type declarations, subroutine names, subroutine entry point, and subroutine exit statement. All this information can be collected in a symbol table and then the decompiler would not need to address the problem of separating data from instructions, or the naming of variables and subroutines” (Page 17). Symbol tables provide information on efficient code entry and are used to handle and track a variety of variables. Using symbol tables makes it easier to track variable types and code segments for the purposes of decompilation, since this information is hard to retrieve from machine code. Thus, it would be obvious to one of ordinary skill in the art of code decompiling to combine code decompilation with usage of a symbol table.
Regarding claim 3, the rejection of claim 2 is incorporated; and the combination of Goebel, Shen and Emmerik does not explicitly disclose:
- wherein the compiler intermediate representation comprises a first variable and a second variable, the first variable has a first logical address, the second variable has a second logical address, and the first logical address is different from the second logical address.
However, Cifuentes discloses:
- wherein the compiler intermediate representation comprises a first variable and a second variable, the first variable has a first logical address, the second variable has a second logical address, and the first logical address is different from the second logical address (Page 90, “Instruction 3 defines register ax by copying the contents of the integer register variable si. Register variables are treated as local variables rather than registers in this context. Instruction 4 uses register ax to define register dx by sign extension of register ax. Instruction 5 then uses these sign-extended registers to copy them to register tmp, which is used in instruction 6 as the dividend of a divide instruction [wherein the compiler intermediate representation comprises a first variable and a second variable, the first variable has a first logical address, the second variable has a second logical address, and the first logical address is different from the second logical address]”) [Examiner’s Remarks: Cifuentes discloses a plurality of registers as variables, that also serve as addresses for the purposes of memory allocation.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Cifuentes into the combined teachings of Goebel, Shen, and Emmerik to include “wherein the compiler intermediate representation comprises a first variable and a second variable, the first variable has a first logical address, the second variable has a second logical address, and the first logical address is different from the second logical address”. As noted in Cifuentes, “Since register variables are used by compilers for efficiency purposes…” (page 40). Variables are a symbolic representation of abstract storage locations and are generally used in programming to make it easier for programmers to reference a memory location. Variable usage makes it easier to both read and write programs. Programs typically reference more than one memory location, necessitating the usage of multiple variables representing different memory addresses. Thus, it would be obvious to one of ordinary skill in the art of code decompiling to combine code decompilation with variable usage.
Claims 10-11 are apparatus claims corresponding to the method claims hereinabove (claims 2-3 respectively). Therefore, claims 10-11 are rejected for the same reasons as set forth in the rejection of claims 2-3 respectively.
Claims 18-19 are computer-readable storage medium claims corresponding to the method claims hereinabove (claims 2-3 respectively). Therefore, claims 18-19 are rejected for the same reasons as set forth in the rejection of claims 2-3 respectively.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US 6289505 B1 (hereinafter “Goebel”), in view of “LLBT: An LLVM-based Static Binary Translator” by Shen et. al, (hereinafter “Shen”), further in view of “UQBT: Adaptable Binary Translation at Low Cost” by Cifuentes and Emmerik (hereinafter “Emmerik”) (Examiner’s remarks: The second author is used to refer to Emmerik to avoid confusion with Cifuentes references cited in previous office actions and in following rejections), and further in view of “Ghidra – A quick start guide with pictures and a C++ example” by James Tate (hereinafter “Tate”).
Regarding claim 8, the rejection of claim 1 is incorporated; and the combination of Goebel, Shen, and Emmerik does not explicitly disclose:
- receiving the first code input by a user through a graphical user interface.
However, Tate discloses:
- receiving the first code input by a user through a graphical user interface (Page 3, under heading “Binary example”, “To view the binary in Ghidra simply press the hotkey “I” or go to File [Wingdings font/0xE0] Import and choose the file. Ghidra should recognize the file as an .elf for x86 64 bit processor. Click through the next couple of popup windows choosing the default selections for now and eventually you will see the disassembly [receiving the first code input by a user through a graphical user interface]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Tate into the combined teachings of Goebel, Shen, and Emmerik to include “receiving the first code input by a user through a graphical user interface”. As noted in Tate, using a GUI allows users to input and view code throughout the decompilation process (page 3 and figures). The ability to see and interact with the process makes code decompilation easier and more accessible, even for users with less programming knowledge. Thus, it would be obvious to one of ordinary skill in the art of code decompilation to combine the capability for code decompilation with a GUI for code input.
Claim 16 is a computing apparatus claim corresponding to the method claim hereinabove (claim 8). Therefore, claim 16 is rejected for the same reasons as set forth in the rejections of claim 8.
Claims 27-29 are rejected under 35 U.S.C. 103 as being unpatentable over US 6289505 B1 (hereinafter “Goebel”), in view of “LLBT: An LLVM-based Static Binary Translator” by Shen et. al, (hereinafter “Shen”), further in view of “UQBT: Adaptable Binary Translation at Low Cost” by Cifuentes and Emmerik (hereinafter “Emmerik”) (Examiner’s remarks: The second author is used to refer to Emmerik to avoid confusion with Cifuentes references cited in previous office actions and in following rejections), and further in view of “Reverse Compilation Techniques” by Cristina Cifuentes (hereinafter “Cifuentes”), and further in view of “Understanding the x64 Code Models” by Eli Bendersky (hereinafter “Bendersky”).
Regarding claim 27, the rejection of claim 1 is incorporated, and the combination of Goebel, Shen, and Emmerik does not explicitly disclose:
obtaining a relocation table from the first code, wherein the relocation table stores the plurality of logical addresses of the variables;
determining relocation types based on types of the variables associated with the functions in the first code and associated compilation options, wherein the compilation option is used to indicate a compilation manner; and
relocating, based on the relocation table, the addresses of the variables associated with the functions in the first code.
However, Cifuentes discloses:
obtaining a relocation table from the first code, wherein the relocation table stores the plurality of logical addresses of the variables (Page 13, “In general, source binary programs have a relocation table of addresses that are to be relocated when the program is loaded into memory [obtaining a relocation table from the first code]”; Page 182, “Most binary programs contain not only the binary image, but also header information to determine the type of binary program (i.e. there can be different types of executable programs for the same operating system, or for different operating systems that run on the same machine) and initial register values, and a relocation table that holds word offsets from the start of the binary image which need to be relocated according to the address were the program is loaded into memory [wherein the relocation table stores the plurality of logical addresses of the variables]”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Cifuentes into the combined teachings of Goebel, Shen, and Emmerik to include “obtaining a relocation table from the first code, wherein the relocation table stores the plurality of logical addresses of the variables”. As noted in Cifuentes, “Most binary programs contain not only the binary image…and a relocation table that holds word offsets from the start of the binary image which need to be relocated according the address were the program is loaded into memory” (page 182). Relocation tables are used to relocate memory addresses when programs are loaded into memory. The location of code when it is loaded in differs based on the machine and the available memory blocks. Relocation tables with relative addressing allows code to be loaded on different machines and in different memory location on the machine, making memory allocation simpler for programmers. Thus, it would be obvious to one of ordinary skill in the art of code decompiling to combine code decompilation with variable relocation using a relocation table.
The combination of Goebel, Shen, Emmerik, and Cifuentes does not explicitly disclose:
determining relocation types based on types of the variables associated with the functions in the first code and associated compilation options, wherein the compilation option is used to indicate a compilation manner; and
relocating, based on the relocation table, the addresses of the variables associated with the functions in the first code.
However, Bendersky discloses:
determining relocation types based on types of the variables associated with the functions in the first code and associated compilation options, wherein the compilation option is used to indicate a compilation manner (Page 8, paragraph 2, “Let us now turn to the code models for PIC, starting once again with the small model. Here's the sample code, compiled with PIC and the small code model [and associated compilation options, wherein the compilation option is used to indicate a compilation manner]”; Page 8, Paragraph 4, “Since the small vs. big data distinction plays no role in the small model, we're going to focus on the difference between local (static) and global symbols, which does play a role when PIC is generated [based on the types of the variables associated with the functions in the first code]”; Page 9, Paragraph 2, “The interesting case here is the global arrays. Recall that in PIC, global data has to go through GOT, because it may be eventually found or used in other shared libraries”; Page 9, paragraph 3, “And the relevant relocation is a R_X86_64_GOTPCREL… [determining relocation types]”); and
relocating, based on the relocation table, the addresses of the variables associated with the functions in the first code (Page 3, see attached figure below, The figure shows a relocation table with relevant offsets, relocation types, symbol values, and addend for relocation.; Page 4, Paragraph 1, “RIP-relative addressing is relative to the next instruction. So the offset that should be patched into the mov instruction should be relative to 0x3c. The relevant relocation is the second one, pointing to the operand of mov at 0x38. It's R_X86_64_PC32 , which means: take the symbol value, add the addend and subtract the offset this relocation points to. If you do the math you see this ends up placing the relative offset between the next instruction and global_arr , plus 0x1c. This relative offset is just what we need, since 0x1c simply means "the 7th int in the array" (each int is 4 bytes long on x64). So the instruction correctly references global_arr[7] using RIP relative addressing [relocating, based on the relocation table, the addresses of the variables associated with the functions in the first code]”) [Examiner’s remarks: Bendersky discloses using relocation type (in this case R_X86_64_PC32) to calculate a variable address for relocation. Values for calculation are derived from the relocation table. A person of ordinary skill in the art understands that the same process may be applied to variables in the first code.].
PNG
media_image1.png
157
741
media_image1.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Bendersky into the combined teachings of Goebel, Shen, Emmerik, and Cifuentes to include “determining relocation types based on types of the variables associated with the functions in the first code and associated compilation options, wherein the compilation option is used to indicate a compilation manner” and “relocating, based on the relocation table, the addresses of the variables associated with the functions in the first code”. As stated in Bendersky, “References to both code and data on x64 are done with instruction-relative (RIP-relative in x64 parlance) addressing modes. The offset from RIP in these instructions is limited to 32 bits. …Then, a case can arise when an instruction attempting to address some piece of code (or data) just can't do it with its 32-bit offset from RIP” (Page 1, paragraph 4). Relocation tables record information on how the relative addressing of a variable is performed. Taking into account variable type and compilation model information allows for more flexible addressing when compiling and decompiling, and allows for tracking larger instruction sets. Relocation type gives information regarding how a particular address should be relocated. Thus, it would be obvious to one of ordinary skill in the art of code decompiling to combine code decompilation with usage of relocation types, tables, and compilation options.
Claim 28 is an apparatus claim corresponding to the method claim hereinabove (claim 27). Therefore, claim 28 is rejected for the same reasons as set forth in the rejection of claim 27.
Claim 29 is a computer-readable storage medium claim corresponding to the method claim hereinabove (claim 27). Therefore, claim 29 is rejected for the same reasons as set forth in the rejection of claim 27.
Response to Arguments
Applicant’s arguments with respect to claims 1, 9, and 17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191