DETAILED ACTION
This action is in response to the amendments filed on Apr. 20th, 2023 A summary of this action:
Claims 1-20 have been presented for examination.
Claims 2-5, 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite
Claims 1-18, 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more.
Claim(s) 1, 7-8, 10, 12-13 is/are rejected under 35 U.S.C. 102(a)(1)as being anticipated by by Van Praet et al., US 5,854,929.
Claim(s) 2-6, 8, 11, 13, 15-17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Van Praet et al., US 5,854,929 in view of Khairy, Mahmoud, et al. "Accel-sim: An extensible simulation framework for validated gpu modeling." 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020.
Claim(s) 9 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Van Praet et al., US 5,854,929 in view of Alves, Marco Antonio Zanata, et al. "Sinuca: A validated micro-architecture simulator." 2015 IEEE 17th International Conference on High Performance Computing and Communications, 2015 IEEE 7th International Symposium on Cyberspace Safety and Security, and 2015 IEEE 12th International Conference on Embedded Software and Systems. IEEE, 2015.
Claim 18 is not rejected under § 102/103. The closest prior art is the below relied upon combination of Van Praet et al., US 5,854,929 in view of Khairy, Mahmoud, et al. "Accel-sim: An extensible simulation framework for validated gpu modeling." 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020, taken in further view of one of the following references, but this does not fairly teach the particular ordered combination presently claimed.
Kohno et al., US 2001/0007970 ¶¶ 65-77
Duesterwald, US 2003/0110478, ¶¶ 18, 20, 28-32, 34
Cifuentes, Cristina, et al. "Experience in the design, implementation and use of a retargetable static binary translation framework." (2002). §§ 2.1.2-2.1.3
Souza, Maxwell, Daniel Nicácio, and Guido Araújo. "ISAMAP: Instruction mapping driven by dynamic binary translation." International Symposium on Computer Architecture. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010. § III, in particular see figuresd 3- 7 and accompanying description in § III.A, and see § III.D.
Claim 20 is not rejected under § 102/103 – the closest prior art is the cited portions of Van Praet, in view of both Khairy and Alves below, but this does not fairly teach the instances of the model object including “an instance of a completion model object configured to indicate when simulation of execution of respective pseudo-instructions is complete, the instance of the dispatch model object further being configured to retire pseudo-instructions based on an indication of completion received from the instance of the completion model object” as expressly recited
This action is non-final
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-5, 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The dependent claims inherit the deficiencies of the claims they depend upon.
MPEP § 2173.05(b)(IV): “A claim term that requires the exercise of subjective judgment without restriction may render the claim indefinite. In re Musgrave, 431 F.2d 882, 893, 167 USPQ 280, 289 (CCPA 1970). Claim scope cannot depend solely on the unrestrained, subjective opinion of a particular individual purported to be practicing the invention. Datamize LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1350, 75 USPQ2d 1801, 1807 (Fed. Cir. 2005));”
The claims phrase “pseudo-instructions”, wherein the term “pseudo” is a subjective term that renders the claim indefinite because there is no standard provided in the instant disclosure for POSITA to ascertain the scope of the present claims without relying on their own unrestrained, subjective opinion when practicing the invention.
To clarify, at issue is that there is no singular objective standard (e.g. ¶¶ 64 and 66) for what makes an instruction a “pseudo-instruction”.
Examiner interprets it, for purposes of Examination, as one that is “agnostic with respect to an instruction set architecture (ISA) of the first processor architecture design”/”instruction set architecture (ISA) agnostic;” (claims 6 and 15), and suggests amending to expressly recite this in all of the claims
To clarify, note claim 6 must further limit claim 2, i.e. claim 2 is expressly not limited to what is recited in claim 6, as claim 6 must further limit the claim it depends upon by § 112(d) – wherein claim 6 is not rejected under § 112(b) because the recitation in claim 6 renders it definite by limiting what is a pseudo-instruction to have a definite scope.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18, 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more.
Examiner suggests expressly incorporating the subject matter of ¶ 59 to integrate a practical application.
Claim 19 is not rejected under § 101 in view of ¶ 59.
Step 1
Claim 1 and 15 are directed towards the statutory category of a process.
Claim 10 is directed towards the statutory category of an article of manufacture.
Claims 10, and the dependents thereof, are rejected under a similar rationale as representative claim 1, and the dependents thereof.
Step 2A – Prong 1
The claims recite an abstract idea of a mental process. See MPEP § 2106.04(a)(2).
The mental process recited in claim 1 is:
populating a control flow graph with instances of model objects, each instance of the instances of the model objects representing a respective stage of a first processor architecture design;
interconnecting the instances of the model objects in the control flow graph, the interconnected instances of the model objects being an architecture model representing the first processor architecture design;
See figures 5-6, which “are architecture models” (¶ 11). As are fig. 1-2 (¶¶ 7-8, 49).
To generate such a generate such a model is readily a mental process, e.g. a person, such as a IC design engineer, is readily able to mentally create (e.g. by mental evaluation), and/or observe, a graph depicting the high-level architecture of a processor, and readily able to determine what components go into that graph, and readily able to also interconnect them, e.g. by drawing a block diagram such as in fig. 1-2 and 5-6 on pen and paper by mental processes.
Claim 15 recites a similar abstract idea in its generating limitation, and adds another abstract idea of:
converting the instructions to pseudo-instructions that are instruction set architecture (ISA) agnostic; - akin to MPEP 2106.04(a)(2)(II): “Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) (holding that claims to a mental process of "translating a functional description of a logic circuit into a hardware component description of the logic circuit" are directed to an abstract idea, because the claims "read on an individual performing the claimed steps mentally or with pencil and paper")” – to clarify, this limitation is merely converting a few lines of code to a few lines of code in a different language, akin to translating a few sentences from one language to another. E.g. see ¶¶ 42 and 54, e.g. fig. 3, wherein a person is readily able to observe a few lines of code, mentally observe the “MRS” mnemonic/operand (also see ¶ 57), remove it, and provide a translation (¶ 56:In the illustrated example, the MRS, MOV, UBFX, and CMP instruction types in FIG. 3 were converted to ALU pseudo-instructions in FIG. 4 based on the control logic, timing, and memory access of the respective execute stages of the processor architecture being modeled”)
Under the broadest reasonable interpretation, these limitations are process steps that cover mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of pencil and paper but for the recitation of a generic computer component. If a claim, under its broadest reasonable interpretation, covers a mental process but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. A person would readily be able to perform this process either mentally or with the assistance of pen and paper. See MPEP § 2106.04(a)(2).
To clarify, see the USPTO 101 training examples, available at https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility. In particular, with respect to the physical aids, see example # 45, analysis of claim 1 under step 2A prong 1, including: “Note that even if most humans would use a physical aid (e.g., pen and paper, a slide rule, or a calculator) to help them complete the recited calculation, the use of such physical aid does not negate the mental nature of this limitation.”; also see example # 49, analysis of claim 1, under step 2A prong 1: “Moreover, the recited mathematical calculation is simple enough that it can be practically performed in the human mind. Even if most humans would use a physical aid, like a pen and paper or a calculator, to make such calculations, the use of a physical aid would not negate the mental nature of this limitation.”.
As such, the claims recite a mental process.
Step 2A, prong 2
The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d).
The following limitations are merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”:
Preamble of claim 10, the processors of claim 15
Claim 1 does not recite the use of the computer expressly. See MPEP § 2111 for In Re Prater, and see the distinction with claim 15 for its express recite of the use of a processor for the generating step (Examiner further noting that the later steps of claim 15 do not expressly require the processor to be used)
Claim 15 - simulating execution of the pseudo-instructions by the architecture model - mere instructions to “apply it”, specifically “apply” the abstract idea of the translated code (the pseudo-instructions) by executing them in a generic computer environment.
The following limitations are adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g):
Claims 1 and 10 and outputting, by one or more processors, the architecture model including the interconnected instances of the model objects. – mere data outputting
Claim 15 - receiving a software trace including instructions; - mere data gathering
Claim 15 - simulating execution of the pseudo-instructions by the architecture model; – an insignificant computer implementation, as well as mere data gathering for later data outputting in token post-solution steps
Claim 15 - …and generating performance information of the first processor architecture based on the simulation., as well as mere data outputting and activities involved in the outputting.
A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. See MPEP § 2106.04(d).
MPEP 2106.04(II)(A)(2) “…Instead, under Prong Two, a claim that recites a judicial exception is not directed to that judicial exception, if the claim as a whole integrates the recited judicial exception into a practical application of that exception. Prong Two thus distinguishes claims that are "directed to" the recited judicial exception from claims that are not "directed to" the recited judicial exception…Because a judicial exception is not eligible subject matter, Bilski, 561 U.S. at 601, 95 USPQ2d at 1005-06 (quoting Chakrabarty, 447 U.S. at 309, 206 USPQ at 197 (1980)), if there are no additional claim elements besides the judicial exception, or if the additional claim elements merely recite another judicial exception, that is insufficient to integrate the judicial exception into a practical application. See, e.g., RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) ("Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract"); Genetic Techs. Ltd. v. Merial LLC, 818 F.3d 1369, 1376, 118 USPQ2d 1541, 1546 (Fed. Cir. 2016) (eligibility "cannot be furnished by the unpatentable law of nature (or natural phenomenon or abstract idea) itself."). For a claim reciting a judicial exception to be eligible, the additional elements (if any) in the claim must "transform the nature of the claim" into a patent-eligible application of the judicial exception, Alice Corp., 573 U.S. at 217, 110 USPQ2d at 1981, either at Prong Two or in Step 2B” and MPEP § 2106(I): “Mayo, 566 U.S. at 80, 84, 101 USPQ2dat 1969, 1971 (noting that the Court in Diamond v. Diehr found “the overall process patent eligible because of the way the additional steps of the process integrated the equation into the process as a whole,”” – and see MPEP § 2106.05(e).
To further clarify, MPEP § 2106.04(II)(A)(1): “Alice Corp., 573 U.S. at 216, 110 USPQ2d at 1980 (citing Mayo, 566 US at 71, 101 USPQ2d at 1965). Yet, the Court has explained that ‘‘[a]t some level, all inventions embody, use, reflect, rest upon, or apply laws of nature, natural phenomena, or abstract ideas,’’ and has cautioned ‘‘to tread carefully in construing this exclusionary principle lest it swallow all of patent law” See also Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335, 118 USPQ2d 1684, 1688 (Fed. Cir. 2016) ("The ‘directed to’ inquiry, therefore, cannot simply ask whether the claims involve a patent-ineligible concept, because essentially every routinely patent-eligible claim involving physical products and actions involves a law of nature and/or natural phenomenon").”
As a point of clarity, RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) ("Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract"); Genetic Techs. Ltd. v. Merial LLC, 818 F.3d 1369, 1376, 118 USPQ2d 1541, 1546 (Fed. Cir. 2016) (eligibility "cannot be furnished by the unpatentable law of nature (or natural phenomenon or abstract idea) itself." discussed in MPEP § 2106.04(II)(A)(2) as well as MPEP § 2106.04(I): “Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a new abstract idea is still an abstract idea") (emphasis in original).
The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d).
Step 2B
The claimed invention does not recite any additional elements/limitations that amount to significantly more.
The following limitations are merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”:
Preamble of claim 10, the processors of claim 15
Claim 1 does not recite the use of the computer expressly. See MPEP § 2111 for In Re Prater, and see the distinction with claim 15 for its express recite of the use of a processor for the generating step (Examiner further noting that the later steps of claim 15 do not expressly require the processor to be used)
Claim 15 - simulating execution of the pseudo-instructions by the architecture model - mere instructions to “apply it”, specifically “apply” the abstract idea of the translated code (the pseudo-instructions) by executing them in a generic computer environment.
The following limitations are adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g):
Claims 1 and 10 and outputting, by one or more processors, the architecture model including the interconnected instances of the model objects. – mere data outputting
Claim 15 - receiving a software trace including instructions; - mere data gathering
Claim 15 - simulating execution of the pseudo-instructions by the architecture model; – an insignificant computer implementation, as well as mere data gathering for later data outputting in token post-solution steps
Claim 15 - …and generating performance information of the first processor architecture based on the simulation., as well as mere data outputting and activities involved in the outputting.
In addition, the above insignificant extra-solution activities are also considered as well-understood, routine, and conventional activities, as discussed in MPEP § 2106.05(d):
The data receiving and data outputting steps are considered WURC in view of MPEP § 2106.05(d)(II)
The simulating step is considered WURC in view of
Binkert, Nathan, et al. "The gem5 simulator." ACM SIGARCH computer architecture news 39.2 (2011): 1-7. See Abstract, then see § 3.3, in particular the section on the “ISA DSL”. Also see § 4. To clarify, the gem5 simulation was WURC by the time of the effective filing date of the instant application, see:
Nocua, Alejandro, et al. "A gem5 trace-driven simulator for fast architecture exploration of OpenMP workloads." Microprocessors and Microsystems 67 (2019): 42-55. § 2.1, starting at page 43, col. 2, ¶ 4
Jagtap, Radhika, et al. "Exploring system performance using elastic traces: Fast, accurate and portable." 2016 International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation (SAMOS). IEEE, 2016. § 1 ¶ 1: “Computer architects rely heavily on simulation tools to investigate performance bottlenecks and evaluate new ideas. Contemporary simulators like gem5 [1], Simics [2], MARSSx86 [3] and PTLsim [4] cover a large space in terms of level of detail in modelling system components, speed, and flexibility.
Lowe-Power, Jason, et al. "The gem5 simulator: Version 20.0+." arXiv preprint arXiv:2007.03152 (2020). Abstract: “The open-source and community-supported gem5 simulator is one of the most popular tools for computer architecture research” and § 1.1 including: “Since its initial release nine years ago the gem5 simulator has been wildly successful. In this time, the use of gem5 has exploded. Although not a perfect metric, as shown in Figure 1a the gem5 paper has received over 3600 citations according to Google Scholar”
Arafa, Yehia, et al. "Hybrid, scalable, trace-driven performance modeling of GPGPUs." Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. 2021. Abstract, figure 1, § 2.2, § 3.3
Khairy, Mahmoud, et al. "Accel-sim: An extensible simulation framework for validated gpu modeling." 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020. §§ II.A-II.B including table II
Cordeiro, Aline Santana, et al. "Intrinsics-hmc: An automatic trace generator for simulations of processing-in-memory instructions." Simpósio em Sistemas Computacionais de Alto Desempenho (SSCAD). SBC, 2017. Abstract, §§ 2.2-3.3
Lockhart, Derek, Berkin Ilbeyi, and Christopher Batten. "Pydgin: generating fast instruction set simulators from simple architecture descriptions with meta-tracing JIT compilers." 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, 2015. Abstract, § I last two paragraphs, § II-III.C
As such, the claims are directed towards a mental process without significantly more.
Regarding the dependent claims
Claims 2-3 recites similar limitations as claim 15 above, which are rejected under similar rationales
Claim 4 is further limiting the mental process of the translating/converting
Claim 5 is further limiting the content of the information gathered, i.e. its part of the mere data gathering
Claim 6 – this is merely describing a desired result of the converting/translating
Claim 7 – further limiting the mental process discussed above
Claim 8 – this is further limiting the mental process of discussed above by merely excluding some parts of the architecture model
Examiner notes that ¶ 59 is directed to “stripping non-memory access operation and functionality from the instructions when translating to pseudo-instructions,”, rather than excluding non-memory function behavior of the respective stage as claimed, and ¶ 59 then states that this feature of ¶ 59 provides: “simulation of execution of the pseudo-instructions may be faster. Simulation of execution of the non-memory access function may be avoided, while maintaining proper control logic, timing, and memory access for performance analysis.” – thus, Examiner suggests amending to more expressly include the exact subject matter of ¶ 59 - i.e. its further limiting how the additional element of the simulating is to be performed, thus providing the improvement to technology in ¶ 59 at prong 2 – thus, Examiner suggests amending to including this feature expressly in the claims to address the rejection
Rather, see ¶ 46: “The non-memory access functional behavior of the units may not be modeled. For example, for an ALU or MUL, the actual computation of operands and calculation of a result is not modeled. Rather, the latency of the ALU or MUL is modeled. The latency for any unit may be fixed or variable…” – i.e. the model simply represents a “fixed” “latency”, e.g. 1 millisecond for the ALU, further clarifying the mental nature (i.e. it’s a block diagram, with fixed latencies attached to the various blocks for a simple timing analysis where a person may readily just add up the latencies using simple math and pen/paper).
Claim 9 – this is merely further limiting the mental process – see figures 1-2 and 5-6 as discussed above, i.e. its just adding more blocks to the block diagram of the architecture model, wherein the generating of the transactions for memory access is considered, for when this step is performed, as mere data gathering/data storage, and WURC in view of MPEP § 2106.05(d)(II)
Claims 11-14 are rejected under a similar rationale as representative claims above
Claim 16 rejected under a similar rationale as claim 8 above
Claim 17 is further limiting the content of the information gathered, i.e. its part of the mere data gathering
Claim 18 is further limiting the abstract idea of the converting – see ¶¶ 54-55 to clarify, as person is readily able to convert/translate a few lines of code
Claim 20 is merely further limiting what is in the architecture model/block diagram (cf. 1-2, 5-6), wherein the acts (when these are to be later be performed) of fetching is mere data gathering WURC in view of MPEP § 2106.05(d)(II); the act of the conversion is the abstract idea discussed above; the act of the routine is considered mere data transmission WURC in view of MPEP § 2106.05(d)(II); the of the simulation is rejected under a similar rationale as the simulating above, the act of the indicating is mere data outputting WURC in view of MPEP § 2106.05(d)(II); and the act of the retiring is considered as a mental act (mental observation of collected data, followed by a mental judgement, akin to the marking of data items for deletion in PersonalWeb in the July 2024 Fed. Register Notice).
As such, the claims are directed towards a mental process without significantly more.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 7-8, 10, 12-13 is/are rejected under 35 U.S.C. 102(a)(1)as being anticipated by by Van Praet et al., US 5,854,929.
Regarding Claim 1
Van Praet teaches:
A method comprising: (Van Praet, abstract)
populating a control flow graph with instances of model objects, each instance of the instances of the model objects representing a respective stage of a first processor architecture design; interconnecting the instances of the model objects in the control flow graph, the interconnected instances of the model objects being an architecture model representing the first processor architecture design; and outputting, by one or more processors, the architecture model including the interconnected instances of the model objects.
See Van Praet, abstract, then see col. 6, ln. 35-55, then see col. 7-8 paragraph split between the columns, followed by description of fig. 1 in col. 8, followed by subsection “A BiPartite Graph As A Processor Model” including: “he instruction set graph (ISG) for the present invention is designed in accordance with the above requirements. It is a directed bipartite graph GisG (VIsG,EisG) with VIsG= V suVI, where Vs contains vertices representing storage elements in the processor and VI contains vertices repress senting its operations. The edges in VIsGC(V5 xVJU(VIx V 5 ) represent the connectivity of the processor and model data flow from storage, through ISG operations, to storage. FIG. 3 contains a part of the ISG for the example processor” – see fig. 3 to further clarify, and see remaining parts of this Bipartite graph as a processor model subsection for details, incl.: “…ISG operations are primitive processor activities transforming values in storage elements into other values in other storage elements… In the ISG, a distinction is made between two kinds of storage elements…Static Storage consists of memory and controllable registers…Transitory storage passes a value from input to output with a certain delay…Examples [of a transitory] are buses and wires…and pipeline registers… Together, the storage elements define a structural skeleton of the target machine… Read/write ports of static storage are also modelled as transitories in order to make the code generator check for port conflicts… In summary, memory and register nodes are included in the ISG as they are present in the architecture. Transitories on the other hand, are not necessarily uniquely related to physical interconnect resources in the architecture….” – then see description of fig. 3-4 in col. 10, including example fig. 4(b): “A data-stationary instruction that controls a two-cycle multiply-accumulate pipeline, is modelled by two ISG operations, as shown in FIG. 4(b). The operations are connected by a transitory with a delay of one cycle and each of them is annotated with operation stages. The code generator can then easily derive the timing of the complete pattern and replace the pattern by a more abstract operation, as will be explained in the sequel.”
then, see subsection 3, Additional Modeling Issues, starting in col. 15, ¶ 1: “The basic idea behind modelling the decision making capabilities of a processor in the ISG is to introduce abstract control flow operations. Control flow operations in the ISG are much like data-path operations. They just model the control unit of the processor instead of the data path. A jump operation, for example, assigns a new value to the program counter (PC).” – to further clarify on the ISG of Van Praet having been populated and interconnected, see the subsection starting in col. 18, line 24, titled: “Specification of the ISG”: “…Although nML contains all the information needed for code generation, it is not a processor model. It does not explicitly show the connectivity of the data-path, nor does it allow efficient look up of all operations with a certain behavior. The nML description formalism is designed to facilitate the task of describing a processor… An enumeration of both the memory locations and the instruction set of the processor are the basic ingredients of an nML description… The structure in the nML description of 30 the example processor of the present invention is shown in FIG. 11 [see fig. 11]…” – see remaining parts of this section (to col. 21, ln. 13) for more clarification, followed by subsection “Adding a structural skeleton to nML” including ¶ 1 including: “…These transitories have also been added to the nML formalism, to be able to use it as a front-end to the ISG model….An nML description starts with specifying a structural skeleton of the processor at the level desired in the ISG, with exception of most read/write ports of static storage elements…” – to clarify, see the discussion of the transitories above, for these are the interconnects between the model objects of the ISG
for more clarification, see the subsection starting around line 55 of col. 21 titled: “Use of the Model by the Code Generation and Instruction Set Simulation Programs”, including: “…On the one hand, the processor specification consists of a description of the data types and operations that are supported in the instruction set of the processor. The processor specific data types and operations are specified in the C language…On the other hand, the processor specification contains a description of the processor architecture and instruction set. This is specified preferably in the nML language…The processor primitives of the library Lare stored in the LIB format (.lib files), the architecture and instruction set description is stored as an instruction set graph or ISG (.isg files), and the non-primitive functions of the processor model and of the application program are stored in a control data flow graph or CDFG format (.cdfg files)…” – then see fig. 12, and its accompanying description including: “1. The processor specific operations are specified in the C language and this specification is translated into the LIB format by means of the noodle tool. For primitive operations 25 (i.e. operations supported by the instruction set of the processor), only an entry in the LIB is generated; for non primitive operations, also a CDFG view is generated. 2. The processor instruction set and RT-level architecture are specified in the nML language, and are translated into an ISG [the populating and interconnecting steps] by means of the animal tool. Here it is checked that only primitive operations are used in the nML actions. In the ISG, operations are attributed with connectivity and instruction encoding information… Steps 1 and 2 need to be executed once for every processor design iteration,”
as to the outputting, e.g. for simulating, see subsection “A simulator generator based on the ISG” starting in col. 23: “The ISG model is also used as processor model in a retargetable simulator generator. In the sequel, for the purposes of teaching, the retargetable simulator generator CHECKERS is detailed. In fact the instruction level simulator can be an executable C++ program that is automatically generated by analyzing the ISG. The flow of this process is shown in FIG. 13. The first two steps are completely the same as for the retargetable compiler. In a third step the ISG is analyzed by the tool checkers to generate the C++ program… The C++
program basically is a list of calls to the functions containing the behavioral models of the ISG operations, with each call being guarded by the corresponding enabling condition. The functions containing the behavioral models are described in the processor.c file. The last step to build the simulator is to compile the C++ program together with the processor.c file with a C++ compiler. This yields the instruction set simulator…. In the preferred embodiment, the resulting instruction level simulator interprets a stream of non-preprocessed instructions to simulate the behavior of processor”
see subsection “Implementation of the ISG” (starting in col. 23, around line 30) for more details on an exemplary implementation of the ISG– see accompanying figure 14 to further clarify, noting in particular the two parse steps
Regarding Claim 7
Van Praet teaches:
The method of claim 1, wherein each instance of the instances of the model objects represents one or more of a control logic, a timing, and a memory access for the respective stage of the first processor architecture design. (Van Praet, as cited above, teaches that the model objects in the ISG include “ISG operations” (col. 8, last paragraph) for “transforming values in storage elements into other values in other storage elements”, e.g. see fig. 4(a): “FIG. 4(a) shows how a two-cycle, non-pipelined multiply accumulate operation would look like in the ISG” and fig. 4(b): “A data-stationary instruction that controls a two-cycle multiply-accumulate pipeline, is modelled by two ISG operations, as shown in FIG. 4(b). The operations are connected by a transitory with a delay of one cycle and each of them is annotated with operation stages.” as discussed in col. 10, also see fig. 3, as discussed in col. 18 at lines 20-25: “In FIG. 3, two functional units can be found: alu and sh.” – also, col. 15, lines 25-30: “Control flow operations in the ISG are much like data-path operations. They just model the control unit of the processor instead of the data path”
Regarding Claim 10.
Rejected under a similar rationale as claim 1 above.
Regarding Claim 12.
Rejected under similar rationale as claim 7 above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 2-6, 8, 11, 13, 15-17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Van Praet et al., US 5,854,929 in view of Khairy, Mahmoud, et al. "Accel-sim: An extensible simulation framework for validated gpu modeling." 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020.
Regarding Claim 2
While Van Praet alone does not teach the following, Van Praet in view of Khairy teaches:
The method of claim 1, further comprising:
simulating execution of pseudo-instructions by the architecture model, the pseudo-instructions being generated from a software trace; (Van Praet, see col. 23 as cited above, lines 1-30, i.e. its performing an “instruction level” simulation with an “instruction level simulator” based on the “ISG”, e.g. “In the preferred embodiment, the resulting instruction level simulator interprets a stream of non-preprocessed instructions to simulate the behavior of processor. It is also possible to input this instruction stream to the simulator generator in which case the resulting C++ program would contain a behavioral model of the processor for the given instruction stream”
as taken in view of Khairy, abstract, followed by bullet points starting on page 474, col. 2, including: “It introduces Accel-Sim, a simulation framework explicitly designed to make modeling and validating future GPUs easier. By utilizing a flexible frontend, capable of switching between execution-driven vISA simulation and trace-driven mISA simulation, we are able to simulate hand-tuned machine code from NVIDIA binaries without giving up the option to perform execution-driven simulation when appropriate. We demonstrate Accel-Sim’s flexibility by modeling GPUs from Kepler to Turing…” – then, see § II, including subsection II.A, including ¶ 1: “Our new frontend supports both vISA (PTX) execution driven and mISA (SASS) trace-driven simulation. In trace driven mode, mISA traces are converted into an ISAindependent intermediate representation, that has a 1:1 correspondence to the original SASS instructions. Table II depicts an example of how SASS instructions from different machine generations and the virtual instructions from PTX are translated into the ISA-independent representation [example of a pseudo-instruction] used by the performance model. The intermediate format is integrated into GPGPU-Sim 4.0 and represents the interface between the frontend and the performance model. The format includes all the information necessary to perform timing simulation, in particular: (1) the instruction’s control flow (PC and active mask), (2) the instruction’s datapath information (registers accessed and execution unit) and (3) memory addresses for ld/st instructions.” – see table II to clarify which shows an “Example demonstrating how mISA instruction traces and vISA instructions translate into the ISA-independent intermediate representation used by the performance model. In traces, the mapping between opcode and execution unit is provided by the ISA def file in Figure 1.* indicates these values are computed using emulation.”
and generating performance information based on the simulation of the execution of the pseudo-instructions by the architecture model. (Van Praet, as was taken in view of Khairy above, further see Khairy, § II, subsection D: “Accel-Sim’s correlation tool automates the process of generating counter-by-counter correlation data for different architectures. The tool generates graphs and data that serve as correlation guidance to pinpoint workloads and metrics where the simulator is not well correlated to hardware. Using insights from the correlation of various performance counters over different realistic workloads and microbenchmarks, performance bugs or misrepresentations in the simulator are identified and corrected.” – e.g. see graphs in § V such as figure 4-6
Khairy is considered analogous art as it is in the same field of endeavor of simulating digital processing circuits (see instant disclosure, ¶ 46, which also contemplates simulating GPUs as an example of “complex processors”; also see ¶ 48).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Van Praet on a system simulating a digital circuit (the processor) with an “instruction level simulator” with the teachings from Khairy on “a new GPU simulator frontend that minimizes the effort required to simulate different machine ISAs through trace-driven simulation of NVIDIA’s native machine ISA, while still supporting execution-driven simulation of the virtual ISA.” (Khairy, abstract) The motivation to combine would have been that this “minimizes the effort required to simulate different machine ISAs through trace-driven simulation of NVIDIA’s native machine ISA, while still supporting execution-driven simulation of the virtual ISA” and “…We propose a novel, ambidextrous GPU frontend that translates both functionally executed virtual instructions and machine instruction traces into an ISAindependent format for simulation. Using the flexible frontend, a detailed performance model is developed, which has the ability to model contemporary GPUs and execute proprietary binaries that no other open-source simulator can. We believe that Accel-Sim is the most extensively validated open-source GPU simulation framework to date. We demonstrate that Accel-Sim decreases cycle error from 94% in state-of-the-art simulation to 15%, on a comprehensive suite of workloads. Accel-Sim’s ISA-independent performance model opens up opportunities to simulate cards from a wide variety of vendors. Work is currently underway to generate AMD GCN3 traces from Gem5-APU [6] such that Accel-Sim can be used to model and validate AMD GPUs. We believe that Accel-Sim will reduce the accuracy gap between industrial and academic simulators on an ongoing basis, increasing the potential impact of accelerator research.” (Khairy, abstract and § VIII respectively)
Another motivation to combine would have been that Khairy, § II, subsection D: “Accel-Sim’s correlation tool automates the process of generating counter-by-counter correlation data for different architectures. The tool generates graphs and data that serve as correlation guidance to pinpoint workloads and metrics where the simulator is not well correlated to hardware. Using insights from the correlation of various performance counters over different realistic workloads and microbenchmarks, performance bugs or misrepresentations in the simulator are identified and corrected.”
Another motivation to combine would have been that Khairy, § II.E: “Adding detail and flexibility to a performance model often comes at the expense of increased simulation time. Although Accel-Sim is not multithreaded, we take steps to improve its speed. With our improvements, Accel-Sim in trace-driven mode is able to perform 12.5 kilo warp instructions per second, a 4.3× simulation time improvement over GPGPUSim 3.x. Half of our speed improvement comes from the fact that trace-driven mode avoids functional execution.”
Regarding Claim 3
Van Praet in view of Khairy teaches:
The method of claim 2, further comprising:
receiving the software trace comprising instructions; and converting each instruction of the instructions of the software trace into a respective pseudo-instruction of the pseudo-instructions. (See citations above for claim 2)
Regarding Claim 4
Van Praet in view of Khairy teaches:
The method of claim 3, wherein converting each instruction of the instructions of the software trace into the respective pseudo-instruction of the pseudo-instructions includes excluding operands of the respective instruction in the respective pseudo-instruction. (See citations above for claim 2, specifically see table II, note the operand, e.g. “LD.E”, “LDG.E”, “IADD.X”, was excluded in the “ISA-independent representation”)
Regarding Claim 5
Van Praet in view of Khairy teaches:
The method of claim 2, wherein the software trace is from execution or simulation of execution of instructions by a processor having a second processor architecture different from the first processor architecture design. (See citations above for claim 2, e.g. abstract: First, we introduce a new GPU simulator frontend that minimizes the effort required to simulate different machine ISAs through trace-driven simulation of NVIDIA’s native machine ISA, while still supporting execution-driven simulation of the virtual ISA.”, and to clarify, see § I ¶ 3: “Accel-Sim introduces a flexible frontend, that enables it to operate in either trace- or execution-driven mode. Accel-Sim includes a trace-generation tool (built using the NVBit [70] binary instrumentation tool), that produces machine ISA instruction traces from any CUDA binary, including those that use closed-source libraries, like cuDNN [43]. These machine ISA traces are then converted into an ISA-independent intermediate representation that is input to the performance model. The trace-driven frontend allows Accel-Sim to simulate the machine ISA in new cards without implementing the ISA’s functional model and increases the accuracy of the simulator over executing the virtual ISA” – e.g. § II.A ¶ 2: “We generate the traces from NVIDIA GPUs using Accel-Sim’s tracer tool that is built on top of NVbit [70]. We use base+stride compression for the memory traces to keep the trace sizes within an acceptable range. When a new SASS ISA is released, users provide the frontend with an ISA Def file that specifies where each instruction should be executed. This is a relatively simple mapping that can be derived from publicly available information on NVIDIA’s machine ISA [42].”)
Regarding Claim 6
Van Praet in view of Khairy teaches:
The method of claim 2, wherein the pseudo-instructions are agnostic with respect to an instruction set architecture (ISA) of the first processor architecture design. (See citations above for claim 2)
Regarding Claim 8
Van Praet in view of Khairy teaches:
The method of claim 1, wherein each instance of the instances of the model objects represents the respective stage excluding non-memory access functional behavior of the respective stage. (Van Praet, col. 15, ln. 30-40: “Other operations, such as a call to a subroutine or a hardware do loop have a more complex behavior, the details of which are not put in the ISG as they are unneeded for code generation. Instead an abstract control flow operation is inserted in the ISG and its behavioral model is stored elsewhere and made available to the simulator.” and col. 10, lines 50-56: “The code generator can then easily derive the timing of the complete pattern and replace the pattern by a more abstract operation, as will be explained in the sequel.” – and col. 14, lines 40-60: “The design, both the DFG and the ISG, is also taken to a higher level of abstraction. For each subgraph in the DFG that is formed by the partitioning above, a new abstract operation gEL is created, and the subgraph is replaced by an instance of operation g. For each valid binding of this subgraph, a new operation bEVICL is created. Operation b is inserted in the ISG and is a subtype of operation g in the type hierarchy of L. The enabling condition(s), the resources and the timing of operation b can all be derived from the original ISG and are annotated with b. In this way the same relations are obtained as depicted in FIG. 5, but with a DFG and an ISG of much lower complexity. Specific binding possibilities, to be decided on in a subsequent phase, are directly accessible in the library.” - to clarify, see fig. 13, step of “dump C++ program where behavioral models of ISG operations are called, guarded by their enabling conditions” as discussed in col. 23, lines 5-20, i.e. the ISG, at these higher levels of abstract of Van Praet, does not have the behavioral model in the ISG, but rather calls it for the simulation itself as part of the “C++” file for the simulator (compared to the ”.isg” file for the ISG)
as taken in further view of Khairy, as was cited above for claims 2-3, and the rationale to combine above, in further view of Khairy, § II.E: “Adding detail and flexibility to a performance model often comes at the expense of increased simulation time. Although Accel-Sim is not multithreaded, we take steps to improve its speed. With our improvements, Accel-Sim in trace-driven mode is able to perform 12.5 kilo warp instructions per second, a 4.3× simulation time improvement over GPGPUSim 3.x. Half of our speed improvement comes from the fact that trace-driven mode avoids functional execution.”
Regarding Claim 11.
Rejected under a similar rationale as claims 2 above.
Regarding Claim 13.
Rejected under similar rationale as claim 8 above.
Regarding Claim 15.
Rejected under a similar rationale as claims 1-3 above
Regarding Claim 16.
Rejected under a similar rationale as claims 1-3 and 7-8 above
Regarding Claim 17.
Rejected under similar rationale as claim 5 above.
Regarding Claim 19.
Van Praet in view of Khairy teaches:
The method of claim 15, wherein each pseudo-instruction of the pseudo-instructions does not include non-memory access operands. (Van Praet, as was taken in view of Khairy above for claims 1-3 and 8, including Khairy, § II.E: “…Half of our speed improvement comes from the fact that trace-driven mode avoids functional execution” – and see table II as well of Khairy
Claim(s) 9 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Van Praet et al., US 5,854,929 in view of Alves, Marco Antonio Zanata, et al. "Sinuca: A validated micro-architecture simulator." 2015 IEEE 17th International Conference on High Performance Computing and Communications, 2015 IEEE 7th International Symposium on Cyberspace Safety and Security, and 2015 IEEE 12th International Conference on Embedded Software and Systems. IEEE, 2015.
Regarding Claim 9
While Van Praet does not explicitly teach the following, Van Praet in view of Alves teaches:
The method of claim 1 further comprising:
connecting a first traffic driver to a fetch model object instance, the instances of the model objects including the fetch model object instance, the first traffic driver being a model configured to generate first transactions for accessing memory outside of the architecture model; and connecting a second traffic driver to a load-store model object instance, the instances of the model objects including the load-store model object instance, the second traffic driver being a model configured to generate second transactions for accessing memory outside of the architecture model. (Van Praet, fig. 1: “The processor has a load/store architecture and can fetch two operands at a time by using both the program bus (P) and the data bus (D).”, as well as the citations above for claim 1, including the simulator
as taken in view of Alves, abstract, including: “In this paper, we present the validation of a new cycle-accurate, trace-driven simulator, SiNUCA. To perform the validation, we introduce a new set of micro-benchmarks to evaluate the performance of architectural components. SiNUCA provides a controlled environment to simulate the micro-architecture inside the cores, the cache memory sub-system with multi-banked caches, a NoC interconnection and a detailed memory controller” – then, see § III.A for the component of “Processor: This component is responsible for executing the Opcodes. It consists of the fetch, decode, rename, dispatch, execute and commit stages. Currently, an Out-of-Order (OoO) processor is modeled. The processor consists of 6 main stages, each stage can be configured to take multiple cycles to complete. Although the processor could be simulated with fewer stages, we implemented these stages separately in order to increase the flexibility and ease simulator extensions.” [i.e. the micro-architecture of the processor core]
then, see figure 1, in particular see the “Processor” component, noting that this has a “Fetch” block coupled with a “Mem” traffic driver for generating transactions from outside of the processor micro-architecture (e.g. see the Table III and Table IV discussing the processor cores); similarly note in fig. 1 in the “Execution” block the “Load” and “Store” coupled to a traffic driver of “MOB” then to “Mem”; see p. 605, col. 2: “ Validated with High Accuracy: We introduce a set of microbenchmarks that cover the main performance relevant components: the control unit, dependency handling, execution units, as well as memory load and store operations on different memory levels.” – again for generating transactions outside of the architecture model (clarify with table III: “MOB entries: 24-read, 16-write; 1-load and 1-store units (1-1 cycle);”) – wherein, as shown in the figure, these all are transactions with various forms of memory such as the caches and the DRAM as visually depicted
Examiner also notes that the BRI of traffic driver is simply a model that drives traffic, such as to generate transactions for accessing memory outside of the architecture model, e.g. see fig. 1 of Alves, for there are multiple elements in fig. 1 which are readily examples of this traffic driver, e.g. if one considers the architecture as being everything on the processing chip, note in tables III and IV that the “Memory Controller” is “Off-chip DRAM controller” with multiple channels, and see fig. 1, wherein this acts as a traffic driver, through separate paths, each path including more traffic drivers such as the Caches with their “Prefetcher”, to the ”Load”/”Store” as well as the “Fetch” objects; to clarify on the BRI, see fig. 1-2 and 5-6 of the instant disclosure, which show the “Fetch”, followed by “Dispatch”, followed by “Load/Store”, wherein in instant fig. 5-6 the Load/Store and Fetch connect to “VPU” (¶¶ 60-61: “The VPUs 502,504 are mapped to memory drivers, which are connected to interconnect and memory models to form a SoC system… A traffic driver can be a model which can generate transactions which can be sent for accessing the memory.”) – in other words, the “Fetch”, “Load”, and “Store” objects of Alves are coupled each with a plurality of traffic drivers, wherein these generate transactions for memory access to an “Off-chip DRAM controller” to off-chip DRAM
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Van Praet a system which included simulating processor architectures with the teachings from Alves on “a new cycle-accurate, trace-driven simulator, SiNUCA”. The motivation to combine would have been that “SiNUCA provides a controlled environment to simulate the micro-architecture inside the cores, the cache memory sub-system with multi-banked caches, a NoC interconnection and a detailed memory controller” (abstract) – also, see page 605, col. 2, including for: “Due to its performance validation, SiNUCA enables simulation of new micro-architecture features with a high fidelity…SiNUCA is able to model several state-of-the-art technologies, such as NUCA, Non-Uniform Memory Access (NUMA), NoC and DDR3 memory controllers. Besides traditional micro-architecture enhancements such as cache pre-fetchers, branch predictors and others, the support for new technologies is important for accurate simulation of future processors…Another important feature to support computer architecture research is the ease of implementing or extending features. This is enabled by SiNUCA with a modular architecture, which provides a direct access to the operational details of all the components.”
Regarding Claim 14.
Rejected under a similar rationale as claim 9 above
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Black, Bryan, et al. "Can trace-driven simulators accurately predict superscalar performance?." iccd. 1996. § 2.2
Butko, Anastasiia, et al. "A trace-driven approach for fast and accurate simulation of manycore architectures." The 20th Asia and South Pacific Design Automation Conference. IEEE, 2015. Abstract and § I, § III.A
Cifuentes, Cristina, Mike Van Emmerik, and Norman Ramsey. "The design of a resourceable and retargetable binary translator." Sixth Working Conference on Reverse Engineering (Cat. No. PR00303). IEEE, 1999. § 4.2
Grandpierre, Thierry, and Yves Sorel. "From algorithm and architecture specifications to automatic generation of distributed real-time executives: a seamless flow of graphs transformations." First ACM and IEEE International Conference on Formal Methods and Models for Co-Design, 2003. MEMOCODE'03. Proceedings.. IEEE, 2003. §§ 2-2.1
Guo, Xuan, and Robert Mullins. "Accelerate cycle-level full-system simulation of multi-core RISC-V systems with binary translation." arXiv preprint arXiv:2005.11357 (2020). Abstract, §§ 2.3-2.2, 3.1-3.2.
Haubelt, Christian, et al. "A SystemC-based design methodology for digital signal processing systems." EURASIP Journal on Embedded Systems 2007.1 (2007): 047580. Abstract, §§ 4.1-5.2
Keinert, Joachim, et al. "SystemCoDesigner—an automatic ESL synthesis approach by design space exploration and behavioral synthesis for streaming applications." ACM Transactions on Design Automation of Electronic Systems (TODAES) 14.1 (2009): 1-23. Abstract, §§ 4-8
Khalid, Humayun. "A trace-driven simulation methodology." ACM SIGARCH Computer Architecture News 23.5 (1995): 27-33. Abstract, §§ II-III
Kogel, Tim, et al. "SystemC based architecture exploration of a 3D graphic processor." 2001 IEEE Workshop on Signal Processing Systems. SiPS 2001. Design and Implementation (Cat. No. 01TH8578). IEEE, 2001. pages 6-7
Lukasiewycz, Martin, et al. "Combined system synthesis and communication architecture exploration for MPSoCs." 2009 Design, Automation & Test in Europe Conference & Exhibition. IEEE, 2009. § 2.1
Panda, Preeti Ranjan. "SystemC: a modeling platform supporting multiple design abstractions." Proceedings of the 14th international symposium on Systems synthesis. 2001. § 3 and subsections
Venkatagiri, Radha, et al. "gem5-approxilyzer: An open-source tool for application-level soft error analysis." 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2019. Abstract, § III and subsections
Patra et al., US 10,489,541. Abstract, cf. 1-3 and accompanying descriptions
Wozniak, US 2004/0162805. Abstract.
Bensal et al., US 2008/0172657. Abstract, cf. 3-6, 9, and accompanying descriptions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID A. HOPKINS whose telephone number is (571)272-0537. The examiner can normally be reached Monday to Friday, 10AM to 7 PM EST.
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, Ryan Pitaro can be reached at (571) 272-4071. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David A Hopkins/ Primary Examiner, Art Unit 2188
Prosecution Insights