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 .
Priority
The applicant’s claim to priority of CN202410123765.8 on 1/29/2024 is acknowledged.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Lee et al. (US 20220019237 hereinafter Lee).
Regarding claim 1 (and similarly 10 and 19), Lee teaches a robot dispatching method, comprising:
displaying at least one dispatchable robot available for switching in response to a robot switching instruction (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information.); and
determining a target robot in response to a trigger operation for the at least one dispatchable robot, and sending robot information of the target robot to a dispatching system, so that the dispatching system associates a pending task associated with an abnormal robot with the target robot (See at least: [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.).
Regarding claim 2 (and similarly 11 and 20), Lee teaches wherein the method further comprises: displaying robot information of the abnormal robot, to generate the robot switching instruction when triggering the robot information is detected; and sending the robot information to the dispatching system based on the robot switching instruction, so that the dispatching system marks the abnormal robot as unavailable based on the robot information (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.).
Regarding claim 3 (and similarly 12), Lee teaches wherein the method further comprises: triggering selection of a takeover location on a display interface, so that the target robot and the abnormal robot perform a shift of the pending task at the takeover location (See at least: [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”).
Regarding claim 4 (and similarly 13), Lee teaches wherein the method further comprises: sending a task cancellation instruction to a local task management system and the abnormal robot based on the dispatching system; receiving the task cancellation instruction based on the abnormal robot to stop performing the task; and receiving the task cancellation instruction based on the local task management system, and canceling a binding relationship between the abnormal robot and the pending task associated therewith based on the task cancellation instruction (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.; [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”).
Regarding claim 5 (and similarly 14), Lee teaches wherein after the receiving the task cancellation instruction based on the local task management system, the method further comprises: determining transfer information of the pending task based on a task state of the pending task that is associated with the abnormal robot to associate the pending task with the target robot based on the transfer information (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.; [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”).Regarding claim 6 (and similarly 15), Lee teaches wherein the determining transfer information of the pending task based on a task state of the pending task that is associated with the abnormal robot comprises: when the task state of the pending task is a non-suspended state, determining that the transfer information is to be associated with the target robot; or when the task state of the pending task is a suspended state, determining that the transfer information is that the state remains unchanged (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.; [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”; Fig. 5 Note: Used Lee to disclose the bolded portion of the claim as the “or” does not require Lee to disclose the limitation after the “or”. ).
Regarding claim 7 (and similarly 16), Lee teaches wherein the displaying at least one dispatchable robot available for switching in response to a robot switching instruction comprises: sending the robot switching instruction to the dispatching system, so that the dispatching system obtains a current state of at least one robot based on the robot switching instruction, and uses a robot whose current state is consistent with a preset state as the dispatchable robot; and receiving the robot information of the dispatchable robot sent by the dispatching system, and displaying the robot information of the at least one dispatchable robot available for switching on a display interface (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.; [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”).Regarding claim 8 (and similarly 17), Lee teaches wherein after the determining a target robot, the method further comprises: sending the takeover location to the dispatching system, so that the dispatching system generates a takeover instruction based on the takeover location, and sends the takeover instruction to the abnormal robot and the target robot, so that the target robot and the abnormal robot move to the takeover location to perform the shift of the pending task (See at least: [0078] The controller 150 is connected to a display or operator PC for platoon control of the mobile robot 10, and may display monitoring information of the mobile robot 10 according to the operation of the central server 100 and may receive setting information; [0104] However, in some forms of the present disclosure, as shown in FIG. 6, the central server 100 identifies position information of respective mobile robots 10 in real-time at every position, and when a position deviation occurs to any mobile robot 10, for example, due to a slip of drive wheels, such an error may be resolved by sending an instruction to adjust the position to the errored mobile robot 10. In addition, the central server 100 collects state information of each mobile robot 10 in real-time, and if any mobile robot 10 in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with another idle mobile robot 10. At this time, through the user interface (UI), the central server 100 may delete the malfunctioning mobile robot 10 from the group and add another idle mobile robot 10 to the position of the deleted mobile robot 10.; [0111] via “Furthermore, when a mobile robot in the platoon malfunctions, the malfunctioning mobile robot may be promptly replaced with an idle mobile robot, thereby preventing production line stoppage.”; Fig. 5).
Regarding claim 9 (and similarly 18), Lee teaches wherein after the determining a target robot, the method further comprises: marking the target robot as occupied based on the dispatching system, and marking the target robot as dispatchable after receiving that the target robot has completed the task (See at least: Fig. 5, steps s1 “work instruction” to s11 “work-finish”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Harry Oh whose telephone number is (571)270-5912. The examiner can normally be reached on Monday-Thursday, 9:00-3:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abby Lin can be reached on (571) 270-3976. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARRY Y OH/Primary Examiner, Art Unit 3657