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 .
Status of Claims
This is in response to applicant’s filing date of September 24, 2024. Claims 1-20 are currently pending.
Priority
Acknowledgment is made of applicant’s claim for foreign priority to Application KR10-2024-0024087, filed on February 20, 2024. The certified copy of the application as required by 37 CFR 1.55 has been received.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on September 24, 2024, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: a robot data collecting unit; a charged state monitoring unit; a charging management unit; a task distribution command unit; robot operating unit in claims 1-10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Abhishek SHARMA (US-20220048186-A1)(“Sharma”) and Wakitani et al (US-20240295886-A1)(“Wakitani”).
As per claim 1, Sharma discloses an apparatus for managing a battery of a robot , the apparatus comprising:
a robot data collecting unit, implemented using one or more computing devices, configured to periodically collect data related to an operation of the robot (Sharma at Figure 2, cloud management system 202 in communication with mobile robots 214 & 216, and Para. [0067] discloses a remote device (server) for receiving sensor and execution data from managed robots:” cloud device management system 202 also includes a deployment and runtime (DR) module 212 that manages communication between the cloud device management system 202 and robots 214 and 216. In one embodiment, the DR module 212 includes a message broker 218 that receives sensor data and execution data from the robots 214 and 216. The robots 214 and 216 may include a communicator 220 and 222, respectively, which establishes a two-way communication with the message broker 218.”);
a charged state monitoring unit, implemented using one or more computing devices, configured to periodically monitor a charged state of the battery of the robot based on the collected data related to the operation of the robot (Sharma at Figure 2, deployment and runtime (DR) module 212 and plan execution engine 224, and Para. [0097] discloses monitoring the charge level of a robot’s battery to determine if the task plan needs to be altered based on a predetermined charge level (threshold):” After the plans and relevant task allocation strategies are deployed on AMRs, the DR module may be triggered or notified for events relating to a specific problem on an AMR or set of AMRs whose battery level is falling below the predetermined threshold, say 60% of battery life. The platform always has a global view of the entire fleet of AMRs and hence, the platform makes decisions dynamically on whether a specific or set of AMRs need to go for charging.”);
; and
a task distribution command unit (Sharma at Figure 1, task allocation catalog module 112, and Para. [0043] disclosing the various factors to allocate a task to one of a plurality of robots:” 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.”), implemented using one or more computing devices, configured to generate, based on the collected data and the charged state, a distribution command signal related to a remaining task to be transmitted to the robot (Sharma at Figure 2, plan execution engines 224 – 228, and Para. [0097] discloses allocating the mobile robots to task remaining to be performed based on the received data from the robots:” the set of tasks that need to be allocated are identified from the new set of plans and then allocated on the fleet of AMRs. The platform may consider additional factors like inventory order priority that the robot is handling, robots that process high priority order to be charged first, congestion or obstacle avoidance, coordination with other robots in the team or fleet etc. The invention is not limited to these embodiments and the scope is broad to include other scenarios that enable the platform to identify relevant solutions for updating one or more plans and task allocation strategies for getting the required optimal results.”).
While Sharma discloses monitoring the battery level of a robot and also the monitoring how a robot is down because of a charging process. See Para. [0103] where Sharma discloses the tracking of “how much time is spent by a robot in a state called ‘charging’. So, the warehouse owner may be interested in the time spent in charging the robot may translate to the system downtime.”
Sharma does not explicitly disclose but Wakitani discloses a charging management unit, implemented using one or more computing devices, configured to generate, based on the collected data and the charged state, a battery charge command signal to be transmitted to the robot (Wakitani at Figure 4, battery amount at each robot (S30) and manage battery charge based on task and the like (S34), and Paras . [0050]-[0054], battery management, and specifically Para. [0052] disclosing selecting robot charging based on battery level and task to be performed:” when there is a plurality of first mobile robots 61 each having a battery remaining amount equal to or less than the lower limit level, the first robot management unit 11 determines the priority of the first mobile robots 61 for replacement or charging of the battery to be executed, based on the battery remaining amount and the kind of the task of each first mobile robot 61.”)
Wakitani is considered to be analogous to the claimed invention because it is in the same field of systems which manages task assignments and batteries of mobile robots. 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 further in view of Wakitani to allow for managing a robot’s battery and then assigning task that need to be performed based on the charged state of the robot’s battery. Motivation to do so would allow for reducing negative effects of service time by mitigating disruptions due to reduction in charge level of robots and to thereby more efficiently manage execution of tasks involving movement in a wide range by the mobile robots (Wakitani at Para. [0017]).
As per claim 2, Sharma and Wakitani disclose the apparatus of claim 1, wherein the robot data collecting unit is configured to collect (i) first data related to the battery of the robot from a robot battery operation database (Sharma at Figure 2 and Para. [0097] the deployment module is notified of the robot’s battery level through communication channel:” the plans and relevant task allocation strategies are deployed on AMRs, the DR module may be triggered or notified for events relating to a specific problem on an AMR or set of AMRs whose battery level is falling below the predetermined threshold, say 60% of battery life. The platform always has a global view of the entire fleet of AMRs and hence, the platform makes decisions dynamically on whether a specific or set of AMRs need to go for charging.”) and (ii) second data related to a task of the robot from a robot operating unit (Sharma ta Para. [0097] discloses the task allocated to each mobile robot is performed by the deployment and runtime module 212:” an alternative or set of alternative plans and one or more task allocation strategies are applied to replace the current plan or set of plans to ensure the specific AMR or set of AMRs may go for charging. Similarly, the set of tasks that need to be allocated are identified from the new set of plans and then allocated on the fleet of AMRs.”).
As per claim 3, Sharma and Wakitani disclose the apparatus of claim 2, wherein:
the first data comprises a battery amount to be consumed when the robot moves, a battery amount consumed for the task, and a required battery amount for the task (Sharma at Para. [0115] discloses that various variables are considered such as task and how they relate to the battery level:” the platform may identify the optimal solution based on comparison between one of the platform, plan, and task allocation strategy variables and predetermined criteria or threshold values. The platform may also consider historical platform variables and customer defined platform variables as discussed herein. The platform may ensure that alternative plans are identified to counter the thresholds which may or may not have been met. for e.g. the battery charging baseline plan variable may be 10% of the overall battery level.”); and
the second data comprises a task amount assigned to the robot (Sharma at Para. [0081] the payload capacity of a robot:” aware that the fleet of robots has an expanded payload capacity”.), an expected task time (Sharma at Para. [0094] discloses using expected task time as a variable for creating a plan:” 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.”), and a task peak time (Sharma at Para. [0097] discloses using different priority rules for allocation including peak time like same day orders and the like:” 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.”).
As per claim 4, Sharma and Wakitani disclose the apparatus of claim 3, wherein the robot data collecting unit is configured to collect data comprising (i) a distance from a position of the robot at time of completing the task to a charging station and (ii) a required battery amount for the robot to move from the position to the charging station (Sharma at Para. [0119] disclose using “assign tasks based on minimizing the distance to be travelled”; and in Para. [0104] a plan that when the battery is below a certain threshold commands a charging of the robot:” battery level is in ‘critical’ state, then update the task to ‘queue for charging’”.).
As per claim 5, Sharma and Wakitani disclose the apparatus of claim 4, wherein the charged state monitoring unit is configured to, based on the first data and the second data: determine the charged state as a first charged state based on a determination that the charged state is not sufficient for performing a currently assigned task and immediate charging is necessary (Sharma at Paras [0104]-[0105] discloses causing the robot to recharge if the level falls below a critical point:” a scenario where the charging plan was built on a task allocation strategy that when the battery level crosses a particular threshold (10% of overall battery charge), then the state may be ‘critical’ and the robot may be enforced to go and stand in a queue to charge. Another scenario may be when the battery level is “not critical” and also, the workload in the warehouse is minimal. The various solutions generated for making a charging decision may be as given below: [0105] a) If the battery level is in ‘critical’ state, then update the task to ‘queue for charging’”.);
determine the charged state as a second charged state based on a determination that the charged state is sufficient for completing the currently assigned task but not sufficient until task peak time is completed (Sharma at Para. [0109] discloses a scenario where the robot continues on the task if above a critical level:” generated for platform to choose whenever a circumstance related to the scenario of ‘charging’ arises, wherein the client may like the robots to continue working in the warehouse till the battery crosses the threshold level or critical stage.”); and
determine the charged state as a third charged state based on a determination that the charged state is sufficient until the task peak time is completed (Sharma at Para. [0108] the plan to charge a robot can be set based workload like low, medium, and high workloads:” based on the workload (low, medium or high), the platform decides which robot may go and charge. This strategy may include type and make of robot (e.g. forklift model vs AGV model) etc.”).
As per claim 6, Sharma and Wakitani disclose the apparatus of claim 5, wherein the charged state monitoring unit is configured to, based on a value obtained by subtracting a first battery amount required for the remaining task assigned to the robot (Sharma at Para. [0106] discloses causing charging of the robot during low workload:” If the workload is minimal and the battery level is not in a ‘critical’ state, charging task may be augmented as ‘Yes’, and if the battery level reaches ‘critical’ state, then the robot's task may be updated to ‘queue and charge’”.) and a second battery amount required for an additional task expected until the task peak time from a current battery state of charge is greater than a third battery amount required for the robot to move to the charging station farthest from the position at the time of completing the task by a predetermined level, determine the charged state as the third charged state (Sharma at Para. [0094] discloses using a robot with a second battery level (higher) for a task where distance is a factor:” the solution that may be applied may consider the forklift having higher battery level to process the order. So, here the solution includes a higher affinity factor towards that robot that has a higher battery level to perform the task of processing the order. So, accordingly, the relevant one or more plans and task allocation strategies may be deployed and related tasks may be allocated considering the affinity factor.”).
As per claim 7, Sharma and Wakitani disclose the apparatus of claim 5, wherein the charging management unit is configured to:
based on the charged state of the robot being the first charged state, terminate the operation of robot and generate a first charging command signal for immediately charging the robot (Sharma at Para. [0105] commanding the robot to go into a charging state based on a critical level:” If the battery level is in ‘critical’ state, then update the task to ‘queue for charging’”);
based on the charged state of the robot being determined as the second charged state, generate a second charging command signal for charging the robot after completing the currently assigned task (Sharma at Para. [0107] disclosing causing the robot even if not low because the remaining tasks are minimal:” update the task to push for proactive charging. So, even if the battery level is not in a ‘critical’ state (say battery level below 10%), but the workload in the warehouse is low, then, the system doesn't foresee more tasks coming in. In such scenario, the tasks may be update to ‘robots may still go ahead and queue for charging’ “.) ; and
based on the charged state of the robot being determined as the third charged state, generate a third charge command signal for terminating the operation of the robot and charging the robot after the task peak time is finished (Sharma at Para. [0080] discloses various charge level states for the robot to issue a charging command:” 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.” So, in a generic way, the platform, or specifically the DR module, tracks the platform variable “system downtime” and one of the generated solutions may be related to the scenario, when the battery level falls below a predetermined threshold—say 65% level of battery, then the existing plans can be replaced by new plans and existing task allocation strategies by new task allocation strategies to enforce the robots to go and queue for charging for a certain period of time and then, later dock for charging for certain period of time”.).
As per claim 8, Sharma and Wakitani disclose the apparatus of claim 5, wherein the task distribution command unit is configured to detect at least one robot having the third charged state, and generate the distribution command signal for distributing the remaining task that is not processed among tasks assigned to other robots that currently need to be charged, to a first robot having a highest state of charge among the detected at least one robot (Sharma at Para. [0048] discloses dynamically changing the task allocation when the charge state is below a certain threshold:” the DR module 102 gets notified that the platform or plan or task allocation strategy variables that are being tracked for robot 104b or for the system, have breached the threshold values (e.g. battery level below 10% of total battery) and also, performance values (number of picks (80 picks) of pick assist AMR is less than the predetermined criteria of 100 picks/hr) is not within the threshold range of values. So, after being notified, the DR 102 module then has to identify an alternative navigating plan(s) and task allocation strategies from the set of navigation plans in the plan catalog 111.”).
As per claim 9, Sharma and Wakitani disclose the apparatus of claim 8, wherein the task distribution command unit is configured to call a second robot having a highest state of charge among robots that are currently being charged and satisfying a preset state of charge (Sharma at Para. [0094] discloses assigning task to a mobile robot with a higher charge/battery level:” solution that may be applied may consider the forklift having higher battery level to process the order.”), and, based on the at least one robot having the third charged state not being detected, generate the distribution command signal for distributing the remaining task to the called second robot (Sharma at Para. [0097] discloses prioritizing the assignment of robots which include second/unassigned robots:” 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.”).
As per claim 10, Sharma and Wakitani disclose the apparatus of claim 1, wherein the charging management unit is configured to, based on an operation-terminated state being announced with respect to the robot having completed the task (Sharma at Para. [0108] the plan to charge a robot can be set based workload like low, medium, and high workloads:” based on the workload (low, medium or high), the platform decides which robot may go and charge. This strategy may include type and make of robot (e.g. forklift model vs AGV model) etc.”), generate the charge command signal for moving to and charging at a charging station capable of charging at a shortest distance regardless of the charged state (Wakitani at Para. [0027] discloses a first and second area of operations for the mobile robots:” wide area task of delivering a parcel from the first area A1 to the second area A2 accepted by the delivery management system 400”; Additionally, each area has a charging station (102, 104) so the closet charging station is in its respective area and thus the shortest distance:” a battery station 102 equipped with a charger 103 is installed. Similarly, in the second store 200, a spare battery 204 for replacement is accommodated, and a battery station 202 equipped with a charger 203 is installed.” At Para. [0030].).
As per claim 11, Sharma discloses a method for managing a battery of a robot, comprising:
periodically collecting data related to an operation of the robot (Sharma at Figure 2, cloud management system 202 in communication with mobile robots 214 & 216, and Para. [0067] discloses a remote device (server) for receiving sensor and execution data from managed robots:” cloud device management system 202 also includes a deployment and runtime (DR) module 212 that manages communication between the cloud device management system 202 and robots 214 and 216. In one embodiment, the DR module 212 includes a message broker 218 that receives sensor data and execution data from the robots 214 and 216. The robots 214 and 216 may include a communicator 220 and 222, respectively, which establishes a two-way communication with the message broker 218.”);
periodically monitoring a charged state of the battery of the robot based on the collected data related to the operation of the robot (Sharma at Figure 2, deployment and runtime (DR) module 212 and plan execution engine 224, and Para. [0097] discloses monitoring the charge level of a robot’s battery to determine if the task plan needs to be altered based on a predetermined charge level (threshold):” After the plans and relevant task allocation strategies are deployed on AMRs, the DR module may be triggered or notified for events relating to a specific problem on an AMR or set of AMRs whose battery level is falling below the predetermined threshold, say 60% of battery life. The platform always has a global view of the entire fleet of AMRs and hence, the platform makes decisions dynamically on whether a specific or set of AMRs need to go for charging.”);
; and
generating, based on the collected data and the charged state, a distribution command signal related to a remaining task to be transmitted to the robot (Sharma at Figure 2, plan execution engines 224 – 228, and Para. [0097] discloses allocating the mobile robots to task remaining to be performed based on the received data from the robots:” the set of tasks that need to be allocated are identified from the new set of plans and then allocated on the fleet of AMRs. The platform may consider additional factors like inventory order priority that the robot is handling, robots that process high priority order to be charged first, congestion or obstacle avoidance, coordination with other robots in the team or fleet etc. The invention is not limited to these embodiments and the scope is broad to include other scenarios that enable the platform to identify relevant solutions for updating one or more plans and task allocation strategies for getting the required optimal results.”).
While Sharma discloses monitoring the battery level of a robot and also the monitoring how a robot is down because of a charging process. See Para. [0103] where Sharma discloses the tracking of “how much time is spent by a robot in a state called ‘charging’. So, the warehouse owner may be interested in the time spent in charging the robot may translate to the system downtime.”
Sharma does not explicitly disclose but Wakitani discloses generating, based on the collected data and the charged state, a battery charge command signal to be transmitted to the robot based on the collected data and the charged state (Wakitani at Figure 4, battery amount at each robot (S30) and manage battery charge based on task and the like (S34), and Paras . [0050]-[0054], battery management, and specifically Para. [0052] disclosing selecting robot charging based on battery level and task to be performed:” when there is a plurality of first mobile robots 61 each having a battery remaining amount equal to or less than the lower limit level, the first robot management unit 11 determines the priority of the first mobile robots 61 for replacement or charging of the battery to be executed, based on the battery remaining amount and the kind of the task of each first mobile robot 61.”)
Wakitani is considered to be analogous to the claimed invention because it is in the same field of systems which manages task assignments and batteries of mobile robots. 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 further in view of Wakitani to allow for managing a robot’s battery and then assigning task that need to be performed based on the charged state of the robot’s battery. Motivation to do so would allow for reducing negative effects of service time by mitigating disruptions due to reduction in charge level of robots and to thereby more efficiently manage execution of tasks involving movement in a wide range by the mobile robots (Wakitani at Para. [0017]).
As per claim 12, Sharma and Wakitani disclose a method of claim 11, wherein collecting the data comprises: collecting (i) first data related to the battery of the robot from a robot battery operation database (Sharma at Figure 2 and Para. [0097] the deployment module is notified of the robot’s battery level through communication channel:” the plans and relevant task allocation strategies are deployed on AMRs, the DR module may be triggered or notified for events relating to a specific problem on an AMR or set of AMRs whose battery level is falling below the predetermined threshold, say 60% of battery life. The platform always has a global view of the entire fleet of AMRs and hence, the platform makes decisions dynamically on whether a specific or set of AMRs need to go for charging.”) and (ii) second data related to a task of the robot from a robot operating unit (Sharma ta Para. [0097] discloses the task allocated to each mobile robot is performed by the deployment and runtime module 212:” an alternative or set of alternative plans and one or more task allocation strategies are applied to replace the current plan or set of plans to ensure the specific AMR or set of AMRs may go for charging. Similarly, the set of tasks that need to be allocated are identified from the new set of plans and then allocated on the fleet of AMRs.”).
As per claim 13, Sharma and Wakitani disclose a method of claim 12, wherein:
the first data comprises a battery amount to be consumed when the robot moves, a battery amount consumed for the task, and a required battery amount for the task (Sharma at Para. [0115] discloses that various variables are considered such as task and how they relate to the battery level:” the platform may identify the optimal solution based on comparison between one of the platform, plan, and task allocation strategy variables and predetermined criteria or threshold values. The platform may also consider historical platform variables and customer defined platform variables as discussed herein. The platform may ensure that alternative plans are identified to counter the thresholds which may or may not have been met. for e.g. the battery charging baseline plan variable may be 10% of the overall battery level.”); and
the second data comprises a task amount assigned to the robot (Sharma at Para. [0081] the payload capacity of a robot:” aware that the fleet of robots has an expanded payload capacity”.), an expected task time (Sharma at Para. [0094] discloses using expected task time as a variable for creating a plan:” 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.”), and a task peak time (Sharma at Para. [0097] discloses using different priority rules for allocation including peak time like same day orders and the like:” 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.”).
As per claim 14, Sharma and Wakitani disclose a method of claim 13, wherein the robot data collecting unit is configured to collect data comprising (i) a distance from a position of the robot at time of completing the task to a charging station and (ii) a required battery amount for the robot to move from the position to the charging station (Sharma at Para. [0119] disclose using “assign tasks based on minimizing the distance to be travelled”; and in Para. [0104] a plan that when the battery is below a certain threshold commands a charging of the robot:” battery level is in ‘critical’ state, then update the task to ‘queue for charging’”.).
As per claim 15, Sharma and Wakitani disclose a method of claim 14, wherein monitoring the charged state comprises, based on the first data and the second data:
determine the charged state as a first charged state based on a determination that the charged state is not sufficient for performing a currently assigned task and immediate charging is necessary (Sharma at Paras [0104]-[0105] discloses causing the robot to recharge if the level falls below a critical point:” a scenario where the charging plan was built on a task allocation strategy that when the battery level crosses a particular threshold (10% of overall battery charge), then the state may be ‘critical’ and the robot may be enforced to go and stand in a queue to charge. Another scenario may be when the battery level is “not critical” and also, the workload in the warehouse is minimal. The various solutions generated for making a charging decision may be as given below: [0105] a) If the battery level is in ‘critical’ state, then update the task to ‘queue for charging’”.);
determine the charged state as a second charged state based on a determination that the charged state is sufficient for completing the currently assigned task but not sufficient until task peak time is completed (Sharma at Para. [0109] discloses a scenario where the robot continues on the task if above a critical level:” generated for platform to choose whenever a circumstance related to the scenario of ‘charging’ arises, wherein the client may like the robots to continue working in the warehouse till the battery crosses the threshold level or critical stage.”); and
determine the charged state as a third charged state based on a determination that the charged state is sufficient until the task peak time is completed (Sharma at Para. [0108] the plan to charge a robot can be set based workload like low, medium, and high workloads:” based on the workload (low, medium or high), the platform decides which robot may go and charge. This strategy may include type and make of robot (e.g. forklift model vs AGV model) etc.”).
As per claim 16, Sharma and Wakitani disclose a method of claim 15, wherein the monitoring the charged state further comprises:
based on a value obtained by subtracting a first battery amount required for the remaining task assigned to the robot (Sharma at Para. [0106] discloses causing charging of the robot during low workload:” If the workload is minimal and the battery level is not in a ‘critical’ state, charging task may be augmented as ‘Yes’, and if the battery level reaches ‘critical’ state, then the robot's task may be updated to ‘queue and charge’”.) and a second battery amount required for an additional task expected until the task peak time from a current battery state of charge is greater than a third battery amount required for the robot to move to the charging station farthest from the position at the time of completing the task by a predetermined level, determine the charged state as the third charged state (Sharma at Para. [0094] discloses using a robot with a second battery level (higher) for a task where distance is a factor:” the solution that may be applied may consider the forklift having higher battery level to process the order. So, here the solution includes a higher affinity factor towards that robot that has a higher battery level to perform the task of processing the order. So, accordingly, the relevant one or more plans and task allocation strategies may be deployed and related tasks may be allocated considering the affinity factor.”).
As per claim 17, Sharma and Wakitani disclose a method of claim 15, wherein generating the battery charge command signal to be transmitted to the robot comprises:
based on the charged state of the robot being the first charged state, terminate the operation of robot and generate a first charging command signal for immediately charging the robot (Sharma at Para. [0105] commanding the robot to go into a charging state based on a critical level:” If the battery level is in ‘critical’ state, then update the task to ‘queue for charging’”);
based on the charged state of the robot being determined as the second charged state, generate a second charging command signal for charging the robot after completing the currently assigned task (Sharma at Para. [0107] disclosing causing the robot even if not low because the remaining tasks are minimal:” update the task to push for proactive charging. So, even if the battery level is not in a ‘critical’ state (say battery level below 10%), but the workload in the warehouse is low, then, the system doesn't foresee more tasks coming in. In such scenario, the tasks may be update to ‘robots may still go ahead and queue for charging’ “.) ; and
based on the charged state of the robot being determined as the third charged state, generate a third charge command signal for terminating the operation of the robot and charging the robot after the task peak time is finished (Sharma at Para. [0080] discloses various charge level states for the robot to issue a charging command:” 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.” So, in a generic way, the platform, or specifically the DR module, tracks the platform variable “system downtime” and one of the generated solutions may be related to the scenario, when the battery level falls below a predetermined threshold—say 65% level of battery, then the existing plans can be replaced by new plans and existing task allocation strategies by new task allocation strategies to enforce the robots to go and queue for charging for a certain period of time and then, later dock for charging for certain period of time”.).
As per claim 18, Sharma and Wakitani disclose a method of claim 15, wherein the task distribution command unit is configured to detect at least one robot having the third charged state, and generate the distribution command signal for distributing the remaining task that is not processed among tasks assigned to other robots that currently need to be charged, to a first robot having a highest state of charge among the detected at least one robot (Sharma at Para. [0048] discloses dynamically changing the task allocation when the charge state is below a certain threshold:” the DR module 102 gets notified that the platform or plan or task allocation strategy variables that are being tracked for robot 104b or for the system, have breached the threshold values (e.g. battery level below 10% of total battery) and also, performance values (number of picks (80 picks) of pick assist AMR is less than the predetermined criteria of 100 picks/hr) is not within the threshold range of values. So, after being notified, the DR 102 module then has to identify an alternative navigating plan(s) and task allocation strategies from the set of navigation plans in the plan catalog 111.”).
As per claim 19, Sharma and Wakitani disclose a method of claim 18, wherein generating the distribution command signal with respect to the remaining task further comprises, based on the at least one robot having the third charged state not being detected(Sharma at Para. [0094] discloses assigning task to a mobile robot with a higher charge/battery level:” solution that may be applied may consider the forklift having higher battery level to process the order.”):
calling a second robot having a highest state of charge among robots that are currently being charged and satisfying a preset state of charge and generating the distribution command signal for distributing the remaining task to the called second robot (Sharma at Para. [0097] discloses prioritizing the assignment of robots which include second/unassigned robots:” 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.”). .
As per claim 20, Sharma and Wakitani disclose a method of claim 11, wherein the charging management unit is configured to, based on an operation-terminated state being announced with respect to the robot having completed the task (Sharma at Para. [0108] the plan to charge a robot can be set based workload like low, medium, and high workloads:” based on the workload (low, medium or high), the platform decides which robot may go and charge. This strategy may include type and make of robot (e.g. forklift model vs AGV model) etc.”), generate the charge command signal for moving to and charging at a charging station capable of charging at a shortest distance regardless of the charged state (Wakitani at Para. [0027] discloses a first and second area of operations for the mobile robots:” wide area task of delivering a parcel from the first area A1 to the second area A2 accepted by the delivery management system 400”; Additionally, each area has a charging station (102, 104) so the closet charging station is in its respective area and thus the shortest distance:” a battery station 102 equipped with a charger 103 is installed. Similarly, in the second store 200, a spare battery 204 for replacement is accommodated, and a battery station 202 equipped with a charger 203 is installed.” At Para. [0030].).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tsuno et al (US-12566460-B2) discloses a management device that manages operations of the autonomous mobile machines and wherein a processor determines whether a residual capacity of a battery of the first mobile machine is less than a predetermined capacity, and specifies a second mobile machine that is not scheduled to operate during a remaining period of the specific period when the residual capacity is less than the predetermined capacity. Figure 1.
EUN S CHOI (WO-2025127283-A1) discloses at least one server or system that controls a plurality of robots that load and move a shipment, and more particularly, to a server or system that allocates robots for each picking zone for effective loading (picking) of a shipment. Wherein the allocating of the identified at least one robot may include selecting at least one robot having the largest residual battery capacity among the identified at least one robot and allocating the selected robot to the selected at least one picking zone. Figures 1-2.
Wise et al (US-20240131703-A1) discloses a server to distribute a set of tasks between a fleet of the mobile robots. See Figure 1.
Kang et al (KR-102473630-B1) discloses a robot control technology which considers the tasks and movement conditions assigned to a plurality of robots, various technologies for accident prevention and safety, and the like and organically controlling a number of robots and facility infrastructure. See Abstract and Figure 123.
Jang et al (US-20210096572-A1) discloses one or more robots to perform at least one task in a space and provide information or data related to the task for the control server including an indication of the battery capacity of the robot. See Figures 1-3.
Seok et al (KR-102190968-B1) discloses a an operation management system and method for optimizing task performance of mobile robots operating by a fuel cell. The operation management method for optimizing task performance of mobile robots operating by a fuel cell comprises: a step of managing specification information of N mobile robots; a step of dividing and allocating a first detailed task to be performed by the N mobile robots according to the specification information of the N mobile robots based on a task. See Abstract and Figure 1.
SAITO; Atsushi et al. (US-20190019051-A1) UNMANNED MOBILE APPARATUS CAPABLE OF TRANSFERRING IMAGING, METHOD OF TRANSFERRING.
DEY; Sounak et al. (US-20180316628-A1) SYSTEMS AND METHODS FOR DYNAMIC SEMANTIC RESOURCE DISCOVERY IN FOG-ROBOT NETWORKS.
Bareddy; Mallinath (US-9821455-B1) Replacing a first robot with a second robot during performance of a task by the first robot.
Soo; Sheryl et al. (US-9796091-B1) Selective robot deployment.
KAZAMA; Yoriko et al. (US-20160026186-A1) Transport Management Apparatus, Transport System, and Transport Management Program.
Vestal; Matthew et al. (US-20140365258-A1) JOB MANAGEMENT SYSTEM FOR A FLEET OF AUTONOMOUS MOBILE ROBOTS.
Orita; Atsuo et al. (US-20080109114-A1) Robot Control Apparatus.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELLIS B. RAMIREZ whose telephone number is (571)272-8920. The examiner can normally be reached 7:30 am to 5:00pm.
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, Ramon Mercado can be reached at 571-270-5744. 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.
/ELLIS B. RAMIREZ/Examiner, Art Unit 3658