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 .
DETAILED ACTION
Claims 1 – 4, 6 – 12, 14 – 18, and 20 are pending.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
This action is in response to the communication filed on 02/19/26.
All objections and rejections not set forth below have been withdrawn.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 6, the recitation “…attest the second node without performing a challenge-response verification…” renders the scope of the claims indefinite. Specifically, the examiner notes that it would be unclear to one of ordinary skill in the art as to how a device attests to a “second node” without performing a challenge-response verification. An “attestation” is by definition a challenge-response verification (e.g. consider Cremers et al., “Formal Analysis of SPDM: Security Protocol and Data Model version 1.2”, pg. 4, “…the attestation mechanism boils down to a challenge-response mechanism…”). Particularly, an attestation involves a challenge by one device (node) to another device (node) to respond with a cryptographic proof to verify that the node is genuine or meets a specific set of security requirements. Thus, the notion that an attestation, as claimed, is performed without any challenge-response verification renders the scope of the claims indefinite.
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.
Claims 1 – 4, 6 – 12, 14 – 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over DMTF, “Security Protocol and Data Model (SPDM) Specification” (Version 1.2.1), in view of DMTF (hereinafter DTMF-2), “Security Protocol and Data Model (SPDM) Architecture White Paper” (Version 1.2.0), in view of Sathyanarayana et al. (Sath’), US 2022/0124118 A1.
Regarding claim 1, as best understood in view of the above noted deficiencies of clarity, DMTF discloses:
An Information Handling System (IHS) (e.g. DMTF, pg. 9, “Introduction”) … to: determine, by a first node (e.g. DMTF, par. 85 – “authentication initiator”) configured in a certificate chain as specified by a Security Protocol and Data Model (SPDM) specification (e.g. DMTF, pg. 25, 26 – figure 1 - SPDM certificate chain), that a second node in the certificate chain possesses a private key … (e.g. DMTF, par. 96, 98 - 106, 109; par. 115 – 119; par. 332 – 335; par. 341-346; par. 498).
Herein, DMTF teaches that a requestor or authentication initiator my request and receive a certificate chain (or simply a raw public key) from a responder, wherein the received certificates of the certificate chain (or the lack thereof) indicate whether the responder has a certificate chain private key which may be used for authentication. While, DMTF teaches that the certificates are identified by object identifiers (OIDs) which indicate which certificate (i.e. private key) is to be used for authentication, DMTF does not appear to explicitly teach that the requestor actually reads the certificate and OID indication when determining the certificate used for authentication.
However, DMTF-2 teaches that the requestor receives the certificate chain from the responder and reads and interprets the received certificates, including the identity information or OIDs within, so as to properly authenticate the responder using the private key (e.g. DMTF-2, par. 82, 84, 98 – 99; par. 124 – EKU; par. 130 – 133; par. 284). DMTF-2 further teaches that if a requester determines that the responder does not possess an OID (i.e. an OID identified certificate), then the requester can perform an attestation without requiring a responder’s digital signature using a private key from a certificate within a certificate chain (e.g. DMTF-2, par. 80; par. 173 - 177).
It would have been obvious to one of ordinary skill in the art to combine the teachings of DMTF-2 with that of DMTF because one of ordinary skill in the art would have been motivated by the teaching that the disclosure of DMTF is indispensable for the application of the SPDM architecture of DMTF-2 (e.g. DMTF-2, par. 30).
Thus, combination enables:
… by determining that the second node has an Object Identifier (OID) stored in the second node (e.g. DMTF-2, par. 82, 84, 98 – 99; par. 124 – EKU; par. 130 – 133; par. 284; DMTF, fig. 7 – “if supports”; par. 113, 498).
wherein the second node comprises a next sequential node of the certificate chain (e.g. DMTF, par. 100 – 105 – the nodes are represented by sequential certificates within a certificate chain);
perform a challenge-response verification to establish proof of possession of the OID (e.g. DMTF, par. 85; par. 115 – 117; – “authentication initiator” sends challenge to a responder that uses its private key to sign the challenge);
DMTF discloses a system for enabling an authentication initiator, according to the SPDM specification, to challenge the authenticity of devices so as to enable the performance of firmware measurements upon devices (e.g. DMTF, pg. 9, Introduction; par. 75; par. 118, 119), thus helping to avoid man-in-the middle attacks within the system (e.g. DMTF, par. 367; par. 548).
However, DMTF does not appear to explicitly disclose that the authentication initiator may be a device (e.g. a baseboard management controller) that could inhibit operation upon the device if the device failed the authentication challenge.
Sath’, like DMTF, also discloses a system for enabling an authentication initiator, according to the SPDM specification (e.g. Sath’, par. 25) to challenge the authenticity of devices so as to enable the performance of firmware measurements upon devices and thus help to avoid man-in-the middle attacks within the system (e.g. Sath’, Abstract; par. 6, 17, 20). Furthermore, Sath’ teaches that the authentication initiator or baseboard management controller (i.e. BMC) may inhibit operation of the device if the device fails the authentication challenge (e.g. Sath’ par. 25).
It would have been obvious to one of ordinary skill in the art to employ the baseboard management controller teachings of Sath’ for inhibiting the operation of devices that fail authentication challenges. This would have been obvious because one of ordinary skill in the art would have been motivated by the teachings that the firmware measurements in a SPDM system can be protected from man-in-the-middle attacks by taking protective actions when device authentication fails (e.g. Sath’, Abstract; par. 25).
Thus, the combination enables:
inhibit operation of the second node based upon the challenge-response verification (e.g. DMTF, pg. 9, Introduction; par. 75; par. 118, 119; e.g. Sath’, Abstract; par. 25).
Furthermore, the examiner notes that DMTF fails to explicitly disclose the use of well-known and standard computing technology, such as memory and processors. However, Sath’ discloses such, and it would have been obvious to one of ordinary skill in the art to recognize such teachings because they would have been motivated by the need for practical means to implementing such a computing system.
Thus, the combination enables:
…comprising: at least one memory coupled to the at least one processor, the at least one memory having program instructions stored thereon that, upon execution by the at least one processor, cause the instructions … (e.g. Sath’, par. 77-79).
Regarding claim 2, the combination enables:
wherein the first node comprises a Baseboard Management Controller (BMC) (e.g. Sath’, Abstract; par. 25), and the second node comprises an alias intermediate Certificate Authority (CA) (e.g. DMTF, par. 101, 102).
Regarding claim 3, the combination enables:
wherein another node downstream on the certificate chain from the alias intermediate CA comprises a firmware update (e.g. DMTF, pg. 100, RequestResynch; pg. 179, Firmware updates for responder).
See also DMTF-2 (e.g. par. 159-162). It would have been obvious to one of ordinary skill in the art to combine these teachings of DMTF-2 with that of DMTF because one of ordinary skill in the art would have been motivated by the teaching that the disclosure of DMTF is indispensable for the application of the SPDM architecture of DMTF-2 (e.g. DMTF-2, par. 30).
See also Sath’ (par. 2, 48) whose teachings for safely performing firmware updates upon devices by the BMC would have also been obvious to one of ordinary skill in the art for the reasons already noted of record.
Regarding claim 4, the combination enables:
wherein the program instructions, upon execution, further cause IHS to: inhibit operation of the second node by disallowing the second node from authenticating the firmware update when the challenge-response verification fails (e.g. DMTF, pg. 100, RequestResynch; pg. 179, Firmware updates for responder; e.g. Sath’, Abstract; par. 2, 48).
See also DMTF-2 (e.g. par. 159-162). It would have been obvious to one of ordinary skill in the art to combine these teachings of DMTF-2 with that of DMTF because one of ordinary skill in the art would have been motivated by the teaching that the disclosure of DMTF is indispensable for the application of the SPDM architecture of DMTF-2 (e.g. DMTF-2, par. 30).
and allow the authentication of the firmware update when the challenge-response verification passes (e.g. DMTF, pg. 100, RequestResynch; pg. 179, Firmware updates for responder; e.g. Sath’, Abstract; par. 2, 48).
Regarding claim 6, as best understood in view of the above noted deficiencies of clarity, the notes that DMTF does not appear to explicitly teach attestation without a challenge-response verification.
However, the DMTF-2 discloses that if a responder supports attestation, but cannot perform signature generation from challenge requests, then the requester can accept a responder’s measurement only (e.g. DMTF-2, par. 80).
It would have been obvious to one of ordinary skill in the art to combine the teachings of DMTF-2 with that of DMTF because one of ordinary skill in the art would have been motivated by the teaching that the disclosure of DMTF is indispensable for the application of the SPDM architecture of DMTF-2 (e.g. DMTF-2, par. 30).
Thus, combination enables:
wherein the program instructions, upon execution, further cause IHS to attest the second node without performing a challenge-response verification when the second node does not possess the OID (e.g. DMTF, fig. 7 – “if supports”; DMTF-2, par. 80; par. 173 - 177).
Regarding claim 7, the combination enables:
wherein the certificate chain comprises a root CA node representing a vendor of a computing device (e.g. DMTF, par. 99 - 104; par. 113, 114; figure 1).
Regarding claim 8, the combination enables:
wherein another node downstream on the certificate chain from the second node comprises a firmware update, and wherein the firmware update is configured to be deployed on a SPDM-enabled device conforming to the SPDM specification (e.g. DMTF, pg. 100, RequestResynch; pg. 179, Firmware updates for responder; e.g. Sath’, Abstract; par. 2, 48).
See also DMTF-2 (e.g. par. 159-162). It would have been obvious to one of ordinary skill in the art to combine these teachings of DMTF-2 with that of DMTF because one of ordinary skill in the art would have been motivated by the teaching that the disclosure of DMTF is indispensable for the application of the SPDM architecture of DMTF-2 (e.g. DMTF-2, par. 30).
Regarding claims 9 – 12, 14 – 18, and 20, they are method and medium claims essentially corresponding to the system claims above, and they are rejected, at least, for the same reasons.
Response to Arguments
Applicant's arguments filed 2/19/26 have been fully considered but they are not persuasive.
Applicant argues or alleges essentially that:
…
… That is, the SPDM Specification does not teach that a first node (i.e., an initiator) issues a challenge-response verification when a second node possesses a OID; rather, it only teaches, and is limited to teaching, that the second node (i.e., responder), that may possess an OID, digitally signs a challenge from the authentication initiator regardless of whether the challenge-response verification was initiated by the initiator. As such, the SPDM Specification can be construed to teach or suggest the emphasized features of amended claim 1 shown above.
…
(Remarks, pg. 11)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, the examiner notes that DMTF teaches that the requestor (i.e. authentication initiator) only initiates the challenge-response verification based upon a private key of a certificate chain when it has been determined that the responder has a OID identified private key to be used for the challenge-response. Furthermore, DMTF-2 explicitly teaches that the certificates and OID values are read by the requester so that the requestor can determine how any authentication (e.g. a challenge-response using a private key within a certificate chain) with the responder should proceed (e.g. DMTF, fig. 7 – “if supports”; par. 113, 498; DMTF-2, par. 82, 84, 98 – 99; par. 124 – EKU; par. 130 – 133; par. 284).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
The outputting step does not require any specific computer or hardware. Thus, for the outputting step: wouldn’t simply writing onto a piece of paper a determination, such as “this software is malicious”, still fall under an abstract idea?
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495