DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments regarding the 35 USC 112(b) rejections are not persuasive. Applicant identifies the language as a version of CodAL in the citation to the specification. CodAL is a trademark. Codasip is a trademark. The use of Codasip in the claims, even if generously interpreted in light of the cited section of the specification cited, is still improper and indefinite. Applicant appears to agree with this, making it explicitly of record on p.7 of the remarks filed 4/30/2026 that “the application makes it abundantly clear that the language ‘Codasip Architecture Language’ is meant to identify a specific goods.” Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. Applicant’s admission on the record here makes it clear that the rejection is warranted. The 35 USC 112(b) rejections are maintained.
Applicant’s preliminary note (p.8 of the remarks) is not commensurate in scope with the claims, and is not persuasive. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant’s arguments on p.9-11 overly narrow the scope of what “developing” a model of a processor (or a “single model of a processor”) from various aspects would reasonably include. Claims are interpreted under the broadest reasonable interpretation. The disclosure of an instruction accurate model is maintained to fall within the scope of a processor model. The cited features involved with it are maintained to disclose that the model is developed using aspects that fall within the scope of the claim language. Examiner suggests that applicant further clarify or define the claim language regarding how those features are used to “develop” the model, if they disagree with this interpretation. The arguments are respectfully not persuasive.
Applicant’s amendments does not clarify what the “new features” of the EDA tool are, or what they are “new” relative to. Examiner notes that where the “new features” language appears is the first mention of the EDA tool in the claims. Under the broadest reasonable interpretation, this includes virtually any EDA tool which offers features. Applicant’s argument is respectfully not persuasive here.
Regarding claim 2, the citation states explicitly states that it can use a CodAL. This is maintained to fall within the scope of the claim language, as claim 3 explicitly notes that Codasip Architecture Languges (CodALs) are an example of such a language. Applicant’s argument is respectfully not persuasive here.
Regarding claim 5, the cited feature where a process is repeated until “results provide satisfactory output results” is maintained to fall within the scope of verification/validation. The arguments here are respectfully not persuasive.
The above remains true (“satisfactory output results” are maintained to fall within the scope of not showing agreement) for claim 6.
Applicant’s remarks regarding claim 7 unreasonably narrow the scope of the term “expected value”, which the cited portions of the reference are maintained to fall within (“prepares expected outputs”). The arguments here are respectfully not persuasive.
The “assembly language application” at issue in claim 8 is part of the model of the reference, and the use of random generation for it results in a model that is based on a random generator. The claim does not exclude other influences or sources from contributing to the generation of the model beyond the random generator. The arguments are not persuasive.
The IA/CA models being supplied by a third party is maintained to be equivalent to a third-party simulator. The arguments for claim 9 are not persuasive.
Applicant argues that the citations for claim 5 and 10 are to the same portions of the reference. The claim language is extremely similar between the two claims, so this is maintained to be reasonable. Applicant alleges that “rejection cannot be correct” when it uses identical citations to another claim rejection. The examiner is unaware of such a rule, and respectfully requests a citation to the MPEP where the MPEP states this. Absent this, this argument is spurious.
Further regarding claim 10, applicant highlights the portion of the rejection that states “see the discussion of the reference in ¶47-55, which falls within the scope of the verification claimed here”. The reference, in the directly cited section of ¶47, discloses a “verification environment” to support “interfaces to models to be verified, and relations there-between”. This is maintained to fall within the scope of the claim language, specifically within the scope of “simulation tools”. The arguments are not persuasive.
In summary, the arguments are all unpersuasive. All rejections are maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 contains the trademark/trade name “Codasip Architecture Language”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe the source of the programming language and, accordingly, the identification/description is indefinite.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Prikryl (US 20150234965 A1).
Regarding Claim 1, Prikryl teaches:
A method for a design of a processor's programming and/or simulation tools, comprising: (¶2 automatic processor design and verification; ¶30 automatically generates the programming and simulation tools)
developing a single model of a processor (¶14 Since there is only single model; ¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results.; ¶40 The reference model 128 prepares expected outputs for the designed ASIP.; examiner notes the reference enummerates how its single model functions in ¶34-40)
from a group consisting of: the processor; (¶26 a conceptual structure and information flow among elements of the conceptual structure for design and verification of an application-specific instruction-set processor.; ¶37 The ASIC/FPGA synthesis module 126 takes hardware description 124 and creates a description for the target hardware technology, e.g., silicon chip, or an FPGA; see also ¶34-36 in general)
a hardware description of the processor; and (¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106.; ¶37 The ASIC/FPGA synthesis module 126 takes hardware description 124 and creates a description for the target hardware technology, e.g., silicon chip, or an FPGA.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
a processor's specifications confirmed to represent the processor and/or the hardware description; and (¶27 The specifications may change during the design process based on results of ASIP simulation, synthesis, and/or verification.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106 ... The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute.; ¶45 The generated verification environment carries a verification of the ASIP design by verifying the generated hardware description 124 against the reference model 128)
generating automatically by an Electronic Design Automation comprising new features tool the processor's programming and/or the simulation tools from the single model of the processor (¶27 The design process starts by determining requirements for a newly developed ASIP in accordance with the target application, resulting in ASIP specifications 102, which determine tools and ASIP design generated by an EDA tool as disclosed infra.)
and a set of design parameters. (¶27 Such ASIP specifications 102 comprise a separate description of an instruction set specifications and a micro-architecture specification.)
Regarding Claim 2, Prikryl teaches:
developing the single model in a language designed to unify a description of an instruction set and a description of a micro-architecture. (¶10 The second category allows to describe and modify all parts of ASIP. Examples of this category are Language for Instruction Set Architectures (LISA), nML, Codasip Architecture Language (CodAL).)
Regarding Claim 3, Prikryl teaches:
wherein the language, comprises: a Codasip Architecture Language. (¶10 The second category allows to describe and modify all parts of ASIP. Examples of this category are Language for Instruction Set Architectures (LISA), nML, Codasip Architecture Language (CodAL).)
Regarding Claim 4, Prikryl teaches:
wherein the set of design parameters is empty. (¶28 The EDA tool 108 is agnostic to whether the IA model 104 and the CA model 106 are template-based or fully configurable.; ¶29 Additional inputs to the EDA tool 108 may comprise optional design parameters 107 influencing the behavior of the EDA tool 108.; ¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36)
Regarding Claim 5, Prikryl teaches:
generating automatically by the Electronic Design Automation tool a verification environment in addition to the programming and/or the simulation tools from the single model of the processor; and verifying the programming tools by the verification environment by: (¶28; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
executing at least one verification application and optional port(s) value(s) on a reference entity resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one value; (¶40 Were the reference model 128 be generated from the final CA model 106, a potential error/irregularity existing in the final CA model 106 would be reflected in both the generated hardware description 124 and the reference model 128; consequently, the verification process would be unable to discover this error/irregularity.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106. The generated verification environment 130 comprises a program specifying usage of a set of tools, libraries and/or functions designed to support verification. In particular, the verification environment 130 program creates instances of the drivers and conceptual structures, defines relationships there-between, as disclosed in reference to FIG. 2 infra. )
determining whether the at least one value characterizing each of the at least one state agrees with at least one expected value characterizing each of the at least one state; and providing the processor's programming tools when the determining shows agreement. (¶37 the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.; ¶41 The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute; ¶42 Because the programming and simulation tools are generated from both the final IA model 104 and the final CA model 106 and the EDA tool 108 extracts parameters describing the micro-architecture from the final CA model 106, the programming tools are aware of a micro-architecture of the ASIP. Therefore, the verification environment 130 is also able to verify that the programming tools are correctly aware of the micro-architecture of the ASIP.)
Regarding Claim 6, Prikryl teaches:
modifying the developed single model of the processor when the determining does not show agreement; and repeating the method as claimed in independent claim 1. (¶35 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results.; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
Regarding Claim 7, Prikryl teaches:
at least one verification application forms a set of pre-prepared verification applications provided by the Electronic Design Automation tool, wherein each verification application includes at least one expected value. (¶40 The reference model 128 prepares expected outputs for the designed ASIP; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106.)
Regarding Claim 8, Prikryl teaches:
generating by the Electronic Design Automation tool from the single model of the processor automatically a random program generator; and (¶32 a random generator of assembly language application(s) may be used.; ¶33 The assembly language representation of the application(s) 120, obtained by either aspect supra, is provided to the assembler 112, which produces a binary representation of the application(s) in a form of one or more object files.)
generating the at least one verification application and the at least one expected value characterizing each of the at least one state by the random program generator. (¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106. The hardware description 124 comprises generated hardware implementation in the language for hardware description and a relevant test environment; see the citations regarding verification presented for claim 5)
Regarding Claim 9, Prikryl teaches:
wherein the reference entity is the processor or a third-party simulator (¶28 In yet another aspect, the IA model 104 and/or the CA model 106 may be produced by/for the specific EDA tool 108 and supplied by a third party.)
Regarding Claim 10, Prikryl teaches:
generating automatically by the Electronic Design Automation tool a verification environment in addition to the programming and/or the simulation tools from the single model of the processor; and verifying the simulation tools by the verification environment by: (¶28; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
verification application and optional port(s) value(s) on the simulation tools, resulting in at least one state of at least one resource, each of the at least one state being characterized by at least one first value; (¶47 the verification environment 230 is a program comprising instructions for the set of tools, libraries and/or functions designed to support verification to create drivers, structures, interfaces to models to be verified, and relations there-between. Thus, on the conceptual level, the verification environment 230 is divided into a predicted results unit 232, and a monitor unit 234.; see the discussion of the reference in ¶47-55, which falls within the scope of the verification claimed here)
executing the at least one verification application and optional port(s) value(s) on a reference entity, resulting in at least one state of the at least one resource, each of the at least one state being characterized by at least one second value; (¶40 Were the reference model 128 be generated from the final CA model 106, a potential error/irregularity existing in the final CA model 106 would be reflected in both the generated hardware description 124 and the reference model 128; consequently, the verification process would be unable to discover this error/irregularity.; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106. The generated verification environment 130 comprises a program specifying usage of a set of tools, libraries and/or functions designed to support verification. In particular, the verification environment 130 program creates instances of the drivers and conceptual structures, defines relationships there-between, as disclosed in reference to FIG. 2 infra. )
determining whether the at least one first value characterizing each of the at least one state agree with the at least one second value characterizing each of the corresponding at least one state; and providing the processor's simulation tools when the determining shows agreement. (¶37 the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.; ¶41 The verification environment 130 then instructs the set of tools, libraries and/or functions how to access the drivers, conceptual structures, and reference model 128, the generated hardware description 124, and how and what verification tests to execute; ¶42 Because the programming and simulation tools are generated from both the final IA model 104 and the final CA model 106 and the EDA tool 108 extracts parameters describing the micro-architecture from the final CA model 106, the programming tools are aware of a micro-architecture of the ASIP. Therefore, the verification environment 130 is also able to verify that the programming tools are correctly aware of the micro-architecture of the ASIP.)
Regarding Claim 11, Prikryl teaches:
modifying the developed single model of the processor when the determining does not show agreement; and repeating the method as claimed in independent claim 1. (¶35 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results.; ¶37 The hardware description 124 together with the ASIC/FPGA synthesis module 126 carry out implementation of the CA model 106. The results of the implementation are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 are needed, the changes are then used to change the IA model 104 and/or the CA model 106 and the process is repeated until the simulation, profiling and/or implementation results provide satisfactory output results.; ¶38 The final IA model 104 and the final CA model 106, i.e., the models, which yield the satisfactory output results, are input into the EDA tool 108, which generates a hardware description 124 and a reference model 128 respectively.)
Regarding Claim 12, Prikryl teaches:
at least one verification application forms a set of pre-prepared verification applications provided by the Electronic Design Automation tool, wherein each verification application includes at least one expected value. (¶40 The reference model 128 prepares expected outputs for the designed ASIP; ¶41 Once the EDA tool 108 generates hardware description 124 and the reference model 128, the EDA tool 108 generates the verification environment 130 from the final IA model 104 and the final CA model 106.)
Regarding Claim 13, Prikryl teaches:
generating by the Electronic Design Automation tool from the single model of the processor automatically a random program generator; and (¶32 a random generator of assembly language application(s) may be used.; ¶33 The assembly language representation of the application(s) 120, obtained by either aspect supra, is provided to the assembler 112, which produces a binary representation of the application(s) in a form of one or more object files.)
generating the at least one verification application and the at least one expected value characterizing each of the at least one state by the random program generator. (¶35 After simulation, debugging, or profiling, the produced output results are reviewed by the user and changes to ASIP specifications 102 may be made based on the output results. When changes to ASIP specifications 102 and/or the design parameters 107 are needed, the changes are then used to change the IA model 104 and/or the CA model 106, and the process of the EDA tool 108 automatically generating the programming and simulation tools and subsequent evaluation of the programming and simulation tools by simulation, debugging, or profiling is repeated until the simulation and profiling provides satisfactory outputs results; ¶36 As soon as the CA model 106 is available, a hardware description 124 may be generated from the CA model 106. The hardware description 124 comprises generated hardware implementation in the language for hardware description and a relevant test environment; see the citations regarding verification presented for claim 5)
Regarding Claim 14, Prikryl teaches:
wherein the reference entity is the processor or a third-party simulator. (¶28 In yet another aspect, the IA model 104 and/or the CA model 106 may be produced by/for the specific EDA tool 108 and supplied by a third party.)
Regarding Claims 15-22:
Claims 15-22 are substantively similar to claims 1, 4-6, 9-11, and 14 respectively. They are rejected under the same grounds as those presented for claims 1, 4-6, 9-11, and 14 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20190258755 A1 discloses a unified model of a network device that falls within the scope of claim 1, see ¶7, 9-10, 12-13, 29-32, 36-37, and 58-60.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIJAN MAPAR whose telephone number is (571)270-3674. The examiner can normally be reached Monday - Thursday, 11:00-8:30.
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, Rehana Perveen can be reached at 571-272-3676. 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.
/BIJAN MAPAR/ Primary Examiner, Art Unit 2189
Prosecution Insights