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 .
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 September 24, 2024 has been considered by the examiner.
Drawings
The drawing submitted on September 24, 2024 has been accepted.
Specification
The specification submitted on September 24, 2024 has been accepted.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a number of integrity measuring units in claim 1
an attestation Unit in claim 1
an integrity attestation in claim 1
a confirmation unit in claim 1
a checking unit in claim 1
an issuing unit in claim 1
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-14 are rejected under 35 U.S.C. 103 as being unpatentable over Pan et al. (US 20220116387 A1 –hereinafter—"Pan”) in view LIM et al. (US 20220210164 A1 –hereinafter-“LIM”).
As per claim 1. Pan discloses a computer-aided industrial device comprising:
a number of integrity measuring units for respectively providing an integrity measurement value ([0105] Network device has a trusted platform module (TPM for short). The TPM has a trusted component (also referred to as a root of trust) that cannot be tampered with, is absolutely trusted, and does not require external maintenance, and is an indispensable part of trustworthiness verification. Generally, the TPM has three roots of trust: a root of trust for measurement (RTM for short), a root of trust for storage (RTS for short), and a root of trust for reporting (RTR for short). The RTM is used to perform integrity measurement on a network device to which the RTM belongs, and is a computing component that is controlled by using a core root of trust for measurement (CRTM for short). The CRTM is execution code used by the TPM to execute the RTM, and is generally stored in a basic input/output system (BIOS for short). Because measurement information is generated by the RTM, the RTM may be used as an origin of transmitting trustworthiness-related measurement information. The integrity measurement may be measurement performed on software on the network device in each phase during running. The RTS is a component used to store integrity measurement and a measurement sequence, and may include a component for storage encryption and an encryption key. The RTR is a component that generates a report through calculation, and can reliably report the measurement information stored in the RTS. Reliability of the RTR component can be ensured by using a signature. The RTM, the RTS, and the RTR may exist in the TPM and the BIOS of the network device, and an expert or a skilled person may determine, through evaluation, whether a system status of the network device meets a trustworthiness standard. It should be noted that the TPM and the BIOS are generally considered as absolutely trustworthy modules);
an attestation unit to provide an integrity attestation protected by a first cryptographic protection for indicating an integrity of the device or of a part of the device ([0111] A network model shown in FIG. 2 shows a scenario of remote attestation. The scenario includes an attest platform 201, an attest server 202, a privacy certificate authority (CA for short) 203, and a user 204. The attest platform 201 may be a network device on which remote attestation needs to be performed, for example, a terminal, an internet of things (IoT for short) gateway, a network, or an application server. The attest platform 201 may include four parts: a central processing unit (CPU for short) & a TPM, a BIOS, a kernel, and an application (app for short), and is used to calculate and record an integrity value. [0112] During implementation, the attest platform 201 may securely send security attributes (for example, security attributes such as software and hardware integrity values, configuration information, and a node status) to the attest server 202 in a particular format and an interaction process by using a challenge-response interaction mechanism, and the attest server 202 performs remote attestation according to a particular policy, to finally attest whether the attest platform 201 is trustworthy. In addition, to ensure device and communication security in the entire remote attestation interaction process, a certificate mechanism (including certificate application and revocation) needs to be pre-deployed to support operations such as certificate verification and check in the interaction process. In one embodiment, the attest platform 201 encrypts and signs, by using a certificate obtained from the privacy CA 203, an integrity value recorded by the attest platform 201. The attest server 202 decrypts received information, and interacts with the privacy CA 203 to verify whether the certificate of the attest platform 201 is valid. The user 204 may check the certificate issued externally by the privacy CA 203, and check a result of remote attestation performed by the attest server 202 on the attest platform 201);
wherein the integrity attestation has a number of provided integrity measurement values ([0134] (7) Remote attestation content, which may include: (a) Hardware integrity value, that is, a set of measurement values generated by a hardware driver (for example, a startup driver) in the attester. (b) Software integrity value, that is, a set of measurement values generated by a dynamically changing object such as a process running in the attester. (c) Configuration information, that is, static data generated in the attester, such as configuration information and a file, and information generated during static measurement.); and
a confirmation unit connected to the attestation unit, the confirmation unit comprising: ([0114] The attester 301 is a to-be-verified device or application in the remote attestation system 300, and may be a switch, a router, a terminal, a personal computer (PC for short), the IoT, an application, or the like. The verifier 302 may be a server with a remote attestation function. The relying party 303 may be, for example, a network management device. In the remote attestation system 300, the relaying party 303 may simultaneously communicate with the attester 301 and the verifier 302 to exchange information during remote attestation. The supply chain entity Asserter 304 may be, for example, a network device of a device manufacturer. A process of implementing remote attestation may include: S11: The attester 301 calculates and collects various pieces of integrity attestation information of the attester 301 by using a root of trust, and provides the integrity attestation information for the relying party 303 as measurement information. S12: The relying party 303 receives the measurement information that is sent by the attester 301 and that is to be used for remote attestation, and verifies an identity of the attester 301 through signature authentication. S13: After the verification succeeds, the relying party 303 signs, by using a certificate of the relying party 303, the measurement information that is sent by the attester 301 and that is to be used for remote attestation, and sends the signature to the verifier 302. S14: The verifier 302 verifies the measurement information provided by the attester 301, and sends a attestation result to the relying party 303. Before S11 to S14, the asserter 304 is configured to provide configuration information such as an initial device ID for the attester 301, where the configuration information includes an integrity attestation reference value or standard value of the attester 301. The asserter 304 is further configured to send the reference value or standard value to the verifier 302, so that the verifier 302 can perform remote attestation. It should be noted that the attester 301 may correspond to the attest platform 201 in FIG. 2, and the verifier 302 may correspond to the attest server 202 in FIG. 2. [0121] The remote attestation mode negotiation method provided in the embodiments of this application may be as follows: A to-be-attested device Attester negotiates with a verification server Verifier/relying party. The negotiation may be initiated by the attester or the verifier/relaying party. It should be noted that the relaying party is separately connected to the verifier and the attester, and is used as a bridge for information exchange between the verifier and the attester. The relaying party and the verifier may be disposed in a same network device, or may be two independently disposed network devices.
a checking unit to provide checking information by checking a state of the confirmation unit and/or of the industrial device ([0133] (6) Remote attestation check mode, which may include: (a) The attester reports a attestation result to the verifier after local check: The attester may directly report the attestation result to the verifier for verification based on an integrity report of the local check. (b) The verifier checks evidence reported by the attester: The attester only reports an original integrity report, and the verifier verifies integrity. [0139] 6) Remote attestation check mode: (b) The verifier checks evidence reported by the attester); and
an issuing unit to issue a confirmation attestation protected by a second cryptographic protection depending on the provided checking information ([0184] An operation such as authorized signature authentication may be performed on the attester by using the Manufacturer Authorized Signing Authority (MASA for short). The MASA is used in a scenario of combining remote attestation and a bootstrapping remote secure key infrastructures (BRSKI for short) protocol of the IETF. The attester 301 calculates and collects various pieces of integrity attestation information of the attester 301 by using a root of trust, and provides the integrity attestation information for the relying party 303 as measurement information);
wherein the confirmation attestation comprises the number of integrity measurement values of the integrity attestation and information derivable from the first cryptographic protection of the integrity attestation ([0108] a process in which the network device performs measurement startup may include: Operation 1: A root of trust in the TPM provides a trust basis for a BIOS. Operation 2: The BIOS is started, to initialize a hardware system, check, by invoking the root of trust in the TPM, a signature of a loader to be run in a next phase, measure the loader and configuration information, and record a measurement value in the TPM. Operation 3: The loader is run, to obtain an operating system image file through location, check, by invoking the root of trust in the TPM, a signature of an operating system kernel to be run in a next phase, measure the kernel, and record a measurement value in the TPM. Operation 4: The kernel is run, to start an operating system, a security application, and the like, measure configuration information, and record a measurement value in the TPM. The foregoing startup process may be referred to as a measurement startup process. The measurement startup process is characterized by the following: In the system startup process, only measurement is performed and a measurement value is recorded, and the startup process is not affected, that is, startup is not stopped because a measurement value corresponding to a startup operation is untrustworthy. [0554] System trustworthiness verification on the network device on which remote attestation is to be performed may be performed first, and BRSKI protocol-based identity validity verification is performed only when a attestation result indicates that a system of the network device is trustworthy. When the system is untrustworthy, BRSKI protocol-based identity validity verification may not be performed, but the network device is directly prevented from accessing the network. In other cases, BRSKI protocol-based identity validity verification and system trustworthiness verification on the network device on which remote attestation is to be performed may be performed simultaneously. The network device is allowed to access the network only when the two pieces of verification succeed).
Pan does not explicitly disclose the connected attestation unit is via a physically protected transmission path. LIM, in analogous art however, discloses the connected attestation unit is via a physically protected transmission path ([0052] That is, at step S200, an encryption key may be shared using existing standard protocols (e.g., PANA, TLS, or the like) in order to protect messages transmitted in respective sections. [0134] Also, the measured individual attestation value to be used for detailed verification is encrypted with the encryption key shared in advance between the remote attestation management apparatus 100 and the device 20, whereby information about the remote attestation targets in the device may be protected such that the content thereof is prevented from being made known to the gateway 10. [0053] Messages transmitted and received in the following steps may be encrypted and decrypted using the shared encryption key. [0054] Here, it can be seen that a gateway 10 and a device 20 share the encryption key K.sub.i_DG therebetween, the gateway 10 and a remote attestation management apparatus 100 share the encryption key K.sub.j_GS therebetween, and the device 20 and the remote attestation management apparatus 100 share the encryption key K.sub.ij_DS therebetween. [0055] Also, in the method for managing remote attestation according to an embodiment of the present invention, the device may be registered at step S300. [0056] That is, at step S300, the reference value to be used in a remote attestation process may be registered along with basic information for device connection in order to manage remote attestation. [0057] A reference comprehensive attestation value (a first reference value) may be registered both in the gateway 10, to which the device 20 is connected, and in the remote attestation management apparatus 100, and a reference individual attestation value (a second reference value) may be registered only in the remote attestation management apparatus 100. [0058] Here, because step S300 is commonly performed when the device 20 is installed in an IoT service and first operated, invasion from the outside rarely occurs at this step. Therefore, the comprehensive and individual attestation values calculated at this time may be registered as the reference values to be used for the following remote attestation process).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of connecting the attestation unit disclosed by Pan is via a physically protected transmission path. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to significantly reduce load of processing remote attestation, which is increasing with the growing scale of IoT, thereby enabling remote attestation to be performed on a large number of devices even in future environments in which the scale of IoT is expected to increase as suggested by LIM (in [0010]).
As per claim 2: Pan in view of LIM discloses the industrial device as claimed in claim 1, wherein: that the first cryptographic protection comprises a first digital signature; and/or the second cryptographic protection comprises a second digital signature (Pan [0184] The attestation result may be used as one of conditions for whether the attester can access a network. If the system trustworthiness attestation result of the attester indicates that the system of the attester is trustworthy, the attester can access the network when another condition such as authorized signature authentication is met. If the system trustworthiness attestation result of the attester indicates that the system of the attester is untrustworthy, the attester cannot access the network even when another condition such as authorized signature authentication is met. An operation such as authorized signature authentication may be performed on the attester by using the Manufacturer Authorized Signing Authority (MASA for short). The MASA is used in a scenario of combining remote attestation and a bootstrapping remote secure key infrastructures (BRSKI for short) protocol of the IETF. For details, refer to related descriptions in an embodiment that is shown in FIG. 43A and FIG. 43B and that includes a remote attestation mode negotiation method and a remote attestation method in a BRSKI framework).
As per claim 3: Pan in view of LIM discloses the industrial device as claimed in claim 2, wherein: the attestation unit provides the cryptographically protected integrity attestation including the number of integrity measurement values and the first digital signature; and/or the confirmation unit provides the cryptographically protected confirmation attestation including at least the number of integrity measurement values and the first digital signature of the integrity attestation and the second digital signature of the confirmation attestation (Pan [0134] (7) Remote attestation content, which may include: (a) Hardware integrity value, that is, a set of measurement values generated by a hardware driver (for example, a startup driver) in the attester. (b) Software integrity value, that is, a set of measurement values generated by a dynamically changing object such as a process running in the attester. (c) Configuration information, that is, static data generated in the attester, such as configuration information and a file, and information generated during static measurement).
As per claim 4: Pan in view of LIM discloses the industrial device as claimed in claim 3, wherein the confirmation unit provides the cryptographically protected confirmation attestation including the number of integrity measurement values and the first digital signature of the integrity attestation, the second digital signature of the confirmation attestation, and the checking information and/or information derivable from the checking information indicative of the formation of the confirmation attestation in the confirmation unit (Pan [0114] The supply chain entity Asserter 304 may be, for example, a network device of a device manufacturer. A process of implementing remote attestation may include: S11: The attester 301 calculates and collects various pieces of integrity attestation information of the attester 301 by using a root of trust, and provides the integrity attestation information for the relying party 303 as measurement information. S12: The relying party 303 receives the measurement information that is sent by the attester 301 and that is to be used for remote attestation, and verifies an identity of the attester 301 through signature authentication. S13: After the verification succeeds, the relying party 303 signs, by using a certificate of the relying party 303, the measurement information that is sent by the attester 301 and that is to be used for remote attestation, and sends the signature to the verifier 302. S14: The verifier 302 verifies the measurement information provided by the attester 301, and sends a attestation result to the relying party 303. Before S11 to S14, the asserter 304 is configured to provide configuration information such as an initial device ID for the attester 301, where the configuration information includes an integrity attestation reference value or standard value of the attester 301).
As per claim 5: Pan in view of LIM discloses the industrial device as claimed in claim 1, wherein: the attestation unit includes a first storage unit secured against external access for storing a first cryptographic credential assigned to the first cryptographic protection; and/or the confirmation unit includes an updatable second storage unit for storing a second cryptographic credential assigned to the second cryptographic protection (Pan [0105] Generally, the TPM has three roots of trust: a root of trust for measurement (RTM for short), a root of trust for storage (RTS for short), and a root of trust for reporting (RTR for short). The RTM is used to perform integrity measurement on a network device to which the RTM belongs, and is a computing component that is controlled by using a core root of trust for measurement (CRTM for short). The CRTM is execution code used by the TPM to execute the RTM, and is generally stored in a basic input/output system (BIOS for short). Because measurement information is generated by the RTM, the RTM may be used as an origin of transmitting trustworthiness-related measurement information. The integrity measurement may be measurement performed on software on the network device in each phase during running. The RTS is a component used to store integrity measurement and a measurement sequence, and may include a component for storage encryption and an encryption key. The RTR is a component that generates a report through calculation, and can reliably report the measurement information stored in the RTS. Reliability of the RTR component can be ensured by using a signature. The RTM, the RTS, and the RTR may exist in the TPM and the BIOS of the network device, and an expert or a skilled person may determine, through evaluation, whether a system status of the network device meets a trustworthiness standard).
As per claim 6: Pan in view of LIM discloses the industrial device as claimed in claim 5, wherein: the first cryptographic protection comprises a first digital signature and the first cryptographic credential comprises a private key assigned to the first digital signature; and/or the second cryptographic protection comprises a second digital signature and the second cryptographic credential comprises a private key assigned to the second digital signature (LIM [0022] Here, identifying the device, the integrity of which is damaged, may be configured such that the gateway decrypts the encrypted first attestation values using first encryption keys previously registered and shared with the devices. [0025] Here, performing the operation for responding to the object, the integrity of which is damaged, may be configured to decrypt the encrypted second attestation value using a second encryption key previously registered and shared with the device, the integrity of which is damaged).
As per claim 7: Pan in view of LIM discloses the industrial device as claimed in a claim 1, wherein the checking unit is connected to a number of physical sensors of the industrial device providing sensor signals indicative of the state of the confirmation unit and/or of the industrial device (LIM [0105]: TABLE-US-00002 TABLE 2 device measured GW connection reference comprehensive connection information comprehensive attestation value information device (e.g., IP attestation value (current value) GW ID (e.g., IP) ID address) (CAV.sub.REF) (CAV.sub.REF) . . . GW123 111.222.3.5 IoT101 20.20.0.19 4f0651d8 . . . 49600b0a 4f0651d8 . . . 49600b0a GW123 111.222.3.5 IoT102 20.20.0.20 dbe69e13 . . . 5a76e59c dbe69e13 . . . 5a76e59c . . . . . . . . . . . ).
As per claim 8: Pan in view of LIM discloses the industrial device as claimed in claim 1, wherein the checking unit is configured to: check a firmware status of the confirmation unit; check an output signal of a housing circuit breaker of the industrial device; check an output signal of a tamper protection sensor of the industrial device; check an output signal of a voltage sensor for monitoring a voltage supply of the industrial device; and/or check whether a present temperature yielded by a temperature sensor the industrial device lies within a predetermined temperature range (LIM: [0045] As the comprehensive attestation value, a chained hash value that is formed by connecting the respective hash values of the targets that need to be verified in the device (e.g., firmware, a boot image, important executable files, settings configuration files, and the like) may be used).
As per claim 9: Pan in view of LIM discloses the industrial device as claimed in claim 1, wherein the attestation unit comprises a tamperproof computing apparatus (Pan [0105] It may be understood that the network device has a trusted platform module (TPM for short). The TPM has a trusted component (also referred to as a root of trust) that cannot be tampered with, is absolutely trusted, and does not require external maintenance, and is an indispensable part of trustworthiness verification).
As per claim 10: Pan in view of LIM discloses the industrial device as claimed in claim 1, further comprising a single housing, in which the attestation unit, the confirmation unit, and the physically protected transmission path connecting the attestation unit and the confirmation unit are arranged (Pan [0105] It may be understood that the network device has a trusted platform module (TPM for short). The TPM has a trusted component (also referred to as a root of trust) that cannot be tampered with, is absolutely trusted, and does not require external maintenance, and is an indispensable part of trustworthiness verification).
As per claim 11: Pan in view of LIM discloses the industrial device as claimed in claim 1, further comprising a housing with the attestation unit arranged therein; Wherein the confirmation unit comprises an attachment module for attachment to a bus of the industrial device (Pan [0111] A network model shown in FIG. 2 shows a scenario of remote attestation. The scenario includes an attest platform 201, an attest server 202, a privacy certificate authority (CA for short) 203, and a user 204. The attest platform 201 may be a network device on which remote attestation needs to be performed, for example, a terminal, an internet of things (IoT for short) gateway, a network, or an application server. The attest platform 201 may include four parts: a central processing unit (CPU for short) & a TPM, a BIOS, a kernel, and an application (app for short), and is used to calculate and record an integrity value).
As per claim 12: Pan in view of LIM discloses the industrial device as claimed in claim 1, further comprising a slide-in housing, wherein at one of the confirmation unit or the confirmation unit and the attestation unit comprises a slide-in module for insertion into the slide-in housing (LIM [0044] Each of the devices 20 may generate an integrity verification value, based on which the state of integrity thereof can be verified, and provide the same in response to a request for integrity verification. The integrity verification value may be classified as a comprehensive attestation value used for the first verification or an individual attestation value used for the second verification. [0045] As the comprehensive attestation value, a chained hash value that is formed by connecting the respective hash values of the targets that need to be verified in the device (e.g., firmware, a boot image, important executable files, settings configuration files, and the like) may be used).
As per claim 13: It is directed to a system comprising: a backend system; a computer-aided industrial device; and a network connecting the backend system to the industrial device (See Figure 2: Attest platform 201 and Attest server ;202 ) wherein the industrial device is having substantially similar limitation of claim 1 and therefore limitation of claim 13 is rejected with the same rationale given above to reject corresponding limitation of claim 1.
As per claim 14. It is directed to a method for operating a computer-aided industrial device, the method having substantially similar claimed limitation of claim 14 and therefore claim 14 is rejected with the same rationale given above to reject claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Walker et al. (US 20170180341 A1) discloses a device that stores a secret in volatile or power-loss-sensitive memory and uses that secret to generate attestation data that can later be checked by another device or backend system. Because the secret is lost when power is removed, a tampered or rebooted device should fail attestation the next time it is queried. The device may also generate sensor log data and bind that log data to the attestation data, so the backend can validate both the device and the readings. This lets simple hardware provide a practical integrity signal without relying on expensive security components.
LIU et al. (US 20190364042 A1) uses hash-based multi-time signatures to authenticate both the verifier’s request and the prover’s response in a remote attestation exchange. The verifier signs the attestation request with its own MTS private key, and the prover validates that signature before revealing attestation information. The prover then signs the attestation reply with its own MTS private key, enabling the verifier to confirm integrity and origin. The scheme relies on secure storage for the HBS private keys and may update the authentication path offline to reduce runtime cost.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408
Prosecution Insights