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 .
DETAILED ACTION
1. This Final Office action is in reply to the Applicant amendment filed on 01 December 2025.
2. Claims 1, 2, 6, 7, 10 11, 15, 17 have been amended.
3. Claims 1-20are currently pending and have been examined. The Information Disclosure Statement filed 09 December 2025 has been considered by the Examiner. A signed copy is enclosed with this Office Action.
Response to Amendment
In the previous office action, Claims 1-20 were rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter (abstract idea). Applicants have not amended Claims 1-20 to provide statutory support and the rejection is maintained.
Response to Arguments
Applicant’s arguments filed 01 December 2025 have been fully considered but they are not persuasive. In the remarks regarding the 35 USC § 101 rejection for Claims 1-20, Applicant argues that: (1) the claims are not directed to an abstract idea, and even if they were, they would amount to significantly more than the abstract idea. Examiner respectfully disagrees. Still commensurate to the two-part subject matter eligibility framework decision in the Federal court decision in Alice Corp. Pty. Ltd. V. CLS Bank International et al., (Alice), 2019 revised patent subject matter eligibility guidance (2019 PEG) and the October 2019 Update: Subject Matter Eligibility (“October 2019 Update), and the new “July 2024 Guidance Update on Patent Subject Matter Eligibility Examples, including on Artificial Intelligence”, and the Examiner details the maintained rejection under 35 U.S.C. 101 in the below rejection with further explanation. Applicant argues that as amended, Applicant states basically: “The claims are patent eligible for at least the reasons that the claims are limited to a practical application…under Prong Two…” (see Remarks/Arguments pages 16-19). However the Examiner respectfully disagrees. Under Step 2A: Prong One, the claims still recite abstract idea limitations identified below in bolded under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as a series of steps for data collection, comparison against rules, and subsequent task assignment. It is a functional method of organizing human activity (fleet management) that does not inherently require a specific technological improvement to computer functionality itself as well as a mental process. The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter:
Certain methods of organizing human activity –managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). It manages the relationship between an operator, a site’s rules, and a fleet of vehicles. Defining operational permissions based on skill and experience is a "set of rules" or a "business method" for resource allocation. Similar to assigning tasks to workers in a warehouse based on seniority or skill, this is a fundamental organizational practice.
Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion). The steps of "receiving a request"; "defining a limit" based on criteria, and "assigning" vehicles based on rules are processes that can be (and historically have been) performed in the human mind or with the aid of pen and paper. Even though it involves "unmanned vehicles", the logic of checking a person's "skill indicator" against a "site rule" to decide how many tools they can handle is a mental evaluation of data
See MPEP § 2106.04(a) II C. Hence, the claims are ineligible under Step 2A Prong one. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components. Under Prong Two for Claims 1-20 for this step of the analysis (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. Independent Claims 1-20 recite additional elements directed to “processor; compute device; non-transitory processor-readable medium storing code” (e.g., see Applicants’ published Specification ¶’s 3-5, 17-25). Therefore, the claims contain computer components that are cited at a high level of generality and are merely invoked as a tool to perform the abstract idea. Simply implementing an abstract idea on a computer is not a practical application of the abstract idea. There are no specific recitations as to specifically how the “automatically…” steps are defined as “meaningful limitations that collectively represent an abundantly practical application” nor do the claims represent a technical improvement to technology. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible. See MPEP § 2106.05(f) (h). In summary as indicated below through Steps 1-2B, the recitation of a computer (processor) to perform the claim limitations amount to no more than mere instruction to apply the exception using generic computer components. Even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer and insignificant extra-solution activity, which do not provide an inventive concept. For at least these reasons, the rejection is maintained.
Applicant submits that: (2) Roper, JR. et al. (Roper) (US 2024/0078915) does not teach or suggest in amended and broadly recited Claim 1: “First….define, after the registration request of the operator is received, an upper limit of unmanned vehicles (unmanned aerial vehicle (UAV)) for the operator; automatically assign, after the receiving the plurality of mission requests, a plurality of unmanned vehicles to the operator; Second…receive a registration request… for a site having a set of site rules defining operational permissions for the site; define…an upper limit of unmanned vehicles for the operator based on the set of site rules; Third…define…an upper limit of unmanned vehicles for the operator based on the set of site rules and at least one of the skill indicator associated with the operator [see Remarks pages 13-16]. With regard to argument (2), the Examiner respectfully disagrees. First, the Examiner notes Applicants are arguing that “upper limit” is not taught by Roper. However the Examiner notes the broadly recited “upper limit” is not specifically defined in the claims, leaving the Examiner to interpret this phrase limitation as best broadly and reasonably interpreted for the limitations preceding and following this broad phrase limitation. The Examiner adds additional clarification to the argued claim limitations with the following citations of Roper as: define, after the registration request of the operator is received, an upper limit (The management system can validate the mission plan (e.g., a flight plan) as complying with any limitations of a UAV, such as flight time, altitude restrictions, payload restrictions; Each individual data point includes an associated security setting that limits which class of operator or application may access (e.g., view, change, etc.) the data point) of unmanned vehicles (unmanned aerial vehicle (UAV)) for the operator based on the set of site rules (parameters; rules of the external authority) and at least one of the skill indicator associated with the operator (Each of these operations interact to form a successful mission. The tasks included in the mission record can be implemented in the management system 304 or unmanned vehicle 100 controllers 130, or may require actions to be completed by an operator at the interface 308) for at least one unmanned vehicle (the simulation environment 306 can also be used for assessing the skillsets of pilots and operators to grant licenses and/or certifications (e.g., using a digital or virtual process). These licenses and/or certifications can authorize the pilots and operators to operate particular UAVs, access certain types of data, and/or execute missions having particular characteristics (e.g., weather conditions, geographic locations, time of day, number and type of UAVs involved, etc.)), the experience indicator for the site and associated with the operator, or the experience indicator for the at least one unmanned vehicle and associated with the operator (the operations can include configuring the flight plan into a format specified by an external authority for validation by the external authority; transmitting the flight plan in the format to the external authority; and receiving a validation of the flight plan from the external authority, the validation indicative of approval to execute the flight plan. In some implementations, the operations can include storing, at a data store, data representing equipment that can be added to the UAV for completing the at least one action, enabling selection of the equipment for including with the UAV via the computing interface, and updating, based on the selection of the equipment, mission parameters indicative of the one or more operational features. In some implementations, the operations can include receiving, at a simulation environment, the flight plan from the flight management system; simulating execution of the flight plan by the UAV based on the one or more operational features of the UAV; and verifying, based on the simulating, that the UAV is capable of completing the flight plan. In some implementations, the one or more operational features can include at least one of a payload size for transporting by the UAV, an altitude limitation of the UAV, a speed limitation of the UAV, and an operational distance of the UAV. In some implementations, the one or more operational features can represent a specification of hardware sensors supported by the UAV. In some implementations, the operations can include providing an operator of the UAV selective access to telemetry of the UAV, wherein the selective access is based on a security layer provided by the computing interface. In some implementations, the operations can include receiving, at the computing interface, telemetry from the UAV and sending the telemetry to the client device for presentation on a user interface. In some implementations, generating the flight plan for the UAV can include generating the flight plan to include a specification of at least one operator from an operator database for monitoring the UAV during the flight of the UAV. In some implementations, the operations can include granting permission, via the computing interface, to a device of the at least one operator to operate the UAV during the flight of the UAV. In some implementations, granting the permission to the device of the at least one operator can be based on a certification and/or license associated with the operator. In some implementations, the certification and/or license associated with the at least one operator can be obtained through an assessment of the at least one operator using a simulated environment. In some implementations, generating the flight plan for the UAV can include generating the flight plan based on a consideration of capabilities, characteristics, and/or locations of at least one other UAV configured to communicate with the computing interface) (Roper, see at least paragraphs 3-11, 23, 26, 62-70, 79-82, 97, 113). It is noted that any citations to specific, pages, columns, paragraphs, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123. The Examiner has a duty and responsibility to the public and to Applicant to interpret the claims as broadly as reasonably possible during prosecution. In re Prater, 415 F.2d 1 393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969). For at least these reasons, the rejection is maintained.
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 1-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, natural phenomenon, or an abstract idea) because the claimed invention is directed to a judicial exception (i.e., a law of nature, natural phenomenon, or an abstract idea) without significantly more. The claims as a whole recite certain grouping of an abstract idea and are analyzed in the following step process:
Step 1: Claims 1-20 are each focused to a statutory category of invention, namely “non-transitory processor-readable medium storing code; method” sets.
Step 2A: Prong One: Claims 1-20 recite limitations that set forth the abstract ideas, namely from representative independent Claim 1:
“receive a registration request for an operator from a plurality of operators and for a site having a set of site rules defining operational permissions for the site, the operator associated with a skill indicator, an experience indicator for the site, and an experience indicator for at least one unmanned vehicle;
define, after the registration request of the operator is received, an upper limit of unmanned vehicles for the operator based on the set of site rules and at least one of the skill indicator associated with the operator, the experience indicator for the site and associated with the operator, or the experience indicator for the at least one unmanned vehicle and associated with the operator;
receive a plurality of mission requests associated with the site;
automatically assign, after the receiving the plurality of mission requests, a plurality of unmanned vehicles to the operator based on the set of site rules, the experience indicator for the site and associated with the operator, and the experience indicator for the at least one unmanned vehicle and associated with the operator,
each unmanned vehicle from the plurality of unmanned vehicles being assigned in response to a mission request from the plurality of mission requests, a number of unmanned vehicles in the plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the operator, and
automatically authorize, after the automatically assigning, the operator to operate the plurality of unmanned vehicles that are operated by the operator in response to the authorizing”
These abstract idea limitations identified above in bolded under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as a series of steps for data collection, comparison against business rules, and subsequent task assignment. It is a functional method of organizing human activity (fleet management) that does not inherently require a specific technological improvement to computer functionality itself as well as a mental process. The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter:
Certain methods of organizing human activity –managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). It manages the relationship between an operator, a site’s rules, and a fleet of vehicles. Defining operational permissions based on skill and experience is a "set of rules" or a "business method" for resource allocation. Similar to assigning tasks to workers in a warehouse based on seniority or skill, this is a fundamental organizational practice.
Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion). The steps of "receiving a request"; "defining a limit" based on criteria, and "assigning" vehicles based on rules are processes that can be (and historically have been) performed in the human mind or with the aid of pen and paper. Even though it involves "unmanned vehicles", the logic of checking a person's "skill indicator" against a "site rule" to decide how many tools they can handle is a mental evaluation of data
See MPEP § 2106.04(a) II C. Hence, the claims are ineligible under Step 2A Prong one. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components.
Prong Two: Claims 1-20: With regard to this step of the analysis (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. Independent Claims 1-20 recite additional elements directed to “processor; compute device; non-transitory processor-readable medium storing code” (e.g., see Applicants’ published Specification ¶’s 3-5, 17-25). Therefore, the claims contain computer components that are cited at a high level of generality and are merely invoked as a tool to perform the abstract idea. Simply implementing an abstract idea on a computer is not a practical application of the abstract idea. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible. See MPEP § 2106.05(f) (h).
Step 2B: As explained in MPEP § 2106.05, Claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea nor recites additional elements that integrate the judicial exception into a practical application. The additional elements of “processor; compute device; non-transitory processor-readable medium storing code; assignor compute device 100, operator compute devices 120, sig compute devices 140, and UVs 160”, etc. are generically-recited computer-related elements that amount to a mere instruction to “apply it” (the abstract idea) on the computer-related elements (see MPEP § 2106.05 (f) – Mere Instructions to Apply an Exception). These additional elements in the claims are recited at a high level of generality and are merely limiting the field of use of the judicial exception (see MPEP §2106.05 (h) – Field of Use and Technological Environment). There is no indication that the combination of elements improves the function of a computer or improves any other technology.
Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible.
The Examiner interprets that the steps of the claimed invention both individually and as an ordered combination result in Mere Instructions to Apply a Judicial Exception (see MPEP §2106.05 (f)). These claims recite only the idea of a solution or outcome with no restriction on how the result is accomplished and no description of the mechanism used for accomplishing the result. Here, the claims utilize a computer or other machinery (e.g., see Applicants’ published Specification ¶’s 17-25) regarding using existing computer processors as well as program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored. “processor; compute device; non-transitory processor-readable medium storing code; assignor compute device 100, operator compute devices 120, sig compute devices 140, and UVs 160, etc.” in their ordinary capacity for performing tasks (e.g., to receive, analyze, transmit and display data) and/or use computer components after the fact to an abstract idea (e.g., a fundamental economic practice and certain methods of organization human activities) and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016)). Software implementations are accomplished with standard programming techniques with logic to perform connection steps, processing steps, comparison steps and decisions steps. These claims are directed to being a commonplace business method being applied on a general-purpose computer (see Alice Corp. Pty, Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 1357, 110 USPQ2d 1976, 1983 (2014)); Versata Dev. Group, Inc., v. SAP Am., Inc., 793 D.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)) and require the use of software such as via a server to tailor information and provide it to the user on a generic computer. Based on all these, Examiner finds that when viewed either individually or in combination, these additional claim element(s) do not provide meaningful limitation(s) that raise to the high standards of eligibility to transform the abstract idea(s) into a patent eligible application of the abstract idea(s) such that the claim(s) amounts to significantly more than the abstract idea(s) itself. Accordingly, Claims 1-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e. abstract idea exception) without significantly more.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Roper, JR. et al. (Roper) (US 2024/0078915).
With regard to Claims 1, 15, Roper teaches a non-transitory processor-readable medium/method storing code representing instructions to be executed by a processor, the instructions comprising code to cause the processor to (environment 50, management system 304) (see at least paragraphs 24-45):
receive a registration request (the mission request can be configured by an operator using drop-down menus, radio buttons, etc. If required data are not entered, the management system 304 can prevent the mission from being scheduled until the remaining data are received. The management system 304 can prompt the operator for missing mission request data) for an operator (operator) from a plurality of operators (The management system 304 includes a mission execution system 402 (MES). The mission execution system 402 is configured to maintain a comprehensive equipment database, and an operator database. The operator database stores a list of operators and operator actions for those operators. In some implementations, the operator database can also store one or more certifications and/or licenses held by each operator. The equipment database includes operations support equipment 428 status (e.g., equipment status) and a history of all operations performed on the equipment 428. The mission execution system 402 executes a mission record. The mission record includes a list of automatically generated tasks based on the mission request received from an operator. The mission record is generated by the mission execution system 402 to support preflight, flight, and post flight operations. Each of these operations interact to form a successful mission. The tasks included in the mission record can be implemented in the management system 304 or unmanned vehicle 100 controllers 130, or may require actions to be completed by an operator at the interface 308) and for a site (The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations) having a set of site rules (parameters; rules of the external authority) defining operational permissions for the site (the method can include receiving, at the computing interface, telemetry from the UAV and sending the telemetry to the client device for presentation on a user interface. In some implementations, generating the flight plan for the UAV can include generating the flight plan to include a specification of at least one operator from an operator database for monitoring the UAV during the flight of the UAV. In some implementations, the method can include granting permission, via the computing interface, to a device of the at least one operator to operate the UAV during the flight of the UAV; permission to the device of the at least one operator can be based on a certification), the operator associated with a skill indicator (the operator database can also store one or more certifications and/or licenses held by each operator), an experience indicator for the site, and an experience indicator (The operator database stores a list of operators and operator actions for those operators. In some implementations, the operator database can also store one or more certifications and/or licenses held by each operator. The equipment database includes operations support equipment 428 status (e.g., equipment status) and a history of all operations performed on the equipment 428. The mission execution system 402 executes a mission record. The mission record includes a list of automatically generated tasks based on the mission request received from an operator. The mission record is generated by the mission execution system 402 to support preflight, flight, and post flight operations. Each of these operations interact to form a successful mission. The tasks included in the mission record can be implemented in the management system 304 or unmanned vehicle 100 controllers 130, or may require actions to be completed by an operator at the interface 308) for at least one unmanned vehicle (the simulation environment 306 can also be used for assessing the skillsets of pilots and operators to grant licenses and/or certifications (e.g., using a digital or virtual process). These licenses and/or certifications can authorize the pilots and operators to operate particular UAVs, access certain types of data, and/or execute missions having particular characteristics (e.g., weather conditions, geographic locations, time of day, number and type of UAVs involved, etc.) (see at least paragraphs 3-11, 26, 65-70, 79, 97, 113);
define, after the registration request of the operator is received, an upper limit (The management system can validate the mission plan (e.g., a flight plan) as complying with any limitations of a UAV, such as flight time, altitude restrictions, payload restrictions; Each individual data point includes an associated security setting that limits which class of operator or application may access (e.g., view, change, etc.) the data point) of unmanned vehicles (unmanned aerial vehicle (UAV)) for the operator based on the set of site rules (parameters; rules of the external authority) and at least one of the skill indicator associated with the operator (Each of these operations interact to form a successful mission. The tasks included in the mission record can be implemented in the management system 304 or unmanned vehicle 100 controllers 130, or may require actions to be completed by an operator at the interface 308) for at least one unmanned vehicle (the simulation environment 306 can also be used for assessing the skillsets of pilots and operators to grant licenses and/or certifications (e.g., using a digital or virtual process). These licenses and/or certifications can authorize the pilots and operators to operate particular UAVs, access certain types of data, and/or execute missions having particular characteristics (e.g., weather conditions, geographic locations, time of day, number and type of UAVs involved, etc.)), the experience indicator for the site and associated with the operator, or the experience indicator for the at least one unmanned vehicle and associated with the operator (the operations can include configuring the flight plan into a format specified by an external authority for validation by the external authority; transmitting the flight plan in the format to the external authority; and receiving a validation of the flight plan from the external authority, the validation indicative of approval to execute the flight plan. In some implementations, the operations can include storing, at a data store, data representing equipment that can be added to the UAV for completing the at least one action, enabling selection of the equipment for including with the UAV via the computing interface, and updating, based on the selection of the equipment, mission parameters indicative of the one or more operational features. In some implementations, the operations can include receiving, at a simulation environment, the flight plan from the flight management system; simulating execution of the flight plan by the UAV based on the one or more operational features of the UAV; and verifying, based on the simulating, that the UAV is capable of completing the flight plan. In some implementations, the one or more operational features can include at least one of a payload size for transporting by the UAV, an altitude limitation of the UAV, a speed limitation of the UAV, and an operational distance of the UAV. In some implementations, the one or more operational features can represent a specification of hardware sensors supported by the UAV. In some implementations, the operations can include providing an operator of the UAV selective access to telemetry of the UAV, wherein the selective access is based on a security layer provided by the computing interface. In some implementations, the operations can include receiving, at the computing interface, telemetry from the UAV and sending the telemetry to the client device for presentation on a user interface. In some implementations, generating the flight plan for the UAV can include generating the flight plan to include a specification of at least one operator from an operator database for monitoring the UAV during the flight of the UAV. In some implementations, the operations can include granting permission, via the computing interface, to a device of the at least one operator to operate the UAV during the flight of the UAV. In some implementations, granting the permission to the device of the at least one operator can be based on a certification and/or license associated with the operator. In some implementations, the certification and/or license associated with the at least one operator can be obtained through an assessment of the at least one operator using a simulated environment. In some implementations, generating the flight plan for the UAV can include generating the flight plan based on a consideration of capabilities, characteristics, and/or locations of at least one other UAV configured to communicate with the computing interface) (see at least paragraphs 3-11, 23, 26, 62-70, 79-82, 97, 113);
receive a plurality of mission requests (mission requests; tasks of a mission; The management system 304 enables configuration and execution of mission plans for unmanned vehicles 100, such as via the client device 102. For example, the management system 304 can control the remote computing system 104 to provide a remote connection to one or more of the unmanned vehicles 100. The management system 304 can provide security, authentication and/or management permissions for data sent to and/or received from an unmanned vehicle 100. The management system 304 can enable access to current and historical data from one or more unmanned vehicles by users of the management system 304. The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations; mission type and route) associated with the site (delivery locations) (see at least paragraphs 26, 44, 62-70, 105-109);
automatically assign (The management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task), after the receiving the plurality of mission requests, a plurality of unmanned vehicles to the operator based on the set of site rules, the experience indicator for the site and associated with the operator, and the experience indicator for the at least one unmanned vehicle and associated with the operator, each unmanned vehicle from the plurality of unmanned vehicles being assigned in response to a mission request from the plurality of mission requests, a number of unmanned vehicles in the plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the operator (The management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task); For example, the management system 304 can identify UAVs 100 that are capable of transporting particular payloads over minimum distances, and select and/or suggest such a UAV of the swarm for transporting said payload. For example, the management system 304 might send an alert to an operator of the client device 102 indicating that a particular UAV being assigned to a task is not capable of lifting an assigned payload. The operator can then select another available UAV from a list to perform the respective mission of transporting that payload. In another example, the management system 304 can consider the capabilities, characteristics, and locations of multiple UAVs in the same fleet when assigning and/or identifying UAVs to perform tasks. For example, given a fleet of UAVs that includes individual UAVs in various locations, the management system 304 can assign and/or identify a particular UAV to a task to reduce or minimize an estimated total amount of fuel usage used across the fleet) (see at least paragraphs 28, 45);
automatically authorize, after the automatically assigning, the operator to operate the plurality of unmanned vehicles that are operated by the operator in response to the authorizing (The management system 304 can integrate with Unmanned Traffic Management (UTM) authorities and/or other regulatory entities. The management system 304 can manage automated and operator-driven tasks and pre-flight checks. The management system can check one or more certifications of an operator or otherwise validate an operator's authorization to operate a particular UAV, execute a particular mission, and/or access particular data. In some implementations, the management system 304 can be a flight management system (FMS)) (see at least paragraphs 26, 97).
With regard to Claim 10, Roper teaches a method comprising:
defining, at a processor, an upper limit of unmanned vehicles (unmanned aerial vehicle (UAV)) for a first operator from a plurality of operators based on (1) a set of site rules that is for a first site (The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations) and that defines operational permissions for the first site (the method can include receiving, at the computing interface, telemetry from the UAV and sending the telemetry to the client device for presentation on a user interface. In some implementations, generating the flight plan for the UAV can include generating the flight plan to include a specification of at least one operator from an operator database for monitoring the UAV during the flight of the UAV. In some implementations, the method can include granting permission, via the computing interface, to a device of the at least one operator to operate the UAV during the flight of the UAV; permission to the device of the at least one operator can be based on a certification) and (2) at least one of a skill indicator associated with the first operator, the experience indicator for the first site and associated with the first operator, or the experience indicator for at least one unmanned vehicle and associated with the first operator (Turning to FIG. 3, the management system 304 monitors one or more components of the UAV 100 (e.g., including a hybrid generator system of the UAV) and controls their operation to provide efficient operation for execution of missions. As described above in relation to FIG. 1i, the management system 304 receives telemetry 106 that includes status data 178 from the status sensors 174. The telemetry 106 can include some or all of the data of Table 1, above, and can be refreshed at the frequencies shown or at other frequencies as appropriate. For example, the UAV 100 may transmit a subset of the data of Table 1 to the management system 304 unless an operator of the management system has special clearances to access additional data. For example, a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) (see at least paragraphs 3-11, 26, 62-70, 79, 113);
defining, at the processor, an upper limit of unmanned vehicles for a second operator from the plurality of operators based on (1) a set of site rules that is for a second site and that defines operational permissions for the second site (The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations) and (2) at least one of a skill indicator associated with the second operator, the experience indicator for the second site and associated with the second operator, or the experience indicator for at least one unmanned vehicle and associated with the second operator (Turning to FIG. 3, the management system 304 monitors one or more components of the UAV 100 (e.g., including a hybrid generator system of the UAV) and controls their operation to provide efficient operation for execution of missions. As described above in relation to FIG. 1i, the management system 304 receives telemetry 106 that includes status data 178 from the status sensors 174. The telemetry 106 can include some or all of the data of Table 1, above, and can be refreshed at the frequencies shown or at other frequencies as appropriate. For example, the UAV 100 may transmit a subset of the data of Table 1 to the management system 304 unless an operator of the management system has special clearances to access additional data. For example, a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) (see at least paragraphs 3-11, 26, 62-70, 79, 113);
receiving, at the processor, a plurality of mission requests (mission requests; tasks of a mission; The management system 304 enables configuration and execution of mission plans for unmanned vehicles 100, such as via the client device 102. For example, the management system 304 can control the remote computing system 104 to provide a remote connection to one or more of the unmanned vehicles 100. The management system 304 can provide security, authentication and/or management permissions for data sent to and/or received from an unmanned vehicle 100. The management system 304 can enable access to current and historical data from one or more unmanned vehicles by users of the management system 304. The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations; mission type and route) associated with the first site (delivery locations) (see at least paragraphs 26, 44, 62-70, 105-109);
receiving, at the processor, a plurality of mission requests associated with the second site (delivery locations) (see at least paragraphs 26, 44, 62-70, 105-109);
automatically assigning (The management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task), at the processor, a first plurality of unmanned vehicles to the first operator based on (1) the set of site rules for the first site (the operator database can also store one or more certifications and/or licenses held by each operator), and (2) at least one of a skill indicator associated with the first operator (the operator database can also store one or more certifications and/or licenses held by each operator), the experience indicator for the first site and associated with the first operator, or the experience indicator for the at least one unmanned vehicle and associated with the first operator, each unmanned vehicle from the first plurality of unmanned vehicles being automatically assigned in response to a mission request from the plurality of mission requests associated with the first site, a number of unmanned vehicles in the first plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the first operator (For example, the management system 304 can identify UAVs 100 that are capable of transporting particular payloads over minimum distances, and select and/or suggest such a UAV of the swarm for transporting said payload. For example, the management system 304 might send an alert to an operator of the client device 102 indicating that a particular UAV being assigned to a task is not capable of lifting an assigned payload. The operator can then select another available UAV from a list to perform the respective mission of transporting that payload. In another example, the management system 304 can consider the capabilities, characteristics, and locations of multiple UAVs in the same fleet when assigning and/or identifying UAVs to perform tasks. For example, given a fleet of UAVs that includes individual UAVs in various locations, the management system 304 can assign and/or identify a particular UAV to a task to reduce or minimize an estimated total amount of fuel usage used across the fleet) (see at least paragraphs 28-30, 45, 62);
automatically assigning, at the processor, a second plurality of unmanned vehicles to the second operator based on (1) the set of site rules for the second site, and (2) at least one of a skill indicator associated with the second operator, the experience indicator for the second site and associated with the second operator, or the experience indicator for the at least one unmanned vehicle and associated with the second operator, each unmanned vehicle from the second plurality of unmanned vehicles being automatically assigned in response to a mission request from the plurality of mission requests associated with the second site, a number of unmanned vehicles in the second plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the second operator, the upper limit of unmanned vehicles for the first operator being different from the upper limit of the unmanned vehicles for the second operator (The management system 304 can provide security, authentication and/or management permissions for data sent to and/or received from an unmanned vehicle 100. The management system 304 can enable access to current and historical data from one or more unmanned vehicles by users of the management system 304. The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations; mission type and route; (Turning to FIG. 3, the management system 304 monitors one or more components of the UAV 100 (e.g., including a hybrid generator system of the UAV) and controls their operation to provide efficient operation for execution of missions. As described above in relation to FIG. 1i, the management system 304 receives telemetry 106 that includes status data 178 from the status sensors 174. The telemetry 106 can include some or all of the data of Table 1, above, and can be refreshed at the frequencies shown or at other frequencies as appropriate. For example, the UAV 100 may transmit a subset of the data of Table 1 to the management system 304 unless an operator of the management system has special clearances to access additional data. For example, a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) (see at least paragraphs 26-30, 41-46, 62-70, 105-109);
automatically authorizing, after the automatically assigning the first/second plurality of unmanned vehicles, the first/second operator (a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) to operate the first/second plurality of unmanned vehicles that are operated by the first/second operator in response to the authorizing the first/second operator (The management system 304 can integrate with Unmanned Traffic Management (UTM) authorities and/or other regulatory entities. The management system 304 can manage automated and operator-driven tasks and pre-flight checks. The management system can check one or more certifications of an operator or otherwise validate an operator's authorization to operate a particular UAV, execute a particular mission, and/or access particular data. In some implementations, the management system 304 can be a flight management system (FMS)) (see at least paragraphs 3-11, 26-29, 62-70, 79, 97, 113).
With regard to Claims 13, 15, 17, Roper teaches a non-transitory processor-readable medium storing code representing instructions to be executed by a processor, the instructions comprising code to cause the processor to (environment 50, management system 304) (see at least paragraphs 24-45):
defining, at a processor, an upper limit of unmanned vehicles (unmanned aerial vehicle (UAV)) for a first operator from a plurality of operators based on (1) a set of site rules that is for a first site (The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations) and that defines operational permissions for the first site (the method can include receiving, at the computing interface, telemetry from the UAV and sending the telemetry to the client device for presentation on a user interface. In some implementations, generating the flight plan for the UAV can include generating the flight plan to include a specification of at least one operator from an operator database for monitoring the UAV during the flight of the UAV. In some implementations, the method can include granting permission, via the computing interface, to a device of the at least one operator to operate the UAV during the flight of the UAV; permission to the device of the at least one operator can be based on a certification) and (2) at least one of a skill indicator associated with the first operator, the experience indicator for the first site and associated with the first operator, or the experience indicator for at least one unmanned vehicle and associated with the first operator (Turning to FIG. 3, the management system 304 monitors one or more components of the UAV 100 (e.g., including a hybrid generator system of the UAV) and controls their operation to provide efficient operation for execution of missions. As described above in relation to FIG. 1i, the management system 304 receives telemetry 106 that includes status data 178 from the status sensors 174. The telemetry 106 can include some or all of the data of Table 1, above, and can be refreshed at the frequencies shown or at other frequencies as appropriate. For example, the UAV 100 may transmit a subset of the data of Table 1 to the management system 304 unless an operator of the management system has special clearances to access additional data. For example, a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) (see at least paragraphs 3-11, 26, 62-70, 79, 113);
defining, at the processor, an upper limit of unmanned vehicles for a second operator from the plurality of operators based on (1) a set of site rules that is for a second site and that defines operational permissions for the second site (The management system 304 can provide an interface (e.g., management system interface 308) to plan and configure high-level unmanned vehicle mission actions without requiring manual configuration of all of the lower-level details and/or parameters of the entire mission plan. Generally, high-level unmanned vehicle mission actions include general objectives to be accomplished by the unmanned vehicle 100 during the mission rather than specific commands used to achieve those objectives. For example, high-level mission actions can include defining waypoint lists, path planning, mission start and end locations, payload pickup or delivery locations) and (2) at least one of a skill indicator associated with the second operator, the experience indicator for the second site and associated with the second operator, or the experience indicator for at least one unmanned vehicle and associated with the second operator (Turning to FIG. 3, the management system 304 monitors one or more components of the UAV 100 (e.g., including a hybrid generator system of the UAV) and controls their operation to provide efficient operation for execution of missions. As described above in relation to FIG. 1i, the management system 304 receives telemetry 106 that includes status data 178 from the status sensors 174. The telemetry 106 can include some or all of the data of Table 1, above, and can be refreshed at the frequencies shown or at other frequencies as appropriate. For example, the UAV 100 may transmit a subset of the data of Table 1 to the management system 304 unless an operator of the management system has special clearances to access additional data. For example, a first operator may have access to a base set of data from the UAV 100, while a second operator may have access to a second, more comprehensive set of data from the UAV 100 at faster refresh rates) (see at least paragraphs3-11, 26, 62-70, 79, 113);
automatically assign a first plurality of unmanned vehicles to the first operator based on (1) a plurality of mission requests associated with the first site (The management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task. For example, the management system 304 can identify UAVs 100 that are capable of transporting particular payloads over minimum distances, and select and/or suggest such a UAV of the swarm for transporting said payload), (2) role-based access control (RBAC) for the first operator, and (3) at least one of the skill indicator associated with the first operator, the experience indicator for the first site and associated with the first operator, or the experience indicator for the at least one unmanned vehicle and associated with the first operator (Physics-based models account for as-built physical and aerodynamic properties of flight vehicles. Models of real world locations account for infrastructure, terrain, and dynamic weather conditions. Simulated flight test data is generated from each simulated mission. Physics-based simulation is combined with photo-realistic environments, which gives pilots and operators better experience, leading to faster attainment of proficiency. The simulation environment 306 allows industry designers to iterate on drone design, and further allows flight planners to test missions. As previously described, the simulation environment 306 can also be used for assessing the skillsets of pilots and operators to grant licenses and/or certifications (e.g., using a digital or virtual process). These licenses and/or certifications can authorize the pilots and operators to operate particular UAVs, access certain types of data, and/or execute missions having particular characteristics (e.g., weather conditions, geographic locations, time of day, number and type of UAVs involved, etc.)), each unmanned vehicle from the first plurality of unmanned vehicles being automatically assigned in response to a mission request from the plurality of mission requests associated with the first site, a number of unmanned vehicles in the first plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the first operator (management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task. For example, the management system 304 can identify UAVs 100 that are capable of transporting particular payloads over minimum distances, and select and/or suggest such a UAV of the swarm for transporting said payload. For example, the management system 304 might send an alert to an operator of the client device 102 indicating that a particular UAV being assigned to a task is not capable of lifting an assigned payload. The operator can then select another available UAV from a list to perform the respective mission of transporting that payload. In another example, the management system 304 can consider the capabilities, characteristics, and locations of multiple UAVs in the same fleet when assigning and/or identifying UAVs to perform tasks. For example, given a fleet of UAVs that includes individual UAVs in various locations, the management system 304 can assign and/or identify a particular UAV to a task to reduce or minimize an estimated total amount of fuel usage used across the fleet. The capability of the management system 304 in managing tasks and assigning and/or identifying UAVs of a fleet to perform those tasks) (see at least paragraphs 7-11, 44-47, 62, 113);
automatically assign a second plurality of unmanned vehicles to the second operator based on (1) a plurality of mission requests associated with the first site, (2) RBAC for the first/second operator, and (3) at least one of the skill indicator associated with the second operator, the experience indicator for the second site and associated with the second operator, or the experience indicator for the at least one unmanned vehicle and associated with the second operator, each unmanned vehicle from the second plurality of unmanned vehicles being automatically assigned in response to a mission request from the plurality of mission requests associated with the second site, a number of unmanned vehicles in the second plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the second operator, the set of site rules for the first site being different from the set of site rules for the second site (Physics-based models account for as-built physical and aerodynamic properties of flight vehicles. Models of real world locations account for infrastructure, terrain, and dynamic weather conditions. Simulated flight test data is generated from each simulated mission. Physics-based simulation is combined with photo-realistic environments, which gives pilots and operators better experience, leading to faster attainment of proficiency. The simulation environment 306 allows industry designers to iterate on drone design, and further allows flight planners to test missions. As previously described, the simulation environment 306 can also be used for assessing the skillsets of pilots and operators to grant licenses and/or certifications (e.g., using a digital or virtual process). These licenses and/or certifications can authorize the pilots and operators to operate particular UAVs, access certain types of data, and/or execute missions having particular characteristics (e.g., weather conditions, geographic locations, time of day, number and type of UAVs involved, etc.)), each unmanned vehicle from the first plurality of unmanned vehicles being automatically assigned in response to a mission request from the plurality of mission requests associated with the first site, a number of unmanned vehicles in the first plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the first operator (management system 304 can be used to identify a particular UAV that is suited for a task in a mission and automatically assign the respective UAV to perform that task. For example, the management system 304 can identify UAVs 100 that are capable of transporting particular payloads over minimum distances, and select and/or suggest such a UAV of the swarm for transporting said payload. For example, the management system 304 might send an alert to an operator of the client device 102 indicating that a particular UAV being assigned to a task is not capable of lifting an assigned payload. The operator can then select another available UAV from a list to perform the respective mission of transporting that payload. In another example, the management system 304 can consider the capabilities, characteristics, and locations of multiple UAVs in the same fleet when assigning and/or identifying UAVs to perform tasks. For example, given a fleet of UAVs that includes individual UAVs in various locations, the management system 304 can assign and/or identify a particular UAV to a task to reduce or minimize an estimated total amount of fuel usage used across the fleet. The capability of the management system 304 in managing tasks and assigning and/or identifying UAVs of a fleet to perform those tasks) (see at least paragraphs 7-11, 44-47, 62, 113).
With regard to Claims 2, 11, 15, Roper teaches:
automatically authorize, at the processor, the first operator for the first site and not for remaining sites from the plurality of sites (see at least paragraphs 87, 108-112);
receive, at the processor, a registration request for a first/second operator the automatically authorizing including from the plurality of operators and associated with a second site that is from the plurality of sites and that has a set of site rules defining operational permission for the second site (see at least paragraphs 87, 108-112);
automatically authorize, at the processor, after the registration request for the second operator is received, the second operator for the second site from the plurality of sites and not remaining sites from the plurality of sites (see at least paragraphs 87, 108-112).
With regard to Claim 3, Roper teaches:
automatically assign a second plurality of unmanned vehicles to a second operator from the plurality of operators, a number of unmanned vehicles in the second plurality of unmanned vehicles not exceeding an upper limit of unmanned vehicles for the second operator, the upper limit of unmanned vehicles for the first operator is different from the upper limit of unmanned vehicles for the second operator (see at least paragraphs 87, 108-112).
With regard to Claim 4, Roper teaches:
receive a registration request for a second operator from the plurality of operators and associated with a second site that is from the plurality of sites and that has a set of site rules defining operational permission for the second site (see at least paragraphs 87, 108-112);
automatically assign a second plurality of unmanned vehicles to the second operator, a number of unmanned vehicles in the second plurality of unmanned vehicles not exceeding an upper limit of unmanned vehicles for the second operator, the set of site rules for the first site differing from set of site rules for the second site (see at least paragraphs 87, 108-112).
With regard to Claim 5, Roper teaches wherein the code to assign includes code to assign the plurality of unmanned vehicles to the operator further based on role-based access control (RBAC) for the operator and an availability of the operator (see at least paragraphs 7-11, 62).
With regard to Claim 6, Roper teaches: the site is included within a plurality of sites, automatically authorize, after receiving the registration request, the operator for the site and not for remaining sites from the plurality of sites, the code to assign includes code to assign, after the operator has been authorized, the plurality of unmanned vehicles to the operator further based on role-based access control (RBAC) for the operator (see at least paragraphs 7-11, 62).
With regard to Claim 7, Roper teaches: the instructions to automatically authorize include automatically authorize, after receiving the registration request, the operator for the site and not for remaining sites from the plurality of sites, the code to assign includes code to assign, after the operator has been authorized, the plurality of unmanned vehicles to the operator during a time period when the operator is available to operate the plurality of unmanned vehicles (see at least paragraphs 7-11, 62).
With regard to Claim 8, Roper teaches:
receive an indication of communication failure between a compute device of the first operator and a first unmanned vehicle from the plurality of unmanned vehicles assigned to the first operator (see at least paragraphs 28, 72);
automatically, in response to the receiving the indication of communication failure, reassign the first unmanned vehicle to a second operator based on an availability of the second operator and not based on an experience indicator for the site and associated with the second operator, a number of unmanned vehicles assigned to the second operator after the first unmanned vehicles is reassigned to the second operator does not exceed an upper limit of unmanned vehicles for the second operator (see at least paragraphs 28, 72).
With regard to Claim 9, Roper teaches:
receive an indication of communication failure between a compute device of the first operator and each unmanned vehicle from the plurality of unmanned vehicles assigned to the first operator (see at least paragraphs 28, 72);
automatically, in response to the receiving the indication of communication failure, reassign the plurality of unmanned vehicles to at least one operator other than the first operator based on an availability of the at least one operator and not based on an experience indicator for the site and associated with the at least one operator, a number of unmanned vehicles assigned to each operator from the at least one operator after the plurality of unmanned vehicles are reassigned does not exceed an upper limit of unmanned vehicles for each operator from the at least one operator (see at least paragraphs 28, 72).
With regard to Claim 12, Roper teaches wherein the set of site rules for the first site is different from the set of site rules for the second site (see at least paragraph 45).
With regard to Claim 13, Roper teaches:
automatically assigning the first plurality of unmanned vehicles to the first operator includes automatically assigning the first plurality of unmanned vehicles to the first operator further based on role-based access control (RBAC) for the first operator (see at least paragraphs 7-11, 62);
automatically assigning the second plurality of unmanned vehicles to the second operator includes automatically assigning the second plurality of unmanned vehicles to the second operator further based on RBAC for the second operator (see at least paragraphs 7-11, 62).
With regard to Claims 14, 18, Roper teaches:
automatically assigning the first plurality of unmanned vehicles to the first operator includes automatically assigning the first plurality of unmanned vehicles to the first operator further based on an availability of the first operator (see at least paragraphs 44-45);
automatically assigning the second plurality of unmanned vehicles to the second operator includes automatically assigning the second plurality of unmanned vehicles to the second operator further based on an availability of the second operator (see at least paragraphs 44-45).
With regard to Claims 16, 20, Roper teaches:
receiving, at the processor, a registration request for a third operator (see at least paragraphs 29, 69);
defining, at the processor, an upper limit of unmanned vehicles for the third operator from the plurality of operators based on the set of site rules for the first site; and automatically assigning, at the processor, a third plurality of unmanned vehicles to the third operator based on the set of site rules for the first site, each unmanned vehicle from the third plurality of unmanned vehicles being automatically assigned in response to a second mission request from the plurality of mission requests associated with the first site, a number of unmanned vehicles in the third plurality of unmanned vehicles not exceeding the upper limit of unmanned vehicles for the third operator and being different from the number of unmanned vehicles in the first plurality of unmanned vehicles (see at least paragraphs 7-11, 44-47, 62, 113).
With regard to Claim 19, Roper teaches: the code to automatically assign the first plurality of unmanned vehicles to the first operator includes code to automatically assign the first plurality of unmanned vehicles to the first operator further based on the set of site rules of the first site, and the code to automatically assign the second plurality of unmanned vehicles to the second operator includes code to automatically assign the second plurality of unmanned vehicles to the second operator further based on the set of site rules of the second site (see at least paragraphs 28, 72).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Dodd (US 10,909,859)
Michini (US 2018/004207)
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS L MANSFIELD whose telephone number is (571)270-1904. The examiner can normally be reached M-Thurs, alt. Fri. (9-6).
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, Patricia Munson can be reached at (571) 270-5396. 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.
THOMAS L. MANSFIELD
Examiner
Art Unit 3623
/THOMAS L MANSFIELD/Primary Examiner, Art Unit 3624