Abstract:
A method for remotely monitoring a patient. The method includes generating and transmitting input commands to the robot from a remote station. The remote station may include a personal computer that is operated by a doctor. The input commands can move the robot so that a video image and sounds of the patient can be captured by a robot camera and microphone, respectively, and transmitted back to the remote station. The robot may also have a monitor and a speaker to allow for two-way videoconferencing between the patient and a doctor at the remote station. The robot can move from room to room so that a doctor can make “patient rounds” within a medical facility. The system thus allows a doctor visit patients from a remote location, thereby improving the frequency of visits and the quality of medical care. 
     REEXAMINATION RESULTS 
     The questions raised in reexamination proceeding No. 90/012,069, filed Dec. 22, 2011, have been considered, and the results thereof are reflected in this reissue patent which constitutes the reexamination certificate required by 35 U.S.C. 307 as provided in 37 CFR 1.570(e) for  ex parte  reexaminations, or the reexamination certificate required by 35 U.S.C. 316 as provided in 37 CFR 1.997(e) for  inter partes  reexaminations.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of application Ser. No. 10/751,032, filed on Jan. 2, 2004, now U.S. Pat. No. 7,164,969 which is a continuation-in-part of application Ser. No. 10/206,457, filed on Jul. 25, 2002, now U.S. Pat. No. 6,925,357: 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The subject matter disclosed generally relates to the field of robotics. 
     2. Background Information 
     Patient consultation is a critical component of medical care. For example, it is typically imperative that a physician visit a patient after a surgical procedure. Such visits not only allow the physician to observe the patient for follow-up care, but aids in establishing the all important personal relationship between doctor and patient. Because of various economic and regulatory issues it has become increasing difficult for physicians to develop strong relationships with patients through interactive visits. 
     John Hopkins Medical Institution has tested a program where tele-conferencing equipment is placed in a patient&#39;s room. The doctor can then remotely “visit” the patient through the tele-conferencing system. Such an approach would require tele-conferencing equipment in each patient room, thereby increasing the cost of equipping and maintaining the medical facility. Additionally, the tele-conferencing equipment must be placed in a position to allow the doctor to view the patient. This may be in a location adjacent to the patient&#39;s bed. Such a location may not allow the doctor to view an ambulatory patient. 
     Robots have been used in a variety of applications ranging from remote control of hazardous material to assisting in the performance of surgery. For example, U.S. Pat. No. 5,762,458 issued to Wang et al. discloses a system that allows a surgeon to perform minimally invasive medical procedures through the use of robotically controlled instruments. One of the robotic arms in the Wang system moves an endoscope which has a camera that allows a surgeon to view a surgical area of a patient. 
     Tele-robots such as hazardous waste handlers and bomb detectors may contain a camera that allows the operator to view the remote site. Canadian Pat. No. 2289697 issued to Treviranus, et al. discloses a videoconferencing platform that has both a camera and a monitor. The Treviranus patent also discloses embodiments with a mobile platform, and mechanisms for moving the camera and the monitor. 
     Publication Application No. US-2003-0050233-A1 discloses a remote robotic system wherein a plurality of remote stations can control a plurality of robotic arms used to perform a minimally invasive medical procedure. Each remote station can receive a video image provided by the endoscope inserted into the patient. The remote stations are linked to the robotic system by a dedicated communication link. 
     To date there has not been a utilization of mobile robots to allow a doctor to remotely visit a patient. Such a technique would allow more frequent doctor/patient visits and improve the quality of medical care. 
     BRIEF SUMMARY OF THE INVENTION 
     A method for remotely monitoring a patient with a robot that has a camera and a microphone. A robot input command is generated and transmitted from a remote station. The robot input command is received by the robot. The robot moves in response to the robot input command. A video image and sound of the patient is transmitted to the remote station from the robot. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is an illustration of a robotic system; 
         FIG. 2  is a schematic showing movement of a robot in a medical facility; 
         FIG. 3  is a schematic of an electrical system of a robot; 
         FIG. 4  is a further schematic of the electrical system of the robot; 
         FIG. 5  is side view of the robot; 
         FIG. 6  is a top perspective view of a holonomic platform of the robot; 
         FIG. 7  is aside perspective view of a roller assembly of the holonomic platform; 
         FIG. 8  is a bottom perspective view showing a pedestal assembly of the robot; 
         FIG. 9  is a sectional view showing an actuator of the pedestal assembly; 
         FIG. 10  is a side view of a robot head. 
     
    
    
     DETAILED DESCRIPTION 
     Disclosed is a method for remotely monitoring a patient. The method includes generating and transmitting input commands to the robot from a remote station. The remote station may include a personal computer that is operated by a doctor. The input commands can move the robot so that a video image and sounds of the patient can be captured by a robot camera and microphone, respectively, and transmitted back to the remote station. The robot may also have a monitor and a speaker to allow for two-way videoconferencing between the patient and a doctor at the remote station. The robot can move from room to room so that a doctor can make “patient rounds” within a medical facility. The system thus allows a doctor to visit patients from a remote location, thereby improving the frequency of visits and the quality of medical care. 
     Referring to the drawings more particularly by reference numbers,  FIG. 1  shows a robotic system  10 . The robotic system  10  includes a robot  12 , a base station  14  and a remote control station  16 . The control station  16  may be coupled to the base station  14  through a network  18 . By way of example, the network  18  may be either a packet switched network such as the Internet, or a circuit switched network such has a Public Switched Telephone Network (PSTN) or other broadband system. The base station  14  may be coupled to the network  18  by a modem  20  or other broadband network interface device. 
     The remote control station  16  may include a computer  22  that has a monitor  24 , a camera  26 , a microphone  28  and a speaker  30 . The computer  22  may also contain an input device  32  such as a joystick or a mouse. The station  16  is typically located in a place that is remote from the robot  12 . Although only one robot  12  is shown, it is to be understood that the system  10  may have a plurality of robots  12 . In general any number of robots  12  may be controlled by any number of remote stations. For example, one remote station  16  may be coupled to a plurality of robots  12 , or one robot  12  may be coupled to a plurality of remote stations  16 . 
     The robot  12  includes a movement platform  34  that is attached to a robot housing  36 . Also attached to the robot housing  36  are a camera  38 , a monitor  40 , a microphone(s)  42  and a speaker  44 . The microphone  42  and speaker  30  may create a stereophonic sound. The robot  12  may also have an antenna  45  that is wirelessly coupled to an antenna  46  of the base station  14 . The system  10  allows a user at the remote control station  16  to move the robot  12  through the input device  32 . The robot camera  38  is coupled to the remote monitor  24  so that a user at the remote station  16  can view a patient. Likewise, the robot monitor  40  is coupled to the remote camera  26  so that the patient can view the user. The microphones  28  and  42 , and speakers  30  and  44 , allow for audible communication between the patient and the user. 
     Each remote station computer  22  may operate Microsoft OS software and WINDOWS XP or other operating systems such as LINUX. The remote computer  22  may also operate a video driver, a camera driver, an audio driver and a joystick driver. The video images may be transmitted and received with compression software such as MPEG CODEC. 
     The system  10  may be the same or similar to a robotic system sold by the assignee InTouch-Health, Inc. of Santa Barbara, Calif. under the trademark COMPANION. 
       FIG. 2  shows an implementation of the system in a medical facility  50 . The medical facility  50  may be a hospital, assisted living home, etc, that contains a plurality of patient rooms  52 , including a first patient room  52 A and a second patient room  52 B, each containing one or more patients. 
     A doctor may be located at a remote station  16 . The remote station  16  may be on or off the premises of the medical facility  50 . The station  16  is linked to the robot  12  by the network  18  and wireless base station  14 . The medical facility  50  may have a number of wireless base stations  14  located throughout the facility  50  so that the robot  12  is always linked to a station  14 . 
     The system  10  allows the doctor to make patient rounds in the facility  50 . For example, the doctor may generate robot input commands at the remote station  16  that are then transmitted and received by the robot  12 . The input commands may cause the robot to move to the door of the first patient room  52 A. The doctor can view a chart  54  outside the room through the robot camera. The doctor may utilize a zoom feature of the camera to read the chart. 
     After reading the chart the doctor may move the robot into the first patient room  52 A. The system allows the doctor to conduct a two-way videoconference with the patient. The videoconference may allow the doctor to observe the patient through the robot camera. The doctor can also ask questions that can be generated by the robot speaker and/or displayed by the robot monitor. The robot monitor can display the doctor at the remote station so that the patient feels they are being “visited” by the doctor. 
     After the visiting the patient in the first patient room  52 A the doctor can move the robot  12  to the second patient room  52 B where the process is repeated. The system thus allows the doctor to visit multiple patients from a remote location. This increases the frequency of doctor visits, reduces doctor fatigue and improves the overall medical care of the patients. 
       FIGS. 3 and 4  show an embodiment of the robot  12 . The robot  12  may include a high level control system  150  and a low level control system  152 . The high level control system  150  may include a processor  154  that is connected to a bus  156 . The bus  156  is coupled to the camera  38  by an input/output (I/O) port  158 , and to the monitor  40  by a serial output port  160  and a VGA driver  162 . The monitor  40  may include a touchscreen function that allows the patient to enter input by touching the monitor screen  40 . 
     The speaker  44  is coupled to the bus  156  by a digital to analog converter  164 . The microphone  42  is coupled to the bus  156  by an analog to digital converter  166 . The high level controller  150  may also contain random access memory (RAM) device  168 , a non-volatile RAM device  170  and a mass storage device  172  that are all coupled to the bus  162 . The mass storage device  172  may contain medical files of the patient that can be accessed by the user at the remote control station  16 . For example, the mass storage device  172  may contain a picture of the patient. The user, particularly a health care provider, can recall the old picture and make a side by side comparison on the monitor  24  with a present video image of the patient provided by the camera  38 . The robot antennae  45  may be coupled to a wireless transceiver  174 . By way of example, the transceiver  174  may transmit and receive information in accordance with IEEE 802.11b. 
     The controller  154  may operate with a LINUX OS operating system. The controller  154  may also operate MS WINDOWS along with video, camera and audio drivers for communication with the remote control station  16 . Video information may be transceived using MPEG CODEC compression techniques. The software may allow the user to send e-mail to the patient and vice versa, or allow the patient to access the Internet. In general the high level controller  150  operates to control the communication between the robot  12  and the remote control station  16 . 
     The high level controller  150  may be linked to the low level controller  152  by serial ports  176  and  178 . The low level controller  152  includes a processor  180  that is coupled to a RAM device  182  and non-volatile RAM device  184  by a bus  186 . The robot  12  contains a plurality of motors  188  and motor encoders  190 . The encoders  190  provide feedback information regarding the output of the motors  188 . The motors  188  can be coupled to the bus  186  by a digital to analog converter  192  and a driver amplifier  194 . The encoders  190  can be coupled to the bus  186  by a decoder  196 . The robot  12  also has a number of proximity sensors  198  (see also  FIG. 1 ). The position sensors  198  can be coupled to the bus  186  by a signal conditioning circuit  200  and an analog to digital converter  202 . 
     The low level controller  152  runs software routines that mechanically actuate the robot  12 . For example, the low level controller  152  provides instructions to actuate the movement platform to move the robot  12 . The low level controller  152  may receive movement instructions from the high level controller  150 . The movement instructions may be received as movement commands from the remote control station. Although two controllers are shown, it is to be understood that the robot  12  may have one controller controlling the high and low level functions. 
     The various electrical devices of the robot  12  may be powered by a battery(ies)  204 . The battery  204  may be recharged by a battery recharger station  206  (see also  FIG. 1 ). The low level controller  152  may include a battery control circuit  208  that senses the power level of the battery  204 . The low level controller  152  can sense when the power falls below a threshold and then send a message to the high level controller  150 . The high level controller  150  may include a power management software routine that causes the robot  12  to move so that the battery  204  is coupled to the recharger  206  when the battery power falls below a threshold value. Alternatively, the user can direct the robot  12  to the battery recharger  206 . Additionally, the battery  204  may be replaced or the robot  12  may be coupled to a wall power outlet by an electrical cord (not shown). 
       FIG. 5  shows an embodiment of the robot  12 . The robot  12  may include a holonomic platform  210  that is attached to a robot housing  212 . The holonomic platform  210  provides three degrees of freedom to allow the robot  12  to move in any direction. 
     The robot  12  may have a pedestal assembly  214  that supports the camera  38  and the monitor  40 . The pedestal assembly  214  may have two degrees of freedom so that the camera  26  and monitor  24  can be swiveled and pivoted as indicated by the arrows. 
     As shown in  FIG. 6  the holonomic platform  210  may include three roller assemblies  220  that are mounted to a base plate  221 . The roller assemblies  220  allow for movement in any direction. 
     The robot housing  212  may include a bumper  222 . The bumper  222  may be coupled to optical position sensors  223  that detect when the bumper  222  has engaged an object. After engagement with the object the robot can determine the direction of contact and prevent further movement into the object. 
       FIG. 7  shows an embodiment of a roller assembly  220 . Each assembly  220  may include a drive ball  224  that is driven by a pair of transmission rollers  226 . The assembly  220  may include a retainer ring  228  and a plurality of bushings  230  that capture and allow the ball  224  to rotate in x and y directions but prevent movement in a z direction. The assembly also holds the ball under the transmission rollers  226 . 
     The transmission rollers  226  are coupled to a motor assembly  232 . The assembly  232  corresponds to the motor  188  shown in  FIG. 4 . The motor assembly  232  includes an output pulley  234  attached to a motor  236 . The output pulley  234  is coupled to a pair of ball pulleys  238  by a drive belt  240 . The ball pulleys  238  are each attached to a transmission bracket  242 . The transmission rollers  226  are attached to the transmission brackets  242 . 
     Rotation of the output pulley  234  rotates the ball pulleys  238 . Rotation of the ball pulleys  238  causes the transmission rollers  226  to rotate and spin the ball  224  through frictional forces. Spinning the ball  224  will move the robot  12 . The transmission rollers  226  are constructed to always be in contact with the drive ball  224 . The brackets  242  allow the transmission rollers  226  to freely spin in a direction orthogonal to the driven direction when one of the other roller assemblies  220  is driving and moving the robot  12 . 
     As shown in  FIG. 8 , the pedestal assembly  214  may include a motor  250  that is coupled to a gear  252  by a belt  254 . The gear  252  is attached to a shaft  256 . The shaft  256  is attached to an arm  258  that is coupled to the camera  38  and monitor  40  by a bracket  260 . Activation of the motor  250  rotates the gear  252  and sleeve  256 , and causes the camera  38  and monitor  40  to swivel (see also  FIG. 5 ) as indicated by the arrows  4 . 
     As shown in  FIG. 9 , the assembly  214  may further include a tilt motor  262  within the arm  258  that can cause the monitor  40  and camera  38  to pivot as indicated by the arrows  5 . The tilt motor  262  may rotate a worm  264  that rotates a worm gear  266 . The pin  268  is rigidly attached to both the worm gear  266  and the bracket  260  so that rotation of the gear  266  pivots the camera  38  and the monitor  40 . The camera  38  may also include a zoom feature to provide yet another degree of freedom for the operator. 
     The robot  10  may be controlled by a number of different doctors. To accommodate for this the robot may have an arbitration system. The arbitration system may be integrated into the operating system of the robot  12 . For example, the arbitration technique may be embedded into the operating system of the high-level controller  150 . 
     By way of example, the users may be divided into classes that include the robot itself, a local user, a caregiver, a doctor, a family member, or a service provider. The robot  12  may override input commands that conflict with robot operation. For example, if the robot runs into a wall, the system may ignore all additional commands to continue in the direction of the wall. A local user is a person who is physically present with the robot. The robot could have an input device that allows local operation. For example, the robot may incorporate a voice recognition system that receives and interprets audible commands. 
     A caregiver is someone who remotely monitors the patient. A doctor is a medical professional who can remotely control the robot and also access medical files contained in the robot memory. The family and service users remotely access the robot. The service user may service the system such as by upgrading software, or setting operational parameters. 
     Message packets may be transmitted between a robot  12  and a remote station  16 . The packets provide commands and feedback. Each packet may have multiple fields. By way of example, a packet may include an ID field a forward speed field, an angular speed field, a stop field, a bumper field, a sensor range field, a configuration field, a text field and a debug field. 
     The identification of remote users can be set in an ID field of the information that is transmitted from the remote control station  16  to the robot  12 . For example, a user may enter a user ID into a setup table in the application software run by the remote control station  16 . The user ID is then sent with each message transmitted to the robot. 
     The robot  12  may operate in one of two different modes; an exclusive mode, or a sharing mode. In the exclusive mode only one user has access control of the robot. The exclusive mode may have a priority assigned to each type of user. By way of example, the priority may be in order of local, doctor, caregiver, family and then service user. In the sharing mode two or more users may share access with the robot. For example, a caregiver may have access to the robot, the caregiver may then enter the sharing mode to allow a doctor to also access the robot. Both the caregiver and the doctor can conduct a simultaneous tele-conference with the patient. 
     The arbitration scheme may have one of four mechanisms; notification, timeouts, queue and call back. The notification mechanism may inform either a present user or a requesting user that another user has, or wants, access to the robot. The timeout mechanism gives certain types of users a prescribed amount of time to finish access to the robot. The queue mechanism is an orderly waiting list for access to the robot. The call back mechanism informs a user that the robot can be accessed. By way of example, a family user may receive an e-mail message that the robot is free for usage. Tables 1 and 2, show how the mechanisms resolve access request from the various users. 
     
       
         
               
               
               
               
               
               
             
           
               
                 TABLE I 
               
               
                   
               
               
                   
                 Access 
                 Medical 
                 Command 
                 Software/Debug 
                 Set 
               
               
                 User 
                 Control 
                 Record 
                 Override 
                 Access 
                 Priority 
               
               
                   
               
             
             
               
                 Robot 
                 No 
                 No 
                 Yes (1) 
                 No 
                 No 
               
               
                 Local 
                 No 
                 No 
                 Yes (2) 
                 No 
                 No 
               
               
                 Caregiver 
                 Yes 
                 Yes 
                 Yes (3) 
                 No 
                 No 
               
               
                 Doctor 
                 No 
                 Yes 
                 No 
                 No 
                 No 
               
               
                 Family 
                 No 
                 No 
                 No 
                 No 
                 No 
               
               
                 Service 
                 Yes 
                 No 
                 Yes 
                 Yes 
                 Yes 
               
               
                   
               
             
          
         
       
     
     
       
         
               
               
             
               
               
               
               
               
               
               
             
           
               
                 TABLE II 
               
             
             
               
                   
               
               
                   
                 Requesting User 
               
             
          
           
               
                   
                   
                 Local 
                 Caregiver 
                 Doctor 
                 Family 
                 Service 
               
               
                   
               
               
                 Current 
                 Local 
                 Not Allowed 
                 Warn current user of 
                 Warn current user of 
                 Warn current user of 
                 Warn current user of 
               
               
                 User 
                   
                   
                 pending user 
                 pending user 
                 pending user 
                 pending user 
               
               
                   
                   
                   
                 Notify requesting 
                 Notify requesting user 
                 Notify requesting user 
                 Notify requesting 
               
               
                   
                   
                   
                 user that system is in 
                 that system is in use 
                 that system is in use 
                 user that system is in use 
               
               
                   
                   
                   
                 use 
                 Set timeout = 5 m 
                 Set timeout = 5 m 
                 No timeout 
               
               
                   
                   
                   
                 Set timeout 
                   
                 Call back 
                 Call back 
               
               
                   
                 Caregiver 
                 Warn current user 
                 Not Allowed 
                 Warn current user of 
                 Warn current user of 
                 Warn current user of 
               
               
                   
                   
                 of pending user. 
                   
                 pending user 
                 pending user 
                 pending user 
               
               
                   
                   
                 Notify requesting 
                   
                 Notify requesting user 
                 Notify requesting user 
                 Notify requesting 
               
               
                   
                   
                 user that system is 
                   
                 that system is in use 
                 that system is in use 
                 user that system is in use 
               
               
                   
                   
                 in use. 
                   
                 Set timeout = 5 m 
                 Set timeout = 5 m 
                 No timeout 
               
               
                   
                   
                 Release control 
                   
                 Queue or callback 
                   
                 Callback 
               
               
                   
                 Doctor 
                 Warn current user 
                 Warn current user of 
                 Warn current user of 
                 Notify requesting user 
                 Warn current user of 
               
               
                   
                   
                 of pending user 
                 pending user 
                 pending user 
                 that system is in use 
                 pending user 
               
               
                   
                   
                 Notify requesting 
                 Notify requesting 
                 Notify requesting user  
                 No timeout 
                 Notify requesting 
               
               
                   
                   
                 user that system is 
                 user that system is in 
                 that system is in use 
                 Queue or callback 
                 user that system is in use 
               
               
                   
                   
                 in use 
                 use 
                 No timeout 
                   
                 No timeout 
               
               
                   
                   
                 Release control 
                 Set timeout = 5 m 
                 Callback 
                   
                 Callback 
               
               
                   
                 Family 
                 Warn current user 
                 Notify requesting 
                 Warn current user of 
                 Warn current user of 
                 Warn current user of 
               
               
                   
                   
                 of pending user 
                 user that system is in 
                 pending user 
                 pending user 
                 pending user 
               
               
                   
                   
                 Notify requesting 
                 use 
                 Notify requesting user 
                 Notify requesting user 
                 Notify requesting 
               
               
                   
                   
                 user that system is 
                 No timeout 
                 that system is in use 
                 that system is in use 
                 user that system is in use 
               
               
                   
                   
                 in use 
                 Put in queue or 
                 Set timeout = 1 m 
                 Set timeout = 5 m 
                 No timeout 
               
               
                   
                   
                 Release Control 
                 callback 
                 pending user 
                 Queue or callback 
                 Call back 
               
               
                   
                 Service 
                 Warn current user 
                 Notify requesting 
                 Warn current user of 
                 Warn current user of 
                 Not Allowed 
               
               
                   
                   
                 of pending user 
                 user that system is in 
                 request 
                 pending user 
                   
               
               
                   
                   
                 Notify requesting 
                 use 
                 Notify requesting user 
                 Notify requesting user 
                   
               
               
                   
                   
                 user that system is 
                 No timeout 
                 that system is in use 
                 that system is in use 
                   
               
               
                   
                   
                 in use 
                 Callback 
                 No timeout 
                 No timeout 
                   
               
               
                   
                   
                 No timeout 
                   
                 Callback 
                 Queue or callback 
               
               
                   
               
             
          
         
       
     
     The information transmitted between the station  16  and the robot  12  may be encrypted. Additionally, the user may have to enter a password to enter the system  10 . A selected robot is then given an electronic key by the station  16 . The robot  12  validates the key and returns another key to the station  16 . The keys are used to encrypt information transmitted in the session. 
       FIG. 10  shows a robot head  300  that can both pivot and spin the camera  38  and the monitor  40 . The robot head  300  can be similar to the robot  12  but without the platform  210 . The robot head  300  may have the same mechanisms and parts to both pivot the camera  38  and monitor  40  about the pivot axis  4 , and spin the camera  38  and monitor  40  about the spin axis  5 . The pivot axis may intersect the spin axis. Having a robot head  300  that both pivots and spins provides a wide viewing area. The robot head  300  may be in the system either with or instead of the mobile robot  12 . The head  300  may be placed in a patient room to conduct two-way videoconferencing between a patient and a doctor at a remote location. The pivoting and spinning degrees of freedom allow the doctor to move the camera to follow an ambulatory patient. 
     While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.