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 .
Response to Amendment
The amendment filed on 03/11/2026 has been accepted and considered in this office action. No claims have been amended. No claims have been canceled. No new claims have been newly added.
Response to Arguments
Applicant’s arguments, filed on 03/11/2026, with respect to the amended limitations of the independent claims have been fully considered and are not persuasive.
Applicant respectfully submits that the cited reference Duge alone or in combination with other cited references fails to teach or suggest all of the claim limitation. The argument is not persuasive. It is well-settled patent law that in a rejection under 35 U.S.C. 103, the claimed invention is evaluated against the combined teachings of the prior art, not each reference individually. One cannot show non obviousness by attacking references individually where the rejections are based on combinations of references. The rejection does not rely on Duge alone to teach the entire claimed system; rather, it relies on the combined teachings of Skertic, Rao, and Duge.
Applicant argues that Duge describes performing digital certification authentication and verification in a centralized system. Even if Duge uses a central host/controller, that does not distinguish the claim because the claim itself recites an engine control. The claim expressly recites that the distributed decentralized control system comprises “the plurality of nodes and an engine control.” Moreover, Duge is not relied upon to teach the distributed ledger architecture; Skertic and Rao are relied upon for that feature. Duge is relied upon for teaching hardware-backed authentication using security processors, trusted platform modules, hardware security modules, certificates, and cryptographic keys.
Applicant argues that Duge does not teach “Wherein each of the plurality of nodes includes a hardware security module.” This is not persuasive. Duge [para 35] teaches that each smart package (node) receives its own unique digital certificate, client private key, and client public key, and that these credentials are flashed into flash memory disposed within security processors of the smart package itself. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. Therefore, applying Duge’s teaching to Skertic’s [para 0007-0009] smart nodes simply mean equipping each local nodes with an HSM/TMP to house the cryptographic data.
Applicant argues that Duge does not teach the authentication of node configuration data. This argument is not persuasive. Duge [para 66] discloses a mechanism where a host challenges a smart package client to hash an internally stored dataset containing its software code/firmware, part number, serial number, and/or date of manufacture. The host performs a reciprocal hash on copy of the same dataset stored on the host, authorizing the smart package client only if the hash matches. [para 80] Duge discloses that this technology is used to validate component’s source, function, and configuration which under broadest reasonable interpretation refers to the claimed authenticating the node configuration data.
Applicant argues that Duge does not teach the hardware security module to verify integrity of the digital ledger. This limitation is taught by the combination of Skertic and Duge. Skertic [para 33] discloses control module determining control hashes for each node based on information stored in a block of the central blockchain ledger associated with the preceding start/event. Skertic [para 34] discloses comparing the determined control hash with the hash of the message or the preceding hash and states that this ensures the data has not been tampered with subsequent the hashing. Duge [para 35] teaches that each smart package (node) receives its own unique digital certificate, client private key, and client public key, and that these credentials are flashed into flash memory disposed within security processors of the smart package itself. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. It would have been obvious to use Duge’s HSM/security processor in each Skertic node to perform or support the cryptographic hash/signature verification used to verify the integrity of the digital ledger because doing so protects the trusted keys, certificates and hashes from compromise.
Applicant argues that Duge does not teach the hardware security module to provide hardware root of trust. This argument is not persuasive. Duge [para 43] teaches a hardware root of trust because the integrity check during the power-up and software launching sequences is based on a trusted hash stored in a secure hardware device. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. It suggests a hardware root of trust because integrity check begins from trusted hashes, certificate and keys stored in secure hardware, such as TPM, or HSM.
Therefore, the applicant’s argument is ultimately not persuasive.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
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, 3-6, 9, 11-13, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Skertic (EP 3672196 A1) (Cited on prior Office Action mailed on 9/25/2024) in view of Rao (US 11368304 B2) in view of Duge (EP 3672197 A1).
Regarding Claim 1, Skertic teaches:
distributing a digital ledger among a plurality of nodes of a distributed decentralized control system for an aircraft engine, the distributed decentralized control system comprising the plurality of nodes and an engine control (Skertic, [0007]-[0009] provides for a distributed control system including a blockchain or distributed ledger being used within the engine, including the control module for the engine, Skertic further discloses that the engine having a control module and smart nodes)
responsive to the occurrence of a trigger event, performing a security approval for each of the plurality of nodes based at least in part on node configuration data for each of the plurality of nodes and a system configuration block (Skertic, [0008] discloses that when the engine is started, the system compares a hash of the current configuration data of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the nodes before allowing engine start)
wherein the security approval confirms whether each of the plurality of nodes is authorized, wherein each node of the plurality of nodes has a unique node configuration data associated therewith (Skertic, para [0008], lines 4-18, discloses that when the engine is started, the system compares the configuration data (e.g., hash) of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the node before allowing it to function; page 6, para [0034], lines 26-27, Skertic further discloses each smart node associate with a serial number; see also Figs 6-7 and associated description)
responsive to confirming that each of the plurality of nodes is authorized, updating the digital ledger among the plurality of nodes and the engine control (Skertic, page 6, para [0035], lines 33-37, discloses that based upon the comparison, the authenticity and other features of the smart node may be confirmed and the startup operation may proceed. In addition, the central block chain as well as the local node block chains may be updated as a function of the received message).
Wherein each of the plurality of nodes includes a security mechanism to verify integrity of digital ledger (Skertic, para [0032-0037], discloses the need for cybersecurity and securing multiple node data using hashing and encryption. Skertic [para 33] discloses control module determining control hashes for each node based on information stored in a block of the central blockchain ledger associated with the preceding start/event. Skertic [para 34] discloses comparing the determined control hash with the hash of the message or the preceding hash and states that this ensures the data has not been tampered with subsequent the hashing.)
Skertic does not teach; However, Rao teaches:
wherein distributing the digital ledger includes exchanging, via the plurality of nodes, ledger information between a first node among the plurality of nodes and a second node among the plurality of nodes (Rao, Column 7, lines 62-67, discloses that nodes 110b-110d communicates with each other via a network in order to create, transfer, and update the parts of the digital logbook, See Fig 1 and Fig 2; Col 5, lines 9-20, Rao discloses peer-to-peer blockchain architecture where nodes 110a-110d communicate with each other).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic’s system to incorporate the teaching of Rao’s technique of implementing plurality of node in such a way they exchange ledger information directly between one another. One would be motivated to make this modification on Skertic’s system by incorporating Rao’s node-to-node communication to increase redundancy and availability of digital logbook information, improve resistance to single-point compromise or loss of data, and strengthen the tamper-resistant character of the blockchain by distributing digital logbook information among multiple nodes.
Skertic/Rao does not explicitly teach; However, Duge teaches:
Wherein the security mechanism comprises hardware security module to authenticate the node configuration data (Duge [para 66] discloses a mechanism where a host challenges a smart package client to hash an internally stored dataset containing its software code/firmware, part number, serial number, and/or date of manufacture. The host performs a reciprocal hash on copy of the same dataset stored on the host, authorizing the smart package client only if the hash matches. [para 80] Duge discloses that this technology is used to validate component’s source, function, and configuration which under broadest reasonable interpretation refers to the claimed authenticating the node configuration data.);
and provide hardware root of trust (Duge [para 43] teaches a hardware root of trust because the integrity check during the power-up and software launching sequences is based on a trusted hash stored in a secure hardware device. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. It suggests a hardware root of trust because integrity check begins from trusted hashes, certificate and keys stored in secure hardware, such as TPM, or HSM.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao’s system to incorporate the teaching of Duge’s Hardware security module-based trust anchor for authentication and providing root of trust. One would be motivated to make this modification on Skertic/Rao’s system to protect the cryptographic keys, certificates, hashes to validate component’s source, function, and configuration and to provide hardware trust anchor for nodes participating in digital logbook updates. Doing so would improve node level security, ensuring authenticated participation in blockchain ledger updates, and securing the system against counterfeit or malicious nodes.
Regarding Claim 3, Skertic/Rao/Duge teaches the method of claim 1:
Skertic teaches:
Wherein at least one of the plurality of nodes is a sensor (Skertic, page 5, para [0024], lines 5-6, discloses that smart sensor and smart actuator are referred to as smart nodes in Fig. 4).
Regarding Claim 4, Skertic/Rao/Duge teaches the method of claim 1:
Skertic teaches:
Wherein at least one of the plurality of nodes is an actuator (Skertic, page 5, para [0024], lines 5-6, discloses that smart sensor and smart actuator are referred to as smart nodes in Fig. 4).
Regarding Claim 5, Skertic/Rao/Duge teaches the method of claim 1:
Skertic teaches:
Wherein the engine control is a full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses that the control node may be FADEC).
Regarding Claim 6, Skertic/Rao/Duge teaches the method of claim 1:
Skertic teaches:
Wherein performing the security approval comprises: receiving, by the engine control, the unique node configuration data from each of the plurality of nodes (Skertic, page 5, para [0031], lines 37-47, discloses that the control module receive message transmitted by nodes which includes a hash of a digital certificate maintained at the node, the hash may further include data related to the node, as well as a preceding hash. (see, Fig 6.))
authenticating, by the engine control, each of the plurality of nodes using a public key (Skertic, page 6, para [0033], lines 6-9, discloses that upon receiving the hash from each of the nodes, the control module using a corresponding public or private key from the key pair, decrypts the message from each of the nodes; page 6, para [0035], lines 33-35, Skertic further discloses that based on the comparison, the authenticity of smart node may be confirmed.)
updating, by the engine control, the digital ledger (Skertic, page 6, para [0035], lines 33-37, discloses that the central block chain will be updated based on the received message from the control module)
transmitting, by the engine control, the system configuration block to each of the plurality of nodes, wherein each of the plurality of nodes updates the digital ledger based at least in part on the system configuration block (Skertic, page 6, para [0035], lines 33-37, discloses that the local node block chains will be updated based on the received message from the control module).
Regarding Claim 9, Skertic teaches:
A full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses the control node may be, for example, a FADEC) comprising: a memory comprising computer readable instructions; and a processing device for executing the computer readable instructions, the computer readable instructions controlling the processing device to perform operations comprising: (Skertic, page 4, para [0019], lines 1-12, discloses computer readable medium, processing unit)
distributing a digital ledger among a plurality of nodes (Skertic, page 2, para [0007], lines 46-49, discloses a blockchain or distributed ledger being used within the engine to maintain secure communication between various parts of the engine; page 3, para [0008], lines 3-4, Skertic further discloses that the engine having a control module and smart nodes)
of a distributed decentralized control system for an aircraft engine (Skertic, page 3, para [0009], lines 46-47, discloses that the control module and smart nodes may be arranged in a DCS (Distributed Control System) architecture; page 3, para [0008], line 6, aircraft engine)
the distributed decentralized control system comprising the plurality of nodes and the
full authority digital engine control (Skertic, page 3, para [0009], lines 46-47, discloses that the control module and smart nodes may be arranged in a DCS (Distributed Control System) architecture)
responsive to the occurrence of a trigger event, performing a security approval for each of the plurality of nodes based at least in part on node configuration data for each of the plurality of nodes and a system configuration block (Skertic, page 3, para [0008], lines 4-18, discloses that when the engine is started, the system compares the configuration data (e.g., hash) of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the node before allowing it to function)
wherein the security approval confirms whether each of the plurality of nodes is authorized, wherein each node of the plurality of nodes has a unique node configuration data associated therewith (Skertic, para [0008], lines 4-18, discloses that when the engine is started, the system compares the configuration data (e.g., hash) of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the node before allowing it to function; page 6, para [0034], lines 26-27, Skertic further discloses each smart node associate with a serial number)
and responsive to confirming that each of the plurality of nodes is authorized, updating the digital ledger among the plurality of nodes and the full authority digital engine control (Skertic, page 6, para [0035], lines 33-37, discloses that based upon the comparison, the authenticity and other features of the smart node may be confirmed and the startup operation may proceed. In addition, the central block chain as well as the local node block chains may be updated as a function of the received message).
Wherein each of the plurality of nodes includes a security mechanism to verify integrity of digital ledger (Skertic, para [0032-0037], discloses the need for cybersecurity and securing multiple node data using hashing and encryption. Skertic [para 33] discloses control module determining control hashes for each node based on information stored in a block of the central blockchain ledger associated with the preceding start/event. Skertic [para 34] discloses comparing the determined control hash with the hash of the message or the preceding hash and states that this ensures the data has not been tampered with subsequent the hashing.)
Skertic does not teach; However, Rao teaches:
wherein distributing the digital ledger includes exchanging, via the plurality of nodes, ledger information between a first node among the plurality of nodes and a second node among the plurality of nodes (Rao, Column 7, lines 62-67, discloses that nodes 110b-110d communicates with each other via a network in order to create, transfer, and update the parts of the digital logbook, See Fig 1 and Fig 2; Col 5, lines 9-20, Rao discloses peer-to-peer blockchain architecture where nodes 110a-110d communicate with each other).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic’s system to incorporate the teaching of Rao’s technique of implementing plurality of node in such a way they exchange ledger information directly between one another. One would be motivated to make this modification on Skertic’s system by incorporating Rao’s node-to-node communication to increase redundancy and availability of digital logbook information, improve resistance to single-point compromise or loss of data, and strengthen the tamper-resistant character of the blockchain by distributing digital logbook information among multiple nodes.
Skertic/Rao does not explicitly teach; However, Duge teaches:
Wherein the security mechanism comprises hardware security module to authenticate the node configuration data (Duge [para 66] discloses a mechanism where a host challenges a smart package client to hash an internally stored dataset containing its software code/firmware, part number, serial number, and/or date of manufacture. The host performs a reciprocal hash on copy of the same dataset stored on the host, authorizing the smart package client only if the hash matches. [para 80] Duge discloses that this technology is used to validate component’s source, function, and configuration which under broadest reasonable interpretation refers to the claimed authenticating the node configuration data.);
and provide hardware root of trust (Duge [para 43] teaches a hardware root of trust because the integrity check during the power-up and software launching sequences is based on a trusted hash stored in a secure hardware device. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. It suggests a hardware root of trust because integrity check begins from trusted hashes, certificate and keys stored in secure hardware, such as TPM, or HSM.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao’s system to incorporate the teaching of Duge’s Hardware security module-based trust anchor for authentication and providing root of trust. One would be motivated to make this modification on Skertic/Rao’s system to protect the cryptographic keys, certificates, hashes to validate component’s source, function, and configuration and to provide hardware trust anchor for nodes participating in digital logbook updates. Doing so would improve node level security, ensuring authenticated participation in blockchain ledger updates, and securing the system against counterfeit or malicious nodes.
Regarding Claim 11, Skertic/Rao/Duge teaches the full authority digital engine control of claim 9:
Skertic teaches:
Wherein at least one of the plurality of nodes is a sensor (Skertic, page 5, para [0024], lines 5-6, discloses that smart sensor and smart actuator are referred to as smart nodes in Fig. 4).
Regarding Claim 12, Skertic/Rao/Duge teaches the full authority digital engine control of claim 9:
Skertic teaches:
Wherein at least one of the plurality of nodes is an actuator (Skertic, page 5, para [0024], lines 5-6, discloses that smart sensor and smart actuator are referred to as smart nodes in Fig. 4).
Regarding Claim 13, Skertic/Rao/Duge teaches the full authority digital engine control of claim 9:
Skertic teaches:
Wherein performing the security approval comprises: receiving, by the full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses the control node may be, for example, a FADEC), the unique node configuration data from each of the plurality of nodes (Skertic, page 5, para [0031], lines 37-47, discloses that the control module receive message transmitted by nodes which includes a hash of a digital certificate maintained at the node, the hash may further include data related to the node, as well as a preceding hash. (see, Fig 6.))
authenticating, by the full authority digital engine control, each of the plurality of nodes using a public key (Skertic, page 6, para [0033], lines 6-9, discloses that upon receiving the hash from each of the nodes, the control module using a corresponding public or private key from the key pair, decrypts the message from each of the nodes; page 6, para [0035], lines 33-35, Skertic further discloses that based on the comparison, the authenticity of smart node may be confirmed.)
updating, by the full authority digital engine control, the digital ledger (Skertic, page 6, para [0035], lines 33-37, discloses that the central block chain will be updated based on the received message from the control module)
and transmitting, by the full authority digital engine control, the system configuration block to each of the plurality of nodes, wherein each of the plurality of nodes updates the digital ledger based at least in part on the system configuration block (Skertic, page 6, para [0035], lines 33-37, discloses that the local node block chains will be updated based on the received message from the control module).
Regarding Claim 16, Skertic teaches:
A distributed decentralized control system comprising: (Skertic, page 3, para [0009], lines 46-47, discloses that the control module and smart nodes may be arranged in a DCS (Distributed Control System) architecture; page 3, para [0008], line 6, aircraft engine)
a plurality of nodes; and a controller to: (Skertic, page 3, para [0009], lines 46-47, discloses that the control module and smart nodes may be arranged in a DCS (Distributed Control System) architecture)
provide a digital ledger to the plurality of nodes (Skertic, page 2, para [0007], lines 46-49, discloses a blockchain or distributed ledger being used within the engine to maintain secure communication between various parts of the engine; page 3, para [0008], lines 3-4, Skertic further discloses that the engine having a control module and smart nodes)
responsive to the occurrence of a trigger event, perform a security approval for each of the plurality of nodes based at least in part on node configuration data for each of the plurality of nodes and a system configuration block (Skertic, page 3, para [0008], lines 4-18, discloses that when the engine is started, the system compares the configuration data (e.g., hash) of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the node before allowing it to function)
wherein the security approval confirms whether each of the plurality of nodes is authorized, wherein each node of the plurality of nodes has a unique node configuration data associated therewith (Skertic, para [0008], lines 4-18, discloses that when the engine is started, the system compares the configuration data (e.g., hash) of each node to the previously stored data (e.g., control hash) to ensure the authenticity of the node before allowing it to function; page 6, para [0034], lines 26-27, Skertic further discloses each smart node associate with a serial number)
and responsive to confirming that each of the plurality of nodes is authorized, update the digital ledger among the plurality of nodes and the controller (Skertic, page 6, para [0035], lines 33-37, discloses that based upon the comparison, the authenticity and other features of the smart node may be confirmed and the startup operation may proceed. In addition, the central block chain as well as the local node block chains may be updated as a function of the received message).
Wherein each of the plurality of nodes includes a security mechanism to verify integrity of digital ledger (Skertic, para [0032-0037], discloses the need for cybersecurity and securing multiple node data using hashing and encryption. Skertic [para 33] discloses control module determining control hashes for each node based on information stored in a block of the central blockchain ledger associated with the preceding start/event. Skertic [para 34] discloses comparing the determined control hash with the hash of the message or the preceding hash and states that this ensures the data has not been tampered with subsequent the hashing.)
Skertic does not teach; However, Rao teaches:
wherein the plurality of nodes exchange ledger information corresponding to the digital ledger between one another, exchange of the ledger information exchanging, via the plurality of nodes, ledger information between a first node among the plurality of nodes and a second node among the plurality of nodes, (Rao, Column 7, lines 62-67, discloses that nodes 110b-110d communicates with each other via a network in order to create, transfer, and update the parts of the digital logbook, See Fig 1 and Fig 2; Col 5, lines 9-20, Rao discloses peer-to-peer blockchain architecture where nodes 110a-110d communicate with each other).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic’s system to incorporate the teaching of Rao’s technique of implementing plurality of node in such a way they exchange ledger information directly between one another. One would be motivated to make this modification on Skertic’s system by incorporating Rao’s node-to-node communication to increase redundancy and availability of digital logbook information, improve resistance to single-point compromise or loss of data, and strengthen the tamper-resistant character of the blockchain by distributing digital logbook information among multiple nodes.
Skertic/Rao does not explicitly teach; However, Duge teaches:
Wherein the security mechanism comprises hardware security module to authenticate the node configuration data (Duge [para 66] discloses a mechanism where a host challenges a smart package client to hash an internally stored dataset containing its software code/firmware, part number, serial number, and/or date of manufacture. The host performs a reciprocal hash on copy of the same dataset stored on the host, authorizing the smart package client only if the hash matches. [para 80] Duge discloses that this technology is used to validate component’s source, function, and configuration which under broadest reasonable interpretation refers to the claimed authenticating the node configuration data.);
and provide hardware root of trust (Duge [para 43] teaches a hardware root of trust because the integrity check during the power-up and software launching sequences is based on a trusted hash stored in a secure hardware device. Duge [para 80] further discloses that this digital certificate can be stored securely in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) embedded on the component. It suggests a hardware root of trust because integrity check begins from trusted hashes, certificate and keys stored in secure hardware, such as TPM, or HSM.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao’s system to incorporate the teaching of Duge’s Hardware security module-based trust anchor for authentication and providing root of trust. One would be motivated to make this modification on Skertic/Rao’s system to protect the cryptographic keys, certificates, hashes to validate component’s source, function, and configuration and to provide hardware trust anchor for nodes participating in digital logbook updates. Doing so would improve node level security, ensuring authenticated participation in blockchain ledger updates, and securing the system against counterfeit or malicious nodes.
Regarding Claim 17, Skertic/Rao/Duge teaches the distributed decentralized control system of claim 16:
Skertic teaches:
Wherein the controller is a full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses the control node may be, for example, a FADEC)
Regarding Claim 18, Skertic/Rao/Duge teaches the distributed decentralized control system of claim 16:
Skertic teaches:
Wherein performing the security approval comprises: receiving, by the controller, the unique node configuration data from each of the plurality of nodes (Skertic, page 5, para [0031], lines 37-47, discloses that the control module receive message transmitted by nodes which includes a hash of a digital certificate maintained at the node, the hash may further include data related to the node, as well as a preceding hash. (see, Fig 6.))
authenticating, by the controller, each of the plurality of nodes using a public key (Skertic, page 6, para [0033], lines 6-9, discloses that upon receiving the hash from each of the nodes, the control module using a corresponding public or private key from the key pair, decrypts the message from each of the nodes; page 6, para [0035], lines 33-35, Skertic further discloses that based on the comparison, the authenticity of smart node may be confirmed.)
updating, by the controller, the digital ledger (Skertic, page 6, para [0035], lines 33-37, discloses that the central block chain will be updated based on the received message from the control module)
and transmitting, by the controller, the system configuration block to each of the plurality of nodes, wherein each of the plurality of nodes updates the digital ledger based at least in part on the system configuration block (Skertic, page 6, para [0035], lines 33-37, discloses that the local node block chains will be updated based on the received message from the control module).
Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Skertic (EP 3672196 A1) in view of Rao (US 11368304 B2) in view of Duge (EP 3672197 A1) in view of Mullin (US 20200342127 A1) (Cited on prior Office Action mailed on 9/25/2024).
Regarding Claim 2, Skertic/Rao/Duge teaches the method of claim 1,
Skertic/Rao/Duge does not teach: the digital ledger is based on the Ethereum blockchain
However, Mullin teaches:
the digital ledger is based on the Ethereum blockchain (Mullin, page 1, para [0013], discloses that the distributed ledger may be a Blockchain-based distributed ledger or an Ethereum-based distributed ledger.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the teaching of distributed digital ledger as described in Skertic/Rao/Duge to incorporate the use of Ethereum blockchain as disclosed by Mullin. One would be motivated to perform such a modification on Skertic/Rao/Duge’s system in order to ensure that the committed log entry is immutable and cryptographically verifiable which in turns provides security to the system. (Mullin, Page 1)
Regarding Claim 10, Skertic/Rao/Duge teaches the full authority digital engine control of claim 9,
Skertic/Rao/Duge does not teach: the digital ledger is based on the Ethereum blockchain
However, Mullin teaches:
the digital ledger is based on the Ethereum blockchain (Mullin, page 1, para [0013], discloses that the distributed ledger may be a Blockchain-based distributed ledger or an Ethereum-based distributed ledger.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the teaching of distributed digital ledger as described in Skertic/Rao to incorporate the use of Ethereum blockchain as disclosed by Mullin. One would be motivated to perform such a modification on Skertic/Rao/Duge’s system in order to ensure that the committed log entry is immutable and cryptographically verifiable which in turns provides security to the system. (Mullin, Page 1)
Claims 7-8, 14-15, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Skertic (EP 3672196 A1) in view of Rao (US 11368304 B2) in view of Duge (EP 3672197 A1) in view of Samuel (US 20200097658 A1) (Cited on prior Office Action mailed on 9/25/2024).
Regarding Claim 7, Skertic/Rao/Duge teaches the method of claim 1:
and further, wherein a protected component comprises an engine control (Skertic: [0034]-[0035]);
While Skertic heavily implies that the engine will not be started upon authentication of components failing (Skertic: [0029], [0035])
Skertic fails to explicitly teach:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with the protected components.
However, Samuel teaches:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with the protected components (Samuel, page 3, para [0023], discloses that any component that has compromised firmware is identified before the operation system is booted. Depending on the policy, the BIOS may automatically disable components having compromised preventing unauthorized firmware of a component from executing on the computing device).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
Regarding Claim 8, Skertic/Rao/Duge/Samuel teach the method of claim 7:
Skertic/Rao/Duge/Samuel discloses responsive to confirming that at least one of the plurality of nodes is not authorized (Samuel, para 23),
Skertic discloses:
updating the digital ledger among the plurality of nodes that are authorized and the engine control to indicate a current status of the at least one plurality of nodes (Skertic: [0035]-[0036] provides for updating the blockchain ledger to ensure it acts as a log of the authenticity verifications)
Skertic/Rao/Duge does not explicitly teach:
wherein the logged indication of a current status is not authorized.
However, Samuel teaches:
wherein the logged indication of a current status is not authorized.
(Samuel: [0062] provides for logging the current status by notifying an administrator or displaying an error message to the user).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
Regarding Claim 14, Skertic/Rao/Duge teaches the full authority digital engine control of claim 9:
and further, wherein a protected component comprises an engine control (Skertic: [0034]-[0035]);
While Skertic heavily implies that the engine will not be started upon authentication of components failing (Skertic: [0029], [0035])
Skertic fails to explicitly teach:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with the protected components.
However, Samuel teaches:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with protected components. (Samuel, page 3, para [0023], discloses that any component that has compromised firmware is identified before the operation system is booted. Depending on the policy, the BIOS may automatically disable components having compromised preventing unauthorized firmware of a component from executing on the computing device).
Samuel does not teach:
wherein the protected component is full authority digital engine control.
However, Skertic teaches:
wherein the protected component is full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses the control node may be, for example, a FADEC).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
Regarding Claim 15, Skertic teaches the full authority digital engine control of claim 14:
Skertic/Rao/Duge/Samuel discloses responsive to confirming that at least one of the plurality of nodes is not authorized (Samuel, para 23),
Skertic discloses:
updating the digital ledger among the plurality of nodes that are authorized and the engine control to indicate a current status of the at least one plurality of nodes (Skertic: [0035]-[0036] provides for updating the blockchain ledger to ensure it acts as a log of the authenticity verifications)
Skertic/Rao/Duge does not explicitly teach:
wherein the logged indication of a current status is not authorized.
However, Samuel teaches:
wherein the logged indication of a current status is not authorized.
(Samuel: [0062] provides for logging the current status by notifying an administrator or displaying an error message to the user).
Samuel does not teach:
wherein the protected component is full authority digital engine control.
However, Skertic teaches:
wherein the protected component is full authority digital engine control (Skertic, page 4, para [0018], lines 47-48, discloses the control node may be, for example, a FADEC).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
Regarding Claim 19, Skertic/Rao/Duge teaches the distributed decentralized control system of claim 16:
and further, wherein a protected component comprises a controller (Skertic: [0034]-[0035] provides for an engine controller);
While Skertic heavily implies that the engine will not be started upon authentication of components failing (Skertic: [0029], [0035])
Skertic fails to explicitly teach:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with the protected components.
However, Samuel teaches:
responsive to confirming that at least one of the plurality of nodes is not authorized, preventing the at least one of the plurality of nodes from communicating with the protected components (Samuel, page 3, para [0023], discloses that any component that has compromised firmware is identified before the operation system is booted. Depending on the policy, the BIOS may automatically disable components having compromised preventing unauthorized firmware of a component from executing on the computing device).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
Regarding Claim 20, Skertic/Rao/Duge/Samuel teaches the distributed decentralized control system of claim 19:
Skertic/Rao/Duge/Samuel discloses responsive to confirming that at least one of the plurality of nodes is not authorized (Samuel, para 23),
Skertic discloses:
updating the digital ledger among the plurality of nodes that are authorized and the engine control to indicate a current status of the at least one plurality of nodes (Skertic: [0035]-[0036] provides for updating the blockchain ledger to ensure it acts as a log of the authenticity verifications)
Skertic/Rao/Duge does not explicitly teach:
wherein the logged indication of a current status is not authorized.
However, Samuel teaches:
wherein the logged indication of a current status is not authorized.
(Samuel: [0062] provides for logging the current status by notifying an administrator or displaying an error message to the user).
Both Skertic/Rao/Duge and Samuel are in the same field of endeavor, of ensuring the security and integrity of components in a distributed system. It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Skertic/Rao/Duge’s distributed control system to incorporate the teaching of Samuel to disable unauthorized component to ensure security and integrity of components. One would be motivated to perform such a modification, to disable unauthorized components, ensuring that compromised firmware or unauthorized nodes cannot communicate with critical system reducing the risk of malicious or faulty nodes impacting the system’s performance and safety. (Samuel, para [0023])
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 AMIT KHADKA whose telephone number is (703)756-1440. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm.
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, Jeffrey L. Nickerson can be reached at (469) 295-9235. 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.
/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights