Office Action Predictor
Last updated: April 16, 2026
Application No. 18/584,438

Fleet Management Of Unmanned Aerial Vehicles And Flight Authorization System

Final Rejection §103
Filed
Feb 22, 2024
Examiner
PATTON, SPENCER D
Art Unit
3656
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Skydio, INC.
OA Round
2 (Final)
74%
Grant Probability
Favorable
3-4
OA Rounds
3y 1m
To Grant
90%
With Interview

Examiner Intelligence

Grants 74% — above average
74%
Career Allow Rate
424 granted / 575 resolved
+21.7% vs TC avg
Strong +16% interview lift
Without
With
+15.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
26 currently pending
Career history
601
Total Applications
across all art units

Statute-Specific Performance

§101
5.4%
-34.6% vs TC avg
§103
47.4%
+7.4% vs TC avg
§102
20.5%
-19.5% vs TC avg
§112
19.5%
-20.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 575 resolved cases

Office Action

§103
DETAILED ACTION The amendments filed 1/20/2026 have been entered. Claims 31-55 are pending. Claim Objections Claim 46 is objected to because of the following informalities: Claim 46, line 14: “population” should be changed to --propulsion--. Appropriate correction is required. 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. Claims 31-35, 38-40, 44-48, 50, and 52-55 are rejected under 35 U.S.C. 103 as being unpatentable over Bruno et al. (US Patent No. 9,734,723) in view of Cui et al. (US Publication No. 2018/0061249). Bruno teaches: Re claim 31. A method implemented by an unmanned aerial vehicle (UAV) for executing a mission, the method comprising: receiving, at an UAV, a flight plan including navigation information and associated authorization information generated by a computer system (key signed flight plan, Fig. 3; and column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”); verifying, by the UAV, that the authorization information is valid and that the UAV is identified in the authorization information (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID [Electronic ID], region of airspace (inclusion zone), and timeframe that the UAV may fly.” Column 9, lines 31-49: “The UAV flight lock module 210 compares the stored EID with the decrypted flight plan EID. The stored EID and the decrypted flight plan EID must match as a step in releasing the flight lock. Secondly, a match of the text result of the decryption to the clear text authenticates that that the RA 100 approved the flight plan.”); determining, by the UAV, based on operational status data stored in non-volatile memory, whether one or more operational state flags indicate compliance with predefined readiness conditions including at least […] a flight-hour limit status (column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”), wherein the determining is performed locally by the UAV prior to enabling propulsion or autonomous flight control (Column 9, lines 31-49: “the UAV 200 includes a flight lock module 210 … the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan. More specifically, the UAV's flight lock module 210 compares the flight plan location and timeframe with the location and time provided by the UAV's PNT module 220.”. Fig. 3 illustrates the UAV flight lock module 210 as part of the UAV 200. Column 11, lines 22-61: “UAV OS 600 has a secure “vault” 640 which includes encrypted non-volatile memory that contains the key parameters that must be present for an approved flight plan to be executed. Secure vault contains secured data that is used by flight control system 604 to enforce the flight lock functionality and adherence to the defined flight plan. In particular, secure vault 608 contains the following data: Position, Navigation, and Timing (PNT) data.”); in response to the verifying and determining being affirmative, transitioning the UAV from a non-operational mode to an operational mode (column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”; and column 9, lines 31-49: “With both of the above matches, the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan.”); and autonomously navigating the UAV according to the flight plan within a geofence specified by the navigation information (column 8, lines 51-62: “To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly. One example of a mechanism for specifying the inclusion zone is a set of values that define permissible latitude/longitude, altitude, range, and a time frame. More generally, any practical set of parameters that define the boundaries of a three-dimensional airspace and a timeframe can be used to define the inclusion zone.” Column 12, lines 20-22: “If the UAV is operated in autonomous mode, it flies within the bounds of its flight plan under control of the flight control system 620.”). Bruno fails to specifically teach: (re claim 31) determining, by the UAV, based on operational status data stored in non-volatile memory, whether one or more operational state flags indicate compliance with predefined readiness conditions including at least a maintenance status, and a pre-flight checklist status. Cui teaches, at Fig. 5 and paragraphs [0037-0038], mission information subsystem 125 may include a mission profile 129, which sets time constraints, and checklists 130 to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Paragraph [0023] teaches a mission policy management system 89, which includes the mission information subsystem 125, may be implemented in a UAV 2. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. In view of Cui’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the method as taught by Bruno, (re claim 31) determining, by the UAV, based on operational status data stored in non-volatile memory, whether one or more operational state flags indicate compliance with predefined readiness conditions including at least a maintenance status, and a pre-flight checklist status, with a reasonable expectation of success, since Cui teaches setting time constraints and implementing checklists to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. Bruno further teaches: Re claim 32. Wherein the navigation information includes at least one of a set of waypoints, geofence information (column 8, lines 51-62: “To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly. One example of a mechanism for specifying the inclusion zone is a set of values that define permissible latitude/longitude, altitude, range, and a time frame. More generally, any practical set of parameters that define the boundaries of a three-dimensional airspace and a timeframe can be used to define the inclusion zone.”), distances between waypoints, actions to be performed at the set of waypoints, and an estimated transit speed between waypoints derived from historical flight plan execution data. Re claim 33. Wherein the estimated transit speed is adjusted based on environmental information including at least one of expected wind speed, visibility, or time of day (This claim further limits one of the alternatives listed in claim 32. Bruno teaches the geofence information of claim 32 at column 8, lines 51-62.). Re claim 34. Wherein the flight plan is generated based on an estimated flight time determined from the navigation information (column 2, lines 24-31: “The RA server evaluates a UAV's proposed flight plan based upon the attributes of the O/O, attributes of the UAV, the location and time of the requested flight plan, and a set of flight rules and exclusion zones that are developed in consideration of and with the objectives of privacy assurance, security assurance, flight safety assurance (conflict/collision avoidance), and ground safety assurance (protecting people and property on the ground).”). Re claim 35. Wherein the estimated flight time is increased by a predetermined buffer margin before being used to determine whether the UAV satisfies a flight-hour limit condition (column 4, line 59 through column 5, line 5: “the UAV will autonomously head home (the launch site) and land before the time window expires”). Re claim 38. Wherein verifying that the authorization information is valid includes verifying a digital signature generated by the computer system (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.” Column 9, lines 31-49: “The UAV flight lock module 210 compares the stored EID with the decrypted flight plan EID. The stored EID and the decrypted flight plan EID must match as a step in releasing the flight lock. Secondly, a match of the text result of the decryption to the clear text authenticates that that the RA 100 approved the flight plan.”). Re claim 39. Wherein the authorization information is specific to the flight plan and is configured to prevent execution of any flight plan not associated with the authorization information (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”). Re claim 40. Wherein the flight plan is encrypted using a public key associated with the UAV, and wherein the UAV decrypts the flight plan using a corresponding private key stored on the UAV (column 11, lines 22-56: “Public and private encryption and decryption keys for securely storing the contained data.”; and “Secure vault 640 can be written to only via the flight plan loading process by utilizing the encryption enabled by the public and private keys.”). Re claim 44. Further comprising: during autonomous navigation according to the flight plan, receiving an alert of a temporary flight restriction from the computer system via a low-bandwidth communication channel including at least one of a short message service (SMS) message or a voice call (column 8, line 63 through column 9, line 8: “LTE-cellular tracking via a data channel or short message service (SMS). For support of UAV flight plans beyond a specified duration, the UAV must be equipped with an LTE, cellular, or SATCOM communications capability which would allow it to receive in-flight flight plan renewals or updates in order to support extended operations, or intentional confinement by the RA.”; column 5, lines 6-18; and column 21, lines 10-16). Re claim 45. Further comprising: upon detecting that an updated authorization condition is not satisfied during flight, automatically executing a contingency action including at least one of terminating the mission, altering the flight path to avoid a restricted area, or navigating to a designated landing location (Column 9, lines 3-8: “For support of UAV flight plans beyond a specified duration, the UAV must be equipped with an LTE, cellular, or SATCOM communications capability which would allow it to receive in-flight flight plan renewals or updates in order to support extended operations, or intentional confinement by the RA.” And (column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”). Re claim 46. An unmanned aerial vehicle (UAV) comprising: a non-volatile memory storing operational status data and a plurality of operational state flags (flight lock module 210, Fig. 3; and column 10, lines 58-63: “memory capabilities that resides onboard the UAV 600 and enforces the flight lock functionality and adherence to the parameters of the approved and loaded flight plan.”; and column 11, lines 22-61: “UAV OS 600 has a secure “vault” 640 which includes encrypted non-volatile memory that contains the key parameters that must be present for an approved flight plan to be executed. Secure vault contains secured data that is used by flight control system 604 to enforce the flight lock functionality and adherence to the defined flight plan. In particular, secure vault 608 contains the following data: Position, Navigation, and Timing (PNT) data.”); a communication interface configured to receive a flight plan including navigation information and associated authorization information generated by an external computer system (communications system 630, Fig. 6; key signed flight plan, Fig. 3; and column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”); and one or more processors (column 10, lines 58-63: “processing and memory capabilities that resides onboard the UAV 600 and enforces the flight lock functionality and adherence to the parameters of the approved and loaded flight plan.”) configured to: verify that the authorization information is valid and that the UAV is identified in the authorization information (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID [Electronic ID], region of airspace (inclusion zone), and timeframe that the UAV may fly.” Column 9, lines 31-49: “The UAV flight lock module 210 compares the stored EID with the decrypted flight plan EID. The stored EID and the decrypted flight plan EID must match as a step in releasing the flight lock. Secondly, a match of the text result of the decryption to the clear text authenticates that that the RA 100 approved the flight plan.”), determine, based on the operational status data persistently stored in the non-volatile memory of the UAV, whether the operational state flags correspond to predefined readiness conditions including at least […] a flight-hour limit status (column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”; and column 11, lines 22-61: “UAV OS 600 has a secure “vault” 640 which includes encrypted non-volatile memory that contains the key parameters that must be present for an approved flight plan to be executed. Secure vault contains secured data that is used by flight control system 604 to enforce the flight lock functionality and adherence to the defined flight plan. In particular, secure vault 608 contains the following data: Position, Navigation, and Timing (PNT) data.”), perform the determination locally on the UAV prior to enabling population or autonomous flight control (Column 9, lines 31-49: “the UAV 200 includes a flight lock module 210 … the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan. More specifically, the UAV's flight lock module 210 compares the flight plan location and timeframe with the location and time provided by the UAV's PNT module 220.”. Fig. 3 illustrates the UAV flight lock module 210 as part of the UAV 200.), in response to the verifying and determining being affirmative, transition the UAV from a non-operational mode to an operational mode (column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”; and column 9, lines 31-49: “With both of the above matches, the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan.”), and control autonomous navigation of the UAV according to the flight plan within a geofence specified in the navigation information (column 8, lines 51-62: “To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly. One example of a mechanism for specifying the inclusion zone is a set of values that define permissible latitude/longitude, altitude, range, and a time frame. More generally, any practical set of parameters that define the boundaries of a three-dimensional airspace and a timeframe can be used to define the inclusion zone.” Column 12, lines 20-22: “If the UAV is operated in autonomous mode, it flies within the bounds of its flight plan under control of the flight control system 620.”). Bruno fails to specifically teach: (re claim 46) determine, based on the operational status data, whether the operational state flags correspond to predefined readiness conditions including at least a maintenance status, a pre-flight checklist status, and a flight-hour limit status. Cui teaches, at Fig. 5 and paragraphs [0037-0038], mission information subsystem 125 may include a mission profile 129, which sets time constraints, and checklists 130 to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Paragraph [0023] teaches a mission policy management system 89, which includes the mission information subsystem 125, may be implemented in a UAV 2. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. In view of Cui’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the apparatus as taught by Bruno, (re claim 46) determine, based on the operational status data, whether the operational state flags correspond to predefined readiness conditions including at least a maintenance status, a pre-flight checklist status, and a flight-hour limit status, with a reasonable expectation of success, since Cui teaches setting time constraints and implementing checklists to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. Bruno further teaches: Re claim 47. Wherein the authorization information is digitally signed by the external computer system and the processors are configured to verify the digital signature (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.” Column 9, lines 31-49: “The UAV flight lock module 210 compares the stored EID with the decrypted flight plan EID. The stored EID and the decrypted flight plan EID must match as a step in releasing the flight lock. Secondly, a match of the text result of the decryption to the clear text authenticates that that the RA 100 approved the flight plan.”). Re claim 48. Wherein the flight plan is encrypted using a public key associated with the UAV and the processors are configured to decrypt the flight plan using a corresponding private key stored on the UAV (column 11, lines 22-56: “Public and private encryption and decryption keys for securely storing the contained data.”; and “Secure vault 640 can be written to only via the flight plan loading process by utilizing the encryption enabled by the public and private keys.”). Re claim 50. Wherein the processors are further configured to receive an alert of a temporary flight restriction via a low-bandwidth communication channel comprising at least one of a short message service (SMS) message or a voice call (column 8, line 63 through column 9, line 8: “LTE-cellular tracking via a data channel or short message service (SMS). For support of UAV flight plans beyond a specified duration, the UAV must be equipped with an LTE, cellular, or SATCOM communications capability which would allow it to receive in-flight flight plan renewals or updates in order to support extended operations, or intentional confinement by the RA.”; column 5, lines 6-18; and column 21, lines 10-16). Re claim 52. further comprising: the communication interface configured to receive updated authorization information during flight; and the one or more processors further configured to: determine, during execution of the flight plan, whether an updated authorization condition is not satisfied based on the updated authorization information and the operational state flags; and in response to the updated authorization condition not being satisfied, automatically execute a contingency action comprising at least one of terminating the mission, altering the flight path to avoid a restricted area, or navigating to a designated landing location (Column 9, lines 3-8: “For support of UAV flight plans beyond a specified duration, the UAV must be equipped with an LTE, cellular, or SATCOM communications capability which would allow it to receive in-flight flight plan renewals or updates in order to support extended operations, or intentional confinement by the RA.” And (column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”). Re claim 53. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of an unmanned aerial vehicle (UAV) (column 10, lines 58-66: “FIG. 6 is a block diagram illustrating an example implementation of the overall architecture of the operating system (OS) 605, including processing and memory capabilities that resides onboard the UAV 600 and enforces the flight lock functionality and adherence to the parameters of the approved and loaded flight plan. UAV operating system 605 includes one or more processors, such as microprocessors or microcontrollers, that execute instructions to perform the operations of the UAV described herein.”), cause the UAV to: receive a flight plan including navigation information and associated authorization information generated by an external computer system (key signed flight plan, Fig. 3; and column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”); verify that the authorization information is valid and that the UAV is identified in the authorization information (column 8, lines 51-62: “the flight lock requires a digitally signed approved flight plan that specifies the UAV EID [Electronic ID], region of airspace (inclusion zone), and timeframe that the UAV may fly.” Column 9, lines 31-49: “The UAV flight lock module 210 compares the stored EID with the decrypted flight plan EID. The stored EID and the decrypted flight plan EID must match as a step in releasing the flight lock. Secondly, a match of the text result of the decryption to the clear text authenticates that that the RA 100 approved the flight plan.”); determine, based on operational status data persistently stored in non-volatile memory of the UAV, whether operational state flags correspond to predefined readiness conditions comprising at least […] a flight-hour limit status (Column 11, lines 22-61: “UAV OS 600 has a secure “vault” 640 which includes encrypted non-volatile memory that contains the key parameters that must be present for an approved flight plan to be executed. Secure vault contains secured data that is used by flight control system 604 to enforce the flight lock functionality and adherence to the defined flight plan. In particular, secure vault 608 contains the following data: Position, Navigation, and Timing (PNT) data.”. Column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”); performing the determination locally on the UAV prior to enabling propulsion or autonomous flight control (Column 9, lines 31-49: “the UAV 200 includes a flight lock module 210 … the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan. More specifically, the UAV's flight lock module 210 compares the flight plan location and timeframe with the location and time provided by the UAV's PNT module 220.”. Fig. 3 illustrates the UAV flight lock module 210 as part of the UAV 200.); in response to the verification and determination being affirmative, transition the UAV from a non-operational mode to an operational mode (column 8, lines 51-62: “In order to fly, the UAV flight lock must be turned off. To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly.”; and column 9, lines 31-49: “With both of the above matches, the UAV flight lock module 210 releases the flight lock, but only for the location and timeframe (i.e., the four dimensional “inclusion zone”) specified in the flight plan.”); and autonomously navigate the UAV according to the flight plan within a geofence specified in the navigation information (column 8, lines 51-62: “To do this, the flight lock requires a digitally signed approved flight plan that specifies the UAV EID, region of airspace (inclusion zone), and timeframe that the UAV may fly. One example of a mechanism for specifying the inclusion zone is a set of values that define permissible latitude/longitude, altitude, range, and a time frame. More generally, any practical set of parameters that define the boundaries of a three-dimensional airspace and a timeframe can be used to define the inclusion zone.” Column 12, lines 20-22: “If the UAV is operated in autonomous mode, it flies within the bounds of its flight plan under control of the flight control system 620.”). Bruno fails to specifically teach: (re claim 53) determine, based on operational status data persistently stored in non-volatile memory of the UAV, whether operational state flags correspond to predefined readiness conditions comprising at least a maintenance status, a pre-flight checklist status, and a flight-hour limit status. Cui teaches, at Fig. 5 and paragraphs [0037-0038], mission information subsystem 125 may include a mission profile 129, which sets time constraints, and checklists 130 to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Paragraph [0023] teaches a mission policy management system 89, which includes the mission information subsystem 125, may be implemented in a UAV 2. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. In view of Cui’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the medium as taught by Bruno, (re claim 53) determine, based on operational status data persistently stored in non-volatile memory of the UAV, whether operational state flags correspond to predefined readiness conditions comprising at least a maintenance status, a pre-flight checklist status, and a flight-hour limit status, with a reasonable expectation of success, since Cui teaches setting time constraints and implementing checklists to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff. Setting such time constraints and attending to checklists of maintenance items ensures such UAVs are prepared to successfully complete their missions, and do not overextend their fuel supplies. Bruno further teaches: Re claim 54. Wherein the instructions further cause the UAV to: receive updated authorization information during execution of the flight plan, determine whether an updated authorization condition is not satisfied based on the updated authorization information and the operational state flags, and in response to the updated authorization condition not being satisfied, automatically execute a contingency action including at least one of terminating the mission, altering the flight path to avoid a restricted area, or navigating to a designated landing location (Column 9, lines 3-8: “For support of UAV flight plans beyond a specified duration, the UAV must be equipped with an LTE, cellular, or SATCOM communications capability which would allow it to receive in-flight flight plan renewals or updates in order to support extended operations, or intentional confinement by the RA.” And (column 12, lines 31-34: “Similarly, as the time boundary of the flight plan is approached, the flight control system 620 autonomously returns and lands the UAV at its launch coordinates to avoid exceeding the time boundary.”). Re claim 55. Wherein the instructions further cause the UAV to decrypt the flight plan using a private key stored on the UAV, the flight plan having been encrypted using a public key associated with the UAV (column 11, lines 22-56: “Public and private encryption and decryption keys for securely storing the contained data.”; and “Secure vault 640 can be written to only via the flight plan loading process by utilizing the encryption enabled by the public and private keys.”). Claims 36 and 51 are rejected under 35 U.S.C. 103 as being unpatentable over Bruno et al. (US Patent No. 9,734,723) as modified by Cui et al. (US Publication No. 2018/0061249) as applied to claim 31 above, and further in view of Bauer et al. (US Publication No. 2018/0002010). The teachings of Bruno have been discussed above. Bruno fails to specifically teach: (re claim 36) wherein the flight plan is authorized by a cloud system that generates the flight plan and is subsequently authorized by a ground control system that transmits the flight plan to the UAV; and (re claim 51) wherein the communication interface is configured to receive the flight plan after the flight plan has been authorized by a cloud system that generates the flight plan and subsequently authorized by a ground control system that transmits the flight plan to the UAV. Bauer teaches, at paragraph [0120], using a cloud system 120 in conjunction with a ground control system to generate a flight plan. Using such a known combination of a cloud system and a ground control system to generate a flight plan will yield the predictable result of generating a flight plan using distributed processing, with all of the benefits associated therewith. In view of Bauer’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the method as taught by Bruno, (re claim 36) wherein the flight plan is authorized by a cloud system that generates the flight plan and is subsequently authorized by a ground control system that transmits the flight plan to the UAV; and (re claim 51) wherein the communication interface is configured to receive the flight plan after the flight plan has been authorized by a cloud system that generates the flight plan and subsequently authorized by a ground control system that transmits the flight plan to the UAV, with a reasonable expectation of success, since Bauer teaches, at paragraph [0120], using a cloud system 120 in conjunction with a ground control system to generate a flight plan. Using such a known combination of a cloud system and a ground control system to generate a flight plan will yield the predictable result of generating a flight plan using distributed processing, with all of the benefits associated therewith. Claim 41 is rejected under 35 U.S.C. 103 as being unpatentable over Bruno et al. (US Patent No. 9,734,723) as modified by Cui et al. (US Publication No. 2018/0061249) as applied to claim 31 above, and further in view of Zhang et al. (US Publication No. 2019/0278897). The teachings of Bruno have been discussed above. Bruno fails to specifically teach: (re claim 41) wherein determining compliance with predefined readiness conditions further includes: verifying that no onboard components are identified in a component blacklist, the component blacklist stored on the UAV or received from the computer system. Zhang teaches, at paragraph [0268], using a blacklist to exclude certain operators from operating UAVs with specific UAV components. Preventing certain users from operating certain component combinations ensures users only operate UAVs with components they are authorized to operate. In view of Zhang’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the method as taught by Bruno, (re claim 41) wherein determining compliance with predefined readiness conditions further includes: verifying that no onboard components are identified in a component blacklist, the component blacklist stored on the UAV or received from the computer system, with a reasonable expectation of success, since Zhang teaches using a blacklist to exclude certain operators from operating UAVs with specific UAV components. Preventing certain users from operating certain component combinations ensures users only operate UAVs with components they are authorized to operate. Claim 43 is rejected under 35 U.S.C. 103 as being unpatentable over Bruno et al. (US Patent No. 9,734,723) as modified by Cui et al. (US Publication No. 2018/0061249) as applied to claim 31 above, and further in view of Gaydoul et al. (US Publication No. 2009/0142569). The teachings of Bruno have been discussed above. Bruno fails to specifically teach: (re claim 43) wherein determining compliance with predefined readiness conditions further includes: verifying that all required onboard components are identified in a component whitelist. Gaydoul teaches, at paragraph [0051], maintaining a list of components approved for use in aircraft such that the combined system is safe and reliable. In view of Gaydoul’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include, with the method as taught by Bruno, (re claim 43) wherein determining compliance with predefined readiness conditions further includes: verifying that all required onboard components are identified in a component whitelist, with a reasonable expectation of success, since Gaydoul teaches maintaining a list of components approved for use in aircraft such that the combined system is safe and reliable. Allowable Subject Matter Claims 37, 42, and 49 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Response to Arguments Applicant's arguments filed 1/20/2026 have been fully considered but they are not persuasive. Applicant remarks, on pages 10-11: amended claim 31 expressly requires that the UAV itself performs the readiness determination using persistently stored onboard data and that this determination occurs prior to enabling propulsion or autonomous flight control. This is a fundamentally different enforcement model than the mission-centric logic of Bruno or the cloud-centric authorization refinements of Cui. However, Bruno teaches the UAV 200 includes a flight lock module 210 which releases the flight lock only when the stored location and timing data adhere to the define flight plan. The UAV will not fly before the flight lock has been turned off. These elements are taught at Bruno, column 8, lines 51-62; column 9, lines 31-49; and column 11, lines 22-61 as discussed above. Cui teaches a mission information subsystem 125, which may be implemented in a UAV 2, sets time constraints and checklists to verify a UAV’s fuel supply and other suitable operating parameters prior to takeoff at Fig. 5 and paragraphs [0023 and 0037-0038]. Applicant remarks, on page 11: The amended claims require that authorization is a necessary but not sufficient condition for flight. That is, even with valid authorization, the UAV must independently confirm that it is in a compliant operational state-based on maintenance history, checklist completion, and accumulated flight hours-before it is permitted to arm or fly. Nothing in Bruno or Cui teaches, discloses or fairly suggests this separation between authorization validity and physical operability enforced at the UAV level. To the contrary, the references presume that a compliant system will execute an authorized mission. Bruno teaches receiving an authorized flight plan, at Fig. 3 and column 8, lines 51-62, via a digitally signed approved flight plan. Bruno verifies the authorization information at the UAV by ensuring a text result of a decryption of the flight plan matches a clear text version of the flight plan at column 9, lines 31-49. This signed approved flight plan further specifies an identification of the authorized UAV, a region of airspace, and a timeframe that the UAV may fly. These items specified by the approved flight plan are checked for compliance at the UAV as the location and timeframe stored in the UAV must match those specified in the flight plan, see column 9, lines 31-49. 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 SPENCER D PATTON whose telephone number is (571)270-5771. The examiner can normally be reached Monday to Friday 9:00-5:00 ET. 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, Khoi Tran can be reached at (571)272-6919. 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. /SPENCER D PATTON/Primary Examiner, Art Unit 3656
Read full office action

Prosecution Timeline

Feb 22, 2024
Application Filed
Sep 17, 2025
Non-Final Rejection — §103
Jan 20, 2026
Response Filed
Feb 05, 2026
Final Rejection — §103
Apr 09, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602061
UNMANNED AERIAL VEHICLE INSPECTION ROUTE GENERATING APPARATUS AND METHOD
2y 5m to grant Granted Apr 14, 2026
Patent 12583112
MOTION PLANNING TECHNIQUE FOR ROBOTIC SYSTEMS
2y 5m to grant Granted Mar 24, 2026
Patent 12575899
MANUAL AND ROBOTIC END EFFECTOR MOVEMENT COORDINATION
2y 5m to grant Granted Mar 17, 2026
Patent 12569991
VARIABLE PAYLOAD ROBOT
2y 5m to grant Granted Mar 10, 2026
Patent 12558171
FORCE ESTIMATION AND VISUAL FEEDBACK IN SURGICAL ROBOTICS
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
74%
Grant Probability
90%
With Interview (+15.9%)
3y 1m
Median Time to Grant
Moderate
PTA Risk
Based on 575 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month