DETAILED ACTION
This is the initial Office action based on the application filed on February 28, 2024.
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
The drawings are objected to because the description, in paragraph [0123] line 5, recites “(ASMDisplacementMem) 822”; however, this part is not shown in Figure 8. This unshown part also uses the same reference character “822” as a different labeled part within Figure 8 which is “ASMRegisterIndirectMem.” Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0112], lines 1-2, recites “into one a consolidated instruction.” It should read -- into one consolidated instruction --.
Paragraph [0158], line 1, recites “Calling the closeASMBlock().” It should read – Calling the closeASMSnippet() --.
Paragraph [0237], line 2, recites “interpreter instructions 2320.” It should read – interpreter instructions 3220 --.
Appropriate correction is required.
Claim Objections
Claims 3, 7, 10, 16, and 17 are objected to because of the following informalities:
Claim 3 recites, in both line 2 & line 3, “the at least one respective interpreter instruction.” It should read -- the at least one interpreter instruction --.
Claim 3 recites, in line 1, “replacing a virtual function call.” It should read – replacing the virtual function call --.
Claim 7 recites, in lines 1-2, “the set of the plurality of instructions.” It should read -- the set of the plurality of interpreter instructions --.
Claim 10 recites, in lines 1-2, “including the assembly code for a respective interpreter.” It should read – including the assembly code for the respective interpreter instruction --.
Claim 16 recites, in line 1, “The computing system of claim of claim 1.” It should read -- The computing system of claim 1 --.
Claim 17 recites, in lines 1-2, “the assembly code for a respective interpreter instruction.” It should read -- the assembly code for the respective interpreter instruction --.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 19, and 20 recite, in lines 9-10, lines 6-7, and lines 8-9 respectively, the limitation “the respective interpreter instruction.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as -- a respective interpreter instruction – in Claims 1, 19, and 20.
Claims 2-18 depend on Claim 1. Therefore, Claims 2-18 suffer the same deficiency as Claim 1.
Claim 2 recites, in line 1, the limitation “the operations.” The claims are rendered vague and indefinite because it is unclear to the Examiner whether “the operations” is referring back to “operations” recited in line 5 of Claim 1 or “operations” recited in line 10 of Claim 1. In the interest of compact prosecution, the Examiner interprets this limitation as “the operations” referring back to “operations” recited in line 5 of Claim 1.
Claim 3 depends on Claim 2. Therefore, Claim 3 suffers the same deficiency as Claim 2.
Claim 8 recites, in lines 1-2, the limitation “the consolidated interpreter instructions.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as -- the consolidated interpreter instruction – in Claim 8.
Claim 9 depends on Claim 8. Therefore, Claim 9 suffers the same deficiency as Claim 8.
Claim 10 recites, in lines 2-3, the limitation “the consolidated interpreter instructions.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as -- the consolidated interpreter instruction – in Claim 10.
Claim 18 recites, in line 4, the limitation “a size of the operations.” The claims are rendered vague and indefinite because it is unclear to the Examiner whether “the operations” is referring back to “operations in the consolidated interpreter instruction” recited in line 3 of Claim 18, or “operations” recited in line 5 of Claim 1, or “operations” recited in line 10 of Claim 1. In the interest of compact prosecution, the Examiner interprets this limitation as “a size of the operations in the consolidated interpreter instruction.”
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 1, 7, 8, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11,741,197 (hereinafter “Gibbons”) and US 11,119,739 (hereinafter “Allen”).
As per Claim 1, Gibbons discloses:
A computing system (col. 2 lines 15-19, “Other embodiments incorporating this example include corresponding computer systems, apparatus, and computer programs recorded on one or more non-transitory computer readable media (e.g., computer storage devices), each configured to perform the actions of the methods.”) comprising:
at least one memory (col. 2 lines 19-25, “An example computer system includes one or more network computer modules, networking modules, or server modules, memory comprising programmed instructions stored thereon, and one or more processors configured to be capable of executing the stored programmed instructions to perform the actions of the methods (emphasis added).”);
one or more hardware processor units coupled to the at least one memory (col. 24 lines 62-63, “At least one hardware processor 504 is coupled to I/O subsystem 502 for processing information and instructions (emphasis added).”; col. 25 lines 4-7, “Computer system 500 includes one or more units of memory 506, such as a main memory, which is coupled to I/O subsystem 502 for electronically digitally storing data and instructions to be executed by processor 504 (emphasis added).”; col. 27 lines 42-44, “I/O subsystem 502 carries the data to memory 506, from which processor 504 retrieves and executes the instructions (emphasis added).”); and
one or more computer readable storage media storing computer-executable instructions that, when executed, cause the computing system to perform operations (col. 25 lines 12-17, “Such instructions, when stored in non-transitory computer-readable storage media accessible to processor 504, can render computer system 500 into a special-purpose machine that is customized to perform the operations specified in the instructions (emphasis added).”; col. 25 lines 29-33, “Storage 510 is an example of a non-transitory computer-readable medium that may be used to store instructions and data which when executed by the processor 504 cause performing computer-implemented methods to execute the techniques herein (emphasis added).”) comprising:
[…] a plurality of interpreter instructions (col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”);
for respective interpreter instructions of the set of the plurality of interpreter instructions, determining whether an operation is defined to replace the respective interpreter instruction with [combined bytecode operation], wherein operations are defined for less than all types of interpreter instructions (col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 9-14, “Lines 1-3 and 11-13 of Snippet 4 each include two calls to a “push” operation followed by a call to an “add” operation. A combined bytecode operation may correspond to, for example, two “push” operations, a “push” operation followed by an “add” operation, or two “push” operations followed by an “add” operation (emphasis added).”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-67 to col. 15 lines 1-3, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation. The two parameters from the “push” operations of the original sequence, “1” and “Var X,” are provided to the combined bytecode operation. Similarly, the second sequence of operations, from Lines 11-13 of Snippet 4, has been replaced with another “push_push_add” operation, with the parameters “2” and “Var Y.””; col. 15 lines 4-15, “Although in the above example both sequences of operations were replaced by the combined bytecode operation, the compiler need not replace all instances of a sequence of operations with the corresponding combined bytecode operation […] For example, referring to Snippet 4, the compiler may replace Lines 1-3 with “push_push_add” but not replace Lines 11-13, or vice versa. As another example, the compiler may replace Lines 1-3 with “push_push_add,” replace Lines 11-12 with a “push_push” operation, and not replace Line 13 (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”) [Examiner’s Remarks: Note that Gibbons discloses replacing lines of bytecode operations within bytecode instructions with a combined bytecode operation and that not all instances of a sequence of operations need to be replaced by the compiler. Gibbons also discloses a respective set of one or more interpreter instructions for each combined bytecode operation. One of ordinary skill in the art would readily comprehend that the compiler replacing lines of bytecode operations (interpreter instructions) with a combined bytecode operation and not replacing all instances of a sequence of operations includes determining whether an operation is defined to replace the respective interpreter instruction with a combined bytecode operation, wherein operations are defined for less than all types of interpreter instructions.];
for respective interpreter instructions where an operation is defined, including the [bytecode operation] for the respective interpreter instruction in a consolidated interpreter instruction (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-67 to col. 15 lines 1-3, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation. The two parameters from the “push” operations of the original sequence, “1” and “Var X,” are provided to the combined bytecode operation. Similarly, the second sequence of operations, from Lines 11-13 of Snippet 4, has been replaced with another “push_push_add” operation, with the parameters “2” and “Var Y.” (emphasis added).”; col. 15 lines 4-15, “Although in the above example both sequences of operations were replaced by the combined bytecode operation [consolidated interpreter instruction], the compiler need not replace all instances of a sequence of operations with the corresponding combined bytecode operation […] For example, referring to Snippet 4, the compiler may replace Lines 1-3 [an operation is defined] with “push_push_add” but not replace Lines 11-13, or vice versa. As another example, the compiler may replace Lines 1-3 with “push_push_add,” replace Lines 11-12 with a “push_push” operation, and not replace Line 13 (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”; col. 17 lines 42-47, “Additionally, compiler 312 may generate one or more combined bytecode operations based on the set of one or more bytecode instructions, and modify the set of one or more bytecode instructions by replacing one or more sequences of bytecode instructions with calls to combined bytecode operations (emphasis added).”) [Examiner’s Remarks: Note that Gibbons discloses replacing lines of bytecode operations within bytecode instructions with a combined bytecode operation and that not all instances of a sequence of operations need to be replaced by the compiler. Gibbons also discloses a respective set of one or more interpreter instructions for each combined bytecode operation. One of ordinary skill in the art would readily comprehend that the compiler replacing lines of bytecode operations (interpreter instructions) with a combined bytecode operation means an operation is defined for respective interpreter instructions to include the bytecode operation for the respective interpreter instruction in a consolidated interpreter instruction (combined bytecode operation).]; and
executing the consolidated interpreter instruction, wherein the consolidated interpreter instruction replaces multiple interpreter instructions of the set of the plurality of interpreter instructions with corresponding [combined bytecode operation] (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”; col. 15 lines 22-31, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation. The set of one or more interpreter instructions, when executed, produce the same output and/or effects as the corresponding sequence of operations. Generating a set of one or more interpreter instructions for a combined bytecode operation may comprise retrieving or generating interpreter instructions corresponding each bytecode operation and combining the retrieved or generated interpreter instructions (emphasis added).”).
Gibbons does not explicitly disclose:
receiving a set of a plurality of interpreter instructions;
assembly code.
However, Allen discloses:
receiving a set of interpreter instructions (col. 4 lines 24-26, “Byte code, as used herein, refers to program code that has been compiled from source code into a form of instruction set for efficient execution by a software interpreter (emphasis added).”; col. 10 lines 56-59, “As described further at least with respect to FIG. 4, the packet-processing devices may receive the byte code 142 and load the byte code 142 into cache memory, such as i-cache of L1 cache of a processor (emphasis added).”);
assembly code (col. 5 lines 37-40, “The processor of the packet-processing device(s) may then execute the low-level code, which may include the use of a just-in-time (JIT) compiler to translate the byte code into appropriate assembly code (emphasis added).”).
Gibbons is within the same field of endeavor as the claimed invention regarding the consolidation of interpreter instructions. Allen is also within the same field of endeavor as the claimed invention regarding the replacement of interpreter instructions with assembly code.
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 teaching of Allen into the teaching of Gibbons to include “receiving a set of a plurality of interpreter instructions; assembly code.” The modification would be obvious because one of ordinary skill in the art would be motivated to compile high-level or mid-level code into low-level code like assembly for “various efficiencies, such as removing extraneous, duplicative, and/or unnecessary branches in the code” (Allen, col. 5 lines 62-67).
As per Claim 7, the rejection of Claim 1 is incorporated; and Gibbons further discloses:
wherein the set of the plurality of instructions are distributed among multiple code units (col. 12 lines 21-28, “Based on the original JavaScript file 120, the compiler 210 may generate a plurality of interpreter-bytecode pairs, such as interpreter bytecode pair 220A, interpreter bytecode pair 220B, and interpreter bytecode pair 220C. Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”), and the consolidated interpreter instruction comprises all interpreter instructions for a code unit of the multiple code units (col. 12 lines 25-28 & 35-37, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter […] For example, each of defined operations 232A, 232B, and 232C may map the same bytecode operation to a different operation name (emphasis added).”; col. 13 lines 5-10, “Compiler 210 may generate bytecode instructions 240A based on original JavaScript file 120 and defined operations 232A. Bytecode instructions 240A comprise calls to bytecode operations in defined operations 232A. Similarly, interpreter 230B defines a set of bytecode operations 232B (emphasis added).”; col. 13 lines 24-26, “Additionally, as explained in further detail below, each of defined operations 232A, 232B, and 232C may include a respective set of one or more combined bytecode operations (emphasis added).”; col. 13 lines 30-34, “For example, defined operations 232A may include a plurality of combined bytecode operations. Defined operations 232B and 232C may each include some, all, or none of the combined bytecode operations of the plurality of combined bytecode operations.”; col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation [consolidated interpreter instruction] (emphasis added).”) [Examiner’s Remarks: Note that Gibbons discloses bytecode instructions comprising calls to combined bytecode operations within various defined operations in different bytecode interpreter pairs which one of ordinary skill in the art would readily comprehend there are multiple code units among the bytecode interpreter pairs. Gibbons discloses that a combined bytecode operation (consolidated interpreter instruction) replaces/combines a sequence of two or more original bytecode operations and an example of a snippet of code that replaces the first sequence of operations with a combined bytecode operation. Gibbons also discloses a respective set of one or more interpreter instructions for each combined bytecode operation. One of ordinary skill in the art would readily comprehend that all lines in a snippet (code unit) that only includes one sequence of operations may be replaced with a combined bytecode operation which has corresponding interpreter instructions. As a result, the consolidated interpreter instruction comprises all interpreter instructions for a code unit of multiple code units.].
As per Claim 8, the rejection of Claim 7 is incorporated; and Gibbons further discloses:
wherein the consolidated interpreter instructions for the multiple code units are comprised within a set of interpreter instructions (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-31, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation [consolidated interpreter instruction]. The set of one or more interpreter instructions, when executed, produce the same output and/or effects as the corresponding sequence of operations. Generating a set of one or more interpreter instructions for a combined bytecode operation may comprise retrieving or generating interpreter instructions corresponding each bytecode operation and combining the retrieved or generated interpreter instructions (emphasis added).”; col. 12 lines 25-28 & 35-37, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter […] For example, each of defined operations 232A, 232B, and 232C may map the same bytecode operation to a different operation name (emphasis added).”; col. 13 lines 5-10, “Compiler 210 may generate bytecode instructions 240A based on original JavaScript file 120 and defined operations 232A. Bytecode instructions 240A comprise calls to bytecode operations in defined operations 232A. Similarly, interpreter 230B defines a set of bytecode operations 232B (emphasis added).”; col. 13 lines 24-26, “Additionally, as explained in further detail below, each of defined operations 232A, 232B, and 232C may include a respective set of one or more combined bytecode operations (emphasis added).”; col. 13 lines 30-34, “For example, defined operations 232A may include a plurality of combined bytecode operations. Defined operations 232B and 232C may each include some, all, or none of the combined bytecode operations of the plurality of combined bytecode operations.”).
As per Claim 16, the rejection of Claim 1 is incorporated; and Gibbons further discloses:
wherein operations within the consolidated interpreter instruction are sequential (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 9-14, “Lines 1-3 and 11-13 of Snippet 4 each include two calls to a “push” operation followed by a call to an “add” operation. A combined bytecode operation [consolidated interpreter instruction] may correspond to, for example, two “push” operations, a “push” operation followed by an “add” operation, or two “push” operations followed by an “add” operation (emphasis added).”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-67 to col. 15 lines 1-3, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation. The two parameters from the “push” operations of the original sequence, “1” and “Var X,” are provided to the combined bytecode operation. Similarly, the second sequence of operations, from Lines 11-13 of Snippet 4, has been replaced with another “push_push_add” operation, with the parameters “2” and “Var Y (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”).
Claim 19 is a method claim corresponding to system Claim 1 and is rejected for the same
reasons as given in the rejection of that claim.
Claim 20 is a non-transitory computer-readable storage media claim corresponding to system Claim 1 and is rejected for the same reasons as given in the rejection of that claim.
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 8,578,352 (hereinafter “Mitrovic”).
As per Claim 2, the rejection of Claim 1 is incorporated; and the combination of Gibbons and Allen discloses “for at least one interpreter instruction of the set of the plurality of interpreter instructions, determining that an operation is not defined to replace the at least one interpreter instruction (Gibbons, col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”; col. 15 lines 4-15, “Although in the above example both sequences of operations were replaced by the combined bytecode operation, the compiler need not replace all instances of a sequence of operations with the corresponding combined bytecode operation […] For example, referring to Snippet 4, the compiler may replace Lines 1-3 with “push_push_add” but not replace Lines 11-13 [an operation is not defined], or vice versa. As another example, the compiler may replace Lines 1-3 with “push_push_add,” replace Lines 11-12 with a “push_push” operation, and not replace Line 13 (emphasis added).”) with assembly code (Allen, col. 5 lines 37-40, “The processor of the packet-processing device(s) may then execute the low-level code, which may include the use of a just-in-time (JIT) compiler to translate the byte code into appropriate assembly code (emphasis added).”),” “the at least one interpreter instruction (Gibbons, col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”),” and “including the [combined bytecode operation] in the consolidated interpreter instruction (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-67 to col. 15 lines 1-3, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation. The two parameters from the “push” operations of the original sequence, “1” and “Var X,” are provided to the combined bytecode operation. Similarly, the second sequence of operations, from Lines 11-13 of Snippet 4, has been replaced with another “push_push_add” operation, with the parameters “2” and “Var Y.” (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”),” but does not explicitly disclose:
replacing a virtual function call for the at least one interpreter instruction with a devirtualized function call; and
including the devirtualized function call in the consolidated interpreter instruction.
However, Mitrovic discloses:
replacing a virtual function call for the [virtual function] with a devirtualized function call (col. 6 lines 33-35, “Further, virtual function customizer 220 can iteratively devirtualize one or all of the virtual calls identified in the virtual function (emphasis added).”; col. 9 lines 22-26, “As described above and as will be further described in the example below, customization of virtual functions by devirtualizing calls to virtual functions can greatly help to improve the performance of generated code at runtime (emphasis added).”); and
the devirtualized function call (col. 6 lines 33-35, “Further, virtual function customizer 220 can iteratively devirtualize one or all of the virtual calls identified in the virtual function (emphasis added).”; col. 9 lines 22-26, “As described above and as will be further described in the example below, customization of virtual functions by devirtualizing calls to virtual functions can greatly help to improve the performance of generated code at runtime (emphasis added).”).
Mitrovic is within the same field of endeavor as the claimed invention regarding the devirtualization of a virtual function.
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 teaching of Mitrovic into the combined teachings of Gibbons and Allen to include “replacing a virtual function call for the at least one interpreter instruction with a devirtualized function call; and including the devirtualized function call in the consolidated interpreter instruction.” The modification would be obvious because one of ordinary skill in the art would be motivated to devirtualize calls to virtual functions to greatly help “improve the performance of generated code at runtime” (Mitrovic, col. 6 lines 33-35 & col. 9 lines 22-26).
As per Claim 3, the rejection of Claim 2 is incorporated; and Gibbons discloses “the at least one respective interpreter instruction (col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”),” but the combination of Gibbons and Allen does not explicitly disclose:
wherein replacing a virtual function call for the at least one respective interpreter instruction comprises performing a lookup to a virtual function table defined for the at least one respective interpreter instruction.
However, Mitrovic discloses:
wherein replacing a virtual function call for the [devirtualized function call] (col. 6 lines 33-35, “Further, virtual function customizer 220 can iteratively devirtualize one or all of the virtual calls identified in the virtual function (emphasis added).”; col. 9 lines 22-26, “As described above and as will be further described in the example below, customization of virtual functions by devirtualizing calls to virtual functions can greatly help to improve the performance of generated code at runtime (emphasis added).”) comprises performing a lookup to a virtual function table defined for [a class] (col. 2 lines 57-64, “A common way to implement fast virtual calls in a programming language with static types is by associating a virtual table (or "vtable") with each class. Embodiments enable the customization of whole methods to a receiver class. The entry points to the customized methods are then stored as an entry in the vtable of the receiver class. Accordingly, the correct customized method is called without any type checks at runtime (emphasis added).”; col. 10 lines 3-7, “For example, when the lines of code "int k=A.Sum ( );" and "int j=B.Sum( );" of the main routine are executed, the virtual function table, or vtable, for base class 510 can be used to invoke the correct customized compiled function of "Sum." (emphasis added).”) [Examiner’s Remarks: Note that Mitrovic discloses using a virtual function table to invoke a function. One of ordinary skill in the art would readily comprehend that invoking the function using the virtual function table includes performing a lookup to the virtual function table.].
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 teaching of Mitrovic into the combined teachings of Gibbons and Allen to include “wherein replacing a virtual function call for the at least one respective interpreter instruction comprises performing a lookup to a virtual function table defined for the at least one respective interpreter instruction.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a virtual function table that stores a customized version of a virtual function to perform lookups because “customization of virtual functions by devirtualizing calls to virtual functions can greatly help to improve the performance of generated code at runtime” (Mitrovic, col. 2 lines 57-64, col. 9 lines 22-26, & col. 10 lines 3-7).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 7,058,932 (hereinafter “Jennings”).
As per Claim 4, the rejection of Claim 1 is incorporated; and Gibbons discloses “the consolidated interpreter instruction (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-67 to col. 15 lines 1-3, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation. The two parameters from the “push” operations of the original sequence, “1” and “Var X,” are provided to the combined bytecode operation. Similarly, the second sequence of operations, from Lines 11-13 of Snippet 4, has been replaced with another “push_push_add” operation, with the parameters “2” and “Var Y (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”),” but the combination of Gibbons and Allen does not explicitly disclose:
wherein executing the consolidated interpreter instruction is performed in a single iteration of an interpreter execution loop.
However, Jennings discloses:
wherein executing [an operator] is performed in a single iteration of an interpreter execution loop (col. 2 lines 58-60, “FIG. 6 illustrates the main execution loop of the interpreter of the emulation system of FIG. 2, in accordance with a preferred embodiment thereof (emphasis added).”; col. 11 lines 63-65 & col. 12 lines 8-15, “FIG. 6 illustrates the main interpreter execution loop. The interpreter 24 makes up to two attempts to execute any given operator […] This initial attempt to execute the operator handles all arithmetic operations on single precision positive integers (with the exception of division), all branching operations, nearly all loads and stores, and most descriptor indexing and evaluation operations. It also handles most procedure enter and exit operators. During dynamic execution, over ninety-five percent (95%) of all operators are interpreted during this pass (emphasis added).”).
Jennings is within the same field of endeavor as the claimed invention regarding the use of interpreters and instruction sets.
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 teaching of Jennings into the combined teachings of Gibbons and Allen to include “wherein executing the consolidated interpreter instruction is performed in a single iteration of an interpreter execution loop.” The modification would be obvious because one of ordinary skill in the art would be motivated to execute an operator in a single iteration of an interpreter execution loop using an intermediate instruction set optimized “for high speed interpretation on the host computer” (Jennings, col. 2 lines 24-29, col. 11 lines 63-65 & col. 12 lines 8-15).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 6,002,874 (hereinafter “Bahrs”).
As per Claim 5, the rejection of Claim 1 is incorporated; and Gibbons discloses “respective interpreter instructions (col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”)” and “interpreter instructions (see previous citation),” but the combination of Gibbons and Allen does not explicitly disclose:
wherein the respective interpreter instructions are represented as instances of an abstract datatype representing interpreter instructions.
However, Bahrs discloses:
wherein the [instructions] are represented as instances of an abstract datatype representing [instructions] (col. 5 lines 13-16 & lines 18-25, “An object will be created, for example, for the "move", "read", "goto" statements. Each of these statement types will have an abstract object [instance of abstract datatype] for that statement type be created […] If a particular statement, such as the "move" statement, appears in more than one form, for example with differing numbers of parameters, then subclasses of the abstract object will be created for each of the different formats of the instruction. Thus, a move instruction with two parameters will be created as a subclass of the move abstract class and a move instruction with three parameters will similarly be created as a subclass (emphasis added).”).
Bahrs is within the same field of endeavor as the claimed invention regarding the representation of instructions through abstract datatypes.
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 teaching of Bahrs into the combined teachings of Gibbons and Allen to include “wherein the respective interpreter instructions are represented as instances of an abstract datatype representing interpreter instructions.” The modification would be obvious because one of ordinary skill in the art would be motivated to represent instructions as abstract datatypes that may inherit attributes/methods from base classes to create “an automated process for converting legacy applications into object oriented applications, and particularly into programs operable in evolving NC environments” to “increase company data processing efficiencies and allow improved productivity for those companies” (Bahrs, col. 2 lines 14-18 & col. 5 lines 13-16 & lines 18-25).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen and Bahrs as applied to Claim 5 above, and further in view of US 2008/0098037 (hereinafter “Neil”).
As per Claim 6, the rejection of Claim 5 is incorporated; and the combination of Gibbons, Allen, and Bahrs discloses “wherein respective instances of the abstract datatype are derived classes of a base abstract datatype representing (Bahrs, col. 5 lines 13-16 & lines 18-25, “An object will be created, for example, for the "move", "read", "goto" statements. Each of these statement types will have an abstract object [instance of abstract datatype] for that statement type be created […] If a particular statement, such as the "move" statement, appears in more than one form, for example with differing numbers of parameters, then subclasses of the abstract object will be created for each of the different formats of the instruction. Thus, a move instruction with two parameters will be created as a subclass [derived class] of the move abstract class [base abstract datatype] and a move instruction with three parameters will similarly be created as a subclass (emphasis added).”; col. 6 Example 2 lines 2-8 & col. 7 lines 8-14,
“abstract class Statement
{
// execute statement, returning the next statement number to execute
abstract int execute( ) throws StatementExecutionException;
}
class MoveStatement extends Statement
{
[…]
public int execute( ) throws StatementExecutionException
{
:
: statement specific behavior
:
return next;
}
}”; col. 9 lines 44-49, “For each statement in the source, a corresponding statement object is be created. These objects are instances of the appropriate Statement subclass [derived class of a base abstract datatype]. For example, a MOVE (X,TO,Y) statement would cause the creation of a MoveStatement object. There is only one MoveStatement class, but it may have zero to many instances (emphasis added).”) interpreter instructions (Gibbons, col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”),” and “base abstract datatype (Bahrs, col. 5 lines 22-25, “Thus, a move instruction with two parameters will be created as a subclass [derived class] of the move abstract class [base abstract datatype] and a move instruction with three parameters will similarly be created as a subclass (emphasis added).”),” but does not explicitly disclose:
overload an execute function of the base abstract datatype.
However, Neil discloses:
overload an execute function of the [class] (paragraph [0058], “To account for the fact that the execute( ) method implementation in the Upgrade class takes a parameter "resultantVersion" while the implementations in the other classes do not take any parameters, the execute( ) method could be overloaded (emphasis added).”).
Neil is within the same field of endeavor as the claimed invention regarding the overloading of execute functions.
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 teaching of Neil into the combined teachings of Gibbons, Allen, and Bahrs to include “overload an execute function of the base abstract datatype.” The modification would be obvious because one of ordinary skill in the art would be motivated to overload an execute function to increase flexibility in providing multiple ways to call a function based on the input parameters (Neil, paragraph [0058]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 8 above, and further in view of US 2012/0030451 (hereinafter “Pong”) and US 2011/0307954 (hereinafter “Melnik”).
As per Claim 9, the rejection of Claim 8 is incorporated; and Gibbons discloses “the set of interpreter instructions (col. 12 lines 25-28, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions [interpreter instructions]. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”)” and “the consolidated interpreter instructions of the multiple code units (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-31, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation [consolidated interpreter instruction]. The set of one or more interpreter instructions, when executed, produce the same output and/or effects as the corresponding sequence of operations. Generating a set of one or more interpreter instructions for a combined bytecode operation may comprise retrieving or generating interpreter instructions corresponding each bytecode operation and combining the retrieved or generated interpreter instructions (emphasis added).”; col. 12 lines 25-28 & 35-37, “Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter […] For example, each of defined operations 232A, 232B, and 232C may map the same bytecode operation to a different operation name (emphasis added).”; col. 13 lines 5-10, “Compiler 210 may generate bytecode instructions 240A based on original JavaScript file 120 and defined operations 232A. Bytecode instructions 240A comprise calls to bytecode operations in defined operations 232A. Similarly, interpreter 230B defines a set of bytecode operations 232B (emphasis added).”; col. 13 lines 24-26, “Additionally, as explained in further detail below, each of defined operations 232A, 232B, and 232C may include a respective set of one or more combined bytecode operations (emphasis added).”; col. 13 lines 30-34, “For example, defined operations 232A may include a plurality of combined bytecode operations. Defined operations 232B and 232C may each include some, all, or none of the combined bytecode operations of the plurality of combined bytecode operations.”),” but the combination of Gibbons and Allen does not explicitly disclose:
wherein the set of interpreter instructions comprises control structures for jumps between code units of the multiple code units and the control structures are not comprised within the consolidated interpreter instructions of the multiple code units.
However, Pong discloses:
wherein [instructions] comprises control structures for jumps between code units of the multiple code units (paragraph [0131], “Upon receiving a conditional jump instruction [control structure], the conditional jump logic block 422 adjusts a program counter (pc) 302 of a packet processor 110 to a first location of multiple locations in program code stored in instruction memory 112 based on whether a corresponding first condition of multiple conditions is true (emphasis added).”; paragraph [0128], “Packet processors 110 as described herein avert the complexity of speculative execution by using conditional jumps as described below which evaluate multiple jumps and conditions in a single instruction (emphasis added).”).
Pong is within the same field of endeavor as the claimed invention regarding the use of control structures for code jumps.
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 teaching of Pong into the combined teachings of Gibbons and Allen to include “wherein the set of interpreter instructions comprises control structures for jumps between code units of the multiple code units.” The modification would be obvious because one of ordinary skill in the art would be motivated to “avert the complexity of speculative execution by using conditional jumps […] which evaluate multiple jumps and conditions in a single instruction” (Pong, paragraph [0128]).
However, Melnik discloses:
the control structures are not comprised within [a code version] (paragraph [0050], “In one embodiment, the code rewrite engine 206 rewrites code by creating a version of the code without conditional statements (emphasis added).”).
Melnik is within the same field of endeavor as the claimed invention regarding the lack of control structures in certain types of code.
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 teaching of Melnik into the combined teachings of Gibbons, Allen, and Pong to include “the control structures are not comprised within the consolidated interpreter instructions of the multiple code units.” The modification would be obvious because one of ordinary skill in the art would be motivated to include a code version without a control structure such as a conditional statement in order to rewrite code that aids in “improving code coverage for code analyzed for security purposes” (Melnik, abstract & paragraph [0050]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 2003/0041118 (hereinafter “Elnozahy”).
As per Claim 10, the rejection of Claim 1 is incorporated; and the combination of Gibbons and Allen discloses “wherein the including the assembly code (Allen, col. 5 lines 37-40, “The processor of the packet-processing device(s) may then execute the low-level code, which may include the use of a just-in-time (JIT) compiler to translate the byte code into appropriate assembly code (emphasis added).”) for a respective interpreter is performed by a code generator (Gibbons, col. 14 lines 54-58, “The compiler may replace one or more instances of a bytecode sequence with a combined bytecode operation corresponding to the sequence. For example, the compiler [code generator] may generate the following modified bytecode instructions in Snippet 5 (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”; col. 12 lines 21-28, “Based on the original JavaScript file 120, the compiler 210 may generate a plurality of interpreter-bytecode pairs, such as interpreter bytecode pair 220A, interpreter bytecode pair 220B, and interpreter bytecode pair 220C. Each interpreter bytecode pair comprises a respective interpreter and set of one or more bytecode instructions. The bytecode instructions correspond to the bytecode operations defined by the corresponding interpreter (emphasis added).”) and the executing the consolidated interpreter instructions is performed by an interpreter (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”),” and “code generator (Gibbons, col. 14 lines 54-58, “The compiler may replace one or more instances of a bytecode sequence with a combined bytecode operation corresponding to the sequence. For example, the compiler [code generator] may generate the following modified bytecode instructions in Snippet 5 (emphasis added).”),” but does not explicitly disclose:
the code generator and the interpreter share a common address space.
However, Elnozahy discloses:
the [web server] and the interpreter share a common address space (paragraph [0019], “Both script interpreter 210 and JVM 212 reside in the same address space as Web server 200, thereby obviating the need for context switching or spawning heavy-weight processes external to Web server 200, as is commonly done in the art.”).
Elnozahy is within the same field of endeavor as the claimed invention regarding an interpreter sharing an address space with another component.
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 teaching of Elnozahy into the combined teachings of Gibbons and Allen to include “the code generator and the interpreter share a common address space.” The modification would be obvious because one of ordinary skill in the art would be motivated to have an interpreter share an address space with another component like a web server to obviate “the need for context switching or spawning heavy-weight processes” (Elnozahy, paragraph [0019]).
Claims 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 2008/0133888 (hereinafter “Arakawa”).
As per Claim 11, the rejection of Claim 1 is incorporated; and the combination of Gibbons and Allen discloses “wherein the consolidated interpreter instruction (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”) comprises assembly code (Allen, col. 5 lines 37-40, “The processor of the packet-processing device(s) may then execute the low-level code, which may include the use of a just-in-time (JIT) compiler to translate the byte code into appropriate assembly code (emphasis added).”) for at least two respective interpreter instructions (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”),” but does not explicitly disclose:
the assembly code comprises register allocation instructions.
However, Arakawa discloses:
the assembly code comprises register allocation instructions (Figure 1; paragraph [0066], “The explanation of the first program described with an assembler will be offered here. The assembler program assumes an architecture having post-increment type load and store instructions (emphasis added).”; paragraph [0067], “First, according to four immediate transfer instructions "mov #_a, r0", "mov #_b, r1", "mov #_c, r2" and "mov #N, r3", top addresses _a, _b and _c of three arrays and the number N of elements of each array are stored as initial settings in registers r0, r1, r2 and r3 respectively (emphasis added).”; paragraph [0069], “Further, in order to execute the second post-increment load instructions "mov @r0+, r4" and "mov @r1+, r5" prior to the first addition instruction "add r4, r5", other physical registers different from those for the first time are allocated to the registers r4 and r5 (emphasis added).”).
Arakawa is within the same field of endeavor as the claimed invention regarding the use of register allocation instructions in assembly code.
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 teaching of Arakawa into the combined teachings of Gibbons and Allen to include “the assembly code comprises register allocation instructions.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize register allocation instructions so that issues regarding antidependence in particular processors are “resolved by changing the allocation of physical registers” (Arakawa, paragraph [0082]).
As per Claim 12, the rejection of Claim 11 is incorporated; and the combination of Gibbons and Allen does not explicitly disclose:
wherein at least one register referenced by a register allocation instruction is mapped to a CPU register.
However, Arakawa discloses:
wherein at least one register referenced by a register allocation instruction is mapped to a CPU register (Figure 1; paragraph [0067], “First, according to four immediate transfer instructions "mov #_a, r0", "mov #_b, r1", "mov #_c, r2" and "mov #N, r3", top addresses _a, _b and _c of three arrays and the number N of elements of each array are stored as initial settings in registers r0, r1, r2 and r3 respectively (emphasis added).”).
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 teaching of Arakawa into the combined teachings of Gibbons and Allen to include “wherein at least one register referenced by a register allocation instruction is mapped to a CPU register.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize register allocation instructions so that issues regarding antidependence in particular processors are “resolved by changing the allocation of physical registers” (Arakawa, paragraph [0082]).
As per Claim 13, the rejection of Claim 11 is incorporated; and the combination of Gibbons and Allen does not explicitly disclose:
wherein a first register allocation instruction loads a value for an operand into a register and a result of an operation using the operand is written back to the register.
However, Arakawa discloses:
wherein a first register allocation instruction loads a value for an operand into a register and a result of an operation using the operand is written back to the register (Figure 1; paragraph [0067], “Next, in a loop part, according to post-increment load instructions "mov @r0+, r4" and "mov @r1+, r5", array elements are loaded from addresses of the arrays a and b indicated by the registers r0 and r1 into the registers r4 and r5, and concurrently values of the registers r0 and r1 are incremented so as to indicate subsequent array elements. Then, according to an addition instruction "add r4, r5", the array elements loaded into the registers r4 and r5 are added, and the result is stored in the register r5 (emphasis added).”).
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 teaching of Arakawa into the combined teachings of Gibbons and Allen to include “wherein a first register allocation instruction loads a value for an operand into a register and a result of an operation using the operand is written back to the register.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize register allocation instructions so that issues regarding antidependence in particular processors are “resolved by changing the allocation of physical registers” (Arakawa, paragraph [0082]).
As per Claim 14, the rejection of Claim 1 is incorporated; and Gibbons discloses “the consolidated interpreter instruction (col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”),” but the combination of Gibbons and Allen does not explicitly disclose:
wherein the consolidated interpreter instruction comprises register allocation instructions.
However, Arakawa discloses:
wherein the [assembly code] comprises register allocation instructions (Figure 1; paragraph [0066], “The explanation of the first program described with an assembler will be offered here. The assembler program assumes an architecture having post-increment type load and store instructions (emphasis added).”; paragraph [0067], “First, according to four immediate transfer instructions "mov #_a, r0", "mov #_b, r1", "mov #_c, r2" and "mov #N, r3", top addresses _a, _b and _c of three arrays and the number N of elements of each array are stored as initial settings in registers r0, r1, r2 and r3 respectively (emphasis added).”; paragraph [0069], “Further, in order to execute the second post-increment load instructions "mov @r0+, r4" and "mov @r1+, r5" prior to the first addition instruction "add r4, r5", other physical registers different from those for the first time are allocated to the registers r4 and r5 (emphasis added).”).
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 teaching of Arakawa into the combined teachings of Gibbons and Allen to include “wherein the consolidated interpreter instruction comprises register allocation instructions.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize register allocation instructions so that issues regarding antidependence in particular processors are “resolved by changing the allocation of physical registers” (Arakawa, paragraph [0082]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen and Arakawa as applied to Claim 14 above, and further in view of Mitrovic.
As per Claim 15, the rejection of Claim 14 is incorporated; and the combination of Gibbons, Allen, and Arakawa discloses “wherein a register allocation instruction of the register allocation instructions allocates [an array address] to a register (Arakawa, paragraph [0067], “First, according to four immediate transfer instructions "mov #_a, r0", "mov #_b, r1", "mov #_c, r2" and "mov #N, r3", top addresses _a, _b and _c of three arrays and the number N of elements of each array are stored as initial settings in registers r0, r1, r2 and r3 respectively (emphasis added).”),” but does not explicitly disclose:
a devirtualized function call.
However, Mitrovic discloses:
a devirtualized function call (col. 6 lines 33-35, “Further, virtual function customizer 220 can iteratively devirtualize one or all of the virtual calls identified in the virtual function (emphasis added).”; col. 9 lines 22-26, “As described above and as will be further described in the example below, customization of virtual functions by devirtualizing calls to virtual functions can greatly help to improve the performance of generated code at runtime (emphasis added).”).
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 teaching of Mitrovic into the combined teachings of Gibbons, Allen, and Arakawa to include “a devirtualized function call.” The modification would be obvious because one of ordinary skill in the art would be motivated to devirtualize calls to virtual functions to greatly help “improve the performance of generated code at runtime” (Mitrovic, col. 6 lines 33-35 & col. 9 lines 22-26).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen as applied to Claim 1 above, and further in view of US 2020/0125501 (hereinafter “Durham”).
As per Claim 17, the rejection of Claim 1 is incorporated; and the combination of Gibbons and Allen discloses “wherein the including the assembly code (Allen, col. 5 lines 37-40, “The processor of the packet-processing device(s) may then execute the low-level code, which may include the use of a just-in-time (JIT) compiler to translate the byte code into appropriate assembly code (emphasis added).”) for a respective interpreter instruction in a consolidated interpreter instruction comprises [bytecode operations] (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”; col. 13 lines 63-67, “For example, Snippet 4 is a sequence of bytecode instructions contained in bytecode instructions 152 (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 59-62,
“Snippet 5
Line 01: Push_Push_Add 1, Var X
. . .
Line 09: Push_Push_Add 2, Var Y.”; col. 14 lines 63-65, “In Snippet 5, the first sequence of operations, from Lines 1-3 of Snippet 4, has been replaced with a single “push_push_add” operation (emphasis added).”)” and “the consolidated interpreter instruction (see previous citation),” but does not explicitly disclose:
dynamically requesting memory for the consolidated interpreter instruction.
However, Durham discloses:
dynamically requesting memory for [data] (paragraph [0181], “For example, a malloc (memory allocation) instruction may be used in C programming language software to dynamically request memory for data (e.g., variable, buffer, array, etc.) (emphasis added).”).
Durham is within the same field of endeavor as the claimed invention regarding dynamically requesting memory.
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 teaching of Durham into the combined teachings of Gibbons and Allen to include “dynamically requesting memory for the consolidated interpreter instruction.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a malloc instruction to dynamically request memory for data and generate “a cryptographically encoded pointer to the allocated memory” to “provide memory safety to computer systems” since the “fundamentally cryptographic separation policies of cryptographic computing may allow the processor to speculate freely and provide increased performance” (Durham, paragraph [0003, 0044, & 0181]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Gibbons in view of Allen and Durham as applied to Claim 17 above, and further in view of US 12,554,524 (hereinafter “Stabrawa”).
As per Claim 18, the rejection of Claim 17 is incorporated; and the combination of Gibbons, Allen, and Durham discloses “wherein the dynamically requesting memory (Durham, paragraph [0181], “For example, a malloc (memory allocation) instruction may be used in C programming language software to dynamically request memory for data (e.g., variable, buffer, array, etc.) (emphasis added).”) for the consolidated interpreter instruction (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”) comprises: writing operations in the consolidated interpreter instruction (Gibbons, col. 13 lines 57-62, “A combined bytecode operation [consolidated interpreter instruction] is a bytecode operation that combines a sequence of two or more original bytecode operations and, when executed by an interpreter, performs the work the sequence of two or more original bytecode operations would have performed when executed by the interpreter (emphasis added).”; col. 14 lines 1-8,
“Snippet 4
Line 01: Push 1
Line 02: Push Var x
Line 03: Add
. . .
Line 11: Push 2
Line 12: Push Var Y
Line 13: Add.”; col. 14 lines 9-14, “Lines 1-3 and 11-13 of Snippet 4 each include two calls to a “push” operation followed by a call to an “add” operation. A combined bytecode operation [consolidated interpreter instruction] may correspond to, for example, two “push” operations, a “push” operation followed by an “add” operation, or two “push” operations followed by an “add” operation (emphasis added).”; col. 15 lines 22-24, “In an embodiment, the compiler generates a respective set of one or more interpreter instructions for each combined bytecode operation (emphasis added).”),” “determining a size of the operations (Durham, paragraph [0048], “The “Metadata Wall” may refer to the problem of additionally fetching metadata about memory operations such as access control, object type/size, and version (emphasis added).”; paragraph [0060], “On (or during) a memory allocation operation (e.g., a “malloc”), memory allocation logic 146 allocates a range of memory for a buffer and returns the indirect address 114 and the metadata (e.g., one or more of range, permission metadata, size (power), memory allocation size, type, location, ownership, version, tag, privilege level, crypto context ID, etc.) (emphasis added).”),” and “requesting memory of the size to provide allocated memory (Durham, paragraph [0181], “In the example shown in FIG. 19, at 1902, a processor performs a memory allocation requested by a function of a software program. For example, a malloc (memory allocation) instruction may be used in C programming language software to dynamically request memory for data (e.g., variable, buffer, array, etc.). The malloc instruction allocates memory on the heap and also allocates a pointer on the stack (emphasis added).”; paragraph [0052], “The size metadata is dependent on the amount of memory requested by a program (emphasis added).”; paragraph [0060], “On (or during) a memory allocation operation (e.g., a “malloc”), memory allocation logic 146 allocates a range of memory for a buffer and returns the indirect address 114 and the metadata (e.g., one or more of range, permission metadata, size (power), memory allocation size, type, location, ownership, version, tag, privilege level, crypto context ID, etc.) (emphasis added).”),” but does not explicitly disclose:
writing the consolidated interpreter instruction to the allocated memory.
However, Stabrawa discloses:
writing [data] to the allocated memory (col. 3 lines 34-36, “For example, the client may read data from or write data to a location in the externally allocated memory (emphasis added).”).
Stabrawa is within the same field of endeavor as the claimed invention regarding requesting and writing to memory.
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 teaching of Stabrawa into the combined teachings of Gibbons, Allen, and Durham to include “writing the consolidated interpreter instruction to the allocated memory.” The modification would be obvious because one of ordinary skill in the art would be motivated to include a dynamically allocatable external memory that may be requested and written to so that one may “buy smaller more energy-efficient and cost-effective servers and extend their memory capacity, on demand, by using dynamically allocatable external memory” instead of expensive large servers with large memory capacity (Stabrawa, col. 4 lines 64-67 to col. 5 lines 1-2).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FEVEN H HURUY whose telephone number is (571)272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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 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.
/F.H.H./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191