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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 12/12/2025 has been entered.
As per instant Amendment, Claims 1, 10 and 18 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. The new reference van der Kaay et al. (US 6393126) used to address the limitations.
The amended claims 1, 10 and 18 have been addressed in rejection 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 of this title, 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 1 and 3-9 are rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of Bangalore Sathyanarayana et al. (“Bangalore,” US 2022/0124118) and further in view of Van der Kaay et al. (“Kaay,” US 6393126).
Regarding claim 1: Jacquin discloses an Information Handling System (IHS) comprising:
a Baseboard Management Controller (BMC) (Jacquin: fig. 1 item 110 BMC), wherein the BMC comprises at least one memory (Jacquin: fig. 1 item 118 memory) coupled to at least one processor (Jacquin: fig. 1 item 120 processor), the at least one memory having program instructions stored thereon that, upon execution by the at least one processor, cause the BMC to:
after being attested by a requester using a device security certificate associated with the BMC (Jacquin: par. 0016 the platform can be brought up and the BMC can be configured to send a certificate signing request (CSR) to the CA. Based on the CSR received from the BMC, the CA associated with the platform manufacturer may verify the identity of the security processor and private key of BMC before providing an identity certificate to the BMC), obtain a system time value stored in the BMC (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108);
Jacquin does not explicitly disclose conforming to a Security Protocol and Data Model (SPDM) specification.
However, Bangalore discloses conforming to a Security Protocol and Data Model (SPDM) specification (Bangalore: par. 0024 a Security Protocol and Data Model (SPDM) specification [] the SPDM specification defines the request command and response command format for the message objects that may be exchanged between the BMC and the endpoints).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Bangalore with the system/method of Jacquin to include a Security Protocol and Data Model (SPDM) specification. One would have been motivated to verifying integrity of components to detect attacks and preventing data loss upon detection of attacks (Bangalore: par. 0001).
Jacquin in view of Bangalore does not explicitly disclose information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed, sign the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate and send the signed system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed to the requester.
However, Kaay discloses information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed (Kaay: col. 4 lines 48-51 the trusted master clock is certified to be synchronized with an accepted time standard, such as a national time server. The trusted local clock, which issues time stamps, is certified to be synchronized with the trusted master clock);
sign the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography; lines 63-67 through col. 5 lines 1-2 each issued time calibration certificate incorporates the time calibration certificate of the issuing clock. The time calibration certificate of the trusted local clock is then incorporated into the issued trusted temporal tokens [i.e., implies use of last trusted sync data]. Accordingly, the chain of certifications from which trusted time is derived from an accepted source is incorporated into each trusted temporal token); and
send the signed system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed to the requester (Kaay: col. 13 lines 49-60 at a first step 702, an application 208 sends a request, including the data to be time stamped, to the issuing TLC 206. The data, in most cases, will comprise a digest, created by a one-way hash function, of the electronic document to be time stamped. At a step 704, the TLC 206 receives the data and concatenates the data with the current time with a TCCert Log Pointer [] the TLC 206 then signs the concatenation to form the trusted temporal token [] at a step 706, the TLC 206 returns the trusted temporal token to the application 208).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Kaay with the system/method of Jacquin and Bangalore to include sign the system time value and the information associated with the resource of the most recent synchronization using the device security certificate. One would have been motivated for providing and verifying a trusted source of certified time wherein the time stamp can be validated and verified as synchronized with an accepted standard (Kaay: col. 1 lines 17-21).
Regarding claim 3: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Jacquin further discloses wherein the program instructions, upon execution, further cause the BMC to perform the acts of obtaining a system time value (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Kaay further discloses signing the system time value (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography), and sending the signed system time value at ongoing intervals (Kaay: col. 9 lines 38-42 a Time Calibration Certificate (TCCert) typically has a period during which it is valid. The range of accuracy specified by the TCCert during the valid period accounts; col. 11 lines 41-42 the TMC 204 then sends the TCCert to the NOC 210 for logging at a step 504).
The motivation is the same that of claim 1 above.
Regarding claim 4: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Jacquin further discloses wherein the program instructions, upon execution, further cause the BMC to perform the acts of obtaining a system time value (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Kaay further discloses signing the system time value (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography), and sending the signed system time value in response to a request from the requester (Kaay: col. 13 lines 56-60 the TLC 206 then signs the concatenation to form the trusted temporal token [] at a step 706, the TLC 206 returns the trusted temporal token to the application 208).
The motivation is the same that of claim 1 above.
Regarding claim 5: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Jacquin further discloses wherein the requester comprises a console (Jacquin: fig. 1 item 122 input/output interface).
Regarding claim 6: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 5.
Kaay further discloses upon receiving the data structure, determine whether the system time value is invalid (Kaay: col. 14 lines 25-28 at step 810, the NOC determines, by checking its databases, that the issuing TLC 206 did not possess a valid TCCert or that the TCCert is suspect, the process proceeds to step 816); and
generate an alert message based on the determination (Kaay: col. 14 lines 28-30 at step 816, the NOC 210 sends notification to the requesting application that the token cannot be authenticated).
The motivation is the same that of claim 1 above.
Regarding claim 7: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 6.
Bangalore further discloses wherein the program instructions, upon execution, further cause the console to generate instructions for inhibiting operation of the IHS based on the determination (Bangalore: par. 0040 on receiving the "DISCOVERY NOTIFY REQUEST" command, the BMC 102 may perform a partial discovery of the endpoint 106, restart the endpoint authentication and continue with the further communication).
The motivation is the same that of claim 1 above.
Regarding claim 8: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Bangalore further discloses wherein the device security certificate comprises a device identity certificate conforming to the SPDM specification (Bangalore: par. 0024 a Security Protocol and Data Model (SPDM) specification [] the SPDM specification defines the request command and response command format for the message objects that may be exchanged between the BMC and the endpoints).
The motivation is the same that of claim 1 above.
Regarding claim 9: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Jacquin further discloses wherein the program instructions, upon execution, further cause the BMC to obtain the system time value at ongoing intervals (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of Bangalore Sathyanarayana et al. (“Bangalore,” US 2022/0124118), van der Kaay et al. (“Kaay,” US 6393126) and MIKIO (“Mikio,” JP 2006333435 A).
Regarding claim 2: Jacquin in view of Bangalore and Kaay discloses the IHS of claim 1.
Jacquin in view of Bangalore and Kaay does not explicitly disclose combine the information with the system time value in a data structure, sign the data structure using the device security certificate and send the data structure to the requester.
However, Mikio discloses combine the information with the system time value in a data structure (Mikio: page 9, paragraph 7 the internal clock correction unit 17d corrects the internal clock 11 based on the correction signal received from the time comparison unit 17c, and synchronize the internal clock 11 with the standard time);
sign the data structure using the device security certificate (Mikio: page 3, paragraph 3 generating a first digital signature based [] the internal time information); and
send the data structure to the requester (Mikio: page 6, paragraph 3 function of outputting the serial number id, the internal time information t, and the obtained temporary time stamp).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Mikio with the system/method of Jacquin, Bangalore and Kaay to include sign the data structure using the device security certificate. One would have been motivated to providing an ideal environment where the internal clock and the security parameters of the portable terminal are protected within the tamper-resistant protection area (Mikio: page 2 paragraph 6).
Claim 10, 12-13 and 17-18 rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of van der Kaay et al. (“Kaay,” US 6393126).
Regarding claim 10: Jacquin discloses a time trustworthiness verification method comprising:
after being attested by a requester using a device security certificate associated with a Baseboard Management Controller (BMC) (Jacquin: fig. 1 item 110 BMC; par. 0016 the platform can be brought up and the BMC can be configured to send a certificate signing request (CSR) to the CA. Based on the CSR received from the BMC, the CA associated with the platform manufacturer may verify the identity of the security processor and private key of BMC before providing an identity certificate to the BMC), obtaining a system time value stored in the BMC (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Jacquin does not explicitly disclose information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed, signing the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate and sending the signed system time value, the information associated with the source of the most recent synchronization, and the last time at which the most recent synchronization was performed to the requester.
However, Kaay discloses information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed (Kaay: col. 4 lines 48-51 the trusted master clock is certified to be synchronized with an accepted time standard, such as a national time server. The trusted local clock, which issues time stamps, is certified to be synchronized with the trusted master clock);
signing the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography; lines 63-67 through col. 5 lines 1-2 each issued time calibration certificate incorporates the time calibration certificate of the issuing clock. The time calibration certificate of the trusted local clock is then incorporated into the issued trusted temporal tokens [i.e., implies use of last trusted sync data]. Accordingly, the chain of certifications from which trusted time is derived from an accepted source is incorporated into each trusted temporal token); and
sending the signed system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed to the requester (Kaay: col. 13 lines 49-60 at a first step 702, an application 208 sends a request, including the data to be time stamped, to the issuing TLC 206. The data, in most cases, will comprise a digest, created by a one-way hash function, of the electronic document to be time stamped. At a step 704, the TLC 206 receives the data and concatenates the data with the current time with a TCCert Log Pointer [] the TLC 206 then signs the concatenation to form the trusted temporal token [] at a step 706, the TLC 206 returns the trusted temporal token to the application 208).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Kaay with the system/method of Jacquin and Bangalore to include sign the system time value and the information associated with the resource of the most recent synchronization using the device security certificate. One would have been motivated for providing and verifying a trusted source of certified time wherein the time stamp can be validated and verified as synchronized with an accepted standard (Kaay: col. 1 lines 17-21).
Regarding claim 12: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin further discloses performing the acts of obtaining a system time value, signing the system time value, and sending the signed system time value at ongoing intervals (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Kaay further discloses signing the system time value (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography), and sending the signed system time value at ongoing intervals (Kaay: col. 9 lines 38-42 a Time Calibration Certificate (TCCert) typically has a period during which it is valid. The range of accuracy specified by the TCCert during the valid period accounts; col. 11 lines 41-42 the TMC 204 then sends the TCCert to the NOC 210 for logging at a step 504).
The motivation is the same that of claim 1 above.
Regarding claim 13: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin further discloses wherein the program instructions, upon execution, further cause the BMC to perform the acts of obtaining a system time value (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Kaay further discloses signing the system time value (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography), and sending the signed system time value at ongoing intervals (Kaay: col. 9 lines 38-42 a Time Calibration Certificate (TCCert) typically has a period during which it is valid. The range of accuracy specified by the TCCert during the valid period accounts; col. 11 lines 41-42 the TMC 204 then sends the TCCert to the NOC 210 for logging at a step 504).
The motivation is the same that of claim 1 above.
Regarding claim 17: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin further discloses obtaining the system time value at ongoing intervals (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108).
Regarding claim 18: Jacquin discloses a computer program product comprising a non-transitory computer readable storage medium having program instructions stored thereon that, upon execution by a Baseboard Management Controller (BMC) (Jacquin: fig. 1 item 110 BMC), cause the BMC to:
after being attested by a requester using a device security certificate associated with the BMC (Jacquin: par. 0016 the platform can be brought up and the BMC can be configured to send a certificate signing request (CSR) to the CA. Based on the CSR received from the BMC, the CA associated with the platform manufacturer may verify the identity of the security processor and private key of BMC before providing an identity certificate to the BMC), obtain a system time value stored in the BMC (Jacquin: par. 0043 the first command in the cryptographic audit session is to get (step 308) a time associated with an internal time of the security coprocessor 108; par. 0046 the validation tools may determine a first time and a second time associated with the security coprocessor 108).
Jacquin does not explicitly disclose information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed, sign the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate and send the signed system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed to the requester.
However, Kaay discloses information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization was performed (Kaay: col. 4 lines 48-51 the trusted master clock is certified to be synchronized with an accepted time standard, such as a national time server. The trusted local clock, which issues time stamps, is certified to be synchronized with the trusted master clock);
sign the system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed using the device security certificate (Kaay: col. 4 lines 52-53 time stamps and certifications are signed by the issuing device using public key cryptography; lines 63-67 through col. 5 lines 1-2 each issued time calibration certificate incorporates the time calibration certificate of the issuing clock. The time calibration certificate of the trusted local clock is then incorporated into the issued trusted temporal tokens [i.e., implies use of last trusted sync data]. Accordingly, the chain of certifications from which trusted time is derived from an accepted source is incorporated into each trusted temporal token); and
send the signed system time value, the information associated with the source of the most recent synchronization, and a last time at which the most recent synchronization was performed to the requester (Kaay: col. 13 lines 49-60 at a first step 702, an application 208 sends a request, including the data to be time stamped, to the issuing TLC 206. The data, in most cases, will comprise a digest, created by a one-way hash function, of the electronic document to be time stamped. At a step 704, the TLC 206 receives the data and concatenates the data with the current time with a TCCert Log Pointer [] the TLC 206 then signs the concatenation to form the trusted temporal token [] at a step 706, the TLC 206 returns the trusted temporal token to the application 208).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Kaay with the system/method of Jacquin and Bangalore to include sign the system time value and the information associated with the resource of the most recent synchronization using the device security certificate. One would have been motivated for providing and verifying a trusted source of certified time wherein the time stamp can be validated and verified as synchronized with an accepted standard (Kaay: col. 1 lines 17-21).
Claims 11, 14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of van der Kaay et al. (“Kaay,” US 6393126) and MIKIO (“Mikio,” JP 2006333435 A).
Regarding claim 11: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin in view of Kaay does not explicitly disclose combining the information with the system time value in a data structure, signing the data structure using the device security certificate and sending the data structure to the requester.
However, Mikio discloses combining the information with the system time value in a data structure (Mikio: page 9, paragraph 7 the internal clock correction unit 17d corrects the internal clock 11 based on the correction signal received from the time comparison unit 17c, and synchronizes the internal clock 11 with the standard time);
signing the data structure using the device security certificate (Mikio: page 3, paragraph 3 generating a first digital signature based [] the internal time information); and
sending the data structure to the requester (Mikio: page 6, paragraph 3 function of outputting the serial number id, the internal time information t, and the obtained temporary time stamp).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Mikio with the system/method of Jacquin and Kaay to include signing the data structure using the device security certificate. One would have been motivated to providing an ideal environment where the internal clock and the security parameters of the portable terminal are protected within the tamper-resistant protection area (Mikio: page 2 paragraph 6).
Regarding claim 14: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin further comprising: determining, using a console (Jacquin: fig. 1 item 122 input/output interface).
Jacquin in view of Kaay does not explicitly disclose whether the system time value is invalid upon receiving the data structure and generating, using the console, an alert message based on the determination.
However Mikio discloses whether the system time value is invalid upon receiving the data structure (Mikio: page 8, paragraph 3 the internal time verification unit 38 verifies whether the received internal time information t is valid based on the intermediate time information t2 received from the reception time determination unit 36); and
generating, using the console, an alert message based on the determination (Mikio: page 8, paragraph 3 if the verification result is within the allowable range [] the verification result indicates the validity [] the notification (OK) indicating that there is no abnormality in the area 25).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Mikio with the system/method of Jacquin and Kaay to include the system time value is invalid upon receiving the data structure and generating, using the console, an alert message based on the determination. One would have been motivated to providing an ideal environment where the internal clock and the security parameters of the portable terminal are protected within the tamper-resistant protection area (Mikio: page 2 paragraph 6).
Regarding claim 19: Claim 19 is similar in scope to claim 11, and is therefore rejected under similar rationale.
Regarding claim 20: Claim 20 is similar in scope to claim 14, and is therefore rejected under similar rationale.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of van der Kaay et al. (“Kaay,” US 6393126), MIKIO (“Mikio,” JP 2006333435 A) and Bangalore Sathyanarayana et al. (“Bangalore,” US 2022/0124118).
Regarding claim 15: Jacquin in view of Kaay, Mikio discloses the time trustworthiness verification method of claim 14.
Jacquin in view of Kaay and Mikio does not explicitly disclose generating, by the console, instructions for inhibiting operation of an Information Handling System (HIS) based on the determination.
However, Bangalore discloses generating, by the console, instructions for inhibiting operation of an Information Handling System (HIS) based on the determination (Bangalore: par. 0040 on receiving the "DISCOVERY NOTIFY REQUEST" command, the BMC 102 may perform a partial discovery of the endpoint 106, restart the endpoint authentication and continue with the further communication).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Bangalore with the system/method of Jacquin, Kaay and Mikio to include generating, by the console, instructions for inhibiting operation of an Information Handling System (HIS) based on the determination. One would have been motivated to verifying integrity of components to detect attacks and preventing data loss upon detection of attacks (Bangalore: par. 0001).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over JACQUIN et al. (“Jacquin,” US 2022/0278855) in view of van der Kaay et al. (“Kaay,” US 6393126) and Bangalore Sathyanarayana et al. (“Bangalore,” US 2022/0124118).
Regarding claim 16: Jacquin in view of Kaay discloses the time trustworthiness verification method of claim 10.
Jacquin in view of Kaay does not explicitly disclose wherein the device security certificate comprises a device identity certificate conforming to the SPDM specification.
However, Bangalore discloses wherein the device security certificate comprises a device identity certificate conforming to the SPDM specification (Bangalore: par. 0024 a Security Protocol and Data Model (SPDM) specification [] the SPDM specification defines the request command and response command format for the message objects that may be exchanged between the BMC and the endpoints).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Bangalore with the system/method of Jacquin and Mikio to include wherein the device security certificate comprises a device identity certificate conforming to the SPDM specification. One would have been motivated to verifying integrity of components to detect attacks and preventing data loss upon detection of attacks (Bangalore: par. 0001).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fahimeh Mohammadi whose telephone number is (571)270-7857. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Luu Pham can be reached at 5712705002. 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.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439