DETAILED ACTION
This final office action is in response to claims 1-40 filed on 07/28/2025 for examination. Claims 1-40 are being examined and are pending.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment
The amendment filed July 28, 2025 has been entered. Claims 1-40 remain pending in the application. The claims have been amended. Applicant’s arguments and amendments to the claims have overcome each and every claim objection and 112 rejection previously set forth in the Non-Final Office Action mailed January 27, 2025. Claims 1-3, 10, 15-16, 18-19, 23-24, 27, 30, and 34 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Further, applicant’s arguments regarding claims 1-40 have been fully considered but are not persuasive to differentiate over the prior art. Particularly:
Applicant opines that “Applicant has demonstrated that the Downey et al. reference is designed for a different purpose, and it would not have been obvious to modify Downey et al. to arrive at the Applicant’s invention.” Remarks, pg. 14. Applicant seemingly alleges that since Downey teaches a system that may perform system integrity measurements and other operations pre-flight, it could never provide teachings to a system that may perform system integrity measurements in-flight. Remarks, pgs. 16-17 and 20-21. Examiner disagrees. Examiner directs Applicant to the similar system of Mixer. Like Downey, Mixer teaches calculating and verifying a checksum value of system components to verify system integrity. See, e.g., Mixer at [0074-078], [0096], [0020], and [0107]. Further, Mixer teaches calculating and verifying checksums during system operation to ensure continued system integrity. Id. It would have been extremely obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the UAV of the combination of Downey, Jarrell, and Bare with the teachings of Mixer, comprising calculating and verifying checksums during system operation <i.e., in-flight>, to ensure continued integrity of the UAV. Id. Applicant’s associated remarks are unpersuasive.
While Applicant’s remarks are largely conclusory and inconsistently presented, Examiner is identifying further points of possible confusion:
Applicant opines that the prior art fails to teach the integrity check being performed via firmware. Remarks, pgs. 15-18. Examiner notes that both Downey and Mixer teach this (though only one would truly be necessary). See, e.g., Downey at [0170-171] and Mixer at [0055], [0065-066], and [0045]. Accordingly, this is not a deficiency in the prior art. Applicant’s associated remarks are unpersuasive. Examiner further notes that Applicant has seemingly applied this argument to the set of independent claims, but no such amendment is presented in independent claims 10 or 30.
Applicant opines because that the system integrity measurements of Downey may be conducted when changes in configuration are provided and/or other configuration utility operations are performed that may require user involvement, it teaches away from conducting the system integrity measurements in-flight. Remarks, pgs. 16-18 and pgs. 20-21. Examiner disagrees. This is not a teaching away of Downey, Applicant is merely identifying an element not presented in Downey. That is to say, Downey is not explicitly prohibiting such a modification, it just does not contemplate one while identifying additional possible elements. It appears that Applicant’s confusion on this matter is that Applicant is assuming all aspects of a prior art reference must be incorporated into a combination, which is not the case. In reviewing the cited reference, Applicant should note that a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. MPEP 2123. E.g., Downey teaches a UAV system performing an integrity check. See, e.g., Downey at [0127-0129]. As identified hereinabove (and hereinbelow with regards to 35 U.S.C. 103), Mixer teaches continually performing the integrity checks during operation of the system. See, e.g., Mixer at [0074-078], [0096], [0020], and [0107]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the UAV of the combination of Downey, Jarrell, and Bare, with the teachings of Mixer, to ensure continued system integrity during operation. Applicant’s associated remarks are unpersuasive.
Applicant opines that because Downey’s check is presented as possible via wireless or wireless checks, it therefore implies only non-flight checks may be performed. Remarks, pgs. 18-20. Applicant seemingly believes this teaches away from combination because one presented embodiment <i.e., wired> of Downey may be less optimal for combination. Id. Examiner notes to Applicant that even if a possible embodiment of Downey may not be modifiable for in-flight usage (i.e., wired), others embodiments are modifiable for in-flight usage (i.e., wireless). All embodiments/elements presented in a prior art reference’s disclosure do not need to be incorporated into a combination of references. As above, Applicant should note that a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. MPEP 2123. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify a combination of Downey, Jarrell, and Bare with the teachings of Mixer, to ensure continued system integrity during operation. Applicant’s associated remarks are unpersuasive. Additionally, Applicant’s entire premise is flawed. There is no reason/teaching identified by Applicant demonstrating wired UAVs are wholly incapable of flight. Contrarily, it is actually quite common – while not presently relied upon, see, e.g., Braszko (NPL: “Fiber Optic Drones: Poising a Significant C-UAS Challenge”, August 2025).
Applicant recites throughout the arguments that Downey lacks motivation to implement other art. Remarks, pgs. 14-20. Examiner notes that for a reference to be modified, it does not need to contain the motivations for modification. The motivations for modification may be provided by other sources/combinations of sources. I.e., Downey does not need to provide the motivation. E.g., the modifying reference may provide a motivation for modification. See MPEP 2143. Examiner notes that motivations are provided for each combination of art: The combination of Downey and Jarrell is implemented to combat nefarious attacks by unauthorized parties. See, e.g., Jarrell at [0111] with Downey at [0084] and [0127-0129]. The combination of Downey, Jarrell, and Bare is implemented to prevent attestation keys and certificates from being used to track activity and compromise private. See, e.g., Bare at pg. 1, pg. 4, and pg. 6. The combination of Downey, Jarrell, Bare, and Mixer is implemented to ensure continued integrity of the UAV system and detect any malicious tampering. See, e.g., Downey at [0084] and [0127-129] with Mixer at [0020], [0074-078], and [0107]. Each modification would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention based on the teachings of the references. In response to Applicant's arguments against Downey individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant’s associated remarks are unpersuasive.
In view of the foregoing, as well as hereinbelow with regards to 35 U.S.C. 103, Applicant’s arguments regarding claims 1-40 have been considered by are not persuasive to differentiate over the prior art.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 8, 10-14, 17-18, 21-23, 26, 28, 30-31, 33, and 36-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Downey et al. (US20160152337; Hereinafter “Downey”) in view of Jarrell et al. (US20170287341), Bare (NPL: “Attestation and Trusted Computing”; March 2006; Hereinafter “Bare”), and Mixer (US20160359866; Hereinafter “Mixer”).
Regarding claim 1, Downey teaches a system for verification of integrity of an unmanned aerial vehicle (abstract: system resides in a UAV; [0127-0129] and [0121] – UAV software and hardware integrity is verified) which resides in the unmanned aerial vehicle (UAV) and which interfaces with both the communications system of the UAV and the UAV's software resources and hardware resources and which executes firmware ([0025], [0114] – system includes hardware and software resources in communication with the system to execute the instructions; [0086] – system interfaces with communications system; [0170-171] – system may be executed via firmware); and:
a. obtains a serial number or unique identifier of hardware and software on the UAV ([0117-0120] – configuration utility receives configuration information of the UAV’s components from a payload module, which includes serial numbers; [0127] – payload modules compute a hash of their configuration information to send to the configuration utility), and
b. creates a hash code combination of the serial number or the unique identifier ([0127] – payload module and configuration utility compute a hash sum of the configuration information), and
d. transmits the [[encrypted]] hash code over a wired or wireless communications system to a computer which maintains a table of certified codes of a plurality of UAVs which results in said computer verifying authenticity of the UAV being verified or not verifying the UAV ([0127] – payload module and configuration utility compute a hash sum of the configuration information, then: “The flight or payload modules then provide the computed checksum <hash sum> to the configuration utility, which determines whether there are any discrepancies” <i.e., transmits it to the configuration utility computer> and [0127-0129] – if the hash sums do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., usage of the hash sums results in the computer verifying the UAV>, otherwise it does not verify; [0089] – UAV’s payload modules communicate with a ground based control system through a wired or wireless connection; [0117]-[0121] – information for different UAVs stored with the configuration utility), and
e. where the computer then determines whether the UAV's hardware or software has been changed since the UAV was last certified ([0127] – payload module and configuration utility compute a hash sum of the configuration information, and [0127-0129] – if the hash sums do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., the hardware or software is the same as previously stored>; see also [0121] – comparing against previously stored configurations);
f. wherein the system carries out a hardware and software integrity check and includes a control mechanism for controlling the UAV ([0084] – UAV’s local module communicates with a ground based control system; [0108-0111] – the radio control at the configuration utility system controls the UAV via a radio control link, and, e.g., can cause the UAV to return home, roll, pitch, etc.).
While Downey discloses producing and transmitting the hash code to an integrity providing computer (see, e.g., Downey at ([0127-0129]), Downey appears to fail to specifically disclose (1) wherein the system first encrypts the hash code using an encryption algorithm, wherein said control mechanism is controlled using verified integrity communications for the UAV operations during the flight of the UAV, (2) wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated; and (3) wherein the system operates independently of any UAV operator conducting a separate integrity check of the UAV or systems of the UAV and, running the verification of integrity during a flight of the UAV.
However, encrypting communications between two points to preserve communication integrity is well known in the art. E.g., Jarrell discloses a system wherein communications between a UAV and a control station are encrypted using an encryption algorithm (see abstract, [0111]) and verifying the integrity of the communications with the controlling center during operation (see [0111]-[0119] – using challenge-response functions to ensure communication integrity), and wherein the encryption algorithm not known by unintended recipients (see, e.g., [0100] and [0111]-[0119] – encryption/decryption is performed locally on the UAV and by the receiving station).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Downey with the teachings of Jarrell, such that the system encrypts the hash code using an encryption algorithm (as it is a communication between the UAV system and control station), and wherein said control mechanism is controlled using verified integrity communications for the UAV operations during the flight of the UAV, and wherein the encryption algorithm is not known by unintended recipients, to combat against nefarious attacks by unauthorized parties (see, e.g., Jarrell at [0111] and Downey at [0084], [0127]-[0129]).
While the combination of Downey and Jarrell teaches wherein the UAV securely remotely attests its system integrity to a verifier (see, e.g., Downey at [0089], [0118], [0120-121], [0127]), the combination of Downey and Jarrell appears to fail to specifically disclose (2) wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and the software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated; and (3) wherein the system operates independently of any UAV operator conducting a separate integrity check of the UAV or systems of the UAV and, running the verification of integrity during a flight of the UAV.
However, Bare teaches a similar system for securely remotely attesting system integrity and configuration (see, e.g., Bare at pg. 1), wherein a hash code attesting to system integrity and configuration is used to verify with a verifier (pgs. 2-3, pg. 5), and wherein said hash code and the encryption algorithm are not known to the |attesting system| owner or operator (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), wherein the |attesting system| is configured with instructions that provide the protocol for generating the hash code from the |attesting system| hardware and the software on the |attesting system| (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM on the attesting system computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), where verification of |attesting system| authentication parameters remains unknown to the |attesting system| even where the |attesting system| carries the hardware and the software from which the hash code is generated (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM on the attesting system computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hash producing UAV of the combination of Downey and Jarrell with the teachings of Bare, wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated, to protect the UAV against non-exterior malicious or untrusted parties by checking integrity values, and to prevent the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
While the combination of Downey, Jarrell, and Bare teach a system performing verification of integrity for a computing device (see above, particularly, the combination teaches verification of integrity steps a-h for a UAV), the combination of Downey, Jarrell, and Bar appear to fail to specifically disclose wherein the system for verification of integrity operates independently of any UAV operator conducting a separate integrity check of the UAV or systems of the UAV and, performing the verification of integrity steps during a flight of the UAV.
However, Mixer teaches a similar system performing a verification of integrity for a computing device via firmware (see, e.g., abstract, [0018-022], [0055], [0065-066], and [0045]), wherein the system operates independently of any endpoint operator conducting a separate integrity check of the endpoint the endpoint’s systems and, performing the verification of integrity during a runtime of the endpoint ([0074-078], [0096], and [0107] – The verification of integrity of the endpoint device may be conducted during a runtime operation of the endpoint device. It may be, e.g., periodically ran to ensure continued integrity of the endpoint device <i.e., triggered independently of any operator, and occurring during runtime/flight>; [0018] – endpoint devices may be, e.g., any computing component connected via a network, e.g., field devices, I/O devices, subordinate devices, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Downey, Jarrell, and Bare with the teachings of Mixer to perform the verification of integrity during a runtime of the UAV, particularly, wherein the system for verification of integrity operates independently of any UAV operator conducting a separate integrity check of the UAV or systems of the UAV and, performing the verification of integrity steps a.-h. during a flight of the UAV, to ensure continued integrity of the UAV’s systems and detect any malicious tampering with the UAV (see, e.g., Downey at [0084], [0127]-[0129]; with Mixer at [0020], [0074-078], [0107]).
Regarding claim 2, the combination of Downey, Jarrell, Bare, and Mixer teach the system of claim 1, wherein a trusted platform module (TPM) standards compliant chip/system is provided in the UAV for verification of the integrity of the (Bare at pgs. 2 and 5 – a TPM chip is including in the attesting system <i.e., a UAV> and used for verification of the integrity of the attesting system <i.e., UAV> hardware; with Downey at [0114], [0127] – UAV integrity verification). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Downey, Jarrell, and Bare with the teachings of Bare, wherein a trusted platform module (TPM) standards compliant chip/system is provided in the UAV for verification of the integrity of the UAV hardware, to protect the UAV against non-exterior malicious or untrusted parties, and to prevent the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
Regarding claim 8, the combination of Downey, Jarrell, Bare, and Mixer teach the system of claim 1, further comprising a public key system or private key system configured to further encrypt the hash code created in step b (Bare at pg. 5 – digital signature is taken of the hash code #A using the AIKi <i.e., encrypted using the signer’s private key>). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Downey, Jarrell, Bare, and Mixer with the teachings of Bare, further comprising a public key system or private key system configured to further encrypt the hash code created in step b, to implement a zero-knowledge system protecting the UAV against non-exterior malicious or untrusted parties, and preventing the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
Regarding claim 10, Downey teaches a method for securing an unmanned aerial vehicle (UAV) operation including during a flight of the UAV where said UAV includes a plurality of hardware components and where said UAV includes software (abstract, [0127-0129] – system ensures the hardware and software running in the UAV are secure and unchanged; see also [0025], [00114] – using various hardware and software resources), the method comprising, during the flight of the UAV:
generating an authentication hash code corresponding to at least one UAV, and storing said authentication hash code ([0127] – payload module and configuration utility compute a hash sum of the configuration information. The hash sum is subsequently compared to determine integrity <i.e., the hash sum is stored>);
providing at least one computing component electronically coupled with one or more of said plurality of hardware components or said software of said at least one UAV ([0025], [0114] – system includes hardware and software resources in communication with the system to execute the instructions; [0086] – system interfaces with communications system);
obtaining a unique identifier of at least one: (i) hardware component of said plurality of hardware components, or (ii) said software ([0117-0120] – configuration utility receives configuration information of the UAV’s components from a payload module, which includes serial numbers; [0127] – payload modules compute a hash of their configuration information to send to the configuration utility);
creating from said unique identifier a verification hash code for said at least one hardware component or software ([0127] – payload module and configuration utility compute a hash sum of the configuration information);
encrypting said verification hash code using an encryption algorithm;
transmitting said [[encrypted]] verification hash code over a communications network to a remotely situated computing component, decrypting said encrypted verification hash code ([0127] – payload module and configuration utility compute a hash sum of the configuration information, then: “The flight or payload modules then provide the computed checksum <hash sum> to the configuration utility, which determines whether there are any discrepancies” <i.e., transmits it to the configuration utility computer> and [0127-0129] – if the hash sums do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., usage of the hash sums results in the computer verifying the UAV>; [0089] – UAV’s payload modules communicate with a ground based control system through a wired or wireless connection; [0117]-[0121] – information for different UAVs stored with the configuration utility);
comparing said verification hash code with said stored authentication hash code ([0127] – payload module and configuration utility compute a hash sum of the configuration information, and [0127-0129] – if the hash sums match and do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., the hardware or software is the same as previously stored>; see also [0121] – comparing against previously stored configurations);
authenticating the UAV when said verification hash code matches said stored authentication hash code ([0127] – payload module and configuration utility compute a hash sum of the configuration information, and [0127-0129] – if the hash sums match and do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., the hardware or software is the same as previously stored>; see also [0121] – comparing against previously stored configurations).
While Downey discloses producing and transmitting the hash code to a controlling computer (see, e.g., Downey at ([0127-0129]), Downey appears to fail to specifically disclose encrypting said verification hash code using an encryption algorithm wherein said securing of the UAV operation includes securing control directives communicated to the UAV during the UAV operation over the communications network from the remotely situated computing component; wherein said system carries out said authenticating of the UAV during the flight of the UAV, and wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated, and running the verification of integrity steps during the flight of the UAV.
However, encrypting communications between two points to preserve communication integrity is well known in the art. E.g., Jarrell discloses a system wherein communications between a UAV and a control station are encrypted using an encryption algorithm (see abstract, [0111]), wherein the encryption algorithm not known by unintended recipients (see, e.g., [0100] and [0111]-[0119] – encryption/decryption is performed locally on the UAV and by the receiving station); wherein said securing of the UAV operation includes securing control directives communicated to the UAV during the UAV operation over the communications network from the remotely situated computing component (see [0111]-[0119] – using challenge-response functions to ensure communication integrity), and wherein said system carries out said authenticating of the UAV during the flight of the UAV ([0111]-[0113] – communications to/from the control station are received and verified <i.e., they are verified integrity communications>; [0049] – the received secure communications may be used to map flight paths or otherwise control the UAVs <i.e., before performing UAV operations>; [0023] – UAV operations can be, e.g., delivering payloads).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Downey with the teachings of Jarrell, comprising encrypting said verification hash code using an encryption algorithm (as it is a communication between the UAV and control station), wherein said securing of the UAV operation includes securing control directives communicated to the UAV during the UAV operation over the communications network from the remotely situated computing component, wherein said system carries out said authenticating of the UAV during the flight of the UAV, and wherein the encryption algorithm is not known by unintended recipients, to combat against nefarious attacks by unauthorized parties (see, e.g., Jarrell at [0111] and Downey at [0084], [0127]-[0129]).
While the combination of Downey and Jarrell teaches wherein the UAV securely remotely attests its system integrity to a verifier (see, e.g., Downey at [0089], [0118], [0120-121], [0127]), the combination of Downey and Jarrell appears to fail to specifically disclose wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated; and running the verification of integrity during the flight of the UAV.
However, Bare teaches a similar system for securely remotely attesting system integrity and configuration (see, e.g., Bare at pg. 1), wherein a hash code attesting to system integrity and configuration is used to verify with a verifier (pgs. 2-3, pg. 5), and wherein said hash code and the encryption algorithm are not known to the |attesting system| owner or operator (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), wherein the |attesting system| is configured with instructions that provide the protocol for generating the hash code from the |attesting system| hardware and the software on the |attesting system| (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM on the attesting system computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>), where verification of |attesting system| authentication parameters remains unknown to the |attesting system| even where the |attesting system| carries the hardware and software from which the hash code is generated (pgs. 5-6 and pg. 3 – a zero knowledge proof (ZKP) is performed via a TPM operating on the attesting system. Particularly, a TPM on the attesting system computes the hash #A conveying measurement integrity of hardware and/or software. The TPM then computes the signature of the attestation key AIK using the DAA key. The TPM them computes the signature of the hash #A using the attestation key AIK <i.e., encrypts it>. The TPM then constructs a zero-knowledge proof that the TPM possesses the signed (by an issuer) DAA key and the signed (by the DAA key) AIK key. Note: At no point is the hash code, or the encryption algorithm, or the DAA key known to the attesting system’s owner or operator <e.g., a human>. Further, at no point is the hash code or the encryption algorithm known to the attesting system itself <i.e., as all the work is done in the TPM, and only encrypted material leaves the TPM to be transmitted to the verifier>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hash producing UAV of the combination of Downey and Jarrell with the teachings of Bare, wherein said hash code and the encryption algorithm are not known to the UAV owner or operator, wherein the hash code and the encryption algorithm comprise a zero-knowledge proof protocol, wherein the UAV is configured with instructions that provide the protocol for generating the hash code from the UAV hardware and software on the UAV, where verification of UAV authentication parameters remains unknown to the UAV even where the UAV carries the hardware and the software from which the hash code is generated, to protect the UAV against non-exterior malicious or untrusted parties by checking integrity values, and to prevent the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
While the combination of Downey, Jarrell, and Bare teach a system performing verification of integrity for a computing device (see above, particularly, the combination teaches verification of integrity steps a-h for a UAV), the combination of Downey, Jarrell, and Bar appear to fail to specifically disclose performing the verification of integrity steps during the flight of the UAV.
However, Mixer teaches a similar system performing a verification of integrity for a computing device via firmware (see, e.g., abstract, [0018-022], [0055], [0065-066], and [0045]), performing the verification of integrity steps during a runtime of the endpoint ([0074-078], [0096], and [0107] – The verification of integrity of the endpoint device may be conducted during a runtime operation of the endpoint device. It may be, e.g., periodically ran to ensure continued integrity of the endpoint device <i.e., triggered independently of any operator, and occurring during runtime/flight>; [0018] – endpoint devices may be, e.g., any computing component connected via a network, e.g., field devices, I/O devices, subordinate devices, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Downey, Jarrell, and Bare with the teachings of Mixer to perform the verification of integrity during a runtime of the UAV, particularly, performing the verification of integrity steps during the flight of the UAV, to ensure continued integrity of the UAV’s systems and detect any malicious tampering with the UAV (see, e.g., Downey at [0084], [0127]-[0129]; with Mixer at [0020], [0074-078], [0107]).
Regarding claim 11, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein said stored authentication hash code is stored in a database (Downey at [0135], [0152] – the configuration utilities for UAVs may be stored in a database of the UAV configurations; [0127] – the configuration utilities may comprise hash sums).
Regarding claim 12, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 11, further comprising providing a database having a stored plurality of authentication hash codes, wherein each of said stored plurality of authentication hash codes corresponds with a specific UAV (Downey at [0135], [0152] – the configuration utilities for UAVs may be stored in a database of the UAV configurations; [0127] – the configuration utilities may comprise hash sums used to ensure integrity of the UAV).
Regarding claim 13, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, further comprising determining whether one of said hardware components or said software of said UAV has been changed (Downey at [0127]-[0129] – the configuration utility compares the detected configuration against the stored configuration, when they do match <i.e., when something has been changed> the system determines a discrepancy exists).
Regarding claim 14, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, further comprising certifying said UAV by generating said authentication hash code corresponding to said UAV, and storing said authentication hash code (Downey at [0127] – payload module and configuration utility compute a hash sum of the configuration information. The hash sum is subsequently compared to determine integrity <i.e., the hash sum is stored>. If the hash sums match and do not return an error, the configuration utility determines successful completion of the airworthiness test <i.e., the hardware or software is the same as previously stored>; see also [0121] – comparing against previously stored configurations).
Regarding claim 17, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein said unique identifier comprises a serial number (Downey at [0117-0119] – configuration utility receives serial numbers of the UAV’s components from a payload module; [0127] – payload module and configuration utility compute a hash sum of configuration information).
Regarding claim 18, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein obtaining a unique identifier is done for at least one of the (Downey at [0117-0119] – configuration utility receives serial numbers of the UAV’s configuration from a payload module; [0114] – system compares using the hardware, software, and the firmware of the UAV <i.e., information on all is collected>); and wherein said verification hash code is created from a combination of said at least one hardware unique identifier obtained for the at least one of the plurality of hardware components, and said unique identifier obtained for said software (Downey at [0114] – system compares against the hardware, software, and the firmware of the UAV <i.e., information on all is collected as configuration information>; then [0127] – “The configuration utility optionally computes a checksum e.g., a hash sum, of the configuration information, and directs each receiving flight or payload module to compute a same checksum upon receipt of the configuration information. The flight or payload modules then provide the computed checksum to the configuration utility, which determines whether there are any discrepancies. Upon a positive determination, the configuration utility provides the configuration to the flight or payload modules, until the checksum values agree.”).
Regarding claim 21, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein transmitting said encrypted verification hash code is done over a wireless communications network (Downey at [0089] – configuration utility may connect wirelessly or through a wired connection to control the UAV; similarly, Jarrell at [0024]&[0111] – encrypted control communication may occur with control station wirelessly). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Downey with the teachings of Jarrell, wherein transmitting said encrypted verification hash code is done over a wireless communications network, so that the system may securely verify that the communications are secure from malicious actors (see, e.g., Jarrell at [0111]).
Regarding claim 22, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein transmitting said encrypted verification hash code is done over a wired communications network (Downey at [0089] – configuration utility may connect wirelessly or through a wired connection to control the UAV; similarly, Jarrell at [0024] &[0111-0112] – encrypted control communication may occur with control station connected through a wire). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Downey with the teachings of Jarrell, wherein transmitting said encrypted verification hash code is done over a wired communications network, so that the system may securely verify that the communications are secure from malicious actors (see, e.g., Jarrell at [0111-0112]).
Regarding claim 23, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein said wherein a trusted platform module (TPM) standards compliant chip/system is provided in the UAV for: generating the authentication hash code, obtaining a unique identifier of at least one: (i) hardware component of said plurality of hardware components, or (ii) said software; and creating from said unique identifier a verification hash code for said at least one hardware component or said software (Bare at pgs. 2 and 5 – a TPM chip is including in the attesting system <i.e., a UAV> and used for verification of the integrity of the attesting system <i.e., UAV> hardware and software. A hash code A# is generated based on the software and/or hardware and verified; with Downey at [0114], [0127] – UAV integrity verification). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Downey, Jarrell, Bare, and Mixer with the teachings of Bare, wherein said wherein a trusted platform module (TPM) standards compliant chip/system is provided in the UAV for: generating the authentication hash code, obtaining a unique identifier of at least one: (i) hardware component of said plurality of hardware components, or (ii) said software; and creating from said unique identifier a verification hash code for said at least one hardware component or software, to protect the UAV against non-exterior malicious or untrusted parties, and to prevent the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
Regarding claim 26, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein said remotely situated computing component comprises a central command and control system (Downey at [0084] – UAV’s payload modules communicate with a ground based control system; [0108-0111] – the radio control at the configuration utility system controls the UAV via a radio control link, and, e.g., can cause the UAV to return home, roll, pitch, etc.).
Regarding claim 28, the combination of Downey, Jarrell, Bare, and Mixer teach the method of claim 10, wherein encrypting said verification hash code comprises includes implementing a public key system or private key system (Bare at pg. 5 – digital signature is taken of the hash code #A using the AIKi <i.e., encrypted using the signer’s private key>). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Downey, Jarrell, Bare, and Mixer with the teachings of Bare, further comprising a public key system or private key system configured to further encrypt the hash code created in step b, to implement a zero-knowledge system protecting the UAV against non-exterior malicious or untrusted parties, and preventing the attestation key and certificate from being used to track activity and compromise privacy (see, e.g., Bare at pg. 1, pg. 4, pg. 6).
Regarding claim 30, Downey teaches an unmanned aerial vehicle (UAV) comprising:
a plurality of hardware components ([0114] – system comprises hardware components), including at least one processing component ([0004] – system comprises processors), at least one storage component ([0038], [0170] – system includes memory), at least one rotor and an associated drive component connected to the rotor to drive the rotor ([0135-0137], [0163] – UAV includes rotors and system to run the motors); software being stored on said stor