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 Office Action is in response to the Amendment filed on 05/13/2026.
In the instant Amendment, claims 1, 10, and 18 have been amended; and claims 1, 10, and 18 are independent claims. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 05/13/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “neither cited portion of Kaay teaches or suggests that information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization of the system time with the source was performed.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Kaay discloses information associated with a source of the most recent synchronization, and a last time at which the most recent synchronization of the system time with the source 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). More specifically, Kaay discloses Each TMC 204 has a set of TLCs that it is responsible for time certifying [col. 7 lines 57-58] and If the received TCCert is equal to or greater than 24 hours old, the TMC measures the TLC's time offset, computes the time correction, and sends this correction to the 1LC clock to keep it within specification. The offset is again measured, and if the 1LC clock is within specification, the TMC issues a TCCert to the TLC stating that it is within a certain offset from UTC. It is expected that the TMC will certify the 1LC to be within 100 ms of UTC [col. 12 lines 59-67]. Therefore, the examiner finds this argument not persuasive.
Applicant’s arguments: “neither cited portion of Kaay teaches or suggests sign the 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 using the device security certificate.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Kaay discloses sign the 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 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). More specifically, Kaay discloses the TLC 206 must be able to verify that it is indeed a valid TMC 204 that is adjusting its time. In accordance with this first aspect, trusted temporal tokens preferably include the signed time calibration certification of the certifying clock. The NOC 210, through its PKI authentication capabilities, provides a system through which trusted time can be traced to the NTA Trusted Time Server (NTTS) 202 from any TLC 206 through authenticated time calibration certifications. In other words, the source of time from which a trusted temporal token has been derived can be traced back through signed time certifications to the NTTS 202. A second aspect in which PK.I authentication supports the TTI system is in authentication of temporal tokens themselves. The trusted temporal token includes a signed concatenation of a digest of the message to be time stamped as well as the time calibration certification of the issuing TLC 206. This signed concatenation allows the authenticity of the temporal token itself to be verified as being unaltered and issued by a particular TLC 206 [col. 6 lines 59-67 through col. 7 lines 1-11]. Therefore, the examiner finds this argument not persuasive.
Applicant’s arguments: “neither cited portion of Kaay teaches or suggests 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.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Kaay discloses 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). More specifically, Kaay discloses the Trusted Time Infrastructure (TTI) provides a system for commercial or private timing distribution services to deliver to the application layer a "trusted temporal token" or "trusted time stamp" that cryptographically binds the current time of day derived from the NTA to a unique data request submitted by an application [col. 6 lines 1-6] and the NTTS 202 certifies a TMC 204, sends a TCCert to the TMC 204, and records the certification locally. The TMC 204 then sends the TCCert to the NOC 210 for logging at a step 504. At this point, the TMC 204 possesses a valid TCCert and is capable of time certifying other lower clocks. At a step 506, the TM C 204 time certifies a 1LC 206, sends a TCCert to the TLC 206, and records the certification. The TMC 204 also retrieves from the TLC 206 the number of trusted temporal tokens that the TLC 206 has issued since the last certification [] the TMC 204 sends the TCCert and the token count of the TLC 206 to the NOC 210 for logging [col. 11 lines 9-21]. Therefore, the examiner finds this argument not persuasive.
A substantially similar rejection to the previous non-final rejection follows 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 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 of the system time with the source was performed, sign the 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 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 of the system time with the source 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 the 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 of the system time with the resource was performed, signing the 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 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 of the system time with the resource 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 the 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 of the system time with the resource was performed, sign the 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 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 of the system time with the resource 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 the 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 Bangalore and 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
THIS ACTION IS MADE FINAL. 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 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
Prosecution Insights