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 of the following:
Fig. 4: descriptive labels 408, 419, and 422 are illegible;
Fig. 5: descriptive labels 511, 523, and 528 are illegible;
Fig. 6: descriptive labels 608, 619, and 622 are illegible;
Fig. 7: descriptive labels 711, 723, and 728 are illegible;
Fig. 8: descriptive labels 807 and 811 are illegible;
Fig. 9: descriptive labels 911, 921, and 941 are illegible;
Fig. 10: descriptive labels 1011, 1021, and 1041 are illegible.
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.
Claim Objections
Claims 13-19 are objected to because of the following informalities:
“claim 11” In line 1 of the claims must have been –claim 12--, respectively.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 6, 9, 16, and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 6 and 9 are directed to computer implemented methods and fall within the statutory category of processes; Claims 16 and 19 are directed to systems and fall withing the statutory category of machines.
With respect to claim 6:
Step 2A Prong 1:
Claim 6 recites:
executing a partial escape analyzer to perform a partial escape analysis on the inlined code to generate the consolidated code, wherein the partial escape analysis comprises:
identifying the scope of the inlined code, and
identifying an access to the element as the point where the element escapes the scope and located prior to a return from the scope.
Steps (a) - (b) recite “Mental Processes” (i.e., observation, evaluation, judgment, and/or opinion) that can be performed in the human mind, or by a human using pen and paper.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
With respect to claim 9:
Step 2A Prong 1:
Claim 9 recites:
determining that the element is not accessed within the scope after the instructions to allocate the element and prior to the instructions to initialize the element.
Step (a) recites a “Mental Process” (i.e., observation, evaluation, judgment, and/or opinion) that can be performed in the human mind, or by a human using pen and paper.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
With respect to claim 16:
Step 2A Prong 1:
Claim 16 recites:
executing a partial escape analyzer to perform a partial escape analysis on the inlined code to generate the consolidated code, wherein the partial escape analysis comprises:
identifying the scope of the inlined code, and
identifying an access to the element as the point where the element escapes the scope and located prior to a return from the scope.
Steps (a) - (b) recite “Mental Processes” (i.e., observation, evaluation, judgment, and/or opinion) that can be performed in the human mind, or by a human using pen and paper. See corresponding analysis of Claim 6.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
With respect to claim 19:
Step 2A Prong 1:
Claim 19 recites:
determining that the element is not accessed within the scope after the instructions to allocate the element and prior to the instructions to initialize the element.
Step (a) recites a “Mental Process” (i.e., observation, evaluation, judgment, and/or opinion) that can be performed in the human mind, or by a human using pen and paper. See corresponding analysis of Claim 9.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 6, 9-12, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Weingarten et al. (NPL "Inlining-Benefit Prediction with Interprocedural Partial Escape Analysis", hereinafter Weingarten) in view of Wimmer et al. (NPL "Initialize Once, Start Fast: Application Initialization at Build Time", hereinafter Wimmer).
With respect to claim 1:
Weingarten teaches A method comprising:
inlining source code (e.g., pg. 14: left column: last paragraph, “Listing 1. IntListMap”) to generate inlined code, wherein the inlined code comprises instructions to materialize an element within a scope (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”);
consolidating the inlined code (e.g., pg. 13: left column: second paragraph, “within the scope of inlined procedures”) to form consolidated code by moving the instructions to materialize the element to a point where the element escapes the scope (e.g., fig. 1 and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”).
Weingarten does not teach however Wimmer teaches
running a points-to analysis on the (e.g., pg. 184:4: Section 2.1: first paragraph, “The points-to analysis starts with all entry points, e.g., the main method of the application, and iteratively processes all transitively reachable methods until a fixed point is reached.”); and
reducing the (e.g., pg. 184:7: Section 2.4: second paragraph, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to reduce code size and improve code performance.
With respect to claim 2:
Weingarten teaches executing the reduced code (e.g., pg. 13: right column: second paragraph, “inlined procedures” and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→) ”), wherein the reduced code has a reduced execution time (e.g., pg. 21: left column: first half of “Dynamic allocations at runtime”, “We now have faster runtime, even though more bytes are allocated at runtime.”) as compared to the inlined code.
Weingarten does not teach however Wimmer teaches executing the reduced code (e.g., pg. 184:7: Section 2.4: second paragraph, in addition to reduced code, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to optimize performance object-oriented code at build time and run time.
With respect to claim 6:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
executing a partial escape analyzer to perform a partial escape analysis on the inlined code (e.g., pg. 13: right column: first paragraph, “Partial Escape Analysis (PEA) [50] is a control flow sensitive variant of Escape Analysis [7–9, 11, 12, 18, 25, 44, 55] … applying PEA within the scope of inlined procedures,”) to generate the consolidated code, wherein the partial escape analysis comprises:
identifying the scope of the inlined code (e.g., pg. 13: right column: first paragraph, “The analysis computes whether an object escapes outside the scope of the procedure”), and
identifying an access to the element as the point where the element escapes the scope and located prior to a return from the scope (e.g., pg. 15: left column: second paragraph – right column: first full paragraph, “In our example with the put(int, V) procedure, after executing the statement 𝑛0 ≡var boxed=new Integer(key) in line 6, 𝑂 maps the boxed value to a tuple whose integer field is set to the value of the parameter key:
O(𝑛0) = {boxed ↦→ (integer → key)}
Statements in line 7 and line 8 do not modify the boxed object, in other words O(𝑛1) = O(𝑛0) = O(𝑛2). However, 𝑛2 can exploit the mapping O, namely, 𝑛2 can be replaced with list[i].integer==key, because O(𝑛2) tells us that boxed is virtual (i.e. did not yet escape), and its value field is equal to key. The next statement 𝑛3 ≡list[last++]=boxed materializes the boxed object, since the reference to boxed escapes as part of the array-write. Mapping O(𝑛3) becomes:
O(𝑛3) = {boxed ↦→ boxed1}
which means that original allocation boxed is on this control flow path materialized under the name boxed1. PEA thus inserts the instruction var boxed1=new Integer(key) just before 𝑛3”).
With respect to claim 9:
Weingarten teaches wherein the instructions to materialize the element comprise instructions to allocate the element and instructions to initialize the element (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”):
determining that the element is not accessed within the scope after the instructions to allocate the element and prior to the instructions to initialize the element (e.g., pg. 15: left column: fifth paragraph, “Each allocated object is mapped to either a materialized value 𝑚 ∈ V, indicating that the respective object escaped and was allocated as another value𝑚; or to a sequence of field-value pairs 𝑓𝑗 →𝑥𝑗 , indicating the state of an object that did not escape (i.e. object that is virtual): O(𝑛) : V ↦→ V ∪ {( 𝑓0 →𝑥0, . . . , 𝑓𝑖 →𝑥𝑖 ) : 𝑓𝑗 ∈ S ∧ 𝑥𝑗 ∈ V}”).
Weingarten does not teach however Wimmer teaches (e.g., pg. 184:7: Section 2.4: second paragraph, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to improve code performance and reduce runtime.
With respect to claim 10:
Weingarten teaches
removing the initialization check after determining that the element is not accessed within the scope between instructions to allocate the element and instructions to initialize the element (e.g., pg. 15: left column: fifth paragraph, “Each allocated object is mapped to either a materialized value 𝑚 ∈ V, indicating that the respective object escaped and was allocated as another value𝑚; or to a sequence of field-value pairs 𝑓𝑗 →𝑥𝑗 , indicating the state of an object that did not escape (i.e. object that is virtual): O(𝑛) : V ↦→ V ∪ {( 𝑓0 →𝑥0, . . . , 𝑓𝑖 →𝑥𝑖 ) : 𝑓𝑗 ∈ S ∧ 𝑥𝑗 ∈ V}”), wherein the instructions to materialize the element comprise the instructions to allocate the element and the instructions to initialize the element (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”).
With respect to claim 11:
Weingarten teaches wherein the scope corresponds to a class method of a class and the element comprises an object instantiated from the class (e.g., fig. 1 and pg. 16: left column: first paragraph, “Figure 1. Simplified control flow(→) and data flow (d) of put. The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state.”).
With respect to claim 12:
Weingarten teaches A system comprising at least one processor; and an application that, when executing on the at least one processor, performs operations comprising (Weingarten’s method is to be performed by a computer. Therefore, the computer is implicitly disclosed.):
inlining source code (e.g., pg. 14: left column: last paragraph, “Listing 1. IntListMap”) to generate inlined code, wherein the inlined code comprises instructions to materialize an element within a scope (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”);
consolidating the inlined code (e.g., pg. 13: left column: second paragraph, “within the scope of inlined procedures”) to form consolidated code by moving the instructions to materialize the element to a point where the element escapes the scope (e.g., fig. 1 and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”).
Weingarten does not teach however Wimmer teaches
running a points-to analysis on the (e.g., pg. 184:4: Section 2.1: first paragraph, “The points-to analysis starts with all entry points, e.g., the main method of the application, and iteratively processes all transitively reachable methods until a fixed point is reached.”); and
reducing the (e.g., pg. 184:7: Section 2.4: second paragraph, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to reduce code size and improve code performance.
With respect to claim 16:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
executing a partial escape analyzer to perform a partial escape analysis on the inlined code (e.g., pg. 13: right column: first paragraph, “Partial Escape Analysis (PEA) [50] is a control flow sensitive variant of Escape Analysis [7–9, 11, 12, 18, 25, 44, 55] … applying PEA within the scope of inlined procedures,”) to generate the consolidated code, wherein the partial escape analysis comprises:
identifying the scope of the inlined code (e.g., pg. 13: right column: first paragraph, “The analysis computes whether an object escapes outside the scope of the procedure”), and
identifying an access to the element as the point where the element escapes the scope and located prior to a return from the scope (e.g., pg. 15: left column: second paragraph – right column: first full paragraph, “In our example with the put(int, V) procedure, after executing the statement 𝑛0 ≡var boxed=new Integer(key) in line 6, 𝑂 maps the boxed value to a tuple whose integer field is set to the value of the parameter key:
O(𝑛0) = {boxed ↦→ (integer → key)}
Statements in line 7 and line 8 do not modify the boxed object, in other words O(𝑛1) = O(𝑛0) = O(𝑛2). However, 𝑛2 can exploit the mapping O, namely, 𝑛2 can be replaced with list[i].integer==key, because O(𝑛2) tells us that boxed is virtual (i.e. did not yet escape), and its value field is equal to key. The next statement 𝑛3 ≡list[last++]=boxed materializes the boxed object, since the reference to boxed escapes as part of the array-write. Mapping O(𝑛3) becomes:
O(𝑛3) = {boxed ↦→ boxed1}
which means that original allocation boxed is on this control flow path materialized under the name boxed1. PEA thus inserts the instruction var boxed1=new Integer(key) just before 𝑛3”).
With respect to claim 19:
Weingarten teaches wherein the instructions to materialize the element comprise instructions to allocate the element and instructions to initialize the element (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”):
determining that the element is not accessed within the scope after the instructions to allocate the element and prior to the instructions to initialize the element (e.g., pg. 15: left column: fifth paragraph, “Each allocated object is mapped to either a materialized value 𝑚 ∈ V, indicating that the respective object escaped and was allocated as another value𝑚; or to a sequence of field-value pairs 𝑓𝑗 →𝑥𝑗 , indicating the state of an object that did not escape (i.e. object that is virtual): O(𝑛) : V ↦→ V ∪ {( 𝑓0 →𝑥0, . . . , 𝑓𝑖 →𝑥𝑖 ) : 𝑓𝑗 ∈ S ∧ 𝑥𝑗 ∈ V}”).
Weingarten does not teach however Wimmer teaches (e.g., pg. 184:7: Section 2.4: second paragraph, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to improve code performance and reduce runtime.
With respect to claim 20:
Weingarten teaches A non-transitory computer readable medium comprising instructions executable by at least one processor to perform (Weingarten’s method is to be performed by a computer. Therefore, the computer is implicitly disclosed.):
inlining source code (e.g., pg. 14: left column: last paragraph, “Listing 1. IntListMap”) to generate inlined code, wherein the inlined code comprises instructions to materialize an element within a scope (e.g., pg. 14: right column: last half paragraph – pg. 15: left column: first half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call, the resulting compilation unit would contain both the allocation and its usages.
for (i = 0; i < m.last; i += 2)
if (m.list[i].integer == 1)
return m.list[i + 1] = "one";
var boxed1 = new Integer(1);
m.list[m.last++] = boxed1;
return m.list[m.last++] = "one";”);
consolidating the inlined code (e.g., pg. 13: left column: second paragraph, “within the scope of inlined procedures”) to form consolidated code by moving the instructions to materialize the element to a point where the element escapes the scope (e.g., fig. 1 and pg. 16: left column: first full paragraph, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”).
Weingarten does not teach however Wimmer teaches
running a points-to analysis on the (e.g., pg. 184:4: Section 2.1: first paragraph, “The points-to analysis starts with all entry points, e.g., the main method of the application, and iteratively processes all transitively reachable methods until a fixed point is reached.”); and
reducing the (e.g., pg. 184:7: Section 2.4: second paragraph, “Similarly, null checks are removed when the points-to analysis marks a type state as never null.”).
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 Weingarten with the invention of Wimmer to reduce code size and improve code performance.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Weingarten in view of Wimmer as applied to claims 1 and 12 above, and further in view of Zhao et al. (NPL "Function outlining and partial inlining", hereinafter Zhao).
With respect to claim 3:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”).
Weingarten does not teach however Zhao teaches outlining the source code to generate outlined code prior to inlining the source code, wherein inlining the source code comprises inlining the outlined code (e.g., fig. 4 and pg. 7: left column: first figure, “Outlining followed by inlining improves performance.”).
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 Weingarten with the invention of Zhao to allow more inlining and prevent code bloating.
With respect to claim 13:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”).
Weingarten does not teach however Zhao teaches outlining the source code to generate outlined code prior to inlining the source code, wherein inlining the source code comprises inlining the outlined code (e.g., fig. 4 and pg. 7: left column: first figure, “Outlining followed by inlining improves performance.”).
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 Weingarten with the invention of Zhao to allow more inlining and prevent code bloating.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Weingarten in view of Wimmer as applied to claims 1 and 12 above, and further in view of Zhao and Budimlic et al. (NPL "Improving Compilation of Java Scientific Applications", hereinafter Budimlic).
With respect to claim 4:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”):
(e.g., pg. 15: left paragraph: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Zhao teaches outlining the source code, prior to inlining the source code (e.g., fig. 4 and pg. 7: left column: first figure, “Outlining followed by inlining improves performance.”)
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 Weingarten with the invention of Zhao to allow more inlining and prevent code bloating.
Weingarten modified by Zhao does not teach however Budimlic teaches (e.g., pg. 255: left column: Section 2.1, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method.”).
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 Weingarten with the invention of Zhao and Budimlic to ensure inlining will occur under proper circumstances, such as code correctness.
With respect to claim 14:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”):
(e.g., pg. 15: left paragraph: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Zhao teaches outlining the source code, prior to inlining the source code (e.g., fig. 4 and pg. 7: left column: first figure, “Outlining followed by inlining improves performance.”)
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 Weingarten with the invention of Zhao to allow more inlining and prevent code bloating.
Weingarten modified by Zhao does not teach however Budimlic teaches (e.g., pg. 255: left column: first full paragraph, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method.”).
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 Weingarten with the invention of Zhao and Budimlic to ensure inlining will occur under proper circumstances, such as code correctness.
Claims 5, 7, 8, 15, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Weingarten in view of Wimmer as applied to claims 1 and 12 above, and further in view of Budimlic.
With respect to claim 5:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”):
Weingarten does not teach however Budimlic teaches inlining the instructions to materialize the element in a synthetic method to form the inlined code (e.g., fig. 2 and pg. 255: left column: first full paragraph, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method. Figure 2 shows an example of a synthetic method being created to pass an inlined array to it.”).
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 Weingarten with the invention of Budimlic to ensure inlining will occur under proper circumstances, such as code correctness.
With respect to claim 7:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first figure, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
consolidating the instructions to materialize the element (e.g., pg. 15: left column: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Budimlic teaches (e.g., fig. 2 and pg. 255, “Fig. 2 Example of creating a synthetic method for method foo so that an inlined version of array p2Array can be passed to the method call.”) and allocating the element and the supplemental element as one unit (e.g., pg. 263: left column: third paragraph, “Object combining (Veldema et al. 2002) seeks to join together objects that have relatively the same life span. This technique joins objects together by appending fields from one object to another. As a result, multiple objects are (de)allocated at the same time, thereby reducing the strain on memory management”).
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 Weingarten with the invention of Budimlic to improve application performance and enable inlining to be more effective.
With respect to claim 8:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first figure, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
consolidating the instructions to materialize the element (e.g., pg. 15: left column: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Budimlic teaches (e.g., pg. 263: left column: third paragraph, “Object combining [29] seeks to join together objects that have relatively the same life span. This technique joins objects together by appending fields from one object to another. As a result, multiple objects are (de)allocated at the same time, thereby reducing the strain on memory management”) in a synthetic method for an application comprising the scope (e.g., pg. 255: left column: third paragraph, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method.”.
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 Weingarten with the invention of Budimlic to improve application performance and enable inlining to be more effective.
With respect to claim 15:
Weingarten teaches wherein inlining the source code further comprises (e.g., pg. 14: right column: last half paragraph, “If something were to ‘convince’ the inliner that there is benefit in inlining the put call” and source code in “Listing 1. IntListMap”):
Weingarten does not teach however Budimlic teaches inlining the instructions to materialize the element in a synthetic method to form the inlined code (e.g., fig. 2 and pg. 255: left column: first full paragraph, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method. Figure 2 shows an example of a synthetic method being created to pass an inlined array to it.”).
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 Weingarten with the invention of Budimlic to ensure inlining will occur under proper circumstances, such as code correctness.
With respect to claim 17:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first figure, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
consolidating the instructions to materialize the element (e.g., pg. 15: left column: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Budimlic teaches (e.g., fig. 2 and pg. 255, “Fig. 2 Example of creating a synthetic method for method foo so that an inlined version of array p2Array can be passed to the method call.”) and allocating the element and the supplemental element as one unit (e.g., pg. 263: left column: third paragraph, “Object combining (Veldema et al. 2002) seeks to join together objects that have relatively the same life span. This technique joins objects together by appending fields from one object to another. As a result, multiple objects are (de)allocated at the same time, thereby reducing the strain on memory management”).
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 Weingarten with the invention of Budimlic to improve application performance and enable inlining to be more effective.
With respect to claim 18:
Weingarten teaches wherein consolidating the inlined code further comprises (e.g., fig. 1 and pg. 16: left column: first figure, “The boxed allocation is moved to latest point before boxed becomes materialized and loads are replaced with scalars from the virtual state...The store node causes the object to escape after the loop exit (esc −−→)”):
consolidating the instructions to materialize the element (e.g., pg. 15: left column: last paragraph, “statement 𝑛3 ≡list[last++]=boxed materializes the boxed object”)
Weingarten does not teach however Budimlic teaches (e.g., pg. 263: left column: third paragraph, “Object combining [29] seeks to join together objects that have relatively the same life span. This technique joins objects together by appending fields from one object to another. As a result, multiple objects are (de)allocated at the same time, thereby reducing the strain on memory management”) in a synthetic method for an application comprising the scope (e.g., pg. 255: left column: third paragraph, “Our object inlining transformation replaces an inlineable object with inlined fields and an inlineable array with arrays of inlined fields. The transformation creates a synthetic method when encountering an inlineable object or array passed to a method call. It then replaces the original method call with a call to the synthetic method.”.
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 Weingarten with the invention of Budimlic to improve application performance and enable inlining to be more effective.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHELLE XUE HAN whose telephone number is (571)270-3362. The examiner can normally be reached Mon-Fri (7:30-5), Every 2nd Fri off.
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 Sough can be reached at (571) 272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHELLE XUE HAN/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights