DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a Non-Final rejection on the merits of this application. Claims 1-20 are pending and addressed below.
Continued Examination Under 37 CFR 1.114
1. 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 10/06/2025 has been entered.
Response to Arguments
2. Applicant’s amendments/arguments filed 10/06/2025 with respect to 35 USC 102,
have been fully considered but moot because the arguments do not apply to the combination of references and/or rationale being used in the current rejection.
Claim Rejections - 35 USC § 103
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
4. Claims 1-4, 8-14, 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (US 20220048186, hereinafter Sharma) in view of Borne-Pons (US 20220147059, hereinafter Borne-Pons).
Regarding claim 1, Sharma teaches a method (see at least abstract: “A system and a method to dynamically update plans and task allocation strategies on at least one or more of cloud and plurality of heterogeneous autonomous mobile devices (e.g. robot) has been described.”), comprising:
storing, at a mobile robot, a local repository of self-assigned task definitions (see at least [0037]: “A plan execution engine includes a logic for executing a plan, allocating tasks by one or more heterogeneous devices and/or cloud. A plan may include several sub-plans that in combination form the plan. Robot behaviour is a low level atomic activity, within a plan, executed by a robot under certain conditions. For example, a “robot charging” plan may include three states: robot waiting state, robot docking state, and robot charging state.”; [0043]: “In one of the embodiments, a catalog store 101 may include multiple catalogs like Plan catalog 111, Task allocation catalog 112, Agent catalog 113 etc. Task allocation catalog 112 may be used by platforms to retrieve different task allocation strategies, for example, assign order based on shortest distance or assign order based on reducing overall time required to process orders.”; [0045]: “In one embodiment, the autonomous mobile robots include processors for executing the instructions and memory for storage.”);
determining, at a processor of the mobile robot, that a local activity metric associated with tasks assigned to the mobile robot by a central server meets an idle criterion (see at least
[0029]: “The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.”; [0043]: “FIG. 1 is a block diagram illustrating a system 100 for dynamically generating solutions for updating plans and task allocation strategies, according to an embodiment. It is understood that the term ‘dynamically’ may include runtime or post-deployment operations or while the autonomous mobile device is in different states, like active or idle in an operating environment.”; [0047]: “In one embodiment, consider a scenario where there are 3 AMRs (104b, 104c, 104d (not shown)) and one of them needs to be charged first. So, it all depends on how the plan ‘charging’ is configured. The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR),…The DR module 102 ensures seamless transition of functionalities between the plan execution engines for optimal performance.”; [0091]: “FIG. 6 is an exemplary flow diagram illustrating process steps for updating plans and task allocation strategies, according to an embodiment. In one embodiment, DR module monitors events happening at the platform level and at the robot level as discussed herein (601). The DR module analyzes and keeps track of the values of all variables of platform, plan, and task allocation strategy that may be tracked (602). These values that are to be tracked may be compared with the predetermined criteria provided at design time or in the plan, and task allocation strategy itself. The predetermined criteria can be customized or defined as per the various factors, for example based on throughput expected in the warehouse, say 100 picks per hour by a Pick assist robot.”);
in response to determining that the local activity metric meets the idle criterion, selecting, by the processor of the mobile robot, one of the self-assigned task definitions from the local repository (see at least [0091]: “The DR module analyzes and keeps track of the values of all variables of platform, plan, and task allocation strategy that may be tracked (602). These values that are to be tracked may be compared with the predetermined criteria provided at design time or in the plan, and task allocation strategy itself. The predetermined criteria can be customized or defined as per the various factors, for example based on throughput expected in the warehouse, say 100 picks per hour by a Pick assist robot. The variables may also be compared with threshold values that may be set based on various factors as discussed herein (603). After comparison between one of the analysed platform variables, task allocation strategy and/or plan variables and a predetermined criteria or pre-defined threshold values, the platform may continue monitoring events or ignore the notification if the variables have values higher than the threshold value or the predetermined criteria (604). However, in case the values fall below the threshold value or predetermined criteria, the platform may generate one or more solutions based on better alternatives (605), like analyzing historical data to identify better alternative plans and task allocation strategies.”); and
initiating execution of a self-assigned task corresponding to the selected self-assigned task definition at the mobile robot (see at least [0090]: “In one embodiment, the plan execution engine executing the deployed plan retrieves the data corresponding to the exposed variables of the new plan based on the mapping of the deployed plan and the new plan. Finally, based on the retrieved plan data, the plan execution engine executes the new plan (510). The result of executing the new plan is updated with the sensor and execution data store.”; [0091]: “However, in case the values fall below the threshold value or predetermined criteria, the platform may generate one or more solutions based on better alternatives (605), like analyzing historical data to identify better alternative plans and task allocation strategies. The solution may be to identify successful, popular, or efficient plans and/or task allocation strategies that have successfully worked in the past for the given instance (606). The next step for the DR module may be to verify whether the better alternative plans and task allocation strategies are compatible with the deployed plans and task allocation strategies on the cloud and/or plurality of heterogeneous devices (607). The compatibility check is done using multiple implementations as discussed herein. In case the plans and/or task allocation strategies are not compatible or are a mismatch, then, the DR module goes back to generating additional solutions for identifying the next best set of plans and task allocation strategies (608). In case the compatibility check returns positive, then the deployed plans and deployed task allocation strategies may be updated with the better alternative plans and task allocation strategies (609). The updated plans and task allocation strategies are then deployed on at least cloud and/or plurality of heterogeneous autonomous mobile devices (610).”);
wherein each of the self-assigned tasks corresponding to the self-assigned task definitions is executable by the processor of the mobile robot (see at least [0047]: “The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR), however, in some scenarios, the module 102 may decide that since the processing requires heavy computational load (e.g. warehouse map creation while navigating or route map analysis and generation) and hence, incurs heavy cost for the execution engines, in such scenarios, the decision is taken by the DR module 102 in collaboration with the plan execution engine 103a running on the cloud 104a or collaboratively between DR module 102 and one or more of execution engines 103a, 103b, 103c, 103d running on cloud 104a and the AMRs 104b, 104c, and 104d.”).
Sharma fails to explicitly teach wherein each of the self-assigned tasks is independently executable by the processor of the mobile robot where no task is assigned to the mobile robot by the central server.
However, Borne-Pons teaches a method and system for performing robotic tasks wherein each of a self-assigned tasks is independently executable by a processor of a mobile robot (see at least Fig. 2 and [0024]: “As shown in FIG. 2, the robot 200 (i.e., each of the robots included in the fleet of robots 110) may include one or more processors 210, a memory 220, one or more sensors 230, a motion and propulsion control system 240, and one or more input output (I/O) devices 250.”) where no task is assigned to the mobile robot by a central server (see at least Fig. 1 and [0037]: “In an aspect, the electronic device 160 may provide a graphical user interface that enables the user to configure the set of tasks, such as to create the initial tasks included in the set of tasks, configure the tasks specifications for each task, or other task initialization operations. In an aspect, the set of tasks created by the user may be stored in a database, such as the one or more databases 130 of FIG. 1…In such instances, the fleet of robots 110 may receive the initial set of tasks via the one or more networks 140.”; [0053]: “In some aspects the fleet of robots 110 may be configured to perform idle functions that may not require worker appointment or supervision. The particular idle functions each robot performs may be configured on a per-use case basis. The idle functions may include tasks that are useful to the system and may allow every robot to contribute to the efficient operation of the system 100 when they do not have a supervised task to perform. As an example, a robot may be configured to perform communication relay tasks when idle. The communication relay tasks may include using peer-to-peer or other communication techniques to expand the communication capabilities of the fleet of robots 110. For example, it may be known that a particular location at the site of interest 150 has particularly bad communication coverage and so an idle robot may be configured to travel to the particular location (or an edge of the particular location) and monitor for transmissions that may then be received by the idle robot and retransmitted (e.g., via a broadcast or other transmission technique) in order to allow robots operating within locations having poor communication coverage to communicate with remote robots operating at the site of interest 150. It is noted that the exemplary idle tasks described above have been provided for purposes of illustration, rather than by way of limitation and that robots of embodiments may be configured to perform additional idle tasks designed to provide utility to the system 100. Additionally, the fleet of robots 110 may be configured with a recovery mode behavior that the robots are to perform in case a robot becomes disconnected from the rest of the fleet for a prolonged period of time. For example, the recovery mode behavior may specify that the robots are to return to a particular location when communication is lost from the fleet of robots 110 for the period of time. The location may be the one or more docking stations 118, a location where the robot last had communication with the fleet of robots 110, or another location.”; [0057]: “As shown above, the idle and docking behaviors of the fleet of robots 110 may allow the robots to perform various independent tasks (i.e., tasks that do not require supervision by another robot) to maintain themselves in good working order, deliver information or files generated during performance of tasks, or other types of actions when not assigned to perform tasks….During the robot's idle time or when the robot needs to recharge or refuel, the idle mode or docking behaviors may cause the robot to return to the one or more docking stations 118 in order to provide the point cloud file information to a remote device (e.g., the electronic device 160, the user device 120, the one or more databases 130, another device, or a combination of different devices) or may travel to a location where connectivity to the one or more networks 140 is available so that the information may be provided to the remote device(s).”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma to incorporate the teachings of Borne-Pons and provide a self-assigned tasks that is independently executable by a processor of a mobile robot where no task is assigned to the mobile robot by a central server, with a reasonable expectation of success, in order to allow the robots to perform various independent tasks such as communication relay tasks to expand the communication capabilities of multiple robots [0053].
Regarding claim 2, modified Sharma teaches the limitations of claim 1. Sharma further teaches sending an indication of the selected self-assigned task definition to the central server (see at least [0040]: “The present invention solves a technical problem in the field of updating plans and task allocation strategies by a cloud and/or multiple heterogeneous autonomous robots. The invention addresses the problem of decision making while the multiple autonomous robots are navigating and provides alternative relevant plans and task allocation strategies for execution based on at least one or more factors like customized plan, platform, task allocation strategy variables, for example, navigation time, pick time, maximum robots per task, maximum robots in a fleet etc, robot type, capability, role, behavior etc.”; [0054]: “So, post-deployment, in the earlier scenario, when the DR module 102 is notified that the AGV 103c has aligned with trolley or shuttle and acquired a new capability, this gives the DR module 102 an opportunity to raise the performance level of the system. After analyzing the notification, DR module 102 checks the platform, task allocation strategy and/or plan variables that indicates that both the plan and task allocations strategy for AGV 103c needs to be updated as discussed herein. The DR module 102 generates multiple solutions for identifying the relevant plans and tasks to be allocated for aligning with the new capability. After identifying the relevant plans and tasks to be allocated, the DR module 102 deploys them on the AGV 103c.”).
Regarding claim 3, modified Sharma teaches the limitations of claim 1. Sharma further teaches after initiating execution of the selected self-assigned task, and prior to completion of the selected self-assigned task, receiving a task assignment from the central server (see at least [0046]: “The system includes a plurality of heterogeneous AMRs 104b-104n, cloud 104a, a catalog store 101 that includes one or more plans and one or more task allocation strategies for deployment. The cloud maintains two-way communication with the plurality of autonomous mobile robots 104b-104n and the AMRs also communicate with each other through various messaging protocols. The system further comprises a plurality of plan execution engines 103a . . . 103n that are executing on a plurality of AMRs and the cloud. These one or more plan execution engines collaboratively execute the deployed one or more plans and task allocation strategies at the plurality of AMRs 104b . . . 104n based on the instructions received from DR module 102. The DR module 102 may act like a platform manager that coordinates the two-way communication between the execution engines, cloud, devices, catalog store, and the data store.”); and
interrupting execution of the selected self-assigned task (see at least [0057]: “For example, the values in the ‘parameters’ variable indicate the default values or customized values that may be overridden while deploying the task allocation strategy. During deployment, the parameter variable ‘preemptible’ with value ‘True’ indicates whether the application wants the task to be preemptible or not. For example, if a robot is already assigned to a task and there is a better task allocation strategy available, should this robot be preempted or not. For value ‘True’, the robot may be preempted. The parameter variable [‘preemptionThreshold’: 0.2] indicates the threshold at which the robot may be preempted. This variable may ensure that the task allocation strategy does not keep on assigning new tasks by preempting the robots for a minor performance gain.”).
Regarding claim 4, modified Sharma teaches the limitations of claim 3. Sharma further teaches prior to interrupting execution of the selected self-assigned task: determining that a remaining execution time for the selected self-assigned task exceeds a threshold (see at least [0050]: “In one embodiment, the DR module 102 continuously monitors events that may include monitoring or analyzing the platform variable, task allocation strategy variable, and/or plan variables, and on receiving a notification or a trigger, analyzes the notification to check whether the platform, task allocation strategy, and/or plan variables have breached their thresholds and hence, they may warrant updating one or more plans and/or if the notification is related to updating only one or more task allocation strategies deployed to at least one or more of cloud and the heterogeneous robots 103b . . . 103n.”; [0058]: “The next variable to be tracked may be “throughputBreachInterval”: 300 which indicates how long it is fine to breach these values before the DR module looks out for alternatives. So, in one embodiment, if the variables to be tracked are consistently breached for 300 units of time, then, the DR module reacts to the event else there may not be a need for the DR module to take any steps for switching or replacement of the task allocation strategy.”).
Regarding claim 8, modified Sharma teaches the limitations of claim 1. Sharma further teaches wherein each self-assigned task definition identifies a corresponding one of a plurality of subsystems of the mobile robot (see at least [0044]: “In one embodiment, the different plan execution engines may publish or broadcast the state of their corresponding autonomous mobile robots that is subscribed to by the plan execution engine of the other autonomous mobile robots. The communication may be established using communication mechanisms provided by Robot Operating System, Data distribution Service, or using simple UDP proxy, etc.”);
wherein the local activity metric meeting the idle criterion corresponds to one of the subsystems (see at least [0094]: “In one embodiment, after comparison between at least one or more of platform variables, plan variables, task allocation strategy variables and predetermined criteria or defined threshold values (e.g. battery level below 10% of overall battery level of the robot, navigation time within a min and max range, pick time and drop time within a min and max range etc.), the platform may generate solutions based on better alternatives, say for example task allocation strategies, related to either tasks allocated or to be allocated for the device. For example, there may be two tasks—‘sit idle’ and ‘process an order.’ So, according to the task allocation strategy, the robot may have to either work to process the order or sit idle.”); and
wherein selecting the one of the self-assigned task definition includes restricting the selection to self-assigned task definitions identifying the one of the subsystems (see at least [0128]: “The compatibility score may be having a scoring mechanism based on different models. One of the models may be having a range of +1 to 5 or −1 to −5. A positive score indicates the plans are compatible and can be an alternative replacement for an existing plan running on the device. A higher positive score may indicate the platform may have a higher approval rating for the new plan based on plan variables as discussed herein, without limiting to popularity, success rate, effective functioning in similar scenarios etc. A negative score may indicate the incompatibility and also the score may have a higher negative rating for a varied device type, which may indicate that the plan is incompatible as the device type deviates from the general functionality or specifications etc.”).
Regarding claim 9, modified Sharma teaches the limitations of claim 1. Sharma further teaches wherein selecting the one of the self-assigned task definitions from the local repository includes prioritizing the self-assigned task definitions according to at least one of:
(i) a location of the mobile robot (see at least [0047]: “The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR), however, in some scenarios, the module 102 may decide that since the processing requires heavy computational load (e.g. warehouse map creation while navigating or route map analysis and generation) and hence, incurs heavy cost for the execution engines, in such scenarios, the decision is taken by the DR module 102 in collaboration with the plan execution engine 103a running on the cloud 104a or collaboratively between DR module 102 and one or more of execution engines 103a, 103b, 103c, 103d running on cloud 104a and the AMRs 104b, 104c, and 104d.”);
(ii) a predetermined frequency of each self-assigned task (see at least [0059]: “The library may be executed at the desired frequency and the plan execution engine relays the data for the variables back to the DR module.”);
(iii) time periods elapsed since respective previous performances of each self- assigned task (see at least [0040]: “The invention addresses the problem of decision making while the multiple autonomous robots are navigating and provides alternative relevant plans and task allocation strategies for execution based on at least one or more factors like customized plan, platform, task allocation strategy variables, for example, navigation time, pick time, maximum robots per task, maximum robots in a fleet etc, robot type, capability, role, behavior etc.”);
(iv) a priority indicator included in at least one of the self-assigned task definitions (see at least [0097]: “The platform generates multiple solutions that may be applied to ensure high performance and efficiency, for prioritizing the robots based on type of robot e.g. robots can wait in a queue instead of immediately moving for charging or another solution may be specific set of robots of particular type (e.g. forklift) may initially go first for queueing and secondly, the next set of robot (e.g. AGV), and later the remaining set of robots. The other solutions that may be generated may be related to the ordering of robots based on the priority of inventory order (e.g. same day order) or grouping of inventory orders based on the type of robots that can execute the specific group or similarity of inventory orders, capability of robot, for example having additional weight picking capability than others in the fleet etc. This solution related to ordering or prioritizing can change as per the order fulfillment criteria given by the warehouse owner or robotics solution providers or may also be driven by the inventory order itself.”);
(v) expected completion times of the self-assigned task (see at least [0121]: “Mostly, there is no guarantee to find the best solution as some of these are NP-hard problems and hence, given the time frame, the best solution obtained is considered as the chosen solution for considering a plan and/or task allocation strategy by the DR module. So, to find the best solution, in addition to the factors discussed herein, other factors may include cut-off time, what is being expected, how much does a task allocation strategy usually take based on the scale it is targeting, or suppose if max load factor is 100, then, how much is the usual time consumed for task assignment, etc.”);
(vi) a battery charge level of the mobile robot (see at least [0080]: “Consider a scenario, where there may be a plan for charging that includes tasks, like “Go and queue at the charging station for a certain time (e.g. 3 seconds) and dock for charging for a certain time” In this plan, queueing time is a time wherein the forklift/AGVs/AMR or set of AIVIRs are waiting to get to the charging slot for docking. So, in this scenario, the platform may be influenced or plans can be reconfigured to make a decision to go and charge based on the platform variable—“% level of battery.”).
Regarding claim 10, modified Sharma teaches the limitations of claim 1. Sharma further teaches wherein the self-assigned task definitions include at least one of:
(i) a mapping task for a region of a facility in which the mobile robot is deployed (see at least [0047]: “The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR), however, in some scenarios, the module 102 may decide that since the processing requires heavy computational load (e.g. warehouse map creation while navigating or route map analysis and generation) and hence, incurs heavy cost for the execution engines, in such scenarios, the decision is taken by the DR module 102 in collaboration with the plan execution engine 103a running on the cloud 104a or collaboratively between DR module 102 and one or more of execution engines 103a, 103b, 103c, 103d running on cloud 104a and the AMRs 104b, 104c, and 104d.”);
(ii) a calibration task (see at least [0070]: “These plan execution values may be determined at different stages of plan execution as well as in real-time based on a change in the environment or robot's condition. For example, task allocation to robots may be determined at different stages of plan execution or in real time, when any of the autonomous robots assigned to a particular task breaks down and the task has to be reassigned to other robots that have not broken down and are capable to execute the task.”);
(iii) a data processing task (see at least [0030]: “These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable instruction execution apparatus, create a mechanism for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.” [0044]: “One or more plan execution engines 103b, 103c . . . 103n running on the AMRs 104b, 104c, . . . 104n executing the plan and task allocation strategies, updates the sensor and execution data store 106 with any sensor data captured by the robots or execution result of executing an action of the plan and/or task allocation strategies by the plan execution engines running on the robots or the cloud.”); and
(iv) traveling to an area of the facility and generating output indicating that the mobile robot is available for task assignment (see at least [0045]: “Some of the solutions provided by the module 102 may be related to scenarios like managing charging of AMRs in a warehouse—identifying the AMR to be charged first among a set of AMRs or if there are multiple slots, preferring a specific type of AMR that may get a higher priority for a specific slot or in route planning decisions or identifying the robot which is prioritized to get stack of software or software updates, or based on other robot related plan or task allocation strategy variables, for example, ability to rotate in-place, turn in radius, navigation time, charging time etc. The DR module 102 may handle all the primitives, generates the plan—for example charging, navigation, multi-robot coordination tasks, or other tasks like robot waiting queue, narrow aisle turn, complex tasks like deadlock avoidance, obstacle avoidance etc. and provides a generic interface to handle such complex and varying tasks.”).
Regarding claim 11, Sharma teaches a mobile robot (see at least Fig. 1 and [0045]: “In one embodiment, the autonomous mobile robots include processors for executing the instructions and memory for storage.), comprising:
a memory storing a local repository of self-assigned task definitions (see at least [0037]: “A plan execution engine includes a logic for executing a plan, allocating tasks by one or more heterogeneous devices and/or cloud. A plan may include several sub-plans that in combination form the plan. Robot behaviour is a low level atomic activity, within a plan, executed by a robot under certain conditions. For example, a “robot charging” plan may include three states: robot waiting state, robot docking state, and robot charging state.”; [0043]: “In one of the embodiments, a catalog store 101 may include multiple catalogs like Plan catalog 111, Task allocation catalog 112, Agent catalog 113 etc. Task allocation catalog 112 may be used by platforms to retrieve different task allocation strategies, for example, assign order based on shortest distance or assign order based on reducing overall time required to process orders.”; [0045]: “In one embodiment, the autonomous mobile robots include processors for executing the instructions and memory for storage.”);
a locomotive assembly (see at least [0046]: “In one embodiment, the platform may manage dynamic or runtime updation of plans and task allocation strategies on plurality of heterogeneous devices, for example heterogeneous autonomous mobile robots (AMR), like forklifts, AGVs, gripper, pick assist AMR, drones (104b, 104c . . . 104n) etc.”);
a communications interface communicatively connecting the mobile robot with a central server (see at least [0044]: “The DR module 102 is an interface between the plan execution engines 103a . . . 103n and the catalog store 101 and sensor execution data store 106. In one embodiment, sensor and execution data store 106 also receives a constraint solution from the DR module 102 based on the two-way communication with the one or more plan execution engines 103a . . . 103 executing the one or more plans and task allocation strategies.”); and
a processor configured to: determine that a local activity metric associated with tasks assigned to the mobile robot by the central server meets an idle criterion (see at least [0029]: “The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.”; [0043]: “FIG. 1 is a block diagram illustrating a system 100 for dynamically generating solutions for updating plans and task allocation strategies, according to an embodiment. It is understood that the term ‘dynamically’ may include runtime or post-deployment operations or while the autonomous mobile device is in different states, like active or idle in an operating environment.”; [0047]: “In one embodiment, consider a scenario where there are 3 AMRs (104b, 104c, 104d (not shown)) and one of them needs to be charged first. So, it all depends on how the plan ‘charging’ is configured. The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR),…The DR module 102 ensures seamless transition of functionalities between the plan execution engines for optimal performance.”; [0091]: “FIG. 6 is an exemplary flow diagram illustrating process steps for updating plans and task allocation strategies, according to an embodiment. In one embodiment, DR module monitors events happening at the platform level and at the robot level as discussed herein (601). The DR module analyzes and keeps track of the values of all variables of platform, plan, and task allocation strategy that may be tracked (602). These values that are to be tracked may be compared with the predetermined criteria provided at design time or in the plan, and task allocation strategy itself. The predetermined criteria can be customized or defined as per the various factors, for example based on throughput expected in the warehouse, say 100 picks per hour by a Pick assist robot.”);
in response to determining that the local activity metric meets the idle criterion, select one of the self-assigned task definitions from the local repository (see at least [0091]: “The DR module analyzes and keeps track of the values of all variables of platform, plan, and task allocation strategy that may be tracked (602). These values that are to be tracked may be compared with the predetermined criteria provided at design time or in the plan, and task allocation strategy itself. The predetermined criteria can be customized or defined as per the various factors, for example based on throughput expected in the warehouse, say 100 picks per hour by a Pick assist robot. The variables may also be compared with threshold values that may be set based on various factors as discussed herein (603). After comparison between one of the analysed platform variables, task allocation strategy and/or plan variables and a predetermined criteria or pre-defined threshold values, the platform may continue monitoring events or ignore the notification if the variables have values higher than the threshold value or the predetermined criteria (604). However, in case the values fall below the threshold value or predetermined criteria, the platform may generate one or more solutions based on better alternatives (605), like analyzing historical data to identify better alternative plans and task allocation strategies.”); and
initiate execution of a self-assigned task corresponding to the selected self- assigned task definition at the mobile robot (see at least [0090]: “In one embodiment, the plan execution engine executing the deployed plan retrieves the data corresponding to the exposed variables of the new plan based on the mapping of the deployed plan and the new plan. Finally, based on the retrieved plan data, the plan execution engine executes the new plan (510). The result of executing the new plan is updated with the sensor and execution data store.”; [0091]: “However, in case the values fall below the threshold value or predetermined criteria, the platform may generate one or more solutions based on better alternatives (605), like analyzing historical data to identify better alternative plans and task allocation strategies. The solution may be to identify successful, popular, or efficient plans and/or task allocation strategies that have successfully worked in the past for the given instance (606). The next step for the DR module may be to verify whether the better alternative plans and task allocation strategies are compatible with the deployed plans and task allocation strategies on the cloud and/or plurality of heterogeneous devices (607). The compatibility check is done using multiple implementations as discussed herein. In case the plans and/or task allocation strategies are not compatible or are a mismatch, then, the DR module goes back to generating additional solutions for identifying the next best set of plans and task allocation strategies (608). In case the compatibility check returns positive, then the deployed plans and deployed task allocation strategies may be updated with the better alternative plans and task allocation strategies (609). The updated plans and task allocation strategies are then deployed on at least cloud and/or plurality of heterogeneous autonomous mobile devices (610).”)
wherein each of the self-assigned tasks corresponding to the self-assigned task definitions is executable by the processor of the mobile robot (see at least [0047]: “The DR module 102 analyzes the configuration to ensure that whether the plan execution engines 103b, 103c, and 103d (not shown) running on the AMRs 104b, 104c, and 104d respectively can decide amongst themselves, and if that is possible, then the plan execution engines takes the decision on its own (e.g. sending location information of the AMR), however, in some scenarios, the module 102 may decide that since the processing requires heavy computational load (e.g. warehouse map creation while navigating or route map analysis and generation) and hence, incurs heavy cost for the execution engines, in such scenarios, the decision is taken by the DR module 102 in collaboration with the plan execution engine 103a running on the cloud 104a or collaboratively between DR module 102 and one or more of execution engines 103a, 103b, 103c, 103d running on cloud 104a and the AMRs 104b, 104c, and 104d.”).
Sharma fails to explicitly teach wherein each of the self-assigned tasks is independently executable by the processor of the mobile robot where no task is assigned to the mobile robot by the central server.
However, Borne-Pons teaches a method and system for performing robotic tasks wherein each of a self-assigned tasks is independently executable by a processor of a mobile robot (see at least Fig. 2 and [0024]: “As shown in FIG. 2, the robot 200 (i.e., each of the robots included in the fleet of robots 110) may include one or more processors 210, a memory 220, one or more sensors 230, a motion and propulsion control system 240, and one or more input output (I/O) devices 250.”) where no task is assigned to the mobile robot by a central server (see at least Fig. 1 and [0037]: “In an aspect, the electronic device 160 may provide a graphical user interface that enables the user to configure the set of tasks, such as to create the initial tasks included in the set of tasks, configure the tasks specifications for each task, or other task initialization operations. In an aspect, the set of tasks created by the user may be stored in a database, such as the one or more databases 130 of FIG. 1…In such instances, the fleet of robots 110 may receive the initial set of tasks via the one or more networks 140.”; [0053]: “In some aspects the fleet of robots 110 may be configured to perform idle functions that may not require worker appointment or supervision. The particular idle functions each robot performs may be configured on a per-use case basis. The idle functions may include tasks that are useful to the system and may allow every robot to contribute to the efficient operation of the system 100 when they do not have a supervised task to perform. As an example, a robot may be configured to perform communication relay tasks when idle. The communication relay tasks may include using peer-to-peer or other communication techniques to expand the communication capabilities of the fleet of robots 110. For example, it may be known that a particular location at the site of interest 150 has particularly bad communication coverage and so an idle robot may be configured to travel to the particular location (or an edge of the particular location) and monitor for transmissions that may then be received by the idle robot and retransmitted (e.g., via a broadcast or other transmission technique) in order to allow robots operating within locations having poor communication coverage to communicate with remote robots operating at the site of interest 150. It is noted that the exemplary idle tasks described above have been provided for purposes of illustration, rather than by way of limitation and that robots of embodiments may be configured to perform additional idle tasks designed to provide utility to the system 100. Additionally, the fleet of robots 110 may be configured with a recovery mode behavior that the robots are to perform in case a robot becomes disconnected from the rest of the fleet for a prolonged period of time. For example, the recovery mode behavior may specify that the robots are to return to a particular location when communication is lost from the fleet of robots 110 for the period of time. The location may be the one or more docking stations 118, a location where the robot last had communication with the fleet of robots 110, or another location.”; [0057]: “As shown above, the idle and docking behaviors of the fleet of robots 110 may allow the robots to perform various independent tasks (i.e., tasks that do not require supervision by another robot) to maintain themselves in good working order, deliver information or files generated during performance of tasks, or other types of actions when not assigned to perform tasks….During the robot's idle time or when the robot needs to recharge or refuel, the idle mode or docking behaviors may cause the robot to return to the one or more docking stations 118 in order to provide the point cloud file information to a remote device (e.g., the electronic device 160, the user device 120, the one or more databases 130, another device, or a combination of different devices) or may travel to a location where connectivity to the one or more networks 140 is available so that the information may be provided to the remote device(s).”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma to incorporate the teachings of Borne-Pons and provide a self-assigned tasks that is independently executable by a processor of a mobile robot where no task is assigned to the mobile robot by a central server, with a reasonable expectation of success, in order to allow the robots to perform various independent tasks such as communication relay tasks to expand the communication capabilities of multiple robots [0053].
Regarding claim 12, modified Sharma teaches the limitations of claim 11. Sharma further teaches wherein the processor is further configured to: send an indication of the selected self-assigned task to the central server (see at least [0040]: “The present invention solves a technical problem in the field of updating plans and task allocation strategies by a cloud and/or multiple heterogeneous autonomous robots. The invention addresses the problem of decision making while the multiple autonomous robots are navigating and provides alternative relevant plans and task allocation strategies for execution based on at least one or more factors like customized plan, platform, task allocation strategy variables, for example, navigation time, pick time, maximum robots per task, maximum robots in a fleet etc, robot type, capability, role, behavior etc.”; [0054]: “So, post-deployment, in the earlier scenario, when the DR module 102 is notified that the AGV 103c has aligned with trolley or shuttle and acquired a new capability, this gives the DR module 102 an opportunity to raise the performance level of the system. After analyzing the notification, DR module 102 checks the platform, task allocation strategy and/or plan variables that indicates that both the plan and task allocations strategy for AGV 103c needs to be updated as discussed herein. The DR module 102 generates multiple solutions for identifying the relevant plans and tasks to be allocated for aligning with the new capability. After identifying the relevant plans and tasks to be allocated, the DR module 102 deploys them on the AGV 103c.”).
Regarding claim 13, modified Sharma teaches the limitations of claim 11. Sharma further teaches wherein the processor is further configured to: after initiating execution of the selected self-assigned task, and prior to completion of the selected self-assigned task, receive a task assignment from the central server (see at least [0046]: “The system includes a plurality of heterogeneous AMRs 104b-104n, cloud 104a, a catalog store 101 that includes one or more plans and one or more task allocation strategies for deployment. The cloud maintains two-way communication with the plurality of autonomous mobile robots 104b-104n and the AMRs also communicate with each other through various messaging protocols. The system further comprises a plurality of plan execution engines 103a . . . 103n that are executing on a plurality of AMRs and the cloud. These one or more plan execution engines collaboratively execute the deployed one or more plans and task allocation strategies at the plurality of AMRs 104b . . . 104n based on the instructions received from DR module 102. The DR module 102 may act like a platform manager that coordinates the two-way communication between the execution engines, cloud, devices, catalog store, and the data store.”); and
interrupt execution of the selected self-assigned task (see at least [0057]: “For example, the values in the ‘parameters’ variable indicate the default values or customized values that may be overridden while deploying the task allocation strategy. During deployment, the parameter variable ‘preemptible’ with value ‘True’ indicates whether the application wants the task to be preemptible or not. For example, if a robot is already assigned to a task and there is a better task allocation strategy available, should this robot be preempted or not. For value ‘True’, the robot may be preempted. The parameter variable [‘preemptionThreshold’: 0.2] indicates the threshold at which the robot may be preempted. This variable may ensure that the task allocation strategy does not keep on assigning new tasks by preempting the robots for a minor performance gain.”).
Regarding claim 14, modified Sharma teaches the limitations of claim 13. Sharma further teaches wherein the processor is further configured, prior to interrupting execution of the selected self-assigned task, to: determine that a remaining execution time for the selected self-assigned task exceeds a threshold (see at least [0050]: “In one embodiment, the DR module 102 continuously monitors events that may include monitoring or analyzing the platform variable, task allocation strategy variable, and/or plan variables, and on receiving a notification or a trigger, analyzes the notification to check whether the platform, task allocation strategy, and/or plan variables have breached their thresholds and hence, they may warrant updating one or more plans and/or if the notification is related to updating only one or more task allocation strategies deployed to at least one or more of cloud and the heterogeneous robots 103b . . . 103n.”; [0058]: “The next variable to be tracked may be “throughputBreachInterval”: 300 which indicates how long it is fine to breach these values before the DR module looks out for alternatives. So, in one embodiment, if the variables to be tracked are consistently breached for 300 units of time, then, the DR module reacts to the event else there may not be a need for the DR module to take any steps for switching or replacement of the task allocation strategy.”).
Regarding claim 18, modified Sharma teaches the limitations of claim 11. Sharma fu