DETAILED ACTION
Claims 1, 3-10, and 12-22 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 5, 2025, has been entered.
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 21-22 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 claims 21-22, applicant claims that the second primary opcode portion is arranged adjacent to the first primary opcode portion in the packet. However, this appears to be new matter since FIG.5 shows primary opcode portions separated from one another by L and S fields. The specification points out opcode portions 206, 306, and 406, which are fields that do not include L and S. While 508 is adjacent to 512, it appears that these entire segments are not primary opcode portions (only the rightmost 13 bits in each segment is a primary opcode portion).
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, 17-18, and 21-22 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 is separate from the first instruction (OP1 is separate from OP3 and OP1H+OP1L is separate from OP2H+OP2L, and the first and second instructions each perform their own respective operation. As such, they are physically and functionally separate instructions) and 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); and
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).
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.
Referring to claim 21, Moreno has taught the method of claim 1, wherein the second primary opcode portion (FIG.3, second format, OP1H) is arranged adjacent to the first primary opcode portion in the first packet (FIG.3, second format, OP2H)).
Claim 22 is rejected for similar reasoning as claim 21.
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 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Moreno in view of Iyer et al., “Energy-Aware Opcode Design” (as previously cited). Furthermore, “OpenRISC 1000 Architecture Manual” is cited as extrinsic evidence of a primary opcode indicating a type of functional unit to be used.
Referring to claim 7, Moreno has taught the method of claim 1, but has not taught wherein the determining of the first functional unit and the determining of the second functional unit are performed prior to decoding the secondary opcode portion of the second instruction. However, Iyer has taught decoding alternatives which include a parallel decoding where the primary and secondary opcodes are decoded at the same time (p.572, section D, and FIG.3(a)), and a serial decoding where the primary opcode is decoded first and, if the primary opcode matches that compared to it, the secondary opcode will then be decoded (p.572, section D, and FIG.3(b)). One of ordinary skill in the art would have recognized that fewer bits would be compared when the primary opcode is not matched because the secondary opcode comparison would be skipped. This would result in reduced power consumption. 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 to decode all instructions at once (e.g. in the same cycle as taught on p.308, first paragraph), but in serial fashion (with primary opcodes decoded before secondary opcodes). Note that Iyer’s teaching is related to OpenRISC instructions. In the attached OpenRISC Architecture Manual, the primary opcode essentially determined a functional unit. For instance, pages 33-251 set forth all instructions in the instruction set. Of all of these instructions, a primary opcode portion (6-bit leftmost portion of the instruction) having a value of 0x32 corresponds to only floating-point instructions that would use a floating-point unit (FPU of p.9). A value of 0x0A corresponds to only vector instructions (for a vector unit). In other words, the primary opcode indicates a category/type of instructions that has a corresponding functional unit. Thus, decoding the primary portion allows the system to determine the functional unit upon match. For instance, taking FIG.3(b) of Iyer, comparing the primary opcode to 0x32 (111000) is a test to determine that the type of instruction is one that corresponds to an arithmetic/logical type instruction (that would correspond to a functional unit that executes the type). Thus, upon a primary match before the secondary opcode is decoded, the system determines that the instruction corresponds to an arithmetic/logic unit. If FIG.3(a) has instead shows comparing to 0x32, a match would determine a floating-point unit is required. A match to 0x0A would determine a vector unit is required, and so on. So, overall, it would be obvious to decode just a portion of overall opcode information in Moreno so as to determine a functional unit upon a match and then continue decoding the remaining opcode information.
Claim 16 is rejected for similar reasoning as claim 7.
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).
Response to Arguments
On page 8 of applicant’s response, applicant argues that it improper to rely on the same element of a prior art reference as teaching two separate claim elements such as the first and second size fields of two separate instructions.
In addition to this argument not being persuasive for reasoning set forth in the Advisory Action, the examiner notes that applicant has not claimed that the first and second size fields are separate, but that the first and second instructions are separate. However, as explained in the rejection, OP3 is separate from OP1, and OP2H+OP2L (OP2) is separate from OP1H+OP1L (OP1). Note that the PX field does not need to be interpreted as a field of the instruction per se. The PX field is part of the overall packet and corresponds to each instruction in the packet to indicate instruction size. Thus, it can be said that the instruction includes the PX field, even if the PX field is external to the instruction. However, note that even if the PX field had to be considered part of the instruction, a shared PX field doesn’t mean the instructions having other differing fields aren’t separate. Each still has its own opcode(s), operands, and performs respective functions such that they are separate.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Pan has taught “Heads and Tails: A Variable-Length Instruction Format Supporting Parallel Fetch and Decode”, including bundles of variable-sized instructions, where the first byte indicates length information. Instructions may pair escape opcodes with secondary opcodes.
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
Prosecution Insights