DETAILED ACTION
This action is in response to communications filed on 02/17/2026 in which claims 1, 12, 17, 18, 19, and 20 have been amended. No claims have been cancelled or newly added. Claims 1-20 are presented for examination.
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
Rejections under 35 U.S.C. § 112
Applicant has amended claims 17-20 in response to the previously set forth rejection under 35 U.S.C. § 112(b) for indefiniteness.
The amendment sufficiently overcomes the rejection and accordingly is withdrawn. However, the amendments to the claims have introduced additional rejections under 35 U.S.C. § 112 as stated in this action.
Rejections under 35 U.S.C. § 101
Applicant has amended claims 17-20 in response to the previously set forth rejection under 35 U.S.C. § 101.
The amendment defines the claims as falling in the statutory category of machines and removes the inclusion of limitations that previously characterized the claim as signals per-se and is therefore patent-eligible under 35 U.S.C. § 101. The rejection has accordingly been withdrawn.
Rejections under 35 U.S.C. § 103
The applicant has amended the claims in response to the previously set forth rejections under 35 U.S.C. § 103. Applicant argues that amended claims 1, 12, and 17 recite subject matter which is not taught or suggested by the references of record, either alone or in combination.
Applicant’s arguments with respect to claim(s) 1, 12, and 17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The claims remain rejected over the prior art, per the ground(s) of rejection presented herein this office action.
Claim Objections
Claim 12 is objected to because of the following informalities:
Claim 12 recites “providing the user in the graphical representations of controls associated with the hardware device; and” appears to contain a typographical error wherein the words “in the” may be unnecessary. Alternatively, language may instead be intended to mirror the claim language of claim 17 which alternatively recites “providing the user, on a screen, graphical representations of controls associated with the hardware device; and”. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a development system in claim 1
an input output device in claims 6 and 7
a hardware module in claims 9 and 10
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For the purposes of examination of the claim limitations, the Examiner will be interpreting the hardware structure associated with "a development system" as in independent claim 1, " an input output device " as in dependent claims 6 and 7, and "a hardware module" as in dependent claims 9 and 10, “ which are not found or described in the specification as illustrated in [Figure 3] and defined in specification paragraph [page 10 of 16 | lines 3-5] as a “computer” includes a personal computer or other type of processing device such as a tablet or smart device that is communicatively connected to a debugger portion 304 via a wired or wireless connection 303. The “processing device” includes such as in examples, a universal asynchronous receiver transmitter, a universal serial bus, and transmission control protocol/internet protocol as described in specification paragraph [page 3 of 16 |lines 12-14]. The “development system” that includes a hub portion operative to receive debugged signals and send and 20 receive commands to a microcontroller portion and a debugging portion communicatively connected to the hub portion as described in specification paragraph [page 1 of 16 | Lines19-21]. The “input output device” include such a signal may include, for example, a button, and input/output circuit, a pin, an analog output from a knob or a waveform signal from a 25 signal generator. The ID capable, hardware modules and input and output devices 212 allows the system 200 to identify connections and reroute connections or introduce signals and connections associated with commands and settings input by the user in the processing device 202 as described in specification paragraph [page 8 of 17 |lines 23-28]. The “hardware module” may include portions of the development board, an extension board, or a separate module board connected to the development board or an extension board as described in specification paragraph [page 7 of 16 | Lines 21-22].
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.
Claims 12-20 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.
Claim 12 recites “wherein an ID chip on hardware, or hardware module equipped with ID, allows the hub portion and a debugger to obtain an ID of the ID chip”. Specifically, the final recitation of “the ID chip” would lack antecedent basis if the alternative “hardware module equipped with ID” is employed. That is, “the ID chip” only has sufficient antecedent basis under the situation where the claim is interpreted to read “wherein an ID chip on hardware allows the hub portion and a debugger to obtain an ID of the ID chip”. The element does not have antecedent basis under the alternative interpretation where the claim would be interpreted to read “wherein a hardware module equipped with ID allows the hub portion and a debugger to obtain an ID of the ID chip”. In the second interpretation of the claim, “the ID chip” lacks antecedent basis.
Claim 17 likewise recites the deficiency stated above for claim 12 and is rejected under the same rationale.
Dependent claims 13-16 and 18-20 incorporate the deficiencies of their respective independent claims, as given above, and are rejected under the same rationale.
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.
Claims 1-11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mohammed et al (US Patent Publication No US 2014/0095120 A1), hereinafter referred to as Mohammed.
Regarding claim 1, Mohammed discloses A system for hardware and software development comprising: ((Mohammed, ¶20) " The processing system 200 can implement an integrated development environment 300, allowing unified hardware and software development and configuration of the programmable system 100 with hardware configuration files and software programming developed by the integrated development environment 300.")
a development system comprising: ((Mohammed, ¶19) " FIG. 1 shows a programmable system 100 configurable by a processing system 200 implementing an integrated development environment 300 according to embodiments of the invention."). See also Figures 1 and 2.
a hub portion operative to receive debugged signals and send and receive commands to a microcontroller portion; A core hub includes a bridge which is coupled to microcontroller 102 which contains the debug on chip 108 and wherein the hub provides the primary data and control interface to a microcontroller ((Mohammed, ¶28) "The core architecture may also include a Chub ( core hub) 116, including a bridge 118, such as a single-level or multi-level Advanced High-Performance Bus Bridge, and optionally a DMA ( direct memory access) controller 120, that is coupled to the microcontroller 102 via bus 122. The Chub 116 may provide the primary data and control interface between the microcontroller 102 and its peripherals and memory, and a programmable core 124.") See also Figure 2, item 116.
PNG
media_image1.png
911
753
media_image1.png
Greyscale
a debugging portion communicatively connected to the hub portion; See also Figure 2 depicting the debug on chip 108 of a microcontroller 102 connected via bidirectional arrows and a bus to the core hub 116.
a multiplexor communicatively connected to the hub portion and the microcontroller portion; and A bus 122 is given as being connected to the microcontroller 102 and the core hub 116 in Figure 2. The bussed signals are described as being multiplexed ((Mohammed, ¶71) " Any of the signals provided over various buses described herein may be time multiplexed with other signals and provided over one or more common buses.")
a development board communicatively connected to the debugging portion and the multiplexor. A programmable system on chip 124 (as a development board) is shown as being connected to a microcontroller 102 with a debug on chip 108 (debugging portion), wherein the connections are given as buses in Figure 2. The bussed signals are described as being multiplexed ((Mohammed, ¶71) " Any of the signals provided over various buses described herein may be time multiplexed with other signals and provided over one or more common buses.")
Regarding claim 2, Mohammed discloses The system of claim 1, as stated previously and further discloses further comprising a development extension board communicatively connected to the development board. An extended memory interface mechanism is part of the PSoC ((Mohammed, ¶29) "In one embodiment, the programmable core 124 includes a GPIO (general purpose IO) and EMIF ( extended memory interface) block 130 to provide a mechanism to extend the external off-chip access of the microcontroller 102, a programmable digital block 132, a programmable analog block 134, and a special functions block 136, each configured to implement one or more of the subcomponent functions."). The PSoC 124 is connected to a memory 126, as in Figure 2. ((Mohammed, ¶28) "The Chub 116 may also be coupled to shared SRAM 126 and an SPC (system performance controller) 128. The private SRAM 112 is independent of the shared SRAM 126 that is accessed by the microcontroller 102 through the bridge 118. The CPU core 104 accesses the private SRAM 112 without going through the bridge 118, thus allowing local register and RAM accesses to occur simultaneously with DMA access to shared SRAM 126. Although labeled here as SRAM, these memory modules may be any suitable type of a wide variety of (volatile or non-volatile) memory or data storage modules in various other embodiments.")
Regarding claim 3, Mohammed discloses The system of claim 2, as stated previously and further discloses wherein the development extension board is operable to transmit an identifier of the development extension board and a manifest file, The extended memory interface component is configured to extend off-chip access to memory ((Mohammed, ¶29) "In one embodiment, the programmable core 124 includes a GPIO (general purpose IO) and EMIF ( extended memory interface) block 130 to provide a mechanism to extend the external off-chip access of the microcontroller 102, a programmable digital block 132, a programmable analog block 134, and a special functions block 136, each configured to implement one or more of the subcomponent functions. In various embodiments, the special functions block 136 may include dedicated (non-programmable) functional blocks and/or include one or more interfaces to dedicated functional blocks, such as USB, a crystal oscillator drive, JTAG, and the like."). The memory 126 is shown externally connected with bidirectional transmission lines to the PSoC 124, in Figure 2. ((Mohammed, ¶28) "The Chub 116 may also be coupled to shared SRAM 126 and an SPC (system performance controller) 128. The private SRAM 112 is independent of the shared SRAM 126 that is accessed by the microcontroller 102 through the bridge 118. The CPU core 104 accesses the private SRAM 112 without going through the bridge 118, thus allowing local register and RAM accesses to occur simultaneously with DMA access to shared SRAM 126. Although labeled here as SRAM, these memory modules may be any suitable type of a wide variety of (volatile or non-volatile) memory or data storage modules in various other embodiments.") the manifest file operative to describe capabilities and connection terminals of the development extension board. Configuration files may be processed using the programmable system whereby the configuration files are described as being particular to the architecture and indicative of descriptions of hardware circuitry and corresponding mappings ((Mohammed, ¶21) "After hardware configuration files and software programming is developed, the processing system 200 can program and/or configure the programmable system 100 with the developed hardware configuration and software programming, for example, through a coupling device 230."); ((Mohammed, ¶25) " The processing system 200 can send the device-specific configuration files and the application programming interfaces to the programmable system 100. The programmable system 100 can utilize the configuration files to configure particular hardware components in the programmable digital and/or analog blocks 132 and 134 to implement the hardware circuitry described by the hardware description code. "); ((Mohammed, ¶37) " The integrated development environment 300 can include a code generator 330 to generate configuration files from the received descriptions of the hardware circuitry. In some embodiments, when the received descriptions of the hardware circuitry are in an abstracted or generic format, the code generator 330 can access a device-specific hardware mapping unit 340 to map the received descriptions of the hardware circuitry to the programmable digital and/or analog blocks 132 and 134 of the programmable system 100. In other words, the code generator 330 can determine where and how the programmable system 100 implements the generic circuitry provided by the user or system designer. This level of abstraction can allow users without specific knowledge of the programmable system 100 the ability to program and configure the programmable system 100 to perform various applications through the use of generic circuit descriptions and diagrams. The code generator 330 can generate the configuration files from the device-specific version of the hardware circuitry descriptions.").
Regarding claim 4, Mohammed discloses The system of claim 2, stated previously and further discloses wherein the development extension board includes a file describing a feature of the development extension board. The resources of the programmable system have corresponding device-specific configuration files ((Mohammed, ¶23) " In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."). The extended memory interface mechanism is part of the programmable system, thereby indicating as a resource of the programmable system ((Mohammed, ¶29) "In one embodiment, the programmable core 124 includes a GPIO (general purpose IO) and EMIF ( extended memory interface) block 130 to provide a mechanism to extend the external off-chip access of the microcontroller 102, a programmable digital block 132, a programmable analog block 134, and a special functions block 136, each configured to implement one or more of the subcomponent functions.").
Regarding claim 5, Mohammed discloses The system of claim 1, as stated previously and further discloses further comprising a processor board communicatively connected to the multiplexor. A CPU core 104 is connected to the bus 122, as given in Figure 2. The bussed signals are described as being multiplexed ((Mohammed, ¶71) " Any of the signals provided over various buses described herein may be time multiplexed with other signals and provided over one or more common buses.")
Regarding claim 6, Mohammed discloses The system of claim 1, as stated previously and further discloses further comprising an input output device communicatively connected to the development board. ((Mohammed, ¶22) " The processing system 200 can include system interface devices 206 that allow the processing system 200 to communicate with external devices, such as the user input device 210, the display device 220, and the programmable system 100.") See also Figures 1 and 2 wherein Figure 1 depicts a display device and a user input device communicatively coupled via a coupling device to the programmable system, wherein in Figure 2, the programmable system includes the PSoC.
Regarding claim 7, Mohammed discloses The system of claim 6 as stated previously and further discloses further comprising a data server communicatively connected to the input output device and the debugging portion. See Figure 11 depicting a machine readable storage medium 1128 connected via bus 1130 to video display, alpha numerical input device, cursor control device, etc. in exemplary system 1100 ((Mohammed, ¶75) " machine-readable storage medium 1128 is shown in an exemplary embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media ( e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. "). The exemplary system 1100 is representative of the processing system 200 ((Mohammed, ¶70) " In one embodiment, computer system 1100 may be representative of a processing system, such as processing system 200."). The processing system 200 comprises debug hardware 208 as well as is connected to the programmable system 100 which contains the debug on chip 108, thereby indicating communicative connection between such components (See at least Figures 1 and 2).
Regarding claim 8, Mohammed discloses The system of claim 1, as stated previously and further discloses further comprising a processing device communicatively connected to the debugging portion and a data server. A processing device 1102 is depicted as being communicatively coupled to a data storage device 1118 in Figure 11, all as part of a computer system 1100. The computer system is exemplary of a processing system 200 ((Mohammed, ¶70) " In one embodiment, computer system 1100 may be representative of a processing system, such as processing system 200."). The processing system 200 includes a debug hardware ((Mohammed, ¶26) " After the programmable system 100 has been programmed with the hardware configuration and software or firmware programming developed with the integrated development environment 300, the processing system 200 can include debug hardware 208 to perform debugging operations on the programmable system 100."). The processing system is further communicatively coupled to the debug on chip of the programmable system 100- See Figures 1 and 2. The data storage device may be a data server ((Mohammed, ¶75) " The machine-readable storage medium 1128 may also be used to store instructions to perform a method for schematic design including components that are both internal and external to the device being configured, as described herein. While the machine-readable storage medium 1128 is shown in an exemplary embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media ( e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions")
Regarding claim 9, Mohammed discloses The system of claim 4, as stated previously and further discloses wherein a hardware module is operable to transmit an identifier of the development extension board and a manifest file, The extended memory interface component is configured to extend off-chip access to memory ((Mohammed, ¶29) "In one embodiment, the programmable core 124 includes a GPIO (general purpose IO) and EMIF ( extended memory interface) block 130 to provide a mechanism to extend the external off-chip access of the microcontroller 102, a programmable digital block 132, a programmable analog block 134, and a special functions block 136, each configured to implement one or more of the subcomponent functions. In various embodiments, the special functions block 136 may include dedicated (non-programmable) functional blocks and/or include one or more interfaces to dedicated functional blocks, such as USB, a crystal oscillator drive, JTAG, and the like."). The memory 126 is shown externally connected with bidirectional transmission lines to the PSoC 124, in Figure 2. ((Mohammed, ¶28) "The Chub 116 may also be coupled to shared SRAM 126 and an SPC (system performance controller) 128. The private SRAM 112 is independent of the shared SRAM 126 that is accessed by the microcontroller 102 through the bridge 118. The CPU core 104 accesses the private SRAM 112 without going through the bridge 118, thus allowing local register and RAM accesses to occur simultaneously with DMA access to shared SRAM 126. Although labeled here as SRAM, these memory modules may be any suitable type of a wide variety of (volatile or non-volatile) memory or data storage modules in various other embodiments.") the manifest file operative to describe functions and connection terminals of the hardware module. Configuration files may be processed using the programmable system whereby the configuration files are described as being particular to the architecture and indicative of descriptions of hardware circuitry and corresponding mappings ((Mohammed, ¶21) "After hardware configuration files and software programming is developed, the processing system 200 can program and/or configure the programmable system 100 with the developed hardware configuration and software programming, for example, through a coupling device 230."); ((Mohammed, ¶25) " The processing system 200 can send the device-specific configuration files and the application programming interfaces to the programmable system 100. The programmable system 100 can utilize the configuration files to configure particular hardware components in the programmable digital and/or analog blocks 132 and 134 to implement the hardware circuitry described by the hardware description code. "); ((Mohammed, ¶37) " The integrated development environment 300 can include a code generator 330 to generate configuration files from the received descriptions of the hardware circuitry. In some embodiments, when the received descriptions of the hardware circuitry are in an abstracted or generic format, the code generator 330 can access a device-specific hardware mapping unit 340 to map the received descriptions of the hardware circuitry to the programmable digital and/or analog blocks 132 and 134 of the programmable system 100. In other words, the code generator 330 can determine where and how the programmable system 100 implements the generic circuitry provided by the user or system designer. This level of abstraction can allow users without specific knowledge of the programmable system 100 the ability to program and configure the programmable system 100 to perform various applications through the use of generic circuit descriptions and diagrams. The code generator 330 can generate the configuration files from the device-specific version of the hardware circuitry descriptions.")
Regarding claim 10, Mohammed discloses The system of claim 2, as stated previously and further discloses wherein a hardware module includes a file that describes a feature of the hardware module. The resources of the programmable system have corresponding device-specific configuration files ((Mohammed, ¶23) " In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."). The resources may be hardware resources ((Mohammed, ¶33) " The programmable analog block 134 may include analog resources including, but not limited to, comparators, mixers, PGAs (programmable gain amplifiers), TIAs (transimpedance amplifiers), ADCs (analog-to-digital converters), DACs ( digital-to-analog converters), voltage references, current sources, sample and hold circuits, and any other suitable type of analog resources."); ((Mohammed, ¶43) " The integrated development environment 300 can determine which hardware resources or components within the program system 100, such as the programmable digital blocks 132 and the programmable analog blocks 134, can implement the circuitry described by the reduced hardware description code according to a mapping.")
Regarding claim 11, Mohammed discloses The system of claim 1, as stated previously and further discloses wherein the multiplexor is controlled by the hub portion. ((Mohammed, ¶28) " The core architecture may also include a Chub ( core hub) 116, including a bridge 118, such as a single-level or multi-level Advanced High-Performance Bus Bridge, and optionally a DMA ( direct memory access) controller 120, that is coupled to the microcontroller 102 via bus 122. The Chub 116 may provide the primary data and control interface between the microcontroller 102 and its peripherals and memory, and a programmable core 124. The DMA controller 120 may be programmed to transfer data between system elements without burdening the CPU core 104."); ((Mohammed, ¶71) " Any of the signals provided over various buses described herein may be time multiplexed with other signals and provided over one or more common buses")
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed et al (US Patent Publication No US 2014/0095120 A1), hereinafter referred to as Mohammed, in view of Kuehnis et al (US Patent Publication No. US 2020/0285559 A1), hereinafter referred to as Kuehnis.
Regarding claim 12, Mohammed discloses (except the limitations surrounded by brackets ([[..]])) A method for operating a system, the method comprising: ((Mohammed, ¶26) " After the programmable system 100 has been programmed with the hardware configuration and software or firmware programming developed with the integrated development environment 300, the processing system 200 can include debug hardware 208 to perform debugging operations on the programmable system 100."); ((Mohammed, ¶72) " The processing device 1102 is configured to execute processing logic 1126 for performing the operations and steps discussed herein.")
receiving an input from a user on a processing device, the input indicating a hardware device selected by the user; ((Mohammed, ¶22-23) " The processing system 200 can include system interface devices 206 that allow the processing system 200 to communicate with external devices, such as the user input device 210, the display device 220, and the programmable system 100. For example, the processing system 200 can include a system interface 206 to communicate with the programmable system 100 over the coupling device 230. In some embodiments, the system interface devices 206 can receive inputs, for example, through the user input device 210, and present information, for example, via the display device 220. The processing system 200 can develop hardware and software applications for the programmable system 100 in response to user input, for example, from the user input device 210. The integrated development environment 300 can include various development tools that allow system designers to describe hardware circuitry for the programmable system 100 to implement and to provide software or firmware code for the microcontroller 102. In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL. ")
receiving an indication that a hardware device is installed in the system; ((Mohammed, ¶61) "Annotation elements may be designed with the existing tools for creating components, and a property (e.g., "annotation") of the object may be set to indicate that the component is to be placed in the annotation layer."); ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design.")
presenting a representation of the hardware device to the user on a display screen; ((Mohammed, ¶62) " FIG. 7 is an example screen shot showing the differentiation of annotation elements in a schematic generator, according to embodiments of the invention. Wires that connect to annotation hot spots may be forced to the annotation layer. Wires and other components with the annotation property may include a visual indication to indicate their nature. For example, internal components, such as wire 701 may be present in a default manner. Annotation elements ( e.g., representing external components), such as wire 702, however, may be present in a different manner. The annotation elements may have, for example, a different color, size, shape, weight, thickness, opacity or shading. They may be drawn using dashed or dotted lines. The visual indication may be any feature of the objects that distinguishes annotation objects from non-annotation objects ( or objects in one domain from objects in a different domain).")
providing the user with a graphical representation of the system; ((Mohammed, ¶55) " One embodiment includes a method to place objects in a single schematic or diagram that represent components both internal and external to the device to be configured, and to automatically determine placement of those objects. The connection point or points between the internal and external objects may be automatically defined at a logical boundary")
providing the user in the graphical representations of controls associated with the hardware device; and ((Mohammed, ¶Claim 9) " provide a graphical user interface for creating a circuit schematic to configure the programmable device;"); ((Mohammed, ¶68) " One advantage of the schematic designer described herein is that it lets the user visualize and configure the entire design, including the components that he may have little or no control over. Allowing external components to be placed and configured in the development tool, greatly improves design documentation and promotes system understanding.")
receiving an input from a user, the input is operative to control and debug the hardware device, ((Mohammed, ¶23) " The processing system 200 can develop hardware and software applications for the programmable system 100 in response to user input, for example, from the user input device 210. The integrated development environment 300 can include various development tools that allow system designers to describe hardware circuitry for the programmable system 100 to implement and to provide software or firmware code for the microcontroller 102. In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL"); ((Mohammed, ¶68) " One advantage of the schematic designer described herein is that it lets the user visualize and configure the entire design, including the components that he may have little or no control over. Allowing external components to be placed and configured in the development tool, greatly improves design documentation and promotes system understanding."); ((Mohammed, ¶35) "In some embodiments, the design editor 310 can access a database 320 to help determine dependency, build rules, and debug rules for the received descriptions of the hardware circuitry."); ((Mohammed, ¶40) "The debugger 360 can perform debugging operations on the programmable system 100 as configured with the configuration files and the application programming interfaces. For instance, the debugger 360 can perform step over, step into, and step out operations, which allows users the ability to perform incremental evaluations that step through programming code.") wherein the system is operative to emulate or change connections of the hardware device using a hub portion of the system A coupling device (as a hub of the system) is used to configure the programmable system (hardware device) according to configuration files that are derived from hardware description code that describes the circuitry/ routing of connections of components ((Mohammed, ¶21) " After hardware configuration files and software programming is developed, the processing system 200 can program and/or configure the programmable system 100 with the developed hardware configuration and software programming, for example, through a coupling device 230. In some embodiments, the coupling device 230 can be a wired device, such as a Universal Serial Bus (USB) cable, Ethernet cable, etc, or can represent a wireless link between the processing system 200 and the programmable system 100."); ((Mohammed, ¶23) " In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."); ((Mohammed, ¶41) " Referring to FIG. 4, the integrated development environment 300 can receive hardware description code 401, such as hardware description language code 402, state diagrams 403, hardware schematics 404, and flowcharts 405, which can describe hardware circuitry. The hardware circuitry can include one or more circuits to perform various application or functions and analog and/or digital signal routing associated with the circuits."). The programmable digital block of the programmable system may be configured for emulating various functions ((Mohammed, ¶30-31) " The programmable digital block 132 may include a digital logic array including an array of digital logic blocks and associated routing. In one embodiment, the digital block architecture is comprised ofUDBs (universal digital blocks). For example, each UDB may include an ALU together with CPLD functionality or other types of digital programmable logic functions. In various embodiments, one or more UDBs of the programmable digital block 132 may be configured to perform various digital functions, including, but not limited to, one or more of the following functions: a basic I2C slave; an I2C master; a SPI master or slave; a multi-wire (e.g., 3-wire) SPI master or slave (e.g., MISO/MOSI multiplexed on a single pin); timers and counters ( e.g., a pair of 8-bit timers or counters, one 16 bit timer or counter, one 8-bit capture timer, or the like); PWMs (e.g., a pair of 8-bit PWMs, one 16-bit PWM, one 8-bit deadband PWM, or the like), a level sensitive I/0 interrupt generator; a quadrature encoder, a UART ( e.g., half-duplex); delay lines; and any other suitable type of digital function or combination of digital functions which can be implemented in a plurality of UDBs."); ((Mohammed, ¶44) " The integrated development environment 300, in blocks 440 and 450, can perform placement and routing for both the programmable digital blocks 132 and the programmable analog blocks 134 of the programmable system 100. The placement and routing can determine where the hardware circuitry is to be placed in the programmable digital blocks 132 and the programmable analog blocks 134. The placement and routing can also allocate or set signal routing for the hardware circuitry placed in the programmable digital blocks 132 and the programmable analog blocks 134")., [[and wherein an ID chip on hardware, or hardware module equipped with ID, allows the hub portion and a debugger to obtain an ID of the ID chip and manifest file of each hardware component in the system.]]
While Mohammed does disclose the use of configuration files being transmitted through a coupling device (hub) as given above and further discloses the acquisition by a debugger of the device-specific configuration files for the components of the programmable system ((Mohammed, ¶40) " The compiler 350 can also provide the configuration files and the application programming interfaces to a debugger 360, such as the debug hardware 208. The debugger 360 can perform debugging operations on the programmable system 100 as configured with the configuration files and the application programming interfaces. For instance, the debugger 360 can perform step over, step into, and step out operations, which allows users the ability to perform incremental evaluations that step through programming code.");((Mohammed, ¶37) "In some embodiments, when the received descriptions of the hardware circuitry are in an abstracted or generic format, the code generator 330 can access a device-specific hardware mapping unit 340 to map the received descriptions of the hardware circuitry to the programmable digital and/or analog blocks 132 and 134 of the programmable system 100."), Mohammed does not explicitly suggest or disclose the utilization of an ID chip on hardware/ hardware module equipped with ID that allows the hub portion and the debugger to obtain an ID and a manifest file of each hardware component in the system. However, Kuehnis discloses and wherein an ID chip on hardware, or hardware module equipped with ID, PDIDs are used to describe system components in a SoC/debugging context ((Kuehnis, ¶40) " With an arbitrarily nested system as in FIG. 2, the following PDIDs in Table 1 may be used to identify the system components."). The system components may describe a trace source, which may be a hardware source ((Kuehnis, ¶2) " Modem processors such as system on chips (SoCs) often include several hardware trace sources, and users are adding their software (SW)/firmware (FW) traces to the same debug infrastructure."); ((Kuehnis, ¶27) " As used herein, a "trace" is a stream of data about system functionality and behavior of a target system, transported to a host system for analysis and display. In other cases, the trace can be self-hosted, in which the data is consumed in the system itself by a debug engine that decodes and potentially visualizes the data. A "trace source" is an entity inside the system that generates trace information using a defined protocol. A "platform description ID" (PDID) describes a (sub )system or part of it. A (sub )system could be a single trace source or another complex nested (sub)system. In turn, platform description metadata information translates the PDID into data to configure a debug component processing the given trace stream.") allows the hub portion and a debugger to obtain an ID of the ID chip and manifest file of each hardware component in the system. Trace messages from the trace source are provided to a debugger for decoding, wherein trace messages include the PDID as stated above, thereby indicating that the debugger obtains the ID ((Kuehnis, ¶39) " In the high level shown in FIG. 2, DTS 250 includes a debug and test controller 260, which may initiate test operations within SoC 210 and receive a trace stream therefrom. In turn, debug and test controller 260 may provide trace messages to debugger 280, which may decode the information
stored therein using one or more decoders present in one or more decoder books "). The decoding process of the debugger includes the coupling to a manifest file ((Kuehnis, ¶58) " Decoding process 800 may be executed by a debugger as present in a given debug and test system, which may be implemented with hardware circuitry, firmware, software and/or combinations thereof. In embodiments herein, a debugger 840 couples to a decoder table 850/manifest, which may be a hierarchical decoder structure as described herein "); See also Figure 8 depicting the manifest comprising each PDID of given trace streams. A coupling device (as a hub) is used to perform decoding of PDIDs ((Kuehnis, ¶123) " As further illustrated in FIG. 18, another device
that may couple to switch/bridge 1820 is a debug and test system 1828 to perform decoding using PDIDs to access decoder subsystems of (potentially) multiple decoder books present in a decoder 1829. ")
Kuehnis is analogous to the claimed invention because it is related to the same field of endeavor of hardware development systems used for debug and test purposes. It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have modified the system disclosed by Mohammed with the teachings of Kuehnis to include the utilization of hardware modules equipped with IDs that enable the debugger/hub to obtain such ID because some teaching, suggestion, or motivation in the prior art would have led one having skill in the art to do so in order to arrive at the claimed invention. Mohammed discloses the generation of configuration files from received descriptions of hardware in a design interface and further discloses a configuration of a programmable system according to the configuration files for use in debugging applications. Mohammed further states that the programmable system can be reconfigured and that debugging operations may be performed according to the programmable system configured with the configuration files. Kuehnis discloses a methodology for dynamic re-configuration of circuitry during debugging operations (See ¶32-33, 45) and leverages dynamic tracing as an enhanced debugging technique, wherein the hardware identifiers (PDIDs) are used in trace messages to inform the debugger. By modifying the disclosed debugger solution of Mohammed to include the dynamic tracing functionality as part of the debugger, as disclosed by Kuehnis, one having skill in the art would arrive at the claimed invention. One would be compelled to make such a change because Kuehnis suggests that employing tracing in debugging for a complex and dynamic system may yield more efficient debugging in the development of SoCs and systems implementing SoCs ((Kuehnis, ¶67) " With embodiments, tracing may be performed to efficiently enable decoding of traces from complex platforms. While in some cases it may not be possible to decode every single trace in a real dynamic system, as costs would be too high to have a unique 1:1 trace-to-decoder relationship. But with an embodiment having a tiered approach (root, stem, branch), efficient decoding of a dynamic system can be performed with reduced complexity, overhead, and bandwidth. Thus debugging may be performed more efficiently, realizing quicker identification of problems in a debugged system, and reducing time to market in development of SoCs and systems implementing such SoCs. "); ((Kuehnis, ¶25-26) " In various embodiments, a debug system is provided with techniques to provide a platform description composed out of an accumulation of descriptions (subsystem descriptions). This platform description identifier is used to describe arbitrary complex systems via support for indefinite deep nesting of subsystems and an arbitrary amount of subsystem descriptions. By way of the temporal nature of each description item, systems can be dynamically changed while maintaining debug capabilities. Such changes may include physical changes (e.g., plug/unplug components), changes due to power options (powering up or down of components), dynamically loading/unloading software/ firmware modules and code paging in microcontrollers, among others. With embodiments, a processor or other SoC can provide a more reliable and higher quality output to trace analysis tools. Embodiments reduce the risk of totally unusable data, by providing the ability to properly decode traces. And with embodiments, message content is reduced via the techniques described herein to reduce code density, especially as compared to use of a globally unique identifier (GUID) on every message. As such, embodiments realize higher code density and lower trace bandwidth requirements. ").
Regarding claim 13, the proposed combination discloses The method of claim 12, as stated previously and further discloses in view of Mohammed wherein the receiving an indication that a hardware device is installed in the system includes receiving a unique identifier of the hardware device. The annotation layer distinguishes what is contained (installed) in the device and not ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. "); ((Mohammed, ¶61) " Annotation elements may be designed with the existing tools for creating components, and a property (e.g., "annotation") of the object may be set to indicate that the component is to be placed in the annotation layer."). The annotation elements are uniquely identified by visual indicators of their nature (( Mohammed, ¶62) " FIG. 7 is an example screen shot showing the differentiation of annotation elements in a schematic generator, according to embodiments of the invention. Wires that connect to annotation hot spots may be forced to the annotation layer. Wires and other components with the annotation property may include a visual indication to indicate their nature. For example, internal components, such as wire 701 may be present in a default manner. Annotation elements ( e.g., representing external components), such as wire 702, however, may be present in a different manner. The annotation elements may have, for example, a different color, size, shape,weight, thickness, opacity or shading. They may be drawn using dashed or dotted lines. The visual indication may be any feature of the objects that distinguishes annotation objects from non-annotation objects ( or objects in one domain from objects in a different domain).");
Regarding claim 14, the proposed combination discloses The method of claim 12, as stated previously and further in view of Mohammed discloses wherein the receiving an indication that a hardware device is installed in the system includes receiving a manifest file describing capabilities and connections of a hardware device. The annotation layer of the schematic indicates what elements are within the system (indication of hardware installed in the system) for determining what is actually to be implemented in the design ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design."). Schematic diagrams are exemplary of hardware description code ((Mohammed, ¶23) "In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."). A configuration file (manifest file with capabilities and connections) is generated according to hardware description code ((Mohammed, ¶37) "The integrated development environment 300 can include a code generator 330 to generate configuration files from the received descriptions of the hardware circuitry").
Regarding claim 15, the proposed combination discloses The method of claim 12, as stated previously and further in view of Mohammed discloses wherein after receiving an indication that a hardware device is installed in the system, The annotation layer of the schematic is an indication of what is contained in the system ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design."); ((Mohammed, ¶65) " FIG. 9 is an example screen shot showing components in both a first domain and a second domain in a schematic generator, according to embodiments of the invention. In this embodiment, objects 810, 820 and 830 are illustrated as well as additional objects 940. The additional objects 940 are external objects that are part of the annotation layer. As illustrated, objects 810, 820 and 830 are drawn with darker solid lines, while additional objects 940 are drawn with lighter dotted lines. This visual indication signifies the differentiation between the device layer and the annotation layer."). the hardware device sends a manifest representing a function of the hardware device to the processing device for display to the user The addition of an annotation component of a hardware device into a schematic triggers the warning dialog indicating the function of the added element to a display of a window to a user ((Mohammed, ¶60) "FIG. 6 is an example screen shot showing a warning dialog for annotation elements in a schematic generator, according to embodiments of the invention. In one embodiment, the schematic designer interface 600 displays the objects or components used in the design. If one of the objects added to the design is designated as an annotation element ( e.g., because it represents an external component for the device being designed), a warning dialog 610 may be displayed. For example, the warning dialog 610 may include text indicating that the annotation element is a symbol for annotation purposes only and the corresponding component will not implement any function in the device schematic. If annotation layers are not currently enabled or no annotation layers currently exist, the warning dialog 610 may ask the user whether they wish to create or enable an annotation layer. If the user agrees, the schematic designer may add the annotation element to the design as part of the annotation layer (or some other defined domain). If the user does not agree, the schematic designer may not add the annotation element to the schematic."); ((Mohammed, ¶Abstract) "The method further includes assigning the graphical objects into one of an internal domain and an external domain and displaying, by the processing device, the graphical objects from both the internal domain and the external domain in a single view of the design interface")
Regarding claim 16, the proposed combination discloses The method of claim 12, as stated previously and further in view of Mohammed discloses wherein the graphical representation of the system is on a display screen. ((Mohammed, ¶73) " The computer system 1100 may further include a network interface device 1108. The computer system 1100 also may include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1112 ( e.g., a keyboard), a cursor control device 1114 (e.g., a mouse), and a signal generation device 1116 (e.g., a speaker)."). See also Figures 6-8 depicting graphical representations of a schematic for a system in the form of a screenshot ((Mohammed, ¶12-14) "FIG. 6 is an example screen shot showing a warning dialog for annotation elements in a schematic generator, according to embodiments of the invention. FIG. 7 is an example screen shot showing the differentiation of annotation elements in a schematic generator, according to embodiments of the invention. FIG. 8 is an example screen shot showing components in a first domain in a schematic generator, according to embodiments of the invention.")
Regarding claim 17, Mohammed discloses (except the limitations surrounded by brackets ([[..]])) A terminal comprising at least one processor; and at least one memory storing instruction(s) that, when executed by the at least one processor, cause the at least one processor to cause: ((Mohammed, ¶70) " FIG. 11 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 1100 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. "); ((Mohammed , ¶71) " The exemplary computer system 1100 includes a processing device 1102, a main memory 1104 ( e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 1106 ( e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1118, which communicate with each other via a bus 1130. ")
receiving an input from a user on a processing device, the input indicating a hardware device selected by the user; ((Mohammed, ¶22-23) " The processing system 200 can include system interface devices 206 that allow the processing system 200 to communicate with external devices, such as the user input device 210, the display device 220, and the programmable system 100. For example, the processing system 200 can include a system interface 206 to communicate with the programmable system 100 over the coupling device 230. In some embodiments, the system interface devices 206 can receive inputs, for example, through the user input device 210, and present information, for example, via the display device 220. [0023] The processing system 200 can develop hardware and software applications for the programmable system 100 in response to user input, for example, from the user input device 210. The integrated development environment 300 can include various development tools that allow system designers to describe hardware circuitry for the programmable system 100 to implement and to provide software or firmware code for the microcontroller 102. In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to to a hardware description language, such as Verilog or V HDL.")
receiving an indication that a hardware device is installed in a development system; ((Mohammed, ¶61) "Annotation elements may be designed with the existing tools for creating components, and a property (e.g., "annotation") of the object may be set to indicate that the component is to be placed in the annotation layer."); ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design.")
presenting a representation of the hardware device to the user on a display screen; ((Mohammed, ¶62) " FIG. 7 is an example screen shot showing the differentiation of annotation elements in a schematic generator, according to embodiments of the invention. Wires that connect to annotation hot spots may be forced to the annotation layer. Wires and other components with the annotation property may include a visual indication to indicate their nature. For example, internal components, such as wire 701 may be present in a default manner. Annotation elements ( e.g., representing external components), such as wire 702, however, may be present in a different manner. The annotation elements may have, for example, a different color, size, shape, weight, thickness, opacity or shading. They may be drawn using dashed or dotted lines. The visual indication may be any feature of the objects that distinguishes annotation objects from non-annotation objects ( or objects in one domain from objects in a different domain).")
providing the user with a graphical representation of the development system; ((Mohammed, ¶55) " One embodiment includes a method to place objects in a single schematic or diagram that represent components both internal and external to the device to be configured, and to automatically determine placement of those objects. The connection point or points between the internal and external objects may be automatically defined at a logical boundary")
providing the user on a screen, graphical representations of controls associated with the hardware device; and ((Mohammed, ¶Claim 9) " provide a graphical user interface for creating a circuit schematic to configure the programmable device;"); ((Mohammed, ¶68) " One advantage of the schematic designer described herein is that it lets the user visualize and configure the entire design, including the components that he may have little or no control over. Allowing external components to be placed and configured in the development tool, greatly improves design documentation and promotes system understanding.")
receiving an input from a user, the input is operative to control and debug the hardware device, ((Mohammed, ¶23) " The processing system 200 can develop hardware and software applications for the programmable system 100 in response to user input, for example, from the user input device 210. The integrated development environment 300 can include various development tools that allow system designers to describe hardware circuitry for the programmable system 100 to implement and to provide software or firmware code for the microcontroller 102. In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL"); ((Mohammed, ¶68) " One advantage of the schematic designer described herein is that it lets the user visualize and configure the entire design, including the components that he may have little or no control over. Allowing external components to be placed and configured in the development tool, greatly improves design documentation and promotes system understanding."); ((Mohammed, ¶35) "In some embodiments, the design editor 310 can access a database 320 to help determine dependency, build rules, and debug rules for the received descriptions of the hardware circuitry."); ((Mohammed, ¶40) "The debugger 360 can perform debugging operations on the programmable system 100 as configured with the configuration files and the application programming interfaces. For instance, the debugger 360 can perform step over, step into, and step out operations, which allows users the ability to perform incremental evaluations that step through programming code.") wherein the system is operative to emulate or change connections of the hardware device using a hub portion of the development system, A coupling device (as a hub of the system) is used to configure the programmable system (hardware device) according to configuration files that are derived from hardware description code that describes the circuitry/ routing of connections of components ((Mohammed, ¶21) " After hardware configuration files and software programming is developed, the processing system 200 can program and/or configure the programmable system 100 with the developed hardware configuration and software programming, for example, through a coupling device 230. In some embodiments, the coupling device 230 can be a wired device, such as a Universal Serial Bus (USB) cable, Ethernet cable, etc, or can represent a wireless link between the processing system 200 and the programmable system 100."); ((Mohammed, ¶23) " In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."); ((Mohammed, ¶41) " Referring to FIG. 4, the integrated development environment 300 can receive hardware description code 401, such as hardware description language code 402, state diagrams 403, hardware schematics 404, and flowcharts 405, which can describe hardware circuitry. The hardware circuitry can include one or more circuits to perform various application or functions and analog and/or digital signal routing associated with the circuits."). The programmable digital block of the programmable system may be configured for emulating various functions ((Mohammed, ¶30-31) " The programmable digital block 132 may include a digital logic array including an array of digital logic blocks and associated routing. In one embodiment, the digital block architecture is comprised ofUDBs (universal digital blocks). For example, each UDB may include an ALU together with CPLD functionality or other types of digital programmable logic functions. In various embodiments, one or more UDBs of the programmable digital block 132 may be configured to perform various digital functions, including, but not limited to, one or more of the following functions: a basic I2C slave; an I2C master; a SPI master or slave; a multi-wire (e.g., 3-wire) SPI master or slave (e.g., MISO/MOSI multiplexed on a single pin); timers and counters ( e.g., a pair of 8-bit timers or counters, one 16 bit timer or counter, one 8-bit capture timer, or the like); PWMs (e.g., a pair of 8-bit PWMs, one 16-bit PWM, one 8-bit deadband PWM, or the like), a level sensitive I/0 interrupt generator; a quadrature encoder, a UART ( e.g., half-duplex); delay lines; and any other suitable type of digital function or combination of digital functions which can be implemented in a plurality of UDBs."); ((Mohammed, ¶44) " The integrated development environment 300, in blocks 440 and 450, can perform placement and routing for both the programmable digital blocks 132 and the programmable analog blocks 134 of the programmable system 100. The placement and routing can determine where the hardware circuitry is to be placed in the programmable digital blocks 132 and the programmable analog blocks 134. The placement and routing can also allocate or set signal routing for the hardware circuitry placed in the programmable digital blocks 132 and the programmable analog blocks 134")., [[and wherein an ID chip on hardware, or hardware module equipped with ID, allows the hub portion and a debugger to obtain an ID of the ID chip and manifest file of each hardware component in the system.]]
While Mohammed does disclose the use of configuration files being transmitted through a coupling device (hub) as given above and further discloses the acquisition by a debugger of the device-specific configuration files for the components of the programmable system ((Mohammed, ¶40) " The compiler 350 can also provide the configuration files and the application programming interfaces to a debugger 360, such as the debug hardware 208. The debugger 360 can perform debugging operations on the programmable system 100 as configured with the configuration files and the application programming interfaces. For instance, the debugger 360 can perform step over, step into, and step out operations, which allows users the ability to perform incremental evaluations that step through programming code.");((Mohammed, ¶37) "In some embodiments, when the received descriptions of the hardware circuitry are in an abstracted or generic format, the code generator 330 can access a device-specific hardware mapping unit 340 to map the received descriptions of the hardware circuitry to the programmable digital and/or analog blocks 132 and 134 of the programmable system 100."), Mohammed does not explicitly suggest or disclose the utilization of an ID chip on hardware/ hardware module equipped with ID that allows the hub portion and the debugger to obtain an ID and a manifest file of each hardware component in the system. However, Kuehnis discloses and wherein an ID chip on hardware, or hardware module equipped with ID, PDIDs are used to describe system components in a SoC/debugging context ((Kuehnis, ¶40) " With an arbitrarily nested system as in FIG. 2, the following PDIDs in Table 1 may be used to identify the system components."). The system components may describe a trace source, which may be a hardware source ((Kuehnis, ¶2) " Modem processors such as system on chips (SoCs) often include several hardware trace sources, and users are adding their software (SW)/firmware (FW) traces to the same debug infrastructure."); ((Kuehnis, ¶27) " As used herein, a "trace" is a stream of data about system functionality and behavior of a target system, transported to a host system for analysis and display. In other cases, the trace can be self-hosted, in which the data is consumed in the system itself by a debug engine that decodes and potentially visualizes the data. A "trace source" is an entity inside the system that generates trace information using a defined protocol. A "platform description ID" (PDID) describes a (sub )system or part of it. A (sub )system could be a single trace source or another complex nested (sub)system. In turn, platform description metadata information translates the PDID into data to configure a debug component processing the given trace stream.") allows the hub portion and a debugger to obtain an ID of the ID chip and manifest file of each hardware component in the system. Trace messages from the trace source are provided to a debugger for decoding, wherein trace messages include the PDID as stated above, thereby indicating that the debugger obtains the ID ((Kuehnis, ¶39) " In the high level shown in FIG. 2, DTS 250 includes a debug and test controller 260, which may initiate test operations within SoC 210 and receive a trace stream therefrom. In turn, debug and test controller 260 may provide trace messages to debugger 280, which may decode the information
stored therein using one or more decoders present in one or more decoder books "). The decoding process of the debugger includes the coupling to a manifest file ((Kuehnis, ¶58) " Decoding process 800 may be executed by a debugger as present in a given debug and test system, which may be implemented with hardware circuitry, firmware, software and/or combinations thereof. In embodiments herein, a debugger 840 couples to a decoder table 850/manifest, which may be a hierarchical decoder structure as described herein "); See also Figure 8 depicting the manifest comprising each PDID of given trace streams. A coupling device (as a hub) is used to perform decoding of PDIDs ((Kuehnis, ¶123) " As further illustrated in FIG. 18, another device
that may couple to switch/bridge 1820 is a debug and test system 1828 to perform decoding using PDIDs to access decoder subsystems of (potentially) multiple decoder books present in a decoder 1829. ")
Kuehnis is analogous to the claimed invention because it is related to the same field of endeavor of hardware development systems used for debug and test purposes. It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have modified the system disclosed by Mohammed with the teachings of Kuehnis to include the utilization of hardware modules equipped with IDs that enable the debugger/hub to obtain such ID because some teaching, suggestion, or motivation in the prior art would have led one having skill in the art to do so in order to arrive at the claimed invention. Mohammed discloses the generation of configuration files from received descriptions of hardware in a design interface and further discloses a configuration of a programmable system according to the configuration files for use in debugging applications. Mohammed further states that the programmable system can be reconfigured and that debugging operations may be performed according to the programmable system configured with the configuration files. Kuehnis discloses a methodology for dynamic re-configuration of circuitry during debugging operations (See ¶32-33, 45) and leverages dynamic tracing as an enhanced debugging technique, wherein the hardware identifiers (PDIDs) are used in trace messages to inform the debugger. By modifying the disclosed debugger solution of Mohammed to include the dynamic tracing functionality as part of the debugger, as disclosed by Kuehnis, one having skill in the art would arrive at the claimed invention. One would be compelled to make such a change because Kuehnis suggests that employing tracing in debugging for a complex and dynamic system may yield more efficient debugging in the development of SoCs and systems implementing SoCs ((Kuehnis, ¶67) " With embodiments, tracing may be performed to efficiently enable decoding of traces from complex platforms. While in some cases it may not be possible to decode every single trace in a real dynamic system, as costs would be too high to have a unique 1:1 trace-to-decoder relationship. But with an embodiment having a tiered approach (root, stem, branch), efficient decoding of a dynamic system can be performed with reduced complexity, overhead, and bandwidth. Thus debugging may be performed more efficiently, realizing quicker identification of problems in a debugged system, and reducing time to market in development of SoCs and systems implementing such SoCs. "); ((Kuehnis, ¶25-26) " In various embodiments, a debug system is provided with techniques to provide a platform description composed out of an accumulation of descriptions (subsystem descriptions). This platform description identifier is used to describe arbitrary complex systems via support for indefinite deep nesting of subsystems and an arbitrary amount of subsystem descriptions. By way of the temporal nature of each description item, systems can be dynamically changed while maintaining debug capabilities. Such changes may include physical changes (e.g., plug/unplug components), changes due to power options (powering up or down of components), dynamically loading/unloading software/ firmware modules and code paging in microcontrollers, among others. With embodiments, a processor or other SoC can provide a more reliable and higher quality output to trace analysis tools. Embodiments reduce the risk of totally unusable data, by providing the ability to properly decode traces. And with embodiments, message content is reduced via the techniques described herein to reduce code density, especially as compared to use of a globally unique identifier (GUID) on every message. As such, embodiments realize higher code density and lower trace bandwidth requirements. ").
Regarding claim 18, the proposed combination discloses The terminal according to claim 17, as stated previously and further in view of Mohammed discloses wherein the receiving an indication that a hardware device is installed in the system includes receiving a unique identifier of the hardware device. The annotation layer distinguishes what is contained (installed) in the device and not ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. "); ((Mohammed, ¶61) " Annotation elements may be designed with the existing tools for creating components, and a property (e.g., "annotation") of the object may be set to indicate that the component is to be placed in the annotation layer."). The annotation elements are uniquely identified by visual indicators of their nature (( Mohammed, ¶62) " FIG. 7 is an example screen shot showing the differentiation of annotation elements in a schematic generator, according to embodiments of the invention. Wires that connect to annotation hot spots may be forced to the annotation layer. Wires and other components with the annotation property may include a visual indication to indicate their nature. For example, internal components, such as wire 701 may be present in a default manner. Annotation elements ( e.g., representing external components), such as wire 702, however, may be present in a different manner. The annotation elements may have, for example, a different color, size, shape,weight, thickness, opacity or shading. They may be drawn using dashed or dotted lines. The visual indication may be any feature of the objects that distinguishes annotation objects from non-annotation objects ( or objects in one domain from objects in a different domain).");
Regarding claim 19, the proposed combination discloses The terminal according to claim 17, as stated above and further in view of Mohammed discloses wherein the receiving an indication that a hardware device is installed in the system includes receiving a file associated with a configuration of the hardware device. The annotation layer of the schematic indicates what elements are within the system (indication of hardware installed in the system) for determining what is actually to be implemented in the design ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design."). Schematic diagrams are exemplary of hardware description code ((Mohammed, ¶23) "In some embodiments, the integrated development environment 300 can receive hardware description code that describes this hardware circuitry in an abstracted or generic manner, and can convert the generic code into device-specific configuration files that are particular to the architecture and/or resources of the programmable system 100. The hardware description code provided by the system designers can include schematic circuit diagrams and/ or hardware code written according to a hardware description language, such as Verilog or V HDL."). A configuration file is generated according to hardware description code ((Mohammed, ¶37) "The integrated development environment 300 can include a code generator 330 to generate configuration files from the received descriptions of the hardware circuitry").
Regarding claim 20, Mohammed discloses The terminal according to claim 17, as stated previously and further in view of Mohammed discloses wherein after receiving an indication that a hardware device is installed in the system, The annotation layer of the schematic is an indication of what is contained in the system ((Mohammed, ¶63) " In one embodiment, the annotation layer can be disabled to clearly indicate what elements are contained within the device and what elements are external. When the annotation layer is disabled, all the elements in the annotation layer may be removed from the displayed schematic and leave behind the creator components which are actually implemented in the PSoC design."); ((Mohammed, ¶65) " FIG. 9 is an example screen shot showing components in both a first domain and a second domain in a schematic generator, according to embodiments of the invention. In this embodiment, objects 810, 820 and 830 are illustrated as well as additional objects 940. The additional objects 940 are external objects that are part of the annotation layer. As illustrated, objects 810, 820 and 830 are drawn with darker solid lines, while additional objects 940 are drawn with lighter dotted lines. This visual indication signifies the differentiation between the device layer and the annotation layer."). the hardware device sends a manifest representing functions of the hardware device to a processing device for display to the user. The addition of an annotation component of a hardware device into a schematic triggers the warning dialog indicating the function of the added element to a display of a window to a user ((Mohammed, ¶60) "FIG. 6 is an example screen shot showing a warning dialog for annotation elements in a schematic generator, according to embodiments of the invention. In one embodiment, the schematic designer interface 600 displays the objects or components used in the design. If one of the objects added to the design is designated as an annotation element ( e.g., because it represents an external component for the device being designed), a warning dialog 610 may be displayed. For example, the warning dialog 610 may include text indicating that the annotation element is a symbol for annotation purposes only and the corresponding component will not implement any function in the device schematic. If annotation layers are not currently enabled or no annotation layers currently exist, the warning dialog 610 may ask the user whether they wish to create or enable an annotation layer. If the user agrees, the schematic designer may add the annotation element to the design as part of the annotation layer (or some other defined domain). If the user does not agree, the schematic designer may not add the annotation element to the schematic."); ((Mohammed, ¶Abstract) "The method further includes assigning the graphical objects into one of an internal domain and an external domain and displaying, by the processing device, the graphical objects from both the internal domain and the external domain in a single view of the design interface")
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 EMILY GORMAN LEATHERS whose telephone number is (571)272-1880. The examiner can normally be reached Monday-Friday, 9:00 am-5:00 pm ET.
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, EMERSON PUENTE can be reached at (571) 272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/E.G.L./Examiner, Art Unit 2187
/JOHN E JOHANSEN/Examiner, Art Unit 2187
Prosecution Insights