DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been presented for examination.
Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/13/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed an abstract idea without significantly more.
Independent claim 11 (non-transitory computer readable media) and independent claim 16 (method) are treated as representative. The dependent claims 12–15 and 17–20 do not add additional elements that integrate the abstract idea into a practical application or provide an inventive concept, for the reasons below.
Claim 11. Non-transitory computer readable media storing instructions operable to cause one or more processors of a dock to perform operations for automated pre-flight unmanned aerial vehicle (UAV) inspection, the operations comprising:
determining to perform an automated pre-flight inspection of a UAV while the UAV is located at the dock;
performing the automated pre-flight inspection using one or more sensors to produce output representing operational states of the UAV;
and enabling a launch process for the UAV to exit the dock based on the output.
Step 1: Statutory Category – Yes
Claim 11 recites “non-transitory computer readable media” storing instructions and thus falls within the statutory category of a manufacture. See MPEP 2106.03.
Step 2A Prong One Evaluation: Judicial Exception – Yes (Mental Processes)
In Step 2A Prong One of the 2019 PEG, the claim is analyzed to determine whether it recites a judicial exception (mathematical concept, mental process, or certain methods of organizing human activity).
The Office submits that the foregoing limitation(s) recites an abstract idea in the form of a mental process because, under its broadest reasonable interpretation, the claimed operations can be performed in the human mind or by a human using pen and paper. See MPEP 2106.04(a)(2)(III).
Claim 11, under its broadest reasonable interpretation, recites a sequence of operations such as: determining to perform an inspection, performing the inspection using sensors to produce output representing operational states. These steps amount to collecting information (inspection/sensor data), analyzing/evaluating information (operational states), and determining an outcome (enable launch based on the evaluated output). Such data collection, evaluation, and decision-making can be performed mentally or with pen-and-paper and therefore recite a mental process.
Accordingly, claim 11 recites an abstract idea.
Step 2A Prong Two Evaluation: Practical Application – No
In Step 2A, Prong two of the 2019 PEG, a claim is evaluated to determine whether it integrates the recited judicial exception into a practical application. As noted in MPEP 2106.04(d), it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. The courts have indicated that additional elements such as: merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The Office submits that the foregoing limitation(s) recite additional elements that do not integrate the recited judicial exception into a practical application.
The claim must be evaluated to determine whether it integrates the judicial exception into a practical application. The additional elements beyond the abstract idea include: one or more processors, a dock, one or more sensors, and enabling a launch process for the UAV to exit the dock based on the output. Further, the step of “enabling a launch process for the UAV to exit the dock based on the output” is interpreted as an output/authorization step, consistent with [0140] of the specification (“a launch operation for the UAV to exit the dock may be enabled based on the output.”). As such, this step amounts to insignificant extra-solution activity because it merely acts on or reports the result of the abstract evaluation (i.e., the operational-state output) and does not impose meaningful limits on the claim such that it is no more than nominally or tangentially related to the invention. See MPEP 2106.05(g). These additional elements do not integrate the abstract idea into a practical application because they merely recite generic computer components and a field-of-use environment (UAV dock/pre-flight context) performing routine functions (collecting inspection data, producing output, enabling launch). The claim does not recite a specific improvement to computer functionality, sensor technology, UAV control, or dock hardware; it instead uses generic components to implement the abstract decision logic of inspection, output, launch enablement. Therefore, the claim does not integrate the abstract idea into a practical application.
Step 2B Evaluation: Inventive Concept – No
In Step 2B, it is evaluated whether the claim includes additional elements that amount to significantly more than the judicial exception. Claim 11 does not contain significantly more than the abstract idea because: the processors and sensors are recited at a high level of generality, the operations are stated as results (determine, perform inspection, produce output, enable launch) without a specific technological mechanism, there is no unconventional arrangement of components or non-routine processing that improves the functioning of the dock/UAV/sensors. Accordingly, claim 11 is directed to an abstract idea and does not include an inventive concept.
Independent Claims: Claim 16 recites a method, which falls within the statutory category of a process. See MPEP 2106.03. Claim 16 recites a mental process because it includes: performing an inspection to determine operational states (evaluation/analysis). These steps are again directed to collecting information, analyzing it, and reporting results—operations that can be performed mentally or with pen and paper under the broadest reasonable interpretation. See MPEP 2106.04(a)(2)(III). Therefore, claim 16 is rejected under the same rationale.
Step 1: Statutory Category – Yes
Claim 16 recites a method, which falls within the statutory category of a process. See MPEP 2106.03.
Step 2A Prong One Evaluation: Judicial Exception – Yes (Mental Processes)
Claim 16 recites an abstract idea in the form of a mental process, because under its broadest reasonable interpretation it recites collecting and evaluating information to determine operational states (i.e., inspection data, determining operational states). See MPEP 2106.04(a)(2)(III).
Step 2A Prong Two Evaluation: Practical Application – No
The claim is evaluated to determine whether it integrates the abstract idea into a practical application. The additional elements include: the “dock,” “one or more sensors,” and a “computing device,” as well as the steps of “obtaining instructions” and “transmitting output… for storage or display.” These additional elements do not integrate the abstract idea into a practical application. The dock, sensors, and computing device are recited generically and serve only as a technological environment for implementing the abstract inspection/evaluation logic. Moreover, “obtaining instructions” is a data gathering step necessary to perform the abstract idea, and “transmitting output… for storage or display” is a data output step reporting results. Both amount to insignificant extra-solution activity that does not meaningfully limit the abstract idea. See MPEP 2106.05(g). Therefore, claim 16 does not integrate the abstract idea into a practical application.
Step 2B Evaluation: Inventive Concept – No
Claim 16 does not recite significantly more than the abstract idea. The claim does not recite a specific technological improvement to the dock, sensors, UAV systems, or computing device, and it does not recite an unconventional arrangement or non-routine processing. The steps are stated at a results level (obtain instructions; determine operational states; transmit output) using generic components performing routine functions. Accordingly, claim 16 is directed to an abstract idea without an inventive concept.
Dependent claims (12–15, 17–20):
Claim 12 adds transmitting output for display at a user device and enabling launch according to a user-device signal. These limitations still fall within collecting, transmitting, and acting on information and do not add a technical improvement; they are routine output/authorization steps that do not integrate the abstract idea into a practical application and do not provide an inventive concept.
Claim 13 adds user-device signaling, output including visual data, and streaming visual data during inspection. These are additional information collection/output steps (capturing and streaming data) using generic cameras and communication and thus do not provide significantly more than the abstract idea.
Claim 14 specifies camera types (dock camera, gimbal camera, navigation camera). This is a field-of-use limitation describing conventional components at a high level and does not add a technological improvement or inventive concept.
Claim 15 adds that the determination is performed using output of an artificial intelligence model trained for use with the UAV/dock. This limitation still amounts to generic automation of the abstract decision (whether to perform inspection) and is recited without specific technical details about the model, training, architecture, or how it improves the operation of the dock/UAV, and therefore does not provide significantly more.
Claim 17 adds obtaining second instructions from a user device via UI interactions and performing inspection portions according to those instructions. This is still information receipt and conditional execution (human-in-the-loop control) and does not integrate the abstract idea into a practical application or supply an inventive concept.
Claim 18 adds streaming information associated with the inspection to the user device during the inspection. This is a generic communication/output function and does not provide significantly more.
Claim 19 specifies the computing device is the user device. This is merely a designation of where the output is sent/displayed and does not add significantly more.
Claim 20 adds enabling a launch process based on operational states. This is the same abstract decision/authorization concept as claim 11 and does not provide significantly more.
Therefore, claims 11-20 are ineligible under 35 USC § 101.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 4-6, 8-13, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Salgueiro (US 20170190423 A1), in view of Arksey (US 20220399936 A1).
Regarding Claim 1, Salgueiro discloses a system for automated pre-flight unmanned aerial vehicle (UAV) inspection [0002] “The present disclosure relates generally to unmanned aerial vehicles (UAVs) and, more particularly, to pre-flight test mechanisms for UAVs.”, the system comprising:
a UAV including one or more cameras, one or more sub-systems, and a frame [0020] “include a UAV 102.” [0018] “The UAV includes a frame” [0034] “A down-pointing camera 216 on UAV 102” [0091] “the controller of the UAV may check its motor currents, motor control circuits, batteries, flight computers, communications systems, sensors, any intelligence in the payload, or any other UAV systems (i.e., sub-systems), to determine whether the internal systems of the UAV are performing within acceptable limits.” and;
a dock including one or more processors, one or more memories, and one or more sensors configured for use with an automated pre-flight inspection of the UAV while the UAV is located at the dock [0016] “a controller instructs an unmanned aerial vehicle (UAV) docked to a landing perch to perform a pre-flight test operation of a pre-flight test routine. The controller receives sensor data associated with the pre-flight test operation from one or more force sensors of the landing perch, in response to the UAV performing the pre-flight test operation. The controller determines whether the sensor data associated with the pre-flight test operation is within an acceptable range. The controller causes the UAV to launch from the landing perch based in part on a determination that UAV has passed the pre-flight test routine.” [0017] “The landing perch further has a controller that includes one or more network interfaces to communicate with a computer network, a processor coupled to the one or more network interfaces and configured to execute a process, and a memory configured to store the process executable by the processor.” [0022] “landing perch 106 configured to couple with UAV 102.”, wherein the one or more processors are configured to execute instructions stored in the one or more memories to:
perform the automated pre-flight inspection using the one or more sensors to produce output representing operational states of the one or more sub-systems, and one or more portions of the frame [0016] “a controller instructs an unmanned aerial vehicle (UAV) docked to a landing perch to perform a pre-flight test operation of a pre-flight test routine. The controller receives sensor data associated with the pre-flight test operation from one or more force sensors of the landing perch, in response to the UAV performing the pre-flight test operation. The controller determines whether the sensor data associated with the pre-flight test operation is within an acceptable range.” [0042] “sensors 232 may be used to test various maneuvers that may be performed by UAV 102 (e.g., rise, hover, descent, turn, bank, etc.), to ensure the correct forces act on the frame of UAV 102 as part of a pre-flight test routine. Once UAV 102 has completed such a test routine, and the load cell readings are verified as within limits, the post magnets formed by coils 226 may be reversed, and UAV 102 can be launched with confidence that all systems are operating correctly.” [0089] “sensors measure the resulting lift force” [0080] “verify that all rotors and flight controls are functioning normally” [0091] “perform a self-test of internal systems”, and transmit the output for display at a user device associated with the UAV [0067] “Peripheral interface(s) 415 include the mechanical, electrical, and signaling circuitry for communicating data to and/or from any of the peripheral components of UAV 102 and/or landing perch 106. For example, controller 400 may provide control signals to any of coils 226 or to a pump or other mechanism used to force a heating or cooling medium through an aperture 230 on a post 222 of landing perch 106. In another example, controller 400 may receive sensor data from a sensor 232 on any of posts 222-224 of landing perch 106. Further peripherals that may receive control commands from controller 400 and/or provide data to controller 400 via interfaces 415 may include, but are not limited to, cameras (e.g., camera 236, camera 216, etc.), microphones, security sensors, marker lights (e.g., beacon lights 234), keypads, electronic displays, environmental sensors/monitors, or the like. (i.e., user device with the UAV to transmit and display data)”
Salgueiro does not appear to teach the full claim limitations regarding the “operational states of the one or more cameras”
However, Arksey teaches equivalent teachings output operational states of the one or more cameras [0204] “Drones 12100 may upon hive arrival begin their preflight process 12105 to check their systems and ensure they can operate safely.” [0205] “Drones 12100 may then enter their launch and calibrate module 12110 and perform basic checks to ensure each drone is operating nominally. Drones 12100 may image known objects to ensure that optical and other systems are working properly. They may for example orbit their launching hive and observe the visual and RF markers 12230 to calibrate their visual systems and may correct optical flaws such as dirty lens or estimate the visibility issues such as fog or rain. They may also calibrate their RF systems and ensure that there are no unanticipated network problems.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro and Arksey to make the system wherein to output operational states of the one or more cameras.
A person that is skilled in the art would have been motivated to combine Salgueiro and Arksey to improve overall system operation by calibrating the visual system of the UAV Arksey [0205] “Drones 12100 may then enter their launch and calibrate module 12110 and perform basic checks to ensure each drone is operating nominally. Drones 12100 may image known objects to ensure that optical and other systems are working properly. They may for example orbit their launching hive and observe the visual and RF markers 12230 to calibrate their visual systems and may correct optical flaws such as dirty lens or estimate the visibility issues such as fog or rain. They may also calibrate their RF systems and ensure that there are no unanticipated network problems.”
Regarding Claim 6, The combination of Salgueiro with Arksey teaches the system of claim 1, Salgueiro discloses wherein the one or more sensors include some lights to illuminate on the dock and one or more dock cameras configured to capture visual data depicting the UAV during the automated pre-flight inspection [0034] “Base 220 may also include a set of one or more beacon lights 234 that UAV 102 may use to adjust its alignment and orientation during a landing.” [0036] “base 220 may include a security camera 236. Using a fisheye lens, for example, security camera 236 may survey the sky and surrounding ground horizons, to ensure no obstructions or other UAVs are in the area prior to takeoff of UAV 102. In some cases, security camera 236 may also be operable to record a malicious user that attempts to steal or vandalize UAV 102, package 104, landing perch 106, or any other device associated with package delivery system 100.”
Salgueiro does not appear to teach the claim limitation regarding “one or more dock lights configured to illuminate during the automated pre-flight inspection”
However, Arksey teaches equivalent teachings to include one or more dock lights configured to illuminate during the automated pre-flight inspection [0166] ““Hive architecture 700 may include (drone) hive 7100 as well as one or more landing or takeoff systems. In some embodiments, the landing/takeoff systems may be used with passive visual lighting, active lighting, or RF beacons to allow drones to localize landing site 7160” [0167] “Hive architecture 700 may include one or more markers 7180, which may be static optical or lit in a pattern. In some embodiments, hive architecture 700 may also include multiple lights 7190 allowing blink patterns to aid in localization. In addition, hive 700 may include multiple RF beacons 7230, such as Bluetooth LE or UWB that provide precise localization on the various part of hive 700. In some embodiments, hive 700 may have markers, such as QR codes, to calibrate measurement rulers as part of any of these systems.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro and Arksey to make the system wherein to include one or more dock lights configured to illuminate during the automated pre-flight inspection.
A person that is skilled in the art would have been motivated to combine Salgueiro and Arksey to improve overall system operation by calibrating the visual system of the UAV Arksey [0205] “Drones 12100 may then enter their launch and calibrate module 12110 and perform basic checks to ensure each drone is operating nominally. Drones 12100 may image known objects to ensure that optical and other systems are working properly. They may for example orbit their launching hive and observe the visual and RF markers 12230 to calibrate their visual systems and may correct optical flaws such as dirty lens or estimate the visibility issues such as fog or rain. They may also calibrate their RF systems and ensure that there are no unanticipated network problems.”
Regarding Claim 8, The combination of Salgueiro with Arksey teaches the system of claim 6, Salgueiro discloses wherein the visual data is streamed to the user device during the automated pre-flight inspection [0056] “An operator console may be located in the front passenger seat of road vehicle 320, allowing the driver or copilot to monitor and manage the operation of storage areas 314, 316 and all UAVs 102 in the flock.” [0067] “Peripheral interface(s) 415 include the mechanical, electrical, and signaling circuitry for communicating data to and/or from any of the peripheral components of UAV 102 and/or landing perch 106. Further peripherals that may receive control commands from controller 400 and/or provide data to controller 400 via interfaces 415 may include, but are not limited to, cameras (e.g., camera 236, camera 216, etc.), microphones, security sensors, marker lights (e.g., beacon lights 234), keypads, electronic displays, environmental sensors/monitors, or the like. [0071] “During operation, controller 400 may use cloud computing techniques (e.g., centralized processing from one or more remote servers) or fog computing techniques (e.g., extending the cloud computing paradigm to the edges of the network), to coordinate the operations of all of the sensors, actuators, and networking functions of landing perch 106 and/or UAV 102. For example, controller 400 may not have a persistent Internet connection or have a limited bandwidth Internet connection. In such cases, controller 400 may be configured to exchange data (e.g., delivery confirmations, status information, compartment requests, etc.) with another device (e.g., a delivery vehicle, a user device, etc.) that forwards the information to a central server.”
Regarding Claim 9, The combination of Salgueiro with Arksey teaches the system of claim 1, Salgueiro discloses wherein the automated pre-flight inspection is performed in response to a signal, from the user device, indicating to prepare the UAV for flight [0056] “An operator console may be located in the front passenger seat of road vehicle 320, allowing the driver or copilot to monitor and manage the operation of storage areas 314, 316 and all UAVs 102 in the flock.” [0055] “Example computing equipment that may be located on vehicle 320 may include a controller system responsible for the centralized coordination of UAV operations, including scheduling, route planning, resource management, security, safety monitoring, testing of UAVs, inventory, analytics, and/or other functions. A communications subsystem of vehicle 320 may manages data links from the truck to the Internet. For example, such a communication system may use satellite, 3G/4G cellular, or other wireless connections. Alternatively, or in addition to, vehicle 320 may be configured to communicate via a wired connection (e.g., fiber, Cat 5, etc.) if vehicle 320 is parked. Orders, status updates, air traffic control messages, and/or remote telemetry from all UAVs 102 may use these Internet connections. In some cases, vehicle 320 may also use various short-range communication mechanisms to communicate with the UAV flock. For example, vehicle 320 may communicate with UAVs 102 via wireless channels, optical data links and/or beacon lights provided by perches 106 or otherwise integrated into roost 300.”
Regarding Claim 10, The combination of Salgueiro with Arksey teaches the system of claim 1, Salgueiro discloses wherein the automated pre-flight inspection is performed according to a schedule defined for one or both of the dock or the UAV [0055] “Example computing equipment that may be located on vehicle 320 may include a controller system responsible for the centralized coordination of UAV operations, including scheduling, route planning, resource management, security, safety monitoring, testing of UAVs, inventory, analytics, and/or other functions.”
Regarding Claim 11, The combination of Salgueiro with Arksey teaches a non-transitory computer readable media storing instructions operable to cause one or more processors of a dock to perform operations for automated pre-flight unmanned aerial vehicle (UAV) inspection, the operations comprising:
Salgueiro discloses determining to perform an automated pre-flight inspection of a UAV while the UAV is located at the dock; performing the automated pre-flight inspection using one or more sensors to produce output representing operational states of the UAV; and enabling a launch process for the UAV to exit the dock based on the output [0133] “it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof.” [0016] “a controller instructs an unmanned aerial vehicle (UAV) docked to a landing perch to perform a pre-flight test operation of a pre-flight test routine. The controller receives sensor data associated with the pre-flight test operation from one or more force sensors of the landing perch, in response to the UAV performing the pre-flight test operation. The controller determines whether the sensor data associated with the pre-flight test operation is within an acceptable range. The controller causes the UAV to launch from the landing perch based in part on a determination that UAV has passed the pre-flight test routine.”
Regarding Claim 12, The combination of Salgueiro with Arksey teaches the non-transitory computer readable media of claim 11, Salgueiro discloses wherein the launch process is enabled according to a signal from the user device [0093]: “An operator console may be located in the front passenger seat of road vehicle 320, allowing the driver or copilot to monitor and manage the operation of storage areas 314, 316 and all UAVs 102 in the flock. If a UAV on a delivery run is having difficulties (e.g., the UAV cannot locate an address, cannot find a good place to land, is under attack, is having a mechanical or electrical problem, etc.) the user console can function as a manual pilot station, and the human can guide that UAV out of trouble, in one embodiment.” [0095]: “At step 536, the controller may download the flight authorization to the UAV (e.g., a certificate, etc.) and instruct the UAV to begin its launch sequence. Such a launch sequence may entail, for example, the UAV starting its rotors and notifying the landing perch when the UAV is ready for takeoff.”
The claim also recites the parallel limitations in claims 1 and 11, respectively for the reasons discussed above. Therefore, claim 12 is rejected using the same rational reasoning.
Regarding Claim 13, The claim recites a non-transitory computer readable media of the parallel limitations in claims 6, 9, and 8, respectively for the reasons discussed above. Therefore, claim 13 is rejected using the same rational reasoning.
Regarding Claim 16, The combination of Salgueiro with Arksey teaches the non-transitory computer readable media of claim 11, Salgueiro discloses obtaining instructions to use a dock to perform an automated pre-flight inspection of a UAV while the UAV is located at the dock [0018] “The UAV also has a controller that includes one or more interfaces to communicate with the landing perch, a processor coupled to the one or more interfaces and configured to execute a process, and a memory configured to store the process executable by the processor. When executed, the process is operable to receive an instruction (i.e., obtaining instructions) from the landing perch to perform a pre-flight test operation. The process when executed is also operable to perform the pre-flight test operation while the UAV is docked at the landing perch (i.e., while the UAV is located at the dock). The process when executed is further operable to receive launch authorization from the landing perch and to launch the UAV from the landing perch.”
The claim also recites a method of the parallel limitations in claim 1, respectively for the reasons discussed above. Therefore, claim 16 is rejected using the same rational reasoning.
Regarding Claim 17, The combination of Salgueiro with Arksey teaches the method of claim 16, Salgueiro discloses wherein the instructions are obtained from a user device [0056] “An operator console may be located in the front passenger seat of road vehicle 320, allowing the driver or copilot to monitor and manage the operation of storage areas 314, 316 and all UAVs 102 in the flock. If a UAV on a delivery run is having difficulties (e.g., the UAV cannot locate an address, cannot find a good place to land, is under attack, is having a mechanical or electrical problem, etc.) the user console can function as a manual pilot station, and the human can guide that UAV out of trouble, in one embodiment.”,
and wherein performing the automated pre-flight inspection comprises: obtaining, from the user device during the automated pre-flight inspection, second instructions produced via interactions with a user interface at the user device; and performing at least a portion of the automated pre-flight inspection according to the second instructions [0018] “The UAV also has a controller that includes one or more interfaces to communicate with the landing perch, a processor coupled to the one or more interfaces and configured to execute a process, and a memory configured to store the process executable by the processor. When executed, the process is operable to receive an instruction (i.e., obtaining instructions) from the landing perch to perform a pre-flight test operation. The process when executed is also operable to perform the pre-flight test operation while the UAV is docked at the landing perch (i.e., while the UAV is located at the dock). The process when executed is further operable to receive launch authorization from the landing perch and to launch the UAV from the landing perch.” [0058] “An example of roost 300 in operation is as follows. First, the driver of vehicle 320 may drive and park vehicle 320 in a location that is within UAV range of all delivery addresses. Next, roof 312 is retracted and UAVs 102 and perches 106 are enabled. A particular UAV 102 located on a storage perch 106 in group 306 may then be assigned to a particular delivery order by the local server. The particular UAV 102 may then undergo a pre-flight self-test procedure while still anchored magnetically to its perch 106.” [0071] “controller 400 may be configured to exchange data (e.g., delivery confirmations, status information, compartment requests, etc.) with another device (e.g., a delivery vehicle, a user device, etc.) that forwards the information to a central server.”
Regarding Claim 18, The claim recites a method of the parallel limitations in claims 8, respectively for the reasons discussed above. Therefore, claim 18 is rejected using the same rational reasoning.
Regarding Claim 19, The claim recites a method of the parallel limitations in claims 1, respectively for the reasons discussed above. Therefore, claim 19 is rejected using the same rational reasoning.
Regarding Claim 20, The claim recites a method of the parallel limitations in claim 11, respectively for the reasons discussed above. Therefore, claim 20 is rejected using the same rational reasoning.
Claim(s) 2-5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Salgueiro (US 20170190423 A1), in view of Arksey (US 20220399936 A1), and further in view of Woodman (US 20200391878 A1).
Regarding Claim 2, The combination of Salgueiro with Arksey teaches the system of claim 1, Salgueiro discloses wherein, to perform the automated pre-flight inspection [0002] “The present disclosure relates generally to unmanned aerial vehicles (UAVs) and, more particularly, to pre-flight test mechanisms for UAVs.” [0016] “a controller instructs an unmanned aerial vehicle (UAV) docked to a landing perch to perform a pre-flight test operation of a pre-flight test routine. The controller receives sensor data associated with the pre-flight test operation from one or more force sensors of the landing perch, in response to the UAV performing the pre-flight test operation. The controller determines whether the sensor data associated with the pre-flight test operation is within an acceptable range.”, the one or more processors are configured to execute the instructions to:
determine, for each of the one or more sub-systems, a second operational state indicating a condition of the sub-system [0016] “a controller instructs an unmanned aerial vehicle (UAV) docked to a landing perch to perform a pre-flight test operation of a pre-flight test routine. The controller receives sensor data associated with the pre-flight test operation from one or more force sensors of the landing perch, in response to the UAV performing the pre-flight test operation. The controller determines whether the sensor data associated with the pre-flight test operation is within an acceptable range.” [0042] “sensors 232 may be used to test various maneuvers that may be performed by UAV 102 (e.g., rise, hover, descent, turn, bank, etc.), to ensure the correct forces act on the frame of UAV 102 as part of a pre-flight test routine. Once UAV 102 has completed such a test routine, and the load cell readings are verified as within limits, the post magnets formed by coils 226 may be reversed, and UAV 102 can be launched with confidence that all systems are operating correctly.” [0089] “sensors measure the resulting lift force” [0080] “verify that all rotors and flight controls are functioning normally” [0091] “perform a self-test of internal systems”,
Salgueiro does not appear to teach the claim limitation regarding “determine, for each of the one or more cameras, a first operational state indicating whether a lens of the camera is clean”
However, Arksey teaches equivalent teachings wherein to determine, for each of the one or more cameras, a first operational state indicating whether a lens of the camera is clean [0204] “Drones 12100 may upon hive arrival begin their preflight process 12105 to check their systems and ensure they can operate safely.” [0205] “Drones 12100 may then enter their launch and calibrate module 12110 and perform basic checks to ensure each drone is operating nominally. Drones 12100 may image known objects to ensure that optical and other systems are working properly. They may for example orbit their launching hive and observe the visual and RF markers 12230 to calibrate their visual systems and may correct optical flaws such as dirty lens or estimate the visibility issues such as fog or rain. They may also calibrate their RF systems and ensure that there are no unanticipated network problems.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro and Arksey to make the system wherein to determine, for each of the one or more cameras, a first operational state indicating whether a lens of the camera is clean.
A person that is skilled in the art would have been motivated to combine Salgueiro and Arksey to improve overall system operation by calibrating the visual system of the UAV Arksey [0205] “Drones 12100 may then enter their launch and calibrate module 12110 and perform basic checks to ensure each drone is operating nominally. Drones 12100 may image known objects to ensure that optical and other systems are working properly. They may for example orbit their launching hive and observe the visual and RF markers 12230 to calibrate their visual systems and may correct optical flaws such as dirty lens or estimate the visibility issues such as fog or rain. They may also calibrate their RF systems and ensure that there are no unanticipated network problems.”
The combination of Salgueiro with Arksey does not appear to teach the full claim limitation regarding “determine, for each of the one or more portions of the frame, a third operational state indicating an extent of damage to the portion”
However, Woodman teaches equivalent teachings to determine, for each of the one or more portions of the frame, a third operational state indicating an extent of damage to the portion [0164] “The operational systems information may include information related to flight of the aerial vehicle 110, for example, remaining battery power, mechanical structural integrity (i.e., extent of damage) and operation, and electrical operation. Continuing with this example, if all the arms 135 are not properly extended in a “locked” position for flight (e.g., via a sensor where each arm 135 couples with the housing 130 or electronic connection from the arms 135 to a sensor system or some combination thereof), the systems check module 820 detects this information.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro, Arksey, and Woodman to make the system wherein to determine, for each of the one or more portions of the frame, a third operational state indicating an extent of damage to the portion.
A person that is skilled in the art would have been motivated to combine Salgueiro, Arksey, and Woodman to improve overall system safety before a UAV flight Woodman [0205] “The systems check module 820 identifies the operational systems of the aerial vehicle to ensure safety and correctness before executing the flight plan. The operational systems information may include information related to flight of the aerial vehicle 110, for example, remaining battery power, mechanical structural integrity and operation, and electrical operation. Continuing with this example, if all the arms 135 are not properly extended in a “locked” position for flight (e.g., via a sensor where each arm 135 couples with the housing 130 or electronic connection from the arms 135 to a sensor system or some combination thereof), the systems check module 820 detects this information. The systems check module 820.”
Regarding Claim 3, The combination of Salgueiro with Arksey and Woodman teaches the system of claim 2, The combination of Salgueiro with Arksey does not appear to teach the full claim limitation regarding “wherein the one or more portions of the frame correspond to a body of the UAV and multiple arms of the UAV, and wherein the third operational state determined for an arm of the multiple arms indicates whether the arm is extended and locked”
However, Woodman teaches equivalent teachings wherein the one or more portions of the frame correspond to a body of the UAV and multiple arms of the UAV, and wherein the third operational state determined for an arm of the multiple arms indicates whether the arm is extended and locked [0164] “The systems check module 820 identifies the operational systems of the aerial vehicle to ensure safety and correctness before executing the flight plan. The operational systems information may include information related to flight of the aerial vehicle 110, for example, remaining battery power, mechanical structural integrity and operation, and electrical operation. Continuing with this example, if all the arms 135 are not properly extended in a “locked” position for flight (e.g., via a sensor where each arm 135 couples with the housing 130 or electronic connection from the arms 135 to a sensor system or some combination thereof), the systems check module 820 detects this information. The systems check module 820, through the flight controller 315, may provide notification of this possible operational issue, for example, via lighting an LED 410 on the aerial vehicle 110 and/or transmitting this information via the communications subsystem 360 to the remote controller 120 to provide notification via the display 170 of the remote controller 120. By way of example, when the arms are not locked, the system check module 820 may have the power subsystem 340 (e.g., via the flight controller 315) disable power supply to the thrust motor electronics 325. Also, by way of example, the system check module 820 may disable, e.g., through the flight controller 315, received control signals from the remote controller 120.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro, Arksey, and Woodman to make the system wherein wherein the one or more portions of the frame correspond to a body of the UAV and multiple arms of the UAV, and wherein the third operational state determined for an arm of the multiple arms indicates whether the arm is extended and locked.
A person that is skilled in the art would have been motivated to combine Salgueiro, Arksey, and Woodman to improve overall system safety before a UAV flight Woodman [0205] “The systems check module 820 identifies the operational systems of the aerial vehicle to ensure safety and correctness before executing the flight plan. The operational systems information may include information related to flight of the aerial vehicle 110, for example, remaining battery power, mechanical structural integrity and operation, and electrical operation. Continuing with this example, if all the arms 135 are not properly extended in a “locked” position for flight (e.g., via a sensor where each arm 135 couples with the housing 130 or electronic connection from the arms 135 to a sensor system or some combination thereof), the systems check module 820 detects this information. The systems check module 820.”
Regarding Claim 4, The combination of Salgueiro with Arksey and Woodman teaches the system of claim 2, Salgueiro discloses wherein the one or more sub-systems include one or more of a propulsion system, an electrical system, a vision system, a navigation system, a command-and-control system, or a battery system and the second operational states are determined by performing tests against the each of the one or more sub-systems [0091] “the controller of the UAV commands the UAV to perform a self-test of any or all of the internal systems (i.e., sub-systems) of the UAV. For example, the controller of the UAV may check its motor currents, motor control circuits, batteries, flight computers, communications systems, sensors, any intelligence in the payload, or any other UAV systems, to determine whether the internal systems of the UAV are performing within acceptable limits.”
Regarding Claim 5, The combination of Salgueiro with Arksey and Woodman teaches the system of claim 4, Salgueiro discloses wherein, to determine the third operational state for the propulsion system, the one or more processors are configured to execute the instructions to: cause propellers of the propulsion system to rotate according to input obtained from the user device; and capture, using the one or more sensors, data based on the rotation of the propellers [0042] “sensors 232 may be used to test various maneuvers that may be performed by UAV 102 (e.g., rise, hover, descent, turn, bank, etc.), to ensure the correct forces act on the frame of UAV 102 as part of a pre-flight test routine. Once UAV 102 has completed such a test routine, and the load cell readings are verified as within limits, the post magnets formed by coils 226 may be reversed, and UAV 102 can be launched with confidence that all systems are operating correctly.” [0080] “For example, if the rotors of UAV 102 are energized at flight power while UAV 102 is still magnetically coupled to landing perch 106, sensors 232 may measure the upward and lateral forces on UAV 102. In this way, takeoff process 447 may verify that all rotors and flight controls are functioning normally at full flight power, while UAV 102 is safely retained on perch 106 by the electromagnets. While still docked, UAV 102 may also cycle through various simulated flight maneuvers (e.g., rising, hovering, descending, turning, banking, etc.), allowing takeoff process 447 to use sensor data from sensors 232, to verify that the correct forces are acting on the airframe for each maneuver.” [0089] “sensors measure the resulting lift force” [0091] “perform a self-test of internal systems” [0091] “the controller of the UAV commands the UAV to perform a self-test of any or all of the internal systems (i.e., sub-systems) of the UAV. For example, the controller of the UAV may check its motor currents, motor control circuits, batteries, flight computers, communications systems, sensors, any intelligence in the payload, or any other UAV systems, to determine whether the internal systems of the UAV are performing within acceptable limits.”
Regarding Claim 14, The combination of Salgueiro with Arksey teaches the non-transitory computer readable media of claim 13 [0133] “it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof.”
wherein the one or more cameras include one or more of a camera of the dock [0036] “base 220 may include a security camera 236. Using a fisheye lens, for example, security camera 236 may survey the sky and surrounding ground horizons, to ensure no obstructions or other UAVs are in the area prior to takeoff of UAV 102. In some cases, security camera 236 may also be operable to record a malicious user that attempts to steal or vandalize UAV 102, package 104, landing perch 106, or any other device associated with package delivery system 100.”
The combination of Salgueiro with Arksey does not appear to teach “a gimbal camera of the UAV, or a navigation camera of the UAV”
However, Woodman teaches equivalent teachings wherein the one or more cameras include one or more of a camera of the dock, a gimbal camera of the UAV, or a navigation camera of the UAV [0032] “The aerial vehicle may include a mounting structure that couples with a camera and can secure it. The mounting structure can be removably attachable from the aerial vehicle 110. The mounting structure may include a gimbal to couple with the camera, which can assist with stabilization for image capture.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro, Arksey, and Woodman to make the system wherein the one or more cameras include one or more of a camera of the dock, a gimbal camera of the UAV, or a navigation camera of the UAV.
A person that is skilled in the art would have been motivated to combine Salgueiro, Arksey, and Woodman to improve overall system safety before a UAV flight Woodman [0205] “The systems check module 820 identifies the operational systems of the aerial vehicle to ensure safety and correctness before executing the flight plan. The operational systems information may include information related to flight of the aerial vehicle 110, for example, remaining battery power, mechanical structural integrity and operation, and electrical operation. Continuing with this example, if all the arms 135 are not properly extended in a “locked” position for flight (e.g., via a sensor where each arm 135 couples with the housing 130 or electronic connection from the arms 135 to a sensor system or some combination thereof), the systems check module 820 detects this information. The systems check module 820.”
Claim(s) 7 are rejected under 35 U.S.C. 103 as being unpatentable over Salgueiro (US 20170190423 A1), in view of Arksey (US 20220399936 A1), and further in view of Kimchi (EP 3060885 B1).
Regarding Claim 7, The combination of Salgueiro with Arksey teaches the system of claim 6, The combination of Salgueiro with Arksey does not appear to teach the full claim limitations regarding “wherein the dock includes an enclosure defining a window configured to receive the UAV to allow for entry of the UAV into the dock and exit of the UAV from the station, and wherein the one or more dock cameras include a first dock camera internal to the enclosure and a second dock camera external to the enclosure”
However, Kimchi teaches equivalent teachings wherein the dock includes an enclosure defining a window configured to receive the UAV to allow for entry of the UAV into the dock and exit of the UAV from the station, and wherein the one or more dock cameras include a first dock camera internal to the enclosure and a second dock camera external to the enclosure [0054] “In communicating with UAVs, the control station 401 may be configured to identify when a UAV is arriving, determine a storage compartment module 403, 405, 407, 409 into which the UAV is to place a container 480, open the storage compartment module to allow placement of the container 480 by a UAV and/or take control of the UAV to assist in landing the UAV at the secure delivery location 400. For example, as a UAV approaches the secure delivery location 400, the control station 401 may identify the UAV and determine that the UAV is to disengage a container 480 into the storage compartment module 403. The top doors 403(A) and 403(B) (i.e., a window) of the storage compartment module 403 may be opened by the control system 401 and one or more cameras 406 (i.e., internal and external cameras), and/or other input components, activated to monitor the position of the UAV 200 (not shown). The cameras 406 may be positioned inside the storage compartment modules and only visible externally when the top doors are opened, may be positioned on another exterior surface of the secure delivery location 400 and/or may be positioned remote from the secure delivery location 400 and in communication (e.g., wired and/or wireless) with the control station 401.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro, Arksey, and Kimchi to make the system wherein the dock includes an enclosure defining a window configured to receive the UAV to allow for entry of the UAV into the dock and exit of the UAV from the station, and wherein the one or more dock cameras include a first dock camera internal to the enclosure and a second dock camera external to the enclosure.
A person that is skilled in the art would have been motivated to combine Salgueiro, Arksey, and Kimchi to improve overall system of the UAV landing assist into secure location Kimchi [0054] “the control station 401 may be configured to identify when a UAV is arriving, determine a storage compartment module 403, 405, 407, 409 into which the UAV is to place a container 480, open the storage compartment module to allow placement of the container 480 by a UAV and/or take control of the UAV to assist in landing the UAV at the secure delivery location 400.
Claim(s) 15 are rejected under 35 U.S.C. 103 as being unpatentable over Salgueiro (US 20170190423 A1), in view of Arksey (US 20220399936 A1), and further in view of Kimberly (US 20200180791 A1).
Regarding Claim 15, The combination of Salgueiro with Arksey teaches the non-transitory computer readable media of claim 11,
The combination of Salgueiro with Arksey teaches does not teach “wherein the determination to perform the automated pre-flight inspection is performed using output of an artificial intelligence model trained for use with one or both of the UAV or the dock.”
However, Kimberly teaches equivalent teachings wherein the determination to perform the automated pre-flight inspection is performed using output of an artificial intelligence model trained for use with one or both of the UAV or the dock [0005] “In accordance with one embodiment disclosed in some detail below, the inspection processes generated by the inspection planning module may be dynamic and data- and model-driven at different levels. Each inspection plan may be assembled wholly or partially from a backbone set of pre-calculated (at design time) inspection plans that can be flexibly deployed as guided by the models and data. In addition, each inspection plan may be dynamically created (e.g., generated directly by an artificial intelligence planning system) from system and airplane models and data. For example, these fully dynamic processes can be targeted at achieving high levels of operation reliability and low operational cost.”
It would have been obvious to a person that is skilled in the art before the effective filing date to combine Salgueiro, Arksey, and Kimberly to make the system wherein the determination to perform the automated pre-flight inspection is performed using output of an artificial intelligence model trained for use with one or both of the UAV or the dock.
A person that is skilled in the art would have been motivated to combine Salgueiro, Arksey, and Kimberly to improve overall system flexibility of the UAV inspection Kimberly [0005] “In accordance with one embodiment disclosed in some detail below, the inspection processes generated by the inspection planning module may be dynamic and data- and model-driven at different levels. Each inspection plan may be assembled wholly or partially from a backbone set of pre-calculated (at design time) inspection plans that can be flexibly deployed as guided by the models and data. In addition, each inspection plan may be dynamically created (e.g., generated directly by an artificial intelligence planning system) from system and airplane models and data. For example, these fully dynamic processes can be targeted at achieving high levels of operation reliability and low operational cost.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUSSAM ALZATEEMEH whose telephone number is (703)756-1013. The examiner can normally be reached 8:00-5:00 M-F.
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, Aniss Chad can be reached on (571) 270-3832. 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.
/HUSSAM ALDEEN ALZATEEMEH/Examiner, Art Unit 3662
/Madison R. Inserra/Primary Examiner, Art Unit 3662