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 .
This is a final office action on the merits. Claims 1-15 are currently pending and are addressed below.
The examiner notes that the fundamentals of the rejection are based on the broadest reasonable interpretation of the claim language. Applicant is kindly invited to consider the reference as a whole. References are to be interpreted as by one of ordinary skill in the art rather
than as by a novice. See MPEP 2141. Therefore, the relevant inquiry when interpreting a reference is not what the reference expressly discloses on its face but what the reference would teach or suggest to one of ordinary skill in the art.
Response to Arguments
Applicant's arguments, filed 09/18/2025, have been fully considered but they are not persuasive and have been addressed by the examiner below.
Claim 1 (amended limitations)
Regarding the limitation of claim 1 that recites, “from an operator management database, a pre-defined monitoring schedule of an operator who performs a monitoring task,” and “at least one time zone in which the operator cannot perform the monitoring task,” it is challenged that the disclosed reference of Sebastian merely describes identifying "coincident time periods between first and second execution windows" and evaluating "workload levels" to find "blank spaces." These blank spaces are computational results derived from analyzing mission sequences, not pre-defined monitoring schedules acquired from an operator management database. Sebastian's system starts with mission data and computes operator availability, whereas the claimed invention acquires pre-existing operator schedules that already define when operators can and cannot perform monitoring tasks.
While the argument has been carefully considered, the examiner respectfully disagrees. Upon further inspection, Sebastian explicitly discloses providing an operator with a “modified sequence in advance,” to allow them to plan and customize their workload. The sequence provided is considered “pre-defined,” under broadest reasonable interpretation as it is defined in advance of execution (¶¶ [0009], [0079]-[0081]). Further, Sebastian discloses time-based sequences for UAV missions that outline windows and include, “blank spaces,” representing a time where the operator is free from control of the associated UAV, therefore, defining an operator availability within the time-based sequence (¶¶ [0084]-[0086], [0088]-[0091], [0093]-[0095], ). Additionally, Sebastian teaches that the “mission database,” (Fig.1, Item 131) functions as a operator management database because it stores and provides pre-defined schedules dictating when an operator performs monitoring tasks (¶¶ [0059]-[0062]). Further, execution windows and overlapping operations corresponding to time periods in which the operator can and cannot perform monitoring is disclosed. For example, at least one time zone in which the operator cannot perform the monitoring task is provided in the form of overlapping segments, or fixed execution windows (¶¶ [0085]-[0086], Fig.3). These stored time constraints define when an operator is able to perform monitoring and when the operator is not required to do so, or unable.
Applicant’s assertion that the monitoring schedule is independent of mission data, or manually defined is not supported by the claim language. The claim does not exclude schedules derived from mission information, or require that the operator schedules be manually entered by the operator (though, this is also disclosed by the reference ¶¶ [0093] allowing the operators to input their tasks and time-based information) and under broadest reasonable interpretation, a schedule stored in a database that defines operator availability and is retrieved for monitoring purposes is satisfied by the reference. As such, the rejection concerning this particular limitations is maintained.
Relative to applicant’s remark where amended claim recites, “wherein the monitoring task includes monitoring tasks of different task types…allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task,” and Sebastian is challenged, the examiner has carefully considered the argument and respectfully disagrees. The examiner would like to note that the claim language does not require the operator specialization, or exclusive assignment of task types as argued by applicant (see Remarks, “task-type specialization,” pg.7). Sebastian discloses that mission operation assignments vary by “task carried out, complexity, distance…” (¶¶ [0079]) which suggests that missions include operations having different task types. It is further specified that operations are classified by complexity values (¶¶ [0077]) and time components updated based on task characteristics, which suggests that different task types are treated differently and that operations are prioritized based on priority differences of operation tied to task types. The disclosure then provides that these operations are allocated when the operation server reschedules operations by setting preferred start time and moving operations within execution windows to eliminate overlap in the operator work queue (¶¶ [0086]-[0089], [0100]-[0101]). As such, the examiner respectfully disagrees and the rejection is maintained.
Claim 5
Applicant claims that Sebastian fails to disclose the specific task type specialization required by Claim 5 where operators develop expertise in specific monitoring tasks and handle those tasks across all UAVs, rather than Sebastian’s general mission management approach. Additionally, there is a technical advantage from the specific allocation pattern claimed where the expertise of the monitoring task for each task type can be enhanced, making it possible to allow the operator to more appropriately perform the monitoring task.
While this is noted in applicant’s specification, it is not required by the recitation of the claim language. Under broadest reasonable interpretation, the claim language required by “a first task type” and a “second task type,” only requires differentiation of the type of task. With regards to the cited reference, the context of a first operator is interpreted as the operator initially assigned to a UAV that creates work overlap and/or overload, and a second operator being the newly assigned operator of the first operator’s task. Based on their workload and schedule, a UAV with a second monitoring required timing is reassigned to the second operator. However, it is disclosed in the reference that task allocation goes beyond evaluation of general assignments, where updated time components and complexity values associated with the operation (type of complexity associated with a task/operation) are taken into consideration. Metric data is utilized to evaluate an operator based on factors such as skill level, completion time, and but not limited to, condition in order to assign UAV operations to an operator (see at least ¶¶ [0077]-[0080], [0100]).
Claim 7
Furthermore, it is argued that Sebastian fails to disclose the cross-base monitoring capability required by claim 7. However, the examiner would like to note that the disclosure of Sebastian teaches an operation server that provides time-based sequences of operation for each of a plurality of UAVs, allowing them to form monitoring schedules corresponding to individual UAVs. The mission information includes origination location, ground operations, taxi-in and taxi-out phases, and parking positions, which the examiner can reasonably correspond to a deployment base for a UAV. Since the monitoring schedules are provided for multiple UAVs having distinct missions and associated origination locations, the schedule is configured to monitor another unmanned aerial vehicle deployed from a base different from the base of the unmanned vehicle (see at least ¶¶ [0049], [0075]).
In light of the amendment and applicant’s arguments with respect to the rejection of claims 1-11 under 35 U.S.C 101 have been fully considered and are persuasive. The rejection has been withdrawn.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sprengart Sebastian et al. (US20220172629A1), hereinafter referred to as Sebastian, in view of Spjuth Par et al. (US20210304343A1), hereinafter referred to as Par.
Regarding claim 1, Sebastian discloses: a monitoring plan generation device (see at least Sebastian, ¶¶ [0043] which discloses a monitoring plan device (device, system, and method of facilitating simultaneous mission management) for unmanned moving vehicle tasks) comprising: at least one memory configured to store program code and at least one processor configured to access the program code and operate as instructed by the program code (see at least Sebastian, ¶¶ [0007]-[0008] discloses a memory, processor configured to store program code), the program code including:
first acquisition code configured to cause the at least one processor to acquire from an operator management database, a pre-defined monitoring schedule of an operator who performs a monitoring task for monitoring an unmanned aerial vehicle used for delivering an article (see at least Sebastian, ¶¶ [0009], [0025] discloses the system acquiring the monitoring schedule of an operator (coincident time periods between first and second execution windows of monitoring a first and second UAV) who performs an operating task for monitoring a plurality of UAVs; ¶¶ [0003], [0015] time sequences being generated from mission plan (delivery, surveillance, etc.) of UAV used for performing a task; [0078]-[0080] discloses an example of acquiring a monitoring schedule of an operator to evaluate workload levels and mitigate assignments depending on the operator’s observed scheduling and when an operator is free to perform a monitoring task, known as blank spaces; ¶¶ [0009], [0079]-[0081], [0084]-[0086], [0088]-[0091], [0093]-[0095] providing an operator with a “modified sequence in advance,” to allow them to plan and customize their workload)
the monitoring schedule including a at least one time zone in which the operator can perform the monitoring task (see at lest Sebastian, ¶¶ [0005] discloses operator intervention which is the time that the operator can perform the monitoring task as they are awaiting a subsequent operation of a UAV; ¶¶ [0014]-[0019] which discloses a time zone (time-based sequence) corresponding to when an operator can perform (operator intervention, or “downtime”) the monitoring task (mission) of the UAV; [0084]-[0086], [0088]-[0091], [0093]-[0095] discloses time-based sequences for UAV missions that outline windows and include, “blank spaces,” representing a time where the operator is free from control of the associated UAV, therefore, defining an operator availability within the time-based sequence)
and at least one time zone in which the operator cannot perform the monitoring task (see at least Sebastian, ¶¶ [0085]-[0086] which discloses at least one time zone in which the operator cannot perform the monitoring task is provided in the form of overlapping segments, or fixed execution windows, this means at least one time zone in which the operator cannot perform the monitoring task)
second acquisition code configured to cause the at least one processor to acquire a monitoring required timing at which the unmanned aerial vehicle needs to be monitored (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle needs to be monitored for a respective operation (cargo delivery, surveillance, etc) including an earliest start and latest end time)
generation code configured to cause the at least one processor to generate a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule and the monitoring required timing (see at least Sebastian, ¶¶ [0008]-[0009], [0011], [0025]-[0028] which discloses the generation (providing the operator) a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule (a modified sequence based on coincident time periods between a first execution window within a first time-based sequence) and the monitor required timing of the UAV; )
wherein the monitoring task includes monitoring tasks of different task types, and the generation code is further configured to cause the at least one processor to generate the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task (see at least Sebastian, (¶¶ [0077]-[0079], [0086]-[0089], [0100]-[0101] which discloses operations are classified by complexity values and time components updated based on task characteristics, which suggests that different task types are treated differently and that operations are prioritized based on priority differences of operation tied to task types; operations are allocated when the operation server reschedules operations by setting preferred start time and moving operations within execution windows to eliminate overlap in the operator work queue, this means that monitoring task includes monitoring tasks of different task types, and the generation code is further configured to cause the at least one processor to generate the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task)
Sebastian is silent on, however, in the same field of endeavor Par teaches:
flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle (see at least Par, ¶¶ [0060]-[0061], [0065]-[0067] which discloses software that controls movement of a UAV such as altitude stabilization, position/altitude feedback, etc., this means that flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle as taught by Par. The examiner would like to note that Sebastian discloses generating adaptive monitoring plans for UAV operations and assumes control exists at a surface level (operators accessing and controlling UAVs for missions), but does not explicitly disclose the inherent flight mechanisms associated with direct control. Incorporating this teaching enables control of the scheduled UAV operations through known flight mechanisms and allows for improvement by providing the flight control functionality necessary to carry out the UAV operations.
Regarding claim 2, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the generation code is further configured to cause the at least one processor to:
generate the monitoring plan by allocating the monitoring task to be performed at the monitoring required timing to the time zone in which the operator can perform the monitoring task in the monitoring schedule of the operator (see at least Sebastian, ¶¶ [0037]-[0038], Fig. 3-4 which discloses an example of a monitoring plan of a single UAV (Fig.3) and a modified work queue including modified time-based sequences for an operator; [0078]-[0080] discloses an example of acquiring a monitoring schedule of an operator to evaluate workload levels and allocating the monitoring tasks to be performed depending on the operator’s observed scheduling and when an operator is free to perform a monitoring task, known as blank spaces)
Regarding claim 3, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the first acquisition code is further configured to cause the at least one processor to:
acquire the monitoring schedule of each of a plurality of the operators (see at least Sebastian, ¶¶ [0077] which discloses acquiring the monitoring schedule of a plurality of operators (subjective workload to update time components) to aid in modification of time elements),
the second acquisition code is further configured to cause the at least one processor to:
acquire a plurality of the monitoring required timings (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060], [0100] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle, or vehicles needs to be monitored for a respective operation including an earliest start and latest end time)
the generation code is further configured to cause the at least one processor to:
generate, on the basis of a plurality of the monitoring schedules and the plurality of monitoring required timings, the monitoring plan by allocating the monitoring task to be performed at each of the plurality of monitoring required timings to the time zone in which any one of the plurality of operators can perform the monitoring task in any one of the plurality of monitoring schedules (see at least Sebastian, ¶¶ [0008]-[0009], [0011], [0025]-[0028]; [0100] discloses generating on a basis of a plurality of monitoring schedules and monitoring required timings (workloads with timing elements for multiple operators) to other operators (using similar overlap and determination techniques) based on the best schedule)
Regarding claim 4, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the operator includes a first operator and a second operator, the first acquisition code is further configured to cause the at least one processor to:
acquire the monitoring schedule of the first operator and the monitoring schedule of the second operator, the monitoring required timing includes a first monitoring required timing and a second monitoring required timing (see at least Sebastian, ¶¶ [0099]-[0100] discloses generating on a basis of a plurality of monitoring schedules and monitoring required timings (workloads with timing elements for multiple operators) to other operators (using similar overlap and determination techniques) based on the best schedule; acquiring a first operator monitoring schedule including a first and second monitoring required timing, mission plans for a plurality of UAVS.)
the generation code is further configured to cause the at least one processor to generate the monitoring plan by:
(i) allocating the monitoring task to be performed at the first monitoring required timing to the time zone in which the first operator can perform the monitoring task in the monitoring schedule of the first operator (see at least Sebastian, ¶¶ [0095]-[0097] discloses allocating the monitoring task (modification plan) to be performed at the first monitoring required timing (first execution window) to the time zone in which the first operator can perform the monitoring task based on modified time-based sequences)
(ii) allocating the monitoring task to be performed at the second monitoring required timing to the time zone in which the second operator can perform the monitoring task in the monitoring schedule of the second operator (see at least Sebastian, ¶¶ [0099]-[0101] discloses an instance of allocating the monitoring task to be performed at the second monitoring required timing to a second operator (handoff by operation server) that fits the monitoring schedule of the second operator)
Note: With regards to the reference, the context of a first operator is interpreted as the operator initially assigned to a UAV that creates work overlap and/or overload, and a second operator being the newly assigned operator of the first operator’s task. Based on their workload and schedule, a UAV with a second monitoring required timing is reassigned to the second operator.
Regarding claim 5, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the operator includes a first operator and a second operator, the first acquisition code is further configured to cause the at least one processor to:
acquire the monitoring schedule of the first operator and the monitoring schedule of the second operator (see at least Sebastian, ¶¶ [0099]-[0100] discloses generating on a basis of a plurality of monitoring schedules and monitoring required timings (workloads with timing elements for multiple operators) to other operators (using similar overlap and determination techniques) based on the best schedule; acquiring a first operator monitoring schedule including a first and second monitoring required timing, mission plans for a plurality of UAVS.)
the unmanned aerial vehicle includes a first unmanned aerial vehicle and a second unmanned aerial vehicle, the second acquisition code is further configured to cause the at least one processor to:
acquire the monitoring required timing of the first unmanned aerial vehicle and the monitoring required timing of the second unmanned aerial vehicle (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060], [0100] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle, or vehicles needs to be monitored for a respective operation including an earliest start and latest end time)
the monitoring task includes:
a monitoring task of a first task type and a monitoring task of a second task type (see at least Sebastian, ¶¶ [0099]-[0100] discloses generating on a basis of a plurality of monitoring schedules and monitoring required timings (workloads with timing elements for multiple operators) to other operators (using similar overlap and determination techniques) based on the best schedule; acquiring a first operator monitoring schedule including a first and second monitoring required timing, mission plans for a plurality of UAVS.); [00100] discloses obtaining a plurality of monitoring task types (various factors such as task carried out, disclosed in ¶¶ [0079]) and generating a monitoring task assigned to an operator on the basis on )
the generation code is further configured to cause the at least one processor to generate the monitoring plan by:
(i) allocating, to the time zone in which the first operator can perform the monitoring task in the monitoring schedule of the first operator, the monitoring task of the first task type to be performed at the monitoring required timing of the first unmanned aerial vehicle and the monitoring task of the first task type to be performed at the monitoring required timing of the second unmanned aerial vehicle (see at least Sebastian, ¶¶ [0095]-[0097] discloses allocating the monitoring task (modification plan) to be performed at the first monitoring required timing (first execution window) to the time zone in which the first operator can perform the monitoring task based on modified time-based sequences)
(ii) allocating, to the time zone in which the second operator can perform the monitoring task in the monitoring schedule of the second operator, the monitoring task of the second task type to be performed at the monitoring required timing of the first unmanned aerial vehicle and the monitoring task of the second task type to be performed at the monitoring required timing of the second unmanned aerial vehicle (see at least Sebastian, ¶¶ [0099]-[0101] discloses an instance of allocating the monitoring task to be performed at the second monitoring required timing to a second operator (handoff by operation server) that fits the monitoring schedule of the second operator)
Regarding claim 6, Sebastian discloses: the monitoring plan generation device according to claim 1,
wherein the unmanned aerial vehicle includes a first unmanned aerial vehicle and a second unmanned aerial vehicle (see at least Sebastian, ¶¶ [0108] discloses a first and second unmanned aerial vehicle)
the monitoring schedule of a first operator among a plurality of the operators has a monitoring task allocated thereto and configured to:
monitor the first unmanned aerial vehicle and a monitoring task allocated thereto and configured to monitor the second unmanned aerial vehicle (see at least Sebastian, ¶¶ [0106], [0108] which discloses a first operator’s monitoring schedule to monitor a first and second unmanned aerial vehicle) the program code further including delay control code configured to cause the at least one processor to:
delay, when a delay occurs in a delivery schedule of the first unmanned aerial vehicle, the monitoring required timing of the first unmanned aerial vehicle, and the generation code is further configured to cause the at least one processor to change, in a case where at least a part of the monitoring required timing after the delay of the first unmanned aerial vehicle and at least a part of the monitoring required timing of the second unmanned aerial vehicle overlap with each other (see at least Sebastian, ¶¶ [0083] which discloses examples where an operation server creates real-time updates to UAVs monitoring timing including take-off delays from a plurality of aerial vehicles; [0106]-[0110] which discloses the system identifying an overlap in time periods between time-based sequences of a first and second unmanned aerial vehicle performing a mission (cargo delivery, surveillance) and the operation server undertaking a measure to delay, or hold a second unmanned aerial vehicle from operating when it is detected that the execution window of a first unmanned aerial vehicle requires)
the monitoring plan by allocating the monitoring task to be performed at the monitoring required timing of the second unmanned aerial vehicle to the time zone in which the monitoring task can be performed in the monitoring schedule of a second operator other than the first operator (see at least Sebastian, ¶¶ [0099]-[0101] discloses an instance of allocating the monitoring task to be performed at the second monitoring required timing to a second operator (handoff by operation server) that fits the monitoring schedule of the second operator in the event that operations associated with a first unmanned aerial vehicle of a first operator are difficult/or require)
Regarding claim 7, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the monitoring schedule has a monitoring task already allocated thereto and configured to monitor another unmanned aerial vehicle deployed in a base different from a base of the unmanned aerial vehicle (see at least Sebastian, ¶¶ [0075] discloses an instance of a monitoring schedule with a plurality of UAVs consisting of multiple types of different information such as current base (operation) location, trajectory, etc.)
Regarding claim 8, Sebastian discloses: the monitoring plan generation device according to claim 1, the program code further including transmission code configured to cause the at least one processor to transmit, to a terminal used by the operator, information for causing the operator to perform the monitoring task to be performed at the monitoring required timing in response to arrival of the monitoring required timing (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060], [0100] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle, or vehicles needs to be monitored for a respective operation including an earliest arrival)
Regarding claim 9, Sebastian is silent on, however, in the same field of endeavor, Par teaches: the monitoring plan generation device according to claim 1, wherein the monitoring required timing is at least one of a plurality of timings separated by time in a delivery schedule related to one delivery by the unmanned aerial vehicle (see at least Par, ¶¶ [0082]-[0083], [0133]-[0134] which discloses the monitor required timings being at least one of a plurality of timings in a delivery schedule related to the delivery by the unmanned aerial vehicle)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include the monitoring plan generation device according to claim 1, wherein the monitoring required timing is at least one of a plurality of timings separated by time in a delivery schedule related to one delivery by the unmanned aerial vehicle as taught by Par. The examiner would like to note that the reference of Sebastian is applicable to unmanned UAV scheduling for various mission tasks including delivery, however, for the sake of the disclosure, a delivery schedule is not explicitly disclosed. A mission schedule with time-based sequences of the required timing of the mission are disclosed. Additionally, the background of Sebastian suggests that delivery tasks as implied to be applied. The secondary reference Par is directly related to managing and utilizing a fleet of UAVs specifically for the delivery of goods. Incorporating the teachings of Par into Sebastian would create an improvement for the base device that makes the missions more versatile and adaptive toward the specific task type.
Regarding claim 10, Sebastian discloses: an unmanned aerial vehicle monitoring system (see at least Sebastian, ¶¶ [0043] which discloses a monitoring plan device (device, system, and method of facilitating simultaneous mission management) for unmanned moving vehicle tasks) comprising: at least one memory configured to store program code and at least one processor configured to access the program code and operate as instructed by the program code (see at least Sebastian, ¶¶ [0007]-[0008] discloses a memory, processor configured to store program code), the program code including:
first acquisition code configured to cause the at least one processor to acquire, from an operator management database, a pre-defined monitoring schedule of an operator who performs a monitoring task for monitoring an unmanned aerial vehicle used for delivering an article (see at least Sebastian, ¶¶ [0009], [0025] discloses the system acquiring the monitoring schedule of an operator (coincident time periods between first and second execution windows of monitoring a first and second UAV) who performs an operating task for monitoring a plurality of UAVs; ¶¶ [0003], [0015] time sequences being generated from mission plan (delivery, surveillance, etc.) of UAV used for performing a task; [0078]-[0080] discloses an example of acquiring a monitoring schedule of an operator to evaluate workload levels and mitigate assignments depending on the operator’s observed scheduling and when an operator is free to perform a monitoring task, known as blank spaces; ¶¶ [0009], [0079]-[0081], [0084]-[0086], [0088]-[0091], [0093]-[0095] providing an operator with a “modified sequence in advance,” to allow them to plan and customize their workload)
the monitoring schedule including at least one time zone in which the operator can perform the monitoring task (see at least Sebastian, ¶¶ [0005] discloses operator intervention which is the time that the operator can perform the monitoring task as they are awaiting a subsequent operation of a UAV; ¶¶ [0014]-[0019] which discloses a time zone (time-based sequence) corresponding to when an operator can perform (operator intervention, or “downtime”) the monitoring task (mission) of the UAV; [0084]-[0086], [0088]-[0091], [0093]-[0095] discloses time-based sequences for UAV missions that outline windows and include, “blank spaces,” representing a time where the operator is free from control of the associated UAV, therefore, defining an operator availability within the time-based sequence)
and at least one time zone in which the operator cannot perform the monitoring task (see at least Sebastian, ¶¶ [0085]-[0086] which discloses at least one time zone in which the operator cannot perform the monitoring task is provided in the form of overlapping segments, or fixed execution windows, this means at least one time zone in which the operator cannot perform the monitoring task)
second acquisition code configured to cause the at least one processor to acquire a monitoring required timing at which the unmanned aerial vehicle needs to be monitored (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle needs to be monitored for a respective operation (cargo delivery, surveillance, etc) including an earliest start and latest end time)
generation code configured to cause the at least one processor to generate a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule and the monitoring required timing (see at least Sebastian, ¶¶ [0008]-[0009], [0011], [0025]-[0028] which discloses the generation (providing the operator) a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule (a modified sequence based on coincident time periods between a first execution window within a first time-based sequence) and the monitor required timing of the UAV; )
wherein the monitoring task includes monitoring tasks of different task types, and the generation code is further configured to cause the at least one processor to generate the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task (see at least Sebastian, (¶¶ [0077]-[0079], [0086]-[0089], [0100]-[0101] which discloses operations are classified by complexity values and time components updated based on task characteristics, which suggests that different task types are treated differently and that operations are prioritized based on priority differences of operation tied to task types; operations are allocated when the operation server reschedules operations by setting preferred start time and moving operations within execution windows to eliminate overlap in the operator work queue, this means that monitoring task includes monitoring tasks of different task types, and the generation code is further configured to cause the at least one processor to generate the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task)
Sebastian is silent on, however, in the same field of endeavor Par teaches: flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle (see at least Par, ¶¶ [0060]-[0061], [0065]-[0067] which discloses software that controls movement of a UAV such as altitude stabilization, position/altitude feedback, etc., this means that flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle as taught by Par. The examiner would like to note that Sebastian discloses generating adaptive monitoring plans for UAV operations and assumes control exists at a surface level (operators accessing and controlling UAVs for missions), but does not explicitly disclose the inherent flight mechanisms associated with direct control. Incorporating this teaching enables control of the scheduled UAV operations through known flight mechanisms and allows for improvement by providing the flight control functionality necessary to carry out the UAV operations.
Regarding claim 11, Sebastian discloses: a monitoring plan generation method executed by a computer comprising:
acquiring, from an operator management database, a pre-defined monitoring schedule of an operator who performs a monitoring task for monitoring an unmanned aerial vehicle used for delivering an article (see at least Sebastian, ¶¶ [0009], [0025] discloses the system acquiring the monitoring schedule of an operator (coincident time periods between first and second execution windows of monitoring a first and second UAV) who performs an operating task for monitoring a plurality of UAVs; ¶¶ [0003], [0015] time sequences being generated from mission plan (delivery, surveillance, etc.) of UAV used for performing a task; [0078]-[0080] discloses an example of acquiring a monitoring schedule of an operator to evaluate workload levels and mitigate assignments depending on the operator’s observed scheduling and when an operator is free to perform a monitoring task, known as blank spaces; ¶¶ [0009], [0079]-[0081], [0084]-[0086], [0088]-[0091], [0093]-[0095] providing an operator with a “modified sequence in advance,” to allow them to plan and customize their workload)
the monitoring schedule including at least one time zone in which the operator can perform the monitoring task (see at lest Sebastian, ¶¶ [0005] discloses operator intervention which is the time that the operator can perform the monitoring task as they are awaiting a subsequent operation of a UAV; ¶¶ [0014]-[0019] which discloses a time zone (time-based sequence) corresponding to when an operator can perform (operator intervention, or “downtime”) the monitoring task (mission) of the UAV; [0084]-[0086], [0088]-[0091], [0093]-[0095] discloses time-based sequences for UAV missions that outline windows and include, “blank spaces,” representing a time where the operator is free from control of the associated UAV, therefore, defining an operator availability within the time-based sequence)
and at least one time zone in which the operator cannot perform the monitoring task (see at least Sebastian, ¶¶ [0085]-[0086] which discloses at least one time zone in which the operator cannot perform the monitoring task is provided in the form of overlapping segments, or fixed execution windows, this means at least one time zone in which the operator cannot perform the monitoring task)
acquiring a monitoring required timing at which the unmanned aerial vehicle needs to be monitored (see at least Sebastian, Fig.2 which discloses the monitor required timing (time based sequence for one mission corresponding to a single UAV); ¶¶ [0025]-[0028], [0060] discloses the system acquiring a monitor required timing (execution window) at which the unmanned vehicle needs to be monitored for a respective operation (cargo delivery, surveillance, etc) including an earliest start and latest end time)
generating a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule and the monitoring required timing (see at least Sebastian, ¶¶ [0008]-[0009], [0011], [0025]-[0028] which discloses the generation (providing the operator) a monitoring plan of the unmanned aerial vehicle on the basis of the monitoring schedule (a modified sequence based on coincident time periods between a first execution window within a first time-based sequence) and the monitor required timing of the UAV; )
wherein the monitoring task includes monitoring tasks of different task types, generating the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task (see at least Sebastian, (¶¶ [0077]-[0079], [0086]-[0089], [0100]-[0101] which discloses operations are classified by complexity values and time components updated based on task characteristics, which suggests that different task types are treated differently and that operations are prioritized based on priority differences of operation tied to task types; operations are allocated when the operation server reschedules operations by setting preferred start time and moving operations within execution windows to eliminate overlap in the operator work queue, this means that monitoring task includes monitoring tasks of different task types, and the generation code is further configured to cause the at least one processor to generate the monitoring plan by allocating monitoring tasks of a same task type to a time zone in which a same operator can perform the monitoring task)
Sebastian is silent on, however, in the same field of endeavor Par teaches: providing at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle (see at least Par, ¶¶ [0060]-[0061], [0065]-[0067] which discloses software that controls movement of a UAV such as altitude stabilization, position/altitude feedback, etc., this means that flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle as taught by Par. The examiner would like to note that Sebastian discloses generating adaptive monitoring plans for UAV operations and assumes control exists at a surface level (operators accessing and controlling UAVs for missions), but does not explicitly disclose the inherent flight mechanisms associated with direct control. Incorporating this teaching enables control of the scheduled UAV operations through known flight mechanisms and allows for improvement by providing the flight control functionality necessary to carry out the UAV operations.
Regarding claim 12, Sebastian is silent on, however, in the same field of endeavor, Par teaches: the monitoring plan generation device according to claim 1, wherein the program code further includes: presentation control code configured to cause the at least one processor to control presentation of deliverable times to an orderer by preventing selection of delivery times when operators cannot perform monitoring tasks and controlling physical delivery scheduling (see at least Par, ¶¶ [0133], [0144]-[0146], [0160]-[0162] which discloses the system allowing for user selection of time points based on a utilization schedule that accounts for availability, displaying only relevant ones, this means presentation control code configured to cause the at least one processor to control presentation of deliverable times to an orderer by preventing selection of delivery times when operators cannot perform monitoring tasks)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include the monitoring plan generation device according to claim 1, wherein the program code further includes: presentation control code configured to cause the at least one processor to control presentation of deliverable times to an orderer by preventing selection of delivery times when operators cannot perform monitoring tasks and controlling physical delivery scheduling as taught by Par. Incorporating the teaching would allow for an improvement to the base invention of Sebastian, that further allows the system to utilize the adaptive scheduling and incorporate it into user selections, to make the assignment and execution of tasks smoother.
Regarding claim 13, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the program code further includes:
communication code configured to cause the at least one processor to control communication performed via a communication network to receive UAV information (see at least Sebastian, ¶¶ [0049]-[0051], discloses receiving UAV information via a communications server)
Sebastian is silent on, however, in the same field of endeavor Par teaches: control transmission of flight commands to the unmanned aerial vehicle (see at least Par, ¶¶ [0060]-[0061], [0065]-[0067] which discloses software that controls movement of a UAV such as altitude stabilization, position/altitude feedback, etc., this means that flight control code configured to cause the at least one processor to provide at least one terminal operation for performing flight control including controlling movement and hovering of the unmanned aerial vehicle)
It would have been obvious to a person of ordinary skill in the art to modify Sebastian to include control transmission of flight commands to the unmanned aerial vehicle as taught by Par. The examiner would like to note that Sebastian discloses generating adaptive monitoring plans for UAV operations and assumes control exists at a surface level (operators accessing and controlling UAVs for missions), but does not explicitly disclose the inherent flight mechanisms associated with direct control. Incorporating this teaching enables control of the scheduled UAV operations through known flight mechanisms and allows for improvement by providing the flight control functionality necessary to carry out the UAV operations.
Regarding claim 15, Sebastian discloses: the monitoring plan generation device according to claim 1, wherein the monitoring tasks of different task types include a monitoring task of:
a flight determination time (see at least Sebastian, ¶¶ [0008], [0043], [0058], which discloses a first start time and end time for a mission which is a flight determination time)
a monitoring task of a base take-off time, a monitoring task of a store landing time (see at least Sebastian, ¶¶ [0043] which discloses a takeoff from base, monitoring its departure until it arrives at the destination)
a monitoring task of a store take-off time, a monitoring task of a delivery destination flight time and a monitoring task of a delivery destination landing time (see at least Sebastian, ¶¶ [0043] which landing time at destination and postflight phases which may include additional operations)
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over modified Sebastian, in view of Bornski Timothy et al. (US2021019699A1), hereinafter referred to as Timothy.
Regarding claim 14, Sebastian is silent on, however, in the same field of endeavor Timothy teaches: the monitoring plan generation device according to claim 6, wherein the delay control code is further configured to cause the at least one processor to notify an orderer of delivery cancellation when no operator can perform monitoring tasks (see at least Timothy, ¶¶ [0145]-[0146] which discloses the monitoring plan generation device according to claim 6, wherein the delay control code is further configured to cause the at least one processor to notify an orderer of delivery cancellation when no operator can perform monitoring tasks)
It would have been obvious to a person of ordinary skill in the art to further change modified Sebastian to the monitoring plan generation device according to claim 6, wherein the delay control code is further configured to cause the at least one processor to notify an orderer of delivery cancellation when no operator can perform monitoring tasks as taught by Timothy. Incorporating the teaching would allow for an improvement to the base invention of Sebastian, that further allows the system to utilize the adaptive scheduling and incorporate it into user selections, to make the assignment and execution of tasks smoother.
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 KIRSTEN JADE M SANTOS whose telephone number is (571)272-7442. The examiner can normally be reached Monday: 8:00 am - 4:00 pm, 6:00-8:00 pm (+ with flex).
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, Rachid Bendidi can be reached at (571) 272-4896. 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.
/KIRSTEN JADE M SANTOS/Examiner, Art Unit 3664
/RACHID BENDIDI/Supervisory Patent Examiner, Art Unit 3664