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 drawing submitted on October 13, 2025, to replace Figure 5 has been accepted and entered into the record.
Response to Arguments
Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim 1-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over “The reconfigurable streaming vector processor (RSVP)” by S. Ciricescu; R. Essick; B. Lucas; P. May; K. Moat; J. Norris; M. Schuette; A. Saidi (hereinafter Ciricescu) in view of Yudanov US Patent 11,355,170 (hereinafter Yudanov).
As per claim 18, Ciricescu teaches a system comprising:
a processor comprising at least one core to execute instructions (see page 1, last paragraph “We have implemented a complete system…”, ARM9 host processor coupled with the vector coprocessor in the SoC platform; see also page 3, first column, last paragraph); and
a memory coupled to the processor (Page 7, second column, paragraph “The structure of our implementation appears…” RSVP system includes main memory accessed by both the host ARM9 and the RSVP processor via the BIG memory interface), the memory comprising:
a first memory bank to store configuration information (see last two paragraphs on page 7, the architecture stores configuration via “constants and tunnels” and control registers for vector-stream units);
a second memory bank to store first vector data (see page 5, last paragraph and Fig. 8, Input VSU (vector stream units) fetch input vectors from memory (e.g. VSU1));
a third memory bank to store second vector data (see Fig. 2, system features multiple input VSUs (IVSU1, IVSU2, IVSU3), each sourcing separate vectors); and
a reconfigurable vector processor to perform a vector computation on the first vector data and the second vector data, and provide result vector data to at least one of the second memory bank and the third memory bank (The RSVP is a reconfigurable vector coprocessor that executes vector operations on streams and writing output to memory via OVSU0, see Fig. 10), the reconfigurable vector processor comprising:
a first functional unit to perform a first vector operation using at least one of the first vector data or the second vector data (see Fig. 10, the RSVP includes a set of function units e.g., multiplier, adder and shifter that are configured to perform vector operations on input streams); and
a second functional unit to perform another vector operation (see Fig. 10, multiple distinct function units are available e.g., adder, multiplier and shifter), wherein:
in a first configuration, the second functional unit is coupled to the first functional unit; and in a second configuration, the second functional unit is independent of the first functional unit (the architecture supports deep reconfigurable pipeline, chaining function units in the datapath, or reconfiguring them independent per cycle – enabling both chained and independent configurations. For instance, see page 3, paragraph 3 “chaining multiple function units together”);
Ciricescu did not teach that the processor is integrated into the memory. However, the secondary art Yudanov teaches that the processor is integrated into the memory as can be shown from Fig. 6, wherein the processor is inside the memory. Also, as showing in col. 2, lines 12-42, processing-in-memory, for the purpose of improving throughput while avoiding exorbitant costs.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teaching of Yudanov of utilizing PIM system into the invention of Ciricescu to improve performance and reduced energy consumption by minimizing data movements.
As per claim 19, Ciricescu teaches the system of claim 18, wherein the processor is to send first configuration information to the memory, and in response to the first configuration information the memory is to dynamically configure the reconfigurable vector processor to have the first configuration (The host processor ARM9 sends configuration information such as vector addresses, shapes, scalar values to memory mapped registers or memory, via API (i.g., _vloop(), _vsetz(), etc section 4.1, page 4-5). The RSVP retrieves these configurations from memory to dynamically configure itself, including: vector shape and location (via VSU registers), accumulators and scalar registers, and the dataflow graph that dictates the processing pipeline, section 4.2 “The RSVP processor responds by taking control of execution flow and memory, retrieves the specified DFG from memory, and executes it..”)
As per claim 20, Ciricescu teaches the system of claim 19, wherein the processor is to send a first vector instruction of an instruction set architecture to the memory, and in response to the first vector instruction, the reconfigurable vector processor is to perform the vector computation, provide the result vector data to the at least one of the second memory bank and the third memory bank (the host processor sends a “vector instruction” via function like _vloop(graph_addr, n) to initiate execution of a linear DFG (section 4.2 and 4.3); The RSVP then retrieves the graph from memory (_vload()), executes the vector computation (_vloop()), and writes the result to the output memory using output VSU, Fig. 6), and send a status message to the processor to inform the processor regarding completion of the first vector instruction (see first paragraph of page 5 “When it has completed, control is returned to the host processor”; Further, the RSVP design includes a status/control block, see Figure 10).
As per claim 1, Ciricescu teaches an apparatus comprising:
a die comprising a memory (RSVP SoC implementation contains both ARM9 core and RSVP on a single die, see last paragraph of page 1 and figure 9), the memory comprising:
one or more memory layers having a plurality of banks to store data (see Fig. 2 and Fig. 10, multiple banks/arrays IVSU1-3 and OVSU0); and
at least one complementary metal oxide semiconductor (CMOS) layer (first paragraph of page 2, CMOS and Fig. 9) comprising at least one reconfigurable vector processor (RSVP), the at least one reconfigurable vector processor to perform a vector computation on input vector data obtained from at least one bank of the plurality of banks and provide processed vector data to one or more banks of the plurality of banks (see section 4.1-4.2, and rejection of claim 18 above).
As per claim 2, Ciricescu teaches the apparatus of claim 1, wherein the at least one reconfigurable vector processor comprises a multi-stage functional unit to perform the vector computation (see fig. 7 and page 3, paragraph starts with “Deep pipelining is possible because…” deep chained functions units creating an N-Stage pipeline);
Ciricescu did not teach that the processor is integrated into the memory. However, the secondary art Yudanov teaches that the processor is integrated into the memory as can be shown from Fig. 6, wherein the processor is inside the memory. Also, as showing in col. 2, lines 12-42, processing-in-memory, for the purpose of improving throughput while avoiding exorbitant costs.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teaching of Yudanov of utilizing PIM system into the invention of Ciricescu to improve performance and reduced energy consumption by minimizing data movements.
As per claim 3, Ciricescu teaches the apparatus of claim 1, further comprising a configuration circuit to configure the reconfigurable vector processor in response to configuration information received from a core coupled to the memory (configuration is sent from the host ARM9 via API like _vsetz(), _vloop() and RSVP retrieves configuration from memory to control datapath, see section 4.2 and 4.3 for further details).
As per claim 4, Ciricescu teaches the apparatus of claim 3, wherein the plurality of banks comprises a plurality of arrays (IVSU1-3 Fig. 2), wherein a first array is to store the configuration information (control/configuration data is stored in a scalar/tunnel registers, set via API by the host), the first array being adjacent to a second array and a third array, wherein the second and third arrays are to store at least the input vector data (Memory arrays correspond to separately addressed VSU regions, see Fig. 2 and detailed description of Fig. 2).
As per claim 5, Ciricescu teaches the apparatus of claim 4, wherein the configuration circuit is to receive the configuration information from the first array and, based at least in part thereon, to configure the reconfigurable vector processor (RSVP rads configuration from memory (graph, scalars, vector shape) and configures itself dynamically, see second column first paragraph of page 5).
As per claim 6, Ciricescu teaches the apparatus of claim 5, wherein after the configuration of the reconfigurable vector processor, the reconfigurable vector processor is to perform a plurality of vector operations in response to a plurality of vector instructions received from the core (_vloop() causes RSVP to execute a vector DFG from memory in looped vector instructions, each iteration runs vector ops using pipelined function units, see section 4.2).
As per claim 7, Ciricescu teaches the apparatus of claim 5, wherein the second array is to store column data and the third array is to store row data (The VSUs can address memory in 2D patterns using stride/span/skip, see figure 3. A column/row mapping is programmable by setting shape descriptors appropriately).
As per claim 8. Ciricescu teaches the apparatus of claim 4, wherein in a first configuration, the reconfigurable vector processor comprises: a first functional unit to receive a first source operand of the input vector data (first operand from IVSU1) and a second source operand of the input vector data (IVSU2/3) and generate a first result (resulted outputted via OVSU0), wherein the first functional unit is to obtain the first source operand from the second array and obtain the second source operand from the third array (operand sourcing from separate memory arrays is programmable).
As per claim 9, Ciricescu teaches the apparatus of claim 8, wherein the reconfigurable vector processor further comprises a second functional unit, wherein in the first configuration, the second functional unit is serially coupled to receive the first result from the first functional unit (deep pipeline chaining of function units, Fig. 7, “stage 1 -> stage 7).
As per claim 10, Ciricescu teaches the apparatus of claim 9, wherein the reconfigurable vector processor further comprises a third functional unit coupled to at least one of the first functional unit or the second functional unit (RSVP includes multiple function units (adder, mult, shifter etc.) that can be chained flexibly via reconfigurable fabric, see Fig. 10).
As per claim 11, Ciricescu teaches the apparatus of claim 9, wherein the configuration circuit, in response to second configuration information, is to cause the second functional unit to be independent of the first functional unit (RSVP allows dynamic chaining or independence of units based on control config “…reconfigurable interconnect fabric…These links can be reconfigured every clock cycle”).
As per claim 12, it is rejected for the same reasons set forth above in claim 18 and 19.
As per claim 13, it is rejected for the same reasons set forth above in claim 18 and 20.
As per claim 14, it is rejected for the same reasons set forth above in claim 8, wherein the result of the vector operation is stored in either the second or third array.
As per claim 15, it is rejected for the same reasons set forth above in claim 20, wherein “When it has completed, control is returned to the host processor”; Further, the RSVP design includes a status/control block, see Figure 10. The control is returned to the host processor regardless of the result).
Claims 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ciricescu in view of Yudanov, and further in view of Hessel et al. US PG-Pub 2007/0255894 (hereinafter Hessel).
As per claim 16, Ciricescu teaches a reconfigurable interconnect fabric that is dynamically programmed via control bits stored in configuration registers that are fetched from memory on every cycle as showing in claim 18.
However, Ciricescu failed to disclose that the configuration is driven via a plurality of bitlines and to communicate a bit of the configuration information to the switch circuit.
Hessel teaches a memory buffer switch network between memory and multiple vector lanes, configured on a per-bit basis via control signals (bitlines) to select data routing pathways (see paragraph 147-148).
It would have been obvious to one of ordinary skilled in the art at the time of the invention to leverage Ciricescu RSVP reconfigurable switch fabric and routing logic to be driven on a per-bit basis from configuration memory as used in Hessel to program switch circuits selectively to define interconnect routing. This allows the processor to adapt optimally to different computation demands of long streamline pipeline vs. parallel pipeline.
As per claim 17, Ciricescu teaches the capability of dynamic chaining and independent operation of functional units via control-configurable interconnects (see Fig. 7 and first paragraph of page 8).
However, Ciricescu failed to show routing based on specific bit-control lines.
Hessel teaches enabling routing based on a specific bit-control lines that select which data path is active between memory lanes (see paragraph 147-148).
It would have been obvious to one of ordinary skill in the art at the time of the invention to use Ciricescu control bits to goggle inter-function unit switches for chaining or isolating units with Hessel’s granular bitline control to configure these switches, thus provide first-bit coupling of functional units and second-bit isolation of another functional unit as claimed, for the purpose of allowing the vector processor to adapt efficiently to different computation demands of long streamline pipeline vs parallel pipeline.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IDRISS N ALROBAYE whose telephone number is (571)270-1023. The examiner can normally be reached Mon-Fri, 8am-4:30pm.
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, John Cottingham can be reached at (571) 272-1400. 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.
/IDRISS N ALROBAYE/ Supervisory Patent Examiner, Art Unit 2181
Prosecution Insights