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-20 are pending.
Claims 14-20 are withdrawn from consideration by the applicant and as being directed to non-elected claims.
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 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.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/14/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Election/Restrictions
Applicant’s election without traverse of Group I (claims 1-13) in the replies filed on 3/19/2026 and 4/30/2026 is acknowledged.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure:
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because the applicant has essentially reworded claim 1 as the abstract and does not make clear that which the applicant’s considers to be new in the art to which the invention pertains. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The disclosure is additionally objected to because of the following informalities:
[0062] – recites, “The BMC 302 also generates…” Should recite, “BMC 108”
[0069] – recites in the last line, “The remaining tasks of FIG. 3 are performed…” Should recite, “tasks of FIG. 4”
[0079] – recites in the last line, “However, if the provided authentication key does not the authentication key 161, the security processor 128 sends…” Should probably recite, “if the provided authentication key does not match the authentication key 161.”
[0091] – recites in the last line, “If the authentication key is present, then that indicates the replacement SCM 500 is not a valid replacement SCM (and in fact may be a SCM swapped by a bad actor), then the secure SCM replacement process stops (the "Yes" branch of the decision diamond 516).” Should probably recite, “(the "Yes" branch of the decision diamond 520)” as the rest of the paragraph is referring to this diamond.
Appropriate corrections are 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)(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.
Claims 1-5, 11, and 13 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Paulraj et al (US Pub. No. 2024/0303339), hereafter, “Paulraj.”
As to claim 1, Paulraj discloses a first security module (Fig. 1 and Abstract) comprising:
a connector interface to removably connect to a processor module ([0027], particularly, “Unlike existing servers, where the BMC is integrated on a processor motherboard and cannot be easily moved to another system, DC-SCM 206 is pluggable and can be moved to a new server and new HPM 201 relatively easily.”); and
a controller ([0026], particularly, “DC-SCM 206 includes an iDRAC 208 or other remote access controller or baseboard management controller (BMC). iDRAC 208 includes RoT Binding daemon 209, such as a background software application or process running on iDRAC 208. DC-SCM 206 also includes a security processor 210 stores credentials, licenses, security certificates, and configuration hash values for use in establishing bindings or trust between system components.”) to:
retrieve information stored at the processor module, the information set by a second security module when binding the second security module with the processor module ([0033], particularly, “When the factory mode is active, iDRAC 208 retrieves hardware identity certificates from all of the SPDM-capable hardware devices present in HPM 201, such as CPU 202, memory devices 203, 204, and smart device 205. The hardware identity certificates may be obtained using the SPDM Get_Certificate request message sent by iDRAC 208, which causes the hardware devices to respond with an SPDM Certificate response message.” See also, [0044]-[0045], particularly, “In step 306, iDRAC 31 calculates an overall hash value for all of the hardware identity certificates and firmware measurements for CPU 33 and memory 34 and stores the hash value either locally or with security processor 35 This binds HPM 32 to the DC-SCM associated with iDRAC 31 and sets the system mode to HPM-to-DC-SCM BOUND mode and ends the factory mode.”);
read a first authentication key from a memory of the first security module ([0044]-[0046], particularly, “After the system is installed at a customer site, such as a data center, steps 307-312 may be performed. In steps 307 and 308, power on messages are sent to security processor 35 and iDRAC 31. As part of the boot process, iDRAC 31 obtains hardware identity certificates and firmware measurements from hardware devices 33, 34 present on HPM 32.”);
compute a second authentication key based on the information retrieved from the processor module ([0045]-[0046], particularly, “iDRAC 208 recalculates the overall hash value and fetches the stored hash value in step 309 from security processor 34. In step 310, iDRAC 31 determines whether both hash values match (i.e., factory hash value and recent power on hash value) and then validates the binding between the DC-SCM associated with iDRAC 31 and HPM 32.”); and
determine whether to allow an initialization of the processor module based on the first authentication key and the second authentication key ([0045]-[0046], particularly, “In step 310, iDRAC 31 determines whether both hash values match (i.e., factory hash value and recent power on hash value) and then validates the binding between the DC-SCM associated with iDRAC 31 and HPM 32. In step 311, if the binding is valid, then iDRAC 31 initiates power on for the HPM 32 components and allows the CPU 33 to boot.”)
As to claim 2, Paulraj discloses the first security module is different from or the same as the second security module ([0044]-[0046]).
As to claim 3, Paulraj discloses the controller is to prevent the initialization of the processor module based on the controller determining that the second authentication key is different from the first authentication key ([0045]-[0046], particularly, “In step 310, iDRAC 31 determines whether both hash values match (i.e., factory hash value and recent power on hash value) and then validates the binding between the DC-SCM associated with iDRAC 31 and HPM 32. In step 311, if the binding is valid, then iDRAC 31 initiates power on for the HPM 32 components and allows the CPU 33 to boot.”).
As to claim 4, Paulraj discloses a mismatch of the second authentication key and the first authentication key indicates that the first security module is different from the second security module ([0045]-[0046], particularly, “In step 310, iDRAC 31 determines whether both hash values match (i.e., factory hash value and recent power on hash value) and then validates the binding between the DC-SCM associated with iDRAC 31 and HPM 32. In step 311, if the binding is valid, then iDRAC 31 initiates power on for the HPM 32 components and allows the CPU 33 to boot.”).
As to claim 5, Paulraj discloses the first authentication key was generated by the first security module when binding with a processor module ([0044]-[0046]).
As to claim 11, Paulraj discloses the controller is to: request, from the processor module, a pairing value generated by the second security module based on first information of the processor module and second information of the second security module, wherein the request comprises a controller- provided authentication key sent from the controller to the processor module, the controller-provided authentication key comprising the first authentication key or the second authentication key; and receive, at the controller, the pairing value from the processor module in response to the request, wherein the receipt of the pairing value indicates a validity of the controller- provided authentication key ([0044]-[0046]).
As to claim 13, Paulraj discloses the pairing value comprises a hash value derived from applying a hash function on the first information and the second information ([0044]-[0046]).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6-10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Paulraj in view of Kekicheff et al (US Pub. No. 2019/0334888), hereafter, “Kekicheff.”
As to claim 6, Paulraj discloses the parent claim but does not disclose the information retrieved from the processor module comprises a random number generated by the second security module, wherein the second authentication key is based on the random number.
However, Kekicheff discloses information retrieved from a processor module comprises a random number generated by a second security module, wherein a second authentication key is based on the random number (Abstract, particularly, “A method of binding a device to an authority comprising reading pre-determined data corresponding to characteristics of the device. The method includes obtaining a pseudo-random number and combining it with the pre-determined data to generate a base number.”).
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Paulraj and Kekicheff in order to provide a reliable means to generate unique identifiers for devices to be used in later applications.
As to claim 7, the teachings of Paulraj and Kekicheff as combined for the same reasons set forth in claim 6’s rejection disclose the controller is to: retrieve a serial number from the processor module, wherein the second authentication key is based on the random number and the serial number (Kekicheff, Abstract and [0038], particularly, “In an embodiment, a model number, serial number, and operating system version can be used as the device-specific data.”)
As to claim 8, the teachings of Paulraj and Kekicheff as combined for the same reasons set forth in claim 6’s rejection disclose the serial number is set while the processor module is in a factory mode (Paulraj, [0033] and Kekicheff, [0037]-[0038]).
As to claim 9, the teachings of Paulraj and Kekicheff as combined for the same reasons set forth in claim 6’s rejection disclose the serial number is set by the second security module (Paulraj, [0033] and Kekicheff, [0037]-[0038]).
As to claim 10, the teachings of Paulraj and Kekicheff as combined for the same reasons set forth in claim 6’s rejection disclose after the setting of the serial number the processor module is transitioned to a production mode, wherein the information is retrieved by the first security module from the processor module in the production mode (Paulraj, [0033] and Kekicheff, [0037]-[0038]).
As to claim 12, Paulraj discloses the parent claim but does not disclose the first information comprises a serial number of the processor module, and the second information comprises a serial number of the second security module. However, Kekicheff discloses first information comprises a serial number of the processor module, and second information comprises a serial number of a second security module (Abstract and [0038], particularly, “In an embodiment, a model number, serial number, and operating system version can be used as the device-specific data.”)
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Paulraj and Kekicheff in order to provide a reliable means to generate unique identifiers for devices to be used in later applications.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS J DAILEY whose telephone number is (571)270-1246. The examiner can normally be reached 9:30am-6:00pm.
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, Umar Cheema can be reached on 571-270-3037. 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.
/THOMAS J DAILEY/ Primary Examiner, Art Unit 2458
Prosecution Insights