CTNF 18/529,694 CTNF 96345 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 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. Claim 20 is rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. Claim 20 recites “[a] non-transitory computer readable medium comprising a circuit representation that, when processed by a computer, is used to program or manufacture an integrated circuit” followed by a description of the integrated circuit components. Reciting a “circuit representation” used by a computer to program or manufacture an IC without any characterization of the computer usage renders claim 20 indefinite because the invention may be interpreted as an apparatus comprising a circuit representation (some form of description) that is used/processed by a computer to effectuate programming or manufacturing an IC, or alternatively may be interpreted as an apparatus that includes a circuit representation (some form of description) with the computer implementation (when/if processed by a computer) not being a positively recited functional limitation but rather a potential application of the recited apparatus. Therefore, one of ordinary skill would be unable to determine, with reasonable clarity, the scope of the claimed subject matter. For the purpose of examination, claim 20 is interpreted in the former manner (i.e., an apparatus comprising a circuit representation (some form of description) that is used/processes by a computer to effectuate programming or manufacturing an IC ). Examiner notes however, that as explained in further detail in the rejection of claim 20 below, that such interpretation based on the current characterization of the invention in the preamble, introduces potential for an unintendedly broad reading of the claim with respect to the prior art. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 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 – 07-08-aia AIA (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. 07-15 AIA Claim s 1-3, 5, and 8-9 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by Bernardi et al., "MIHST: A Hardware Technique for Embedded Microprocessor Functional On-Line Self-Test," in IEEE Transactions on Computers , vol. 63, no. 11, pp. 2760-2771, Nov. 2014 . As to claim 1, Bernardi teaches “[a]n integrated circuit (Abstract describing testing structure solution applicable to processor cores embedded in a System on Chip (SoC)) comprising: a processor core configured to execute instructions (FIG. 1 depicting example system architecture including a CPU (processor core) (inherently configured to execute instructions); page 2761, 1 Introduction, paragraph below FIG. 1 beginning with “As a consequence…” describing execution of instructions by the processor being tested) ; one or more test mode registers configured to store test mode selection data (page 2760, I. Introduction, paragraph beginning with “1 The system may be either in normal or in test state…” describing the MIHST unit providing test instructions (test instructions implement a given test sequence and thereby effectuate a “selection” of a “test mode”) to processor under test; page 2761, 1 Introduction, paragraphs beginning with “The most evident advantage …” and “The MIHST unit is programmed …” explaining that the MIHST is programmed to include the test data/instructions and therefore regular system memory (memory outside the processor’s internal storage) is not required for such storage; FIG. 3 depicting MIHST (test) mode instructions stored in instruction register; page 2762, 3 Proposed Approach, paragraph beginning with “As a further explanation…”; FIG. 5 depicting MIHST unit architecture as generating and storing the test opcodes and operands for test instructions; page 2764, MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture includes …” describing MIHST instruction register) ; one or more test result registers configured to store test result data (FIG. 5 depicting MIHST unit architecture including Result Collection; page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature and may be implemented by a MISR (multi-input signature register) module) ; and a test mode circuitry (FIGS. 1 depicting MIHST unit and MUX, FIG. 14 MIHST Unit, D flip-flop, and MUX; Abstract describing MIHST unit as a hardware module (i.e., implemented via circuitry)) configured to: change a microarchitectural state of the processor core from a first state to one or more test mode states (FIG. 1 test mode input to MUX for selectively switching between normal mode of CPU (input from Code Memory to system bus/CPU) to test mode of CPU (input from MIHST to system bus/CPU). Examiner notes that the differing instruction inputs received and processed by the CPU changes the microarchitectural state of the CPU; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” describing switch to test mode as including that the ISR enables the MIHST and forces the system to enter the test mode (pulse on the test_ON signal)) based on test mode selection data written to the one or more test mode registers (the test instructions from the MIHST unit that changes the microarchitectural state of the CPU are stored in register(s) per page 2764, MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture includes …” describing MIHST instruction register and FIG. 3 depicting MIHST (test) mode instructions stored in instruction register, and page 2762, 3.1 Forced Instruction Sequence, paragraph beginning with “As a further explanation…” (CPU instruction register effectuating test and therefore also constituting “test mode” register)) ; execute a sequence of instructions on the processor core in the one or more test mode states (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (i.e., processor execution of the test instructions); page 2761, 1 Introduction, paragraph beginning with “As a consequence…”) to obtain a resulting architectural state of the processor core (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (state is in part determined by processor activity which alters its state in accordance with program sequence dependent context of the processor as for example, inferred on page 2761, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” explaining that a given processor “state” in terms of register contents is preserved for testing)) ; store test result data based on the resulting architectural state (page 2761, 1 Introduction, paragraph beginning with “This working principle …” describing observing test instruction results (i.e., processor behavior/state)) in the one or more test result registers (FIG. 5 depicting MIHST unit architecture including Result Collection; page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature and may be implemented by a MISR (multi-input signature register) module) ; and after executing the sequence of instructions, restore the microarchitectural state of the processor core to the first state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” describing that interrupt feature used to preserve processor state; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” explaining that the “test execution flow” includes a state preservation step (c. 1. prior to testing, saves all general purpose registers (GPRs) to be used in testing), 7. exits the test mode, and e. 8. restores the GPR contents and f. restores system context prior to testing interrupt) based on test mode selection data written to the one or more test mode registers (the foregoing GPR/context restoration, described on page 2768, performed as part of “test execution flow” that includes resetting FIG. 14 D flip-flop with test_Off as described in item “7.” and “e.”) . As to claim 2, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) a processor pipeline branch of the processor core to be selected (page 2762, 3 Proposed Approach, paragraph beginning with “The sample code includes …” describing test model as including a jump/branch instruction (instruction to select a processor branch); Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors) in a dispatch stage of the processor core (execution of instructions in a pipelined processor such as branch instruction inherently entails instruction dispatch (control passes to another instruction sequence)) .” As to claim 3, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states causes a processor pipeline branch of the processor core to be disabled (page 2761, 1 Introduction, paragraph beginning with “As a consequence of …” explaining that MIHST execution (test mode) moves execution control sequencing (e.g., conditional jump (branch)) from the processor to the MIHST-determined instruction sequence (in this manner, otherwise processor-determined branches are effectively disabled)) .” As to claim 5, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) each of multiple processor pipelines of the processor core (Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors (inherently applied parallel processing of instructions via multiple independent execution stages) to be selected in fixed order by a dispatch stage of the processor core (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that the instruction execution sequence (inherently includes dispatch) is forced as a fixed MIHST-determined matter) .” As to claim 8, Bernardi teaches “[t]he integrated circuit of claim 1, in which the test result data is based on intermediate results generated when executing an instruction of the sequence of instructions before the instruction is retired (FIG. 2(c) depicting sequence of program instructions (i.e., results of any given point in program progression is dependent on (based on) previous instruction execution. In such configuration and noting the storage of test results as described on page 2764, 4 MIHST Unit Architecture And Behavior, paragraph beginning with “A Results Collection module …” describing collection/storage of monitored data and generating test signature indicative of execution, the stored result data is inevitably “based on” intermediate results) .” As to claim 9, Bernardi teaches “[t]he integrated circuit of claim 1, in which the test mode circuitry is configured to: responsive to an interrupt (page 2768, Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “d.7.” that execution exits test mode in response to pulse on the test_OFF signal) , write to the one or more test mode registers (FIG. 14 depicting test mode off from output of MIHST and input to flip-flop (effectively a register storing a binary on/off condition) to change test_mode) to restore the microarchitectural state of the processor core to the first state (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items “e.” and “f.” that control is returned to the native ISR, GPR contents are restored and the system context of the microprocessor is restored) ; and after completion of a handling routine for the interrupt (pages 2767-2768, 6. Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology was defined …” and “When the test is activated …” describing use of system interrupt for initiating testing) and completion of execution of the sequence of instructions (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items a. through d. (completion of execution of instruction sequence) , check the one or more test mode registers to determine whether the test mode has been interrupted (page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “7.” exiting test mode in response to test_OFF pulse, which resets the test_mode bit of the flip-flop depicted in FIG. 14) .” Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Mishaeli (US 2020/0096569 A1) . As to claim 4, Bernardi teaches “[t]he integrated circuit of claim 1, in which at least one of the one or more test mode states forces (Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) .” While Bernardi does not explicitly teach register renaming for allocating physical registers, Bernardi further discloses that the MIHST/test sequence includes a branch/jump execution sequence (FIG. 2 (c) MIHST mode execution depicting test instruction sequence including jump instruction; page 2762, 3 Proposed Approach, paragraphs beginning with “FIG. 2 exemplifies …” and “The sample code …”) for a pipelined processor (Abstract) that includes an instruction “MOV [addr], R3” at a second instance of program counter position “3” (FIG. 2 (c)) that presents a writing/rewriting of register R3 (architectural register) as part of the jump/branch instruction (FIG. 2 (c)) that would typically trigger a register renaming processor to allocate a physical register to store the value in the execution fixed order (architectural order) as is well-known in out-of-order processing to avoid false dependencies. For example, Mishaeli discloses an apparatus for implementing processor testing (Abstract) for pipelined processors ([0021]) that includes executing branch instructions in which a rename stage of the processor allocates physical registers of the processor (FIGS. 8A and 8B depicting instruction pipeline 800 including the Alloc and Rename portion of branch prediction (executed by rename/allocator unit 852 in execution end unit 850 in FIG. 8B) for remapping instruction cache registers (physical register file units 858) in the programmed order (in accordance with pipeline 800)) in a fixed order ([0068] register renaming may be implemented for an in-order architecture (i.e., branch execution in program counter instruction order)) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli’s teaching of using register renaming (i.e., renaming architectural registers to physical registers) that may be applied to an in-order (fixed) execution sequence to apparatus taught by Bernardi in which the test execution flow including jump/branch instructions are implemented in a preset (fixed) manner as depicted in (FIG. 2 (c)) by sequential access (program counter selecting preset sequence of instruction set registers) such that in combination the test mode of the apparatus includes forcing a rename stage of the processor core to allocate physical registers of the processor core in a fixed order. The motivation would have been to enable a fixed instruction set execution that accommodates the need to reallocate/rename registers for branch instructions . 07-21-aia AIA Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Gangasani (US 2012/0226942 A1) . As to claim 6, Bernardi teaches “[t]he integrated circuit of claim 1,” and further teaches compression of the test result data including the architectural state result from the execution of the test sequence (page 2764, 4 MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture of the of the MIHST unit includes …” describing “Results Collection module compressing the monitored address, data and control bus signals” related to the test signature), but does not expressly teach that the compression is via XOR of the result data and therefore does not teach “in which the test result data includes an XOR of data, including the resulting architectural state, generated when executing the sequence of instructions.” Prior to the effective filing date, using XOR as a testing results compression technique was known. For example, Gangasani discloses a method/apparatus for implementing run-time self-testing for testing processors (Abstract) that compresses test result data that reflects the architectural state (FIG. 4 output from unit under test (UUT) 450 processed by compacter 460 prior to storing result signature in MISR 470, [0045]-[0046] test vector patterns applied as stimulus to UUT and UUT data (state as stimulated) captured and loaded into compacter 460) by using an XOR of the test result data ([0046] compacter 460 applies XOR that compacts the result data) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Gangasani’s teaching of applying XOR to output architectural result data to the apparatus taught by Bernardi, which teaches compressing the processor architecture test results, such that in combination the apparatus is configured such that the test result data includes an XOR of data, including the resulting architectural state, generated when executing the sequence of instructions. The motivation would have been to compress the result data to conserve overall storage capacity of the apparatus using a known design option for implementing such compression with predictable success . 07-21-aia AIA Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Gangasani (US 2012/0226942 A1), and in further view of Sane (US 2020/0310957 A1) . As to claim 7, Bernardi teaches “[t]he integrated circuit of claim 1,” and further teaches compression of the test result data (page 2764, 4 MIHST Unit Architecture and Behavior, paragraph beginning with “The architecture of the of the MIHST unit includes …” describing “Results Collection module compressing the monitored address, data and control bus signals” related to the test signature), but does not expressly teach that the compression is via XOR of the result data and therefore does not teach “in which the test result data includes an XOR of data, including opcodes for retired instructions, generated when executing the sequence of instructions.” Prior to the effective filing date, using XOR as a testing results compression technique was known. For example, Gangasani discloses a method/apparatus for implementing run-time self-testing for testing processors (Abstract) that compresses test result data that reflects the architectural state (FIG. 4 output from unit under test (UUT) 450 processed by compacter 460 prior to storing result signature in MISR 470, [0045]-[0046] test vector patterns applied as stimulus to UUT and UUT data (state as stimulated) captured and loaded into compacter 460) by using an XOR of the test result data ([0046] compacter 460 applies XOR that compacts the result data) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Gangasani’s teaching of applying XOR to result data to the apparatus taught by Bernardi, which teaches compressing test results, such that in combination the apparatus is configured such that the test result data includes an XOR of data. The motivation would have been to compress the result data to conserve overall storage capacity of the apparatus using a known design option for implementing such compression with predictable success. Neither of Bernardi nor Gangasani appears to teach that the compressed results may include opcodes for retired instructions and therefore do no teach the XOR data “including opcodes for retired instructions, generated when executing the sequence of instructions.” Sane discloses a system/method for implementing processor core performance monitoring (Abstract; [0026]) that includes storing instructions having opcodes in the monitoring result signatures ([0026] allocation paths derived from last branch record (LBR) information are translated using hash into fixed bit signatures; FIG. 2B depicting allocation paths 250, 260, 270, and 280 compressed via hash into corresponding signatures 255, 265, 275, and 285 as described in [0030]-[0031]; [0057] the instructions include opcodes) , including applying the results processing (hash) to retired instructions (Abstract LBR records store recently retired instructions; [0088] and claim 3 hash applied to recently retired instructions) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Sane’s teaching of processor performance monitoring that includes generating signature results in the form of last branch records including corresponding instructions including retired instructions to the apparatus taught by Bernardi as modified by Gangasani, which teaches generating results signatures (Bernardi: page 2764, 4 MIHST Unit Architecture and Behavior, second column, bullet point beginning with “A Results Collection module …”; “ Gangasani: [0046]) using XOR as the result compression technique (Gangasani: [0046]), such that in combination the apparatus is configured such that “the test result data includes an XOR of data, including opcodes for retired instructions, generated when executing the sequence of instructions.” The motivation would have been to compress the result data, including preserving instruction data, which as disclosed by Sane may be useful as monitoring/testing results, as well as “execution output” to conserve overall storage capacity of the apparatus . 07-21-aia AIA Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi . As to claim 10, Bernardi teaches “[t]he integrated circuit of claim 1, comprising: a test controller (FIG. 14 MIHST architecture including MIHST Unit, D flip-flop, and MUX external to CPU) ,” “configured to periodically initiate testing of the processor core by writing to the one or more test mode registers (periodic testing initiated with respect to system bus control by “test_On” write to the D flip flop to set “test_mode” into active test mode. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a testing control function and therefore constitutes part of “a test controller.”) ; a test status register (FIG. 14 D flip-flop storing test_mode state Q) accessible by the test controller (FIG. 14 D flip flop receives “test_On” and “test_Off” inputs and is therefore accessible by test controller) ; and the test mode circuitry (portion of “test controller” providing “test_On” input and MIHST Unit providing “test_Off” input) is configured to: write a test identifier to the test status register (FIG. 14 “test_On” input (write) to D flip flop results in output Q (test_mode) being set to indicate/identify test enabled. Examiner notes that the test mode functionality (inferentially appears to be the MIHST Unit which is expressly depicted in FIG. 14 as also provides a corresponding “test_Off” signal to the D flip flop) provides the write signal is performing a test function and therefore constitutes part of “test mode circuitry.” Applicant’s specification provides no description, purpose, or example of a “test identifier” such that “test identifier” may be reasonably interpreted as any indicator that serves to identify testing in a broad manner so as to encompass a signal that indicates a test) ; and write an indication of test status to the test status register, wherein the indication of test status indicates whether a test is running, interrupted, or completed (FIG. 14 MIHST unit writes to D flip flop via test_Off “control” to reset test_mode indicating completion of test) .” Bernardi does not explicitly teach that the “test controller, external to the processor core ” features depicted in FIG. 14 (e.g., any of MIHST Unit, D flip-flop, and MUX) actually provide the “test_On” write to the D flip flop to set “test_mode” into active test mode such that Bernardi does not expressly teach a test controller, “external to the processor core,” configured to periodically initiate testing of the processor core by writing to the one or more test mode registers. Bernardi teaches in FIG. 14 that the test controller “external to the processor core” at least provides the test_Off signal that effectuates a write (clear) to the D flip flop as part of completing the test mode. It would have been obvious to one of ordinary skill in the art before the effective filing date, in view of Bernardi’s teaching that the MIHST Unit is configured to control the setting of the D flip flop at least by providing the “test_Off” input, to have configured the MIHST Unit to also provide the “test_On” input. The motivation would have been to leverage the test-related programming of the MIHST Unit for determining when to enter test mode processing (responsive, for example, to an initial signaling of test mode enable at the enable input of the MIHST Unit) as well as for competing/exiting the test mode . 07-21-aia AIA Claim s 11-13 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi et al., "MIHST: A Hardware Technique for Embedded Microprocessor Functional On-Line Self-Test," in IEEE Transactions on Computers , vol. 63, no. 11, pp. 2760-2771, Nov. 2014 in view of Rajsuman (US 6,249,892 B1) . As to claim 11, Bernardi teaches “[a] method, comprising: writing to one or more test mode registers (FIG. 14 test_ON written to/stored by D flip-flop (register for providing MUX selection to switch to and from test mode)) to change a microarchitectural state of a processor core from a first state to one or more test mode states (FIG. 14 test_mode input to MUX selects MIHST test instruction input to CPU; Examiner notes that the differing instruction inputs received and processed by the CPU changes the microarchitectural state of the CPU; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” describing switch to test mode as including that the ISR enables the MIHST and forces the system to enter the test mode (pulse on the test_ON signal)) ; executing a sequence of instructions on the processor core in the one or more test mode states (page 2760, 1 Introduction, paragraph beginning with “1. The system may be either in …” describing MIHST unit as providing test instruction stream to the processor core and monitoring processor behavior (i.e., processor execution of the test instructions); page 2761, 1 Introduction, paragraph beginning with “As a consequence…”) to obtain a resulting architectural state of the processor core (execution of the test mode instructions results in an architectural state of CPU) ;” and “writing to the one or more test mode registers (GPR/context restoration, described on page 2768, performed as part of “test execution flow” that includes resetting FIG. 14 D flip-flop with test_Off as described in item “7.” and “e.”) to restore the microarchitectural state of the processor core to the first state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on on-line testing …” describing that interrupt feature used to preserve processor state; page 2768, 6 Use of MIHST For On-Line Testing, paragraph beginning with “When the test is activated …” explaining that the “test execution flow” includes a state preservation step (c. 1. prior to testing, saves all general purpose registers (GPRs) to be used in testing), 7. exits the test mode, and e. 8. restores the GPR contents and f. restores system context prior to testing interrupt) .” Bernardi does not appear to teach “comparing the resulting architectural state to an expected architectural state associated with the sequence of instructions to obtain a test result.” Rajsuman discloses a method/system for testing microprocessors (Abstract) that includes comparing microprocessor testing results with expected results to obtain a test result (col. 4 lines 28-32 describing implementing processor testing; col. 4 lines 51-54 content of MISR (test results) compared with pre-computed simulation signature (expected results) to determine whether there is a fault) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Rajsuman’s teaching of comparing the processor testing results with expected results to obtain a test result to the method taught by Bernardi, which teaches testing to generate architectural states of the processor, such that in combination the method includes comparing the resulting architectural state to an expected architectural state associated with the sequence of instructions to obtain a test result. The motivation would have been to effectuate a significant purpose in performing the processor testing in terms of determining whether the performance under test meets performance expectations as disclosed by Rajsuman. As to claim 12, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states forces (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) a processor pipeline branch of the processor core to be selected (Bernardi: page 2762, 3 Proposed Approach, paragraph beginning with “The sample code includes …” describing test model as including a jump/branch instruction (instruction to select a processor branch); Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors) in a dispatch stage of the processor core (Bernardi: execution of instructions in a pipelined processor such as branch instruction inherently entails instruction dispatch (control passes to another instruction sequence)) .” As to claim 13, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states causes a processor pipeline branch of the processor core to be disabled (Bernardi: page 2761, 1 Introduction, paragraph beginning with “As a consequence of …” explaining that MIHST execution (test mode) moves execution control sequencing (e.g., conditional jump (branch)) from the processor to the MIHST-determined instruction sequence (in this manner, otherwise processor-determined branches are effectively disabled)) .” As to claim 15, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states forces (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) each of multiple processor pipelines of the processor core (Bernardi: Abstract and page 2761, 1 Introduction, paragraph beginning with “To demonstrate the feasibility …” explaining the method applied to pipelined processors (inherently applied parallel processing of instructions via multiple independent execution stages) to be selected in fixed order by a dispatch stage of the processor core (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that the instruction execution sequence (inherently includes dispatch) is forced as a fixed MIHST-determined matter) .” As to claim 16, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, comprising: responsive to an interrupt (Bernardi: page 2768, Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “d.7.” that execution exits test mode in response to pulse on the test_OFF signal) , writing to the one or more test mode registers (Bernardi: FIG. 14 depicting test mode off from output of MIHST and input to flip-flop (effectively a register storing a binary on/off condition) to change test_mode) to restore the microarchitectural state of the processor core to the first state (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items “e.” and “f.” that control is returned to the native ISR, GPR contents are restored and the system context of the microprocessor is restored) ; and after completion of a handling routine for the interrupt (Bernardi: pages 2767-2768, 6. Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology was defined …” and “When the test is activated …” describing use of system interrupt for initiating testing) and completion of execution of the sequence of instructions (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in items a. through d. (completion of execution of instruction sequence) , checking the one or more test mode registers to determine whether the test mode has been interrupted (Bernardi: page 2768, 6. Use of MIHST For On-Line Testing, paragraph beginning with “The following steps describe the test execution flow…” describing in item “7.” exiting test mode in response to test_OFF pulse, which resets the test_mode bit of the flip-flop depicted in FIG. 14) .” 07-22-aia AIA Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Rajsuman as applied to claim 11 above, and further in view of Mishaeli (US 2020/0096569 A1) . As to claim 14, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which at least one of the one or more test mode states forces (Bernardi: Abstract and page 2762, 3 Proposed Approach, paragraph beginning with “The MIHST behavior …” explaining that MIHST technique forces the processor to execute MIHST (test) instructions) .” While Bernardi does not explicitly teach register renaming for allocating physical registers, Bernardi further discloses that the MIHST/test sequence includes a branch/jump execution sequence (FIG. 2 (c) MIHST mode execution depicting test instruction sequence including jump instruction; page 2762, 3 Proposed Approach, paragraphs beginning with “FIG. 2 exemplifies …” and “The sample code …”) for a pipelined processor (Abstract) that includes an instruction “MOV [addr], R3” at a second instance of program counter position “3” (FIG. 2 (c)) that presents a writing/rewriting of register R3 (architectural register) as part of the jump/branch instruction (FIG. 2 (c)) that would typically trigger a register renaming processor to allocate a physical register to store the value in the execution fixed order (architectural order) as is well-known in out-of-order processing to avoid false dependencies. For example, Mishaeli discloses an apparatus for implementing processor testing (Abstract) for pipelined processors ([0021]) that includes executing branch instructions in which a rename stage of the processor allocates physical registers of the processor (FIGS. 8A and 8B depicting instruction pipeline 800 including the Alloc and Rename portion of branch prediction (executed by rename/allocator unit 852 in execution end unit 850 in FIG. 8B) for remapping instruction cache registers (physical register file units 858) in the programmed order (in accordance with pipeline 800)) in a fixed order ([0068] register renaming may be implemented for an in-order architecture (i.e., branch execution in program counter instruction order)) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli’s teaching of using register renaming (i.e., renaming architectural registers to physical registers) that may be applied to an in-order (fixed) execution sequence to method taught by Bernardi as modified by Rajsuman in which as taught by Bernardi the test execution flow including jump/branch instructions are implemented in a preset (fixed) manner as depicted in (FIG. 2 (c)) by sequential access (program counter selecting preset sequence of instruction set registers) such that in combination the test mode includes forcing a rename stage of the processor core to allocate physical registers of the processor core in a fixed order. The motivation would have been to enable a fixed instruction set execution that accommodates the need to reallocate/rename registers for branch instructions . 07-22-aia AIA Claim s 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Rajsuman as applied to claim 11 above, and further in view of Mishaeli (US 2023/0102991 A1), Mishaeli ‘991 . As to claim 17, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11,” and Bernardi teaches that the MIHST testing utilizes processor registers for execution of the test instructions (pages 2760-2761, 1 Introduction, paragraphs beginning with “The MIHST approach is founded …” and “As a consequence …” explaining processor execution of the instruction sequence provided by MIHST (would inherently entail using processor registers such as instruction register as depicted in FIG. 3)) including using the native processor interrupt handling functions for entering test mode and preserving processor state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on online testing …” and pages 2767-2768, 6 Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology …” and “When the test is activated …” describing using of the interrupt service of the microprocessor to enter test mode while preserving processor state) . Use of a control status register for interrupt activation and storing state during interrupt handling was known prior to the effective filing date. For example, Mishaeli ‘991 discloses a method/system for testing processors (Abstract) in which a control register included in the processor core architecture (FIG. 2 processor core 110 including control registers 206A, [0046] control registers 206A serve at least in part to control testing) is used to save the state and isolate a processor core for testing (transferring of status/context) (Abstract setting of control register results in switch to test mode status of processor including preserving processor state and control transfer; [0054], [0070], and [0082]-[0084] control register written to for activating functional testing including saving processor state and transfer of processor control (effectively an interrupt and context switch)) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli ‘991’s teaching of the otherwise well-known use of control registers that affect processor status (a form of control status register) for implement context switches including preserving processor operational state and transfer of processor control to the method taught by Bernardi as modified by Rajsuman, which teaches using native processor interrupt functionality that includes preserving processor state and transferring control to test mode, such that in combination the method is configured such that “the one or more test mode registers include a control status register of the processor core.” The motivation would have been to leverage native processor interrupt functionality including a control status register for implementing switching between normal operations and test mode for efficiently controllable on-line testing as disclosed by each of Bernardi and Mishaeli ‘991. As to claim 18, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, and Bernardi teaches using the native processor interrupt handling functions (i.e., native to the processor instruction set architecture) for entering test mode and preserving processor state (page 2762, 3 Proposed Approach, paragraph beginning with “Focusing on online testing …” and pages 2767-2768, 6 Use of MIHST For On-Line Testing, paragraphs beginning with “A suitable methodology …” and “When the test is activated …” describing using of the interrupt service of the microprocessor to enter test mode while preserving processor state) . Using a control status register instruction for handling interrupts including state context switching (e.g., switching to a different instruction sequence for testing or other interrupt purposes) that would entail writing to registers (e.g., test mode registers if the interrupt is for testing) was known prior to the effective filing date. For example, Mishaeli ‘991 discloses a method/system for testing processors (Abstract) in which a control register included in the processor core architecture (FIG. 2 processor core 110 including control registers 206A, [0046] control registers 206A serve at least in part to control testing) is used to save the state and isolate a processor core for testing (transferring of status/context) (Abstract setting of control register results in switch to test mode status of processor including preserving processor state and control transfer; [0054], [0070], and [0082]-[0084] control register written to for activating functional testing including saving processor state and transfer of processor control (effectively an interrupt and context switch)) and that includes use of a control status register instruction that results in writing to test mode registers (FIG. 3 “Prolog” to testing (SBFT) includes Activate_SBFT instruction (WRMSR) to initiate switch to test mode including saving core state and loading SBFT-test to cache (entails writing to test mode registers because cached test instructions would necessarily have to be loaded into instruction registers for execution); [0033] testing initiated using a read-write machine specific register (WRMSR) command (this particular type of command is used for writing to processor registers for controlling processor behavior)) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mishaeli ‘991’s teaching of using native control status register instructions for writing to processor registers that for testing constitute test mode registers to the method taught by Bernardi as modified by Rajsuman, which teaches using native processor interrupt functionality that includes preserving processor state and transferring control to test mode, such that in combination the method is configured such that “the one or more test mode registers are written to using a control status register instruction of an instruction set architecture supported by the processor core.” The motivation would have been to leverage native processor interrupt logic including native control status register instructions for implementing switching between normal operations and test mode for efficiently controllable on-line testing as disclosed by each of Bernardi and Mishaeli ‘991 . 07-22-aia AIA Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi in view of Rajsuman as applied to claim 11 above, and further in view of Terechko (US 2019/0278677 A1) . As to claim 19, the combination of Bernardi and Rajsuman teaches “[t]he method of claim 11, in which the one or more test mode registers” “are written to using a store instruction of an instruction set architecture supported by the processor core (Bernardi: pages 2766-2767, 5.2 MIHST-Ready Program Generation, paragraph beginning with “Considering the previous …” explaining that test mode execution entails a sequence of branches and register load (store) instructions in which the sequence is generated by the MIHST unit. Examiner notes that execution of such instructions is performed by the processor such that the instructions are supported by the instruction set architecture of the processor) .” Bernardi does not appear to teach memory mapping of the test mode registers. Memory mapping of registers was known prior to the effective filing date. For example, Terechko discloses a method for testing processor cores (Abstract) in which memory mapping of registers is used to provide external access to register content ([0020] Memory Mapped Input/Output (MIMO) used for sharing test result register contents; [0021] describing shared memory region in which respective memory partitions mapped for respective processor cores) . It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Terechko’s teaching of memory mapping test registers to the method taught by Bernardi as modified by Rajsuman, which teaches that the test registers may be written to by store instructions, such that in combination the method is configured such that the one or more test mode registers “are memory mapped” and are written to using a store instruction of an instruction set architecture supported by the processor core. The motivation would have been to enable more efficient access to test data that is stored in registers as disclosed by Terechko . 07-21-aia AIA Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Bernardi et al., "MIHST: A Hardware Technique for Embedded Microprocessor Functional On-Line Self-Test," in IEEE Transactions on Computers , vol. 63, no. 11, pp. 2760-2771, Nov. 2014, in view of Blaauw (US 5,689,432) . Note : For the purpose of compact prosecution regarding claim 20, Examiner notes that nature of the claimed subject matter as it relates to prior art examination appears somewhat unclear such that Applicant should be aware that the scope of the claim in terms of prior art evaluation may be broader than what Applicant intends. Namely, claim 20 appears to be similar in some respects to a program product type claim that would typically be an apparatus (non-transitory computer readable medium) configured with instructions to perform a method when executed by a processor (a form of machine). Claim 20 differs in that in that the claim takes on the form of a “program product” claims but does not recite any instructions or actual functions/method steps (i.e., the program product is not recited as a form of “machine” including instructions). Claim 20 appears eligible under 101 because it recites “a non-transitory computer readable medium” (an apparatus such a computer memory or a sheet of paper). However, the nature of the apparatus in terms of what is stored – a “representation” - appears to be a description of an IC that can potentially be used by a computer to assist in programming or manufacturing the IC, such that claim 20 appears to be fundamentally directed to storing a circuit description on a non-transitory medium that may be used by a computer without any characterization of how the usage to program or manufacture is implemented. An apparatus claim must be distinguished from the prior art by its own structure, not by the manner in which it may be used. The manner in which claim 20 is characterized introduces the potential for f