DETAILED ACTION
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 6-10 are objected to because of the following informalities:
Claim 6, line 1: “the sending” lacks basis and should be corrected to “the sending of the request packet”.
Claim 8, line 1: “the sending” lacks basis and should be corrected to “the sending of the request packet”.
Claim 10, line 2: Change “a last level cache communicatively coupled” to “the last level cache, which is communicatively coupled” to clearly connect the term with “a last level cache of the CPU” in claim 1, last line.
Claim 10, line 3: Change “central processing unit” to “CPU” to maintain consistency of using the abbreviation.
Claims 7 and 9 are objected to for inheriting the objection of claims 6 and 8, respectively.
Appropriate correction is required.
Terminal Disclaimer
The terminal disclaimer filed on April 15, 2026, disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of any patent granted on Application No. 19/225,903 has been reviewed and is accepted. The terminal disclaimer has been recorded. The Non-Statutory Double Patenting rejections of claims 1-20 has been withdrawn.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 10 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 10 fails to further limit the subject matter of claim 1 as the limitation “sending the request packet to a last level cache communicatively coupled to the central processing unit and the hardware accelerator” in lines 2-3 is equivalent to the limitation “sending the request packet to the hardware accelerator via a last level cache of the CPU” in claim 1, last line.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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-13, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Piry et al. (US 20230042247 A1) in view of Gschwind et al. (US 20130262841 A1), Asri et al. (“CASPHAr: Cache-Managed Accelerator Staging and Pipelining in Heterogeneous System Architectures”, see Non-Final Office Action mailed January 28, 2026), and Caprioli et al. (US 20090300338 A1).
Wikipedia “AArch64” (see Non-Final Office Action mailed January 28, 2026) Is cited as extrinsic evidence to show that SME is an extension of AArch64.
Microsoft “The AArch64 processor (aka arm64), part 1: Introduction” (see Non-Final Office Action mailed January 28, 2026) is cited as extrinsic evidence to indicate the bit size of a word.
Regarding claim 11, Piry teaches a processing system (Fig. 1 and [0026]: System 130) comprising:
a hardware accelerator (Fig. 1 and [0026-0028]: shared unit 100 provides extra functionality for multiple CPUs. Therefore, it’s a hardware accelerator); and
a central processing unit (CPU) (Fig. 1: CPU0 120a) the CPU configured to:
send a request packet to the hardware accelerator
Piry does not teach that the processing system comprises of a last level cache, that the CPU includes an LSU and a buffer, the buffer communicatively coupled to the LSU, the buffer further communicatively coupled to the hardware accelerator via the last level cache, and that the CPU is configured to send a first SME request from the LSU to the buffer, send a second SME request from the LSU to the buffer, merge, at the buffer, the first SME request in the buffer and second SME request in the buffer to generate a request packet, and sending the request packet to the hardware accelerator via the last level cache.
Note that the shared unit in Piry can be set to execute SME instructions (see [0026]). Therefore, instructions sent to the shared unit from the CPU may be SME instructions (requests).
Gschwind teaches a CPU and an LSU and a buffer in a memory system, the buffer communicatively coupled to the LSU (Figs. 1 and 2, [0014-0024]: Processor 26 includes an optimization unit 28, which is coupled to the instruction storage 23 and issue queue 25 (see Fig. 1). The instruction storage stores instructions and loads instructions into the issue queue. Therefore, the instruction storage is an LSU. The issue queue as the buffer), the buffer further communicatively coupled to a hardware accelerator , and that the CPU is configured to send a first request from the LSU to the buffer, send a second request from the LSU to the buffer, merge, , the first request in the buffer and the second request in the buffer to generate a request packet (Figs. 1 and 3, [0018-0021]: A plurality of instructions are to be sent to the issue queue, and from the issue queue, two or more instructions are analyzed, wherein a first instruction is a first request and a second instruction may be a second request. In the issue queue, the first instruction and second instruction may be optimized (merged) into an optimized instruction. The optimized instruction then may be stored in the issue queue 11. The optimized instruction as the request packet).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry with the teachings of Gschwind to have combined and optimized SME instructions into an optimized instruction and send the optimized instruction to the shared unit. One of ordinary skill would have recognized that combining instructions into one or more optimized instructions has the benefit of reducing the number of instructions for processing and reduces the number of steps performed in a processing unit (see Gschwind [0057]).
Piry, in view of Gschwind, still does not teach a processing system comprising of a last level cache and a central processing unit (CPU) including a load-store unit (LSU) and a buffer, merge, at the buffer, the first SME request in the buffer and the second SME request in the buffer to generate a request packet, the buffer further communicatively coupled to the hardware accelerator via the last level cache, and send a request packet to a hardware accelerator via the last level cache.
Note that the Issue queue in Gschwind can be implemented as cache memory (see [0023]).
Asri teaches a processing system comprising of a last level cache (Page 5, Fig. 5: CASPHAr system, which comprises a CPU and an LLC) and a central processing unit (CPU) including a load-store unit (LSU) and a buffer (Page 5, Fig. 5: The CPU includes an LSU and L2 cache. The L2 cache as the buffer), the buffer further communicatively coupled to the hardware accelerator via the last level cache (Page 5, Fig. 5: The L2 cache is communicatively coupled to the hardware accelerator through the LLC), and send data to a hardware accelerator via the last level cache (Pages 4-5, Fig. 5 and Section “CASPHAr System Architecture”: The CASPHAr system allows the CPU to exchange dependent data to the accelerator via the LLC when it becomes available).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry, in view of Gschwind, with the teachings of Asri to have the CPU include both the LSU and buffer and have the buffer transfer data to an LLC and have the LLC transfer data to the accelerator. Having the CPU include both the LSU and the buffer be included with the CPU decreases latency, which improves overall performance. Utilizing the LLC to transfer data (such as instructions) from a CPU to an accelerator can minimize or avoid unnecessary off-chip DRAM transfers (see Page 1, section “Introduction”), which one of ordinary skill may appreciate.
Piry, in view of Gschwind and Asri, still does not teach that the CPU is to merge, at the buffer, the first SME request in the buffer and the second SME request in the buffer to generate a request packet.
Caprioli teaches to merge stores at a store queue (Fig. 1B and [0037, 0078]: Stores can be merged with already-buffered stores in a store queue 126).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry, in view of Gschwind and Asri, with the teachings and techniques of Caprioli to have performed the merging of SME requests at the instruction issue queue. By merging the instructions at the issue queue instead of merging the instructions outside the issue queue, it would reduce the amount of data moving between different circuits, which would reduce power consumption, for example, which may be appreciated.
Regarding claim 12, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of claim 11, wherein:
the first SME request and the second SME request each include information comprising at least one of an opcode and a payload (Gschwind, Fig. 5 and [0046-0049]: In the current combination, instruction 51 would be the first SME request and instruction 52 would be the second SME request. Instructions 51 and 52 indicates the operations to be done, which can only be indicated by an opcode. The instructions also indicate which registers to use. The registers indicated in each instruction as the payload); and
the request packet includes a payload comprising the information for the first SME request and the information for the second SME request (Gschwind, Fig. 5 and [0046-0049]: In the current combination, the optimized instruction 53 indicates the instruction operations to be performed (which are indicated as opcodes) and the registers to be used (which are indicated as physical rename registers). The opcodes and registers of instructions 51 and 52 as the payload of the request packet).
Regarding claim 13, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of Claim 12, wherein:
the request packet includes a header comprising information indicating a location of the information for the first SME request in the payload of the request packet and a location of the information for the second SME request in the payload of the request packet (Gschwind, Fig. 5 and [0054-0055]: In the current combination, when an optimized instruction 53 is created, the operations to be performed are indicated at the beginning portion of the optimized instruction (In the instance of Fig. 5, the “Ld” and “Add” operations). The operations indicated at the beginning of the optimized instruction point to their respective portion within the optimized instruction (which can be seen when the optimized instruction is optionally divided into two different instructions 54 and 55). Therefore, the operations to be performed indicated at the beginning portion of the optimized instruction as the header).
Regarding claim 15, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of Claim 11, wherein to merge the first SME request and the second SME request, the CPU is configured to:
determine the first SME request and the second SME request can be merged based on one or more attributes of the first SME request and one or more attributes of the second SME request (Gschwind, Fig. 4 and [0027-0028]: In the current combination, the CPU would check the target register of the first instruction and the operand and target register of the second instruction and see if they are the same (step 43). The target register as the one or more attributes of the first SME request and the operand and target register as the one or more attributes of the second SME request); and
merge the first SME request and the second SME request to generate the request packet for the hardware accelerator (Gschwind, Figs. 4-5 and [0028, 0047]: In the current combination, based on the target destination or register of the first and second instructions is the same, and whether the target destination or register is the same as the location of an operand of the second instruction, the instructions (such as instructions 51 and 52 in Fig. 5) are used to generate an optimized instruction 53 and be sent to the shared unit).
Regarding claim 16, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of claim 11, wherein to send the request packet, the CPU is configured to:
determine the request packet includes a threshold number of SME requests (Gschwind, Figs, 4 and 5, [0046-0049]: In the current combination, an optimized instruction requires two or more instructions. Therefore, the threshold number is two or more instructions); and
send the request packet to the hardware accelerator based on determining the request packet includes the threshold number of SME requests (Gschwind, Fig. 3 and [0034-0036]: In the current combination, when the optimized instruction, which includes two or more instructions, is created (meaning the threshold number has been met), the optimized instruction is sent to the shared unit for execution).
Regarding claim 17, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of Claim 12, wherein to send the request packet, the CPU is configured to:
determine the payload of the request packet includes a threshold number of words (See claim 16 rejection. The SME instruction set is part of the AArch64 Arm architecture in which SME instructions are 32-bit wide. The word size defined in the AArch64 is 32-bits. Therefore, each instruction is a word length and as a result, the threshold number of words is 2 or more words; See Wikipedia and Microsoft); and
send the request packet to the hardware accelerator based on determining the payload includes the threshold number of words (Gschwind, Fig. 3 and [0034-0036]: In the current combination, when the optimized instruction, which includes two or more instructions, is created (meaning the threshold number has been met), the optimized instruction is sent to the shared unit for execution).
Regarding claims 1-3, 5-6, and 8, the claims recite a method similar to the processing system of claims 11-13 and 15-17, respectively. Therefore, the claims are rejected on the same premises.
Regarding claim 7, Piry, in view of Gschwind, Asri, and Caprioli, teaches the method of claim 6.
Piry, in view of Gschwind, Asri, and Caprioli, does not teach that the threshold number of SME requests ranges from 7 SME requests to 10 SME requests.
However, it would have been obvious to one of ordinary skill in the art before the effective filing date to have modified the teachings of Piry, in view of Gschwind, Asri, and Caprioli, to have the threshold number of SME requests range from 7 SME requests to 10 SME requests. One of ordinary skill would recognize that merging more than two instructions has the benefit of decreasing bus traffic between the CPU and the shared unit, which would decrease power consumption as a result. Additionally, changing in size/proportion, i.e., changing the threshold range between 7 to 10 SME requests, is deemed a routine expedient and not a patentable distinction (MPEP 2144.04(IV)(A)).
Regarding claim 9, Piry, in view of Gschwind, Asri, and Caprioli, teaches the method of claim 8.
Piry, in view of Gschwind, Asri, and Caprioli, does not teach that the threshold number of words ranges from 10 words to 16 words.
However, it would have been obvious to one of ordinary skill in the art before the effective filing date to have modified the teachings of Piry, in view of Gschwind, Asri, and Caprioli, to have the threshold number of words range from 10 words to 16 words. One of ordinary skill would recognize that merging more than two instructions has the benefit of decreasing bus traffic between the CPU and the shared unit, which would decrease power consumption as a result. Additionally, changing in size/proportion, i.e., changing the threshold number between 10 to 16 words, is deemed a routine expedient and not a patentable distinction (MPEP 2144.04(IV)(A)).
Regarding claim 10, Piry, in view of Gschwind, Asri, and Caprioli, teaches the method of Claim 1, wherein sending the request packet to the hardware accelerator comprises sending the request packet to a last level cache communicatively coupled to the central processing unit and the hardware accelerator (In the current combination, the optimized instruction is sent to the last level cache, in which the cache is communicatively coupled between the CPU and hardware accelerator since the CPU sends the optimized instruction to the last level cache and then the hardware accelerator fetches the optimized instruction from the last level cache for processing).
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Piry et al. (US 20230042247 A1) in view of Gschwind et al. (US 20130262841 A1), Asri et al. (“CASPHAr: Cache-Managed Accelerator Staging and Pipelining in Heterogeneous System Architectures”, see Non-Final Office Action mailed January 28, 2026), Caprioli et al. (US 20090300338 A1), and Xiu (“Part 2: Arm Scalable Matrix Extension (SME) Instructions”, see Non-Final Office Action mailed January 28, 2026).
Regarding claim 14, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of Claim 11, wherein:
the first SME request comprises a load-store operation (Gschwind, Fig. 5 and [0046]: In the current combination, instruction 51 indicates a “Ld” operation, which uses a load-store pipeline, therefore it’s a load-store operation); and
the second SME request comprises an (Gschwind, Fig. 5 and [0047]: In the current combination, Instruction 52 indicates an “Add” operation).
Piry, in view of Gschwind, Asri, and Caprioli, does not teach that the second SME request comprises a matrix operation.
Xiu teaches a matrix operation (Starting at page 10 of printout, section “Addition of a vector to ZA rows and columns”: The instruction ADDHA adds a source vector to each horizontal slice of a ZA tile).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry, in view of Gschwind, Asri, and Caprioli, with the teachings of Xiu to have the second SME request perform a matrix operation. One of ordinary skill would recognize that matrix instructions perform operations on large data sets compared to arithmetic or vector instructions, which accelerates data processing, which improves the performance of a processor as a result.
Regarding claim 4, the claim recites a method similar to the processing system of claim 14. Therefore, the claim is rejected on the same premises.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Piry et al. (US 20230042247 A1) in view of Gschwind et al. (US 20130262841 A1), Asri et al. (“CASPHAr: Cache-Managed Accelerator Staging and Pipelining in Heterogeneous System Architectures”, see Non-Final Office Action mailed January 28, 2026), Caprioli et al. (US 20090300338 A1), and Tran et al. (US 20060095732 A1).
Regarding claim 18, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of Claim 11.
Piry, in view of Gschwind, Asri, and Caprioli, does not teach that the CPU further comprises an address queue configured to queue a first address associated with the first SME request and a second address associated with the second SME request and that the CPU is further configured to dequeue the first address from the address queue and the second address from the address queue based on sending the request packet.
Tran teaches a CPU comprising an address queue (Figs. 3 and 6, [0198-0215]: Fig. 3 is a block diagram of a processor, comprising of decode pipelines 1630 comprising of issue-loop circuit 1800. In the issue circuit, there exists a non-critical issue queue 1860 which stores program counter addresses. Therefore, the issue queue is an address queue) configured to queue a first address associated with the first request and a second address associated with the second request Fig. 6, [0198-0215]: issue queue 1860 stores the instruction program address of a first instruction INST0 and a second instruction INST1. INST0 as the first request and INST1 as the second request) and that the CPU is further configured to dequeue the first address from the address queue and the second address from the address queue based on issuing the instructions (Figs. 3 and 6, [0198-0215]: Instructions INST0 and INST1 are fed (dequeued) into the decode circuitry 1870, meaning they’ve been issued into the processing pipeline).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry, in view of Gschwind, Asri, and Caprioli, with the teachings of Tran to have queued PC addresses associated with their respective SME instructions and to dequeue them in response to the optimized instruction being issued. Storing the addresses of each instruction queued into the processor allows one of ordinary skill to easily analyze what instructions have/have not been optimized by comparing what’s in the address queue to what’s queued in the buffer, which may provide further support in debugging the processor.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Piry et al. (US 20230042247 A1) in view of Gschwind et al. (US 20130262841 A1), Asri et al. (“CASPHAr: Cache-Managed Accelerator Staging and Pipelining in Heterogeneous System Architectures”, see Non-Final Office Action mailed January 28, 2026), Caprioli et al. (US 20090300338 A1), and Henry et al. (US 20240220323 A1).
Regarding claim 19, Piry, in view of Gschwind, Asri, and Caprioli, teaches the processing system of claim 11.
Piry, in view of Gschwind, Asri, and Caprioli, does not explicitly teach that the hardware accelerator includes a matrix execution pipeline and a load-store execution pipeline.
Henry teaches an accelerator which includes a matrix execution pipeline and a load-store execution pipeline (Fig. 3 and [0086-0089]: Matrix operations accelerator is capable of executing matrix manipulation operations within the FMA grid 306 or load and store operations, in which the data buffers 305 load/store data from memory. The FMA grid as the matrix execution pipeline and the data buffers as the load-store execution pipeline).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Piry, in view of Gschwind, Asri, and Caprioli, with the teachings of Henry to have the shared unit include a matrix execution pipeline and a load-store pipeline. One of ordinary skill would recognize that an accelerator capable of executing SME instructions would require an execution pipeline and load-store pipeline. Therefore, both pipelines should be present so that all SME instructions can be executed on the shared unit.
Response to Arguments/Amendments
Applicant’s amendments, filed April 15, 2026, addresses the specification objections. The specification objections has been withdrawn.
Applicant’s amendments, filed April 15, 2026, addresses the claim objections. The claim objections has been withdrawn. However, new claim objections have been raised. See “Claim Objections” section above.
Applicant’s arguments, see page 8, paragraph 7, filed April 15, 2026, with respect to the rejection of claims 1-9 and 20 under 35 U.S.C. 101 have been fully considered and are persuasive. The rejection of claims 1-9 and 20 under 101 has been withdrawn.
Applicant’s amendments, filed April 15, 2026, addresses the 35 U.S.C. 112(a)/112(b) rejections. The 112(a)/112(b) rejections has been withdrawn.
Applicant’s arguments, see page 9, paragraph 7 to page 11, paragraph 5, filed April 15, 2026, with respect to the rejection of claims 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art. See 103 rejections for claims 1-19 above.
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 EMILIO ALCANTARA-RAMOS whose telephone number is (571)272-4211. The examiner can normally be reached Mon-Fri 8:30-5:00 PST.
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, Jyoti Mehta can be reached at (571)270-3995. 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.
/E.A./Examiner, Art Unit 2183
/David J. Huisman/Primary Examiner, Art Unit 2183
Prosecution Insights