DETAILED ACTION
Notice of 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 .
Status of the Application
Claims 1-2 and 4-6 were pending and were rejected in the previous office action. Claims 1, 5, and 6 were amended. Claim 4 was cancelled. Claims 1-2 and 5-6 remain pending and are examined in this office action.
Response to Arguments
35 USC § 101:
Applicant’s arguments with respect to the previous § 101 rejection of claims 1-2 and 4-6 (pgs. 8-10, remarks filed 5/12/2026) have been fully considered and are persuasive. The claims (using claim 1 as representative) are amended to recite: “the controller is further configured to instruct the drone to travel to the vehicle by transmitting control signals to a flight control section of the drone that cause one or more propellers of the drone to fly the drone toward the vehicle” and “the controller then instructs the drone to travel to the updated reception place at the updated reception time by transmitting control signals to the flight control section of the drone that cause the one or more propellers of the drone to fly the drone to the updated reception place to deliver the product ordered by the user.” These limitations clearly integrate any recited abstract idea into a practical application by adding meaningful limitations beyond generally linking the use of the judicial exception to a particular technological environment to transform the judicial exception into patent-eligible subject matter (controlling the drone via control signals that cause propellers of the drone to operate/fly the drone to the updated reception place), similar to Diamond v. Diehr. The § 101 rejection of claims 1-2 and 4-6 is withdrawn.
35 USC § 103:
Applicant’s arguments regarding the previous § 103 rejections of claims 1-2 and 4-6 (pgs. 10-14, remarks filed 5/12/2026) have been considered but are moot as they do not apply to the current grounds of rejection applied in the § 103 rejections of claims 1-2 and 5-6 below, in response to applicant’s amendments. Note that claim 4 is cancelled in the 5/12/2026 amendments. Please see the current § 103 rejection(s) of claims 1-2 and 5-6 below.
Claim Objections
Claim 6 is objected to because of the following informalities:
Claim 6 was amended to recite “the controller is further configured to calculate, in accordance with a subsequent request of the user, a timing to receive the product from the drone” in a similar manner to claims 1 and 5. However, since claim 6 previously recites a computer rather than a controller, it appears that the claim was intended recite “the computer calculating, in accordance with a subsequent request of the user, a timing to receive the product from the drone.”
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190043370 A1 to Mulhall et al. (Mulhall) in view of US 20160253908 A1 to Chambers et al. (Chambers), and further in view of US 20200265383 A1 to Zhang, and further in view of US 20230306355 A1 to Mehta et al. (Mehta).
Claim 1: Mulhall teaches:
A control device (Mulhall: Fig. 1 and ¶ 0032-0033 showing client computing device 104, also see ¶ 0098-0099 showing as a computer hardware implementation wherein “the computer architecture 800 illustrated in FIG. 8 illustrates an architecture for a server computer, or network of server computers, or any other types of computing devices suitable for implementing the functionality described herein. The computer architecture 800 may be utilized to execute any aspects of the software components presented herein”) comprising:
a controller, including at least a processor and a memory (Mulhall: ¶ 0041 showing computing device 104 may include a mobile device or smart phone; ¶ 0099 showing computer hardware implementation including a CPU 802 and memory 804), and provided in a vehicle (Mulhall: ¶ 0041 showing mobile computing device/smart phone within the interior of the receiving vehicle and running the product acquisition application)
the controller configured to: determine an arrival time at which the vehicle will arrive at a destination requested by a user (Mulhall: ¶ 0068 showing “preliminary order data 156(P) is generated via the client computing device 104…the preliminary order data 156(P) may also indicate a latest arrival time that the user can arrive at the destination-location 112. For example, the user may have a meeting scheduled at 11:45 AM at the destination-location 112 such that the preliminary order data 156(P) indicates a latest arrival time of 11:45 AM”; also see ¶ 0009, ¶ 0070, ¶ 0072),
determine a period of delivery time for a drone to deliver, to the vehicle, a product ordered by the user who is traveling in the vehicle (Mulhall: ¶ 0078 “travel-schedule that defines time-based expectations of when the receiving vehicle will reach various points along the first route”; ¶ 0061 showing determined time that vehicle is within rendezvous area for receiving the delivery and ¶ 0064 showing “At time T3, the receiving vehicle 106 and the UAV 108 reach the rendezvous area 114 at substantially the same time when the UAV 108 searches for and ultimately identifies the receiving vehicle. It can be appreciated that designing and timing the flightpath so that the vehicles reach the rendezvous area at substantially the same time conserves energy resources for at least the reasons that the UAV 108 does not have to waste energy by hovering and waiting for the receiving vehicle 106, nor does the UAV have to waste energy by chasing down the receiving vehicle 106 if it has already reached and passed the third-location P3, UAV”),
determine, on a basis of (i) the arrival time when the vehicle will arrive at the destination (Mulhall: ¶ 0006, ¶ 0038, ¶ 0068, ¶ 0070, ¶ 0072 showing use of expected arrival time that a receiving vehicle is expected to arrive at its desired destination, for use in determining when and where UAV may be able to rendezvous to deliver the product; also generally see ¶ 0062 showing estimating time the receiving vehicle arrives at rendezvous location prior to arrival at the final destination) and (ii) the period of delivery time for the drone to deliver, to the vehicle, the product ordered by the user who is traveling in the vehicle (Mulhall: ¶ 0062 showing considering travel time of the UAV for the UAV to go from an originating location, to the rendezvous location for meeting with the vehicle; “the navigation engine 116 may determine that the third-location P.sub.3, UAV is the closest location with which the UAV 108 may rendezvous with the receiving vehicle along the predetermined route while still avoiding one or more volumes of restricted airspace. The navigation engine 116 may further determine an amount of time that the UAV 108 will take to travel from the first fulfillment center 404(1) to the third location”; also see ¶ 0080 showing “flight plan data which indicates when the UAV will be at various points along the flight path”; also see ¶ 0061, ¶ 0064 as per above), whether or not it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination (Mulhall: ¶ 0062 showing determining to dispatch the UAV at the correct time such that it would reach the rendezvous location for delivery at the same time as the en route receiving vehicle; also see ¶ 0080-0083, and ¶ 0070, ¶ 0072, Fig. 5 showing determining whether the en-route rendezvous delivery can be made from the UAV to the vehicle while still allowing the vehicle to arrive at its destination by a predetermined arrival time, considering the factors above, and providing various possible options for rendezvous and delivery from the UAV to the receiving vehicle prior to arrival at the destination),
wherein in a state in which it is determined that the drone can deliver the product ordered by the user before the vehicle arrives at the destination (Mulhall: ¶ 0083, ¶ 0061-0064, Fig. 4 showing determining drone and receiving vehicle can rendezvous for delivery prior to arrival at the destination; also see ¶ 0006 “determine when and where the UAV may be able to efficiently rendezvous with the receiving vehicle to deliver the product”; also see ¶ 0007, ¶ 0036 showing determine when and where to rendezvous between the UAV and the receiving vehicle), the controller is further configured to instruct the drone to travel to the vehicle by transmitting control signals to a flight control section of the drone that cause one or more propellers of the drone to fly the drone toward the vehicle (Mulhall: ¶ 0007-0009 showing order requesting UAV delivery of the product, which causes flight path and flight schedule designed to control the drone to travel to the vehicle, e.g. when and where the UAV will rendezvous; ¶ 0038, ¶ 0050, Fig. 1 showing transmitting flight plan data and dispatch data to the UAV which is stored at navigation module 150 of the UAV, i.e. control signals received at the UAV at flight control section and causing the UAV to fly toward the vehicle destination, wherein as per Figs. 2A-2B the UAV clearly flies through the use of one or more propellers),
With respect to the limitation(s):
in a state in which it is determined that the drone cannot deliver the product ordered by the user before the vehicle arrives at the destination, based on an analysis of a plurality of different flight routes for the drone, the controller is further configured to notify the user that it is impossible to deliver the product before the vehicle arrives at the destination,
Mulhall teaches delivery of a product ordered by the user wherein the product is delivered to the vehicle of the user while it is in transit to, i.e. prior to, its final destination (Mulhall: ¶ 0083, ¶ 0061-0064, ¶ 0006-0007, ¶ 0036), but does not explicitly discuss a situation in which the product is unable to be delivered as originally entered or requested based on analysis of different flight routes.
However, Chambers teaches determining, in a drone package delivery system, based at least in part on analysis of data including a plurality of flight corridors and paths (Chambers: ¶ 0056; ¶ 0049-0058 generally) that a user requested refinement to a delivery route cannot be performed, i.e. impossible to deliver the product, and sending a notification to the user of this determination (Chambers: ¶ 0119-0122 showing based on service request, service request handler may also play an active part in determining the route a UAV 102 takes on a mission to complete a service request; and as per ¶ 0124-0127 a requesting user is presented with a user interface for route refinement and the system received user input of route refinement, which is then validated in a validation process; showing ¶ 0128 “If the route refinement selection is not valid…the system interface manager 406 will send information to the client device that will cause a “selection invalid” indicator to be presented 456 on the client device, so the service requestor 104 realizes that the route refinement selection previously made cannot be used”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the determination that a route to a current delivery selection is infeasible based on current user input of Chambers in the UAV delivery system of Mulhall with a reasonable expectation of success of arriving at the claimed invention, with the motivation to “to confirm that the route refinement selection will not cause the UAV 102 to crash or cause the mission to otherwise fail. Validation is done to ensure that the service requestor 104 has not introduced human error into the routing process. For example, a service requestor 104 could specify a delivery location that is in a body of water, or a trajectory that intersects a building” (Chambers: ¶ 0126).
With respect to the limitation(s):
and, upon receipt of the notification, the user designates an updated reception place and an updated reception time, such that, after a further determination is made as to the viability of the updated reception place and the updated reception time, the controller then instructs the drone to travel to the updated reception place at the updated reception time by transmitting control signals to the flight control section of the drone that cause the one or more propellers of the drone to fly the drone to the updated reception place to deliver the product ordered by the user
Mulhall teaches that a drone transports the delivery order to a user’s dynamic location, e.g. a user moving in a vehicle (Mulhall: ¶ 0004; and ¶ 0083, ¶ 0061-0064, ¶ 0006-0007, ¶ 0036), and teaches instructing the drone to travel to a reception place (or an updated reception place based on changes to delivery) by transmitting control signals to the flight control section of the drone that cause the one or more propellers of the drone to fly the drone (Mulhall: ¶ 0080-0083, ¶ 0004, ¶ 0009, ¶ 0038, ¶ 0050, Fig. 1; Figs. 2A-2B showing propellers used for UAV flight), but does not explicitly teach that upon receipt of a notification indicating an originally scheduled delivery cannot be made, the user provides an updated delivery location and an updated delivery time for instructing delivery of the order to the user.
However, Chambers teaches upon receipt of the notification (Chambers: ¶ 0128 as per above), the user designated an updated reception place, and a route for the drone is validated against the updated reception place (Chambers: ¶ 0128-0129 showing client device used to input new route refinement selection) before then instructing the drone to perform the delivery to the delivery destination (Chambers: ¶ 0129; see ¶ 0040-0041 showing mission data generated and transmitting to the UAV, and the UAV is launched to perform the delivery). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the validate of a new input route refinement from the requesting user to generate UAV delivery instructions of Chambers in the UAV delivery system of Mulhall/Chambers with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the limitation above.
Still, while Chambers receives an updated delivery area selection in response to the notification/prompt, validating the flight path/route to the new delivery destination, and instructing the drone to perform the delivery to the delivery destination (as per above) – Chambers does not explicitly teach that the user responds by also providing an updated delivery time.
However, Zhang teaches that the user selection to modify a delivery request including selection of a new delivery time window and new delivery area or fixed address (Zhang: ¶ 0102-0104). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the user selection of a delivery window when modifying a delivery request of Zhang in the UAV delivery system of Mulhall/Chambers with a reasonable expectation of success of arriving at the claimed invention, with the motivation to allow the user to “select a convenient delivery time window” (Zhang: ¶ 0104). In addition, it would have also been obvious to one of ordinary skill in the art before the effective filing date of the invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
With respect to the limitation:
in the state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is further configured to calculate, in accordance with a subsequent request of the user, a timing to receive the product from the drone
Mulhall teaches determining it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination (Mulhall: ¶ 0077, ¶ 0083, ¶ 0061-0064, Fig. 4 showing determining drone and receiving vehicle can rendezvous for delivery prior to arrival at the destination; also see ¶ 0006 “determine when and where the UAV may be able to efficiently rendezvous with the receiving vehicle to deliver the product”; also see ¶ 0007, ¶ 0036 showing determine when and where to rendezvous between the UAV and the receiving vehicle, and further teaches dynamic updating the flight path of the UAV to orders based on the real-time/current location and speed of the receiving vehicle (Mulhall: ¶ 0077, ¶ 0004, ¶ 0009, ¶ 0095, ¶ 0117), but Mulhall/Chambers/Zhang do not explicitly teach a modification including a step to calculate, in accordance with a subsequent request of the user, a timing to receive the product from the drone.
However, Mehta teaches modifying an existing drone delivery order based on a subsequent request of the user after an original delivery order for at least one product is in progress, and determining/calculating an updated time to receive the product (Mehta: ¶ 0031, ¶ 0038, ¶ 0059-0060). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the determination of an updated delivery time according to a subsequent user request to modify the order of Mehta in the UAV delivery system of Mulhall/Chambers/Zhang with a reasonable expectation of success of arriving at the claimed invention, with the motivation to solve the problems that “In some systems, UAVs are provided with a flight plan based on products being delivered to a particular customer, where the products cannot be updated after the products have been loaded onto the UAV and/or after the UAV has begun delivery. Accordingly, consumers may find it difficult to modify, cancel, or reschedule orders, leading to additional trips by UAVs for returns or multiple orders” (Mehta: ¶ 0003).
Claim 2: Mulhall/Chambers/Zhang/Mehta teach claim 1. Mulhall, as modified above, further teaches:
wherein: in a state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is configures to further determine, on a basis of at least one of a traveling state of the vehicle and a traveling environment of the vehicle, whether or not it is possible to receive the product from the drone (Mulhall: ¶ 0088-0093 showing determining method of delivery/transfer protocol for delivering the order from the UAV to the receiving vehicle, based on environmental conditions in the rendezvous area (i.e. traveling environment of the vehicle), and the operational state of the vehicle (e.g. velocity, whether the vehicle is under autopilot, etc.))
Claim 5: See the rejection of claim 1 teaching analogous limitations. Mulhall further teaches:
A control method for use in a control device that includes a controller (Mulhall: ¶ 0032-0033, ¶ 0098-0099 showing computer implementing the en route delivery flight planner system; Fig. 6, ¶ 0075 showing “a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations”).
Claim 6: See the rejection of claim 1 teaching analogous limitations. Mulhall further teaches: A computer-readable storage medium having a control program stored therein, the control program causing a computer to execute a process (Mulhall: ¶ 0098-0102 showing memory/storage device storing program executed by CPU, with ¶ 0102 specifying the memory/storage device as a “computer-readable storage medium”; and ¶ 0075 showing “a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Zimmerman can be reached on (571)272-4602. 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.
/HUNTER MOLNAR/Examiner, Art Unit 3628
Prosecution Insights