DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/7/2026 has been entered.
Claims 1, 8, 9, 13, 16 and 18 have been amended. Claims 7, 12, 15 and 20 have been canceled. Claims 1-6, 8-11, 13 and 16-18 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The previously pending objection to claims 1, 9 and 16 has been withdrawn.
The previously pending rejection to claims 1-13, 15-18 and 20, under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, has been withdrawn.
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-6, 8-11, 13 and 16-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to an abstract idea without significantly more.
Here, under step 1 of the Alice analysis, system claims 1-6 and 8 are directed to at least one orchestration processor configured by non-transitory processor executable code and at least one platform processor, apparatus claims 9-11 and 13 are directed to at least one orchestration processor configured by non-transitory processor executable code, and method claims 16-18 are directed to a series of steps. Thus the claims are directed to a machine, machine and process, respectively.
Under step 2A Prong One of the analysis, the claimed invention is directed to an abstract idea without significantly more. The claims recite performing a task, including receiving, establishing, determining, defining, aggregating, assigning, transmitting, selecting and sending steps.
The limitations of receiving, establishing, determining, defining, aggregating, assigning, transmitting, selecting and sending, are a process that, under its broadest reasonable interpretation, covers organizing human activity concepts, but for the recitation of generic computer components.
Specifically, the claim elements recite receive one or more mission objectives; establish a datalink with a plurality of heterogeneous mobile platforms comprising crewed platforms, uncrewed platforms, and unattended sensors; determine, for each of the plurality of heterogeneous mobile platforms, a platform-capability profile including sensor capability information, effector capability information, locomotion- related operating constraints, and endurance information; define a mission task, defined to achieve the mission objective, within capabilities of at least one mobile platform in the plurality of heterogeneous mobile platforms based on the platform-capability profiles; aggregate a plurality of the mission tasks into aggregate behaviors according a hierarchical mission-task architecture; define one or more virtual platforms, each virtual platform corresponding to a set of tasks defined by the one or more mission objectives and comprising an amalgamation of two or more heterogeneous mobile platforms configured and tasked to operate in concert to accomplish behaviors beyond capabilities of any individual mobile platform; assign two or more mobile platforms to the virtual platform to function as a singular asset, wherein the virtual platform is formed based on the platform-capability profiles; transmit task-assignment data to the assigned heterogeneous mobile platform to cause coordinated execution of the aggregate behaviors; determine that at least one of the mobile platforms assigned to the virtual platform is impaired or unavailable; and automatically select, based on the platform capability profiles, a replacement mobile platform from the plurality of heterogeneous mobile platforms and reassign at least one mission task to the replacement mobile platform; send the platform-capability profiles; and receive the mission task.
That is, other than reciting at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor, the claim limitations merely cover managing interactions between people, including following rules or instructions, thus falling within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Under Step 2A Prong Two, the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This judicial exception is not integrated into a practical application. The claims include at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor. The at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor in the steps is recited at a high-level of generality, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. As a result, the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
None of the dependent claims recite additional limitations that are sufficient to amount to significantly more than the abstract idea. Claims 2 and 3 recite an additional sending step and additional further describes the data representative of a location. Claims 4-6 further describe the plurality of mobile platforms and recite additional monitor, select, and task one or more behaviors and task two or more heterogeneous mobile platforms steps. Claim 8 recites an additional combining step. Similarly, dependent claims 10, 11, 13, 17 and 18 recite additional details that further restrict/define the abstract idea. A more detailed abstract idea remains an abstract idea.
Under step 2B of the analysis, the claims include, inter alia, at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor.
As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
There isn’t any improvement to another technology or technical field, or the functioning of the computer itself. Moreover, individually, there are not any meaningful limitations beyond generally linking the abstract idea to a particular technological environment, i.e., implementation via a computer system. Further, taken as a combination, the limitations add nothing more than what is present when the limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
In addition, as discussed in paragraph 0021 of the specification, “The system, embodied in a mobile platform, includes a processor 300 and memory 302 connected to the processor 300 for embodying processor executable code. Each mobile platform may define a node in a network such as a mobile ad-hoc network; the processor 300 is configured to communicate with a heterogeneous orchestration engine via a data communication device 304 (including IP radio networks, satellite networks, cellular networks, wi-fi, or the like). The processor 300 may receive data from other nodes via the orchestration engine and data communication device 304, and store such data in a data storage element 308. Likewise, the processor 300 may receive sensor data from one or more sensors 306 and send that data the orchestration engine for distribution to other nodes.”
As such, this disclosure supports the finding that no more than a general purpose computer, performing generic computer functions, is required by the claims.
Viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. See Alice Corporation Pty. Ltd. v. CLS Bank Int’l et al., No. 13-298 (U.S. June 19, 2014).
Claim Rejections - 35 USC § 102
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 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-6, 8-11, 13 and 16-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sudarsan et al (US 20200166928 A1).
As per claim 1, Sudarsan et al disclose a system, comprising: at least one orchestration processor configured by non-transitory processor executable code (i.e., FIG. 2 is a block diagram of a particular example of a hub device 102. The hub device 102 of FIG. 2 may be a stationary hub device 102A or a mobile hub device 102B of FIG. 1, ¶ 0025) to:
receive one or more mission objectives (i.e., If a goal or objective is specified, the processor(s) 210 can be used to execute one or more of the decision models 220 to evaluate the goal or objective and determine one or more tasks (e.g., specific operations or activities) to be performed to accomplish the goal or objective, ¶ 0031);
establish a datalink, via a network interface, with a plurality of heterogeneous mobile platforms comprising crewed platforms, uncrewed platforms, and unattended sensors (i.e., data can be gathered while an expert remote vehicle operator performs the specific task, ¶ 0023. The stationary hub device 102A can communicate with other stationary devices (e.g., infrastructure devices 106) via wired connections and can communicate with mobile device (e.g., unmanned vehicles 104 and mobile hub devices 102B) via wireless connections. The network interface device(s) 204 can be used to communicate location data 214 (e.g., peer location data associated with one or more peer hub devices), sensor data (e.g., a sensor data stream, such as a video or audio stream), task data, commands to unmanned vehicles 104, etc., ¶ 0026);
determine, for each of the plurality of heterogeneous mobile platforms, a platform-capability profile including sensor capability information (i.e., The unmanned vehicle 104 also includes one or more sensors 350 configured to generate sensor data 352, ¶ 0048), effector capability information, locomotion- related operating constraints, and endurance information (i.e., inventory data indicating that several of the unmanned vehicles 104 stored at the mobile hub device 102B are in a ready state (e.g., have sufficient fuel or a sufficient battery charge level, have no fault conditions that would limit or prevent operation, etc.), have equipment that would be helpful for riot control (e.g., a tear gas dispenser, a loud speaker, a wide angle camera, etc.), have movement capabilities (e.g., range, speed, off-road tires, maximum altitude) appropriate for use in the adjacent zone, etc., ¶ 0017. Examples of other equipment 354 can include effectors or manipulators (e.g., to pick up, move, or modify objects), weapons systems, cargo related devices (e.g., devices to acquire, retain, or release cargo), etc., ¶ 0049);
define a mission task, defined to achieve the mission objective, within the capabilities of at least one mobile platform in the plurality of heterogeneous mobile platforms based on the platform-capability profiles (i.e., The vehicle selection model 222 is executable by the processor(s) 210 to evaluate the inventory data 230, task assignment data 232, the map data 234, and the location data 214, to assign one or more unmanned vehicles 104 of the plurality of unmanned vehicles 104 to perform a task of a task assignment, ¶ 0034. The mission planning model 224 can provide the set of estimated capabilities to the vehicle selection model 222, and the vehicle selection model 222 can select the one or more unmanned vehicles 104 to assign to a task based in part on the set of estimated capabilities, ¶ 0036);
aggregate a plurality of the mission tasks into aggregate behaviors according a hierarchical mission-task architecture (i.e., operating in the coordination role, can receive status information 332 from peer devices of the group, generate aggregate status information for the group based on the status information 332, and transmit the aggregate status information 332 to a remote command device. When the coordination and control device is operating in the coordination role, the peer devices of the group can operate autonomously and cooperatively to perform a task, ¶ 0055. The architecture (also referred to herein as a topology) of a model includes a configuration of layers or nodes and connections therebetween, ¶ 0080);
define one or more virtual platforms, each virtual platform corresponding to a set of tasks defined by the one or more mission objectives and comprising an amalgamation of two or more heterogeneous mobile platforms configured and tasked to operate in concert to accomplish behaviors beyond capabilities of any individual mobile platform (i.e., the unmanned vehicle 104 of FIG. 3 is part of a swarm (e.g., a group of unmanned vehicles 104 that are coordinating to perform a task), the unmanned vehicle 104 can provide some or all of the capabilities data 338 to other vehicles of the swarm or to a coordination and control vehicle of the swarm, ¶ 0051);
assign two or more mobile platforms to the virtual platform to function as a singular asset, wherein the virtual platform is formed based on the platform-capability profiles (i.e., the unmanned vehicle 104 of FIG. 3 is part of a swarm (e.g., a group of unmanned vehicles 104 that are coordinating to perform a task), the unmanned vehicle 104 can provide some or all of the capabilities data 338 to other vehicles of the swarm or to a coordination and control vehicle of the swarm, ¶ 0051);
transmit task-assignment data to the assigned heterogeneous mobile platform to cause coordinated execution of the aggregate behaviors (i.e., the network interface device(s) 204 of a mobile hub device 102B can include one or more wireless transmitters, one or more wireless receivers, or a combination thereof (e.g., one or more wireless transceivers) to communicate with the other devices, ¶ 0026);
determine that at least one of the mobile platforms assigned to the virtual platform is impaired or unavailable (i.e., Examples of such intrinsic factors include occurrence of fault conditions or equipment malfunctions, ¶ 0036); and
automatically select, based on the platform capability profiles, a replacement mobile platform from the plurality of heterogeneous mobile platforms and reassign at least one mission task to the replacement mobile platform (i.e., method 500 also enables the hub device 102 to plan task routes for the unmanned vehicles 104, which can include handing recovery of an unmanned vehicle 104, hand off of the unmanned vehicle to another hub device 102, ¶ 0062); and
a plurality of heterogeneous mobile platforms, each comprising: one or more sensors (i.e., The unmanned vehicle 104 also includes one or more sensors 350 configured to generate sensor data 352, ¶ 0048); and
at least one platform processor configured by non-transitory processor executable code to: send the platform-capability profiles to the at least one orchestration processor (i.e., The vehicle selection model 222 is executable by the processor(s) 210 to evaluate the inventory data 230, task assignment data 232, the map data 234, and the location data 214, to assign one or more unmanned vehicles 104 of the plurality of unmanned vehicles 104 to perform a task of a task assignment, ¶ 0034); and
receive the mission task from the orchestration processor (i.e., assign one or more unmanned vehicles 104 of the plurality of unmanned vehicles 104 to perform a task of a task assignment, ¶ 0034).
As per claim 2, Sudarsan et al disclose wherein each at least one platform processor is further configured to send sensor output data representative of a location of the corresponding mobile platform to the orchestration processor (i.e., The location data 214 can also include peer location data indicating the locations of peer devices (e.g., peer hub devices, infrastructure devices, unmanned vehicles, or a combination thereof), ¶ 0028), the sensor output data being used by the orchestration processor to update the platform-capability profiles (i.e., Other portions of the capabilities data 338 are updated or modified during normal operation of the unmanned vehicle 104, ¶ 0053).
As per claim 3, Sudarsan et al disclose wherein the data representative of a location comprises a location relative to a ground control device (i.e., the location data 214 can be determined by one or more location sensors 216, such as a global positioning system receiver, a local positioning system sensor, a dead-reckoning sensor, etc. If the hub device 102 is a stationary hub device 102A, the location data 214 can be preprogrammed in the memory 212 or can be determined by one or more location sensors 216. The location data 214 can also include peer location data indicating the locations of peer devices (e.g., peer hub devices, infrastructure devices, unmanned vehicles, or a combination thereof), ¶ 0028).
As per claim 4, Sudarsan et al disclose wherein the plurality of mobile platforms includes both crewed platforms and uncrewed platforms (i.e., Accordingly, devices (e.g., hub devices 102 and unmanned vehicles 104) of the system 100 are able to operate cooperatively or autonomously to perform one or more tasks. While a human can intervene, in some implementations, the system 100 can operate without human intervention, ¶ 0024).
As per claim 5, Sudarsan et al disclose the orchestration processor is further configured to: individually monitor, select, and task one or more behaviors of one or more mobile platforms in the plurality of mobile platforms based on the one or more sensors, one or more payloads, one or more effectors, or a cargo associated with corresponding mobile platform (i.e., the vehicle selection model 222 can select an unmanned vehicle 104 that has equipment capable of performing the task and that has sufficient fuel or battery charge, and that has particular other characteristics (e.g., flight range, off-road tires, etc.) to accomplish the task. In some implementations, the vehicle selection model 222 can also select the unmanned vehicle 104 based on other information, such as the peer location data, ¶ 0034), using the platform-capability profiles to determine feasible behaviors (i.e., mission planning model 224 can provide the set of estimated capabilities to the vehicle selection model 222, ¶ 0036).
As per claim 6, Sudarsan et al disclose the orchestration processor is further configured to: task two or more heterogeneous mobile platforms in the plurality of mobile platforms to achieve a common objective, including coordination of crewed and uncrewed platforms (i.e., After the vehicle selection model 222 selects the one or more unmanned vehicles 104 to perform the task, the hub device 102 assigns the one or more unmanned vehicles 104 to the task by storing information (e.g., in the inventory data 230) indicating that the one or more unmanned vehicles 104 are occupied, instructing the one or more unmanned vehicles 104, and deploying the one or more unmanned vehicles 104, ¶ 0034. The cost-benefit model 228 is configured to consider a priority assigned to the task (e.g., how important is successful accomplishment of this specific task to accomplishment of an overall goal or objective), ¶ 0035).
As per claim 8, Sudarsan et al disclose the orchestration processor is further configured to: combine aggregate behaviors into complex behaviors comprising coordinated execution of multiple aggregate behaviors (i.e., operating in the coordination role, can receive status information 332 from peer devices of the group, generate aggregate status information for the group based on the status information 332, and transmit the aggregate status information 332 to a remote command device. When the coordination and control device is operating in the coordination role, the peer devices of the group can operate autonomously and cooperatively to perform a task, ¶ 0055).
Claims 9-11 and 13 are rejected based upon the same rationale as the rejection of claims 1, 5, 6 and 8, respectively, since they are the apparatus claims corresponding to the system claims.
Claims 16-18 are rejected based upon the same rationale as the rejection of claims 1, 6 and 8, respectively, since they are the method claims corresponding to the system and apparatus claims.
Response to Arguments
In the Remarks, Applicant argues the claims recite a specific technological system that improves the functioning of distributed command-and-control architectures for heterogeneous crewed and uncrewed platforms through capability-based task allocation, hierarchical behavior generation, and dynamic reconfiguration of composite virtual platforms. The Claims therefore recite a specific technological architecture for controlling distributed robotic systems and are not directed to an abstract idea. The Patent Office characterized the claims as organizing human activity. However, the Claims are directed to the automated control and coordination of physical platforms communicating through a networked orchestration processor and operating on real-world sensor data.
The Claims require an orchestration processor configured to establish a datalink with a plurality of heterogeneous mobile platforms including crewed platforms, uncrewed platforms, and unattended sensors; maintain platform capability profiles describing technical characteristics of each platform; receive sensor output data from the platforms; update the platform capability profiles based on that data; determine executable mission tasks based on those capability profiles; aggregate the tasks into hierarchical behaviors; define virtual platforms composed of multiple heterogeneous platforms functioning as a singular operational asset; and automatically reassign tasks when one of the platforms becomes impaired. These operations are performed automatically by the orchestration processor using machine-to-machine communications and platform sensor data and therefore constitute a technological control framework rather than a scheme for organizing human activity.
The orchestration engine receives sensor information from the platforms, selects tasks that fall within the capabilities of those platforms, aggregates the tasks into more complex behaviors, and dynamically substitutes platforms when a platform becomes unavailable so that mission execution can continue. The claimed system therefore improves the technological field of distributed robotic orchestration by enabling capability-based control of heterogeneous assets and persistent mission execution despite the loss or degradation of individual platforms. Such automated coordination and reconfiguration of networked robotic systems is a technical improvement to the operation of distributed machine systems and does not constitute an abstract idea.
The Claims require specific machine structures and operations including networked communication between an orchestration processor and heterogeneous platforms, maintenance of capability profiles describing platform operating characteristics, sensor-driven updates to those profiles, hierarchical aggregation of mission tasks into coordinated behaviors, formation of virtual platforms composed of multiple physical platforms acting as a single operational asset, and automatic replacement of impaired platforms based on updated capability information. These limitations meaningfully constrain the scope of the Claims and define a concrete system for coordinating distributed robotic assets using real-time platform state information. The claimed orchestration processor does not merely process information in the abstract but instead performs automated control of physical systems based on technical characteristics and sensor inputs from those systems.
Furthermore, the claims recite significantly more than any alleged abstract idea. The orchestration processor is not a generic computer performing routine data processing but is specifically configured to maintain capability abstractions for heterogeneous platforms, generate hierarchical behaviors from mission tasks, create composite virtual platforms from multiple physical assets, and dynamically reconfigure those virtual platforms when a constituent platform becomes impaired. This architecture enables the orchestration of heterogeneous robotic platforms as composite operational assets whose capabilities are derived from the combined capabilities of their constituent platforms. The automatic reassignment of tasks based on dynamically updated capability profiles improves the resilience and persistence of distributed robotic systems and represents a technological improvement to the field of networked machine control. The Examiner respectfully disagrees.
Importantly, as an initial point, other than the recitation of a network interface, method claims 16-18 fail to recite any computer elements (e.g., at least one orchestration processor) implementing the method steps.
As described in paragraphs 0017 and 0018 of the specification, “This concept can apply to anything in the environment including an unattended ground sensor, a police officer or soldier, or an uncrewed surface vessel. For example, a small uncrewed aerial vehicle (UAS) has a camera sensor, no effectors, a range of 20km and an endurance of 2 hours. The orchestration engine 100 may task this asset to perform reconnaissance (Recon) of a specific location, perform overwatch for a friendly unit, or, track and surveille a potentially hostile unit for situational awareness. Recon, Overwatch, and Track may be classed as mission tasks.”
“Within the system, the capabilities of a given asset (crewed or uncrewed) is known and abstracted. One value of this abstraction is the ability of the orchestration engine 100 to select an asset to meet specific mission requirements without understanding the specifics of the underlying platform. An Overwatch mission for a group of soldiers can be accomplished by any ISR platform that is within the kinematic envelope. A commander doesn’t have to care about the specifics of a platform as long as the mission is accomplished. This notion lends itself to improved persistence.”
As a result, and contrary to Applicant’s assertion, the claim limitations merely cover task assignment, including managing interactions between people, and following rules or instructions, thus falling within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Under Step 2A Prong Two, the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by (a) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (b) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. 2019 PEG Section III(A)(2), 84 Fed. Reg. at 54-55. Besides the abstract idea, the claims include at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor.
The at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor in the steps is recited at a high-level of generality, such that it amounts no more than mere instructions to apply the exception using a generic computer component. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. It should be noted that because the courts have made it clear that mere physicality or tangibility of an additional element or elements is not a relevant consideration in the eligibility analysis, the physical nature of these computer components does not affect this analysis. See MPEP 2106.05(I) for more information on this point, including explanations from judicial decisions including Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26 (2014).
Even when viewed in combination, the additional elements in the claims do no more than use computer components as a tool (i.e., at least one orchestration processor, a network interface, and a plurality of heterogeneous mobile platforms, each comprising: one or more sensors; and at least one platform processor). There is no change to the computers and/or other technology recited in the claims, thus the claims do not improve computer functionality or other technology. See, e.g., Trading Technologies Int’l v. IBG, Inc., 921 F.3d 1084, 1093 (Fed. Cir. 2019) (using a computer to provide a trader with more information to facilitate market trades improved the business process of market trading, but not the computer) and the cases discussed in MPEP 2106.05(a)(I), particularly FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095 (Fed. Cir. 2016) (accelerating a process of analyzing audit log data is not an improvement when the increased speed comes solely from the capabilities of a general-purpose computer) and Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055 (Fed. Cir. 2017) (using a generic computer to automate a process of applying to finance a purchase is not an improvement to the computer’s functionality). Accordingly, the claim as a whole does not integrate the recited judicial exception into a practical application and the claim is directed to the judicial exception.
Moreover, and contrary to Applicant’s assertion, there isn’t any improvement to another technology or technical field, or the functioning of the computer itself. Moreover, individually, there are not any meaningful limitations beyond generally linking the abstract idea to a particular technological environment, i.e., implementation via a computer system. Further, taken as a combination, the limitations add nothing more than what is present when the limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Specifically, as discussed in paragraph 0021 of the specification, “The system, embodied in a mobile platform, includes a processor 300 and memory 302 connected to the processor 300 for embodying processor executable code. Each mobile platform may define a node in a network such as a mobile ad-hoc network; the processor 300 is configured to communicate with a heterogeneous orchestration engine via a data communication device 304 (including IP radio networks, satellite networks, cellular networks, wi-fi, or the like). The processor 300 may receive data from other nodes via the orchestration engine and data communication device 304, and store such data in a data storage element 308. Likewise, the processor 300 may receive sensor data from one or more sensors 306 and send that data the orchestration engine for distribution to other nodes.”
Applicant also argues that Claim 1 recites elements which have not been disclosed by Sudarsan. For example, Claim 1 recites: "define one or more virtual platforms, each virtual platform corresponding to a set of tasks defined by the one or more mission objectives and comprising an amalgamation of two or more heterogeneous mobile platforms configured and tasked to operate in concert to accomplish behaviors beyond capabilities of any individual mobile platform..."
Sudarsan does not disclose the claimed orchestration architecture and therefore cannot anticipate Claim 1. Claim 1 recites a system in which an orchestration processor coordinates heterogeneous mobile platforms using capability-based platform profiles, hierarchical task aggregation, and the formation of virtual platforms composed of multiple heterogeneous platforms operating as a singular operational asset. Sudarsan fails to disclose or suggest these elements, either individually or in combination.
Sudarsan, by comparison, does not disclose maintaining such structured capability profiles describing heterogeneous platform characteristics including sensor capabilities, effector capabilities, locomotion constraints, and endurance parameters, nor does Sudarsan disclose defining tasks based on such profiles in the manner recited in the claim. Sudarsan does not disclose such a hierarchical task architecture in which mission tasks are aggregated into progressively higher- level operational behaviors. Sudarsan does not disclose such a capability-derived virtual platform. Instead, Sudarsan assigns tasks to individual vehicles or groups of vehicles but continues to treat those vehicles as independent assets performing assigned roles. The reference does not disclose defining a new composite operational entity that functions as a singular asset whose combined capabilities exceed those of any individual platform. Sudarsan does not disclose such an arrangement in which heterogeneous platforms are amalgamated into a singular operational asset defined by combined capabilities. This dynamic reconstitution of the virtual platform based on capability profiles ensures persistence of mission execution even when constituent platforms change. Sudarsan does not disclose such capability-driven reconstitution of a virtual composite asset. The Examiner respectfully disagrees.
As discussed in the updated rejection, and contrary to Applicant’s assertion, Sudarsan et al indeed disclose Applicant’s amended claim language.
Sudarsan et al disclose establish a datalink, via a network interface, with a plurality of heterogeneous mobile platforms comprising crewed platforms, uncrewed platforms, and unattended sensors (i.e., data can be gathered while an expert remote vehicle operator performs the specific task, ¶ 0023. The stationary hub device 102A can communicate with other stationary devices (e.g., infrastructure devices 106) via wired connections and can communicate with mobile device (e.g., unmanned vehicles 104 and mobile hub devices 102B) via wireless connections. The network interface device(s) 204 can be used to communicate location data 214 (e.g., peer location data associated with one or more peer hub devices), sensor data (e.g., a sensor data stream, such as a video or audio stream), task data, commands to unmanned vehicles 104, etc., ¶ 0026)…
…aggregate a plurality of the mission tasks into aggregate behaviors according a hierarchical mission-task architecture (i.e., operating in the coordination role, can receive status information 332 from peer devices of the group, generate aggregate status information for the group based on the status information 332, and transmit the aggregate status information 332 to a remote command device. When the coordination and control device is operating in the coordination role, the peer devices of the group can operate autonomously and cooperatively to perform a task, ¶ 0055. The architecture (also referred to herein as a topology) of a model includes a configuration of layers or nodes and connections therebetween, ¶ 0080)…
…define one or more virtual platforms, each virtual platform corresponding to a set of tasks defined by the one or more mission objectives and comprising an amalgamation of two or more heterogeneous mobile platforms configured and tasked to operate in concert to accomplish behaviors beyond capabilities of any individual mobile platform (i.e., the unmanned vehicle 104 of FIG. 3 is part of a swarm (e.g., a group of unmanned vehicles 104 that are coordinating to perform a task), the unmanned vehicle 104 can provide some or all of the capabilities data 338 to other vehicles of the swarm or to a coordination and control vehicle of the swarm, ¶ 0051).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDRE D BOYCE whose telephone number is (571)272-6726. The examiner can normally be reached M-F 10a-6:30p.
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, Rutao (Rob) Wu can be reached at (571) 272-6045. 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.
/ANDRE D BOYCE/Primary Examiner, Art Unit 3623 June 16, 2026
Prosecution Insights