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 .
A preliminary amendment to the claims was received on 09/26/2023 and is acknowledged by the Office. Claims 3, 5-12, and 14-15 are currently amended. Claims 16-20 are newly added. Claims 1-20 remain pending.
Priority
The instant application 18/552,602 is a 371 of PCT application PCT/US2022/071604, which claims priority to provisional application 63/173,221, which claims the priority filing date of 04/09/2021. Therefore, the effective filing date of the instant application 18/552,602 is 04/09/2021.
Oath/Declaration
Applicant’s oath/declaration filed on 09/26/2023 has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 09/26/2023, 01/10/2024, 05/30/2024, 08/02/2024, 11/27/2024, and 04/07/2025, respectively, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings submitted on 09/26/2023 with the instant application are acceptable for examination purposes.
Specification
The specification submitted on 09/26/2023 with the instant application are acceptable for examination purposes.
Claim Objections
Claim 2, 7, and 16 are objected to because of the following informalities:
In both Claims 2 and 16, the limitation recites “the response message comprises a response message with a second payload …”, which is suggested to better re-phrased as “the response message comprises a reply message with a second payload …” instead to distinguish the separate recitations of “response message”.
In line 4-5 of Claim 7, the limitation, “is configured to: to generate ECC bits or cyclic redundancy check (CRC) for the first data of the request message”, should read as: “is configured to: bits for the first data of the request message”.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2, 5-6, 8-10, 12, 14, 15-16, and 19-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Hoermaier et al. (US 20210006353 A1), hereinafter Hoermaier.
Regarding Claim 1:
Hoermaier teaches a method implemented by a host of a system for secure communication with at least one destination (Hoermaier – Paragraph [0002]: The present invention relates generally to a system and method for data transmission and, in particular embodiments, to a system and method for transferring data and a data check field; and Paragraph [0023]: The master device may verify both the integrity of the data and the decoded address by verifying the checksum according to the received data and the locally stored version of the expected decoded address. Similarly, the integrity of a write operation may be verified by the slave device by generating checksum based on written data and decoded address and comparing the generated checksum to a checksum received from the master device) coupled to the host by an interconnect (Hoermaier – Paragraph [0020]: The present invention will be described with respect to preferred embodiments in specific contexts, such as systems and methods for transmitting data in a battery monitoring application, a SPI bus, and a bus master-based data transmission system. The invention, however, may also be applied to other types of data transmission systems), the method comprising:
generating a request message for a destination of the at least one destination (Hoermaier – Paragraph [0062]: For full-duplex SPI data transfers, a transmit data word (data from master SPI device 502 to slave SPI device 504) and a receive data word (data from slave SPI device 504 to master SPI device 502) may be transferred in parallel. A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word). A transmit data word may also include a read request indicating from which address in slave SPI device 504 (or which particular slave device for embodiments that include multiple slave devices) master SPI device 502 wants to read data. The read data is transferred to master SPI device 502 with an SPI transfer that follows the read request. This may occur in the immediately following SPI transfer, or in a later SPI transfer; and Paragraph [0072]: In various embodiments, read type indicator 546 is used to by master SPI device 502 to request read data from slave SPI device 504, while write type indicator 548 is used by master SPI device 502 to write data to slave SPI device 504. For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); generating first integrity bits for first data of the request message (Hoermaier – Paragraph [0072]: For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); inserting the first integrity bits in the request message (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits); transmitting, through the interconnect, the request message that includes the first data and the first integrity bits to the destination (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits; and Paragraph [0059]: FIG. 5A illustrates a block diagram of an embodiment SPI bus system 500 that utilizes embodiment systems and methods of embedding sideband information in data transmissions. As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line; and Paragraph [0072]: In various embodiments, read type indicator 546 is used to by master SPI device 502 to request read data from slave SPI device 504, while write type indicator 548 is used by master SPI device 502 to write data to slave SPI device 504. For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); receiving, through the interconnect, a response message from the destination (Hoermaier – Paragraph [0059]: FIG. 5A illustrates a block diagram of an embodiment SPI bus system 500 that utilizes embodiment systems and methods of embedding sideband information in data transmissions. As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line; and Paragraph [0073]: FIG. 5C illustrates data frame 560 that can be transferred from slave SPI device 504 to master SPI device 502. As shown, data frame 560 includes first read data word 552, second read data word 554, third read data word 556 which may include, for example, data requested by master SPI device 502); extracting second integrity bits from the response message (Hoermaier – Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558 and the previously transmitted (and therefore locally stored) read type indicator 546 and write type indicator 548 according to embodiment systems and methods described above); verifying integrity of second data of the response message based on the second integrity bits (Hoermaier – Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558); and consuming the second data of the response message in response to verifying the integrity of the second data of the response message (Hoermaier – Paragraph [0060]: As shown, master SPI device 502 includes transmit register 514 coupled to the transmit data line, receive register 516 coupled to the receive data line, and a baud rate and chip select generator 518 coupled to the shift clock and the chip select line. Baud rate and chip select generator 518 may be designed, for example, to implement and facilitate SPI data transfers using SPI systems and methods known in the art. Transmit buffer 512 is coupled to transmit register 514 such that data in transmit buffer 512 is transmitted over the transmit data line via transmit register 514, and receive buffer 510 is coupled to receive register 516 such that data received from the receive data line is transferred to receive buffer 510. Checksum verification block 530 verifies the validity of the data received from the receive data line using embodiment systems and methods described herein; Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558; and Paragraph [0075]: These internal protection mechanisms facilitate error detection if a transfer of data between two locations inside the μC is corrupted. Thus, if a data transfer is found to be corrupted, the corrupted data may be discarded and execution avoided).
Regarding Claim 2:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein: the request message comprises a command message with a first payload that comprises the first data; or the response message comprises a response message with a second payload that comprises the second data (Hoermaier – Paragraph [0062]: For full-duplex SPI data transfers, a transmit data word (data from master SPI device 502 to slave SPI device 504) and a receive data word (data from slave SPI device 504 to master SPI device 502) may be transferred in parallel. A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word). A transmit data word may also include a read request indicating from which address in slave SPI device 504 (or which particular slave device for embodiments that include multiple slave devices) master SPI device 502 device wants to read data. The read data is transferred to master SPI device 502 with an SPI transfer that follows the read request. This may occur in the immediately following SPI transfer, or in a later SPI transfer).
Regarding Claim 5:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein: the second integrity bits of the response message comprise the first integrity bits of the request message that are generated by the host; or the second integrity bits of the response message comprise integrity bits generated by the destination (Hoermaier – Figure 5C – data frame transferred from slave to master device; and Paragraph [0073]: FIG. 5C illustrates data frame 560 that can be transferred from slave SPI device 504 to master SPI device 502. As shown, data frame 560 includes first read data word 552, second read data word 554, third read data word 556 which may include, for example, data requested by master SPI device 502. Data frame 560 also includes CRC 558 that is generated by checksum generator 528 based on bits 8-63 in data frame 560 as well as additional sideband information according to embodiments of the present invention).
Regarding Claim 6:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein the destination comprises a memory that is configured to store the first integrity bits with the first data of the request message (Hoermaier – Paragraph [0061]: Slave SPI device 504 includes receive register 522 coupled to the transmit data line, transmit register 524 coupled to the receive data line; and Paragraph [0062]: A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word); and Paragraph [0064]: As an example of the operation of SPI bus system 500, a sequence of four read requests is stored in transmit buffer 512 and sent to slave SPI device 504 via transmit register 514 and the transmit data line. For safety and verification reasons, these data transfers are end-to-end protected (e.g. by a checksum included in a transmit data word). Slave SPI device 504 may be configured to verify the transmitted data using the checksum and to discard the transmitted data if the checksum does not match).
Regarding Claim 8:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein the first integrity bits of the request message or the second integrity bits of the response message comprise one of: parity bits determined based on the respective data of the request message or the response message; ECC bits determined based on the respective data of the request message or the response message; or CRC bits determined based on the respective data of the request message or the response message (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits; and Paragraph [0072]: Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535; and Paragraph [0073]: Data frame 560 also includes CRC 558 that is generated by checksum generator 528 based on bits 8-63 in data frame 560).
Regarding Claim 9:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein: the request message comprises an address of the destination, the first data comprising plaintext bits, and the first integrity bits that correspond to the first data of the request message; or the response message comprises an acknowledgement to the host; the second data comprising plaintext bits, and the second integrity bits that correspond to the second data of the response (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits; and Paragraph [0071]: FIGS. 5B and 5C illustrate example data frames that can be exchanged between master SPI device 502 and slave SPI device 504. These data frames operate according to an SPI protocol with 32 bits per SPI word and 2 SPI words per data frame. However, other frame types could be used in alternative embodiments. FIG. 5B illustrates a data frame 535 that can be transferred from master SPI device 502 to slave SPI device 504. As shown data frame 535 includes 64 bits that comprise a first write data word 540, a second write data word 542, a third write data word 544, a read type indicator 546, a write type indicator 548 and a CRC 550; and Paragraph [0072]: In some embodiments, the write type indicator can be interpreted as write request to a given write address or set of write addresses, whereas the read indicator can be seen as a read request from a given read address or set of read addresses. The given address(es) may be comprised in the indicators).
Regarding Claim 10:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein the interconnect that couples the host to the at least one destination comprises one of a fabric, a bus, a link, or one or more communication channels (Hoermaier – Paragraph [0059]: FIG. 5A illustrates a block diagram of an embodiment SPI bus system 500 that utilizes embodiment systems and methods of embedding sideband information in data transmissions. As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line).
Regarding Claim 12:
Hoermaier teaches the method of claim 1.
Hoermaier further teaches wherein the response message is a first response message, the method further comprising: receiving, through the interconnect, a second response message from the destination or another of the at least one destination (Hoermaier – Paragraph [0064]: As an example of the operation of SPI bus system 500, a sequence of four read requests is stored in transmit buffer 512 and sent to slave SPI device 504 via transmit register 514 and the transmit data line. For safety and verification reasons, these data transfers are end-to-end protected (e.g. by a checksum included in a transmit data word). Slave SPI device 504 may be configured to verify the transmitted data using the checksum and to discard the transmitted data if the checksum does not match; and Paragraph [0065]: Assuming that the first read request is correctly received and answered by slave SPI device 504, the transfer of the first read request leads to a first frame of receive data to be stored in the master device because SPI bus system 500 operates using full-duplex operation. However, this first frame of received data may be related to a formerly transferred transmit data word or read request. Thus, the read data requested by first request may be received in the second frame of receive data in receive buffer 510 of master SPI device 502 at the same time that master SPI device 502 issues a second read request); extracting third integrity bits from the second response message; failing to verify integrity of third data of the second response message based on the third integrity bits; and discarding the third data of the second response message in response to failing to verify the integrity of the third data of the second response message (Hoermaier – Paragraph [0066]: Assuming that one data transfer of received SPI data from receive buffer 510 is found corrupted and discarded (data will not arrive in memory 503) and that subsequent data transfers are executed correctly, there will be one read data set missing in the memory; and Paragraph [0060]: receive buffer 510 is coupled to receive register 516 such that data received from the receive data line is transferred to receive buffer 510. Checksum verification block 530 verifies the validity of the data received from the receive data line using embodiment systems and methods described herein).
Regarding Claim 14:
Hoermaier teaches the method of claim 12.
Hoermaier further teaches further comprising, in response to failing to verify the third data of the second response message, engaging security countermeasures of the system that include at least one of: erasing contents of one or more memories of the system; erasing one or more encryption keys of the system; resetting an entropy generation network of the system; altering a security state of the system; or altering a power state of the system (Hoermaier – Paragraph [0066]: Assuming that one data transfer of received SPI data from receive buffer 510 is found corrupted and discarded (data will not arrive in memory 503) and that subsequent data transfers are executed correctly, there will be one read data set missing in the memory; and Paragraph [0060]: receive buffer 510 is coupled to receive register 516 such that data received from the receive data line is transferred to receive buffer 510. Checksum verification block 530 verifies the validity of the data received from the receive data line using embodiment systems and methods described herein).
Regarding Claim 15:
Hoermaier teaches an integrated circuit (Hoermaier – Paragraph [0010]: In accordance with another embodiment, an integrated circuit includes a bus; a bus master circuit coupled to the bus; and a data storage circuit coupled to the bus, the data storage circuit including a data storage area, an address decoder, and a read checksum generator) comprising: host with a functional core; at least one destination that includes a memory block or a peripheral block; at least one interconnect coupling the host and the at least one destination and a secure communication system implemented at least in part by the host, the secure communication system configured to: (Hoermaier – Paragraph [0059]: As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line; and Paragraph [0062]: For full-duplex SPI data transfers, a transmit data word (data from master SPI device 502 to slave SPI device 504) and a receive data word (data from slave SPI device 504 to master SPI device 502) may be transferred in parallel. A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word). A transmit data word may also include a read request indicating from which address in slave SPI device 504 (or which particular slave device for embodiments that include multiple slave devices) master SPI device 502 device wants to read data. The read data is transferred to master SPI device 502 with an SPI transfer that follows the read request. This may occur in the immediately following SPI transfer, or in a later SPI transfer) generate a request message for a destination of the at least one destination (Hoermaier – Paragraph [0062]: For full-duplex SPI data transfers, a transmit data word (data from master SPI device 502 to slave SPI device 504) and a receive data word (data from slave SPI device 504 to master SPI device 502) may be transferred in parallel. A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word). A transmit data word may also include a read request indicating from which address in slave SPI device 504 (or which particular slave device for embodiments that include multiple slave devices) master SPI device 502 device wants to read data. The read data is transferred to master SPI device 502 with an SPI transfer that follows the read request. This may occur in the immediately following SPI transfer, or in a later SPI transfer; and Paragraph [0072]: In various embodiments, read type indicator 546 is used to by master SPI device 502 to request read data from slave SPI device 504, while write type indicator 548 is used by master SPI device 502 to write data to slave SPI device 504. For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); generate first integrity bits for first data of the request message (Hoermaier – Paragraph [0072]: For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); insert the first integrity bits in the request message (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits); transmit, through the interconnect, the request message that includes the first data and the first integrity bits to the destination (Hoermaier – Figures 5B and 5C: example data frames exchanged between master device 502 and slave device 504, including CRC words/bits; and Paragraph [0059]: FIG. 5A illustrates a block diagram of an embodiment SPI bus system 500 that utilizes embodiment systems and methods of embedding sideband information in data transmissions. As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line; and Paragraph [0072]: In various embodiments, read type indicator 546 is used to by master SPI device 502 to request read data from slave SPI device 504, while write type indicator 548 is used by master SPI device 502 to write data to slave SPI device 504. For example, when master SPI device 502 requests read data, the appropriate read request is encoded in the read type indicator 546 and transmitted to slave SPI device 504. On the other hand, when master SPI device 502 requests that data be written to master SPI device 502, an appropriate write request is encoded in write type indicator 548 and the data to be written is placed in first write data word 540, second write data word 542 and/or third write data word 544 as necessary. Before transmission, CRC 550 is generated to according to bits 8-63 in data frame 535); receive, through the interconnect, a response message from the destination (Hoermaier – Paragraph [0059]: FIG. 5A illustrates a block diagram of an embodiment SPI bus system 500 that utilizes embodiment systems and methods of embedding sideband information in data transmissions. As shown, SPI bus system 500 includes a master SPI device 502 coupled to at least one slave SPI device 504 over a bus that includes a transmit data line, a receive data line, a shift clock lines and a chip select line; and Paragraph [0073]: FIG. 5C illustrates data frame 560 that can be transferred from slave SPI device 504 to master SPI device 502. As shown, data frame 560 includes first read data word 552, second read data word 554, third read data word 556 which may include, for example, data requested by master SPI device 502); extract second integrity bits from the response message (Hoermaier – Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558 and the previously transmitted (and therefore locally stored) read type indicator 546 and write type indicator 548 according to embodiment systems and methods described above); verify integrity of second data of the response message based on the second integrity bits (Hoermaier – Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558); and consume the second data of the response message in response to verifying the integrity of the second data of the response message (Hoermaier – Paragraph [0060]: As shown, master SPI device 502 includes transmit register 514 coupled to the transmit data line, receive register 516 coupled to the receive data line, and a baud rate and chip select generator 518 coupled to the shift clock and the chip select line. Baud rate and chip select generator 518 may be designed, for example, to implement and facilitate SPI data transfers using SPI systems and methods known in the art. Transmit buffer 512 is coupled to transmit register 514 such that data in transmit buffer 512 is transmitted over the transmit data line via transmit register 514, and receive buffer 510 is coupled to receive register 516 such that data received from the receive data line is transferred to receive buffer 510. Checksum verification block 530 verifies the validity of the data received from the receive data line using embodiment systems and methods described herein; Paragraph [0073]: When data frame 560 is received by master SPI device 502, the data is verified by checksum verification block 530 according using CRC 558; and Paragraph [0075]: These internal protection mechanisms facilitate error detection if a transfer of data between two locations inside the μC is corrupted. Thus, if a data transfer is found to be corrupted, the corrupted data may be discarded and execution avoided).
Regarding Claim 16:
Hoermaier teaches the integrated circuit of claim 15.
Hoermaier further teaches wherein: the request message comprises a command message with a first payload that comprises the first data; or the response message comprises a response message with a second payload that comprises the second data (Hoermaier – Paragraph [0062]: For full-duplex SPI data transfers, a transmit data word (data from master SPI device 502 to slave SPI device 504) and a receive data word (data from slave SPI device 504 to master SPI device 502) may be transferred in parallel. A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word). A transmit data word may also include a read request indicating from which address in slave SPI device 504 (or which particular slave device for embodiments that include multiple slave devices) master SPI device 502 device wants to read data. The read data is transferred to master SPI device 502 with an SPI transfer that follows the read request. This may occur in the immediately following SPI transfer, or in a later SPI transfer).
Regarding Claim 19:
Hoermaier teaches the integrated circuit of claim 15.
Hoermaier further teaches wherein: the second integrity bits of the response message comprise the first integrity bits of the request message that are generated by the host; or the second integrity bits of the response message comprise integrity bits generated by the destination (Hoermaier – Figure 5C – data frame transferred from slave to master device; and Paragraph [0073]: FIG. 5C illustrates data frame 560 that can be transferred from slave SPI device 504 to master SPI device 502. As shown, data frame 560 includes first read data word 552, second read data word 554, third read data word 556 which may include, for example, data requested by master SPI device 502. Data frame 560 also includes CRC 558 that is generated by checksum generator 528 based on bits 8-63 in data frame 560 as well as additional sideband information according to embodiments of the present invention).
Regarding Claim 20:
Hoermaier teaches the integrated circuit of claim 15.
Hoermaier further teaches wherein the destination comprises a memory that is configured to store the first integrity bits with the first data of the request message (Hoermaier – Paragraph [0061]: Slave SPI device 504 includes receive register 522 coupled to the transmit data line, transmit register 524 coupled to the receive data line; and Paragraph [0062]: A transmit data word may include data that is intended to be stored in slave SPI device 504 at an address that is indicated by a write address included in the transmit data word (or a formerly transmitted data word; and Paragraph [0064]: As an example of the operation of SPI bus system 500, a sequence of four read requests is stored in transmit buffer 512 and sent to slave SPI device 504 via transmit register 514 and the transmit data line. For safety and verification reasons, these data transfers are end-to-end protected (e.g. by a checksum included in a transmit data word). Slave SPI device 504 may be configured to verify the transmitted data using the checksum and to discard the transmitted data if the checksum does not match).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 3-4, 7, 13, and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoermaier in view of Fernandes et al. (US 20220091928 A1), hereinafter Fernandes.
Regarding Claim 3:
Hoermaier teaches the method of claim 1.
Hoermaier does not expressly teach wherein: generating the first integrity bits comprises generating error correction code (ECC) bits based on the first data of the request message; or verifying the integrity of the second data of the response message comprises decoding the second integrity bits as ECC bits for a payload of the response message.
However, Fernandes teaches wherein: generating the first integrity bits comprises generating error correction code (ECC) bits based on the first data of the request message; or verifying the integrity of the second data of the response message comprises decoding the second integrity bits as ECC bits for a payload of the response message (Fernandes – Paragraph [0013]: The control bits 201 and data bits 202 are provided to an infrastructure component (Main) 210. The data bits 202 also provided to the ECC generation circuit 230. The ECC generation circuit 230 calculates the ECC for the data bits 202 and provides the calculated ECC 231 to the infrastructure component (Safe) 220. The control bits 201 also are provided to the ECC infrastructure component 220; and Paragraph [0021]: Thirty-two-bit words 315-318 each comprise 32 bits of the original 128 bits of data, and thirty-two-bit words 331-334 each comprise the 7 ECC bits corresponding to the 32 data bits in each associated word 331-334. That is, the ECC bits in word 331 comprise the ECC bits calculated for the 32 bits of data in word 315. Similarly, the ECC bits in words 332-334 comprise the ECC bits calculated for the 32 bits of data in words 316-318, respectively. Data words 315-318 are represented in FIG. 2 as data bits 222. ECC words 331-334 are represent in FIG. 2 as ECC words 248).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hoermaier, further incorporating Fernandes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fernandes’s teaching to generate and verify ECC bits in requests and responses between interconnected components into Hoermaier’s method for secure data communication. This addition would enhance the security of Hoermaier’s method by providing further means of verifying messages transmitted between a host and a destination component.
Regarding Claim 4:
The combination of Hoermaier and Fernandes teaches the method of claim 3.
Fernandes further teaches wherein: the first integrity bits of the request message comprise first ECC bits and the first ECC bits of the request message are not used by the destination for error detection or error correction; or the second integrity bits of the response message comprise second ECC bits and the second ECC bits of the response message are not used by the host for error detection or error correction (Fernandes – Figure 2: example processing of a data message between components (e.g. a CPU core and a shared memory); and Paragraph [0027]: FIG. 5 shows an example of a system 300 comprising multiple masters 302, 306, 310, and 314, multiple slaves 320 and 324, and an interconnect 330. The component shown in FIG. 5 may be provided on a semiconductor die. Any suitable number of masters and slaves can be provided. Information can flow bi-directionally through the interconnect 330 between any master 302-314 and any slave 320 and 324. As data and control signals from through any given node (master, interconnect, or slave), the complete data and control signal check (per the example of FIG. 2) need not be performed at each node. That is, if master 302 is sending a communication to slave 324, the logic of FIG. 2 need not be performed multiple times along the communication path—within each of master 302, interconnect 330, and slave 324).
The motivation to combine the arts is the same as that of Claim 3, with the addition that redundant integrity checks are not considered necessary in each component taught by Fernandes.
Regarding Claim 7:
Hoermaier teaches the method of claim 1.
Hoermaier does not expressly teach wherein the destination comprises a memory that, responsive to receiving the request message, is configured to: to generate ECC bits or cyclic redundancy check (CRC) for the first data of the request message; and store the ECC bits or CRC with the first data of the request message.
However, Fernandes teaches wherein the destination comprises a memory that, responsive to receiving the request message, is configured to: to generate ECC bits or cyclic redundancy check (CRC) for the first data of the request message; and store the ECC bits or CRC with the first data of the request message (Fernandes – Paragraph [0022]: Referring back to FIG. 2, data bits 222 and ECC words 248 are provided to the ECC error detection circuit 250. For each of the 32-bit data words (315-318 comprising data bits 222, the ECC error detection circuit 250 generates the 7 ECC bits and compares the newly calculated ECC bits to the ECC bits in the corresponding ECC words 248 (words 331-334). Error signal 251 (which may interrupt the CPU 110 or cause an external host to be signaled) indicates whether or not the ECC bits match (e.g., an Error signal with a value of 0 means the ECC bits matched, and an Error signal with a value of 1 means that at least one ECC bit did not match. In the absence of an ECC error, data bits 232 from the ECC error detection circuit 250 comprises data bits 222. Thus, if neither Error signal 241 nor Error signal 251 indicates an error (i.e., no control bit error and no ECC bit error), the control bits 221 and data bits 232 are provided to a downstream component such as shared memory 128).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hoermaier, further incorporating Fernandes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fernandes’s teaching of a memory capable of performing an integrity check on a request from a host and storing the ECC bits and the payload data contained in the message into Hoermaier’s method for secure data communication. This addition would enhance the security of Hoermaier’s method by providing another layer of verification of messages transmitted between a host and a destination component.
Regarding Claim 13:
Hoermaier teaches the method of claim 12.
Hoermaier does not expressly teach further comprising generating an interrupt to the host or a security entity of the system in response to failing to verify the third data of the second response message.
However, Fernandes teaches further comprising generating an interrupt to the host or a security entity of the system in response to failing to verify the third data of the second response message (Fernandes – Paragraph [0015]: In one example, the control signal comparator 240 performs a bit-wise comparison of control bits 211 and control bits 239. Error signal 241 indicates whether or not the control bits 211 and 239 match. In one example, Error signal 241 is a single bit signal (e.g., 0 indicates that control bits 211 and 239 match, and 1 indicates a mismatch). If there is a mismatch, the CPU core 110 may be interrupted (or an external host may be signaled) which then executes an interrupt service routine to respond to the error).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hoermaier, further incorporating Fernandes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fernandes’s teaching to generate an interrupt in response to failing to verify integrity of a message data into Hoermaier’s method for secure data communication. This combination would further enhance the security of the method by providing an immediate defense mechanism against potentially malicious communications.
Regarding Claim 17:
Hoermaier teaches the integrated circuit of claim 15.
Hoermaier does not expressly teach wherein: to generate the first integrity bits comprises generating error correction code (ECC) bits based on the first data of the request message; or to verify the integrity of the second data of the response message comprises decoding the second integrity bits as ECC bits for a payload of the response message.
However, Fernandes teaches wherein: to generate the first integrity bits comprises generating error correction code (ECC) bits based on the first data of the request message; or to verify the integrity of the second data of the response message comprises decoding the second integrity bits as ECC bits for a payload of the response message (Fernandes – Paragraph [0013]: The control bits 201 and data bits 202 are provided to an infrastructure component (Main) 210. The data bits 202 also provided to the ECC generation circuit 230. The ECC generation circuit 230 calculates the ECC for the data bits 202 and provides the calculated ECC 231 to the infrastructure component (Safe) 220. The control bits 201 also are provided to the ECC infrastructure component 220; and Paragraph [0021]: Thirty-two-bit words 315-318 each comprise 32 bits of the original 128 bits of data, and thirty-two-bit words 331-334 each comprise the 7 ECC bits corresponding to the 32 data bits in each associated word 331-334. That is, the ECC bits in word 331 comprise the ECC bits calculated for the 32 bits of data in word 315. Similarly, the ECC bits in words 332-334 comprise the ECC bits calculated for the 32 bits of data in words 316-318, respectively. Data words 315-318 are represented in FIG. 2 as data bits 222. ECC words 331-334 are represent in FIG. 2 as ECC words 248).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hoermaier, further incorporating Fernandes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fernandes’s teaching to generate and verify ECC bits in requests and responses between interconnected components into Hoermaier’s method for secure data communication. This addition would enhance the security of Hoermaier’s method by providing further means of verifying messages transmitted between a host and a destination component.
Regarding Claim 18:
Hoermaier teaches the integrated circuit of claim 15.
Hoermaier does not expressly teach wherein: to generate the first integrity bits comprises generating error correction code (ECC) bits based on the first data of the request message; or to verify the integrity of the second data of the response message comprises decoding the second integrity bits as ECC bits for a payload of the response message.
However, Fernandes teaches wherein: the first integrity bits of the request message comprise first ECC bits and the first ECC bits of the request message are not used by the destination for error detection or error correction; or the second integrity bits of the response message comprise second ECC bits and the second ECC bits of the response message are not used by the host for error detection or error correction (Fernandes – Figure 2: example processing of a data message between components (e.g. a CPU core and a shared memory); and Paragraph [0027]: FIG. 5 shows an example of a system 300 comprising multiple masters 302, 306, 310, and 314, multiple slaves 320 and 324, and an interconnect 330. The component shown in FIG. 5 may be provided on a semiconductor die. Any suitable number of masters and slaves can be provided. Information can flow bi-directionally through the interconnect 330 between any master 302-314 and any slave 320 and 324. As data and control signals from through any given node (master, interconnect, or slave), the complete data and control signal check (per the example of FIG. 2) need not be performed at each node. That is, if master 302 is sending a communication to slave 324, the logic of FIG. 2 need not be performed multiple times along the communication path—within each of master 302, interconnect 330, and slave 324).
The motivation to combine the arts is the same as that of Claim 17, with the addition that redundant integrity checks are not considered necessary in each component taught by Fernandes.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoermaier in view of Jung et al. (US 20210255942 A1), hereinafter Jung.
Regarding Claim 11:
Hoermaier teaches the method of claim 1.
Hoermaier does not expressly teach wherein the interconnect that couples the host to the at least one destination is implemented in accordance with a TileLink communication standard.
However, Jung teaches wherein the interconnect that couples the host to the at least one destination is implemented in accordance with a TileLink communication standard (Jung – Paragraph [0078]: In some example embodiments, the system bus 630 may use a TileLink that is a chip-scale interconnect standard).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hoermaier, further incorporating Jung to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jung’s teaching to implement a TileLink interconnect into Hoermaier’s method for secure data communication. This combination provides a specific practical means of communication between components of an integrated circuit.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thanner et al. (US 20160283314 A1) teaches a network-on-a-chip (NoC) which enables secure communications on-chip between cores and peripherals
Kwon et al. (US 20170308433 A1) teaches memory devices with ECC control functions for verifying incoming and outgoing messages
Muralimanohar et al. (US 20120151159 A1) teaches an interface between a memory controller and memory modules which provides ECC protection per-packet
Baek et al. (US 20170123896 A1) teaches an on-chip logic block for performing ECC operations on communications between a host and a memory device(s)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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://p