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 .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 3/11/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 6-8 and 11 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim(s) 6 and 11:
Claim 6 recites, “… if the authenticating of the updated set of security protocols is successful: … identifying the customer configuration bitstream as not authenticated.” Claim(s) 11 recite(s) similar language. The claims are indefinite because the metes and bounds of the claim are unclear. The subject matter of the claims are most similar to that of specification ¶ 0024; however, this section describes a situation in which a previously authenticated customer configuration bitstream must be reauthenticated before use, and not for marking an already-authenticated bitstream as “not authenticated.” The scope of the claims, on the other hand, indicate instead that the customer configuration bitstream is “identified as not unauthenticated.” It is first unclear at what point in the recited process of the parent claim this limitation takes place. If the identification as “not authenticated” takes place before the authentication of the parent claim, then it would see redundant, as the claim does not stipulate any condition in which the bitstream does not get authenticated. If an already authenticated bitstream is then marked as “not authenticated,” it is then unclear whether this occurs before or after reconfiguring the hardware components with the bitstream, as recited in the parent claim. If before, the claims would then recite an unauthenticated bitstream being used to configure the hardware components, which does not seem ideal or intended by the context of the invention. If after, it is then unclear what utility is had by declaring a bitstream, which has already been used to reconfigure the hardware, as not authenticated. Examiner notes that each of these issues is addressed by child claim 7, and this rejection can be overcome by incorporating these clarifying limitations into the rejected claim(s).
Regarding claims 7 and 8:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 5, 9, 19, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by CHANDRA et al (Doc ID WO 2022125714 A1).
Regarding claim 1:
CHANDRA teaches:
A method comprising: configuring hardware components of a programmable logic device (PLD) with an inherently trusted default set of operations (Pg 5 lines 30-34 "… the root of trust may be automatically added by a system builder ... for a user-defined portion of functions implemented in the PLD fabric. For example, the root of trust may be ... added to the PLD configuration data" and pg. 9 lines 11-12 "... the memory 106 of the PLD 100 may include non-volatile memory (e.g., flash memory) utilized to store the configuration data ...") immutably stored in a non-volatile memory and comprising a first root of trust for the PLD (Pg. 48 lines 29-30 "... the secure PLD 410 may include sufficient on-board nonvolatile storage (e.g., the NVM 450) for multiple on-die configuration images.");
authenticating, by the hardware components configured with the default set of operations, a customer configuration bitstream comprising an updated set of operations (Pg. 34 lines 18-26 "... At block 920, a logic device performs a pre-authentication process associated with an update configuration image. ... performing the pre-authentication process may include determining an authentication engine result based, at least in part, on the update configuration image ..."); and
reconfiguring the hardware components to replace the default set of operations with the updated set of operations if the authenticating is successful (Page 35 lines 5-8 "At block 930, a logic device selectively stores an update configuration image in a secure PLD. ... the secure PLD 410 may be configured to selectively store the update configuration image in the NVM 450 in place of a first or second configuration image ..."),
wherein the updated set of operations comprise a second root of trust for the PLD (Page 35 lines 6-8 "... the secure PLD 410 may be configured to selectively store the update configuration image in the NVM 450 in place of a first or second configuration image ...").
Regarding claim 2:
CHANDRA teaches:
The method of claim 1, wherein the authenticating comprises: verifying the customer configuration bitstream comprises a trusted security block (CHANDRA Pg. 5 lines 23-25 "… the embedded security block may provide a hardware root of trust and hardened cryptographic capabilities to address security threats.").
Regarding claim 5:
Examiner notes that this claim seems to simply represent a second iteration of the already claimed method, and performs no function distinct over what is taught in the prior art.
CHANDRA teaches:
The method of claim 1, wherein: the customer configuration bitstream is a first customer configuration bitstream and the updated set of operations is a first updated set of operations (Pg 58 lines 19-23 "The BMC 1070 initiates a configuration and PFR firmware update. ... An update to the customer firmware image is associated with an update to a configuration image from which the die 1015 booted that corresponds to the customer firmware image."); and
the method further comprises: authenticating, by the hardware components configured with the first updated set of operations, a second customer configuration bitstream comprising a second updated set of operations, (Pg. 34 lines 18-26 "... At block 920, a logic device performs a pre-authentication process associated with an update configuration image. ... performing the pre-authentication process may include determining an authentication engine result based, at least in part, on the update configuration image ...") and
reconfiguring the hardware components with the second updated set of operations to replace the first updated set of operations in the hardware components (Page 35 lines 5-8 "At block 930, a logic device selectively stores an update configuration image in a secure PLD. ... the secure PLD 410 may be configured to selectively store the update configuration image in the NVM 450 in place of a first or second configuration image ..."),
wherein the second updated set of operations comprise a third root of trust for the PLD (Page 35 lines 6-8 "... the secure PLD 410 may be configured to selectively store the update configuration image in the NVM 450 in place of a first or second configuration image ...").
Regarding claim 9:
CHANDRA teaches:
A PLD comprising a field programmable gate array (FPGA) operable to perform the method of claim 1 (Pg 5 lines 28-30 "... the multi-chip system includes a PLD die, such as an integrated circuit (IC) with an FPGA fabric .... The PLD die may implement customer control functions and may contain a root of trust.").
Regarding claim 19:
CHANDRA teaches:
The method of claim 2, further comprising: receiving a design for the PLD (CHANDRA Pg. 4 lines 2-5 "A circuit design may be represented ... by a netlist, which can describe components and connections therebetween in the design. For example, a user design may be converted into … a netlist including a set of PLD components …");
adding the trusted security block to the design (CHANDRA Pg. 6 lines 4-7 "… the configuration bitstream for configuring the PLD functionality of the security block may be updated separated from the PLD die of the multi-chip system that implements user functions …"); and
generating the customer configuration bitstream according to the design (CHANDRA Pg. 6 lines 4-7 "… the configuration bitstream for configuring the PLD functionality of the security block may be updated separated from the PLD die of the multi-chip system that implements user functions …").
Regarding claim 20:
CHANDRA teaches:
The method of claim 19, wherein: the receiving, the adding, and the generating are performed by a first device different from the PLD (CHANDRA Pg 18 lines 25-30 "… The secure PLD manufacturer 520 prepares the one or more requested secure PLDs 410 by fabricating the individual ICs and programming them with security mechanisms …"); and
the method further comprises verifying, by a second device different from the first device and the PLD, that the customer configuration bitstream comprises the trusted security block (CHANDRA Pg. 5 lines 23-25 "… the embedded security block may provide a hardware root of trust and hardened cryptographic capabilities to address security threats.").
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 3 is rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) as applied to claim 2 above, and further in view of PANZICA et al (Doc ID US 20220358062 A1).
Regarding claim 3:
CHANDRA teaches:
The method of claim 2,
PANZICA teaches the following limitation(s) not taught by CHANDRA:
wherein: the verifying comprises determining the customer configuration bitstream restricts access to the non-volatile memory by the hardware components ([0082] "… the state machine 404 may determine whether an MP configuration restricts access to a protected memory area 310 that does not need to be accessed during execution of the secure service request ...").
Verifying the presence of a security block in code is/are known technique(s) in the art, as demonstrated by CHANDRA. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the root of trust update of CHANDRA with the security block detection of PANZICA with the motivation to ensure that the updated root of trust is secure and untampered with, as can be verified by using a secure block.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) as applied to claim 1 above, and further in view of MCNEIL et al (Doc ID US 10776522 B1).
Regarding claim 4:
CHANDRA teaches:
The method of claim 1,
MCNEIL teaches the following limitations not taught by CHANDRA:
wherein the authenticating comprises: reading metadata associated with the customer configuration bitstream ((70) Col 11 lines 25-26 "In block 730, the IC is capable of authenticating the configuration data using the decrypted public key."); and
confirming the metadata identifies that the customer configuration bitstream was previously authenticated ((70) Col 11 lines 28-30 "In block 735, the IC determines whether the configuration data has been authenticated.").
Verifying whether an update has previously been authenticated is/are known technique(s) in the art, as demonstrated by MCNEIL. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the root of trust update of CHANDRA with the previous authentication detection of MCNEIL with the motivation to save resources by opting to not authenticate an update if it can be verified that the update has already been authenticated.
Claims 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) as applied to claim 1 above, and further in view of HAJOST et al (Doc ID US 8990559 B2) and MILTON et al (Doc ID US 20200351261 A1).
Regarding claim 6:
CHANDRA teaches:
The method of claim 1, the method further comprises: further configuring the hardware components with an inherently trusted default set of security protocols stored in the non-volatile memory (CHANDRA Pg 6 lines 1-3 "The separate die may implement a security block/engine (e.g., embedded security block) to provide security functions.");
HAJOST teaches the following limitations not taught by CHANDRA:
authenticating, by the hardware components configured with the default set of operations, an updated set of security protocols for the PLD ((21) Col 7 lines 16-17 "the encrypted file can be validated by the module 300 to ensure the authenticity of the encrypted file ..."); and
if the authenticating of the updated set of security protocols is successful: replacing the default set of security protocols with the updated set of security protocols in the non-volatile memory, ((22) Col 7 lines 26-28 "Upon the validation of the encrypted file, the policy settings defined in the validated encrypted file can be applied to a target computing device, as shown in block 350.") and
Authenticating an update to security policies and applying the policies once authenticated is/are known technique(s) in the art, as demonstrated by HAJOST. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the root of trust update of CHANDRA with the authenticated security policy update of HAJOST with the motivation to ensure that incoming updates to security policies have not been tampered with.
MILTON teaches the following limitation(s) not taught by the combination of CHANDRA and HAJOST:
identifying the customer configuration bitstream as not authenticated ([0024] "… based on configurations, the security policy manager 330 may … trigger re-authentication as needed so that the supplicant may use the updated configurations.").
Requiring reauthentication after an update to security policies is/are known technique(s) in the art, as demonstrated by MILTON. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the root of trust update of CHANDRA and HAJOST with the reauthentication requirement of MILTON with the motivation to ensure that any in-use processes are compliant with the most up-to-date security policies. Only those which are will succeed in reauthentication.
Regarding claim 7:
The combination of CHANDRA, HAJOST, and MILTON teaches:
The method of claim 6, further comprising: reconfiguring the hardware components with the default set of operations (CHANDRA Page 35 lines 5-8 "At block 930, a logic device selectively stores an update configuration image in a secure PLD. ... the secure PLD 410 may be configured to selectively store the update configuration image in the NVM 450 in place of a first or second configuration image ...");
further configuring the hardware components with the updated set of security protocols (HAJOST (22) Col 7 lines 26-28 "Upon the validation of the encrypted file, the policy settings defined in the validated encrypted file can be applied to a target computing device, as shown in block 350."); and
reauthenticating, by the hardware components reconfigured with the default set of operations, the customer configuration bitstream (MILTON [0024] "… based on configurations, the security policy manager 330 may … trigger re-authentication as needed so that the supplicant may use the updated configurations.").
Requiring reauthentication after an update to security policies is/are known technique(s) in the art, as demonstrated by MILTON. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the root of trust update of CHANDRA, HAJOST, and MILTON with the reauthentication requirement of MILTON with the motivation to ensure that any in-use processes are compliant with the most up-to-date security policies. Only those which are will succeed in reauthentication.
Regarding claim 8:
The combination of CHANDRA, HAJOST, and MILTON teaches:
The method of claim 6, wherein: the default set of operations and the default set of security protocols are provided by a predetermined inherently trusted party (CHANDRA Pg. 18 lines 20-21 "As shown in FIG. 5A, the secure PLD customer 510 and secure PLD manufacturer 520 may be considered trusted …"entities within the provisioning system 500); and
the default set of security protocols and the updated set of security protocols comprise cryptographic processes (CHANDRA Pg. 5 lines 23-25 "… the embedded security block may provide a hardware root of trust and hardened cryptographic capabilities to address security threats.").
Claims 10, 12, 13, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1), and further in view of HAJOST et al (Doc ID US 8990559 B2).
Regarding claim 10:
CHANDRA teaches:
A method comprising: configuring hardware components of a programmable logic device (PLD) with an inherently trusted default set of operations (Pg 5 lines 30-34 "… the root of trust may be automatically added by a system builder ... for a user-defined portion of functions implemented in the PLD fabric. For example, the root of trust may be ... added to the PLD configuration data" and pg. 9 lines 11-12 "... the memory 106 of the PLD 100 may include non-volatile memory (e.g., flash memory) utilized to store the configuration data ...") immutably stored in a non-volatile memory and comprising a first root of trust for the PLD (Pg. 48 lines 29-30 "... the secure PLD 410 may include sufficient on-board nonvolatile storage (e.g., the NVM 450) for multiple on-die configuration images.");
further configuring the hardware components with an inherently trusted default set of security protocols stored in the non-volatile memory (CHANDRA Pg 6 lines 1-3 "The separate die may implement a security block/engine (e.g., embedded security block) to provide security functions.");
The remainder of this claim’s limitations are rejected with the same prior art mapping and justification, mutatis mutandis, as applied to claim 6.
Regarding claim(s) 12, 13, and 16-18:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 1, 2, 5, 8 and 9 above.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) and HAJOST et al (Doc ID US 8990559 B2) as applied to claim 10 above, and further in view of MILTON et al (Doc ID US 20200351261 A1).
Regarding claim 11:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 6 above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) and HAJOST et al (Doc ID US 8990559 B2) as applied to claim 13 above, and further in view of PANZICA et al (Doc ID US 20220358062 A1).
Regarding claim 14:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 3 above.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over CHANDRA et al (Doc ID WO 2022125714 A1) and HAJOST et al (Doc ID US 8990559 B2) as applied to claim 12 above, and further in view of MCNEIL et al (Doc ID US 10776522 B1).
Regarding claim 15:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 4 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703) 756-4528. The examiner can normally be reached M-F 0800-1600 EST.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights