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 is the initial Office Action based on the application filed 04/30/2025. Claims 1-20 are presented for examination and have been considered below.
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.
Claims 1–4, 8–11, and 15–20 are rejected under 35 U.S.C. 103 as being unpatentable over Seznayov et al., U.S. Patent No. 11,263,077 B1 (“Hailo”), in view of Rosenblattl, U.S. Patent Application Publication No. 2020/0081765 A1 (“Rosenblattl”).
Claim 1: Hailo teaches a functional safety protection circuit, comprising:
a configuration module, wherein the configuration module is configured to obtain a first configuration instruction (e.g., Hailo teaches layer control units (“LCUs”) that configure and control protected circuitry, CRC engines, and memory. Hailo expressly claims an LCU “operative to configure and control” the CRC engine and memory and further teaches that layer/dataflow operation is defined by configuration information. See claim 7. Hailo further states that layers communicate using allocated memory blocks and signaling “all defined by the configuration.” See Col. 28, lines 23-26) and a reference check code (e.g., In Hailo’s Fig. 73 embodiment, an expected test-output CRC 1532 is calculated a priori by the compiler and preconfigured in the NN processor. Hailo states that the expected test CRC is calculated by taking a CRC over the compiler-generated expected test output and that the test data and expected test CRC are preconfigured in the NN processor. See col. 66, approximately ll. 42–65, Fig. 73 discussion);
a protected module, wherein the protected module is configured to generate first target information based on the first configuration instruction (e.g., Hailo’s protected computational-logic circuit/tensor-data-flow path 1540, Fig. 73, receives input tensors and corresponding weights and generates output tensors/test output. The test data are injected under control of the LCU allocated to the particular configured layer. See col. 66, lines 31-50 );
a check operation module, wherein the check operation module is configured to perform a preset check operation on the first target information to obtain a target check code associated with the first configuration instruction (e.g., Hailo’s CRC circuit 1533, in Fig. 73, calculates a running CRC checksum over the test output 1544 generated by protected computational logic 1540) Hailo elsewhere expressly teaches CRC engine 1448 calculating a CRC over output data 1453 generated by computational logic circuit 1442. See col. 66, lines 31-50 ); and
a functional safety detection module, wherein the functional safety detection module is configured to determine a first functional safety detection result of the protected module based on the reference check code and the target check code (e.g., Hailo states that the calculated test CRC is compared by comparator 1542 with previously configured expected test CRC 1532; a match/mismatch is determined, and error signal 1548 is generated upon a mismatch. Likewise, CRC engine 1448 generates a calculated CRC that may be compared to preconfigured expected CRC checksum 1454 by comparator 1452, with error signal 1457 raised upon a mismatch. See col. 66, lines 31-50).
Not explicitly taught by Hailo is that the reference check code is associated with the “first configuration instruction”.
However, Rosenblattl teaches generating a plurality of initial values, calculating for each initial value a specific CRC reference value, and storing the pairs of initial value and associated CRC reference value. During operation, a particular initial value is selected, the hardware CRC engine performs the CRC using that selected value, and the calculated CRC is compared with the reference CRC corresponding to the selected value (e.g., Abstract, [0014]). Rosenblattl further teaches writing the selected initial value, start address, and length into a configuration register of the CRC hardware engine (e.g., [0066]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hailo’s preconfigured expected-CRC functional-safety mechanism such that each reference CRC is stored, selected, or otherwise associated with the configuration value/instruction to which it pertains, as taught by Rosenblattl, in order to ensure that a runtime CRC generated under a particular configuration is compared against the correct reference CRC corresponding to that same configuration. This would have amounted to applying Rosenblattl’s known configuration/reference-CRC association technique to Hailo’s similar CRC-based functional-safety system to obtain the predictable result of more reliably selecting the correct expected CRC for the operative configuration. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007).
Claim 2: Hailo and Rosenblattl teach the functional safety protection circuit according to claim 1, but fail to teach that the reference check code associated with the first configuration instruction comprises reference check codes respectively corresponding to a plurality of preset data types; and that the protected module is configured to generate first target information based on the first configuration instruction comprises that: the protected module is configured to determine configuration information respectively corresponding to the plurality of preset data types based on the first configuration instruction, and generate the first target information respectively corresponding to the plurality of preset data types based on the configuration information respectively corresponding to the plurality of preset data types.
However, Hailo teaches a plurality of different NN data types, including input feature/tensor data, weight data, and output feature/tensor data. In Hailo’s Fig. 73 embodiment, input tensors 1536 and weights 1538 are supplied to the computational path, and output tensors 1546 are generated. Hailo additionally teaches separate CRC protection of different classes of NN data. For weight data, each block of weights has a precalculated CRC, a runtime CRC is calculated for the corresponding block, and the two are compared. For tensor data, Hailo teaches CRC generation/checking in the input/output tensor paths and CRCs calculated across feature data. Hailo also teaches that operation of the respective layer/data paths is controlled according to configuration allocated by the compiler and corresponding LCUs. See Fig. 73. Furthermore, Rosenblattl teaches associating each respective configuration/initial value with its corresponding specific reference CRC and subsequently selecting the proper pair for checking (e.g., [0014]). It would therefore have been obvious to maintain respective configuration/reference-CRC associations for the respective protected data types in Hailo so that each separately configured data path/type is checked against its proper expected value.
Claim 3: Hailo and Rosenblattl teach the functional safety protection circuit according to claim 2, wherein that the check operation module is configured to perform a preset check operation on the first target information to obtain a target check code associated with the first configuration instruction comprises that: the check operation module is configured to perform preset check operations on the first target information respectively corresponding to the plurality of preset data types, to obtain target check codes respectively corresponding to the plurality of preset data types.
For instance, Hailo teaches CRC generation/check operations performed on separately protected tensor data paths, including CRC generator/check circuits associated with respective input and output streams. See col. 53, ll. 1–65; col. 54, ll. 1–20; Figs. 53A–55. Hailo explains that CRCs are generated for blocks of protected tensor data and subsequently checked at corresponding receiving/protected circuitry. Hailo further teaches CRC circuitry usable at different locations in the protected neural-network datapath. See Hailo, Figs. 67A–69, including CRC protection across tensor/features and CRC circuitry usable in input-buffer, output-buffer, IA, and APU circuitry. Thus, Hailo teaches performing respective preset CRC/check operations on respective protected target information to obtain respective CRC/check results, corresponding to the claimed target check codes. Rosenblattl further confirms the known practice of computing a runtime CRC under a selected configuration and comparing that CRC against the reference CRC corresponding to that selected configuration. See Rosenblattl, ¶¶ [0042], [0088]..
Claim 4: Hailo and Rosenblattl teach the functional safety protection circuit according to claim 3, wherein the functional safety detection module is configured to determine a first functional safety detection result of the protected module based on the reference check code and the target check code comprises that: the functional safety detection module is configured to determine the first functional safety detection result based on the reference check codes respectively corresponding to the plurality of preset data types and the target check codes respectively corresponding to the plurality of preset data types.
For instance, Hailo teaches determining functional-safety/error results based upon CRC verification for separately protected data. Hailo describes CRC checking of protected tensor streams and generation of an error indication when the CRC verification fails. See Hailo, col. 53, ll. 1–15; col. 54, ll. 15–25; col. 55, ll. 1–15. Hailo further teaches that its CRC engines/check circuitry determine whether received or generated data satisfy the expected CRC relationship and provide an error indication upon failure. Hailo’s broader functional-safety architecture also uses generated and expected CRC values to produce fault/error results for protected computation paths. See Hailo, col. 66, lines 31-67; Fig. 73, in which comparator 1542 compares a generated test CRC with expected test CRC 1532 and produces error signal 1548 when the values do not correspond. As discussed with respect to claims 1–2, Rosenblattl teaches maintaining respective reference CRC values associated with respective configuration values and comparing a calculated CRC against the reference CRC corresponding to the selected configuration. It therefore would have been obvious to determine an overall or corresponding functional-safety result from the respective target/reference CRC comparisons for Hailo’s separately protected data paths, because the individual comparison results already indicate whether the corresponding protected information has passed or failed integrity verification.
Claim 8: Hailo and Rosenblattl teach the functional safety protection circuit according to claim 1, wherein the configuration module is further configured to obtain a second configuration instruction, and the protected module comprises: a second generation submodule, which is configured to generate second target information based on the second configuration instruction; and a redundant generation submodule corresponding to the second generation submodule, wherein the redundant generation submodule is configured to generate third target information based on the second configuration instruction, wherein the functional safety detection module is further configured to determine a second functional safety detection result of the protected module based on the second target information and the third target information.
For instance, Hailo expressly discloses a software-defined redundant-allocation functional-safety mechanism in which the compiler/SDK determines and configures resources for a main computation path and one or more corresponding redundant computation paths. See Hailo, col. 56, ll. 15–45; Fig. 56.
Hailo further teaches that the compiler configures the NN processor to create a main computation path and one or more redundant computation paths, and that corresponding CRC information generated for those paths is compared to detect an error. See Hailo, col. 57, ll. 25–50; Figs. 56–57. Accordingly, under a broadest reasonable interpretation:
the compiler/SDK configuration for the redundant execution corresponds to the claimed second configuration instruction;
the main computation path corresponds to the claimed second generation submodule;
the redundant computation path corresponds to the claimed redundant generation submodule;
the respective outputs of the main and redundant paths correspond to the claimed second target information and third target information.
Hailo additionally discloses N allocated computation-resource groups, including a main computation path and N−1 redundant computation paths, whose respective results/CRC information are supplied to majority-voting/comparison logic for fault detection. See Hailo, col. 58, ll. 15–35; Fig. 57. Most significantly, Hailo teaches that the compiler may allocate additional SC/APU resources for redundancy and ensures that the main tensor-data-flow path and the redundant tensor-data-flow path are functionally identical. See Hailo, col. 59, ll. 30–50; Fig. 58. This supports the claimed corresponding main/redundant generation modules operating pursuant to the same configured function. Hailo further teaches determining a functional-safety result based on the outputs/check information from the main and redundant paths. CRCs or corresponding results from those paths are compared/voted, and disagreement produces an error indication. See Hailo, col. 57, ll. 25–50; col. 58, ll. 15–35; Figs. 56–57.
As per claim 9, the claim depends from claim 2 and adds substantially the redundant-generation limitations of claim 8. For the reasons stated regarding claim 2, Hailo in view of Rosenblattl renders obvious the plurality-of-data-type limitations. And For the reasons stated regarding claim 8, Hailo expressly teaches a main computation path and corresponding redundant computation path operating according to compiler-defined configuration and generating outputs that are compared for functional-safety detection.
As per claim 10, the claim 10 depends from claim 3 and adds the redundant-generation limitations. For the reasons stated regarding claim 3, Hailo teaches respective CRC/check operations for the respective protected data. And for the reasons stated regarding claim 8, Hailo teaches functionally identical main and redundant computation paths whose respective outputs/CRCs are compared to detect faults.
As per claim 11, the claim 11 depends from claim 4 and additionally recites the redundant-generation limitations. For the reasons stated regarding claim 4, Hailo teaches determining safety/error results from corresponding CRC comparisons. Hailo additionally teaches comparing CRCs produced for the main and redundant tensor-data paths in CRC comparator 1144 and generating error signal 1143 when a mismatch is detected.
Claim 15 recites a chip comprising substantially the functional-safety protection circuit recited in claim 1. For the reasons stated regarding claim 1, Hailo in view of Rosenblattl teaches or renders obvious the recited functional-safety protection circuit.
Claim 16 depends from claim 15 and recites substantially the plurality-of-preset-data-types limitations of claim 2. For the reasons stated regarding claims 2 and 15, Hailo teaches plural protected NN data types, corresponding CRC protection, configuration-controlled processing, and chip implementation, while Rosenblattl teaches explicit configuration/reference-CRC association.
Claim 17 depends from claim 16 and recites substantially the respective-check-operation limitations of claim 3. For the reasons stated regarding claims 3, 15, and 16, Hailo teaches respective CRC/check operations over separately protected NN data and an IC/SoC implementation.
Claim 18 recites the method claim 1. Therefore, claim 18 is rejected for the same reasons of stated in the rejection of claim 1.
Claims 19 and 20 are directed to computer-readable medium and device embodiments that correspond to the method claim of claim 8. Accordingly, claim 19 and 20 are rejected on the same grounds as claim 8.
Allowable Subject Matter
Claims 5-7, and 12-14 are 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUERRIER MERANT whose telephone number is (571)270-1066. The examiner can normally be reached Monday-Friday 8:00 Am - 5:00 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, Mark Featherstone can be reached at 571-270-3750. 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.
/GUERRIER MERANT/Primary Examiner, Art Unit 2111 8/26/2026
Prosecution Insights