$3DETAILED ACTION
This action is responsive to the Application filed 8/06/2024.
Accordingly, claims 1-20 are submitted for prosecution on merits.
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.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2 step analysis.
Step I: this is directed to a method/process category
Step 2A.
Prong One:
Based on the elements recited as “identifying” (load and store operations in code), “assigning” (metadata of each operation), “generating” (oracle conditions for the program), the method claim is directed to the abstract idea of organizing, identifying, and manipulating data according to logic rules to resolve an optimization problem (register promotion) in that the “identifying” is merely data collection, the “assigning” being act of classifying or indexing based on structural relationship, and “generating oracle conditions” being a mathematical/logical calculation or rule-setting step. That is, per MPEP 2106.04(a)(2) the recited steps rely entirely on mathematical logic, data manipulation and information processing (i.e. Digitech and Electric Power Group case) which can all be performed mentally or via generic computer or means of pen/paper
Prong Two:
The element recited as “to facilitate register promotion” merely states a result or a goal, without providing a specific, structural, technological mechanism to achieve it. MPEP2106.04(d)(1)
The clause recited as “where one or more indices … are not known at compile time” merely highlights that the claim covers a theoretical problem-solving framework in terms of “oracle condition”, rather than implementing a concrete technical solution that actually modifies computer hardware or software operations.
The claim does not integrate the abstract idea into a practical application because it fails to recite an improvement to the functioning of a computer itself, or to a technology.
Step 2B:
Individually, the elements recited as “identifying”, “assigning”, “generating” steps are well-understood, routine, and conventional activities in the computer field and design – MPEP 2106l.05(d)
The additional elements such as “facilitate register promotion”, “indices … are not known at compile time” and “oracle conditions” have been interpreted as a static setting, an intended utility or result.
When construed in an ordered combination, the above elements do not represent a non-conventional arrangement of steps that yield an inventive technological result; thus, they cannot add significantly more to the abstract Idea understood from Step IIA, prong one above.
In short, the method claim appears to apply the abstract Idea on a generic computer capable of compile-time logic – MPEP 2106l.05(f)
Claim 1 is deemed non eligible under the 35 USC § 101 statute
Claims 16 and 20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 16 and 20 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2 step analysis.
A. Eligibility of claim 16
Step I, this claim is directed to an apparatus/system category
Per Step2A, prong one:
This claim recites “identifying” (load and store operations in code), “assigning” (metadata of each operation), “generating” (oracle conditions for the program) exactly as in claim 1; and as set forth above, these steps amount respectively, to merely data collecting, classifying or indexing based on structural relationship, and relying on a mathematical/logical calculation or rule-setting step; which fall under the activities of a Abstract Idea that includes organizing, identifying, and manipulating data according to logic rules to resolve an optimization problem (register promotion), ad all of which can be performed by a human mind, a generic computer and via pen/paper. MPEP 2106.04(a)(1)(2)
Per step2A, prong two
Claim 16 recites elements such as “to facilitate register promotion”, “indices … are not known at compile time” and “oracle conditions” and these are construed as mere intended use - MPEP 2106.04(d)(1) – or extra-solution measure - - as opposed to presenting specific steps or arranged mechanism that show transformation or improvement to the computer field in which the abstract idea operates. Claim 16 fails to integrate the Abstract Idea into a practical application.
Per step 2B,
When construed in an ordered combination or individually, the additional elements – i.e. as “to facilitate register promotion”, “indices … are not known at compile time” and “oracle conditions” - do not represent a non-conventional arrangement of synergic steps that yield an inventive technological result; but instead, amount to mere expression of intended result - MPEP 2106.04(d)(1) - or static setting of no-relevance – MPEP 2106.05(g) - to the targeted “register promotion”; thus, they cannot add significantly more to the abstract Idea understood from Step IIA, prong one above. In other words, the above subject matter appears to apply the abstract Idea on a generic computer capable of compile-time logic – MPEP 2106l.05(f)
Claim 16 is deemed non-eligible under the 35 USC 101 statute.
B. Eligibility of claim 20
This media/product claim includes the same limitations as method claim 1.
Per step 2A, prong one, this claim recites elements actions -- (“identifying”, “assigning” (metadata), “generating” (conditions) -- that fall under the mental processes - MPEP 2106.04(a)(2) - via use of mathematical computer techniques or pen/paper, and as such, is directed to a Abstract Idea.
Per step 2A, prong two, the elements recited as “to facilitate register promotion”, “indices … are not known at compile time” and “oracle conditions” are construed as rather geared toward extra-solution description or intended use – MPEP 2106.05(c ) (f) (g) - not for implementing a non-conventional transformation.
The product claim does not integrate the Abstract Idea into a practical application.
Per step 2B
The additional elements – i.e. as “to facilitate register promotion”, “indices … are not known at compile time” and “oracle conditions” - construed individually or within an order do not represent a non-conventional arrangement of synergic steps that yield an inventive technological result; but instead, amount to mere expression of intended result - MPEP 2106.04(d)(1) - or static setting of no-relevance – MPEP 2106.05(g) - to the targeted “register promotion”; thus, they cannot add significantly more to the abstract Idea understood from Step IIA, prong one above.
Claim 20 is deemed non-eligible under the 35 USC 101 statute.
Step2A analysis of the dependent claims.
Claims 2 and 17 recite type of metadata for use in constructing an array; but this descriptive limitation cannot yield a functional improvement to the Abstract Idea of prong one.
Claims 3 ad 18 recite “determining”, “assigning” and “generating” (a condition) which reminisce of mental activities set forth with step 2A, prong One.
Claims 4 and 19 recite “creating” a new definition for each condition; and this activity amounts to a extra-solution that fail to provide a transformation or inventive addition to the computer field in which the abstract Idea operates.
Claim 5 recites condition to select a reaching definition, which broadly interpreted fall under activity of a mental process.
Claims 6 and 7 recite selecting or creating a definition for an operation based on a differential value obtained from a mathematical means of calculating a distance or difference within a range, and this combination of mental activities (select, create a definition) with mathematical means (calculate a difference) are well known activities that characterize a mental process for a Abstract Idea type judicial exception defined by the circuit courts.
Claims 8 and 9 recite uniformity analysis on variables in generating a condition and use of a strategy to reduce (intended use) the number of comparisons, which merely express an intended result or a well-understood technique of analyzing data by a mental process in that these can be viewed as generic application of a optimization strategy to reorganize data under the well-understood activities of an Abstract Idea context.
Claim 10 recites use of conditional select instructions as conditions but the generating of conditions has been considered activity of the Abstract Idea type exception.
Claims 11, 12 recite condition being geared for multiple constant loads and stores and using a SSA to support the control flow; none of that clearly showing mechanism details to improve a technological field
Claim 13 recites metadata being added to the representation code at the compiler front; but using added static metadata cannot be viewed as implementing a detailed mechanism to improve a technological field.
Claims 14, 15 depict generic use of condition on an intermediate representation, where the array is of type multi-dimensional; those static and additional characteristics cannot be viewed as description of a detailed mechanism to improve a technological field.
Claims 1, 16, 20 are deemed non-eligible under 35 USC § 101 statute.
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, 3-5, 8-16, 18-20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over in view of Callahan et al, “Improving Register Allocation for Subscripted Variables”, ACM SigPlan’90, June 1990, pp. 53-65 (herein Callahan) in view of Lo et al, USPN: 6,151,706 (herein Lo)
As per claim 1, Callahan discloses a method of generating code for a graphics processing unit (GPU – Chaitin style graph coloring register allocation – R bottom pg. 53; MIPS R2000, floating point – top R pg. 61), the method comprising:
identifying load and store operations (Store: statement writes to the location, Load: statement reads from the location – top R pg. 53) in program code that access an array of structures (subscripted arrays – bottom R pg. 53; matrix multiply – Appendix B, pg. 65; matrix Multiplication – R bottom col. pg. 62 to L top, col. pg. 63; sec. 2.3.3 - iteration spaces: loops, loop nest, loop body - pg. 60-61; sec. 2.3.2: array, outer loop, inner loop – pg. 59);
assigning metadata (subscripted variables – Abstract, Introduction pg 53; sec. 2.1; dependence graph: node v, edge e, threshold г(e), pg.54-55 - – Note1: graph node subscripts or indices associated with dependency by way of array, loops or matrices related iterations or operations in which a load and store value dependency exists and threshold of loop dependence reads on metadata associated with each such L or S operation construed from nodes and edge definition – definitions along the control-flow paths - middle L, pg. 58 on a dependency graph – sec. 2: dependence graph – L col. pg. 54) to each of the identified load and store operations (see location data is written or read from - top R pg. 53),
the metadata associated with each operation (see above) representing a structure of the array (Note2: mapped loop iterations containing multiple instances of Load and Store operations resulting in a dependence graph modeled for analytic traversal reads on a software array, a Array of Structures or Structure of Arrays; i.e. AoS or SoA, that can be traversed for a scalar replacement and reduction of register pressure – sec 2.2, L bottom pg. 55 to sec. 2.2.1, pg. 57); and
generating oracle conditions for the program code (sec. 2.2.1 pg. 57; Reference Replacement, Register to register moves, code motion – pg. 56; sec 2.2.1 pg. 57; Initialization: many transfers will be eliminated by live-range coalescing in the compiler’s register allocator – L col. pg. 57) based on the metadata (see above),
Callahan does not explicitly disclose
(i) generating oracle conditions for program code to facilitate register promotion,
(ii) wherein one or more indices of the array accessed by the load and store operations are not known at compile time.
As for (i)
The use of a dependency graph as basis to apply scalar replacement in Callahan is driven from the basis of pruning away inconsistent dependencies between inner loop and outer loops in relation to source and sink flow interpreted along a threshold of consistency (sec 2.1.1 and 2.1.2 pg. 54 to pg. 55) from a dependency graph analysis and pruning where a scalar can be speculatively registered based on whether a true flow of values can be identified as most consistent and transitive control loop flow associated with source and sink operations, the consistency thereof rendering valid a definition of a scalar replacement – temporary value that can be kept in a register – for a source/store relationship with a sink/load; that is, after pruning inconsistent dependencies deemed unprofitable to the replacement algorithm (L col. pg. 58), determining existence of a consistent input dependency from a source (store) to a sink (load) being condition for moving a load flow out of the loop consistently after some iterations, will validate a presumption by the algorithm in which the temporary value assignment to a register is to be confirmed so to exploit direct store of store/load operations data to register, where the most recent definitions and naming scalar temporaries consistently within a given loop (pg. 58) can be retained to exploit this speculative register storage. In other words, the compiler context in Callahan identifies a consistent source-to-sink control flow path in order to prove that this store (Source) will always flow into a specific Load (Sink) a set of iterations later, thereby effect of keeping that temporary scalar in the register would bypass the RAM entirely as result of the source-sink consistency validation. Thus, use of a speculative scalar replacement that relies on consistent dependency a control flow between store and load after some judicious iteration verifications or graph unrolling (pg. 59) to consolidate the speculated retention of temporary scalar in register entails an algorithm attempt to bypass costly memory operations to seek affirmation on Load/Store effective value by way of promoting use of register – refer herein as (*) - to accelerate iterative loop code and resolution of addresses at each layer of the iterations.
As for (ii)
Callahan’s pruning technique explicitly demonstrates that the absolute indices and loop boundaries do not need to be known at compile time; as only the geometric distance vector (the stride) matters as the dependency analysis calculates the difference between the indices, with the difference vector reset for each new iteration (R col. pg. 59) by the algorithm moving dependences inward to the innermost loop in consideration of stride (bottom R, pg 58), shortening distances between references to the same array location to make the scalar replacement visible (sec 2.3 pg.58), the replacement algorithm configured to allow scalar replacement to bypass RAM route, on basis of ascertaining consistent dependencies of source-sink control flow via a threshold number of graph unrolling instances (pg. 59) at the beginning of which, a threshold of a dependence restarts from zero. That way, the compiler can safely prune or preserve graph dependencies based on this stride alone, enabling the compiler to use a distance difference metric as compile-time constant to achieve flawless register promotion for complex array structure completely independent of runtime index values – referred herein as (**)
Lo discloses use of speculative structuring of load and stores (col. 3 li. 37-65) to implement code motion using SSA representation to eliminate redundancy of paths and retain some paths of graph representation deemed more efficient that others (claim 1 pg. 15) using a optimizing compiler that applies partial elimination and register promotion (col. 4 li. 65 to col 5 li. 24) including therewith speculative code motion at compile time for loads and stores in architectures using MIPS R10000 associated with Silicon Graphics(register promotion, before code generation and register allocation - col. 12 li .28 to col 13 li. 6)
Therefore, based on the pruning of dependency graph (sec 2.1.2 R col. pg.54) and code motion in Callahan (L col pg. 56) experiment for rewriting subscripted variable as scalar for an improved register allocation (top L pg. 54), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the scalar replacement algorithm that analyze source-sink (store-load) relationship in control flow observed from a dependency graph via indices metadata thereon, so that preservation of scalar-register assignment by the algorithm based on identifying consistent dependence between such control flow would enable the speculated scalar value to be retained in the assigned register, in order to form oracle code to facilitate register promotion – as in Lo code motion, and as set forth in (*); where in doing so, the compiler context associated this scalar replacement and graph pruning would rely only on the distance separating two reference to a same location of the array representative of the dependency graph in the sense that one or more indices of the array accessed by the load and store operations are not known at compile time – as set forth above in (**); because
loop unrolling based on indices of loop operations as represented in a dependency graph in relation to source-sink (store-load) operations required per a multi-loop complexities and data dependency entails a heavy amount of memory address and actual values resolution at each stage of a iteration, which can incur unpredicted change at each increment like modification by a alias, which can further cause delay in processing of computation intensive applications, graphics programs or software experiments/designs having large and complex memory operations and accesses; and using this scalar/register assignment under this speculative scalar replacement technique that relies on distance between consecutive references and liveliness of dependencies between source and sink control flow as set forth above, in order to prune away store-load relationships deemed non-profitable to the replacement algorithm while keeping the most consistent (guaranteed to realize) source-sink control flows, as a previously speculated replacement scalar associated with a given load or store as part of this source-sink liveliness and consistency control flow check, can be retained by committing a register entity bypassing thereby standard memory sequence of operations and delay implication thereby required to validate or affirm the exact scalar for each such operation at a given stage of iterating loop when the risk of reading an improper value at a location is always significant due to lack of prior knowledge as to the state of change in values during runtime; e.g. one of a complex and large computational intensive program such as a architecture to perform graphics program as in Lo.
As per claim 3, Callahan discloses method of claim 1, wherein generating the oracle conditions comprises:
determining a set of possible addresses (R col. pg. 55 to L col. pg. 56 - Note3: true dependence algorithm – sec 2.1.1 pg. 54 - to generate temporaries at specific locations - i.e. of graph peeling - at which a register is designated to hold the temporary scalar identified by the algorithm from a peeled iteration reads on address of a dependency flow at which to generate a temporary value) accessed by each load (which possible generators reach a load along the control flow paths – L col. pg. 58) or store operation based on the metadata (see indices i, j, k in Initialization - R col. pg. 56 to L col. pg. 57);
assigning a scalar to each unique address (sec 2.2: scalar replacement; refer to possible addresses on graph flow peeling and register store of a scalar per Note3 from above) in the set of possible addresses; and
generating a condition (refer to IF, else statements for e, ev, eg for source or sink with true output dependence or true input dependence - Prunegraph: L col. pg.55) for each scalar that compares an address of the load or store operation with the address corresponding to the scalar (sec 2.2: Scalar Replacement - pg. L col. pg. 55 to L col. pg. 56; i.e. reuse-generating dependences 1, 2, 3; a consistent output dependence carried … from a definition, consistent input dependence – Code Motion: R col. pg. 56).
As per claim 4, Callahan discloses method of claim 3, wherein the oracle conditions for store operations create new definitions (definition of A(I) in either statement S1 or S2 can provide the value used in statement S3 – L col. pg. 58; Reference Replacement: if gi is a load from memory then we must insert a “load” T= gi immediately before the generating statement… If gi is a definition then we must insert a “store” of form gi=T following the generating statement- R col pg. 55) for each scalar assigned to an address.
As per claim 5, Callahan discloses method of claim 4, wherein the oracle conditions for load operations select a reaching definition (determine if a definition … reaches a load on all paths – bottom, L pg. 58) for each scalar based on the new definitions created by the store operations (determining which possible generators reach a load along the control flow paths, determining the profitability of scalar replacement on each generator – L col. pg. 58; true dependence if the first statement writes to the location and the second reads from it – top R col. pg .54 – Note4: determining that a load is reachable on all paths from a store at one a location at which a register can be designated to hold a scalar reads on reaching definition for load operation for each scalar pertaining to a definition created by a store operation by the algorithm).
As per claim 8, Callahan discloses method of claim 1, further comprising:
performing uniformity analysis (treats backward and forward edges uniformly when determining the number of temporaries – R col. pg. 55) on index variables (see metadata per claim 1) used in the load and store operations; and
generating different oracle conditions (refer to claim 1) based on whether an index variable (see above) is determined to be uniform (see treats edges uniformly from above) or varying across threads of the GPU.
As per claim 9, Callahan discloses method of claim 8, wherein the oracle conditions for uniform index variables use a divide-and-conquer strategy (sec 2.3.2: restrict … to consistent dependences that contain only one loop induction variable in each subscript position … whenever a threshold of a dependence becomes zero ,the next inner non-zero entry in the distance vector for the dependence becomes the new threshold and the loop corresponding to that new entry becomes the new carrier – L col. Middle to R col. pg. 59) to reduce a number of comparisons needed (else statements for e, ev, eg for source or sink with true output dependence or true input dependence - Prunegraph: L col. pg.55).
As per claim 10, Callahan discloses method of claim 8, wherein the oracle conditions for varying index variables use conditional select instructions (e.g. procedure prunegraph(G): if else statements – L col. pg. 44; reuse-generating dependences are 1, 2, 3 – R col pg. 55 top L col. pg. 56; list of the responsibilities of the algorithm – L col. pg. 58) to avoid divergent control flow.
As per claim 11, Callahan discloses method of claim 1, wherein the oracle conditions handle multiple non-constant stores and loads to the same location (if the edge is not carried by the unrolled loop, then it is copied into the new loop body – R col. pg. 59) in the array.
As per claim 12, Callahan discloses method of claim 1, wherein the oracle conditions are generated using a static single assignment (SSA) algorithm that supports scalarization (to keep the values in temporary variables correct across the iterations of the innerloop, we insert, for each generator gi, the following block of assignment … - L col. pg. 56) amid control flow.
As per claim 13, Callahan discloses method of claim 1, wherein the metadata (see Note1 in claim 1) is added to an intermediate representation (sec. 2.1; dependence graph: node v, edge e, threshold г(e) - pg. 54-55) of the program code by a compiler front-end (sec 2: Method, compiler of the M120 - L col. pg. 54).
As per claim 14, Callahan discloses method of claim 13, wherein the oracle conditions are generated on the intermediate representation (procedure PruneGraph (G) – L col. pg. 55).
As per claim 15, Callahan discloses method of claim 1, wherein the array of structures is a multi-dimensional array (sec 2.1 pg. 54-55 -Note4: hierarchized load/store relationships set as branches of a dependency graph where each branch can be an array of relationships between read/write within a iteration reads on hierarchy of relationship arrays combined into a dependence graph being formed as multi-dimensional array ).
As per claim 16, Callahan discloses an apparatus for generating code for a graphics processing unit (GPU), comprising: a memory; and at least one processor coupled to the memory and configured to:
identify load and store operations in program code that access an array of structures;
assign metadata to each of the identified load and store operations, the metadata associated with each operation representing a structure of the array; and
generate oracle conditions for the program code based on the metadata to facilitate register promotion, wherein one or more indices of the array accessed by the load and store operations are not known at compile time.
(all of which having been addressed in claim 1)
As per claim 18, Callahan discloses apparatus of claim 16, wherein the at least one processor is further configured to generate the oracle conditions by:
determining a set of possible addresses accessed by each load or store operation
based on the metadata;
assigning a scalar to each unique address in the set of possible addresses; and
generating a condition for each scalar that compares an address of the load or store
operation with the address corresponding to the scalar.
(Refer to rejection of claim 3)
As per claim 19, Callahan discloses apparatus of claim 18, wherein the oracle conditions for store operations create new definitions for each scalar assigned to an address.
(Refer to rejection of claim 4)
As per claim 20, Callahan discloses a computer-readable medium storing computer executable code for generating code for a graphics processing unit (GPU), comprising code to:
identify load and store operations in program code that access an array of structures;
assign metadata to each of the identified load and store operations, the metadata
associated with each operation representing a structure of the array; and
generate oracle conditions for the program code based on the metadata to facilitate
register promotion, wherein one or more indices of the array accessed by the load and
store operations are not known at compile time.
(All of which having been addressed in claim 1)
Claims 2, 17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over in view of Callahan et al, “Improving Register Allocation for Subscripted Variables”, ACM SigPlan’90, June 1990, pp. 53-65 (herein Callahan) in view of Lo et al, USPN: 6,151,706 (herein Lo) further in view of Raikin et al, USPN: 11,321,092 (herein Raikin)
As per claim 2, Callahan does not explicitly disclose method of claim 1, wherein the metadata includes:
an offset indicating a field offset within the structure;
a length indicating a dimension of the array; and
a stride indicating a size of the structure.
Callahan discloses analyzing the dependency graph in the attempt to generate scalar/register assignment according to a speculative values replacement (sec. 2.1.1 pg. 54) algorithm that unrolls the loop elements on the graph, and determine node/edge relationships for load and store control flow to be mutually reachable and consistent (pg. 55, 58) so to promote direct use register in the course of load/store programmatic development, where the unrolling heuristic cache locality using unroll threshold size that shorten distances between source and sink accesses directed at a same location (sec 2.3.2 pg. 59) so to better exploit cache proximity based on stride between accesses from a array operation to a next array access. Therefore, the traversing of indices on the graph node entails use of offset increment and length of the indexed array.
Raikin discloses vector processor comprising a tensor descriptor memory (TDM) structure to store information such as base address, dimension offsets, stride and sizes (col. 4, li. 41-47) so that dimension indexes of the tensor can be used to construct vector representation of the granular effect of reads and writes corresponding to the tensor model under consideration by a ISA architecture for implementing multi-dimension computational model (col. 3 li. 34-55), where ISA definition of a store Tensor instruction include tensor metadata such base address, dimension offsets, strides and sizes that be extracted from the TDM in memory (col.8 li. 2-10)
Therefore, based on the calculation of distance and stride to implement a scalar replacement that favor cache spatial proximity and avert delay of miss in Callahan, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement metadata associated with definition of a store operation on a dependency graph so that the metadata include
an offset indicating a field offset within the structure;
a length indicating a dimension of the array; and
a stride indicating a size of the structure; as set forth in Raidin; because
distance as difference calculated between two access points of a graph in Callahan replacement technique utilizes length of the array implementing different nodes dependencies on the graph, and offset dimensions can be used to shorten the gap in iterating a next analytic step in which load and store operations and indexes from the dependency graph can be fetched during runtime of algorithm which is being configured to affirm or deselect a relationship in which a definition for store locations on the dependency chain can be made consistent and reachable for a subsequent load to actually commit a scalar to a register, where offset attached to each predefined distance, or stride, of the incremental graph unrolling - for detecting a reaching definition as criterion for the speculative scalar register allocation - would also obviate payload for the algorithm.
As per claim 17, Callahan discloses apparatus of claim 16, wherein the metadata includes:
an offset indicating a field offset within the structure;
a length indicating a dimension of the array; and
a stride indicating a size of the structure.
(refer to rationale of claim 2)
Allowable Subject Matter
Claims 6 and 7 are objected to as being dependent upon a rejected base claim, but would be allowable (pending resolution of any outstanding rejection of another type) if rewritten in independent form including all of the limitations of the base claim and any intervening claims, as following:
(Claims 6 and 7):
method of claim 1, wherein generating the oracle conditions further comprises:
for each store operation:
calculating a pointer difference between a pointer operand of the store operation and a base pointer of the array;
generating a select instruction that conditionally selects a stored value of the store operation based on comparing the pointer difference to each slot accessed by the load and store operations; and
creating a new definition for each scalar mapped to the store operation using the select instruction;
for each load operation:
calculating a pointer difference between a pointer operand of the load operation and the base pointer of the array;
generating a select instruction that conditionally selects a reaching definition of each scalar mapped to the load operation based on comparing the pointer difference to each slot accessed by the load and store operations,
wherein the reaching definition is determined using the new definitions created for the store operations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
July 09, 2026
Prosecution Insights