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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 9, 18, 20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claims 9 and 18, the claims recites:
the limitation "in the event that the initial configuration present in the memory does not match the configuration created in the configurating step, the configuration created in the configurating step is used to control the robot arm, the initial configuration is used to control the robot arm".
It is unclear in the claimed event whether 1) the new configuration created in the configurating step is used or 2) the initial configuration is used to control the robot arm. For examining purposes, the limitation will be interpreted to have meaning 1).
Regarding Claim 20, the claim recites:
the limitation " A modular robot having a robot arm and a controller configured to carry out the method of claim 19. ", but claim 19 is directed to “A controller for operating a modular robot”, not a method.
It is unclear in the claimed event whether 1) the modular robot carries out the method of Claim 10 or 2) the modular robot has the controller of Claim 19. For examining purposes, the limitation will be interpreted to have meaning 1).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claim(s) 1-5, 7, 9-12, 14, 16-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Malzahn et al (US 20230028405, hereinafter Malzahn).
Regarding Claim 1, Malzahn teaches:
a method for operating a modular robot (see at least "A method for automatic on-the-fly robot topology recognition, kinematic and dynamic model as well as controller generation and tuning implemented in a master/slave software framework and enabled by a custom electronic slave device specifically developed and integrated into each and every modular robotic component may be exemplary of such a method." in par. 0033) , the modular robot comprising:
a robot base (see at least "FIG. 2 is an exemplary diagram of an integrated system, called modular robot 10, comprising a master module 11 embodied by a robot base," in par. 0120) ,
at least a robot arm arranged on the robot base (see at least "FIG. 2 is an exemplary diagram of an integrated system, called modular robot 10, comprising a master module 11 embodied by a robot base, then slave modules 12 including a “hub” robot module 12H, at least one arm-like assembly including two joint module 12J, at least one “link” robot module 12L and at least one end-effector 12E, for instance a gripper tool." in par. 0120) , and
a controller (see at least "The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12. In variant embodiments the server device or the robot module database 90 may not be arranged inside the master module 11, but may be disposed outside, in particular remote, for instance being accessed by the master communication node 300 by a wireless link. The master module 11 may also include a further processor equipped module to perform other functionalities required to the master module 11 or such functionalities can be performed by the circuitry of the module 300 itself." in par. 0103) ,
the robot arm comprising a plurality of arm modules configured to be arranged in a modular manner (see at least "In FIG. 12 it shown a flow diagram representing an embodiment of a method 100 of configuring modular configurable robot 10 like the one described so far. The method 100 may comprise: [0249] an initialization stage 110, wherein a modular robot 10 is provided and an automation task for the robot is defined, [0250] a robot assembly stage 120, comprising operations of mounting and/or dismounting modules of the modular robot, wherein a user may assemble a new module on the robot or removes an existing module from the robot, [0251] an automatic reconfiguration stage 1002" in par. 0248);
the method comprising the controller carrying out the following steps:
receiving allocation information from each of the arm modules in an allocation determining step (see at least "As exemplified in FIG. 10, the automatic reconfiguration stage 1002 may comprise: [0255] a virtual network topology detection operation 130 comprising accessing by said master network communication module 300 said respective port state values stored in said slave module memory register 81 of said network communication slave modules 84 in said ring or chain network and computing at said master network communication module 300 a graph structure VNT, having the slave modules 84 as nodes and the connection among their ports as edges of said graph structure VNT, representative of a virtual topology of the communication network 30 of the assembled configurable robot 10 as a function of said respective port state values" in par. 0254 and 0255);
determining arm module base data based on the allocation information for each arm module in an arm module base data determining step (see at least "As exemplified in FIG. 10, the automatic reconfiguration stage 1002 may comprise: [0255] a virtual network topology detection operation 130 comprising accessing by said master network communication module 300 said respective port state values stored in said slave module memory register 81 of said network communication slave modules 84 in said ring or chain network and computing at said master network communication module 300 a graph structure VNT, having the slave modules 84 as nodes and the connection among their ports as edges of said graph structure VNT, representative of a virtual topology of the communication network 30 of the assembled configurable robot 10 as a function of said respective port state values" in par. 0254 and 0255);
creating a configuration of the modular robot from the allocation information and the arm module base data of the individual arm modules in a configurating step, (see at least "a configuration retrieval operation (150) comprising retrieving from said centralized module database or lookup table 9), as a function of said unique identification code I stored in said accessed slave module register 81 corresponding records containing robot module parameters FKI, e.g. functional, kinematic and inertial and semantic parameters, wherein the operation of providing the module database and retrieving the information therefrom facilitates reducing built-in data storage in the robot modules, [0258] a topology reconstruction operation 160 comprising generating an updated robot description file FD including updated robot kinematics and dynamics model UM, as a function of said graph structure VNT representative of the detected virtual topology in step 130, including said information OI of a relative orientation and said robot module parameters FKI, " in par. 0257 and 0258)
wherein the configuration is used to control the robot arm. (see at least " a controller configuration stage 170, comprising operations of configuring robot module controllers, e.g. controller modules 52, as well as the user interface, for instance on-the-fly." in par. 0259 )
Regarding Claim 2, Malzahn teaches:
The method according to claim 1,
wherein additionally in the allocation determining step,
allocation information of the robot base is received and/or (see at least " In one or more embodiments, the base module 400 may comprise the control module device 300 coupled to a respective base slave device 84′, 84″ while the first 402 and second modules 404 may comprise respective chained sets of slave devices 4020, 4040, for instance wherein slave devices 84 in each set of slave devices 4020, 4040 are configured to be coupled to joints of the respective robot module 402, 404, as discussed in the following." in par. 0276)
in the arm module base data determining step, arm module base data of the robot base is determined, wherein the allocation information of the robot base and/or the arm module base data of the robot base is taken into account when creating the configuration of the modular robot in the configurating step. (see at least " a virtual network topology detection operation comprising accessing by said master network communication module said respective port state values stored in said slave module memory set of registers of said ring or chain network of network communication slave modules and computing at said master network communication module a graph structure, having the slave modules as nodes and the connection among their ports as edges of said graph structure, representative of a virtual topology of the communication network of the assembled configurable robot as a function of said respective port state values;" in par. 0055)
Regarding Claim 3, Malzahn teaches:
The method according to claim 1,
wherein the arm module base data includes at least kinematic data, wherein the kinematic data includes a relative position of a first flange and a second flange of the respective arm modules and/or the robot base. (see at least " The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12." in par. 0103 and “The coupling mechanism 50, arranged to at least one end of said robot module 12, i.e. a first module 12.sub.1, which is configured for coupling with a corresponding coupling mechanism of the adjacent module, i.e. 12.sub.2, to form the EMI 100, includes a mechanical coupling member, embodied for instance by a flange 56 or 66 as shown in FIG. 6B, and an electrical coupling member, embodied for instance by a electrical board 57 or 67 as shown in the same FIG. 6B….Such operative electrical connection of the EMI 100 comprises a network communication signal connection, i.e. for signal NS, and a power supply connection, for power PW, as mentioned, however said electrical coupling members 57, 67 comprise respective orientation detecting arrangements configured to form upon said coupling an orientation electrical signal O which value depends on the relative orientation of the coupling of said upstream robot module 12.sub.1 with respect to the adjacent module 12.sub.2. The orientation electrical signal O is supplied to the slave processor module 72 of the upstream robot module 12, which is in signal exchange with the slave network module 84, thus the slave processor module 72 of the robot module can obtain an indication of the relative orientation on the basis of the orientation electrical signal O which can be transmitted over the communication network in the network signals NS to the master module 300.” In par. 0107)
Regarding Claim 4, Malzahn teaches:
4. The method according to according to claim 1,
wherein the controller, the robot base and the arm modules forming the robot arm are connected to one another via a field bus and data are exchanged between the arm modules, the robot base and the controller via the field bus, wherein a mechanical structure of the robot arm is determined by the controller in the allocation determining step on the basis of a sequence of the allocation information of the arm modules in a telegram of the field bus. (see at least " For instance, a data bus 723 is arranged between the microprocessor system 72 and the module functional system 52 to enable frequent and larger volume data transfer, e.g. commands C." in par. 0191 and “The solution described may exploit network implementation facilitating to connect electronic (slave) devices in apparent topologies that are bus, tree- or star-shaped, which in the context of robotic modules may result in robots with series kinematic chains as well as tree-like kinematics.” In par. 0406)
Regarding Claim 5, Malzahn teaches:
5. The method according to according to claim 1,
wherein the allocation information of the arm modules is influenced by a respective unique allocation number of the arm modules. (see at least " The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12." in par. 0103)
Regarding Claim 7, Malzahn teaches:
7. The method according to claim 1,
wherein further data is read out from at least one of the arm modules and/or determined for at least one of the arm modules to create the configuration in the configurating step, wherein the further data of the arm modules include dynamic data, wherein the dynamic data include a mass inertia of the arm modules. (see at least " In one or more embodiments, providing the centralized database or lookup table 90 may comprise providing a database wherein properties stored, and accessible as a function of module type and version, or in general by the identification code I, comprise records comprising one or more of the following functional, kinematic and inertial parameters FKI: [0305] coordinate transformations between the coordinate frames assigned to the robot module 12, [0306] inertial parameters of the robot module 12, including center of mass coordinates with respect to an upstream frame, a module mass along with the module inertia parameters with respect to the center of mass. [0307] a set of module state parameters [0308] parameters for possible kinematic, differential or dynamic constraints, which can be conceivably realized with the module. In one or more embodiments, parameters for possible kinematic, differential or dynamic constraints may comprise mathematically formulated constraints as linear or quadratic matrix inequalities for the module state parameters. " in par. 0304-0306)
Regarding Claim 9, Malzahn teaches:
9. The method according to claim 1, wherein:
the controller further determines whether a configuration of the modular robot is present in a memory, wherein, in the event that no configuration of the modular robot is present in the memory, the configuration created in the configurating step is stored as initial configuration in the memory (see at least " The method 100 may comprise: [0249] an initialization stage 110, wherein a modular robot 10 is provided and an automation task for the robot is defined” in par. 0248 and “an automatic reconfiguration stage 1002, whose execution may be configured to be triggered either via periodic trigger, to check whether there are changes to the robot, or manually, for instance by the user through a software push-button” in par. 0251) ; and
wherein, in the event that an initial configuration of the modular robot is present in the memory, the initial configuration present in the memory is compared to the configuration created in the configurating step (see at least " an automatic reconfiguration stage 1002, whose execution may be configured to be triggered either via periodic trigger, to check whether there are changes to the robot" in par. 0251) ,
wherein, in the event that the initial configuration present in the memory matches the configuration created in the configurating step, the initial configuration is used to control the robot arm and, in the event that the initial configuration present in the memory does not match the configuration created in the configurating step, the configuration created in the configurating step is used to control the robot arm, the initial configuration is used to control the robot arm (see at least " As a result of the removal/addition of a single slave robot module 12, the fully automated on-the-fly cycle 1002 may be triggered." in par. 0269) , and
in the event that the initial configuration present in the memory does not match the configuration created in the configurating step, the configuration created in the configurating step is stored in the memory and used to control the robot arm. (see at least “the automatic reconfiguration stage 1002” in par. 0251 " As a result of the removal/addition of a single slave robot module 12, the fully automated on-the-fly cycle 1002 may be triggered." in par. 0269)
Regarding Claim 10, Malzahn teaches:
10. A method for operating a modular robot (see at least "A method for automatic on-the-fly robot topology recognition, kinematic and dynamic model as well as controller generation and tuning implemented in a master/slave software framework and enabled by a custom electronic slave device specifically developed and integrated into each and every modular robotic component may be exemplary of such a method." in par. 0033), the modular robot comprising:
a robot base (see at least "FIG. 2 is an exemplary diagram of an integrated system, called modular robot 10, comprising a master module 11 embodied by a robot base," in par. 0120),
at least a robot arm arranged on the robot base (see at least "FIG. 2 is an exemplary diagram of an integrated system, called modular robot 10, comprising a master module 11 embodied by a robot base, then slave modules 12 including a “hub” robot module 12H, at least one arm-like assembly including two joint module 12J, at least one “link” robot module 12L and at least one end-effector 12E, for instance a gripper tool." in par. 0120), and
a controller (see at least "The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12. In variant embodiments the server device or the robot module database 90 may not be arranged inside the master module 11, but may be disposed outside, in particular remote, for instance being accessed by the master communication node 300 by a wireless link. The master module 11 may also include a further processor equipped module to perform other functionalities required to the master module 11 or such functionalities can be performed by the circuitry of the module 300 itself." in par. 0103),
wherein the controller, the robot base and the arm modules forming the robot arm are connected to one another via a field bus and data are exchanged between the arm modules, the robot base and the controller via the field bus (see at least " For instance, a data bus 723 is arranged between the microprocessor system 72 and the module functional system 52 to enable frequent and larger volume data transfer, e.g. commands C." in par. 0191 and “The solution described may exploit network implementation facilitating to connect electronic (slave) devices in apparent topologies that are bus, tree- or star-shaped, which in the context of robotic modules may result in robots with series kinematic chains as well as tree-like kinematics.” In par. 0406),
wherein a data telegram is sent out by the controller and the field bus sends the data telegram through all arm modules via a ring line and subsequently the data telegram returns to the controller, and (see at least " For instance, the EtherCAT network of the example considered may comprise: [0223] four devices 84.sub.1, 84.sub.2, 84.sub.3 . . . , 84.sub.p serially coupled therebetween, having an open ring or a chain-like connection 30, [0224] an EtherCAT network master device 300 coupled to a first device 84.sub.1 and to a last device 84.sub.p of the serially coupled devices, the master configured to connect the two ends of such a chain or ring connection 30." in par. 0222 and “For instance, a data telegram may travel through the sequence of coupled devices 84.sub.1, 84.sub.2, 84.sub.3 . . . , 84.sub.p passing from one another and being processed without being stopped, until the telegram eventually travels through the full ring 30, reaching a halt once communicated back to the master 300.” In par. 0226)
wherein each arm module is a bus subscriber and comprises a switch-on unit for the field bus (see at least In the considered slave device 84.sub.1, the telegram sent by the master 300 may be received at the first port P0. Subsequently, the telegram may be provided to the EPU 81, which may be configured to process the received telegram “on-the-fly”, exchanging “payload” information destined to the respective slave device in the chain 84.sub.1, 84.sub.2. For instance, such an exchange at the EPU 81 may comprise operations of: [0228] reading or extracting information from the telegram, [0229] writing or adding information to the telegram. [0230] Subsequently, the EPU 81 may provide the processed telegram to the adjacent port, for instance the second P1. [0231] In the considered exemplary network 30: [0232] if a device input port P0 is in the first open state, then network data packages are sent through the open port P0 towards a slave connected to such port P0, wherein the network package is received back through the respective slave input port and forwarded to the next port in the sequence. [0233] the telegram arrives at port P0 within the device 84, which is always the upstream port. Then if port P1 is in closed state, the telegram advances to the next port P2. Eventually the telegram will pass through the first port P0 again on its way back to the master 300;" in par. 0227-0231 ) ;
the method comprising the controller carrying out the following steps:
receiving allocation information from each of the arm modules in an allocation determining step, wherein each switch-on unit writes the allocation information into the data telegram, wherein the allocation information of each arm module includes a unique allocation number; (see at least In the considered slave device 84.sub.1, the telegram sent by the master 300 may be received at the first port P0. Subsequently, the telegram may be provided to the EPU 81, which may be configured to process the received telegram “on-the-fly”, exchanging “payload” information destined to the respective slave device in the chain 84.sub.1, 84.sub.2. For instance, such an exchange at the EPU 81 may comprise operations of: [0228] reading or extracting information from the telegram, [0229] writing or adding information to the telegram. [0230] Subsequently, the EPU 81 may provide the processed telegram to the adjacent port, for instance the second P1. [0231] In the considered exemplary network 30: [0232] if a device input port P0 is in the first open state, then network data packages are sent through the open port P0 towards a slave connected to such port P0, wherein the network package is received back through the respective slave input port and forwarded to the next port in the sequence. [0233] the telegram arrives at port P0 within the device 84, which is always the upstream port. Then if port P1 is in closed state, the telegram advances to the next port P2. Eventually the telegram will pass through the first port P0 again on its way back to the master 300;" in par. 0227-0231 and “retrieving from slave devices 80 in the network 30, e.g. starting from the first device 80′ in the sequential network 30A, at least one identification code I, for instance representing a type and version identifier, wherein the at least one identification code I may be stored in the non-volatile memory 720 of the microprocessor system 72 of the integrated slave electronic control module 80, [0303] using the retrieved identification code I as a key to query the master database 90 and retrieve or lookup module properties of the module 402 from the centralized database or lookup table.” In par. 0300-0303)
determining arm module base data based on the allocation information for each arm module in an arm module base data determining step, wherein the arm module base data include at least kinematic data (see at least “retrieving from slave devices 80 in the network 30, e.g. starting from the first device 80′ in the sequential network 30A, at least one identification code I, for instance representing a type and version identifier, wherein the at least one identification code I may be stored in the non-volatile memory 720 of the microprocessor system 72 of the integrated slave electronic control module 80, [0303] using the retrieved identification code I as a key to query the master database 90 and retrieve or lookup module properties of the module 402 from the centralized database or lookup table.” In par. 0300-0303 and “In one or more embodiments, providing the centralized database or lookup table 90 may comprise providing a database wherein properties stored, and accessible as a function of module type and version, or in general by the identification code I, comprise records comprising one or more of the following functional, kinematic and inertial parameters FKI:” in par. 0304);
creating a configuration of the modular robot from the allocation information and the arm module base data of the individual arm modules in a configurating step, wherein on the basis of the order of the allocation information of the arm modules, a mechanical structure of the robot arm is determined in the data telegram of the field bus; and (see at least "a configuration retrieval operation (150) comprising retrieving from said centralized module database or lookup table 9), as a function of said unique identification code I stored in said accessed slave module register 81 corresponding records containing robot module parameters FKI, e.g. functional, kinematic and inertial and semantic parameters, wherein the operation of providing the module database and retrieving the information therefrom facilitates reducing built-in data storage in the robot modules, [0258] a topology reconstruction operation 160 comprising generating an updated robot description file FD including updated robot kinematics and dynamics model UM, as a function of said graph structure VNT representative of the detected virtual topology in step 130, including said information OI of a relative orientation and said robot module parameters FKI, " in par. 0257 and 0258)
controlling the robot arm on the basis of the configuration. (see at least " a controller configuration stage 170, comprising operations of configuring robot module controllers, e.g. controller modules 52, as well as the user interface, for instance on-the-fly." in par. 0259 )
Regarding Claim 11, Malzahn teaches:
11. The method according to claim 10,
wherein additionally in the allocation determining step, allocation information of the robot base is received and/or in the arm module base data determining step, arm module base data of the robot base is determined, wherein the allocation information of the robot base and/or the arm module base data of the robot base is taken into account when creating the configuration of the modular robot in the configurating step. (see at least " In one or more embodiments, the base module 400 may comprise the control module device 300 coupled to a respective base slave device 84′, 84″ while the first 402 and second modules 404 may comprise respective chained sets of slave devices 4020, 4040, for instance wherein slave devices 84 in each set of slave devices 4020, 4040 are configured to be coupled to joints of the respective robot module 402, 404, as discussed in the following." in par. 0276)
Regarding Claim 12, Malzahn teaches:
12. The method according to claim 10, wherein the kinematic data of the arm module base data includes a relative position of a first flange and a second flange of the respective arm modules and/or the robot base. (see at least " The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12." in par. 0103 and “The coupling mechanism 50, arranged to at least one end of said robot module 12, i.e. a first module 12.sub.1, which is configured for coupling with a corresponding coupling mechanism of the adjacent module, i.e. 12.sub.2, to form the EMI 100, includes a mechanical coupling member, embodied for instance by a flange 56 or 66 as shown in FIG. 6B, and an electrical coupling member, embodied for instance by a electrical board 57 or 67 as shown in the same FIG. 6B….Such operative electrical connection of the EMI 100 comprises a network communication signal connection, i.e. for signal NS, and a power supply connection, for power PW, as mentioned, however said electrical coupling members 57, 67 comprise respective orientation detecting arrangements configured to form upon said coupling an orientation electrical signal O which value depends on the relative orientation of the coupling of said upstream robot module 12.sub.1 with respect to the adjacent module 12.sub.2. The orientation electrical signal O is supplied to the slave processor module 72 of the upstream robot module 12, which is in signal exchange with the slave network module 84, thus the slave processor module 72 of the robot module can obtain an indication of the relative orientation on the basis of the orientation electrical signal O which can be transmitted over the communication network in the network signals NS to the master module 300.” In par. 0107)
Regarding Claim 14, Malzahn teaches:
14. The method according to claim 10,
wherein further data is read out from at least one of the arm modules and/or determined for at least one of the arm modules to create the configuration in the configurating step, wherein the further data of the arm modules include dynamic data, wherein the dynamic data include a mass inertia of the arm modules. (see at least " In one or more embodiments, providing the centralized database or lookup table 90 may comprise providing a database wherein properties stored, and accessible as a function of module type and version, or in general by the identification code I, comprise records comprising one or more of the following functional, kinematic and inertial parameters FKI: [0305] coordinate transformations between the coordinate frames assigned to the robot module 12, [0306] inertial parameters of the robot module 12, including center of mass coordinates with respect to an upstream frame, a module mass along with the module inertia parameters with respect to the center of mass. [0307] a set of module state parameters [0308] parameters for possible kinematic, differential or dynamic constraints, which can be conceivably realized with the module. In one or more embodiments, parameters for possible kinematic, differential or dynamic constraints may comprise mathematically formulated constraints as linear or quadratic matrix inequalities for the module state parameters. " in par. 0304-0306)
Regarding Claim 16, Malzahn teaches:
16. The method according to claim 10, wherein a movement information of the arm modules is taken into account in the configurating step, wherein the movement information of the respective arm modules comprises possible movements of the respective arm module. (see at least " In another example, motion range, torque or speed limits may be constraints suitable for robot joint modules 18." in par. 0308 )
Regarding Claim 17, Malzahn teaches:
17. The method according to claim 10, wherein a working space and/or a load capacity of the robot arm is determined when creating the configuration in the configurating step. (see at least " In another example, motion range, torque or speed limits may be constraints suitable for robot joint modules 18." in par. 0308)
Regarding Claim 18, Malzahn teaches:
18. The method according to claim 10, wherein:
the controller further determines whether a configuration of the modular robot is present in a memory, wherein, in the event that no configuration of the modular robot is present in the memory, the configuration created in the configurating step is stored as initial configuration in the memory (see at least " The method 100 may comprise: [0249] an initialization stage 110, wherein a modular robot 10 is provided and an automation task for the robot is defined” in par. 0248 and “an automatic reconfiguration stage 1002, whose execution may be configured to be triggered either via periodic trigger, to check whether there are changes to the robot, or manually, for instance by the user through a software push-button” in par. 0251), and
wherein, in the event that an initial configuration of the modular robot is present in the memory, the initial configuration present in the memory is compared to the configuration created in the configurating step (see at least " an automatic reconfiguration stage 1002, whose execution may be configured to be triggered either via periodic trigger, to check whether there are changes to the robot" in par. 0251),
wherein, in the event that the initial configuration present in the memory matches the configuration created in the configurating step, the initial configuration is used to control the robot arm and, in the event that the initial configuration present in the memory does not match the configuration created in the configurating step, the configuration created in the configurating step is used to control the robot arm, the initial configuration is used to control the robot arm (see at least " As a result of the removal/addition of a single slave robot module 12, the fully automated on-the-fly cycle 1002 may be triggered." in par. 0269, note the case where no change is detected is interpreted as the current configuration matching the old configuration), and
in the event that the initial configuration present in the memory does not match the configuration created in the configurating step, the configuration created in the configurating step is stored in the memory and used to control the robot arm. (see at least “the automatic reconfiguration stage 1002” in par. 0251 " As a result of the removal/addition of a single slave robot module 12, the fully automated on-the-fly cycle 1002 may be triggered." in par. 0269)
Regarding Claim 19, Malzahn also teaches:
19. A controller for operating a modular robot
for implementing the method of Claim 10 (see Claim 10 analysis for rejection of the method)
Regarding Claim 20, Malzahn also teaches:
20. A modular robot having a robot arm and a controller configured to carry out the method of claim 19. (see Claim 10 analysis for rejection of the method)
Claim Rejections - 35 USC § 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.
Claim(s) 6, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malzahn et al (US 20230028405, hereinafter Malzahn) in view of Shelton et al (US 20200405425, hereinafter Shelton).
Regarding Claim 6, Malzahn teaches:
6. The method according to claim 1,
wherein the allocation information of the arm modules is influenced by a respective configuration file of the arm modules, (see at least " The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12." in par. 0103)
Malzahn does not appear to explicitly teach all of the following, but Shelton does teach:
wherein the allocation information of the arm modules is calculated as a hash value from the allocation number and the configuration file. (see at least " various aspects, Integrity of communications between the robotic surgical instrument and a surgical hub (e.g. surgical hub 106) such as, for example, data communications indicative of positions and/or motions of an end effector of the robotic surgical instrument are verified. In at least one aspect, accurate communications between the robotic surgical instrument and the surgical hub can be ensured using security codes such as, for example, cyclic redundancy checks (CRC) which are error-detecting codes attached to data communications to detect accidental changes in communicated data which may occur during data transmission." in par. 0344 and “In various instances, a safety processor is configured to stop the motor pack from running if a computed CRC, which is computed from the received data, does not match the received CRC. A CRC verification module can be employed by the safety processor to compute a CRC from the received data and compare the computed CRC with the received CRC. In various instances, processors of the robotic surgical instrument and/or the surgical hub may comprise security code generator modules and/or security code verification modules. Security codes can be generated by CHECK-SUM, HASH, or other suitable protocols. The security code generation module and/or the security code verification module may be implemented in hardware, firmware, software or any combination thereof.” In par. 0345)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Malzahn to incorporate the teachings of Shelton wherein the detachable motor packs communicate data to a surgical hub using hashing for security, in order to arrive at using the same security and safety check protocol for the robot components taught by Malzahn. The motivation to incorporate the teachings of Shelton would be to improve safety and security (see par. 0344-0345).
Regarding Claim 13, Malzahn teaches:
13. The method according to claim 10,
wherein the allocation information of the arm modules is influenced by a respective configuration file of the arm modules (see at least " The master module 11 includes also a server device configured to host a centralized robot module database 90, comprising a set of records containing robot module parameters, in particular functional, kinematic and inertial and semantic parameters, accessible by a respective unique identification code I, which, as shown in FIG. 2, is stored in a processor module 72 of each robot module 12." in par. 0103),
Malzahn does not appear to explicitly teach all of the following, but Shelton does teach:
wherein the allocation information of the arm modules is calculated as a hash value from the allocation number and the configuration file. (see at least " various aspects, Integrity of communications between the robotic surgical instrument and a surgical hub (e.g. surgical hub 106) such as, for example, data communications indicative of positions and/or motions of an end effector of the robotic surgical instrument are verified. In at least one aspect, accurate communications between the robotic surgical instrument and the surgical hub can be ensured using security codes such as, for example, cyclic redundancy checks (CRC) which are error-detecting codes attached to data communications to detect accidental changes in communicated data which may occur during data transmission." in par. 0344 and “In various instances, a safety processor is configured to stop the motor pack from running if a computed CRC, which is computed from the received data, does not match the received CRC. A CRC verification module can be employed by the safety processor to compute a CRC from the received data and compare the computed CRC with the received CRC. In various instances, processors of the robotic surgical instrument and/or the surgical hub may comprise security code generator modules and/or security code verification modules. Security codes can be generated by CHECK-SUM, HASH, or other suitable protocols. The security code generation module and/or the security code verification module may be implemented in hardware, firmware, software or any combination thereof.” In par. 0345)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Malzahn to incorporate the teachings of Shelton wherein the detachable motor packs communicate data to a surgical hub using hashing for security, in order to arrive at using the same security and safety check protocol for the robot components taught by Malzahn. The motivation to incorporate the teachings of Shelton would be to improve safety and security (see par. 0344-0345).
Claim(s) 8, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malzahn et al (US 20230028405, hereinafter Malzahn) in view of Daniel et al (US 20190163172, hereinafter Daniel).
Regarding Claim 8, Malzahn teaches:
8. The method according to claim 1,
Malzahn does not appear to explicitly teach all of the following, but Daniel does teach:
wherein further data is read out from at least one of the arm modules and/or determined for at least one of the arm modules to create the configuration in the configurating step, wherein the further data comprise at least one wear information for an arm module, wherein the controller receives the wear information of the arm module and/or calculates a wear information of the arm module and determines and outputs a replacement recommendation for the arm module based on the wear information. (see at least "In accordance with one embodiment, a feedback mechanism can be provided on a manufacturing cell to provide feedback data as cell data to help teach the predictive models. Feedback data (e.g., good, bad, or ugly, or a sliding scale) can be provided based on the amount of damage suffered by a particular component. For example, a manufacturing cell that is configured to provide a 0-5 scale on how bad a particular component is can be used to train the system to predict when maintenance will be needed on that type of component across the installed base. In addition, the feedback mechanism can also include the ability to collect data on outlier events that do not directly relate to a predictive model (e.g., operator error that damages a contact tip and requires replacement; the replacement of that contact tip, and the data associated with it, would not be utilized in the creation of a predictive model for determining contact tip life)." in par. 0058 and “A degraded component of the welding equipment may include, for example, a contact tip, a gas nozzle, a wire conduit, a wire liner, an electrical cable, a wire drive roll, a tool fixture, a tool clamp, an air filter, or a robot joint.” In par. 0060)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Malzahn to incorporate the teachings of Daniel wherein feedback data is collected from the robot joints and used to predict when to replace the part. The motivation to incorporate the teachings of Daniel would be to minimize waste and maximize productivity (see par. 0051)
Regarding Claim 15, Malzahn teaches:
15. The method according to claim 10,
Malzahn does not appear to explicitly teach all of the following, but Daniel does teach:
wherein further data is read out from at least one of the arm modules and/or determined for at least one of the arm modules to create the configuration in the configurating step, wherein the further data comprise at least one wear information for an arm module, wherein the controller receives the wear information of the arm module and/or calculates a wear information of the arm module and determines and outputs a replacement recommendation for the arm module based on the wear information. (see at least "In accordance with one embodiment, a feedback mechanism can be provided on a manufacturing cell to provide feedback data as cell data to help teach the predictive models. Feedback data (e.g., good, bad, or ugly, or a sliding scale) can be provided based on the amount of damage suffered by a particular component. For example, a manufacturing cell that is configured to provide a 0-5 scale on how bad a particular component is can be used to train the system to predict when maintenance will be needed on that type of component across the installed base. In addition, the feedback mechanism can also include the ability to collect data on outlier events that do not directly relate to a predictive model (e.g., operator error that damages a contact tip and requires replacement; the replacement of that contact tip, and the data associated with it, would not be utilized in the creation of a predictive model for determining contact tip life)." in par. 0058 and “A degraded component of the welding equipment may include, for example, a contact tip, a gas nozzle, a wire conduit, a wire liner, an electrical cable, a wire drive roll, a tool fixture, a tool clamp, an air filter, or a robot joint.” In par. 0060)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Malzahn to incorporate the teachings of Daniel wherein feedback data is collected from the robot joints and used to predict when to replace the part. The motivation to incorporate the teachings of Daniel would be to minimize waste and maximize productivity (see par. 0051)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DYLAN M KATZ whose telephone number is (571)272-2776. The examiner can normally be reached Mon-Thurs. 8:00-6:00.
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, 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 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.
/DYLAN M KATZ/Primary Examiner, Art Unit 3657