DETAILED ACTION
Claims 1-20 are presented for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
The drawings received on 2 December 2022 are accepted.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
MPEP §2164.01(a) outlines the Wands factors to consider to determine undue experimentation:
(A) The breadth of the claims;
(B) The nature of the invention;
(C) The state of the prior art;
(D) The level of one of ordinary skill;
(E) The level of predictability in the art;
(F) The amount of direction provided by the inventor;
(G) The existence of working examples; and
(H) The quantity of experimentation needed to make or use the invention based on the content of the disclosure.
Citing In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988).
Here, the claim recitations “simulation state information,” as currently recited, is not enabled.
(A) The breadth of the claims
Claim 1 recites “simulation state information relating to … a central processing unit (CPU) design simulation.” The scope of CPU design simulation is extremely broad. The scope of “simulation state information” relating to said simulation is even broader. For example, CPC classification G06F30/30 and subgroups relating to “circuit design”, excluding G06F30/31 covers approximately 86,000 patent documents within the US. This covers logical design with functional simulation or model checking. This covers physical design and analog simulation at various levels of scale. There is simulation for particular design verification and other simulation for large-scale estimation of executing entire programs. The respective “information” used in each of these respective simulations is even broader than the vast categories and different types of simulation for circuit design involved. Accordingly, the claimed “simulation state information” is extremely broad.
Somehow, or in some manner, this simulation state information is used to generate memory access instructions of some sort for unknown purpose. The alleged results to be achieved from the simulation state information is essentially entirely absent. Because the purpose of this simulation state information is unknown, the result to be achieved by using the simulation state information does not narrow down the scope of what is encompassed by “simulation state information.”
Claims 5 and 11 recite substantially similar “simulation state information.”
(B) The nature of the invention
The nature of the invention deals generally with computer technology and is thus reasonably predictable.
(C) The state of the prior art & (D) The level of one of ordinary skill
MPEP §2164.05(a) states:
The state of the prior art is what one skilled in the art would have known, at the time the application was filed, about the subject matter to which the claimed invention pertains. The relative skill of those in the art refers to the skill of those in the art in relation to the subject matter to which the claimed invention pertains at the time the application was filed. See MPEP § 2164.05(b). See Pac. Biosciences of Cal., Inc. v. Oxford Nanopore Techs., Inc., 996 F.3d 1342, 1352, 2021 USPQ2d 519 (Fed. Cir. 2021).
Here, a person of ordinary skill in the art would be familiar with the existence of different types of circuit simulation at different levels, but would generally have expertise limited to some subsection thereof. There are no even experts who would be familiar with every type of circuit simulation or the scope of what information may be encompassed by the claimed “simulation state information”.
(E) The level of predictability in the art
Computer technology is generally considered one of the more predictable areas of technology.
(F) The amount of direction provided by the inventor
Figure 5 and Specification [0047] show “simulation state information (206)” may include “register state (412) and/or virtual memory state (414).”
It is unclear whether the register is a physical register performing the simulation or whether the register is a virtual register representative of a register of a simulated device. Similarly, it is unclear whether the virtual memory state is the virtual memory of the hardware executing the simulation or whether the virtual memory is of simulated virtual memory of the target device being simulated. Accordingly, it is unclear whether the “simulation state information” is state information of the environment in which the simulation is running, i.e. outside the simulation, or if the state information is information about the state within the simulation.
It is unclear how “register state” or “virtual memory state” are intended to be used for generating any particular memory access instruction.
Specification [0038] states “In some embodiments, the ISG 104 is an open FORCE-RISCV ISG.” However, any further documentation relating to FORCE-RISCV ISG has not be further described nor incorporated by reference.
(G) The existence of working examples
No working example has been provided.
(H) The quantity of experimentation needed to make or use the invention based on the content of the disclosure
The quantity of experimentation needed to make or use the invention is practically unlimited. There are almost no limits on the scope of what information might be relevant as input “simulation state information.” Furthermore, there is no indication what the result to be achieved by the generated memory access instructions is supposed to achieve as a desirable result. Accordingly, it is also unclear what the output is supposed to be. That is, given some set of information and a process which outputs memory access instructions of some type, it is unclear whether or not the particular output memory access instruction “cause a desired number of exceptions” or not. See Specification [0037] item 3.
Therefore, where both the putative inputs and outputs are essentially unknown, no amount of experimentation will be sufficient to make or use the invention. While there are some vast bounds which could be broadly placed over the scope of possible input information, there are no limits on the scope of output information other than some form of memory access instruction. Even considering, by brute force, all possible input information a person of ordinary skill in the art would not know if any particular result is sufficient to end further experimentation.
Dependent claims
None of dependent claims 2-4, 6-10, or 12-20 further define what is meant by “simulation state information." Accordingly, the dependent claims are rejected at least for depending from a rejected claim.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-6, 9-11, 13, 14, and 16-20
Claims 1, 4-6, 9-11, 13, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over US patent 7,395,196 B2 Emek [herein “Emek”] in view of Aharon, A., et al. “Verification of the IBM RISC System/6000 by a dynamic biased pseudo-random test program generator” IBM Sys. J., vol. 30, no. 4 (1991) [herein “Aharon”].
Claim 1 recites “1. A method for generating a memory access instruction by a network device.” Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Emek column 5 lines 4-15 disclose:
A "system" as used herein, is a set of components connected using some form of interconnect, which is capable of performing a set of transactions. Components may include processors and other processing elements, caches, various types of memories, bridges, interrupt controllers, DMA engines, etc. The interconnect between these components may comprise, for example, several buses and the bus-bridges connecting them. In many cases, a system contains multiple instances of a certain type of component: for example, a system with symmetric multiprocessing would contain several processors. Examples of transactions include memory mapped I/O (MMIO) and direct memory access (DMA).
The transactions accessing memory locations corresponds with generated memory access instructions. The interconnect of the system is a network. The processor(s) are network devices of the respective interconnect where they are connected.
Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Claim 1 further recites “the method comprising: obtaining constraints on a memory access instruction, the constraints comprising a target address range and a specification of valid address locations.” Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 1 further recites “obtaining simulation state information relating to a current state of a central processing unit (CPU) design simulation.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached is information relating to a current state of the design simulation.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use coverage testing into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 1 further recites “and generating the memory access instruction based on the target address range, the specification of valid address locations, and the simulation state information.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions. See further Emek column 6 lines 52-53.
Emek column 6 lines 65-66 disclose “choice from a set of available resources.” The available resources correspond to those satisfying respective constraints.
Claim 4 further recites “4. The method of claim 1, wherein the step of generating comprises: obtaining previous instruction information relating to a history of instructions previously simulated by the CPU design simulation; and generating the memory access instruction further based on the previous instruction information.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Emek column 6 lines 65-66 disclose “choice from a set of available resources.” The available resources correspond to those satisfying respective constraints.
Emek does not explicitly disclose history of previously simulated instructions; however, in analogous art of random test generation, Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached corresponds with information relating to a history of instructions previously simulated. Executing tests for coverage of blocks that were not reaches corresponds with generating respective memory access instructions based on previous instruction information.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use coverage testing into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 5 recites “5. A method for generating a memory access instruction by a network device.” Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Emek column 5 lines 4-15 disclose:
A "system" as used herein, is a set of components connected using some form of interconnect, which is capable of performing a set of transactions. Components may include processors and other processing elements, caches, various types of memories, bridges, interrupt controllers, DMA engines, etc. The interconnect between these components may comprise, for example, several buses and the bus-bridges connecting them. In many cases, a system contains multiple instances of a certain type of component: for example, a system with symmetric multiprocessing would contain several processors. Examples of transactions include memory mapped I/O (MMIO) and direct memory access (DMA).
The transactions accessing memory locations corresponds with generated memory access instructions. The interconnect of the system is a network. The processor(s) are network devices of the respective interconnect where they are connected.
Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Claim 5 further recites “the method comprising: obtaining constraints on a memory access instruction, the constraints comprising a target address range and a specification of valid address locations.” Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 5 further recites “obtaining simulation state information relating to a current state of a central processing unit (CPU) design simulation.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached is information relating to a current state of the design simulation.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use coverage testing into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 5 further recites “generating a plurality of possible target addresses based on the target address range, the specification of valid address locations, and the simulation state information; selecting one of the possible target addresses for the memory access instruction; and generating the memory access instruction based on the selected one of the possible target addresses.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Emek column 6 lines 65-66 disclose “choice from a set of available resources.” The available resources correspond to those satisfying respective constraints.
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 6 further recites “6. The method of claim 5 wherein the step of selecting includes randomly selecting the one of possible target address.” Emek column 5 lines 47-51 disclose “The verification system 10 enables the creation of tests that have various degrees of randomness. The ability of the verification system 10 to introduce random unspecified values is fundamental, since design flaws in practice are usually unpredictable.”
Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Emek column 6 lines 65-66 disclose “choice from a set of available resources. Emek column 7 lines 23-26 discloses “If a test case generator were to generate a transaction of type T, and the type T requires an instance of a resource A and an instance of a resource B, it would randomly choose a pair (a,b) from a Cartesian product.” Randomly choosing a selection for generating a transaction, i.e. of a processor accessing a certain memory location, corresponds to a random selecting of respective possible addresses.
Claim 9 further recites “9. The method of claim 5, further comprising, removing one or more possible target addresses from the plurality of possible target addresses based on a filter criterion prior to selecting one possible target address of the plurality of possible target addresses.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation Aharon page 532 left column sixth bullet item teaches “Protect the required areas of memory and certain registers from being used by the generated test.” Protecting areas of memory from use by the generated tests corresponds with removing possible target addresses before selecting possible target addresses. The areas of memory being required corresponds with a filter criterion.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 10 further recites “10. The method of claim 9, wherein the filter criterion is based on one of the simulation state information and previous instruction information relating to a history of instructions previously simulated by the CPU design simulation.” From the above list of alternatives the Examiner is selecting “simulation state information.”
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations. Memory addresses outside the allowed memory addresses are addresses which have been removed from possible target addresses. The initialization of registers is simulation state information.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 11 recites “11. A network device, comprising: a memory configured to store instructions; and a processor coupled to the memory and configured to execute the instructions stored in the memory.” Emek column 3 lines 47-51 disclose “The invention provides a computer software product, including a computer-readable medium in which computer program instructions are stored, which instructions, when read by a computer, cause the computer to perform a method of verifying a system design.” A computer includes processor and memory.
Claim 11 further recites “to cause the network device to: obtain constraints on a memory access instruction, the constraints comprising a target address range and a specification of valid address locations.” Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 11 further recites “obtain simulation state information relating to a current state of a central processing unit (CPU) design simulation.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached is information relating to a current state of the design simulation.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use coverage testing into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 11 further recites “and generate the memory access instruction based on the target address range, the specification of valid address locations, and the simulation state information.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Emek column 6 lines 65-66 disclose “choice from a set of available resources.” The available resources correspond to those satisfying respective constraints.
Claim 13 further recites “13. The network device of claim 11, wherein executing the instructions further causes the network device to: obtain previous instruction information relating to a history of instructions previously simulated by the CPU design simulation; and generate the memory access instruction further based on the previous instruction information.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions.
Emek column 6 lines 65-66 disclose “choice from a set of available resources.” The available resources correspond to those satisfying respective constraints.
Emek does not explicitly disclose history of previously simulated instructions; however, in analogous art of random test generation, Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached corresponds with information relating to a history of instructions previously simulated. Executing tests for coverage of blocks that were not reaches corresponds with generating respective memory access instructions based on previous instruction information.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use coverage testing into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 14 further recites “14. The network device of claim 11, wherein executing the instructions further causes the network device to: generate a plurality of possible target addresses.” Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations. Plural allowed memory addresses is a plurality of possible target addresses.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 14 further recites “and randomly select one of the possible target addresses for the memory access instruction.” Emek column 5 lines 47-51 disclose “The verification system 10 enables the creation of tests that have various degrees of randomness. The ability of the verification system 10 to introduce random unspecified values is fundamental, since design flaws in practice are usually unpredictable.”
Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Emek column 6 lines 65-66 disclose “choice from a set of available resources. Emek column 7 lines 23-26 discloses “If a test case generator were to generate a transaction of type T, and the type T requires an instance of a resource A and an instance of a resource B, it would randomly choose a pair (a,b) from a Cartesian product.” Randomly choosing a selection for generating a transaction, i.e. of a processor accessing a certain memory location, corresponds to a random selecting of respective possible addresses.
Claim 16 further recites “16. The network device of claim 14, wherein executing the instructions further causes the network device to: remove one or more possible target addresses from the plurality of possible target addresses.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation Aharon page 532 left column sixth bullet item teaches “Protect the required areas of memory and certain registers from being used by the generated test.” Protecting areas of memory from use by the generated tests corresponds with removing possible target addresses before selecting possible target addresses. The areas of memory being required corresponds with a filter criterion.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 16 further recites “based on a filter criterion prior to randomly selecting one possible target address of the plurality of possible target addresses.” Emek column 5 lines 47-51 disclose “The verification system 10 enables the creation of tests that have various degrees of randomness. The ability of the verification system 10 to introduce random unspecified values is fundamental, since design flaws in practice are usually unpredictable.”
Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Emek column 6 lines 65-66 disclose “choice from a set of available resources. Emek column 7 lines 23-26 discloses “If a test case generator were to generate a transaction of type T, and the type T requires an instance of a resource A and an instance of a resource B, it would randomly choose a pair (a,b) from a Cartesian product.” Randomly choosing a selection for generating a transaction, i.e. of a processor accessing a certain memory location, corresponds to a random selecting of respective possible addresses.
Claim 17 further recites “17. The network device of claim 16, wherein executing the instructions further causes the network device to: obtain previous instruction information relating to a history of instructions previously simulated by the CPU design simulation, wherein the filter criterion is based on the previous instruction information.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 533 left column second paragraph “Coverage evaluation helps to detect and remove ‘holes’ in the biasing. The final set of strategies ensures that there is a generation process with a reasonable probability of covering every architectural feature and every design block.”
Aharon page 535 right column third paragraph teaches:
One of the simplest coverage techniques is ensuring that each line of the code has been executed at least once. A special function analyzes the character representation of an APL function and splits each labeled line into two lines. The first one contains the label and an assignment statement that sets the corresponding bit in a trace vector associated with this function. …. A bucket of test programs is then executed (using the Run mode) on the "trace-modified" RTPG. Zero values in the trace vector indicate blocks that were not reached.
The trace vector indicating which blocks were not reached is previous instruction information.
Aharon page 535 last paragraph to page 536 first line disclose “The information from the previous step (line coverage) is used to select only those test programs that pass through the skipped line.” Using coverage information to select only those test programs which pass through a skipped line corresponds with a filter criteria based on previous instruction information.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 18 further recites “18. The network device of claim 16, wherein the filter criterion is based on the simulation state information.” Emek does not explicitly disclose a target address range and a specification of valid address locations; however, in analogous art of random test generation, Aharon page 529 left column first paragraph teaches “The generated test programs are relatively simple, and again, must obey many restrictions.” The restrictions which must be obeyed correspond to one or more constraints.
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations. Memory addresses outside the allowed memory addresses are addresses which have been removed from possible target addresses. The initialization of registers is simulation state information.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek and Aharon. One having ordinary skill in the art would have found motivation to use restrictions on memory addresses into the system of test case generation for functional verification for the advantageous purpose of “to automatically produce a vast number of test programs for the comprehensive verification of the design.” See Aharon page 527 last line to page 528 line 2.
Claim 19 further recites “19. The network device of claim 11, wherein the instructions comprise an instruction stream generator.” The claim language “instruction stream generator” is interpreted in light of Specification paragraph 36.
Emek abstract discloses “Generation of test cases for functional verification of a complex system-under-test is achieved by the use of a probability matrix.” Generating test cases for functional verification corresponds with being an instruction stream generator.
Claim 20 further recites “20. The network device of claim 11, wherein executing the instructions further causes the network device to: send to the CPU design simulation, an executable test case including the memory access instruction.” Emek column 6 lines 6-7 disclose “The test cases 30 are executed by an execution engine 12 on an implementation of the system under test.”
Emek column 6 lines 52-53 disclose “Transaction examples are a processor accessing a certain memory location.” Accessing a memory location corresponds with memory access instructions.
Dependent Claims 2, 3, 7, and 12
Claims 2, 3, 7, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Emek and Arahon as applied to claims 1, 5, and 11 above, and further in view of US patent 6,353,829 B1 Koblenz, et al. [herein “Koblenz”].
Claim 2 further recites “2. The method of claim 1, wherein the step of generating comprises: storing a value in a previously unused memory location of the CPU design simulation.” Emek column 6 line 59 disclose “executing a store or a load assembly instruction.”
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
But neither Emek nor Aharon explicitly disclose storing in previously unused memory; however, in analogous art of computer memory operation, Koblenz column 5 lines 23-33 teach:
Conventional computer systems provide memory allocation techniques that allow programs to allocate and de-allocate (i.e., free) memory dynamically. To allocate a block of memory, a program invokes a memory allocation routine (e.g., "malloc") passing the size of the requested block of memory. The memory allocation routine locates a free block of memory, which is usually stored in a "heap," marks the block as being allocated, and returns to the program a pointer to the allocated block of memory. The program can then use the pointer to store data in the block of memory.
Locating free blocks of memory is selecting memory from a previously unused memory location.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Koblenz. One having ordinary skill in the art would have found motivation to use conventional memory allocation into the system of test case generation for functional verification because tracking free memory in a heap for allocation/free routines is art recognized method suitable for the purpose of memory allocation. See Koblenz column 5 lines 23-37.
Claim 2 further recites “and generating the memory access instruction further based on an address of the previously unused memory location.” Koblenz column 5 lines 23-33 teach “returns to the program a pointer to the allocated block of memory. The program can then use the pointer to store data in the block of memory.” Returning a pointer to the block of memory is generating memory access according to the address of the particular unused and now allocated memory location. A pointer includes an address.
Claim 3 further recites “3. The method of claim 2, wherein the step of storing is performed according to information stored in an executable test case.” Emek column 6 lines 6-7 disclose “The test cases 30 are executed by an execution engine 12 on an implementation of the system under test.”
Claim 7 further recites “7. The method of claim 5 wherein the step of selecting includes selecting a previously unused memory location of the CPU design simulation.” Emek column 6 line 59 disclose “executing a store or a load assembly instruction.”
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
But neither Emek nor Aharon explicitly disclose storing in previously unused memory; however, in analogous art of computer memory operation, Koblenz column 5 lines 23-33 teach:
Conventional computer systems provide memory allocation techniques that allow programs to allocate and de-allocate (i.e., free) memory dynamically. To allocate a block of memory, a program invokes a memory allocation routine (e.g., "malloc") passing the size of the requested block of memory. The memory allocation routine locates a free block of memory, which is usually stored in a "heap," marks the block as being allocated, and returns to the program a pointer to the allocated block of memory. The program can then use the pointer to store data in the block of memory.
Locating free blocks of memory is selecting memory from a previously unused memory location.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Koblenz. One having ordinary skill in the art would have found motivation to use conventional memory allocation into the system of test case generation for functional verification because tracking free memory in a heap for allocation/free routines is art recognized method suitable for the purpose of memory allocation. See Koblenz column 5 lines 23-37.
Claim 12 further recites “12. The network device of claim 11, wherein executing the instructions further causes the network device to: store a value in a previously unused memory location of the CPU design simulation.” Emek column 6 line 59 disclose “executing a store or a load assembly instruction.”
Aharon page 529 left column first bullet item teaches “initialization of base registers to get the allowed memory addresses.” The allowed memory addresses are a specification of valid address locations.
But neither Emek nor Aharon explicitly disclose storing in previously unused memory; however, in analogous art of computer memory operation, Koblenz column 5 lines 23-33 teach:
Conventional computer systems provide memory allocation techniques that allow programs to allocate and de-allocate (i.e., free) memory dynamically. To allocate a block of memory, a program invokes a memory allocation routine (e.g., "malloc") passing the size of the requested block of memory. The memory allocation routine locates a free block of memory, which is usually stored in a "heap," marks the block as being allocated, and returns to the program a pointer to the allocated block of memory. The program can then use the pointer to store data in the block of memory.
Locating free blocks of memory is selecting memory from a previously unused memory location.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Koblenz. One having ordinary skill in the art would have found motivation to use conventional memory allocation into the system of test case generation for functional verification because tracking free memory in a heap for allocation/free routines is art recognized method suitable for the purpose of memory allocation. See Koblenz column 5 lines 23-37.
Claim 12 further recites “and generate the memory access instruction further based on an address of the previously unused memory location.” Koblenz column 5 lines 23-33 teach “returns to the program a pointer to the allocated block of memory. The program can then use the pointer to store data in the block of memory.” Returning a pointer to the block of memory is generating memory access according to the address of the particular unused and now allocated memory location. A pointer includes an address.
Dependent Claims 8 and 15
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Emek and Arahon as applied to claims 5 and 11 above, and further in view of US patent 6,006,028 Aharon, et al. [herein “Patent ‘028”].
Claim 8 further recites “8. The method of claim 5, wherein the step of generating the plurality of possible target addresses comprises: determining an instruction addressing mode of the memory access instruction.” Emek and Aharon does not explicitly disclose an addressing mode; however, in analogous art of test program generators, Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent ‘028 column 10 line 36 teaches “A 'format' is a finite set of field names.” Patent ‘028 column 12 line 23 provides an example “Format: AW-OPCODE W1, D2, B2.” The format and/or opcode correspond with an addressing model of the instruction.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Patent ‘028. One having ordinary skill in the art would have found motivation to use CISC instruction sets into the system of test case generation for functional verification for the advantageous purpose of “developing generators for non-traditional processors such as graphic engines and I/O controllers.” See Patent ‘028 column 4 lines 39-40.
Claim 8 further recites “determining whether the instruction addressing mode permits combinations of fixed-value operands; determining whether the instruction addressing mode permits combinations of flexible-value operands.” The claim language “fixed-value operands” and “flexible-value operands” are interpreted in light of Specification paragraphs 44-45.
Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent '028 column 10 lines 25-40 teach:
A data-type describes such a set of data strings by their length, either fixed or variable under limits, and structure.
….
Definition: A 'sub-operand' over a format F is a triplet holding a length expression over F , an address expression over F and a data expression.
An 'operand' over format Fis a finite set of sub-operands over F. A semantic procedure is a procedure which manipulates the architecture resources and represents the operation performed by the instruction. An 'instruction tree' is a triplet holding a format F, a semantic procedure, and a finite set of operands over F.
Sub-operands plural is a combination of operands. Fixed length data string data types are fixed value. Variable length data string data types are flexible value.
Claim 8 further recites “and for each combination of permitted fixed-value operands and/or flexible-value operands, combining the specification of valid address locations, the target address range, and the combination of permitted fixed-value operands and/or flexible-value operands to generate one possible target address of the plurality of possible target addresses.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions. See further Emek column 6 lines 52-53. Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek and Aharon does not explicitly disclose an addressing mode; however, in analogous art of test program generators, Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent ‘028 column 10 lines 56-57 teach “The semantic domain of address expressions consists of addresses as defined above.” The addresses are address locations. Thus, the instruction format outlined here for CISC is a combination of address location along with the range and operands.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Patent ‘028. One having ordinary skill in the art would have found motivation to use CISC instruction sets into the system of test case generation for functional verification for the advantageous purpose of “developing generators for non-traditional processors such as graphic engines and I/O controllers.” See Patent ‘028 column 4 lines 39-40.
Claim 15 further recites “15. The network device of claim 14, wherein executing the instructions further causes the network device to: determine an instruction addressing mode of the memory access instruction.” Emek and Aharon does not explicitly disclose an addressing mode; however, in analogous art of test program generators, Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent ‘028 column 10 line 36 teaches “A 'format' is a finite set of field names.” Patent ‘028 column 12 line 23 provides an example “Format: AW-OPCODE W1, D2, B2.” The format and/or opcode correspond with an addressing model of the instruction.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Patent ‘028. One having ordinary skill in the art would have found motivation to use CISC instruction sets into the system of test case generation for functional verification for the advantageous purpose of “developing generators for non-traditional processors such as graphic engines and I/O controllers.” See Patent ‘028 column 4 lines 39-40.
Claim 15 further recites “determine whether the instruction addressing mode permits combinations of fixed-value operands; determine whether the instruction addressing mode permits combinations of flexible-value operands.” The claim language “fixed-value operands” and “flexible-value operands” are interpreted in light of Specification paragraphs 44-45.
Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent '028 column 10 lines 25-40 teach:
A data-type describes such a set of data strings by their length, either fixed or variable under limits, and structure.
….
Definition: A 'sub-operand' over a format F is a triplet holding a length expression over F , an address expression over F and a data expression.
An 'operand' over format Fis a finite set of sub-operands over F. A semantic procedure is a procedure which manipulates the architecture resources and represents the operation performed by the instruction. An 'instruction tree' is a triplet holding a format F, a semantic procedure, and a finite set of operands over F.
Sub-operands plural is a combination of operands. Fixed length data string data types are fixed value. Variable length data string data types are flexible value.
Claim 15 further recites “and for each combination of permitted fixed-value operands and/or flexible-value operands, combine the specification of valid address locations, the target address range, and the combination of permitted fixed-value operands and/or flexible-value operands to generate one possible target address of the plurality of possible target addresses.” Emek column 6 lines 3-6 disclose “The test generator engine 22 may also receive some generic knowledge of the system specification, and can exploit this knowledge to generate sequences of transactions to form the test cases 30.” Generating sequences of transactions corresponds with generating the memory access instructions. See further Emek column 6 lines 52-53. Emek column 6 lines 65-66 disclose “choice from a set of available resources.”
Emek and Aharon does not explicitly disclose an addressing mode; however, in analogous art of test program generators, Patent '028 column 10 lines 22-23 teach “automatic test generation of Complex Instructions Sets Computers (CISC).”
Patent ‘028 column 10 lines 56-57 teach “The semantic domain of address expressions consists of addresses as defined above.” The addresses are address locations. Thus, the instruction format outlined here for CISC is a combination of address location along with the range and operands.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Emek, Aharon, and Patent ‘028. One having ordinary skill in the art would have found motivation to use CISC instruction sets into the system of test case generation for functional verification for the advantageous purpose of “developing generators for non-traditional processors such as graphic engines and I/O controllers.” See Patent ‘028 column 4 lines 39-40.
Conclusion
Prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 5845064 A Huggins; James D.
teaches
Testing and verification of a CPU using a reference model
US 6076158 A Sites; Richard Lee et al.
Branch prediction in high-performance processor
US 5918035 A Van Praet; Johan Roland et al.
Processor modeling in code generation and instruction set simulation
US 6081864 A Lowe; Mike et al.
Dynamic configuration of a device under test
Emek, R., et al. “X-GEN: A Random Testcase Generator for Systems and SOCs” 7th IEEE Int’l High-Level Design Validation & Test Workshop (2002)
X-Gen, a model-based random test-case generator
Adir, A., et al. “Genesys-Pro: Innovations in Test Program Generation for Functional Processor Verification” IEEE Design & Test of Computers, pp. 84-93 (2004)
Genesys-Pro: random test-program generation (RTPG).
Page 89 right column teaches stream generation.
Li, T., et al. “MA2TG: A Functional Test Program Generator for Microprocessor Verification” IEEE Proceedings of 2005 8th Euromicro Conf. on Digital Sys. Design (2005)
microprocessor architectural automatic test program generator.
Constraint and coverage verification.
Kitchen, N. & Kuehlmann, A. “Stimulus Generation for Constrained Random Simulation” IEEE 2007 Int’l Conf. on Computer-Aided Design, pp. 258-265 (2007)
Constrained random simulation.
Jeong, S., et al. “Random Test Program Generation for Reconfigurable Architectures” 13th Int’l Workshop on Microprocessor Test & Verification (2012)
RTPG for reconfigurable processors including custom ISA extension.
Chupilko, M., et al. “Test Program Generator MicroTESK for RISC-V” IEEE 19th Int’l Workshop on Microprocessor & SOC Test Security & Verification, pp. 6-11 (2018)
RISC-V Instruction set specification.
Test program generator
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jay B Hann whose telephone number is (571)272-3330. The examiner can normally be reached M-F 10am-7pm EDT.
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, Renee Chavez can be reached at (571) 270-1104. 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.
/Jay Hann/Primary Examiner, Art Unit 2186 15 April 2026
Prosecution Insights