Prosecution Insights
Last updated: July 17, 2026
Application No. 18/174,715

INSTRUCTION PACKING SCHEME FOR VLIW CPU ARCHITECTURE

Non-Final OA §102§103§112
Filed
Feb 27, 2023
Priority
Jan 07, 2021 — continuation of 11/593,110
Examiner
HUISMAN, DAVID J
Art Unit
2183
Tech Center
2100 — Computer Architecture & Software
Assignee
Texas Instruments Incorporated
OA Round
3 (Non-Final)
58%
Grant Probability
Moderate
3-4
OA Rounds
1y 3m
Est. Remaining
91%
With Interview

Examiner Intelligence

Grants 58% of resolved cases
58%
Career Allowance Rate
392 granted / 678 resolved
+2.8% vs TC avg
Strong +34% interview lift
Without
With
+33.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 8m
Avg Prosecution
50 currently pending
Career history
764
Total Applications
across all art units

Statute-Specific Performance

§101
3.3%
-36.7% vs TC avg
§103
61.9%
+21.9% vs TC avg
§102
12.0%
-28.0% vs TC avg
§112
17.4%
-22.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 678 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION Claims 1, 3-10, and 12-20 have been examined. 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 . Claim Objections Claim 19 is objected to because of the following informalities: In line 11, replace “instruction” with --instructions--. Appropriate correction is required. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 4, 7, 13, and 16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Referring to claim 4, lines 4-5 and the last two lines include new matter with respect to the parent application because the examiner cannot find original support for the size field specifying the size based on the link field for the respective instruction. For instance, FIG.5 shows size field S1, which indicates the size of instruction 504. The size is not based on field L1 (second link field). As such, this is new matter that must be deleted. Referring to claim 7, applicant claims determining the first and second functional units prior to accessing the secondary opcode portion of the second instruction. This appears to be new matter that must be deleted. That is, while paragraph [0018] of the specification sets forth that the secondary opcode portion need not be decoded to determine the functional units, this is different from saying the portion is not accessed. For instance, in FIG.3, step 602, the entire packet (e.g. FIG.5) is received and, thus, the packet and all fields therein, including the secondary opcode portion are accessed (in order to fetch them). This occurs before any decoding in steps 606-610. As such, the secondary opcode portion is accessed prior to decoding the primary opcode portion, which determines the functional unit. If applicant wants to say that the determining of the functional units occurs without decoding the secondary opcode portion (e.g. similar to claim 8), this would be supported. But “accessed” in this context is not supported. Per MPEP 2163.06, for prior art examination, the examiner is to examine the claim as worded. Claims 13 and 16 are rejected for similar reasoning as claims 4 and 7, respectively. Terminal Disclaimer The terminal disclaimer filed on August 9, 2024, disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S. Patent No. 11,593,110 has been reviewed and is accepted. The terminal disclaimer has been recorded. Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1, 3-6, 8-10, 12-15, and 17-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Moreno et al., “An innovative low-power high performance programmable signal processor for digital communications”. Referring to claim 1, Moreno has taught a method comprising: receiving a first packet (see Figure 3. An LIW packet having one of the listed layouts is received. The packet can include the instructions of the formats shown in Figure 4) that includes: a first instruction (under a first interpretation, from Figure 3, taking the bottom packet, for instance, a first instruction would be OP3, which is the 16-bit instruction in Figure 4. Alternatively, under a second interpretation, the first instruction would be OP2 (OP2H+OP2L) in the second packet of Figure 3) that includes: a first primary opcode portion (under the first interpretation, see Figure 4, “Opcode”. Alternatively, under the second interpretation, the portion would include bits 0 to 19 of one of the 30-bit formats of Figure 4, which would fit into bits 24 to 43 of the second packet); and a first size field that specifies a size of the first instruction (under both interpretations, see Figure 4, “PX”. The first paragraph on p.308 states “the prefix (PX) field indicates how to interpret the LIW. The information in the prefix field includes parallel versus serialized execution, as well as the number and length of the individual instructions packed within the LIW.”); and a second instruction (under the first interpretation, from Figure 3, the second instruction of the bottom packet would be OP1, which may be the 20-bit instruction with extended opcode in Figure 4. Alternatively, under the second interpretation, the second instruction would be OP1 (OP1H+OP1L) in the second packet of Figure 3) that includes: a second primary opcode portion (under the first interpretation, see Figure 4, “Opcode”. Alternatively, under the second interpretation, the portion would include bits 0 to 19 of one of the 30-bit formats of Figure 4, which would fit into bits 4 to 23 of the second instruction packet); a second size field that specifies a size of the second instruction (under both interpretations, see Figure 4, “PX”. The first paragraph on p.308 states “the prefix (PX) field indicates how to interpret the LIW. The information in the prefix field includes parallel versus serialized execution, as well as the number and length of the individual instructions packed within the LIW.”. Thus, the PX field is also a second size field, in addition to a first size field, because it indicates that the packet includes a second instruction that is a particular number of bits in size); and a secondary opcode portion separated from the second primary opcode portion in the first packet (under the first interpretation, see Figure 4, 20-bit format with extended opcode, field “XO1”, which corresponds to an expanded (“secondary”) opcode (see p.305, left column, last paragraph). As can be seen the “Opcode” and “XO1” portions in that format are separated. Alternatively, under the second interpretation, this portion would include bits 20 to 29 of one of the 30-bit formats of Figure 4, which would fit into bits 44 to 53 of the second packet, which from Figure 3, shows the two opcode portions of OP2 being separated); determining a first functional unit associated with the first instruction based on the first primary opcode portion (under the first interpretation, from Figure 7, the “Opcode” field of OP3 is decoded to determine OP3’s type and, thus, determine a functional unit associated with OP3. For instance, if OP3 is determined to perform an integer operation based on the opcode of OP3, the integer unit (IU) is determined. A similar determining occurs for OP2 under the second interpretation); providing a second packet that includes the first primary opcode portion to the first functional unit (under the first interpretation, the opcode is sent to the first functional unit (e.g. IU) as part of a second packet (along with any inputs) to control the functional unit to perform the desired operation (e.g. addition, subtraction, etc.). A similar providing occurs under the second interpretation); determining a second functional unit associated with the second instruction based on the second primary opcode portion (under the first interpretation, from Figure 7, the “Opcode” field of OP1 is decoded to determine OP1’s type and, thus, determine a functional unit associated with OP1. For instance, if OP1 is determined to perform a storage access operation based on the opcode of OP1, the storage access unit (AU) is determined. A similar determining occurs for OP1 under the second interpretation); and providing a third packet that includes the second primary opcode portion and the secondary opcode portion to the second functional unit (under the first interpretation, the opcode is sent to the second functional unit (e.g. AU) as part of a third packet (along with any inputs) to control the functional unit to perform the desired operation (e.g. load, store, etc.). A similar providing occurs under the second interpretation). Referring to claim 3, Moreno has taught the method of claim 1, wherein the size of the first instruction is different from the size of the second instruction (under the first interpretation, the bottom packet in Figure 3 shows the first instruction is 16 bits and the second instruction is 20 bits in size). Referring to claim 4, Moreno has taught the method of claim 1, wherein: the first instruction includes a first link field that specifies whether the first instruction is last in the first packet (see Figure 4, “PX”. The first paragraph on p.308 states “the prefix (PX) field indicates how to interpret the LIW. The information in the prefix field includes parallel versus serialized execution, as well as the number and length of the individual instructions packed within the LIW.”. Thus, under the first interpretation, the PX field is also a first link field that, when set appropriately, indicates that the first instruction (OP3) is the last instruction in the packet (note that what follows it is not an instruction per se, but an extension of OP2). Similarly, under the second interpretation, the PX field is a link field that indicates that the first instruction (OP2) is the last instruction); the size of the first instruction as specified by the first size field is further based on the first link field (under both interpretations, when the PX field indicates the first instruction is the last instruction, the PX field also indicates the size of the first instruction); the second instruction includes a second link field that specifies whether the second instruction is last in the first packet (under the first interpretation, the PX field is also a second link field that, when set appropriately, indicates that the second instruction (OP1) is not the last instruction in the packet. Under the second interpretation, the PX field is also a second link field that, when set appropriately, indicates that the second instruction (OP1) is not the last instruction in the packet); and the size of the second instruction as specified by the second size field is further based on the second link field (under both interpretations, when the PX field indicates the second instruction is not the last instruction, the PX field also indicates the size of the second instruction). Referring to claim 5, Moreno has taught the method of claim 1, wherein a size of the first primary opcode portion is equal to a size of the second primary opcode portion (under the first interpretation, from Figure 4, all primary opcode portions are equal in size (7 bits). Under the second interpretation, from Figure 4, all primary opcode portions are equal in size (20 bits)). Referring to claim 6, Moreno has taught the method of claim 1, wherein the first instruction does not include a secondary opcode portion (under the first interpretation, from Figure 4, the 16-bit first instruction does not include a secondary opcode portion XO1. Under the second interpretation, the first instruction (OP2) may be the 30-bit instruction shown in FIG.4 without an XO1 field. This field is a secondary opcode portion field and the instruction is without it). Referring to claim 8, Moreno has taught the method of claim 1, wherein the providing of the third packet to the second functional unit is performed without decoding the secondary opcode portion of the second instruction (under both interpretations, from Figure 7, the decoding (DEC) is separate from the providing (indicated by down arrows below DEC. Thus, the providing is performed after decoding and without decoding (meaning the transfer of data from one end of the wire to the other between DEC and functional units does not include further decoding). Referring to claim 9, Moreno has taught the method of claim 1, wherein the secondary opcode portion is separated from the second primary opcode portion in the first packet by a primary opcode portion of at least one other instruction (under the second interpretation, from Figure 3, the secondary opcode portion (second packet, OP1L) is separated from the second primary opcode portion (second packet, OP1H) by a primary opcode portion of at least one other instruction (second packet, OP2H)). Claim 10, outside of the decoder and the two “provide” limitations, is rejected for similar reasoning as claim 1. Moreno has further taught the claimed decoder (see Figure 7, DEC, which is coupled to the functional units (BU, IU, AU, etc.)) and providing the first and second instructions to the first and second functional units, respectively (see Figure 7 and note the flow from the decoder to the functional units). Claims 12-15 and 17-18 are rejected for similar reasoning as claims 3-6 and 8-9, respectively. 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 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Moreno in view of Codrescu et al., U.S. Patent Application Publication No. 2006/0218379. Referring to claim 19, Moreno has taught a circuit device comprising: a set of processor functional units that includes a first functional unit and a second functional unit (see Figure 7, BU, AU, IU, etc.); and a decoder (Figure 7, DEC) coupled to the set of processor functional units and configured to: receive a packet (see Figure 3. An LIW packet (e.g. the second packet) having one of the listed layouts is received. The packet can include the instructions of the formats shown in Figure 4) that includes: a first portion (bits 0 to 43 of the second packet of Figure 3) that includes: a set of primary opcode portions of a set of instructions (this portion includes primary opcode portions OP1H and OP2H of the set of instructions OP1 and OP2); and a size field that specifies a size of a respective instruction of the set of instructions (see the PX field of the second packet. The first paragraph on p.308 states “the prefix (PX) field indicates how to interpret the LIW. The information in the prefix field includes parallel versus serialized execution, as well as the number and length of the individual instructions packed within the LIW.”); and a second portion (bits 44 to 63 of the second packet of Figure 3) that includes a set of secondary opcode portions (second packet, portions OP1L and OP2L) of a subset of the set of instruction (OP1 and OP2), wherein the second portion is arranged adjacent to the first portion (see Figure 3 and note that the first and second portions are next to each other with the border between bits 43 and 44); determine, based on the first portion of the packet, that a first instruction of the set of instructions is associated with the first functional unit and that a second instruction of the set of instructions is associated with the second functional unit (the decoder DEC decodes the opcodes to determine which functional units the instructions are associated with. As is known with long instruction word machines, different instructions go to different functional units for parallel execution (p.302 (“Parallelism is achieved by executing multiple instructions simultaneously (VLIW)”), p.308, first paragraph, and Figure 7); and provide the first instruction to the first functional unit and the second instruction to the second functional unit (the instructions are provided to the functional units for parallel execution). Moreno has not taught a set of size fields that each specifies a size of a respective instruction. Specifically, Moreno is silent on how the PX field is encoded to indicate size. However, Codrescu has taught an instruction packet that has instructions of variable size (see FIG.5). This packet includes a packet header (FIG.5, 112) that includes a size field for each instruction in the packet (see FIG.6, ‘s’ fields). One of ordinary skill in the art would have recognized that individual size fields for each instruction could be substituted for whichever size encoding is implemented in the PX field of Moreno while realizing the same results (size indication for each instruction in the packet) (MPEP 2143(I)(B)). Since there are more than two sizes per instruction in Moreno (Figure 4), one of ordinary skill in the art would have also recognized that more than one bit would be needed per size field. The individual size indications of Codrescu are more intuitive because each instruction is controlled by a respective field, as opposed to Moreno’s teaching, which would involve converting a 4-bit PX encoding to the group of sizes used in the packet. While individual size fields may increase the size of PX, this could be deemed acceptable if a designer is able to modify the hardware to accommodate more than 64 packet bits. Alternatively, a designer may instead keep the packet size at 64 bits despite lengthening PX by removing instruction bits, e.g. at least one opcode bit such that fewer instruction types are available (if all the types are not deemed necessary in a particular design (MPEP 2144.04(II)(A)), thereby simplifying the datapath with this routine omission of functionality), and/or at least one register identifier bit (from Src and Dst fields) (if a smaller register file is desired to reduce circuit size), etc. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moreno such that the PX field includes a set of size fields that each specifies a size of a respective instruction (i.e., Codrescu’s individual size fields are substituted for size encoding in Moreno). Referring to claim 20, Moreno, as modified, has taught the circuit device of claim 19, wherein each primary opcode portion of the set of primary opcode portions has the same size (see Figure 3 and note that both primary portions are 20 bits in size). Allowable Subject Matter Claims 7 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable over the prior art if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Please note that any amendments to address 112 rejections may affect allowability. Response to Arguments On page 8 of applicant’s response, applicant asserts that claim 1 is amended to recite the allowable subject matter of claim 2. The examiner notes that current claim 1 has different scope from original claim 2, due to various deletions. As such, a new rejection appears above based on an updated search. Conclusion The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Altman, 2006/0174089, has taught encoding an instruction group with instructions have primary and secondary opcodes. Iyer has taught a serial approach to decoding an instruction with a secondary opcode, where the primary opcode is compared first followed by the secondary (section (IV)(D)). 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 date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to David J. Huisman whose telephone number is 571-272-4168. The examiner can normally be reached on Monday-Friday, 9:00 am-5:30 pm. 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. /David J. Huisman/Primary Examiner, Art Unit 2183
Read full office action

Prosecution Timeline

Show 4 earlier events
Dec 12, 2024
Applicant Interview (Telephonic)
Dec 15, 2024
Examiner Interview Summary
Dec 18, 2024
Response Filed
Feb 13, 2025
Final Rejection mailed — §102, §103, §112
Apr 14, 2025
Response after Non-Final Action
May 05, 2025
Request for Continued Examination
May 10, 2025
Response after Non-Final Action
Jul 15, 2026
Non-Final Rejection mailed — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12645635
COMPUTE NEAR MEMORY CONVOLUTION ACCELERATOR
2y 11m to grant Granted Jun 02, 2026
Patent 12639145
RESILIENT POST-PROCESSING ARCHITECTURE FOR ABNORMAL PROCESS TERMINATION
3y 2m to grant Granted May 26, 2026
Patent 12613704
SHARING SNAPSHOTS BETWEEN RESTORATION AND RECOVERY
6y 4m to grant Granted Apr 28, 2026
Patent 12613703
TIGHTLY-COUPLED SLICE TARGET FILE DATA
4y 7m to grant Granted Apr 28, 2026
Patent 12602229
NEURAL NETWORK ACCELERATOR FOR OPERATING A CONSUMER PIPELINE STAGE USING A START FLAG SET BY A PRODUCER PIPELINE STAGE
4y 10m to grant Granted Apr 14, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
58%
Grant Probability
91%
With Interview (+33.6%)
4y 8m (~1y 3m remaining)
Median Time to Grant
High
PTA Risk
Based on 678 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month