DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s arguments and amendment dated March 19, 2026. Claims 19-22, 24, 26-32, 34, 36-38, 40-42, and 44-46 are currently amended and claims 19-46 remain pending in the application and have been fully considered by Examiner.
In view of Applicant’s amendments, the claim objections and 35 USC 112(b) rejections presented in the Non-Final Office action are withdrawn.
Applicant's arguments with respect to the prior art rejections have been considered, but are not persuasive, as detailed below in the Prior Art Argument - Rejections section.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Objections
Claim 22 is objected to because of the following informality: lines 3-4 recite “the intermediate representation”, which appears to be a typographical error that should recite the non-executable intermediate representation.”
Appropriate correction is required.
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 19, 20, 21, 23, 24, 27, 28, 29, 30, 31, 33, 34, 37, 38, 39, and 43, are rejected under 35 U.S.C. 103 as being unpatentable over Thorell (US 20080148060, hereinafter Thorell) in view of Bothner (US 6110226, hereinafter Bothner).
With respect to claim 19, Thorell discloses A computing system (e.g., Fig. 1), comprising:
a software development device comprising one or more processors (e.g., Fig. 1 and associated text, e.g., [0016], a central software development system 10 [software development device]; [0034] The code authenticator 12, code processor 24 and/or code scanner 28 included in … the central software development system 10 described herein may comprise one or more microprocessors.); and
one or more computing devices each comprising one or more processors (e.g., Fig. 1 and associated text, e.g., [0018] The central system 10 may generate program code designed for various types of devices 14 such as computers [one or more computing devices].); wherein:
the software development device (e.g., [0016], a central software development system 10.) is configured to perform operations comprising:
compiling a source code of an application program to generate a non-executable intermediate representation (e.g., Figs. 1-5 and associated text, e.g., [0016], central software development system 10 [software development device] … source code is returned to the central system 10 for compilation into program code [intermediate representation] … the term `program code` is … code that requires a final compilation or interpretation step before it can be executed (bytecode) [non-executable intermediate representation]; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code [non-executable intermediate representation]; see also [0023].),
issuing a digital certificate for the non-executable intermediate representation (e.g., Figs. 1-2 and 4-5 along with associated text, e.g., [0017], Program code [non-executable intermediate representation] generated by the central system 10 is signed by a code authenticator 12 included in … the system 10 for indicating authenticity of the program code; [0027], A message builder 44 constructs a composite message containing the program code, the digital signature, and optional information such as a header and/or digital certificate identifying the encryption key used to sign the program code; see also [0016] and [0033].);
the non-executable intermediate representation is transferrable to any of the one or more computing devices (e.g., Fig. 1 and 4-5 along with associated text, e.g., [0022], Program code is made available for download to each device 14 for which the code was designed; see also [0016] and [0033].);
a first computing device of the one or more computing devices (e.g., Fig. 1, particularly, Remote Device 14.) is configured to perform operations comprising:
receiving the non-executable intermediate representation and the digital certificate (e.g., Figs. 1-2 and 4-5 along with associated text, e.g., [0027], A message builder 44 constructs a composite message containing the program code, the digital signature, and optional information such as a header and/or digital certificate identifying the encryption key used to sign the program code. The message is provided either directly or indirectly to each device 14 for which the code is designed; see also [0016] and [0033].),
authenticating the non-executable intermediate representation based on the digital certificate (e.g., Figs. 1-2 and 4-5 along with associated text, e.g., [0023], a code validator 34 included in the device 14 determines … whether the signature is recognized … If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code; [0027], A code validator 34 included in each target device 14 verifies whether the signature associated with the program code is recognized … if a digital certificate is provided with the program code and corresponding signature as part of a received message, the code validator 34 may compare the program code signature to a signature included in the digital certificate; see also [0016] and [0033].); and
converting the non-executable intermediate representation to generate a code (e.g., Fig. 1 and 4-5 along with associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling [converting]… bytecode [non-executable intermediate representation] and then executing the resulting code [code]; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time.).
Although Thorell discloses a non-executable intermediate representation and converting the non-executable intermediate representation (see above), it does not appear to explicitly disclose conforming to a predetermined execution environment without depending on computer architecture of a distribution destination or machine … prior to executing the machine code. However, in analogous art, Bothner teaches conforming to a predetermined execution environment without depending on computer architecture of a distribution destination (e.g., Figs. 5 and 7 along with associated text, e.g., col. 1:39-50, the Java programming language has emerged, holding the promise of “write-once, run anywhere” … machine-independent byte-code instructions; col. 3:28-39, The solution is Java-based, providing machine independence … the system software may include, in addition to the pre-compiled Java code, a Java Virtual Machine [predetermined execution environment], allowing Java bytecode [intermediate representation] to be downloaded and run; claim 1, an intermediate form in which code is represented in terms of machine-independent code instructions.) and to generate a machine code prior to executing the machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 3:42-44, the optimizing ahead-of-time Java compiler is capable of compiling … Java bytecode; col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner, such that bytecode is compiled ahead of time into machine code, because such code is “efficient” and has “comparable size and speed as code written in C/C++” while “the “compatibility with the Java world is afforded,” as suggested by Bothner (see col. 8:30 and col. 3:31-34).
With respect to claim 29, Thorell discloses An information processing method in a computing system comprising a software development device and one or more computing devices (e.g., Fig. 1 and associated text, e.g., [0016], a central software development system 10 [software development device]; [0018] The central system 10 may generate program code designed for various types of devices 14 such as computers [one or more computing devices].), the method comprising:
compiling, at the software development device, a source code of an application program to generate a non-executable intermediate representation ;
issuing, at the software development device, a digital certificate for the non-executable intermediate representation, wherein the non-executable intermediate representation is transferrable to any of the one or more computing devices (e.g., Figs. 1-2 and associated text, e.g., [0017], Program code [non-executable intermediate representation] generated by the central system 10 [software development device] is signed by a code authenticator 12 included in … the system 10 for indicating authenticity of the program code; [0027], A message builder 44 constructs a composite message containing the program code, the digital signature, and optional information such as a header and/or digital certificate identifying the encryption key used to sign the program code; see also [0016] and [0033].);
receiving, at a first computing device of the one or more computing devices, the non-executable intermediate representation and the digital certificate (e.g., Figs. 1-2 and associated text, e.g., [0027], A message builder 44 constructs a composite message containing the program code, the digital signature, and optional information such as a header and/or digital certificate identifying the encryption key used to sign the program code. The message is provided either directly or indirectly to each device 14 [first computing device] for which the code is designed; see also [0016 and [0033].);
authenticating, at the first computing device, the non-executable intermediate representation based on the digital certificate (e.g., Figs. 1-2 and 4-5 along with associated text, e.g., [0023], a code validator 34 included in the device 14 [first computing device] determines … whether the signature is recognized … If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code; [0027], A code validator 34 included in each target device 14 verifies whether the signature associated with the program code is recognized … if a digital certificate is provided with the program code and corresponding signature as part of a received message, the code validator 34 may compare the program code signature to a signature included in the digital certificate; see also [0016] and [0033].); and
converting the non-executable intermediate representation into a code .
Although Thorell discloses a non-executable intermediate representation and converting the non-executable intermediate representation (see above), it does not appear to explicitly disclose conforming to a predetermined execution environment without depending on computer architecture of a distribution destination or machine … prior to executing the machine code. However, in analogous art, Bothner teaches conforming to a predetermined execution environment without depending on computer architecture of a distribution destination (e.g., Figs. 5 and 7 along with associated text, e.g., col. 1:39-50, the Java programming language has emerged, holding the promise of “write-once, run anywhere” … machine-independent byte-code instructions; col. 3:28-39, The solution is Java-based, providing machine independence … the system software may include, in addition to the pre-compiled Java code, a Java Virtual Machine [predetermined execution environment], allowing Java bytecode [intermediate representation] to be downloaded and run; claim 1, an intermediate form in which code is represented in terms of machine-independent code instructions.) and into a machine code prior to executing the machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 3:42-44, the optimizing ahead-of-time Java compiler is capable of compiling … Java bytecode; col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner, such that bytecode is compiled ahead of time into machine code, because such code is “efficient” and has “comparable size and speed as code written in C/C++” while “the “compatibility with the Java world is afforded,” as suggested by Bothner (see col. 8:30 and col. 3:31-34).
With respect to claims 20 and 30, Bothner further teaches wherein the converting the non-executable intermediate representation into the machine code comprises converting the non-executable intermediate representation into the machine code to match the computer architecture of the distribution destination (e.g., Figs. 5 and 7 along with associated text, e.g., col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code; col. 7:35-36, which generates machine-specific RTL representing the machine instructions; claim 1, pre-compiling code … for a specific machine using an optimizing ahead-of-time compiler, producing pre-compiled code; claim 3 … precompiled from said machine-independent code instructions.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
With respect to claims 21 and 31, Thorell also discloses wherein the converting the non-executable intermediate representation is performed after the authenticating the non-executable intermediate representation (e.g., Figs. Figs. 1-2 and 4-5 along with associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling [converting] … bytecode [non-executable intermediate representation] and then executing the resulting code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling [converting] bytecode [non-executable intermediate representation] into executable code in real-time.).
With respect to claim 23, Thorell also discloses wherein the operations of the first computing device further comprise executing thecode (e.g., Fig. 1 and associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code; [0033], Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time.) and Bothner further teaches machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
With respect to claim 33, Thorell also discloses executing, at the first computing device, thecode e.g., Fig. 1 and associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code; [0033], Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time.) and Bothner further teaches machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
With respect to claim 24, Thorell also discloses wherein the software development device comprises a first compiler that compiles the source code to generate the non-executable intermediate representation (e.g., Figs. 1-5 and associated text, e.g., [0020], The code processor 24 included in … the central system 10 compiles the modified source code into program code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code; [0016], the term `program code` is … code that requires a final compilation or interpretation step before it can be executed (bytecode).); and wherein the first computing device comprises a second compiler that converts the non-executable intermediate representation to generate the code (e.g., Figs. 1 and 4-5 along with associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling [convert] bytecode [non-executable intermediate representation] into executable code in real-time.) and Bothner further teaches machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
With respect to claim 34, Thorell also discloses wherein: the compiling the source code to generate the non-executable intermediate representation is performed by a first compiler of the software development device (e.g., Figs. 1-5 and associated text, e.g., [0020], The code processor 24 included in … the central system 10 compiles the modified source code into program code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code; [0016], the term `program code` is … code that requires a final compilation or interpretation step before it can be executed (bytecode).), and the converting the non-executable intermediate representation to generate the code is performed by a second compiler of the first computing device (e.g., Fig. 1 and associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code; [0033], Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time.) and Bothner further teaches machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
With respect to claim 27, Thorell also discloses wherein the first computing device comprises a system program comprising a function for authenticating the non-executable intermediate representation (e.g., Figs. 1-2 and associated text, e.g., [0023], a code validator 34 included in the device 14 [first computing device] determines … whether the signature is recognized … If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code; [0027], A code validator 34 included in each target device 14 verifies whether the signature associated with the program code is recognized … if a digital certificate is provided with the program code and corresponding signature as part of a received message, the code validator 34 may compare the program code signature to a signature included in the digital certificate; see also [0016] and [0033].).
With respect to claim 37, Thorell also discloses wherein the authenticating the non-executable intermediate representation is performed by a system program of the first computing device (e.g., Figs. 1-2 and associated text, e.g., [0023], a code validator 34 included in the device 14 [first computing device] determines … whether the signature is recognized … If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code; [0027], A code validator 34 included in each target device 14 verifies whether the signature associated with the program code is recognized … if a digital certificate is provided with the program code and corresponding signature as part of a received message, the code validator 34 may compare the program code signature to a signature included in the digital certificate; see also [0016] and [0033].).
With respect to claims 28 and 38, Thorell also discloses wherein the digital certificate is prepared by at least one of the software development device or an entity that provides the non-executable intermediate representation (e.g., Figs. 1-2 and associated text, e.g., [0017], Program code generated by the central system 10 [software development device] is signed by a code authenticator 12 included in … the system 10 for indicating authenticity of the program code; [0025] FIG. 2 illustrates an embodiment of the code authenticator 12 included in … the central system 10; [0027], A message builder 44 constructs a composite message containing the program code, the digital signature, and optional information such as a header and/or digital certificate identifying the encryption key used to sign the program code; see also [0016] and [0033].).
With respect to claims 39 and 43, Bothner further teaches wherein the predetermined execution environment comprises an execution environment of a virtual processor (e.g., Figs. 5 and 7 along with associated text, e.g., col. 1:39-50, the Java programming language has emerged, holding the promise of “write-once, run anywhere” … machine-independent byte-code instructions; col. 3:28-38, The solution is Java-based, providing machine independence … the system software may include, in addition to the pre-compiled Java code, a Java Virtual Machine [predetermined execution environment comprises an execution environment of a virtual processor], allowing Java bytecode to be downloaded and run.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
Claims 22, 26, 32, 36, 42, and 46 are rejected under 35 U.S.C. 103 as being unpatentable over Thorell in view of Bothner, as applied to claims 19, 21, 24, 29, 31, and 34 above, and further in view of Anonymous, “LLVM Language Reference Manual” (hereinafter LLVM).
With respect to claims 22 and 32, Thorell also teaches wherein the converting the non-executable intermediate representation (e.g., Fig. 1 and 4-5 along with associated text, e.g., [0023], If the signature is successfully authenticated, a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time.).
Although Thorell in view of Bothner discloses converting the non-executable intermediate representation (see above), it does not appear to disclose that this comprises reflecting a hardware configuration of the first computing device in the intermediate representation. However, this is taught in analogous art, LLVM (e.g., p. 52, top para., There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications; p. 52 § Target Triple, A module may specify a target triple string that describes the target host. The syntax for the target triple is simply: target triple = "x86_64-apple-macosx10.7.0" … This information is passed along to the backend so that it generates code for the proper architecture.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of LLVM, such that target specific hardware configuration details are reflected in the intermediate representation, because it can “improve code” and ensure that the compiler will generate “code for the proper architecture,” as suggested by LLVM (see p. 52, top para. and § Target Triple).
With respect to claim 26, Bothner further teaches wherein the non-executable intermediate representation generation of the machine code by the second compiler (e.g., Figs. 5 and 7 along with associated text, e.g., col. 3:42-44, the optimizing ahead-of-time Java compiler is capable of compiling … Java bytecode; col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
Although Thorell as modified by Bothner discloses a second compiler that compiles non-executable intermediate code to generate machine code (see above), it does not appear to disclose that the non-executable intermediate representation comprises auxiliary information for assisting generation of the machine code. However, this is taught in analogous art, LLVM (e.g., p. 52, top para., There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications; p. 52 § Target Triple, A module may specify a target triple string that describes the target host. The syntax for the target triple is simply: target triple = "x86_64-apple-macosx10.7.0" … This information is passed along to the backend so that it generates code for the proper architecture.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of LLVM, such that target specific hardware configuration details are reflected in the intermediate representation, because it can “improve code” and ensure that the compiler will generate “code for the proper architecture,” as suggested by LLVM (see p. 52, top para. and § Target Triple).
With respect to claim 36, Bothner further teaches wherein the non-executable intermediate representation generation of the machine code (e.g., Figs. 5 and 7 along with associated text, e.g., col. 3:42-44, the optimizing ahead-of-time Java compiler is capable of compiling … Java bytecode; col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
Although Thorell as modified by Bothner discloses compiling non-executable intermediate code to generate machine code (see above), it does not appear to disclose that the intermediate representation comprises auxiliary information for assisting generation of the machine code. However, this is taught in analogous art, LLVM (e.g., p. 52, top para., There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications; p. 52 § Target Triple, A module may specify a target triple string that describes the target host. The syntax for the target triple is simply: target triple = "x86_64-apple-macosx10.7.0" … This information is passed along to the backend so that it generates code for the proper architecture.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of LLVM, such that target specific hardware configuration details are reflected in the intermediate representation, because it can “improve code” and ensure that the compiler will generate “code for the proper architecture,” as suggested by LLVM (see p. 52, top para. and § Target Triple).
With respect to claims 42 and 46, Thorell also discloses wherein the converting the non-executable intermediate representation into the code comprises converting the non-executable intermediate representation into the code ;
wherein the software development device comprises a first compiler that compiles the source code to generate the non-executable intermediate representation (e.g., Figs. 1-5 and associated text, e.g., [0020], The code processor 24 included in … the central system 10 compiles the modified source code into program code; [0033], The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling bytecode into executable code in real-time; [0016], the term `program code` is … code that requires a final compilation or interpretation step before it can be executed (bytecode).); and
wherein the first computing device comprises a second compiler that converts the non-executable intermediate representation to generate thecode, wherein the second compiler is configured to generate thecode and Bothner further teaches machine … machine … to match the computer architecture of the distribution destination … machine … machine (e.g., Figs. 5 and 7 along with associated text, e.g., col. 4:36-37, compiling byte code using a byte code to machine code compiler 519; col. 8:27-30, An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code; col. 7:35-36, which generates machine-specific RTL representing the machine instructions; claim 1, pre-compiling code … for a specific machine using an optimizing ahead-of-time compiler, producing pre-compiled code; claim 3 … precompiled from said machine-independent code instructions.).
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 invention of Thorell with the invention of Bothner for the same reason set forth above.
Although Bothner discloses generating machine code (see above), it does not appear to disclose by reflecting a hardware configuration of the first computing device in one or more instructions included in the non-executable intermediate representation. However, this is taught in analogous art, LLVM (e.g., p. 52, top para., There is no way to generate IR [intermediate representation] that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications; p. 52 § Target Triple, A module may specify a target triple string that describes the target host. The syntax for the target triple is simply: target triple = "x86_64-apple-macosx10.7.0" … This information is passed along to the backend so that it generates code for the proper architecture.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of LLVM, such that target specific hardware configuration details are reflected in the intermediate representation, because it can “improve code” and ensure that the compiler will generate “code for the proper architecture,” as suggested by LLVM (see p. 52, top para. and § Target Triple).
Claims 25 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Thorell in view of Bothner, as applied to claims 24 and 34 above, and further in view of Stephenson et al. (US 7120906, hereinafter Stephenson).
With respect to clams 25, Thorell also discloses wherein the second compiler comprises the second compiler (e.g., e.g., Fig. 1 and associated text, e.g., [0023], a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code.).
Thorell does not appear to disclose a management module for updating data referenced by. However, this is taught in analogous art, Stephenson (e.g., Figs. 1-3E and associated text, e.g., col. 2:62-17, within an optimizing compiler, accessing a first intermediate representation of the source code of a computer program … The feedback data is then updated … ultimately allows the compiler to produce more efficient executable program code from the first intermediate representation; col. 13:5-6, the present invention may be implemented in any compiler running on any machine.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of Stephenson, such that the compiler updates feedback data to generate executable code, because it “ultimately allows the compiler to produce more efficient executable program code from the first intermediate representation, thus speeding up the execution of the computer program,” as suggested by Stephenson (see col. 3:15-18).
With respect to claim 35, Thorell also discloses , at the second compiler of the first computing device, the second compiler (e.g., e.g., Fig. 1 and associated text, e.g., [0023], a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code.).
Thorell does not appear to disclose updating … data referenced by. However, this is taught in analogous art, Stephenson (e.g., Figs. 1-3E and associated text, e.g., col. 2:62-17, within an optimizing compiler, accessing a first intermediate representation of the source code of a computer program … The feedback data is then updated … ultimately allows the compiler to produce more efficient executable program code from the first intermediate representation; col. 13:5-6, the present invention may be implemented in any compiler running on any machine.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of Stephenson, such that the compiler updates feedback data to generate executable code, because it “ultimately allows the compiler to produce more efficient executable program code from the first intermediate representation, thus speeding up the execution of the computer program,” as suggested by Stephenson (see col. 3:15-18).
Claims 40 and 44 are rejected under 35 U.S.C. 103 as being unpatentable over Thorell in view of Bothner, as applied to claims 39 and 43 above, and further in view of Colton et al. (US 20060253508, hereinafter Colton).
With respect to claims 40 and 44, Thorell also discloses wherein the non-executable intermediate representation comprises an arbitrary application program
Thorell does not appear to disclose in an integrated development environment. However, this is taught in analogous art, Colton (e.g., Fig. 25 and associated text, e.g., [0136], developing source code … in an integrated development environment and producing target byte code … Java source code 302 can be compiled in Eclipse into Java byte code 202. In step 2504, if further development is needed for the native application of a first type (comprising first byte code 202…) under development, a developer or an automated IDE process can take further development steps 2506, such as building, launching, testing, and debugging the application; [0139], when a developer invokes a preview command in the IDE … at least some portion of the compiled byte code 202 … is displayed.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of Colton, such that an IDE is used to develop and test application source code and intermediate code, because “such testing reveals errors or areas for improvement that can be addressed … [and] a developer can enhance the original source code,” as suggested by Colton (see [0136]).
Claims 41 and 45 are rejected under 35 U.S.C. 103 as being unpatentable over Thorell in view of Bothner, as applied to claims 19 and 29 above, and further in view of Anonymous, “Introduction to WebAssembly” (hereinafter Anonymous).
With respect to claims 41 and 45, Thorell in view of Bothner does not appear to disclose wherein the non-executable intermediate representation comprises: a type section, an import section, a function section, an export section, a start section, a code section, and a data section. However, this is taught in analogous art, Anonymous (p. 2, 1st para., WASM aims at a low level-of abstraction suitable as an intermediate representation of a higher-level program; p. 3, 2nd para., The standard sections in WASM version 1 are as follows … Type … Import … Function … Export … Start … Code … Data.; p. 17, § WASM as Intermediate Representation, WebAssembly might be an excellent IR (Intermediate Representation) for compilers of all sorts … WASM can be translated to machine code.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Thorell with the invention of Thorell, such that the intermediate representation is WebAssembly, because “WebAssembly might be an excellent IR (Intermediate Representation) for compilers of all sorts” for several reasons such as “WebAssembly really has no dependencies on anything ‘web’ and its module and bytecode format is at such a low level that it can be used to represent any other higher-level program,” as suggested by Anonymous (see p. 17, § WASM as Intermediate Representation).
Prior Art Arguments – Rejections
Applicant’s arguments with respect to the prior art rejections have been fully considered by Examiner but they are not persuasive, as follows:
With respect to claims 1 and 29, Applicant primarily argues that “Thorell merely discloses a ‘just-in-time compiler’ for compiling bytecode into executable code in real-time (See paragraph [0033] of Thorell), and fails to teach or suggest the claimed ‘converting the non-executable intermediate representation to generate a machine code prior to executing the machine code’” because “The second embodiment of Thorell and Bothner merely focus on ‘bytecode” and “It is obvious to one of ordinary skill in the art that ‘bytecode’ is executable under a virtual machine ... Therefore, Thorell and/or Bothner fail to teach or suggest the claimed ‘non-executable intermediate representation’”1 (emphasis added). Examiner respectfully disagrees for two reasons.
First, Thorell makes no mention of a virtual machine and instead states, with emphasis added, “The bytecode must be finally compiled before it can execute, and thus, is intermediate code. Typically, a just-in-time compiler is used for compiling bytecode into executable code”2 (emphasis added). Thus, the bytecode is clearly “a non-executable intermediate representation” 3 that is converted to executable code prior to executing the executable code. Furthermore, to the extent that Thorell does not appear to explicitly disclose that “executable code” is “machine” code, as claimed, Bothner teaches compiling bytecode into “machine code”.4
Second, even assuming that the bytecode of Thorell is potentially executable under a virtual machine, as argued by Applicant, bytecode still falls within the broadest reasonable interpretation (BRI) of a “non-executable intermediate representation”, as follows. Although Applicant’s specification does not use the term “non-executable intermediate representation”, it does describe an intermediate representation that “can be executed on a virtual processor”5 (emphasis added) but is more efficiently used to generate machine code.6 The specification further states that “it is finally necessary to generate the machine code 230 executed by the processor of the distribution destination”7, which Examiner notes is an ordinary physical processor, such as a CPU or GPU8. Accordingly, the BRI of a “non-executable intermediate representation”, in light of Applicant’s specification, includes an intermediate representation that is not executable by an ordinary physical processor, even if it is executable virtually. As “bytecode” is not executable by an ordinary physical processor, it therefore falls within the BRI of a “non-executable intermediate representation” even if it is executable under a virtual machine, as argued by Applicant.
For the reason set forth above, Applicant’s argument is unpersuasive.
With respect to all dependent claims, Applicant references the argument made with respect to independent claims 19 and 299, which is unpersuasive for the reasons set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Anonymous “Java Bytecode Compilation” describes details of using the Java Runtime Environment with a Just-In-Time Compiler that compiles Java bytecode to native machine code.
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 STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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 on 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.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 See Remarks at pp. 10-11.
2 See Thorell at [0033]. See also [0023], “a code processor 38 included in the device 14 executes the program code, e.g., by … compiling … bytecode and then executing the resulting code”.
3 Although Applicant does not appear to argue that “bytecode” is an “intermediate representation”, as claimed, Examiner nonetheless notes that Applicant’s specification at para. [0044] states that “‘intermediate code’ is sometimes called an ‘intermediate representation’” and thus Thorell’s statement that “bytecode” is “intermediate code” is a clear disclosure of the claimed “intermediate representation”.
4 See Bothner, e.g., Figs. 5 and 7 along with associated text, e.g., col. 8:27-30, “An optimizing ahead-of-time Java compiler may be included with installation software such that byte code distributions may be compiled at installation time to produce efficient machine code.”
5 See Applicant’s specification at para. [0044].
6 See Applicant’s specification at para. [0044].
7 See Applicant’s specification at para. [0090].
8 [0038], “The processor 202 is, for example, a CPU or a GPU.”
9 See Remarks at pp. 11-13.
Prosecution Insights