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 .
This Office Action is in response to the Amendment filed on 10/13/2025.
In instant Amendment, claims 1-20 have been amended; claims 1 and 12 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Final.
Response to Arguments
Applicant's arguments filed 10/13/2025 have been fully considered but they are not persuasive and/or moot in view of new grounds of rejection.
Applicant Argues: “...Bunia '985 does not teach an integrated circuit device having a scan chain that performs a scan test, key generation circuitry that generates a session key, a first encryption circuit that encrypts output scan data based on the session key, and a second that circuit that encrypts the session key based on a public key. In fact, Bunia '985 does not even teach encrypting the key bits. Bunia '985 simply teaches the "key bits are...encoded by key encoder 408." (Bunia '985, paragraph [0035], line 3).
Independent claim 12 is amended similar to claim 1. Independent claim 12 is thus patentable for reasons provided above with respect to amended claim 1, and further in view of additional features recited therein.”
Examiner’s Response: The examiner respectfully disagrees. Bhunia is shown to disclose the features of “an integrated circuit device having a scan chain that performs a scan test, key generation circuitry that generates a session key, a first encryption circuit that encrypts output scan data based on the session key”, see Bhunia [0028]-[0030] (i.e., rejection below). The examiner sought to combine Kandele tot each features of a second that circuit that encrypts the session key based on a public key, see [0015], which discusses a public key encryption module PKC_E 858 encrypting K to obtain encrypted session key KEnc, the encryption including at least one or more operations that include at least some public key cryptography method. Thus, Kandele teaches the features as argued relating to “encrypting the key”, which can be combined to Bhuna’s key. Motivation was cited for such a combination. Therefore, the examiner finds this argument not persuasive.
Applicant Argues: Further regarding amended claim 3, Bhunia '985 does not teach or suggest capturing output scan data based on a trigger event that includes one or more of a hardware fault in the integrated circuit device, a fault in a computer program executing on a processor of the integrated circuit device, an environmental condition, and a performance metric.
Examiner’s Response: This argument is moot in view of new grounds of rejection.
The examiner further notes the remaining dependent claim(s) contain arguments that amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Therefore, the examiner finds this argument not persuasive with respect to response provided above for Claim 1, and similar independent claim 12.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4, 6, 12, 15, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhunia et al. (US 2021/0391985 A1) in view of Kandele et al. (US 2023/0275742 A1).
Regarding Claim 1;
Bhunia discloses an integrated circuit device ([0028] - To remedy these and/or other security issues, various embodiments described herein relate to securing an IC by encrypting the input/output data of the IC.), comrpising:
a scan chain configured to perform a scan test and output scan data ([0030] - System 102 is also shown as including, in part, a multitude of boundary scan chain (BSC) cells 120. Encryption module 106 and key management unit 108 may be formed, for example, by modifying a JTAG block disposed in the system. As described further below, during a normal mode of operation, encryption module 106 together with key management unit 108, enable system 102 to operate in a secure manner by encrypting its input/output data. Signals TDI and TDO respectively represent the test data applied to and received from system 102);
key generation security configured to generate a session key ([0028]-[0029] - In one embodiment, the I/O level encryption may be provided through modification of a JTAG architecture. Furthermore, a key management system configured to generate and/or synchronize the keys... and [0055] – ...session key...);
a first encryption circuit configured to encrypt the output scan data based on the session key ([0028]-[0030] - As described further below, during a normal mode of operation, encryption module 106 together with key management unit 108, enable system 102 to operate in a secure manner by encrypting its input/output data and [0055] - Data bits supplied by BSC cells 1114, 1116, 1118 of sender IC 1110 are shown as being encoded using session key register 1125 bits K1, K2, K3, by XOR gates 1124, 1126 and 1128, respectively...).
Bhunia fails to explicitly disclose:
a second encryption circuit to encrypt the session key based on a public key.
However, in an analogous art, Kandele teaches a second encryption circuit to encrypt the session key based on a public key ([0115] - A process is now described in which Chiplet 800 (a first chiplet) generates a session key K and transmits K to a second chiplet for use by the second chiplet in performing encryption. Consistent with some embodiments, the chiplet 800 may perform the following steps with the indicated components: (1) key generation function (sender) 808 computing a session key K consistent with method 900 of FIG. 9 (discussed below), (2) the key generation function (sender) 808 sending K to key manager 806 of the TX Circuit 815, (3) the key manager 806 receiving K and further sending K to the Secure Host 104, (4) Secure Host 104 configured for receiving K and further sending K to public key cryptography (PKC) engine 805 with a request for encryption operation on K and for transmission to a second chiplet, (5) PKC engine 805 receiving and then sending K along with the public key of the second chiplet to public key encryption module PKC_E 858, (6) public key encryption module PKC_E 858 receiving K and public key of second chiplet, (7) public key encryption module PKC_E 858 encrypting K to obtain encrypted session key KEnc, the encryption including at least one or more operations that include at least some public key cryptography method, (8) public key encryption module PKC_E 858 further configured for sending KEnc to the PKC Engine 805, and (9) PKC engine 805 receiving key KEnc and transmitting KEnc to the second chiplet via the communication link 148 to bus controller 146 and then via communication link 154 to the communication bus 156 for delivery to the second chiplet).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Kandele to the circuit and session key of Bhunia to include a second encryption circuit to encrypt the session key based on a public key.
One would have been motivated to combine the teachings of Kandele to Bhunia to do so as it provides / allows to ensure that a received message does not have errors and has not been tampered with (Kandele, [0008]).
Regarding Claim 4;
Bhunia in view of Kandele disclose the device to claim 1.
Bhunia further discloses wherein the first encryption circuit is further configured to encrypt the output scan data based further on a symmetric encryption method (FIG. 3 and FIG. 4 and [0034]-[0035] - [0034] FIG. 4 shows a first IC 400 in communication with a second IC 450. IC 400 is shown as transmitting data received by IC 450. Data generated by core logic 402 of IC 400 is encrypted by encryption module 420 before being transmitted to IC 450. The encrypted data is received and decrypted by decryption module 470 before being supplied to core logic 452 of IC 450. JTAG block 430 is used for testing of IC 400 and for controlling the data that is shifted into the BSC cells (not shown in FIG. 4) of IC 400. Similarly, JTAG block 480 is used for testing of IC 450 and for controlling the data that is shifted into the BSC cells (not shown in FIG. 4) of IC 480 Key register 406 supplies the key bits that are used by encryption module 420 to encrypt data supplied by core logic 402. The key bits are also encoded by key encoder 408 and transmitted to TAP 468 of IC 450. TAP 468, in addition to other functions, delivers the encoded keys to key decoder 472 via TAP controller 466. The keys decoded by key decoder 472 are delivered to and stored in key register 456. Decryption module 470 decrypts the data it receives from encryption module 420 using the key bits supplied thereto by key register 456. In one embodiment, the decrypted data is delivered to a boundary scan chain. As described further below, in one embodiment, the data is encrypted using, for example, an XOR gate. In such embodiments, the XOR gate receives a data bit and a key bit to generate the encrypted output and [0036]).
Regarding Claim 6;
Bhunia and Kandele disclose the circuit to Claim 1.
Kandele further teaches wherein the second encryption circuit is configured to encrypt the session key based further on an asymmetric encryption method ([0115] A process is now described in which Chiplet 800 (a first chiplet) generates a session key K and transmits K to a second chiplet for use by the second chiplet in performing encryption. Consistent with some embodiments, the chiplet 800 may perform the following steps with the indicated components: (1) key generation function (sender) 808 computing a session key K consistent with method 900 of FIG. 9 (discussed below), (2) the key generation function (sender) 808 sending K to key manager 806 of the TX Circuit 815, (3) the key manager 806 receiving K and further sending K to the Secure Host 104, (4) Secure Host 104 configured for receiving K and further sending K to public key cryptography (PKC) engine 805 with a request for encryption operation on K and for transmission to a second chiplet, (5) PKC engine 805 receiving and then sending K along with the public key of the second chiplet to public key encryption module PKC_E 858, (6) public key encryption module PKC_E 858 receiving K and public key of second chiplet, (7) public key encryption module PKC_E 858 encrypting K to obtain encrypted session key KEnc, the encryption including at least one or more operations that include at least some public key cryptography method, (8) public key encryption module PKC_E 858 further configured for sending KEnc to the PKC Engine 805, and (9) PKC engine 805 receiving key KEnc and transmitting KEnc to the second chiplet via the communication link 148 to bus controller 146 and then via communication link 154 to the communication bus 156 for delivery to the second chiplet)..
Similar rationale and motivation is noted for the combination of Kandele to Bhunia and Kandele, as per Claim 1, above.
Regarding Claim(s) 12, 15 and 17; claim(s) 12, 15 and 17 is/are directed to a/an method
associated with the device claimed in claim(s) 1, 4 and 6. Claim(s) 12, 15 and 17 is/are similar in
scope to claim(s) 1, 4, and 6, and is/are therefore rejected under similar rationale.
Claim(s) 3 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhunia et al. (US 2021/0391985 A1) in view of Kandele et al. (US 2023/0275742 A1) and further in view of Schat et al. (US 10,853,485 B1)
Regarding Claim 3;
Bhunia in view of Kandele disclose the device to claim 1.
Bhunia in view of xxx in view of fail to explicitly disclose further comprising a scan controller configured to capture the output scan data based on a trigger event, wherein the trigger event comprises one or more of: a hardware fault in the integrated circuit device; a fault in a computer program executing on a processor of the integrated circuit device; an environmental condition; and a performance metric.
However, in an analogous art, Schat teaches further comprising a scan controller configured to capture the output scan data based on a trigger event, wherein the trigger event comprises one or more of: a hardware fault in the integrated circuit device; a fault in a computer program executing on a processor of the integrated circuit device; an environmental condition; and a performance metric (col. 3, lines 9-28 - A scan test involves loading input scan data into one or more scan chains (also referred to as a “scan shift register”), using the input scan data to test logic in the device-under-test (DUT), loading the scan chain with output scan data from the logic of the DUT, reading out the output scan data from the scan chain, and analyzing the output scan data to determine whether the DUT has passed or failed the test).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Schat to the device and of Bhunia in view of Kandele to include further comprising a scan controller configured to capture the output scan data based on a trigger event, wherein the trigger event comprises one or more of: a hardware fault in the integrated circuit device; a fault in a computer program executing on a processor of the integrated circuit device; an environmental condition; and a performance metric
One would have been motivated to combine the teachings of Schat to Bhunia and Poeluev and to do so as it provides / allows sufficient test coverage and/or a deterministic scan test during the integrated circuit (IC) lifetime as it can be beneficial (Schat, col. 1, lines 43-53).
Regarding Claim(s) 14; claim(s) 14 is/are directed to a/an method associated with the device claimed in claim(s) 3. Claim(s) 14 is/are similar in scope to claim(s) 3, and is/are therefore rejected under similar rationale.
Claim(s) 5, 9, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhunia et al. (US 2021/0391985 A1) in view of Kandele et al. (US 2023/0275742 A1) and further in view of Poeluev (US 2013/0086385 A1).
Regarding Claim 5;
Bhunia in view of Kandele disclose the device to claim 1.
Bhunia further discloses a scan controller configured to capture the output scan data; and ... cause the scan controller to capture the output scan data .... ([0030] - System 102 is also shown as including, in part, a multitude of boundary scan chain (BSC) cells 120. Encryption module 106 and key management unit 108 may be formed, for example, by modifying a JTAG block disposed in the system. As described further below, during a normal mode of operation, encryption module 106 together with key management unit 108, enable system 102 to operate in a secure manner by encrypting its input/output data. Signals TDI and TDO respectively represent the test data applied to and received from system 102)
Bhunia in view of Kandele fails to explicitly disclose ...a root of trust circuity configured to cause the scan controller to ...based on an external control.
However, in an analogous art, Poeluev teaches further a root of trust circuity configured to cause the scan controller to [scan] based on an external control.([0030] - In FIG. 3, the ACC 110 is a small hardware core embedded in a target system-on-chip (SoC) that establishes a hardware-based point of trust on the silicon die. The ACC 110 can be considered a root of trust on the consumer device 104 as it comprises tamper proof features that provide physical protection to sensitive data and methods to provide remote attestation and verification... Although embedded as such, the ACC 110 can continue to serve as a root of trust on the PCB 344 and/or the final device 104 and [0033] - The agent 220 comprises a transport layer API with which the appliance 218 may be used to issue commands and receive responses to/from the ACC 110. Secure operations performed by the appliance 218 may be performed within the HSM 219. The tester 216 or device programmer 226 can be physically connected to the chip through the standard JTAG IEEE 1 149 test ports (e.g., test interface 46 and connection 228), or another programming interface depending on the application).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Poeluev to the scan controller and of Bhunia in view of Kandele to include ...a root of trust circuity configured to cause the scan controller to ...based on an external control.
One would have been motivated to combine the teachings of Poeluev to Bhunia in view of Kandele to do so as it provides / allows distribution and collection of proprietary and sensitive data such as feature provisioning commands, content protection key data, software/firmware code images, test results and yield reporting data (Poeluev, [0004]).
Regarding Claim 9;
Bhunia in view of Kandele disclose the device to claim 1.
Bhunia in view of Kandele fails to explicitly disclose further comprising root-of-trust (RoT) circuitry configured to signal encrypted-scan-dump-mode-on in response to an instruction from an external scan controller; and a control circuit coupled to the RoT circuitry and configured to disable an input pin of the integrated circuit device in response to the signaled encrypted-scan-dump-mode-on.
However, in an analogous art, Poeluev teaches further comprising root-of-trust (RoT) circuitry coupled to the TAP and configured to signal encrypted-scan-dump-mode-on in response to an instruction from an external scan controller ([0030] - In FIG. 3, the ACC 110 is a small hardware core embedded in a target system-on-chip (SoC) that establishes a hardware-based point of trust on the silicon die. The ACC 110 can be considered a root of trust on the consumer device 104 as it comprises tamper proof features that provide physical protection to sensitive data and methods to provide remote attestation and verification... Although embedded as such, the ACC 110 can continue to serve as a root of trust on the PCB 344 and/or the final device 104 and [0033] - The agent 220 comprises a transport layer API with which the appliance 218 may be used to issue commands and receive responses to/from the ACC 110. Secure operations performed by the appliance 218 may be performed within the HSM 219. The tester 216 or device programmer 226 can be physically connected to the chip through the standard JTAG IEEE 1 149 test ports (e.g., test interface 46 and connection 228), or another programming interface depending on the application and [0046] - The ACC 110 and appliance 218 can be configured in various ways to suit a particular environment. ... Enablement/disablement of scan chain testing of the ACC 110 should be available prior to ACC key pair generation to prevent the private key from being revealed. ... the ACC 110 should be encrypted for confidentiality and features may be enabled and disabled via FCTs 250 provided to the ACC 110 and [0061] - All ACC 110 DFT features are controlled by the ACCs own TAP controller 472 and, as such, the hardware should be designed so that the DFT features can be enabled and disabled based on the state of the ACC 110.); and a control circuit coupled to the RoT circuitry and configured to disable an input pin of the integrated circuit device in response to the signaled encrypted-scan-dump-mode-on ([0030] - In FIG. 3, the ACC 110 is a small hardware core embedded in a target system-on-chip (SoC) that establishes a hardware-based point of trust on the silicon die. The ACC 110 can be considered a root of trust on the consumer device 104 as it comprises tamper proof features that provide physical protection to sensitive data and methods to provide remote attestation and verification... Although embedded as such, the ACC 110 can continue to serve as a root of trust on the PCB 344 and/or the final device 104 and [0033] - The agent 220 comprises a transport layer API with which the appliance 218 may be used to issue commands and receive responses to/from the ACC 110. Secure operations performed by the appliance 218 may be performed within the HSM 219. The tester 216 or device programmer 226 can be physically connected to the chip through the standard JTAG IEEE 1 149 test ports (e.g., test interface 46 and connection 228), or another programming interface depending on the application and [0046] -The ACC 110 and appliance 218 can be configured in various ways to suit a particular environment. ...Enablement/disablement of scan chain testing of the ACC 110 should be available prior to ACC key pair generation to prevent the private key from being revealed. ... the ACC 110 should be encrypted for confidentiality and features may be enabled and disabled via FCTs 250 provided to the ACC 110 and [0056] - In some implementations, there is one enable signal detected over the enablement controller and interface 474 per feature item that would need to be enabled or disabled).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Poeluev to the device and of Bhunia in view of Kandele to include further comprising root-of-trust (RoT) circuitry configured to signal encrypted-scan-dump-mode-on in response to an instruction from an external scan controller; and a control circuit coupled to the RoT circuitry and configured to disable an input pin of the integrated circuit device in response to the signaled encrypted-scan-dump-mode-on.
One would have been motivated to combine the teachings of Poeluev to Bhunia in view of Kandele to do so as it provides / allows distribution and collection of proprietary and sensitive data such as feature provisioning commands, content protection key data, software/firmware code images, test results and yield reporting data (Poeluev, [0004]).
Regarding Claim(s) 16; claim(s) 16 is/are directed to a/an method associated with the device claimed in claim(s) 5. Claim(s) 16 is/are similar in scope to claim(s) 5, and is/are therefore rejected under similar rationale.
Claim(s) 7, 8, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhunia et al. (US 2021/0391985 A1) in view of Kandele et al. (US 2023/0275742 A1) and further in view of Narayanan et al. (US 2022/0358230 A1).
Regarding Claim 7;
Bhunia in view of Kandele discloses the circuit to Claim 1.
Kandele further teaches the public key comprises a public key... if the integrated circuit device ([0061] - In some embodiments, the pair of chiplets are part of numerous chiplets, and corresponding communication links, in a package and [0115] - A process is now described in which Chiplet 800 (a first chiplet) generates a session key K and transmits K to a second chiplet for use by the second chiplet in performing encryption. Consistent with some embodiments, the chiplet 800 may perform the following steps with the indicated components: (1) key generation function (sender) 808 computing a session key K consistent with method 900 of FIG. 9 (discussed below), (2) the key generation function (sender) 808 sending K to key manager 806 of the TX Circuit 815, (3) the key manager 806 receiving K and further sending K to the Secure Host 104, (4) Secure Host 104 configured for receiving K and further sending K to public key cryptography (PKC) engine 805 with a request for encryption operation on K and for transmission to a second chiplet, (5) PKC engine 805 receiving and then sending K along with the public key of the second chiplet to public key encryption module PKC_E 858, (6) public key encryption module PKC_E 858 receiving K and public key of second chiplet, (7) public key encryption module PKC_E 858 encrypting K to obtain encrypted session key KEnc, the encryption including at least one or more operations that include at least some public key cryptography method, (8) public key encryption module PKC_E 858 further configured for sending KEnc to the PKC Engine 805, and (9) PKC engine 805 receiving key KEnc and transmitting KEnc to the second chiplet via the communication link 148 to bus controller 146 and then via communication link 154 to the communication bus 156 for delivery to the second chiplet).).
Similar rationale and motivation is noted for the combination of Kandele to Bhunia in view of Kandele, as per claim 9, above.
Bhunia in view of Kandele fail to explicitly disclose a... key of a manufacturer of the integrated circuit device, the... key is stored in one-time-programmable memory of the integrated circuit device.
However, in an analogous art, Narayanan teaches a... key of a manufacturer of the integrated circuit device, the... key is stored in one-time-programmable memory of the integrated circuit device ([0017] – ... secure RAM, secure key registers... [0033] - In the illustrated example of FIG. 2, the example secure data storage 202 includes an example secure read-only-memory (ROM) 204, an example secure random access memory (RAM) 206, and example secure registers 208... For example, the secure data may include program instructions (e.g., stored in the secure ROM 204) used to operate an operating system or other critical application of the computing system 102, decrypted data (e.g., decrypted by a cryptography processor of the computing system 102) stored in the secure RAM 206, encryption keys (e.g., customer keys, manufacturer keys, etc.) stored in the secure registers 208, etc.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Narayanan to the device and of Bhunia in view of Kandele to include disclose a... key of a manufacturer of the integrated circuit device, the... key is stored in one-time-programmable memory of the integrated circuit device.
One would have been motivated to combine the teachings of Narayanan to Bhunia in view of Kandele to do so as it provides / allows to use scan operations to protect secure assets (Narayanan, [0014]).
Regarding Claim 8;
Bhunia in view of Kandele and Narayanan discloses the circuit to Claim 7.
Narayanan further teaches wherein the scan chain is further configured to perform the scan test in-field without coordination a manufacturer of the integrated circuit based on the public key of the manufacture ([0013] - A computing system that includes a SoC device may store various types of secure data, such as secure program instructions of an operating system, decrypted user information stored in a volatile memory, encryption keys stored in key registers, etc. When a test scan operation is performed using a test circuit (e.g., scan chain) in the SoC device, some of this secure data may be shifted out of the SoC as part of the output of the test circuit and [0033] - manufacturer keys... and [0040] - For example, when the SoC device 200 is operating in a test mode, the example test interface 220 may receive a test pattern from an external system (e.g., automated test equipment (ATE) system, etc.) at input port 226, and transmit the test pattern (or an indication thereof) for receipt at the input 212a of the scan chain 212 (and/or at an input of the scan chain 214, etc.).
Similar rationale and motivation is noted for the combination of Narayanan to Bhunia in view of Kandele and Narayanan, as per claim 9, above.
Regarding Claim(s) 18 and 19; claim(s) 18 and 19 is/are directed to a/an method associated with the device claimed in claim(s) 7 and 8. Claim(s) 18 and 19 is/are similar in scope to claim(s) 7 and 8, and is/are therefore rejected under similar rationale.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhunia et al. (US 2021/0391985 A1) in view of Kandele et al. (US 2023/0275742 A1) and Poeluev (US 2013/0086385 A1) and further in view of Whetsel (US 2002/0010887 A1).
Regarding Claim 11;
Bhunia in view of Kandele and Poeluev discloses the circuit to Claim 9.
Bhunia further discloses ...wherein the first encryption circuit is configured to encrypt data (FIG. 1 and FIG. 2 and FIG. 3 – JTAG and FIG. 4 and [0029]-[0030] - Encryption module ... and key management unit ... may be formed, for example, by modifying a JTAG block disposed in the system. As described further below, during a normal mode of operation, encryption module ... together with key management unit ..., enable system ... to operate in a secure manner by encrypting its input/output data and [0032] - Encryption module 106 and key management unit 108 may be formed, for example, by modifying a JTAG block disposed in the system. As described further below, during a normal mode of operation, encryption module 106 together with key management unit 108, enable system 102 to operate in a secure manner by encrypting its input/output data and [0033] - Encryption module 306 together with BSC s 308 provides run-time encryption with low computing cost. Key management unit 310 is adapted to manage the generation, synchronization, and storage of keys. A TAP controller may be used to communicate key bits as described further below and [0036] - As seen from FIGS. 3 and 4, in accordance with one aspect of the present disclosure, an encryption module/layer is disposed between the core (application) logic and the I/O pins. In one embodiment, this is accomplished by including additional circuitry to a boundary scan chain. Adding an encryption module to the scan chain enables a user/designer to perform run-time encryption with low computing cost).
Poeluev further teaches ... in response to the signaled encrypted-scan-dump-mode-on ([0030] - In FIG. 3, the ACC 110 is a small hardware core embedded in a target system-on-chip (SoC) that establishes a hardware-based point of trust on the silicon die. The ACC 110 can be considered a root of trust on the consumer device 104 as it comprises tamper proof features that provide physical protection to sensitive data and methods to provide remote attestation and verification... Although embedded as such, the ACC 110 can continue to serve as a root of trust on the PCB 344 and/or the final device 104 and [0033] - The agent 220 comprises a transport layer API with which the appliance 218 may be used to issue commands and receive responses to/from the ACC 110. Secure operations performed by the appliance 218 may be performed within the HSM 219. The tester 216 or device programmer 226 can be physically connected to the chip through the standard JTAG IEEE 1 149 test ports (e.g., test interface 46 and connection 228), or another programming interface depending on the application and [0046] -The ACC 110 and appliance 218 can be configured in various ways to suit a particular environment. ... Enablement/disablement of scan chain testing of the ACC 110 should be available prior to ACC key pair generation to prevent the private key from being revealed. ... the ACC 110 should be encrypted for confidentiality and features may be enabled and disabled via FCTs 250 provided to the ACC 110).
Similar rationale and motivation is noted for the combination of Poeluev to Bhunia in view of Kandele and Poeluev , as per claim 9, above.
Bhunia in view of Kandele and Poeluev fails to explicitly disclose further comprising: a secure test data register (TDR) coupled to the scan chain wherein the control circuit is further configured to enable access to the TDR... [and] ... data from the TDR register.
However, in an analogous art, Whetsel further teaches further comprising: a secure test data register (TDR) coupled to the scan chain wherein the control circuit is configured to enable access to the TDR... [and] ... data from the TDR register ([0005]-[0006] .... Instructions scanned into the instruction register of the TAP are used to connect the TAP up to a selected test data register(s), i.e. the boundary scan register and/or internal test data registers, so that serial test data can be input and output to the register to effectuate a given test or other type of operation. For example; when the Extest instruction is loaded into the instruction register, the TAP selects and connects up to the boundary scan register via its serial input 15, serial output 13, and control signals 17. Once connected, the TAP responds to the external test port signal pins of the IC to output control to the boundary scan register to communicate test data to the boundary scan register to execute interconnect testing. Similarly, other instructions can be loaded that allow the TAP to select and connect up to other test data registers so that other types of operations such as; internal scan testing, built in self test triggering (1149.1 Runbist instruction), or IC serial bypassing (1149.1 Bypass instruction), can be performed).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Whetsel to the device and of Bhunia in view of Kandele and Poeluev to include further comprising: a secure test data register (TDR) coupled to the scan chain wherein the control circuit is configured to enable access to the TDR... [and] ... data from the TDR register for output from the SoC.
One would have been motivated to combine the teachings of Whetsel to Bhunia in view of Kandele and Poeluev and to do so as it provides / allows core design that efficiently supports a user-added scan register option (Whetsel, [0001]).
Allowable Subject Matter
Upon review of the evidence at hand, it is hereby concluded that the evidence obtained and made of record, alone or in combination, neither anticipates, reasonably teaches, nor renders obvious the below noted features of applicant’s invention as the noted features amount to more than a predictable use of elements in the prior art.
Regarding Claim 2, and similar representative claim 13; the prior art of record as cited within this Office Action, nor those cited, in the additional references cited , alone or in combination, neither anticipates, reasonably teaches, nor renders obvious “further comprising a control circuit to disable an input pin of the integrated circuit during encryption of the output scan by the first encryption circuit and during outputting of the of the encrypted output scan data from the integrated circuit device.”
Regarding Claim 10, and similar representative claim 20, the prior art of record as cited within this Office Action, nor those cited, in the additional references cited , alone or in combination, neither anticipates, reasonably teaches, nor renders obvious “A scan dump controller configured to provide scan control signals to initiate the scan test based on a control from the RoT circuitry; and wherein the control circuit is further configured to select scan control signals from the scan dump controller in place of external controls a, in response to the signaled encrypted-scan-dump-mode-on.”
Thus, claim 2, 10, 13, and 20 are being objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims; however as allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892 attached.
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 KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
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, Luu Pham can be reached at (571)270-5002. 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.
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439