DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner’s Note
Examiner notes that the amendment of claims 8 and 15 do not comply with 37 CFR 1.121(c)(2), which states that “[a]ll claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of ‘currently amended,’ and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims.” Ensure that the status of the claims are correct and comply with 37 CFR 1.121(c)(2) in the future.
Drawings
The lengthy set of drawings has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the drawings.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Recommendations
Examiner makes the following recommendations:
Claim 8, line 2: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim 16, lines 11-12: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim 19, line 5: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim Interpretation
The following is a quotation of MPEP 2111.04(II):
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed.
Regarding claim 1, the claim recites “based on a determination that a control value is a first value” and “based on a determination that the control value is a second value” in lines 4, 8-9, and 11-12. The Applicant’s specification in paragraphs [0067, 00203] suggests that the control value may be a third value, different from the first or second value. Under BRI, none of the limitations are required and the claim would simply recite “a method performed by a processor” when the control value is the third value. Therefore, the limitations, recited above, are contingent. Applicant is advised to insert “positively occurring” actions within the method claim so that the condition of the contingent limitations may be satisfied and recites the same invention as the independent processor and system claims. Note: This does not indicate the claim is allowable and should not be interpreted in that regard.
Regarding claim 2, the claim recites a limitation which is conditional on the contingent limitations “when a control value is a second value” being true.
Regarding claim 6-7, the claims recite “when the control value is the first value” and “based on a determination that the control value is the second value”. Under BRI, none of the limitations are required and the claim would simply recite “decoding a processor state save instruction” and “performing operations corresponding to the processor state save instruction” when the control value is the third value. Therefore, the limitations, recited above, are contingent.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 15 recites the limitation "the fourth instances of the vector instructions" in line 2. There is insufficient antecedent basis for this limitation in the claim. There was no prior instance of “fourth instances of the vector instructions” within the claim or the claim it depends on. For the sake of examination, Examiner will interpret this limitation to be “decode fourth instances of the vector instructions”.
Claim 15 recites the limitation "the fifth instances of the vector instructions" in line 8. There is insufficient antecedent basis for this limitation in the claim. There was no prior instance of “fifth instances of the vector instructions” within the claim or the claim it depends on. For the sake of examination, Examiner will interpret this limitation to be “decode fifth instances of the vector instructions”.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-9, and 11-15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sahita et al. (US 11029957 B1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Wikipedia “list of x86 instructions” is cited as extrinsic evidence to indicate that the even narrower vector width instructions uses a particular opcode format.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area, XSAVE, and XRSTOR, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 1, Sahita teaches a method performed by a processor (Fig. 1: Processor core 109(1-N) as the processor), the method comprising:
executing first instances of vector instructions having respective opcode values regardless of whether they specify wider vectors of a wider vector width or narrower vectors of a narrower vector width, based on a determination that a control value is a first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can execute AVX instructions and AVX-512, when allowed by the control register 112 (i.e., XCR0). AVX/AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). The bits set in XCR0 as the control value and bits 1-2 and 5-7 set to “1” in the XCR0 register as the first value. AVX and AVX-512 instructions as the first instances of vector instructions), the wider vector width being wider than the narrower vector width (Col. 11 lines 9-45: AVX-512 instructions indicate wider vector widths (512-bit vector widths) being wider than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5))
executing second instances of the vector instructions having the respective opcode values when they specify narrower vectors of the narrower vector width, but do not specify wider vectors of the wider vector width, based on a determination that the control value is a second value different than the first value (Fig. 1 and Col. 11 lines 9-45: Bits 1-2 are set to “1” and bits 5-7 are set to “0” as the second value. When the bits are set in the specific configuration, AVX instructions, which specify narrower vectors of the narrower vector width but does not specify wider vectors of the wider vector length, may be executed by the execution circuit 154 within one of processor cores 108(1-N). AVX instructions as the second instances of vector instructions); and
preventing execution of third instances of the vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, based on a determination that the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “0”, AVX-512 instructions, which specify wider vectors of the wider vector width, cannot be executed (i.e., prevented from executing). AVX-512 instructions as the third instances of vector instructions).
Alternatively, regarding claim 1, Sahita teaches a method performed by a processor (Fig. 1: Processor core 109(1-N) as the processor) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Claim 2 is rejected for the same reason as the alternate rejection of claim 1, because, as discussed in the “Claim Interpretation” section, the limitation of claim 2 is contingent and not required.
Regarding claim 2, Sahita teaches the method of claim 1, wherein said preventing comprises causing exceptions for the third instances of the vector instructions (Fig. 1 and Col. 11 lines 9-45: When XCR0[7:5]: is set to “0”, the execution of instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)).
Regarding claim 3, Sahita teaches the method of claim 1, further comprising accessing the control value from an on-die storage location that is on a die on which the processor is disposed (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The processing cores 108(1-N) (core 2502A-N in Fig. 29) may be implemented on a system on a chip (i.e., a die). The control value, located in a control register 112 (i.e., a storage location) in the processing cores, would be considered an on-die storage location that is on a die on which the processor is disposed. Therefore, the processing system would be accessing the control value from an on-die storage location).
Regarding claim 5, Sahita teaches the method of claim 1, wherein the wider vector width is at least 512 bits, and wherein the narrower vector width is no more than 256 bits (AVX uses 256-bit wide registers and AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512 bits and the narrower vector width is no more than 256 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 6, Sahita teaches the method of claim 1, further comprising:
decoding a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)); and
performing operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XSAVE instruction), including:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 set to “1” in the XCR0 register), saving processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
based on a determination that the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), saving processor state of a set of narrower vector registers of the narrower vector width to the processor state save area, without saving the processor state of the set of wider vector registers to the processor state save area (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are to be stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Alternatively, regarding claim 6, Sahita teaches the method of claim 1, further comprising:
decoding a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)); and
performing operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XSAVE instruction) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Regarding claim 7, Sahita teaches the method of claim 1, further comprising:
decoding a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)); and
performing operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XRSTOR instruction), including:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), loading processor state from a processor state save area in system memory into a set of wider vector registers of the wider vector width (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the data stored in the XSAVE memory location (i.e., XSAVE area 164) located within memory 102 are loaded into the ZMM0-31 registers (i.e., loading processor state into a set of wider vector registers) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15). XSAVE area as the processor state save area and memory 102 as the system memory. The ZMM0-31 registers as the set of wider vector registers); and
based on a determination that the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), loading processor state from the processor state save area into a set of narrower vector registers of the narrower vector width,
without loading processor state from the processor state save area into the set of wider vector registers (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the data for the YMM0-15 registers are loaded from the XSAVE memory location (i.e., XSAVE area 164 loads processor state into a set of narrower vector registers), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). The YMM0-15 registers as the set of narrower vector registers).
Alternatively, regarding claim 7, Sahita teaches the method of claim 1, further comprising:
decoding a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)); and
performing operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XRSTOR instruction) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Regarding claim 8, Sahita teaches a processor (Fig. 1: Processor core 109(1-N) as the processor) comprising:
front-end circuitry (Fig. 1: Units within IP gen stage 111, fetch stage 130, decode stage 140, and execution stage 150 as the front-end circuitry) to:
decode first instances of vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify wider vectors of a wider vector width or narrower vectors of a narrower vector width, when a control value is a first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode AVX instructions and AVX-512 through decode stage 140, when allowed by the control register 112 (i.e., XCR0). AVX/AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). The bits set in XCR0 as the control value and bits 1-2 and 5-7 set to “1” in the XCR0 register as the first value. Decoded AVX and AVX-512 instructions as the first decoded instructions), the wider vector width being wider than the narrower vector width (Col. 11 lines 9-45: AVX-512 instructions indicate wider vector widths (512-bit vector widths) being wider than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5));
decode second instances of the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify narrower vectors of the narrower vector width, but do not specify wider vectors of the wider vector width, when the control value is a second value different than the first value (Fig. 1 and Col. 11 lines 9-45: Bits 1-2 set to “1” and bits 5-7 are set to “0” as the second value. When the bits are set in the specific configuration, AVX instructions, which specify narrower vectors of the narrower vector width but does not specify wider vectors of the wider vector length, may be decoded in the decode stage 140 within one of processor cores 108(1-N). Decoded AVX instructions as the second decoded instructions); and
cause exceptions for third instances of the vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “0”, AVX-512 instructions, which specify wider vectors of the wider vector width, cannot be executed as the execution of AVX-512 instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)); and
execution circuitry coupled with the front-end circuitry (Fig. 1: Execution circuit 154, located within the execution stage 150), the execution circuitry to execute the first and second decoded instructions (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as first and second decoded instructions).
Regarding claim 9, Sahita teaches the processor of claim 8, further comprising:
a die on which the processor is disposed (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The processing cores 108(1-N) may be implemented on a system on a chip (i.e., a die)); and
an on-die storage location of the die, the on-die storage location to store the control value (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The control value, located in a control register 112 (i.e., a storage location) in the processing cores 108(1-N) (core 2502A-N in Fig. 29), would be considered an on-die storage location that is on a die on which the processor is disposed. Therefore, the processor cores would be accessing the control value from an on-die storage location).
Regarding claim 11, Sahita teaches the processor of claim 8, wherein the wider vector width is at least 512 bits (AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)), and
wherein the narrower vector width is no more than 256 bits (AVX uses 256-bit wide registers. Therefore, the narrower vector width is no more than 256 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 12, Sahita teaches the processor of claim 11, wherein the wider vector width is 512 bits, and wherein the narrower vector width is either 256 bits or 128 bits (AVX uses 256-bit wide registers and AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is 512 bits and the narrower vector width is 256 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 13, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to decode a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XSAVE instruction), including to:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), save processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), save processor state of a set of narrower vector registers of the narrower vector width to the processor state save area, without saving the processor state of the set of wider vector registers to the processor state save area (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are to be stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Regarding claim 14, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to decode a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XRSTOR instruction), including to:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 set to “1” in the XCR0 register), load processor state from a processor state save area in system memory into a set of wider vector registers of the wider vector width (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the data stored in the XSAVE memory location (i.e., XSAVE area 164) located within memory 102 are loaded into the ZMM0-31 registers (i.e., loading processor state into a set of wider vector registers) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15). XSAVE area as the processor state save area and memory 102 as the system memory. The ZMM0-31 registers as the set of wider vector registers); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), load processor state from the processor state save area into a set of narrower vector registers of the narrower vector width, but not load processor state from the processor state save area into the set of wider vector registers (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the data for the YMM0-15 registers are loaded from the XSAVE memory location (i.e., XSAVE area 164 loads processor state into a set of narrower vector registers), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). The YMM0-15 registers as the set of narrower vector registers).
Regarding claim 15, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to:
decode the fourth instances of the vector instructions having the respective opcode values into corresponding decoded instructions regardless of whether they specify wider vectors of the wider vector width, narrower vectors of the narrower vector width, or even narrower vectors of an even narrower vector width, when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode SSE instructions, AVX instructions, and AVX-512 through decode stage 140, when allowed by the control register 112 (i.e., XCR0). SSE, AVX, AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512. See Wikipedia “list of x86 instructions”, starting at page 25, SSE instructions have the “0F” byte and does not come with a prefix). SSE, AVX, and AVX-512 instructions as the fourth instances of the vector instructions), the even narrower vector width being narrower than the narrower vector width (Col. 11 lines 9-45: SSE instructions indicate even narrower vector widths (128-bit vector widths) being narrower than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “list of x86 instructions”, Pages 25 and 45-46)); and
decode the vector instructions having the respective opcode values into corresponding decoded instructions when they specify even narrower vectors of the even narrower vector width, but do not specify wider vectors of the wider vector width or narrower vectors the narrower vector width, when the control value is a third value different than the first and second values (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value. When the bits are set in the specific configuration, SSE instructions, which specify even narrower vectors of the even narrower vector width but does not specify wider vectors of the wider vector length or narrower vectors the narrower vector width, may be decoded in the decode stage 140 within one of processor cores 108(1-N). SSE instructions as the fifth instances of the vector instructions).
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 4 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Shanbhogue et al. (US 20180067866 A1) and Serebrin et al. (WO 2009094163 A2).
Regarding claim 4, Sahita teaches the method of claim 1.
Sahita does not teach to access the control value from a field of an architecturally-defined virtualization control structure in system memory.
Note that the XCR0 register is a control register (see Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Regarding claim 10, Sahita teaches the processor of claim 8.
Sahita does not teach that the processor is to access the control value from an architecturally-defined field of a virtualization control structure in system memory.
Note that the XCR0 register is a control register (see Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Barragy et al. (US 20060075218 A1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area, XSAVE, and XRSTOR, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 16, Sahita teaches a processor (Fig. 1: Processor core 109(1-N) as the processor) comprising:
an extended control register XCR0 (Fig. 1 and Col. 11 lines 9-45: Control register may be the XCR0 register) including:
a bit position XCR0[5] to store a first bit, the first bit to either be set to enable, or cleared to disable, use of a set of eight 64-bit mask registers k0-k7 (Col. 11 lines 9-45: When bit 5 of XCR0 is set, the opmask registers k0-k7 may be used, otherwise it’s disabled if bit 5 is not set. Bit 5 as the first bit);
a bit position XCR0[6] to store a second bit, the second bit to either be set to enable, or cleared to disable, use of a most significant 256-bits of a first set of sixteen 512-bit vector registers ZMM0-ZMM15 (Col. 11 lines 9-45: When bit 6 of XCR0 is set, the registers ZMM0-ZMM15 may be used, otherwise they’re disabled if bit 6 is not set. Bit 6 as the second bit); and
a bit position XCR0[7] to store a third bit, the third bit to either be set to enable, or cleared to disable, use of a second set of sixteen 512-bit vector registers ZMM16- ZMM31 (Col. 11 lines 9-45: When bit 7 of XCR0 is set, the registers ZMM16-ZMM31 may be used, otherwise they’re disabled if bit 7 is not set. Bit 7 as the third bit); and
front-end circuitry coupled with the extended control register XCR0 (Fig. 1: Units within IP gen stage 111, fetch stage 130, decode stage 140, and execution stage 150 as the front-end circuitry. The control register is coupled with the units), the front-end circuitry to:
when the first, second, and third bits are set (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “1”), , decode first instances of vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify 512-bit vectors of a 512-bit vector width, 256-bit vectors of a 256-bit vector width, or 128-bit vectors of a 128-bit vector width (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode AVX instructions and AVX-512 through decode stage 140, when bit 2 and bits 5-7 are set to “1” in the XCR0 register. AVX-512 instructions indicate 512-bit wide vectors and AVX instructions indicate 256-bit wide vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). Decoded AVX and AVX-512 instructions as the first decoded instructions); and
when the first, second, and third bits are set (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “1”), :
decode second instances of the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify 256-bit vectors of the 256-bit vector width or 128-bit vectors of the 128-bit vector width ; and
execution circuitry, coupled with the front-end circuitry (Fig. 1: Execution circuit 154, located within the execution stage 150), the execution circuitry to execute the first and second decoded instructions (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as first and second decoded instructions).
Sahita does not teach that when the first, second, and third bits are set, and when a control value is a first value, decode vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify 512-bit vectors of a 512-bit vector width, 256-bit vectors of a 256-bit vector width, or 128-bit vectors of a 128-bit vector width; and
when the first, second, and third bits are set, and when the control value is a second value different than the first value:
decode the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify 256-bit vectors of the 256-bit vector width or 128-bit vectors of the 128-bit vector width but not 512-bit vectors of the 512-bit vector width; and
cause exceptions for third instances of the vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, when the control value is the second value.
Note that in Sahita, the XCR0 register is a control register that configures the features of a processor (see Col. 11 lines 9-45), which acts as a configuration register. Additionally, note that when an XCR0 bit 5-7 are “read” as 0, the execution of AVX-512 instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)
Barragy teaches a disable override register (Figs. 2-3 and [0025-0029]: The disable override register (DOR) 90 may override disable a processor feature which may be indicated by a processor configuration register (PCR) 70), in which the value stored in the register would act as a control value and override values read from a configuration register.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Barragy to have used a disable override register (DOR) alongside the XCR0 register such that bit values of the XCR0 register can be read as “0” without modifying the XCR0 register, allowing the execution of AVX instructions and AVX-512 instructions when the control value of the DOR does not override the XCR0 values and only allowing the execution of AVX instructions when the DOR overrides bits 5-7 of the XCR0 register to be read as “0”, causing an exception when an attempt is made to execute AVX-512 instructions. One of ordinary skill would recognize that certain processor features may be inappropriate during a given program phase. Therefore, by disabling certain processor features, program performance may improve (see [0016, 0019]).
Claims 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Barragy et al. (US 20060075218 A1), Shanbhogue et al. (US 20180067866 A1), and Serebrin et al. (WO 2009094163 A2).
Regarding claim 17, Sahita, in view of Barragy, teaches the processor of claim 16.
Sahita, in view of Barragy does not teach that the processor is to access the control value from an architecturally-defined field of a virtualization control structure in system memory.
Note that in Sahita, the XCR0 register is a control register (see Sahita, Col. 11 lines 9-45). Furthermore, the disable override register in the current embodiment controls the XCR0 register, therefore considered a control register.
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy, with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Barragy and Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy and Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Claims 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Shanbhogue et al. (US 20180067866 A1), Serebrin et al. (WO 2009094163 A2), and Rozas et al. (US 20190196982 A1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area and the XSAVE instruction, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 19, the claim is mostly rejected for the same reasons as claim 8.
Sahita also teaches a system (Fig. 1: Computer system) comprising:
a memory ; and
a processor coupled with the memory (Fig. 1: The processor cores 108(1-N) is coupled to memory 102 through system bus 107. Processor cores as the processor).
Sahita does not teach a dynamic random access memory (DRAM) to store a virtual machine control structure (VMCS), the VMCS having a field to store a control value and a processor coupled with the DRAM.
Note that the memory may store details relating to virtual machines (see Col. 8, lines 7-36). Furthermore, note that the XCR0 register is a control register (see Sahita, Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS, stored in a memory ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy, with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
However, the combination raises the issue of how the control register data is to be accessed from the VMCS.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Sahita, in view of Shanbhogue and Serebrin, still does not teach that the memory to store the VMCS is a DRAM.
Rozas teaches the system memory being DRAM and stores the VMCS (Fig. 1A and [0041]: System memory 160 may be DRAM).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue and Serebrin, with the teachings of Rozas to have made the memory to store the VMCS be DRAM. DRAM provides higher storage densities and lower costs compared to other memories such as SDRAM, which may be preferred by one of ordinary skill.
Regarding claim 20, Sahita, in view of Shanbhogue, Serebrin, and Rozas, teaches the system of claim 19, wherein the wider vector width is at least 512 bits (AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)), and wherein the narrower vector width is no more than 256 bits (AVX uses 256-bit wide registers. Therefore, the narrower vector width is no more than 256 bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 21, Sahita, in view of Shanbhogue, Serebrin, and Rozas, teaches the system of claim 19, wherein the front-end circuitry is to decode a processor state save instruction (Sahita, Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XSAVE instruction), including to:
when the control value is the first value (Sahita, Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), save processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Sahita, Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
when the control value is the second value (Sahita, Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), save processor state of a set of narrower vector registers of the narrower vector width to the processor state save area, without saving the processor state of the set of wider vector registers to the processor state save area (Sahita, Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Allowable Subject Matter
Claim 18 is 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.
The statement of reasons for the indication of allowable subject matter of claim 18 can be seen in the Non-Final Office Action mailed March 4, 2026.
Response to Arguments
Applicant's arguments, filed September 4, 2026, with respect to the rejections of claims 1-3, 5-9, 11-15 under 35 U.S.C. 102 and 4, 10, 16-17 and 19-21 under 35 U.S.C. 103 have been fully considered but they are not persuasive.
Regarding arguments on pages 3-4 of Remarks, Applicant argues that Examiner’s interpretation of the claim language is not consistent with the claim limitations.
Examiner respectfully disagrees with this argument. First, note that each limitation starts with some kind of instance of vector instructions (e.g., first instances, second instances, etc.). Therefore, these instances don’t have to be the same. Examiner points to AVX and AVX-512 instructions as a first instance of vector instructions, which is a subset of vector instructions, where AVX, AVX-512, and SSE make up the set of vector instructions having respective opcodes. Then, for the second instance of vector instructions, Examiner points to the AVX instructions, which is another subset of vector instructions having respective opcodes from the x86 ISA. Then, for the third instance of vector instructions, Examiner points to the AVX-512 instructions, which is another subset of vector instructions having respective opcodes from the x86 ISA. Applicant interprets the limitation “vector instructions having respective opcode values” in each limitation paragraph as referring to the same set of vector instructions with the same opcodes. However, the claims are not written in the way the Applicant interprets the claims. Therefore, Applicant’s remarks regarding Examiner’s incorrect interpretation of the claims is considered not persuasive.
Examiner will maintain the rejections of claims 1-3, 5-9, 11-15 under 35 U.S.C. 102 and 4, 10, 16-17 and 19-21 under 35 U.S.C. 103
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20260259731 A1: Tate teaches an ISA which comprises a register to indicate data in a vector register to be a vector (can be seen as a narrower vector length) or a matrix (can be seen as a wider vector length).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EMILIO ALCANTARA-RAMOS whose telephone number is (571)272-4211. The examiner can normally be reached Mon-Fri 8:30-5:00 PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta can be reached at (571)270-3995. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/E.A./Examiner, Art Unit 2183
/David J. Huisman/Primary Examiner, Art Unit 2183
