Optimum Semiconductor Technologies, Inc.

Patent Trials and Appeals Board

Jan 6, 2022

2020005772 (P.T.A.B. Jan. 6, 2022)

UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 14/709,730 05/12/2015 Mayan Moudgill ZL0002-0026-US 1850 155075 7590 01/06/2022 Zhong Law, LLC 100 Connell Drive Suite 2300 Berkeley Heights, NJ 07922 EXAMINER DOMAN, SHAWN ART UNIT PAPER NUMBER 2183 NOTIFICATION DATE DELIVERY MODE 01/06/2022 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): ip@remotedocket.com szhao@zhong-law.com zhong@zhong-law.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte MAYAN MOUDGILL, GARY J. NACER, C. JOHN GLOSSNER, ARTHUR JOSEPH HOANE, PAUL HURTLEY, MURUGAPPAN SENTHILVELAN, PABLO BALZOLA, VITALY KALASHNIKOV, and SITIJ AGRAWAL ____________ Appeal 2020-005772 Application 14/709,730 Technology Center 2100 ____________ Before KARL D. EASTHOM, KARA L. SZPONDOWSKI, and SCOTT B. HOWARD, Administrative Patent Judges. SZPONDOWSKI, Administrative Patent Judge. DECISION ON APPEAL Appellant1 appeals under 35 U.S.C. § 134(a) from the Examiner’s Final Rejection of claims 1-3, 5-24, and 26-42, which constitute all of the claims pending in this application. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM IN PART. 1 We use the word “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. Appellant identifies the real party in interest as Optimum Semiconductor Technologies Inc. Appeal Br. 3. Appeal 2020-005772 Application 14/709,730 2 STATEMENT OF THE CASE Appellant’s invention relates generally “to a vector processor, and in particular, to the architecture and implementation of a vector processor that includes one or more instructions that operate on variable length vectors implemented on a monolithic integrated circuit.” Spec. ¶ 2. “A vector instruction is an instruction that executes on a group of values using one instruction.” Spec. ¶ 3. “The group of values can come from registers, memory, or a combination of both.” Spec. ¶ 4. “Registers that hold groups of values, generally intended for use by vector instructions, are referred to as vector registers” and “[t]he number of values in a group is called the vector length.” Spec. ¶ 4. Earlier “generation vector processors were implemented on multiple boards using customized techniques to improve performance,” but “technology development enabled single-chip microprocessors to out- perform these multi-board implementations, resulting in these vector processors being phas[ed] out.” Spec. ¶ 9. With newer “fixed length vector extensions” introduced “to existing general purpose architectures . . . registers with fixed byte lengths” were “designed to hold multiple smaller length elements that can be operated on simultaneously.” Spec. ¶¶ 11-12. A “newer implementation . . . can support multiple different vector register widths, and instructions that operate on all of these instruction register widths.” Spec. ¶ 14. Claim 1, reproduced below, is representative of the claimed subject matter: 1. A processor, comprising: a vector unit comprising: a vector register file comprising a vector register to hold a varying number of elements; and Appeal 2020-005772 Application 14/709,730 3 a length register file comprising: a first vector length register; and a second vector length register; and an execution unit to: execute a first vector instruction as a single instruction, the first vector instruction comprising a first identifier representing the vector register and a second identifier representing the first vector length register to store a first integer value specifying a first number of operations applied to the varying number of elements, wherein the first number of operations is independent from a number of elements that the vector register is capable of packing therein; and execute a second vector instruction as a single instruction, the second vector instruction comprising the first identifier representing the vector register and a third identifier representing the second vector length register to store a second integer value specifying a second number of operations applied to the varying number of elements, wherein the second number of operations is independent from the number of elements that the vector register is capable of packing therein. REJECTIONS Claims 1, 3, 5, 19-22, 24, 26, and 40-42 stand rejected under 35 U.S.C. § 103 as unpatentable over Damron (US 2011/0145543 A1; published June 16, 2011) and Nickolls et al. (US 2002/0087846 A1; published July 4, 2002) (“Nickolls”). Final Act. 2. Claims 2 and 23 stand rejected under 35 U.S.C. § 103 as unpatentable over Damron, Nickolls, and Karkhanis et al. (US 2011/0320765 A1; published Dec. 29, 2011) (“Karkhanis”). Final Act. 5. Appeal 2020-005772 Application 14/709,730 4 Claims 6-10, 16-18, 27-31, and 37-39 stand rejected under 35 U.S.C. § 103 as unpatentable over Damron, Nickolls, and Bradbury et al. (US 2017/0039067 A1; published Feb. 9, 2017) (“Bradbury”). Final Act. 6. Claims 11-15 and 32-36 stand rejected under 35 U.S.C. § 103 as unpatentable over Damron, Nickolls, and Moyer (US 2005/0055534 A1; published Mar. 10, 2005). Final Act. 12. ANALYSIS Claims 1, 11-15, 19, 22, 32-36, and 40 Issue: Did the Examiner err in finding that the combination of Damron and Nickolls teaches or suggests (emphasis added): execute a first vector instruction as a single instruction, the first vector instruction comprising a first identifier representing the vector register and a second identifier representing the first vector length register to store a first integer value specifying a first number of operations applied to the varying number of elements, wherein the first number of operations is independent from a number of elements that the vector register is capable of packing therein as recited in independent claim 1 and commensurately recited in independent claim 22? The Examiner finds that Damron teaches a processing unit that executes vector processing instructions and includes an identifier of the vector register. Final Act. 3 (citing Damron ¶¶ 35, 45); see also Ans. 4 (“executing an instruction utilizing a vector register . . . discloses the first identifier”). The Examiner further finds that Damron’s “vector size registers store the width, which is expressed as an integer (as shown in Figure 5A), that specifies the number of operations applied to the elements of the vector register.” Final Act. 3 (citing Damron ¶ 35); see also Ans. 4 (“As shown at Figure 4, the instruction for obtaining the width includes an identifier of the Appeal 2020-005772 Application 14/709,730 5 vector length register, which discloses the second identifier.”) The Examiner finds that “Damron does not disclose that both identifiers are included in a single instruction,” but that Damron’s “multiple steps (instructions) . . . could easily be performed in response to execution of a single assembly instruction.” Ans. 4; see also Final Act. 3. The Examiner relies on Nickolls’s disclosure that “a single instruction that incorporates both pieces of information, i.e., configuration information and operands” to teach “that it is known to execute single instructions having identifiers for both configuration values and data operands.” Ans. 4 (citing Nickolls ¶ 34). Appellant argues that “the allowability of claim 1 should be determined based on whether the cited references teach or suggest a single instruction that includes the two specific pieces of information required by the claim, and not on whether the references disclose an instruction that includes an arbitrary identifier tied to an unrelated register such as the ‘configuration register’ discussed in Nickolls.” Appeal Br. 12-13 (boldface omitted). Specifically, Appellant argues that there is “no discussion of vector instructions in the cited passage and drawing” of Nickolls, “let alone a single instruction that specifically includes a representation of a vector register and a representation of a number of operations to be applied to the vector register.” Appeal Br. 14; see also Reply Br. 7. Appellant’s argument against Nickolls separately from Damron does not persuasively rebut the combination made by the Examiner. One cannot show non-obviousness by attacking references individually, where the rejections are based on combinations of references. In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986); In re Keller, 642 F.2d 413, 425 (CCPA 1981). We agree with the Examiner’s finding that Damron’s “identifier of Appeal 2020-005772 Application 14/709,730 6 the vector register” and Damron’s “width, which is expressed as an integer . . . that specifies the number of operations applied to the elements of the vector register” stored in the “vector size register” teach the claimed first “identifier representing the vector register” and “second identifier representing the first vector length register to store a first integer value specifying a first number of operations applied to the varying number of elements,” respectively; and that the combination with Nickolls would include “accessing a selected size register as part of the vector instruction itself, rather than as a separate instruction.” Final Act. 3-4 (citing Damron ¶¶ 35, 45; Nickolls ¶ 70) (emphasis omitted); see also Ans. 4 (citing Nickolls ¶ 34). As cited by the Examiner, Damron recites “a system 100 for executing variable width vector processing instructions.” Damron ¶ 35. Damron also recites that the “processing unit 102 includes one or more vector registers 104 and one or more vector size registers 105.” Damron ¶ 35. Damron explains that the vector register “stores one or more vectors during execution of vector processing instructions,” and that the vector size register “stores the width of the vector register.” Damron ¶ 35. As also cited by the Examiner, Nickolls recites “[a]n instruction 100 that selects a configuration register” and that “includes operation code (op) 102, a configuration select field or configuration field (cn) 104, and operands 106.” Nickolls ¶ 34 (emphasis added). In other words, Damron teaches executing vector processing instructions and identifying vector registers and vector size registers, and Nickolls teaches a single instruction that includes configuration information and operand information. Appeal 2020-005772 Application 14/709,730 7 Thus, we agree with the Examiner’s finding that Damron’s identifying vector registers and vector size registers in multiple instructions, combined with Nickolls’s including configuration and operand data in a single instruction, teaches “a first vector instruction as a single instruction” that comprises “a first identifier representing the vector register and a second identifier representing the first vector length register” as required by claim 1. Appellant also argues that “the skilled person” would not “be motivated to resort to Nickolls in order to cure the deficiency of Damron” because Nickolls provides “no discussion of vector instructions.” Appeal Br. 14. Appellant asserts that the “proposed modification would render the prior art invention being modified unsatisfactory for its intended purpose.” Appeal Br. 14. Specifically, Appellant argues that “an intended purpose of Damron’s invention is to execute one or more vector width instructions before executing a vector processing instruction to ensure the length of a vector is known before the vector processing instruction is processed,” and “modify[ing] this multi-instruction, multi-step scheme of Damron to one including only a single instruction would render . . . Damron unsatisfactory for its intended purpose.” Appeal Br. 15 (citing Damron ¶¶ 36, 49-50). We are not persuaded by Appellant’s arguments. Although Damron presents an implementation that “executes a vector width instruction in a program” and then uses “the width of an appropriate vector register” for the processing unit to “use to process variable vector processing instructions,” Damron allows for “a single set of instructions [to] be utilized for vector processing while supporting many different vector widths.” Damron ¶ 5. We agree with the Examiner that “Damron does not disclose that the purpose of the invention is in any way related to using two instructions to Appeal 2020-005772 Application 14/709,730 8 perform the two functions of: 1) determine the width (number of operations); and 2) perform an according number of operations.” See Ans. 5. Therefore, we also agree with the Examiner that “modifying Damron to perform both steps in response to a single instruction would not interfere with the ability of Damron’s system to achieve its intended purpose of providing configurable vector operations by supporting multiple vector sizes without supplying a multiplicity of size-specific instructions.” See Ans. 5. The Examiner also finds that Damron’s “vector size registers stor[ing] the width . . . that specifies the number of operations applied to the elements of the vector register,” but which “may be different than the actual size of the register,” teaches a vector instruction comprising a first integer value specifying a number of operations applied to the varying number of elements and independent from a number of elements that the register is capable of packing, as claimed. Final Act. 3 (citing Damron ¶¶ 35, 37-38, 45) (emphasis omitted). Specifically, the Examiner finds that Damron’s example describing that “the vector register is thirty two elements wide, but the vector size register specifies sixteen elements,” teaches that the “number of elements specified in the size register indicates the number of operations that are performed” is “independent of the size of the vector register.” Ans. 6 (citing Damron ¶ 38). Appellant argues that “claim 1 clearly requires that the ‘number of operations’ be independent from the number of elements that the vector register is capable of packing therein,” but that Damron’s “vector width register . . . always indicates the number of elements stored in a vector register.” Appeal Br. 15-16. According to Appellant, although Damron’s “‘value in the vector size register 105 may be less than the actual width of Appeal 2020-005772 Application 14/709,730 9 the vector register 104,’ the value in the vector size register 105 still equals the number of elements stored in the vector register” and is not “independent from the number of elements.” Appeal Br. 16 (boldface omitted); see also Reply Br. 8-9. We are not persuaded by Appellant’s arguments. As cited by the Examiner, Damron recites that “the value in the vector size register 105 may be less than the actual width of the vector register 104.” Damron ¶ 38. In an example, Damron recites that “the vector register 104 may have a width of thirty-two,” but “the processing unit 102 may set the vector size register 105 as sixteen.” Damron ¶ 38. In other words, the section of Damron cited by the Examiner teaches that the actual width of the vector register (i.e., a number of elements that the vector register is capable of packing therein) is different from (i.e., independent from) the value in the vector size register (i.e., an integer value specifying the number of operations applied to the elements). Appellant has not explained why Damron’s actual width of the vector register being different from the value of the vector size register does not teach the claimed “first integer value specifying a first number of operations applied to the varying number of elements” being “independent from the number of elements that the vector register is capable of packing therein.” For at least the above reasons we sustain the Examiner’s § 103 rejection of independent claims 1 and 22, as well as the § 103 rejections of dependent claims 11-15, 19, 32-36, and 40, not separately argued. See Appeal Br. 21-22, 24, 25. Claims 2 and 23 Claim 2, and commensurately claim 23, further recites Appeal 2020-005772 Application 14/709,730 10 wherein the first vector instructions comprises an explicit length field containing the second identifier representing the first vector length register specifying the first number of operations to be performed on the varying number of elements, wherein the first number of operations is greater than the number of elements that the vector register is capable of packing therein. The Examiner finds that Damron’s teaching that “the width may be different than the actual size of the register” teaches that “the first number of operations is greater than the number of elements that the vector register is capable of packing therein” as claimed. Ans. 7 (citing Damron ¶¶ 37-38); see also Final Act. 6. The Examiner also finds that “[i]n the case where the register is actually made up of a number of registers treated as a single register, the width (number of operations) would be greater than the number of elements that can be packed into a vector register.” Ans. 7. Appellant argues that Damron “clearly” teaches “that ‘the value in the vector size register 105 may be less than the actual width of the vector register 104,’” but does not teach that “the first number of operations is greater than the number of elements that the vector register is capable of packing therein,” as claimed. Appeal Br. 16-17 (second emphasis added). We are persuaded by Appellant’s arguments. Although Damron recites that “the vector register 104 may be made up of a number of registers that the processing unit 102 treats as a single vector register,” Damron does not teach that such an implementation would result in a number of operations being greater than the number of elements the vector register is capable of packing therein. Damron ¶ 37. Rather, the cited sections of Damron specifically describe an example where “the value in the vector size register 105,” i.e., an integer value specifying the number of operations applied to the elements, “may be less than the actual width of the vector Appeal 2020-005772 Application 14/709,730 11 register,” a number of elements that the vector register is capable of packing therein. See Final Act. 3; Ans. 4; Damron ¶ 38. Damron specifically recites that “the vector register 104 may have a width of thirty-two,” but “the processing unit 102 may set the vector size register 105 as sixteen.” Damron ¶ 38. We agree with Appellant that the Examiner does not make sufficient findings that Damron’s value in the vector size register being less than the actual width of the vector register teaches that the number of operations is greater than the number of elements that the vector register is capable of packing, as claimed. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 2 and 23. Claims 3 and 24 Claim 3, and commensurately claim 24, further recites “wherein the first vector length register is derived from one of a target register, one or more source registers, or an opcode of the first vector instruction.” The Examiner finds that Damron “determin[es] the vector size register based on a vector processing instruction, which encompasses an opcode.” Ans. 7-8 (citing Damron ¶ 39). Appellant argues that Damron cannot “disclose deriving the first vector length register from an opcode of the first vector instruction” because Damron does not teach that “the vector instruction includes an identifier for the vector width register.” Appeal Br. 17. We are not persuaded by Appellant’s arguments. As discussed above, Damron and Nickolls teaches the claimed vector instruction comprising a first identifier representing the vector register and a second identifier representing the first vector length register. Damron recites that “the Appeal 2020-005772 Application 14/709,730 12 variable vector processing instruction may perform various operations on a vector stored in the vector register” including obtaining “the value of the vector size register.” Damron ¶ 39. Damron also recites that “the processing unit 102 obtains the width of the vector register 104 during execution of the code of the program 106 by executing one or more vector register width instructions in the code.” Damron ¶ 43. In other words, Damron teaches the vector register width instructions and vector processing instructions during execution of the code of the program (i.e., opcode). Appellant has not persuasively explained why Damron’s vector instructions during execution of the code of the program does not teach that the “first vector length register is derived from . . . an opcode of the first vector instruction,” as claimed. For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 3 and 24. Claims 5 and 26 Claim 5, and commensurately claim 26, further recites “wherein the length register file further comprises an active length register to provide a number of operations of subsequent vector instructions.” The Examiner finds Damron teaches “a vector size register that indicates the width (which is used to derive the number of operations) of a vector register,” and that this “width is used in subsequent operations.” Ans. 8 (citing Damron ¶ 38). Appellant argues that Damron does not teach “that the vector length register file comprises an active length register, let alone that the active length register is to provide a number of operations of subsequent vector instructions.” Appeal Br. 18. Specifically, Appellant argues that “Damron Appeal 2020-005772 Application 14/709,730 13 nowhere teaches that the width of a vector register equates the number of operations to be performed on the vector register.” Reply Br. 10-11. We are not persuaded by Appellant’s arguments. Damron recites that “the processing unit 102 may be operable to set the value in the vector size register 105.” Damron ¶ 38. In an example, Damron recites that “the vector register 104 may have a width of thirty-two,” but “the processing unit 102 may set the vector size register 105 as sixteen,” and then the “process variable vector process[es] instructions as having a width of sixteen and would use the vector register 104 as vector register with a width of sixteen.” Damron ¶ 38. In other words, Damron teaches setting the vector size register as a different value than the vector register width. Then, instructions are processed to have the set vector size register. Appellant has not persuasively explained why Damron’s setting the vector size register and processing instructions to have the vector size register does not teach “an active length register to provide a number of operations of subsequent vector instructions,” as claimed. For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 5 and 26. Claims 6 and 27 Claim 6, and commensurately claim 27, further recites “wherein the vector unit further comprises a vector accumulator register file to hold scalar values resulting from executing the first vector instruction and the second vector instruction.” Appeal 2020-005772 Application 14/709,730 14 The Examiner finds that Bradbury teaches “using a vector register as an accumulator, which holds a sum (scalar).” Ans. 8 (citing Bradbury ¶¶ 117-118). Appellant argues that Bradbury “never mention[s] a vector accumulator register file, let alone that the vector accumulator register file is to hold scalar values resulting from executing the first vector instruction and the second vector instruction.” Appeal Br. 18. We are not persuaded by Appellant’s arguments. Bradbury discloses “the Vector Checksum instruction takes four 4-byte integer elements from a vector register and adds them together,” and that the “4-byte sum is added to a 4-byte element in another operand, and then saved in yet a further vector register.” Bradbury ¶ 117. In other words, Bradbury teaches adding together (i.e., accumulating) integer (i.e., scalar) values during instructions and operands (i.e., vector instructions). Appellant has not persuasively explained why Bradbury’s accumulating values during instructions and operands does not teach “a vector accumulator register file to hold scalar values resulting from executing the first vector instruction and the second vector instruction,” as claimed. For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 6 and 27. Claims 7 and 28 Claim 7, and commensurately claim 28, further recites “wherein the vector unit further comprises a vector mask register file to hold single bit values to control execution of at least one of the first vector instruction or the second vector instruction.” Appeal 2020-005772 Application 14/709,730 15 The Examiner finds that Bradbury teaches “storing a bit mask in a vector register, which is a vector mask register,” and that “the bits in the mask control execution of vector operations.” Ans. 9 (citing Bradbury ¶¶ 71-72). Appellant argues that “the cited paragraphs at best describe using a bit mask to control the elements of a vector on which an operation occurs,” but that there “is no disclosure of having a vector mask register file to hold single bit values to control execution of at least one of the first vector instruction or the second vector instruction.” Appeal Br. 19; see also Reply Br. 11. We are not persuaded by Appellant’s arguments. Bradbury recites that “the bit mask may be provided in a general purpose register” or “in an element of a vector register,” and “may be included as an explicit operand of the instruction or an implied operand or input.” Bradbury ¶ 71. Bradbury also recites that “[i]f bit 0 is set to zero, the operation occurs on all elements in the vector.” Bradbury ¶ 72. In other words, Bradbury teaches a vector mask register (i.e., bit mask in a vector register) with a single bit value (i.e., bit 0 is set to zero) to control operation of vector instructions (i.e., bit mask included as explicit operand of the instruction, and bit 0 being set to zero causes operation to occur on all vector elements). Appellant has not persuasively explained why Bradbury’s bit mask in a vector register included as an explicit operand of the instruction, which causes operations to occur on the vector elements, does not teach “vector mask register file to hold single bit values to control execution of at least one of the first vector instruction or the second vector instruction,” as claimed. Appeal 2020-005772 Application 14/709,730 16 For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 7 and 28. Claims 8 and 29 Claim 8, and commensurately claim 29, further recites “wherein the vector unit further comprises a logic circuit to support precise exceptions for vector instructions, and wherein an exception is raised responsive to determining that a vector instruction cannot be executed directly by the execution unit.” The Examiner finds that Bradbury teaches “handler (logic circuit) for handling precise exceptions that involves re-doing various calculations when a vector instruction causes an exception” such as “an invalid operation, which is interpreted as an instruction that cannot be executed directly by the execution unit.” Ans. 9 (citing Bradbury ¶¶ 175, 177). Appellant argues that Bradbury’s exception is not “raised responsive to determining that a vector instruction cannot be executed directly by the execution unit.” Appeal Br. 19-20. Specifically, Appellant argues that Bradbury does not teach “an exception is to be raised responsive to determining that a vector instruction cannot be executed directly by the execution unit.” Reply Br. 12. We are not persuaded by Appellant’s arguments. As cited by the Examiner, Bradbury teaches that the vector exception code (VXC) “distinguishes between various types of vector floating point exceptions and indicates which element caused the exception,” with an example that “a vector exception code 900 includes a vector index (VIX) 902, and a vector interrupt code (VIC) 904,” which may be “included in bits 4-7 of the vector exception code.” Bradbury ¶ 177. Bradbury also discloses that the vector Appeal 2020-005772 Application 14/709,730 17 exception code can have the value “0001[:] IEEE Invalid operation.” Bradbury ¶ 177. In other words, Bradbury teaches vector exception code to support vector interrupt code, and an element that caused the exception to be an invalid operation. Appellant has not persuasively explained why Bradbury’s vector exception code supporting vector interrupt code and triggered by an invalid operation does not teach “a logic circuit to support precise exceptions for vector instructions, and wherein an exception is raised responsive to determining that a vector instruction cannot be executed directly by the execution unit,” as claimed. Appellant does not persuasively address the Examiner’s finding that Bradbury’s exception code of an invalid operation teaches a determination that a vector instruction cannot be executed directly by the execution unit. For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 8 and 29. Claims 9 and 30 Claim 9, and commensurately claim 30, further recites “wherein the vector instruction specifies vectors of length larger than supported on the processor, and wherein the processor is to trap the vector instruction and emulate the vector instruction in software.” The Examiner finds that Bradbury teaches “emulator code (software) that fetches (traps) and translates guest instructions (various ISAs support various lengths, so this discloses instructions having larger than supported lengths) to native instructions (emulates).” Ans. 10 (citing Bradbury ¶ 49). Appellant argues that Bradbury “at best describe[s] emulator code that ‘enables the processing environment configured in one architecture to emulate another architecture,’” but does not teach “a processor trapping a Appeal 2020-005772 Application 14/709,730 18 vector instruction that specifies vectors of length larger than supported on the processor and emulating the vector instruction in software.” Appeal Br. 20; see also Reply Br. 12. We are persuaded by Appellant’s arguments. Bradbury recites an “emulator code 212” that “includes an instruction fetching routine 252 to obtain one or more guest instructions 250” and “an instruction translation routine 254 to determine the type of guest instruction that has been obtained and to translate the guest instruction into one or more corresponding native instructions.” Bradbury ¶ 49. We agree with Appellant that the Examiner does not make sufficient findings that Bradbury’s emulator code including an instruction fetching routine and an instruction translation routine teaches “vector instruction specifies vectors of length larger than supported on the processor, and wherein the processor is to trap the vector instruction and emulate the vector instruction in software” as claimed. Specifically, the Examiner has not sufficiently shown that Bradbury’s fetching routine teaches “to trap the vector instruction,” as claimed, and Bradbury’s instruction translation routine teaches “wherein the vector instruction specifies vectors of length larger than supported on the processor,” as claimed. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 9 and 30. Claims 10 and 31 Claim 10, and commensurately claim 31, further recites “wherein the vector unit further comprises a logic circuit providing a control bit to one of suppress or take interrupts when an exception is encountered and providing a Appeal 2020-005772 Application 14/709,730 19 status bit to record an occurrence of an unsuppressed floating point- exception.” The Examiner finds that Bradbury teaches “a status bit that determines (records) whether the exception code is stored (taken or suppressed) in the floating point control register.” Ans. 10 (citing Bradbury ¶ 176). Appellant argues that Bradbury “at best describes using ‘a specified bit (e.g., bit 45) of a designated control register’ to control whether ‘[an exception code] VXC is also placed in a data exception code (DXC) field of a floating point control register,’” but that this does not teach “providing a control bit to one of suppress or take interrupts when an exception is encountered, let alone providing a status bit to record an occurrence of an unsuppressed floating point-exception.” Appeal Br. 21; see also Reply Br. 13. We are persuaded by Appellant’s arguments. Bradbury recites “a vector data exception causes a program interruption,” and “a vector exception code (VXC)” that is “placed in a data exception code (DXC) field of a floating point control register” when “a specified bit (e.g., bit 45) of a designated control register (e.g., CR0) is 1.” Bradbury ¶ 176. We agree with Appellant that the Examiner does not make sufficient findings that Bradbury’s floating control bit (i.e., floating point control register) and vector data exception that causes a program interruption (i.e., exception) teach “a logic circuit providing a control bit to one of suppress or take interrupts when an exception is encountered and providing a status bit to record an occurrence of an unsuppressed floating point-exception,” as claimed. Specifically, the Examiner has not sufficiently shown that Bradbury’s vector exception code being placed in a field of a floating point Appeal 2020-005772 Application 14/709,730 20 control register teaches providing a status bit to record an occurrence of an unsuppressed floating-point exception. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 10 and 31. Claims 16 and 37 Claim 16, and commensurately claim 37, further recites “wherein at least one of the first vector instruction or the second vector instruction is to specify a type associated with the varying number of elements.” The Examiner finds that Bradbury teaches “specifying the type (size) of a floating point number element.” Ans. 12 (citing Bradbury ¶ 92). Appellant argues that Bradbury does not teach “a type associated with the varying number of elements.” Appeal Br. 22. Specifically, Appellant argues that Bradbury does not teach “that at least one of the first vector instruction or the second vector instruction is to specify a type associated with the varying number of elements.” Reply Br. 14. We are not persuaded by Appellant’s arguments. As discussed above, Damron and Nickolls teach the claimed vector instruction. As cited by the Examiner, Bradbury discloses that “a vector register 480 includes a plurality of elements 482a-482n, each including a floating point number,” and that each “floating point number and the size of the floating point number 483a- 483n are input to convert-to-type number logic” and “output is a particular bit representing a class/sign for the floating point number.” Bradbury ¶ 92. In other words, Bradbury teaches using a convert-to-type number logic for the vector register elements floating point numbers to output bits representing classes and signs for the floating point numbers. Appellant has not persuasively explained why the vector instruction taught in Damron and Appeal 2020-005772 Application 14/709,730 21 Nickolls, combined with Bradbury’s outputted bits representing classes and signs for the floating point numbers included in the vector register do not teach a vector instruction that specifies a type associated with the number of elements, as claimed. For at least the above reasons we sustain the Examiner’s § 103 rejection of dependent claims 16 and 37. Claims 17 and 38 Claim 17, and commensurately claim 38, further recites wherein . . . the execution unit is to: record the type of the varying number of elements, compare the recorded type against an expected type, and responsive to determining that the recorded type differs from the expected type, convert the type to the expected type using a set of rules. The Examiner finds that Bradbury teaches that “each element indicates size (type) which discloses that the type was recorded when the element was written,” and “comparing the type (inputting the size) and converting the type (setting to all ones or zeros) using the convert-to-type number logic.” Ans. 12 (citing Bradbury ¶ 92). Appellant argues that Bradbury “simply does not discuss recording the type of a varying number of elements, comparing the type against an expected type, and converting the type to the expected type using a set of rules.” Appeal Br. 23; see also Reply Br. 14. We are persuaded by Appellant’s arguments. As cited by the Examiner, Bradbury discloses that “a vector register 480 includes a plurality of elements 482a-482n, each including a floating point number,” and that each “floating point number and the size of the floating point number 483a- 483n are input to convert-to-type number logic” and “output is a particular bit representing a class/sign for the floating point number.” Bradbury ¶ 92. Appeal 2020-005772 Application 14/709,730 22 Bradbury further discloses that “a selected bit in each mask 486a-486b corresponding to each particular bit is checked,” and then depending on “whether the selected bit is set, the first operand in a vector register 488 is set.” Bradbury ¶ 92. In other words, Bradbury teaches determining a bit representing a class/sign for the floating point number included in the vector register elements, checking (i.e., comparing) a selected bit in the mask, and based on whether the selected bit is set (i.e., responsive to the comparing), then setting the elements of the first operand in a vector register. We agree with Appellant that the Examiner does not make sufficient findings that Bradbury’s checking a selected bit in the mask and setting elements of the first operand in a vector register based on whether the selected bit is set teaches “compar[ing] the recorded type against an expected type, and responsive to determining that the recorded type differs from the expected type, convert[ing] the type to the expected type using a set of rules” as claimed. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 17 and 38. Claims 18 and 39 Claim 18, and commensurately claim 39, further recites “wherein . . . the execution unit is [to:] record the type of the varying number of elements, compare the recorded type against an expected type, and responsive to determining that the recorded type differs from the expected type, invoke an exception.” The Examiner finds that Bradbury teaches that “each element indicates size (type) which discloses that the type was recorded when the element was written,” and “comparing the type (inputting the size) and Appeal 2020-005772 Application 14/709,730 23 converting the type (setting to all ones or zeros) using the convert-to-type number logic.” Ans. 12 (citing Bradbury ¶ 92). The Examiner also finds that Bradbury teaches “an unexpected type causing an exception (divide by zero).” Ans. 13 (citing Bradbury ¶ 177). Appellant argues that Bradbury “simply do[es] not discuss recording the type of a varying number of elements, comparing the type against an expected type, and invoke an exception response to determining that the recorded type differs from the expected type.” Appeal Br. 23; see also Reply Br. 14-15. We are persuaded by Appellant’s arguments. As cited by the Examiner, Bradbury recites that “a vector register 480 includes a plurality of elements 482a-482n, each including a floating point number,” and that each “floating point number and the size of the floating point number 483a-483n are input to convert-to-type number logic” and “output is a particular bit representing a class/sign for the floating point number.” Bradbury ¶ 92. Bradbury further recites that “a selected bit in each mask 486a-486b corresponding to each particular bit is checked,” and then depending on “whether the selected bit is set, the first operand in a vector register 488 is set.” Bradbury ¶ 92. In other words, Bradbury teaches determining a particular bit representing a class/sign for the floating point number included in the vector register elements, checking (i.e., comparing) a selected bit in the mask, and based on whether the selected bit is set (i.e., responsive to the comparing), then setting the elements of the first operand in a vector register. We agree with Appellant that the Examiner does not make sufficient findings that Bradbury’s checking a selected bit in the mask and setting Appeal 2020-005772 Application 14/709,730 24 elements of the first operand in a vector register based on whether the selected bit is set teaches “compar[ing] the recorded type against an expected type, and responsive to determining that the recorded type differs from the expected type, invok[ing] an exception,” as claimed. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 18 and 39. Claims 20 and 41 Claim 20, and commensurately claim 41, further recites “wherein the execution unit is to execute the first vector instruction and the second vector instruction to read from input vector registers not in their entirety along with the first vector length and the second vector length register over multiple cycles.” The Examiner finds that Damron teaches “processing a vector instruction using the less than the entire width of the vector register,” and “processing subsets of the inputs over multiple cycles (an iterative loop) and storing the results.” Ans. 13-14 (citing Damron ¶¶ 38, 64). Appellant argues that Damron’s “vector register is always read in its entirety, even when the value in a vector size register is less than the actual width of a vector register” because “when the value in the vector size register is 4, the vector register stores 4 elements and all 4 elements are read.” Appeal Br. 24; see also Reply Br. 15. We are persuaded by Appellant’s arguments. As cited by the Examiner, Damron recites “executing the code 400C with a vector processing instruction width.” Damron ¶ 64. Damron provides an example where “the processing unit 602D sets the width of the vector register 602D stored in the vector size register 605D to four” as opposed to the width of Appeal 2020-005772 Application 14/709,730 25 sixteen and then “process[es] the variable vector processing instructions as vector processing instructions with a width of four utilizing only a portion of the vector register 604D.” Damron ¶ 64. In other words, Damron teaches setting the width of the vector register to be only a portion of the vector register, and then processing the vector processing instructions with that set width of the vector register. However, the Examiner has not sufficiently shown that Damron teaches processing the instructions with the set width of the vector register not in their entirety. Specifically, Damron teaches setting the vector size register value to 4 and then processing the vector processing instructions with a width of 4, which is the entirety of the set vector size register of 4. See Damron ¶ 64; Appeal Br. 24. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 20 and 41. Claims 21 and 42 Claim 21, and commensurately claim 42, further recites “wherein the vector register file is implemented using one or more memory arrays.” The Examiner finds that Damron teaches “that the processing unit includes cache memory, which discloses a memory array,” which “is defined by the specification as including a number of rows” while “[c]ache memory is conventionally understood to be arranged in a number of lines, which are rows.” Ans. 14 (citing Damron ¶ 39). Appellant argues that Damron’s “cache memory” does not “necessarily mean[] memory array.” Appeal Br. 25; see also Reply Br. 16. We are persuaded by Appellant’s arguments. Damron recites that “the variable vector processing instruction may perform various operations on a vector stored in the vector register 104 such as a vector load instruction Appeal 2020-005772 Application 14/709,730 26 to load a vector from memory into the vector register 104.” Damron ¶ 39. Damron also recites that the “processing unit 102 may also include one or more memories and/or cache memories.” Damron ¶ 40. We agree with Appellant that the Examiner does not make sufficient findings that Damron’s processing unit including memories and/or cache memories teaches using one or more memory arrays. Accordingly, on this record, we do not sustain the Examiner’s 35 U.S.C. § 103 rejection of dependent claims 21 and 42. CONCLUSION We affirm the Examiner’s rejections of claims 1, 3, 5-8, 11-16, 19, 22, 24, 26-29, 32-37, and 40 under 35 U.S.C. § 103. We reverse the Examiner’s rejection of claims 2, 9, 10, 17, 18, 20, 21, 23, 30, 31, 38, 39, 41, and 42 under 35 U.S.C. § 103. In summary: Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1, 3, 5, 19-22, 24, 26, 40-42 103 Damron, Nickolls 1, 3, 5, 19, 22, 24, 26, 40 20, 21, 41, 42 2, 23 103 Damron, Nickolls, Karkhanis 2, 23 6-10, 16-18, 27- 31, 37-39 103 Damron, Nickolls, Bradbury 6-8, 16, 27- 29, 37 9, 10, 17, 18, 30, 31, 38, 39 11-15, 32-36 103 Damron, Nickolls, Moyer 11-15, 32-36 Overall Outcome 1, 3, 5-8, 11- 16, 19, 22, 24, 2, 9, 10, 17, 18, Appeal 2020-005772 Application 14/709,730 27 Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 26-29, 32-37, 40 20, 21, 23, 30, 31, 38, 39, 41, 42 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv). See 37 C.F.R. § 41.50(f). AFFIRMED IN PART