Remote surgical robot system and method for interconnecting its devices

Abstract

The present disclosure relates to a remote surgical robot system and a method for interconnecting its devices. The method includes: receiving device network information of a second device sent by a server, the device network information including information of a target network channel expected to be established with the second device; creating a target network channel with the second device based on the device network information; evaluating the communication status of the target network channel, and determining whether the pairing with the second device is successful based on the communication status of the target network channel obtained by the evaluation. By creating a target network channel between a remote doctor console and a patient surgical platform, and evaluating the communication status of the target network channel, it is possible to determine whether the pairing between the remote doctor console and the patient surgical platform is successful, which is conducive to ensuring that ultra-remote surgery can be implemented smoothly and reliably.

Description

Technical Field

[0001] The present disclosure relates to the technical field of surgical robots, and in particular to a remote surgical robot system and a method for interconnecting its devices. Background Art

[0002] In recent years, surgical robot technology has flourished, resulting in surgical robots for different applicable scenarios such as orthopedic surgical robots, interventional surgical robots, and laparoscopic surgical robots. For doctors, they have the advantages of easy operation and high precision. For patients, they have the advantages of less trauma, less pain, and quick recovery, and are widely accepted by doctors and patients.

[0003] The surgical robot includes a doctor's console and a patient surgical platform. The doctor's console includes a display screen and an operating unit, and the patient surgical platform includes one or more manipulator components, which include a manipulator and a medical device that can be detachably mounted on the manipulator. When in use, the doctor manipulates the operating unit to generate control instructions under the surgical field of view provided by the imaging device in the medical device displayed on the display screen, and the manipulator drives the medical device to perform surgical actions based on the control instructions.

[0004] With the increasing maturity of high-speed communication network technologies with low latency and high bandwidth, such as 5G and the Internet, remote surgical robot technology, which combines the advantages of surgical robot technology and high-speed communication network technology, has emerged. Remote surgical robot technology allows doctors to perform ultra-remote surgery on patients in different countries or provinces and cities, for example, to break through the constraints of space on the implementation of surgery to the greatest extent, and effectively alleviate the problem of uneven distribution of medical resources.

[0005] The remote surgical robot system includes a remote doctor console and a patient surgical platform, which are usually deployed in different countries, provinces, or different districts of the same city. Before implementing ultra-remote surgery, it is necessary to establish communication between the remote doctor console and the patient surgical platform. Especially when at least one of the remote doctor console and the patient surgical platform is deployed in large numbers, how to conveniently and reliably establish communication between the target remote doctor console and the target patient surgical platform has become a technical problem that needs to be solved urgently. Summary of the invention

[0006] Based on this, it is necessary to provide a method for interconnecting a remote surgical robot system and its equipment that can conveniently and reliably establish a pairing between a remote doctor console and a patient surgical platform.

[0007] In one aspect, the present disclosure provides a method for interconnecting devices, the method being applied to a first device in a remote surgical robot system, the system comprising a server, and the first device and a second device capable of communicating with the server, the first device comprising a remote doctor console and a patient surgical platform operable by the remote doctor console, the second device comprising the other of the remote doctor console and the patient surgical platform, the first device and the second device having a pairing relationship, the method comprising:

[0008] receiving device network information of the second device sent by the server, wherein the device network information includes information of a target network channel expected to be established with the second device;

[0009] Creating a target network channel with the second device based on the device network information;

[0010] The communication state of the target network channel is evaluated, and based on the evaluated communication state of the target network channel, it is determined whether pairing with the second device is successful.

[0011] The server determines the device network information that needs to be sent based on the control authority configured for the first device or the second device; or, the server determines the device network information that needs to be sent based on the medical and patient information configured for the first device or the second device, and the medical and patient information is associated with at least one of the core devices and auxiliary devices that need to establish a connection between the remote doctor console and the patient surgery platform.

[0012] Among them, the step of creating a target network channel between the second device based on the device network information includes: creating the target network channel of different communication protocol standards based on the different control permissions configured for the first device or the second device; when the control permission is observer permission, creating the corresponding target network channel based on the UDP protocol; when the control permission is operator permission, for the observer permission included in the operator permission, creating the corresponding target network channel based on the UDP protocol, and for other permissions included in the operator permission, creating the corresponding target network channel based on the TCP protocol.

[0013] The target network channel includes a first target network channel for transmitting high-priority network information, and a second target network channel for transmitting low-priority network information. The step of determining whether the pairing with the second device is successful based on the evaluated communication status of the target network channel includes: when it is evaluated that the communication status of the first target network channel is normal, determining that the pairing with the second device is successful.

[0014] Among them, the first target network channel includes a motion control network channel, an energy control network channel, and a video interaction network channel. When it is evaluated that the communication status of the motion control network channel, the energy control network channel, and the video interaction network channel are all normal, it is determined that the pairing with the second device is successful; when it is evaluated that the communication status of any one of the motion control network channel, the energy control network channel, and the video interaction network channel is abnormal, it is determined that the pairing with the second device has failed.

[0015] The communication status of the target network channel is evaluated by detecting the network connectivity or network communication quality of the target network channel, and the network communication quality is evaluated by at least one of network delay, jitter, packet loss and disorder.

[0016] The method further includes: when it is determined that the pairing with the second device is successful, according to different network communication qualities of the target network channel, allowing or prohibiting the use of corresponding control permissions, or allowing or prohibiting the implementation of corresponding surgical procedures.

[0017] Among them, when the first device is the remote doctor console, the second device is the patient surgical platform, and the control authority of the remote doctor console over the patient surgical platform is configured as operator authority, the method also includes: determining whether the pairing with the patient surgical platform is successful based on detecting the configuration of the operator authority of the patient surgical platform.

[0018] Among them, the method of determining whether the pairing with the patient surgical platform is successful based on detecting the configuration of the operator authority of the patient surgical platform includes: obtaining the ownership authority among the configured operator authorities; determining the controlled object from the patient surgical platform based on the first authority attribution of the ownership authority, the first authority attribution being associated with the controlled object in the patient surgical platform; determining the first target control instruction associated with the controlled object from a preset control instruction set, and sending the first target control instruction to the patient surgical platform; receiving the first actual execution result returned after the controlled object in the patient surgical platform executes the first target control instruction; detecting whether the first actual execution result matches the first expected execution result associated with the first target control instruction; when the first actual execution result matches the first expected execution result, determining that the ownership authority configuration is successful, and then determining that the pairing with the patient surgical platform is successful; or, when the first actual execution result does not match the first expected execution result, determining that the ownership authority configuration fails, and then determining that the pairing with the patient surgical platform fails.

[0019] Among them, the determination of whether the pairing with the patient surgical platform is successful based on detecting the configuration of the operator authority of the patient surgical platform includes: obtaining the unowned authority among the configured operator authorities; determining the uncontrolled object from the patient surgical platform based on the second authority attribution of the unowned authority, the second authority attribution being associated with the uncontrolled object in the patient surgical platform; determining the second target control instruction associated with the uncontrolled object from the preset control instruction set, and sending the second target control instruction to the patient surgical platform; receiving the second actual execution result returned after the uncontrolled object in the patient surgical platform executes the second target control instruction; detecting whether the second actual execution result matches the second expected execution result associated with the second target control instruction; when the second actual execution result matches the second expected execution result, determining that the unowned authority configuration is successful, and further determining that the pairing with the patient surgical platform is successful; or, when the second actual execution result does not match the second expected execution result, determining that the unowned authority configuration fails, and further determining that the pairing with the patient surgical platform fails.

[0020] On the other hand, the present disclosure provides a remote surgical robot system, which includes a server, and a first device and a second device that can communicate with the server, the first device includes one of a remote doctor console and a patient surgical platform that can be controlled by the remote doctor console, the second device includes the other of the remote doctor console and the patient surgical platform, the first device and the second device have a pairing relationship, and the first device is configured to implement the method described in any one of the above embodiments.

[0021] On the other hand, the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, and when the instructions are executed on at least one processor, the method described in any one of the above embodiments is implemented.

[0022] The disclosed remote surgical robot system and the method for interconnecting devices thereof have the following beneficial effects:

[0023] By creating a target network channel between the remote doctor console and the patient surgery platform and evaluating the communication status of the target network channel, it is possible to determine whether the remote doctor console and the patient surgery platform are successfully paired, which is conducive to ensuring that ultra-remote surgery can be implemented smoothly and reliably. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a structural schematic diagram of an embodiment of a master-slave surgical robot suitable for a remote surgical robot system disclosed in the present invention;

[0025] Figure 2For Figure 1 A schematic structural diagram of an embodiment of a surgical instrument of a master-slave surgical robot is shown;

[0026] Figure 3 It is a schematic structural diagram of another embodiment of a slave robot in a master-slave surgical robot suitable for a remote surgical robot system disclosed in the present invention;

[0027] Figure 4 It is a schematic structural diagram of another embodiment of a master-slave surgical robot suitable for a remote surgical robot system disclosed in the present invention;

[0028] Figure 5 A network topology diagram of an embodiment of a remote surgical robot system disclosed herein;

[0029] Figure 6 This is a schematic diagram of a pairing scenario of the remote surgical robot system disclosed in the present invention;

[0030] Figure 7 This is a flow chart of an embodiment of a device registration method disclosed herein;

[0031] Figure 8 It is a structural diagram of an embodiment of a custom protocol for inter-device communication disclosed in the present invention;

[0032] Fig. 9 A flowchart of an embodiment of a method for interconnecting devices disclosed herein;

[0033] Fig.10 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0034] Fig.11 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0035] Fig.12 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0036] Figure 13~Figure 15 A schematic diagram of an interactive interface of an embodiment of a method for interconnecting devices disclosed herein;

[0037] Figure 16~Figure 19 A schematic diagram of an interactive interface of another embodiment of the method for interconnecting devices disclosed herein;

[0038] Figure 20~Figure 22 A schematic diagram of an interactive interface of another embodiment of the method for interconnecting devices disclosed herein;

[0039] Fig.23 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0040] Fig.24 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0041] Figure 25~Figure 28 A schematic diagram of an interactive interface of an embodiment of a method for interconnecting devices disclosed herein;

[0042] Figure 29~Figure 31 A schematic diagram of an interactive interface of another embodiment of the method for interconnecting devices disclosed herein;

[0043] Figure 32~Figure 34 A schematic diagram of an interactive interface of another embodiment of the method for interconnecting devices disclosed herein;

[0044] Fig.35 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0045] Fig.36 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0046] Fig.37 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0047] Fig.38 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0048] Fig.39 A flowchart of another embodiment of the method for interconnecting devices disclosed herein;

[0049] Fig.40 The present invention is a flow chart of another embodiment of the method for interconnecting devices disclosed herein. DETAILED DESCRIPTION

[0050] In order to facilitate the understanding of the present disclosure, the present disclosure will be described more comprehensively below with reference to the relevant drawings. The preferred embodiments of the present disclosure are given in the drawings. However, the present disclosure can be implemented in many different forms and is not limited to the embodiments described in the present disclosure. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present disclosure more thoroughly and comprehensively understood.

[0051] It should be noted that when an element is referred to as being "disposed on" another element, it may be directly on the other element or there may also be a centered element. When an element is considered to be "connected" to another element, it may be directly connected to the other element or there may be a centered element at the same time. When an element is considered to be "coupled" to another element, it may be directly coupled to the other element or there may be a centered element at the same time. The terms "vertical", "horizontal", "left", "right" and similar expressions used in this disclosure are only for illustrative purposes and do not represent the only implementation method. The terms "end" and "proximal end" used in this disclosure are used as directional words, which are commonly used terms in the field of medical devices, wherein the "end" refers to the end away from the operator during surgery, and the "proximal end" refers to the end close to the operator during surgery. The terms "first / second" and the like used in this disclosure represent a component and a class of more than two components with common characteristics.

[0052] Unless otherwise defined, all technical and scientific terms used in this disclosure have the same meaning as those commonly understood by those skilled in the art to which this disclosure belongs. The terms used in this disclosure are only for the purpose of describing specific embodiments and are not intended to limit this disclosure. The term "and / or" used in this disclosure includes any and all combinations of one or more related listed items. The term "multiple" used in this disclosure includes two or more.

[0053] The remote surgical robot system disclosed in the present invention includes a master-slave surgical robot suitable for performing ultra-remote surgery. The master-slave surgical robot includes a remote doctor console and a patient surgical platform. The patient surgical platform may include different types of slave robots, including but not limited to a single-port laparoscope slave robot, a multi-port laparoscope slave robot, a bronchial interventional slave robot, a vascular interventional slave robot, and an orthopedic slave robot. Different types of slave robots have different structural characteristics and may be the same or different in terms of the applicability of surgical types.

[0054] For example, in Figure 1 The master-slave surgical robot shown includes a remote doctor console 100 and a patient surgical platform 200, wherein the patient surgical platform 200 includes a single-port laparoscope slave robot. The remote doctor console 100 is used to send control commands to the patient surgical platform 200 according to the doctor's operation to control the patient surgical platform 200, and is also used to display the images obtained by the patient surgical platform 200. The patient surgical platform 200 is used to respond to the control commands sent by the remote doctor console 100 and perform corresponding operations, and the patient surgical platform 200 is also used to obtain images in the body.

[0055] The patient surgical platform 200 includes a robot arm 210 and a manipulator assembly disposed on the robot arm 210. The manipulator assembly includes a manipulator 220 disposed on the robot arm 210 and a Figure 2 The surgical instrument 230 shown. The patient surgical platform 200 also includes a puncture device 240 that is sheathed around the long axis 231 of the surgical instrument 230. When the patient surgical platform 200 responds to the control command of the remote doctor console 100, the robotic arm 210 is used to adjust the posture of the surgical instrument 230, the manipulator 220 is used to drive the surgical instrument 230 to perform corresponding operations, and the end effector 232 of the surgical instrument 230 is used to extend into the body and perform surgical operations and / or obtain in-body images through the end instrument at the distal end.

[0056] Figure 3 Another patient surgical platform is illustrated, the patient surgical platform 200' includes a multi-hole laparoscope slave robot. The patient surgical platform 200' includes a robotic arm and a plurality of manipulator assemblies 230' arranged on the robotic arm, the robotic arm includes a main arm 210' and a plurality of adjustment arms 220' arranged on a directional platform 215' in the main arm 210', and different manipulator assemblies 230' are arranged on different adjustment arms 220'. The main arm 210' can adjust the posture of the adjustment arm 220' and the manipulator assembly 230', and the adjustment arm 220' can adjust the posture of the manipulator assembly 230'. The manipulator assembly 230' includes a manipulator 240' and a medical device 250' detachably mounted on the manipulator 240'. The manipulator assembly 230' includes a parallelogram mechanism, and by using the parallelogram principle, it can be limited that the manipulator 240' can perform rotational motion around a remote motion center (i.e., Remote Center, RC). Multiple medical devices 250 ′ can be inserted into the patient's body through different puncture devices 500 ′ respectively. Figure 1 The remote physician console 100 shown can also be used to operate Figure 3 The movement of the manipulator assembly 230' is shown in the patient surgical platform 200'.

[0057] For example, in Figure 4An interventional surgical robot 300 is shown, which is also a trans-natural cavity surgical robot, including a remote doctor console and a patient surgical platform 320, wherein the remote doctor console includes a handle 310' and an imaging vehicle 330 connected to each other, and / or the patient surgical platform 320 also includes an imaging vehicle 330. The patient surgical platform 320 is connected with a catheter instrument 340, and is connected with a sensor system 350, and a control system 360 for realizing control between the catheter instrument 340, the sensor system 350 and the imaging vehicle 330. When the doctor performs various procedures on the patient next to the patient surgical platform 320, he can trigger the control command by operating the handle 310' and send it to the patient surgical platform 320 for driving, thereby controlling the catheter instrument 340 to advance, retract, bend and turn, etc.

[0058] The patient surgical platform 320 can usually be moved to the side of the surgical bed to engage the catheter instrument 340, and under the control command, the catheter instrument 340 is controlled to move up and down in the vertical direction, or to translate in the horizontal direction, or to move in non-vertical and non-horizontal directions, so as to provide a better preoperative preparation angle for the operation of the catheter instrument 340. The control command can be a command triggered by the doctor operating the patient surgical platform 320, or a command triggered by the doctor directly clicking or pressing a button set on the patient surgical platform 320. Of course, in other embodiments, the control command can also be a command triggered by voice control or a force feedback mechanism.

[0059] like Figure 4 As shown, further, the patient surgical platform 320 may include a base 321, a sliding seat body 322 that can be lifted and moved along the base 321, and two mechanical arms 323 fixedly connected to the sliding seat body 322. The mechanical arm 323 may include a plurality of arm segments connected at a joint, and the plurality of arm segments provide the mechanical arm 323 with a plurality of degrees of freedom, for example, seven degrees of freedom corresponding to the seven arm segments. A manipulator (not shown in the figure) is installed at the end of the mechanical arm 323, and the manipulator of the mechanical arm 323 is used to engage the catheter instrument 340, and under the driving action of the manipulator, the end of the catheter instrument 340 is controlled to bend and turn accordingly. Among them, the two mechanical arms 323 may be structures that are completely the same or partially the same, one mechanical arm 323 is used to engage the inner catheter instrument 341, and the other mechanical arm 323 is used to engage the outer catheter instrument 342. During installation, the outer catheter device 342 may be installed first, and when the outer catheter device 342 is installed, the catheter of the inner catheter device 341 may be inserted into the catheter of the outer catheter device 342 .

[0060] The sensor system 350 has one or more subsystems for receiving information about the catheter device 340. The subsystems may include: a position sensor system; a shape sensor system for determining the position, orientation, speed, velocity, pose, and / or shape of the tip of the catheter device 340 and / or along one or more segments of the catheter that may constitute the catheter device 340; and / or a visualization system for capturing images from the tip of the catheter device 340.

[0061] The imaging vehicle 330 may be provided with a display system 331 and a flushing system (not shown in the figure), etc. The display system 331 is used to display images or representations of the surgical site and the catheter instrument 340 generated by the subsystem of the sensor system 350. Real-time images of the surgical site and the catheter instrument 340 captured by the visualization system may also be displayed. Images of the surgical site recorded before or during surgery may also be presented using image data from imaging technologies such as computed tomography (CT), magnetic resonance imaging (MRI), optical coherence tomography (OCT), and ultrasound, etc.

[0062] Wherein, the preoperative or intraoperative image data may be presented as a two-dimensional, three-dimensional, or four-dimensional (e.g., time-based or rate-based) image and / or as an image from a model created based on the preoperative or intraoperative image data set, and a virtual navigation image may also be displayed. In the virtual navigation image, the actual position of the catheter device 340 is registered with the preoperative image to present a virtual image of the catheter device 340 within the surgical site to the operator from the outside.

[0063] The control system 360 includes at least one memory and at least one processor. It is understood that the control system 360 can be integrated into the patient surgical platform 320 or the imaging vehicle 330, or can be independently provided. The control system 360 can support wireless communication protocols such as IEEE 802.11, IrDA, Bluetooth, HomeRF, DECT, and wireless telemetry. The control system 360 can transmit one or more signals indicating movement of the catheter instrument 340 by the manipulator to move the catheter instrument 340. The catheter instrument 340 can extend to a surgical site in the body via an opening of a natural cavity or a surgical incision of the patient.

[0064] Furthermore, the control system 360 may include a mechanical control system (not shown in the figure) and an image processing system (not shown in the figure), wherein the mechanical control system is used to control the movement of the catheter device 340, and thus, may be integrated into the patient surgical platform 320. The image processing system is used for virtual navigation path planning, and thus, may be integrated into the imaging vehicle 330. Of course, the various subsystems of the control system 360 are not limited to the specific situations listed above, and may also be reasonably set according to actual conditions.

[0065] The image processing system can image the surgical site using the above imaging technology based on the image of the surgical site recorded before or during the operation. The recorded image can also be converted into a two-dimensional or three-dimensional synthetic image of a part or the entire anatomical organ or segment by software used in combination with manual input. During the virtual navigation procedure, the sensor system 350 can be used to calculate the position of the catheter instrument 340 relative to the patient's anatomical structure, which can be used to generate an external tracking image and an internal virtual image of the patient's anatomical structure, so as to achieve the actual position of the catheter instrument 340 and the preoperative image registration, so that the virtual image of the catheter instrument 340 in the surgical site can be presented to the operator from the outside.

[0066] The structural composition of the inner catheter device 341 and the outer catheter device 342 is substantially the same, and each comprises a slender and flexible inner catheter 41 and an outer catheter 42, wherein the diameter of the outer catheter 42 is slightly larger than that of the inner catheter 41, so that the inner catheter 41 can pass through the outer catheter 42 and provide a certain support for the inner catheter 41, so that the inner catheter 41 can reach the target position in the patient's body, so as to facilitate operations such as tissue or cell sampling from the target position.

[0067] Certain movements of the handle 310 may cause corresponding movements of the catheter instrument 340. For example, when the doctor operates the direction lever of the handle 310 to move upward or downward, the movement of the direction lever of the handle 310 may be mapped to the corresponding pitch movement of the end of the catheter instrument 340; when the doctor operates the direction lever of the handle 310 to move left or right, the movement of the direction lever of the handle 310 may be mapped to the corresponding yaw movement of the end of the catheter instrument 340. In this embodiment, the handle 310 may control the end of the catheter instrument 340 to move within a 360° spatial range.

[0068] The remote surgical robot system disclosed in the present invention also includes a server. Figure 5As shown, the remote doctor consoles A1~A3 and patient surgical platforms B1~B3 of the same or different master-slave surgical robots are respectively connected to the server S to communicate with the server S. The server S can be used to manage the information sent by the remote doctor consoles A1~A3 and the patient surgical platforms B1~B3, and can be used to transfer the transmission of information between the remote doctor consoles A1~A3 and the patient surgical platforms B1~B3. The server S can also be used to realize the device interconnection (i.e. pairing) between the remote doctor consoles A1~A3 and the patient surgical platforms B1~B3. Pairing includes the connection between two devices to achieve communication.

[0069] In ultra-tele-surgery, the remote doctor console and the patient surgery platform are deployed in different locations. For example, they can be deployed in different countries, different provinces, or different jurisdictions in the same city.

[0070] The server may also be deployed at a location different from any of the remote doctor console and the patient surgery platform. For example, the server, the remote doctor console, and the patient surgery platform may be deployed in different cities. The server may also be deployed at the same location as one of the remote doctor console and the patient surgery platform. For example, the server may be deployed independently of the remote doctor console or the patient surgery platform located at the same location. For another example, the server may be integrated with the remote doctor console or the patient surgery platform located at the same location. It is understandable that the server may also be deployed in the cloud.

[0071] In the remote surgical robot system disclosed in the present invention, at least one remote doctor console, one patient surgical platform and one server are deployed respectively.

[0072] The remote doctor console may include at least one, the patient operation platform may include at least one, and the server may also include at least one.

[0073] When there is one server, each remote doctor console and each patient surgical platform are connected to the one server. When there are multiple servers, the servers are connected through a network topology structure, and different remote doctor consoles and different patient surgical platforms can be connected to any of the same or different servers. The network topology structure between multiple servers includes at least one of a star topology, a ring topology, a bus topology, a tree topology, a mesh topology, a virtual local area network, and a wireless topology.

[0074] The remote doctor console and the server, the patient surgery platform and the server, and the servers can be connected through the same type or different types of high-speed communication networks. For example, these types of high-speed communication networks may include at least one of Internet broadband, Internet private network, 5G network, and 5G private network.

[0075] For example, the remote doctor consoles A1~A3 and the patient surgical platforms B1~B3 can realize one-to-one, one-to-many and many-to-one communication under the action of the server S. The paired remote doctor consoles and the patient surgical platforms can communicate end-to-end without the need for the server's transfer function. For example, these pairings can be understood from the perspective of the remote doctor console, such as Figure 6 As shown:

[0076] One-to-one pairing means that one remote doctor console is paired with one patient surgical platform. For example, remote doctor consoles A2 and A3 are paired with only one patient surgical platform, such as A2 paired with B2, or A3 paired with B1. Therefore, A2 and A3 are paired one-to-one.

[0077] One-to-many pairing refers to a pairing of a remote doctor console with multiple patient surgical platforms. For example, for remote doctor console A1, it is paired with patient surgical platforms B2 and B3 at the same time, so for A1, it is a one-to-many pairing.

[0078] Many-to-one pairing refers to the pairing of multiple remote doctor consoles with one patient surgical platform. For example, remote doctor consoles A1 and A2 are paired with one patient surgical platform B2 at the same time, so for A1 and A2, they belong to many-to-one pairing.

[0079] <Device Registration>

[0080] There are many types and models of remote doctor consoles and patient surgical platforms, and there are also many counterfeit and shoddy products. Inappropriate pairing of remote doctor consoles and patient surgical platforms can easily lead to surgical risks. In order to minimize the surgical risks that may be caused by inappropriate pairing between remote doctor consoles and patient surgical platforms, remote doctor consoles or patient surgical platforms that are not allowed to be paired (i.e., not allowed to be used) can be filtered out by using device registration. That is, only remote doctor consoles and patient surgical platforms that have completed registration on the server are allowed to be used for pairing.

[0081] The remote doctor console and the patient surgery platform are registered to the server in the same way. To simplify the description, any remote doctor console and any patient surgery platform can be described as a device. Figure 7 , the method of registering the device to the server includes:

[0082] 101. After the device establishes a connection with the server, the device sends a registration request to the server.

[0083] The process of establishing a connection between the device and the server includes: the device sends a connection request to the server; the server receives the connection request sent by the device, attempts to establish a connection with the device, and returns a connection status to the device. When the returned connection status is a successful connection, the device and the server establish a long connection; otherwise, the device and the server do not establish a long connection. When the returned connection status is a failed connection, the connection process can be re-executed.

[0084] 102. The server receives a registration request sent by the device, and authenticates the registration request based on a judgment rule agreed upon between the server and the device.

[0085] 103. In response to the server determining that the authentication is successful, the server accepts the registration of the device and returns a registration success status to the device.

[0086] The server may maintain registration information of registered devices through a registration list or the like, and the registration information includes device information of these devices.

[0087] 104. In response to the server determining that the authentication fails, the server rejects the registration of the device and returns a registration failure status to the device.

[0088] In some embodiments, in 102, the agreed judgment rule includes a first judgment rule, and the first judgment rule includes a custom protocol agreed upon between the device and the server. The custom protocol includes a protocol header and a protocol body, the protocol header is the message header, and the protocol body is the message data part. For different custom protocols, the format specified by the protocol header is usually the same, but the format specified by the protocol body is usually different. The difference in the protocol body can be reflected in that the fields included therein have at least one difference in the number of fields, field type, field arrangement order, and data exchange format. Figure 8 It illustrates a custom protocol based on TCP protocol.

[0089] The registration request is a data message encapsulated in the format specified by the custom protocol. After receiving the registration request, the server decapsulates the registration request according to the format specified by the agreed custom protocol. If the decapsulation is successful, it can be determined that the authentication is successful; if the decapsulation fails, it can be determined that the authentication fails.

[0090] When the device is in the initial state, for example, before the device is registered with the server, different devices only store the device information of the local end and the device information of the server. The device registration request includes the device information of the server and the device information of the local end. The device information of the server includes at least one of the IP address and port number of the server. The device information of the local end of the device includes the basic device information and the network information of the device. The basic device information includes at least one of the unique device identifier (ID or UDID) of the device, the device name (name), the device type (type), the manufacturer name (manufacture), the device function (function), the suitable operation type (operation type), and the device location (position). The network information of the device includes at least one of the IP address and port number of the device.

[0091] The device registration request is encapsulated into a data message according to the format specified by the custom protocol. Taking the custom protocol as the TCP protocol as an example, the port number of the server and the port number of the device are encapsulated in the protocol header, and other device information of the device is encapsulated in the protocol body. The protocol body includes multiple fields, and the device information of the device is stored under the corresponding fields. For example, these fields include at least one of the device unique identifier (ID or UDID), device name (name), device type (type), device manufacturer name (manufacture), device function (function), and IP address. The fields of the protocol body can also include a timestamp (time) field, which is used to store the time when the device registration request is sent to the server.

[0092] In some embodiments, different devices can communicate through the same or different custom protocols. For example, the remote doctor console and the server can communicate through an agreed first custom protocol; the patient surgery platform and the server can communicate through an agreed second custom protocol; the remote doctor console and the patient surgery platform can communicate through an agreed third custom protocol. The three custom protocols can be the same or different. In some embodiments, a remote doctor console can be configured to support communication with multiple patient surgery platforms respectively through the same or different custom protocols, and a patient surgery platform can also be configured to support communication with multiple remote doctor consoles respectively through the same or different custom protocols.

[0093] In some embodiments, for example, when the remote doctor console or the patient surgical platform communicates with the server through an agreed custom protocol, the protocol body of the custom protocol may include at least one field for storing the custom protocol supported by the remote doctor console or the patient surgical platform for pairing. In 103, when the server accepts the registration of the device, the custom protocol that the corresponding device can support for pairing may also be stored in the server.

[0094] Take an example to illustrate the field device function in the protocol body. For the remote doctor console, the device function includes operable functions; for the patient surgery platform, the device function includes operable functions. The device functions of different remote doctor consoles or different patient surgery platforms may be the same or different. The remote doctor console and patient surgery platform that are expected to be used in pairing must at least match the device core functions in the device functions before they are allowed to be paired. Exemplarily, the device core functions include at least one of motion control functions and energy control functions, both of which are related to the device hardware conditions. Only when the corresponding device hardware conditions are met can the implementation of the corresponding core functions be supported. For example, for the patient surgical platform, including the slave hand robot and the energy platform, the patient surgical platform supports motion control functions based on the slave hand robot and supports energy control functions based on the energy platform; for the remote doctor console, including the hand operation part and the foot pedal part, the remote doctor console supports motion control functions based on the hand operation part and supports energy control functions based on the foot pedal part; for the patient surgical platform, if the remote doctor console cannot support motion control functions or energy control functions due to the limitations of its equipment hardware conditions, it may not be allowed to pair with the patient surgical platform, or, from the perspective of control authority, at least it is not allowed to be configured to have full operator control authority over the patient surgical platform, and it may have observer authority at this time. In some embodiments, the motion control function or energy control function can be further classified, and the core function of the device corresponds to a more specific core function. The remote doctor console and the patient surgical platform that are expected to be paired need to match at least in the more specific core function before they are allowed to be paired. Of course, this is also closely related to the equipment hardware conditions of the device, and will not be elaborated here. Among them, the device functions including the core functions of the device under the device function field can be recorded by associated coding, such as digital records. Among the device functions, different flag records can be added to the device core functions and the device non-core functions to facilitate the matching of the device core functions.

[0095] In 103, the server accepts the registration of the device, and the server stores the registration information of the device, which includes data stored in at least some fields in the custom protocol body, such as one or more of device information, custom protocols supported by the device for pairing, etc., for use in subsequent pairing. After 103, after the server accepts the registration of the device, a login password can be assigned to the device, which is used for simple authentication when the device subsequently logs in to the server, so that the server no longer needs to authenticate the device based on the agreed judgment rules such as custom protocols or encryption algorithms.

[0096] In some embodiments, the agreed judgment rule may include a second judgment rule, and the second judgment rule includes an encryption algorithm agreed upon between the device and the server. The registration request may be a data message encapsulated according to a format specified by a custom protocol, or may be a data message encapsulated according to a format specified by a general protocol. In some embodiments, the encryption algorithm may encrypt at least part of the data in the protocol body in the data message to generate a first check value, and the first check value is stored in the authentication field of the protocol body, wherein the data in the protocol body may not include the data stored in the authentication field. After receiving the registration request, the server decapsulates the registration request according to the format specified by the custom protocol or the general protocol to obtain all the data of the data message, and the server may encrypt the data in the protocol body based on the agreed encryption algorithm to generate a second check value. The server detects whether the first check value and the second check value are the same. If they are the same, it indicates that the data is complete and legal, and the authentication can be determined to be successful; if they are different, it indicates that the data is missing or illegal, and the authentication can be determined to be failed.

[0097] Alternatively, when the encryption algorithm is reversible, the server may not generate the second verification value, but instead, based on the inverse solution of the encryption algorithm, directly decrypt the first verification value stored in the authentication field obtained by decapsulating the registration request to obtain verification data. The server compares the verification data obtained by decryption with at least part of the corresponding data in the protocol body. If they are the same, it indicates that the data is complete and legal, and it can be determined that the authentication is successful; if they are different, it indicates that the data is missing or illegal, and it can be determined that the authentication has failed.

[0098] Exemplarily, the encryption algorithm may be a base64 encryption algorithm or a hash algorithm. The data used for encryption in the protocol body may be data of all fields in the protocol body, or data of fields selected according to a certain rule. Such a rule may be, for example, fields selected at intervals from each other, or the first few consecutive fields, or the last few consecutive fields, etc. In one example, one or more of the device information of the associated device in the protocol body may be selected for encryption. For example, the unique identifier, device name, and timestamp in the protocol body may be selected as the data of the field to be encrypted. In one example, the data of the selected fields may be concatenated into a string and then subjected to the encryption process.

[0099] In some embodiments, the registration request can be double-authenticated in combination with the first judgment rule and the second judgment rule, which can prevent unauthorized devices from being allowed to access the remote surgical robot system described in the present disclosure, thereby ensuring the safety and reliability of remote surgery.

[0100] In the scenario of double authentication, the registration request is usually a data message encapsulated according to the format specified by the custom protocol. The server decapsulates the registration request based on the format specified by the custom protocol and performs the first authentication. If the decapsulation is successful, it is determined that the first authentication is successful and enters the second authentication; if the decapsulation fails, it is determined that the first authentication has failed, and the second authentication will not be entered, and the server will reject the device registration. In the second authentication, the server encrypts the data in the protocol body based on the agreed encryption algorithm to generate a second check value. The server detects whether the first check value and the second check value stored in the authentication field in the data message corresponding to the registration request are the same. If they are the same, it can be determined that the second authentication is successful. When both authentications are successful, the server will accept the device registration; if they are different, it can be determined that the second authentication has failed, and the server will reject the device registration.

[0101] Alternatively, in the second authentication, as described above, the server may not generate the second verification value, but instead, based on the inverse solution of the encryption algorithm, directly decrypt the first verification value stored in the authentication field obtained by decapsulating the registration request to obtain verification data. The server compares the verification data obtained by decryption with at least part of the corresponding data in the protocol body. If they are the same, the authentication is determined to be successful; if they are different, the authentication is determined to have failed.

[0102] In some embodiments, the patient surgical platform may include multiple types. When the same remote doctor console manipulates different patient surgical platforms to perform the same or different types of operations, the types of data exchanged between the remote doctor console and the patient surgical platform may be different. The remote doctor console may also include multiple types. When different remote doctor consoles manipulate the same patient surgical platform to perform the same or different types of operations, the types of data exchanged between the remote doctor console and the patient surgical platform may also be different. Among them, the different types of data exchanged between the remote doctor console and the patient surgical platform can be reflected in the different field types in the protocol body of the custom protocol. It can be understood that due to the different field types in the protocol body, the custom protocols including the protocol body are also different.

[0103] In some embodiments, the server can be used as an open platform for a variety of remote doctor consoles and a variety of patient surgery platforms. The server and different devices can agree on different judgment rules for authentication during registration. As long as the device can be successfully authenticated, it can be allowed to register and subsequently paired for ultra-remote surgery. For example, when the judgment rules include custom protocols, different judgment rules correspond to different custom protocols. For another example, when the judgment rules include encryption algorithms, different judgment rules correspond to different encryption algorithms, where using encryption algorithms with the same name to encrypt data corresponding to different field types can be understood as different encryption algorithms.

[0104] Taking the example of the server using a custom protocol to authenticate the registration request sent by the device, when the server receives the registration request sent by any device, it does not know whether the server and the device have agreed on a custom protocol, nor does it know which custom protocol has been agreed upon. Therefore, the server usually needs to call all its known custom protocols to try to decapsulate the registration request sent by the current device. If the registration request can be decapsulated based on a certain custom protocol, it is determined that the authentication is successful; if the registration request cannot be decapsulated based on any custom protocol, it is determined that the authentication has failed.

[0105] Exemplarily, after receiving the registration request, the server may try to decapsulate the registration request using all known custom protocols in order. In some embodiments, it is assumed that the device includes a first device and a second device, the judgment rule agreed upon by the first device and the server is a first custom protocol, the judgment rule agreed upon by the second device and the server is a second custom protocol, and all known custom protocols include the first custom protocol and the second custom protocol. When receiving the registration request, the server may first try to decapsulate the currently received registration request using the first custom protocol, and if the decapsulation fails, then try to decapsulate the currently received registration request using the second custom protocol.

[0106] For example, after the server receives the first registration request sent by the first device, the server first decapsulates the first registration request based on the first custom protocol. At this time, the decapsulation is successful, and it is determined that the authentication is successful. For another example, after the server receives the second registration request sent by the second device, the server first decapsulates the second registration request based on the first custom protocol. At this time, the decapsulation fails. The server then decapsulates the second registration request based on the second custom protocol. At this time, the decapsulation is successful, and it is determined that the authentication is successful. For another example, the server may also receive a third registration request sent by a third device. However, the third device may not have agreed on a custom protocol with the server. In this case, after the server receives the third registration request sent by the third device, the server first decapsulates the third registration request based on the first custom protocol. At this time, the decapsulation fails. The server then decapsulates the third registration request based on the second custom protocol. At this time, the decapsulation still fails, and it is determined that the authentication failed.

[0107] In some embodiments, the core equipment of the patient surgical platform includes a hand robot, an imaging platform and an energy platform. The hand robot includes a manipulator and a medical device mounted on the manipulator, and the remote doctor console controls the movement of the medical device by controlling the movement of the manipulator. The imaging platform is used to process multimedia data, such as processing video or audio. The video can be derived from an imaging device in a medical device such as an endoscope; the audio can be derived from the remote doctor console or the sound input from the hand robot, including voice intercom. The energy platform is used to control the energy device in the medical device. The energy device can be, for example, an electric knife, an ultrasonic knife, a microwave ablation knife, a radiofrequency ablation knife, a stapler, a plasma knife, etc. The imaging platform and the energy platform can be placed separately or integrated on a movable trolley. For the convenience of description, the imaging platform and the energy platform can be collectively referred to as an image energy processing platform. In some embodiments, the patient surgical platform can also include auxiliary equipment, such as a monitor, a ventilator, a CT machine, an EM electromagnetic positioning system, a pneumoperitoneum machine, an operating table, or a shadowless lamp.

[0108] Generally, the type of remote surgical robot system can depend on the type of slave robot in the master-slave surgical robot, and different slave robots usually have different structural characteristics. The various types of slave robots include but are not limited to single-port laparoscope slave robots, multi-port laparoscope slave robots, bronchial interventional slave robots, vascular interventional slave robots, and orthopedic slave robots.

[0109] In some embodiments, the type of the remote doctor console may depend on the type of the operating unit, which is used to control the actions of the medical device in the hand robot, including motion control, clamping control, cutting control, coagulation control, suturing control, etc. The operating unit includes a hand operating unit, and the types of the hand operating unit include but are not limited to an operating unit in the form of a game handle, an operating unit in the form of a mechanical linkage, an operating unit in the form of a magnetic navigation, an operating unit in the form of a trackball, etc.

[0110] In some embodiments, remote doctor consoles and patient surgical platforms that are not registered with the server or have different communication protocols are generally prohibited from pairing. Pairing requires the same communication protocol, which generally refers to the same custom protocol, mainly including the same format specified by the custom protocol.

[0111] In some embodiments, remote doctor consoles and patient surgical platforms that are registered with the server and have the same communication protocol are generally allowed to be paired. Regardless of the differences in the types of remote doctor consoles or patient surgical platforms, the remote doctor console and patient surgical platform can be paired when the basic conditions that the remote doctor console and the patient surgical platform have been registered with the server and have the same communication protocol are met.

[0112] In some embodiments, a custom protocol can be agreed upon between a type of remote physician console and a type of patient surgical platform so that the type of remote physician console is specifically used to be paired with the type of patient surgical platform, that is, the remote physician console is specifically used to manipulate a specific type of patient surgical platform.

[0113] In some embodiments, the same custom protocol can be agreed upon between one type of remote physician console and multiple types of patient surgical platforms, or multiple custom protocols can be agreed upon separately, so that this type of remote physician console can also be universally used in pairing with multiple types of patient surgical platforms, that is, the remote physician console can be universally used to manipulate multiple specific types of patient surgical platforms.

[0114] Exemplarily, a remote doctor console manufactured by a manufacturer can be configured to be used to manipulate one or more types of patient surgical platforms manufactured by the manufacturer or other manufacturers. For example, manufacturer A manufactures a universal remote doctor console A1, and manufactures a first type of patient surgical platform A2 and a second type of patient surgical platform A3. The first type of patient surgical platform A2 is, for example, a patient surgical platform with a single-port laparoscope slave robot, and the second type of patient surgical platform A3 is, for example, a patient surgical platform with a multi-port laparoscope slave robot. The same custom protocol can be agreed upon between the remote doctor console A1 and the patient surgical platforms A2 and A3, or different custom protocols can be agreed upon respectively. The remote doctor console A1 can be configured to manipulate one or more of the patient surgical platforms A2 and A3.

[0115] Exemplarily, remote doctor consoles manufactured by different manufacturers can be configured to be specifically used to manipulate one or more types of patient surgical platforms manufactured by each manufacturer. For example, manufacturer B manufactures a remote doctor console B1, and manufactures a patient surgical platform B2 of the first type and a patient surgical platform B3 of the second type, and the same custom protocol, such as the first custom protocol, can be agreed upon between the remote doctor console B1 and the patient surgical platforms B2 and B3; manufacturer C manufactures a remote doctor console C1, and manufactures a patient surgical platform C2 of the first type and a patient surgical platform C3 of the second type, and the same custom protocol, such as the second custom protocol, can be agreed upon between the remote doctor console C1 and the patient surgical platforms C2 and C3, which is different from the first custom protocol; remote doctor consoles B1 and C1 are, for example, both remote doctor consoles with mechanical linkage type operating parts, patient surgical platforms B2 and C2 are, for example, both single-port laparoscope slave robots, and patient surgical platforms B3 and C3 are, for example, both multi-port laparoscope slave robots. The remote doctor console B1 manufactured by manufacturer B can only be configured to be used exclusively for manipulating one or more of the patient surgical platforms B2 and B3 manufactured by manufacturer B, but cannot be configured to be used to manipulate the patient surgical platforms C2 and C3 manufactured by manufacturer C. At the same time, the remote doctor console C1 manufactured by manufacturer C can only be configured to be used exclusively for manipulating one or more of the patient surgical platforms C2 and C3 manufactured by manufacturer C, but cannot be configured to be used to manipulate the patient surgical platforms B2 and B3 manufactured by manufacturer B.

[0116] Exemplarily, remote doctor consoles manufactured by different manufacturers can be configured to be used to manipulate one or more types of patient surgical platforms manufactured by different manufacturers. Assume that manufacturer B manufactures a remote doctor console B1, and manufactures a patient surgical platform B2 of the first type and a patient surgical platform B3 of the second type; manufacturer C manufactures a remote doctor console C1, and manufactures a patient surgical platform C2 of the first type and a patient surgical platform C3 of the second type; remote doctor consoles B1 and C1 are, for example, both remote doctor consoles with mechanical linkage type operating parts, patient surgical platforms B2 and C2 are, for example, both single-port laparoscope slave robots, and patient surgical platforms B3 and C3 are, for example, both multi-port laparoscope slave robots. For example, a first custom protocol is agreed upon between the remote doctor console B1 and patient surgical platforms B2, B3, C2, and C3, and in the remote A second custom protocol is agreed upon between the doctor console C1 and the patient surgical platforms B2, B3, C2, and C3. The first custom protocol may be the same as or different from the second custom protocol. The remote doctor console B1 manufactured by manufacturer B may be configured to be capable of manipulating one or more of the patient surgical platforms B2 and B3 manufactured by it, and at the same time, may also be configured to be capable of manipulating one or more of the patient surgical platforms C2 and C3 manufactured by manufacturer C; the remote doctor console C1 manufactured by manufacturer C may be configured to be capable of manipulating one or more of the patient surgical platforms C2 and C3 manufactured by it, and at the same time, may also be configured to be capable of manipulating one or more of the patient surgical platforms B2 and B3 manufactured by manufacturer B.

[0117] In some embodiments, a custom protocol may be agreed upon between one type of patient surgical platform and one type of remote physician console, or multiple custom protocols may be agreed upon between one type of patient surgical platform and multiple types of remote physician consoles, so that the type of patient surgical platform can also be configured to be operated by one or more remote physician consoles of this type.

[0118] Exemplarily, a patient surgery platform manufactured by a manufacturer can be configured to be manipulated by one or more types of remote doctor consoles manufactured by the manufacturer or other manufacturers. For example, manufacturer A manufactures a first type of patient surgery platform A1, and manufacturer A also manufactures a first type of remote doctor console A2 and a second type of remote doctor console A3. The first type of remote doctor console A2 can be, for example, a remote doctor console with an operating unit in the form of electromagnetic navigation, and the second type of remote doctor console A3 can be, for example, a remote doctor console with an operating unit in the form of a mechanical linkage. The same custom protocol can be agreed upon between the patient surgery platform A1 and the remote doctor consoles A2 and A3, or different custom protocols can be agreed upon respectively, and the patient surgery platform A1 can be configured to be manipulated by one or more of the remote doctor consoles A2 and A3.

[0119] Exemplarily, the patient surgical platforms manufactured by different manufacturers can be configured to be manipulated only by one or more types of patient surgical platforms manufactured by each manufacturer. For example, manufacturer B manufactures a first type of patient surgical platform B1, and manufacturer B also manufactures a first type of remote doctor console B2 and a second type of remote doctor console B3. The same custom protocol, such as the first custom protocol, can be agreed between the patient surgical platform B1 and the remote doctor consoles B2 and B3; manufacturer C manufactures a first type of patient surgical platform C1, and manufacturer B also manufactures a first type of remote doctor console C2 and a second type of remote doctor console C3. The same custom protocol, such as the second custom protocol, can be agreed between the patient surgical platform C1 and the remote doctor consoles C2 and C3, which is different from the first custom protocol; patient surgical platforms B1 and C1 can be, for example, single-port laparoscopic slave robots, remote doctor consoles B2 and C2 can be, for example, remote doctor consoles with operating parts in the form of electromagnetic navigation, and remote doctor consoles B3 and C3 can be, for example, remote doctor consoles with operating parts in the form of mechanical linkages. Patient surgical platform B1 can only be configured to be manipulated by one or more of remote doctor consoles B2 and B3. Meanwhile, the patient surgery platform C1 can only be configured to be manipulated by one or more of the remote physician consoles C2 and C3.

[0120] Exemplarily, patient surgical platforms manufactured by different manufacturers can be configured to be manipulated by one or more types of remote doctor consoles manufactured by different manufacturers. Assume that manufacturer B manufactures a first type of patient surgical platform B1, and manufacturer B also manufactures a first type of remote doctor console B2 and a second type of remote doctor console B3; manufacturer C manufactures a first type of patient surgical platform C1, and manufacturer B also manufactures a first type of remote doctor console C2 and a second type of remote doctor console C3; patient surgical platforms B1 and C1 can both be, for example, single-port laparoscopic hand robots, remote doctor consoles B2 and C2 can both be, for example, remote doctor consoles with operating parts in the form of electromagnetic navigation, and remote doctor consoles B3 and C3 can both be, for example, remote doctor consoles with operating parts in the form of mechanical linkages. For example, in the patient surgical platform B1 and remote doctor consoles B2, B3, C2, C3, etc., the remote doctor consoles B2, B3, C2, C3 can both be remote doctor consoles with operating parts in the form of mechanical linkages. 3, and a second custom protocol is agreed upon between the patient surgery platform C1 and the remote doctor consoles B2, B3, C2, and C3. The first custom protocol may be the same as or different from the second custom protocol. The patient surgery platform B1 manufactured by manufacturer B may be configured to be capable of being manipulated by one or more of the remote doctor consoles B2 and B3 manufactured by it, and at the same time, may also be configured to be capable of being manipulated by one or more of the remote doctor consoles C2 and C3 manufactured by manufacturer C; the patient surgery platform C1 manufactured by manufacturer C may be configured to be capable of being manipulated by one or more of the patient surgery platforms C2 and C3 manufactured by it, and at the same time, may also be configured to be capable of being manipulated by one or more of the remote doctor consoles B2 and B3 manufactured by manufacturer B.

[0121] It is understandable that whether the remote doctor console and the patient surgery platform can be used in pair depends mainly on whether the two have been registered with the server and whether the communication protocols of the two are the same. Even if the remote doctor console and the patient surgery platform are manufactured by different manufacturers, they can usually be used in pair as long as they are registered with the server and the communication protocols of the two are the same. When pairing, at least the observer privilege can be allowed. This disclosure describes more conditions for allowing pairing by examples later.

[0122] <Equipment Maintenance>

[0123] When the remote doctor console and the patient surgery platform are successfully registered with the server, the server will store the device information of these devices. However, as the number of remote doctor consoles and patient surgery platforms successfully registered with the server increases, if the server does not regularly maintain these remote doctor consoles and patient surgery platforms, the existence of a large number of inactive remote doctor consoles or patient surgery platforms will not only waste the storage space of the server, but also reduce the efficiency of pairing between active remote doctor consoles and patient surgery platforms.

[0124] In some embodiments, the server may clear the registration information of inactive remote doctor consoles and patient surgery platforms registered in the server at a certain period, for example, the registration information of these inactive devices may be removed from the device list maintained by the server. When clearing inactive devices, it may first be detected whether the device to be cleared is currently in a pairing state. If it is not currently in a pairing state, the clearing program is started; if it is currently in a pairing state, the device to be cleared may be converted to an active device, or the clearing program may be started after the pairing state of the device to be cleared is released, so as to prevent the device to be cleared from being paired and used when the clearing program is started, so that the ultra-teleoperative surgery is unfavorably interrupted, affecting the implementation of the surgery.

[0125] Inactivity includes inactive login and inactive pairing. Inactive login includes that the login frequency is less than the preset login frequency or the login duration is less than the preset login duration within the inactive period set by the server. Inactive pairing includes that the successful pairing frequency is less than the preset pairing frequency or the usage duration after successful pairing is less than the preset pairing usage duration within the inactive period. Among them, from the perspective of the server's timing, the server can be cleared once a week, for example; the inactivity period is the time from the successful registration of the device to the start of the server, such as 1 year; the preset login frequency is the number of times the device logs in to the server recorded by the server, such as 1 time; the preset login duration is the cumulative time the device logs in to the server, such as 1 hour; the preset pairing frequency is the number of times the device is paired with other devices recorded by the server, such as 1 time; the preset pairing usage duration is the cumulative time from the establishment of pairing with other devices to the unpairing recorded by the server, such as 1 hour.

[0126] The server effectively saves server resources by regularly clearing the registration information of inactive remote doctor consoles and patient surgery platforms, and can improve the efficiency of pairing between remote doctor consoles and patient surgery platforms. In addition, it also prevents these inactive remote doctor consoles and patient surgery platforms from being illegally used, affecting the safety of ultra-remote surgery.

[0127] <Device interconnection>

[0128] In some embodiments, the registered remote doctor console and the patient surgical platform can be interconnected, that is, paired. The present disclosure discusses three pairing modes, and the pairing initiators of different pairing modes are different. Among them, the first mode is a two-end calling mode, which means that both the remote doctor console and the patient surgical platform initiate pairing. The second mode is a single-end calling mode, which means that one end of the remote doctor console and the patient surgical platform initiates pairing. The third mode is an administrator direct connection mode, which means that the server initiates pairing.

[0129] In the first mode and the second mode, the pairing initiator needs to log in to the server before initiating pairing. Among them, the pairing initiator can quickly log in to the server using the login password assigned by the server when the registration is completed. The pairing initiator includes at least one of the remote doctor console and the patient surgery platform. In the third mode, the pairing initiator is the server, and the user needs to log in to the server with the administrator account and password to obtain administrator privileges. The administrator privileges can be used to configure the judgment rules agreed with each device for the server, and can also be used to directly pair the device.

[0130] To simplify the description, one of the remote doctor console and the patient surgery platform may be referred to as the first device and the other as the second device. The pairing methods in the three modes are introduced below.

[0131] <First Mode - Two-way Calling>

[0132] In some embodiments, see Fig. 9 , the method comprising:

[0133] 201. The first device sends a first request to the server.

[0134] The first request is used to request the server to send second device information of a second device that may be paired with the first device.

[0135] In one embodiment, the communication protocol such as the custom protocol agreed upon between all first devices and all second devices registered to the server is the same. Any first device and any second device can communicate after pairing. In this case, the first request is simply used to request the server to send second device information that can be paired with the second device.

[0136] In one embodiment, the communication protocols such as custom protocols agreed upon between at least part of the first device and the second device registered to the server are different. The first device and the second device with different communication protocols cannot communicate even after pairing. In this case, in order to improve compatibility and pairing efficiency, the server can match the custom protocols supported by the second device based on the relevant information carried in the first request, such as the custom protocols supported by the first device for pairing, and filter out the second devices in the second device that are related to the custom protocols supported by the first device for pairing as the second devices that can be paired, and provide the second device information of the second devices that can be paired.

[0137] The pairable second device may be a second device that satisfies several conditions in the second device. For example, the pairable second device includes an online second device, that is, a second device logged in to the server. For example, the pairable second device includes a second device that is in an unpaired state.

[0138] The first request is encapsulated into a data message in a format specified by a custom protocol agreed upon by the first device and the server and sent to the server.

[0139] 202. The server receives a first request, and sends second device information that can be paired with a second device to the first device based on the first request.

[0140] After receiving the first request, the server decapsulates the first request based on the custom protocol agreed with the first device to obtain the custom protocol supported by the first device for pairing. The custom protocol supported by the first device for pairing is used to communicate with the second device and is different from the custom protocol agreed with the server.

[0141] Based on the acquired custom protocol supported for pairing by the first device, the server matches a second device having the same custom protocol supported for pairing from the registered second devices as a pairable second device, and acquires second device information associated with the pairable second device.

[0142] In one embodiment, the second device information includes at least one of a plurality of device information of the corresponding second device, and the at least one device information can uniquely represent the corresponding second device. In particular, based on security and simplicity, the second device information may only include a unique identifier of the corresponding second device, without providing device network information of the device. When naming the unique identifier, it can be named in combination with the device location information, such as "XX Hospital Patient No. XX Surgical Platform", which can provide more useful information without affecting communication security.

[0143] 203. The first device receives second device information that can be paired with the second device and is sent by the server.

[0144] After the first device receives the second device information, the second device information can be displayed on the display screen of the first device in at least one of a variety of forms such as a list, so that the doctor can choose to pair it.

[0145] 204. The first device obtains target second device information of the target second device determined based on the second device information, and sends a first pairing request to the server.

[0146] The target second device is a second device that the doctor expects to pair with the first device among the pairable second devices. The first pairing request is used to request to establish a pairing with the target second device, and the first pairing request includes device information of the first device and target second device information of the target second device. In one embodiment, the device information of the first device and the target second device information can both only include the unique identifier of the corresponding device.

[0147] The first pairing request is also encapsulated into a data message in the format specified by the custom protocol agreed upon by the first device and the server and sent to the server.

[0148] 205. The server receives a first pairing request sent by the first device.

[0149] After receiving the first pairing request, the server may return a signaling indicating receipt of the first pairing request to the first device.

[0150] 206. The target second device sends a second request to the server.

[0151] The second request is used to request the server to send first device information of a pairable first device that may be paired with the target second device.

[0152] The pairable first device may include at least part of the first device registered with the server. Similarly, in order to improve the pairing efficiency, the pairable first device may include a first device registered with the server and having the same communication protocol as the second device. To achieve this purpose, the second request may include a custom protocol supported by the second device for pairing. The second request is encapsulated into a data message in the format specified by the custom protocol agreed upon by the target second device and the server and sent to the server.

[0153] 207 . The server receives the second request, and sends first device information that can be paired with the first device to the target second device based on the second request.

[0154] After receiving the second request, the server decapsulates the second request based on the custom protocol agreed upon with the target second device, and obtains the custom protocol supported by the second device for pairing.

[0155] Based on the acquired custom protocol supported by the second device for pairing, the server matches a first device with the same custom protocol supported for pairing from the registered first devices as a pairable first device, and acquires first device information associated with the pairable first device.

[0156] The first device information includes at least one of a plurality of device information of the corresponding first device, for example, may only include a unique identifier of the corresponding first device without providing device network information of the device.

[0157] 208. The target second device receives the first device information that can be paired with the first device sent by the server.

[0158] The description of 208 may refer to the description of 203 and will not be repeated here.

[0159] 209 , the target second device obtains target first device information of the target first device to be paired determined based on the first device information, and sends a second pairing request to the server.

[0160] The target first device is a first device among the pairable first devices that the doctor expects to pair with the target second device. The second pairing request is used to request pairing with the target first device, and the second pairing request includes target second device information of the target second device and target first device information of the target first device. In one embodiment, the first device information includes at least one of a plurality of device information of the corresponding first device, and the at least one device information can uniquely represent the corresponding first device. Exemplarily, the first device information may only include a unique identifier of the corresponding device.

[0161] The second pairing request is also encapsulated into a data message in the format specified by the custom protocol agreed upon by the target second device and the server and sent to the server.

[0162] 210. The server receives a second pairing request sent by a target second device.

[0163] After receiving the second pairing request, the server may return a signal indicating receipt of the second pairing request to the target second device.

[0164] Among them, since the first device and the target second device it requests to pair with are registered with the server, and the target second device and the target first device it requests to pair with are registered with the server, the received pairing request returned by the server to the first device or the target second device can indicate that the pairing request is allowed, and the server's return to the device that initiated the pairing request can be represented by paired request ok signaling.

[0165] 211. The server determines whether two peer devices to be paired match based on the first pairing request and the second pairing request.

[0166] The two peer devices refer to the first device and the target second device, and the two are each other's peer devices. The server detects the matching of the first pairing request and the second pairing request.

[0167] In 211, the server may determine whether the two peer devices to be paired match based on the information included in the first pairing request and the information included in the second pairing request. For example, the server may determine whether the two peer devices to be paired match based on detecting whether the target first device information matches the first device information of the first device. If the target first device information matches the first device information of the first device, it is determined that the two peer devices to be paired match; otherwise, it is determined that the two peer devices to be paired do not match.

[0168] 204 may include determining at least one target second device information associated with the target second device, for example, when including multiple, the first device may send multiple first pairing requests to the server, each first pairing request is used to request to establish a pairing with a target second device. 209 may include determining at least one target first device information associated with the target first device, for example, when including multiple, the target second device may send multiple second pairing requests to the server, each second pairing request is used to request to establish a pairing with a target first device.

[0169] In 211 , if the server determines that the two peer devices to be paired match, the process proceeds to 212 ; otherwise, the process proceeds to 214 .

[0170] 212. The server sends device network information of the opposite device to at least one of the first device and the target second device.

[0171] The device network information may include at least one of an IP address, a port number, and a custom protocol supported by the device for pairing.

[0172] In 212, the server may send the device network information of the target second device to the first device. Alternatively, the server may send the device network information of the first device to the target second device. Alternatively, the server may send the device network information of the target second device to the first device, and send the device network information of the first device to the target second device.

[0173] 213 , at least one of the first device and the target second device receives the device network information of the opposite device sent by the server, and establishes pairing with the opposite device based on the device network information.

[0174] The first device receives the device network information of the target second device, and establishes pairing with the target second device based on the device network information. Alternatively, the target second device receives the device network information of the first device, and establishes pairing with the first device based on the device network information. Alternatively, both are performed simultaneously.

[0175] After pairing of the first device and the target second device is completed, the first device and the target second device can directly communicate based on any custom protocol that both support pairing.

[0176] 214. The server sends a pairing failure notification to the first device and the target second device.

[0177] In the above 204 or 209, the corresponding device can send a corresponding pairing request to the server in response to the triggering of an event. The event, for example, includes a control for sending a pairing request being triggered, or the corresponding target device information is determined to reach a preset delay time, and the preset delay time can be 0 or other non-zero time.

[0178] In some embodiments, the pairing implemented by 213 is real-time pairing. After real-time pairing, the first device and the target second device can communicate instantly. The communication between the two does not need to be transferred through the server, and the communication is directly end-to-end. In some embodiments, the pairing implemented by 213 is a scheduled pairing. After the first device and the target second device meet the scheduled conditions, they will enter and implement real-time pairing. For example, the scheduled conditions include the arrival of the scheduled pairing time, the physical state of the remote doctor console or the patient's surgical platform meets the pairing requirements, etc.

[0179] In some embodiments, after 213, after the first device and the target second device establish pairing, the pairing success status is returned to the server, and the server receives the pairing success status and sends a pairing success prompt to the first device and the target second device. In some embodiments, after 211, if the server determines that the desired paired peer device does not match, the server can send a pairing failure prompt to the first device and the target second device. The pairing success or pairing failure prompt can be displayed in a UI interface or sound.

[0180] In some embodiments, two devices may send pairing requests to the server simultaneously or in different time periods. When any device sends a pairing request to the server, the server may start a timer to count the time it takes for the other device expected by the device to send a pairing request to the server. If the other device also sends a pairing request to the server within the set waiting time range, and the server determines that the pairing request sent by the device matches the pairing request sent by the other device, the server determines that the device matches the other device, and the pairing is deemed successful; if the timeout or the pairing request does not match, the server determines that the device does not match the other device, and the pairing is deemed failed. For example, the set time may be 60s, 120s, 180s, etc. Setting an appropriate waiting time range can improve the user experience and avoid unnecessary time waste during pairing.

[0181] <Second Mode - Single-ended Call>

[0182] In some embodiments, see Fig.10 , the method comprising:

[0183] 301. The first device sends a first request to the server.

[0184] 302. The server receives the first request, and sends second device information that can be paired with the second device to the first device based on the first request.

[0185] 303. The first device receives second device information that can be paired with the second device and is sent by the server.

[0186] 304. The first device obtains target second device information of the target second device determined based on the second device information, and sends a first pairing request to the server.

[0187] 305. The server receives a first pairing request sent by the first device.

[0188] After receiving the first pairing request, the server may return a signaling indicating receipt of the first pairing request to the first device.

[0189] The principles of 301 to 305 in the second mode are the same or similar to those of 201 to 205 in the first mode, and will not be repeated here.

[0190] 306. The server sends a first pairing request to the target second device associated with the target second device information.

[0191] 307 , the target second device receives the first pairing request sent by the server, and obtains a response instruction generated in response to the first pairing request.

[0192] The target second device may generate a notification based on the first pairing request and play the notification to facilitate the doctor to respond to the pairing request based on the notification, ie, respond.

[0193] The content of the notification is to notify the target second device whether to accept the pairing initiated by the first device. In some embodiments, the notification can be played in the form of a UI interface or a sound.

[0194] In some embodiments, the user can make a decision on whether the target second device accepts or rejects the pairing of the first device based on the notification. For example, when playing in the form of a UI interface, operable controls of "Accept pairing of the first device" and "Reject pairing of the first device" can be displayed on the display screen of the second target device. When the user operates the operable control of "Accept pairing of the first device", it indicates acceptance of the pairing of the first device, or, when the user operates the operable control of "Reject pairing of the first device", it indicates rejection of the pairing of the first device. For example, when playing in the form of sound, "Whether to accept pairing of the first device" can be played in the audio device of the second target device. The user can recognize the user's audio input of "Accept pairing of the first device" through the voice recognition device set in the second target device, and generate a response instruction to accept the pairing of the first device, or recognize the user's audio input of "Reject pairing of the first device" and generate a response instruction to reject the pairing of the first device.

[0195] In some embodiments, the second target device may also make a decision to accept or reject pairing with the first device, that is, the decision is made by the device itself. For example, when the target second device receives the first pairing request sent by the server, a timer may be started to count. When the response waiting time range is reached and the target second device does not obtain the user's response to the notification, the second target device generates a response instruction to reject the pairing of the first device by default. The target second device sends the response instruction to the server. After receiving the response instruction, the server sends a notification of pairing failure to the first device. For another example, the target second device may be configured to store a whitelist, which is associated with one or more first devices. The target second device allows the first device associated with the whitelist to pair with it without the user having to respond to the notification. For example, in a whitelist scenario, if the first device is in the whitelist of the target second device, the user can actively respond to the notification within the response waiting time range, and the response includes the target second device accepting or rejecting the pairing of the first device. When the preset conditions are met, such as when the response waiting time range is reached and the target second device has not obtained the user's response to the notification, the second target device automatically generates a response instruction to accept the pairing of the first device, and the target second device sends the response instruction to the server. After receiving the response instruction, the server sends a notification of successful pairing to the first device.

[0196] 308. The target second device sends a response instruction to the server.

[0197] 309 , in response to receiving the affirmative response instruction, the server sends the device network information of the opposite device to at least one of the first device and the target second device.

[0198] If the response instruction indicates that the target second device accepts pairing with the first device, the response instruction is an affirmative response instruction.

[0199] 310 , at least one of the first device and the target second device receives device network information of the opposite device sent by the server, and establishes pairing with the opposite device based on the device network information.

[0200] For example, the server sends the device network information of the target second device to the first device, the first device receives the device network information, and establishes pairing with the target second device based on the device network information.

[0201] 311. The server sends a prompt indicating successful pairing to the first device and the target second device.

[0202] 312, the first device receives the prompt of successful pairing sent by the server, and plays the prompt of successful pairing; the target second device receives the prompt of successful pairing sent by the server, and plays the prompt of successful pairing.

[0203] 313. In response to receiving the negative response instruction, the server sends a pairing failure prompt to the first device.

[0204] If the response instruction indicates that the target second device rejects pairing with the first device, the response instruction is a negative response instruction.

[0205] In addition, the server may also simultaneously send a pairing failure prompt to the target second device.

[0206] 314. The first device receives the pairing failure prompt sent by the server and plays the pairing failure prompt.

[0207] In some embodiments, the first device is a remote doctor console, and the target second device is a patient surgery platform, which is suitable for use when the doctor actively matches the patient. In some embodiments, the first device is a patient surgery platform, and the target second device is a remote doctor console, which is suitable for use when the patient actively matches the doctor. The two applicable scenarios can maximize the use of high-quality medical resources.

[0208] In the above embodiments, the request sent by the local device to the server for requesting a pairable peer device, such as the first request sent by the first device to the server, or the second request sent by the second device to the server, may include or not include a screening condition.

[0209] When these requests do not include any screening conditions, in order to facilitate the pairing of the local device with the target peer device among the pairable peer devices, the server can obtain various status information of the peer device and send it to the local device for prompting, such as display. These status information may include at least one of the custom protocol information supporting pairing, online status information, device type information, device function information, applicable surgery type information, network status information, device location information, power-on self-test status information, pairing status information, scheduled pairing time information, and control authority allocation status information of the peer device. The doctor can select the target peer device for the desired pairing based on these status information. However, too much status information is not conducive to the fast and accurate desired pairing. Therefore, in order to further improve the pairing efficiency, these requests can be configured to include screening conditions so that the server can accurately provide the pairable peer devices based on the screening conditions so that the doctor can select the target peer device for the desired pairing.

[0210] In some embodiments, the filtering conditions may be configured based on the above-obtainable status information of the local device or the opposite device. Some filtering conditions are associated with the status information of the local device and the opposite device, and some filtering conditions are only associated with the status information of the opposite device. The filtering conditions may include at least one of the following.

[0211] For example, the filtering condition includes the custom protocol that the local device supports for pairing. The server can obtain the filtering condition from the device information of the local device, and based on the filtering condition, match the peer devices registered with the server with the custom protocol that matches the pairing supported by the local device as the pairable peer devices. By setting the filtering condition, the pairable peer devices that can be paired and used can be obtained.

[0212] For example, the screening condition includes the device type of the local device. The registration information of the local device or the opposite device stored by the server may include the device type of the device. For the opposite device being a patient surgical platform, the device type may be reflected in the type of slave robot, including a single-port laparoscope slave robot, a multi-port laparoscope slave robot, a bronchial interventional slave robot, a vascular interventional slave robot, or an orthopedic slave robot, etc.; for the opposite device being a remote doctor console, the device type may be reflected in the type of operating unit, including an operating unit in the form of a game controller, an operating unit in the form of a mechanical linkage, an operating unit in the form of a magnetic navigation, or an operating unit in the form of a trackball, etc. Different types of remote doctor consoles may be suitable for different types of patient surgical platforms. The server may obtain the screening condition from the device information of the local device, and based on the screening condition, match the opposite device that matches the device type of the local device from the opposite devices registered to the server as a pairable opposite device for registration.

[0213] For example, the screening condition includes the device functions supported by the local device. The registration information of the local device or the opposite device stored by the server may include the device functions supported by the device, and the device functions include the core functions of the device. Pairing is allowed only when the remote doctor console and the patient surgical platform match in the core functions of the device. Exemplarily, the core functions of the device include motion control functions or energy control functions. This is usually considered especially when the control authority to be configured is (full) operator authority. If the control authority to be configured is only the observer authority, it is irrelevant whether the core functions of the device match. As long as the functions of the two end devices expected to be paired include the observation function, they can be matched and pairing is allowed. Among them, the server can obtain the screening condition from the device information of the local device, and match the opposite device in the opposite device registered to the server with the device function supported by the local device as a pairable opposite device based on the screening condition. By setting the screening condition, a pairable opposite device that can be paired and used can be obtained.

[0214] For example, the screening conditions include the types of surgeries supported by the local device, and the registration information of the local device or the peer device stored in the server may include the appropriate surgical types of the device. Different slave robots may be suitable for the same or different surgical types. For example, for thoracic or abdominal surgery, a (single-hole or multi-hole) laparoscopic slave robot may be suitable; for bronchial or vascular or urinary surgery, a (bronchial or vascular) interventional slave robot may be suitable; for orthopedic surgery, an orthopedic slave robot may be suitable. Different remote doctor consoles may be suitable for the same or different surgical types. The surgical type may also include more specific surgical procedures, such as urological surgery, lung surgery, liver surgery, kidney surgery, knee replacement surgery, etc. For urological surgery, the slave robot may be matched as a (vascular) interventional slave robot; for lung surgery, the slave robot may be matched as a (bronchial) interventional slave robot; for liver surgery or kidney surgery, the slave robot may be matched as a (single-hole or multi-hole) laparoscopic slave robot; for knee replacement surgery, the slave robot may be matched as an orthopedic slave robot. The server can obtain the screening condition from the device information of the local device, and match the remote devices registered with the server with the surgical type supported by the local device as the pairable remote devices based on the screening condition. By setting the screening condition, the pairable remote devices that can be paired and used can be obtained.

[0215] For example, the screening condition includes the appointment pairing time of the local device. The appointment pairing time of the local device can be input by the doctor and obtained by the server. The doctor can input the operation planning time of the opposite device and obtain it by the server. The operation planning time includes an occupied time period and an idle time period. The server can match the pairable opposite device whose appointment pairing time does not conflict with the idle time period from the operation planning time associated with the opposite device obtained by the server based on the appointment pairing time of the local device. Among them, the opposite device that is in an unpaired state and has not been configured with an operation planning time can be considered that its operation planning time is an idle time period.

[0216] For example, the screening condition includes the expected online status of the peer device. When the server obtains that the peer device is currently logged in to the server, it can mark the peer device as online; when it obtains that the peer device is not currently logged in to the server, it can mark the peer device as offline. The doctor can configure the expected online status as a screening condition so that the server can match the pairable peer device that meets the online status, which is conducive to quickly obtaining the peer device that can be paired in real time.

[0217] For example, the screening condition includes the network status expected by the peer device. The server can obtain the network status between the peer device and the server. The network status can include the network type and the network communication status. The network communication status includes normal and abnormal. The doctor can configure the expected network status as the screening condition so that the server can match the pairable peer device that meets the network status.

[0218] For example, the screening condition includes the expected pairing state of the peer device. The server can obtain and maintain the pairing state of the local device or the peer device, and the pairing state includes a paired state and an unpaired state. To ensure privacy and security, the pairable peer device usually comes from the peer device in an unpaired state. In the remote teaching scenario, multiple local devices can be paired with one peer device, and the peer device may be in a paired state. In this scenario, the pairable peer device is also allowed to come from the peer device in a paired state. The doctor can configure the expected pairing state as a screening condition for the server to match a suitable pairable peer device.

[0219] For example, the screening conditions include the device positioning expected by the peer device. The registration information of the local device or the peer device stored in the server may include the device positioning of the device. The device positioning may be obtained through a positioning module configured for the device, such as a GPS positioning module, a Beidou positioning module, a Starlink positioning module, etc., or may be obtained through IP address resolution, or may be manually written. A variety of positioning methods may be used for mutual verification. If the verification succeeds, it is used for screening. If the verification fails, the user may be prompted to manually modify the device positioning for screening. Device positioning may include multiple levels, such as continental, national, provincial, municipal, district, street, or building levels. Doctors can configure the expected device positioning as a screening condition for the server to match a pairable peer device that matches the device positioning.

[0220] For example, the screening conditions include the control authority allocation status expected by the peer device. The server can obtain the control authority allocation status configured by the peer device, and the control authority allocation status includes the state where all control authorities are allocated, the state where some control authorities are allocated, and the state where control authorities are not allocated. For the state where all control authorities are allocated, it is more suitable for pairing in substitute teaching scenarios. For the state where some control authorities are allocated, it is more suitable for pairing in collaborative surgery scenarios. For the state where control authorities are not allocated, it is suitable for pairing in any scenario. Doctors can configure the expected control authority as a screening condition so that the server can match a suitable pairable peer device.

[0221] For example, the screening condition includes the expected power-on self-test status of the peer device. When the server communicates with the local device or the peer device, it can obtain the power-on self-test status of the device. The power-on self-test status can include multiple levels, for example, it can include that all the software and hardware functions of the device are normal or the software and hardware core functions of the device are all normal. Generally, it is expected that all the software and hardware functions of the matched peer device are normal. However, when the peer device expected to be paired does not meet the requirements of all the software and hardware functions being normal, in order to ensure that ultra-remote surgery can be implemented, as long as the software and hardware core functions are normal, the peer device can also be paired and used. The power-on self-test status can be associated with the patient's condition information. For example, when the peer device is a patient surgery platform, its device software and hardware functions include core devices and auxiliary devices, the core devices include such as hand robots and energy platforms, and the auxiliary devices include such as monitors or ventilators. When the patient's condition is not serious and does not need to be applied to auxiliary devices, even if the software and hardware functions of the auxiliary devices are abnormal, as long as the software and hardware functions of the core devices are normal, they can also be paired and used, which can meet the minimum pairing requirements and improve the pairing success rate. The server can determine whether auxiliary devices are needed from the patient's condition information input from the local device or the peer device. The patient's condition information can include the definition of the core device and auxiliary devices to be used. The doctor can configure the expected power-on self-test state so that the server can match the appropriate peer device.

[0222] Among them, the above-mentioned screening conditions can be used alone or in combination, and the opposite-end device that meets one or more of the above-mentioned screening conditions can be used as a pairable opposite-end device.

[0223] <Third Mode - Administrator Direct Connection>

[0224] In some embodiments, the server can obtain all the first devices and second devices that have completed registration, and perform the desired pairing based on the obtained first devices and second devices, so as to realize batch configuration of devices in multiple locations and improve pairing efficiency. However, in actual situations, different communication protocols may be agreed upon between these first devices and second devices. Since the communication protocols are not visible, the pairing led by doctors is often tentative, resulting in low pairing efficiency.

[0225] In some embodiments, the server may configure different labels for different custom protocols that the corresponding device supports for pairing. When the device information of the corresponding device is displayed on the display screen of the device or the server, the label may be displayed together to facilitate the doctor to identify devices that can be paired with each other. Among them, the custom protocols that each device supports for pairing may include that different labels can be configured for the custom protocols of the device. For example, a first device and a second device with the same label can be paired with each other, and a first device and a second device with different labels cannot be paired with each other. Among them, different labels can be represented by different digital codes, characters, text, colors or symbols.

[0226] In some embodiments, the doctor can use the server itself for direct administrator connection; or, the doctor can use any device that can log in to the server with administrator privileges, including a remote doctor console, a patient surgery platform, a desktop computer or a portable mobile terminal for direct administrator connection, and the portable mobile terminal includes a mobile phone, a tablet computer or a laptop computer. In some embodiments, any of these devices that can be directly connected by the administrator can be devices registered to the server, and the registration of these devices can be authenticated through a custom protocol or encryption algorithm as described above to improve security. In some embodiments, the mobile terminal device can be bound to the remote doctor console or the patient surgery platform, and participate in the pairing configuration of the above-mentioned multiple modes as a remote doctor console or a patient surgery platform.

[0227] In some embodiments, in order to facilitate the use of a server for administrator direct connection, the present disclosure provides a method, referring to Fig.11 , the method comprising:

[0228] 401. Obtain first device information of a first device registered with a server.

[0229] 402 : Acquire target first device information associated with the target first device determined based on the first device information.

[0230] The target first device is used to pair with the second device.

[0231] 403 . Based on the target first device information, second device information of a pairable second device that can be paired with the target first device is matched from second devices registered with the server.

[0232] As mentioned above, the custom pairing protocol supported by the pairable second device that can be paired with the target first device is generally compatible with the custom pairing protocol supported by the target first device.

[0233] 404 , obtain target second device information associated with the target second device determined based on the second device information.

[0234] 405 , obtaining device network information of at least one of the target first device and the target second device.

[0235] 406 , sending the device network information to a peer device associated with the network information.

[0236] 407, the opposite device receives the network information, and establishes pairing with the local device associated with the network information based on the network information to achieve direct communication.

[0237] For example, in 406, when the device network information includes the device network information of the target first device, the device network information is sent to the target second device. Further in 407, the target second device establishes pairing with the target first device based on the device network information of the target first device.

[0238] For example, in 406, when the device network information includes the device network information of the target second device, the device network information is sent to the target first device. Further in 407, the target first device establishes pairing with the target second device based on the device network information of the target second device.

[0239] For example, in 406, when the device network information includes the device network information of the target first device and the device network information of the target second device, the device network information of the target first device is sent to the target second device, and the device network information of the target second device is sent to the target first device. Further in 407, the target second device establishes pairing with the target first device based on the device network information of the target first device, and the target first device establishes pairing with the target second device based on the device network information of the target second device.

[0240] Through the above 401 to 406, it can help to quickly perform pairing and improve pairing efficiency.

[0241] After 406, after the target first device and the target second device are paired, at least one of the target first device and the target second device returns a pairing success status to the server, and the server receives the pairing success status to update the pairing status it maintains. The server can send a pairing success prompt to the target first device and the target second device.

[0242] In some embodiments, the target first device may include one, the target second device may include at least one, and the pairable second device may include a second device that supports a custom pairing protocol that is compatible with the custom pairing protocol supported by the target first device.

[0243] For example, assuming that the target first device supports a custom pairing protocol A, when the custom pairing protocol supported by the second device includes A, the second device can be used as a pairable second device.

[0244] In some embodiments, the target first device includes at least one, the target second device includes one, and the pairable second device includes a second device that supports a custom pairing protocol and is compatible with the custom pairing protocol supported by each target first device.

[0245] For example, assuming that a target first device supports a custom pairing protocol A and another target first device supports a custom pairing protocol B, the second device can be used as a pairable second device when the custom pairing protocols supported by the second device are compatible with A and B.

[0246] For example, when the custom protocol supported for pairing in the second device is compatible with at least one custom protocol supported for pairing in each target first device, the second device may serve as a pairable second device.

[0247] Exemplarily, assuming that a target first device supports custom pairing protocols A and B, and another target first device supports custom pairing protocols C and D, the second device can serve as a pairable second device when the custom pairing protocol supported by the second device is compatible with at least one of A and B and at least one of C and D. For example, a second device that supports custom pairing protocols including A and C, or including A and D, or including B and C, or including B and D can serve as a pairable second device. Of course, a second device including A, B and C, or including A, C and D, or including B, C and D, or including A, B, C and D is also within the aforementioned category and can be used as a pairable second device.

[0248] Exemplarily, assuming that a target first device supports custom pairing protocols A and B, and another target first device supports custom pairing protocols B and C, the second device can serve as a pairable second device when the custom pairing protocol supported by the second device is compatible with at least one of A and B and at least one of B and C. For example, a second device that supports custom pairing protocols including B, or including A and B, or including B and C, or including A and C can serve as a pairable second device. Of course, a second device that includes A, B and C is also within the aforementioned category and can serve as a pairable second device.

[0249] In some embodiments, when determining the first device for pairing and the second device for pairing with the first device, screening conditions may be configured to obtain suitable devices. The description of these screening conditions may refer to the foregoing text and will not be repeated here.

[0250] Based on the pairing methods of the first to third modes, it is possible to quickly achieve one-to-one, one-to-many, or many-to-one pairing between any remote doctor console and the patient's surgical platform. This can simplify user operations, save labor costs and time costs, reduce the complexity of remote surgery, improve the universality of remote surgery, and help establish an ultra-remote surgery medical network.

[0251] In some embodiments, in the above-mentioned multiple pairing modes, the server may save the pairing information of the first device and the second device to be paired, and assign a unique pairing identifier to both. The first device and the second device may attempt to establish pairing and communicate based on the pairing identifier, and are prohibited from communicating with each other before the pairing is successful. The signaling (i.e., data) of each subsequent communication may carry the pairing identifier for communication authentication. For devices with mismatched pairing identifiers, the recipient has the right to refuse communication services.

[0252] In some embodiments, the server can obtain the pairing status of all devices in real time, and can maintain a pairing table based on the pairing status, which records the paired, pairing or unpaired status of the device. The server can set the status of the device that has completed real-time pairing to paired. The server can set the status of the device that has scheduled pairing or the device that is establishing real-time pairing to pairing. The server can also delete the pairing information of the device that failed to pair or the unpaired device, and set the status of the device that failed to pair or the unpaired device to unpaired. Among them, as the pairing table is updated, the second device information of the second device that can be paired, or the first device information of the first device that can be paired with each other and the second device information of the second device can be updated and sent to the relevant devices, for example, the former is updated and sent to the first device, and the latter is updated and sent to the server, to facilitate pairing.

[0253] In some embodiments, the first device, the second device or the server may include a display screen and an input device, and the display screen and the input device may be used to quickly realize visual pairing of the first device and the second device. The display screen and the input device may be independent components, and the input device may include, for example, a mouse and a keyboard, wherein, on the remote doctor console side, its operating unit may also be used as a mouse during the pairing stage. The display screen and the input device may also be integrated components, such as a touch screen.

[0254] <UI interaction of two-way calling>

[0255] In some embodiments, the present disclosure provides a method for pairing, see Fig.12 , the method comprising:

[0256] 501. The first device displays a first configuration interface on its first display screen, and in response to obtaining a trigger of a first control in the first configuration interface, sends a first request to a server.

[0257] 502. The server receives a first request sent by a first device, and sends second device information that can be paired with a second device to the first device based on the first request.

[0258] 503. The first device receives the second device information that can be paired with the second device sent by the server, and displays the second device information in the first configuration interface.

[0259] 504. The first device obtains target second device information of a target second device to be paired determined based on the second device information, and sends a first pairing request to the server.

[0260] After determining the target second device information, the first device can immediately and automatically trigger the first pairing request to the server. After determining the target second device information, the first device can respond to the triggering of an event and send a first pairing request to the server. The event includes the first device reaching the delay time from the time the target second device information is determined, or a control in the first configuration interface is triggered, and the control is a control for controlling the sending of the pairing request. Among them, the first device obtains that the timer reaches the delay time, or obtains that the control is triggered, and sends a first pairing request to the server.

[0261] 505. The server receives a first pairing request sent by the first device.

[0262] After receiving the first pairing request, the server may return a signaling indicating receipt of the first pairing request to the first device.

[0263] 506. The target second device displays a second configuration interface on its second display screen, and in response to obtaining a trigger on the first control in the second configuration interface, sends a second request to the server.

[0264] 507 , the server receives the second request sent by the target second device, and sends the first device information that can be paired with the first device to the target second device based on the second request.

[0265] 508. The target second device receives the first device information that can be paired with the first device and sent by the server, and displays the first device information in the second configuration interface.

[0266] 509. The target second device obtains target first device information determined based on the first device information, and sends a second pairing request to the server.

[0267] After determining the target first device information, the target second device can immediately and automatically trigger a second pairing request to the server. After determining the target first device information, the target second device can respond to the triggering of an event and send a second pairing request to the server. The event includes the timing of the target second device reaching the delay time from the determination of the target first device information, or a control in the second configuration interface is triggered, and the control is a control for controlling the sending of the pairing request. Among them, the target second device obtains that the timing reaches the delay time, or obtains that the control is triggered, and sends a second pairing request to the server.

[0268] 510. The server receives a second pairing request sent by a target second device.

[0269] After receiving the second pairing request, the server may return a signal indicating receipt of the second pairing request to the target second device.

[0270] 511. The server determines whether two peer devices to be paired match based on the first pairing request and the second pairing request.

[0271] If the server determines that the two peer devices to be paired match, the process proceeds to 512 ; otherwise, the process proceeds to 515 .

[0272] 512. The server sends device network information of the opposite device to at least one of the first device and the target second device.

[0273] 513 , at least one of the first device and the target second device receives the device network information of the opposite device sent by the server, and establishes pairing with the opposite device based on the device network information.

[0274] 514, after the first device and the target second device are paired, a message that the pairing is successfully established is displayed on the first configuration interface and the second configuration interface respectively.

[0275] 515. The server sends a notification of pairing failure to the first device and the target second device.

[0276] 516. The first device and the target second device receive a notification of pairing establishment failure sent by the server, and display a message of pairing establishment failure on the first configuration interface and the second configuration interface respectively.

[0277] Exemplarily, the message of successful pairing or failed pairing may be displayed by popping up a dialog box in each configuration interface, or may be displayed by a fixed or floating status bar in each configuration interface.

[0278] In some embodiments, in combination Figure 13 to Figure 15 Refer, in 501 or 506, the first control 1 can be a button. When button 1 is clicked, it means that the first control 1 is triggered, and the corresponding device sends a corresponding request to the server to request the device information of the paired peer device. In 503 or 508, the corresponding device information sent by the server can be displayed on the corresponding configuration interface through the second control 2. The second control 2 can be a list control. The list control 2 includes at least one list option. One list option is associated with the device information of one device. In 504 or 509, when the corresponding device detects that one or more list options are selected, it can determine that the device information associated with the one or more list options is the target device information, that is, determine the target peer device that the corresponding device expects to pair with. Exemplarily, take the configuration interface of a remote doctor console, such as the remote doctor console of Hospital A, as an example. Fig.13 , the first control 1 is triggered, and the remote doctor console of Hospital A sends a request to request a paired peer device; Fig.14At this time, the server matches the patient surgery platforms of hospitals A~E and displays them in the configuration interface in list control 2; Fig.15 , when the list option associated with the patient surgery platform of Hospital B is selected and confirmed, the patient surgery platform of Hospital B is the peer device that Hospital A's remote doctor console expects to pair with, and a pairing request is issued. Similarly, if Hospital A's remote doctor console is determined as the peer device expected to pair with in the corresponding configuration interface of the patient surgery platform of Hospital B, and another pairing request is issued, the two match and can be paired; otherwise, the two do not match and cannot be paired.

[0279] In this embodiment, when the corresponding device obtains the pairing failure, it can automatically restore the list options to the initial state, such as the unselected state, to facilitate the subsequent pairing of the corresponding device with other peer devices. The corresponding device can also cancel the pairing with the peer device when the list options are restored to the initial state, such as the unselected state.

[0280] In some embodiments, in combination Figures 16 to 19 Refer, in 501 or 506, the first control 1' can be a window control, and the corresponding device can generate a second control 2' in the respective configuration interface according to its device information. The second control 2' can be a drag control, which has an initial position in the corresponding configuration interface. When the second control 2' is moved to the window of the window control 1', it means that the first control 1' is triggered, and the corresponding device sends a corresponding request to the server to request the device information of the pairable counterpart device. In 503 or 508, the corresponding device information can be displayed in the corresponding configuration interface through the third control 3'. The third control 3' can be a drag control, which has an initial position in the corresponding configuration interface. The number of third controls 3' is the same as the number of pairable counterpart devices, and each third control 3' corresponds to a counterpart device. In 504 or 509, the corresponding device can determine that the device information associated with the third control 3' is the target device information when detecting that the third control 3' is moved to the window of the window control 1', that is, determine the target counterpart device that the corresponding device expects to pair with. Exemplarily, take the configuration interface of a remote doctor console, such as the remote doctor console of Hospital A, as an example. Fig.16 and Fig.17 When the second control 2' representing the remote doctor console of Hospital A moves into the window of the window control 1', the remote doctor console of Hospital A sends a request to request that the peer device can be paired; Fig.18 At this time, the server matches the patient surgery platform of Hospital A~E and displays it in the configuration interface by dragging the control 3'; Fig.19, when the drag control 3' associated with the patient surgery platform of Hospital B is moved into the window of the window control 1' and confirmed, the patient surgery platform of Hospital B is the peer device that the remote doctor console of Hospital A expects to pair with, and a pairing request is issued. Similarly, if the remote doctor console of Hospital A is determined as the peer device expected to pair with in the corresponding configuration interface of the patient surgery platform of Hospital B, and another pairing request is issued, the two match and can be paired; otherwise, the two do not match and cannot be paired.

[0281] In this embodiment, see Figure 20 to Figure 22 , the window of the window control 1' may include a first area 11' and a second area 12', the first area 11' includes a first sub-area 11a' and a second sub-area 11b', which are respectively used to accommodate the second control 2', and the second area 12' is used to accommodate the third control 3', wherein these areas can also be implemented by windows. In the case where one or more remote doctor consoles can be paired with a patient surgical platform, the second control 2' is associated with the remote doctor console, and the third control 3' is associated with the patient surgical platform. The first sub-area 11a' and the second sub-area 11b' can be associated with different control permissions, or can also be associated with different pairing orders. Exemplarily, in response to the third control 3' moving to the second area 12', the patient surgical platform associated with the third control 3' sends a first request to the server, which can match a remote doctor console that can be paired with the patient surgical platform and display it in the configuration interface of the patient surgical platform. The pairable remote doctor console can be displayed outside the window in the form of a drag control.

[0282] For example, the first sub-area 11a' can be associated with a first control authority of the remote doctor console accommodated therein over the patient surgical platform accommodated in the second area 12', and the second sub-area 11b' can be associated with a second control authority of the remote doctor console accommodated therein over the patient surgical platform accommodated in the second area 12', and the first control authority is different from the second control authority. Exemplarily, the first control authority is full operator authority, and the second control authority is observer authority. When the second control 2' associated with the first remote doctor console is moved to the first sub-area 11a', the first remote doctor console is configured to have full operator authority over the patient surgical platform accommodated in the second area 12'; when the second control 2' associated with the second remote doctor console is moved to the second sub-area 11b', the second remote doctor console is configured to have observer authority over the patient surgical platform accommodated in the second area 12'. Fig. 22For the same patient surgical platform, such as the patient surgical platform of Hospital A, the remote doctor console of Hospital A has different control permissions or pairing order than the remote doctor console of Hospital B. In this example, the second sub-area 11b' may include one or more remote doctor consoles with full operator permissions and multiple observer permissions for quick pairing with a patient surgical platform. In this way, quick allocation of control permissions can be achieved during pairing.

[0283] For example, the first sub-area can be associated with a first pairing order of a remote doctor console accommodated therein and a patient surgical platform accommodated in the second area, and the second sub-area can be associated with a second pairing order of a remote doctor console accommodated therein and a patient surgical platform accommodated in the second area, and the first pairing order and the second pairing order are different. Exemplarily, the first pairing order takes precedence over the second pairing order, and when the second control associated with the first remote doctor console is moved to the first sub-area, the first remote doctor console is configured to have a first pairing order with the patient surgical platform accommodated in the second area; when the second control associated with the second remote doctor console is moved to the second sub-area, the second remote doctor console is configured to have a second pairing order with the patient surgical platform accommodated in the second area. In this example, the first area can include more sub-areas, and different sub-areas have different pairing orders. In this way, the pairing order can be quickly set when pairing. In this example, the first area can also be used to accommodate different patient surgical platforms, and the second area is used to accommodate remote doctor consoles, and the pairing order between different patient surgical platforms and the same remote doctor console can also be quickly set. Exemplarily, in response to a drag control associated with a patient surgical platform being moved to a second area, the patient surgical platform sends a first request to the server, which can match a pairable remote physician console that can be paired with the patient surgical platform and display it in the configuration interface of the patient surgical platform. The pairable remote physician console can be displayed outside the window in the form of a drag control.

[0284] Among them, whether the second control or the third control is moved into the first control can be determined by detecting whether the pixel coordinates of the boundary of the second control or the third control fall within the pixel coordinate range of the boundary of the first control. Whether the second control or the third control is moved to the corresponding area can also be determined by detecting whether the pixel coordinates of the boundary of the second control or the third control fall within the pixel coordinate range of the boundary of the corresponding area.

[0285] In this embodiment, the drag control may have the same or different sizes before and after being moved. For example, the drag control may have a larger or smaller size when being moved into the first control relative to before being moved.

[0286] In this embodiment, when the corresponding device obtains the pairing failure, at least the third control of the second control and the third control can be automatically moved out of the first control and reset to the position before being moved, so as to facilitate the subsequent pairing of the corresponding device with other peer devices. The corresponding device can also cancel the pairing with the peer device when it obtains that the second control and the third control are removed from the first control. Among them, when the second control or the third control is manually moved out, once the second control or the third control is moved out of the first control, it can automatically restore to the position before being moved.

[0287] In some embodiments, in 501 or 506, the first control may be a button. When the button is clicked, it indicates that the first control is triggered, and the corresponding device sends a corresponding request to the server to request device information of a pairable peer device. The corresponding device may generate a second control in its respective configuration interface according to its device information. In 503 or 508, the corresponding device information sent by the server may be displayed in the corresponding configuration interface through a third control. The number of the third controls is the same as the number of pairable peer devices. Each third control corresponds to one peer device. The second control and the third control are fixed in position in the configuration interface. In 504 or 509, when the display screen of the corresponding device is a touch screen, when the corresponding device detects that the contact of the finger on the touch screen starts to move from one of the second control and the third control, and maintains the contact and continues to move to the other of the second control and the third control, the device determines that the device information associated with the third control corresponding to the start or end of maintaining the contact and continuing to move is the target device information, that is, the target opposite device with which the corresponding device expects to be paired is determined; or, when the display screen of the corresponding device is a touch screen or a non-touch screen, when the corresponding device detects that the cursor starts to move from one of the second control and the third control on the display screen, and continues to move to the other of the second control and the third control, the device determines that the device information associated with the third control corresponding to the start or end of the continuous movement is the target device information, that is, the target opposite device with which the corresponding device expects to be paired is determined. In 504 or 509, when the display screen of the corresponding device is a touch screen, the corresponding device may also determine that the device information associated with the third control included in the closed track is the target device information when it detects that the finger keeps in contact with the touch screen and continuously moves around the third control to form a closed track such as a circle, square, triangle, etc., that is, determine the target peer device that the corresponding device expects to pair with; or, when the display screen of the corresponding device is a touch screen or a non-touch screen, the corresponding device may also determine that the device information associated with the third control included in the closed track is the target device information when it detects that the cursor continuously moves around the third control on the display screen to form a closed track, that is, determine the target peer device that the corresponding device expects to pair with. In 504 or 509, the corresponding device may also determine that the peer device is the target peer device when it detects that the number of clicks or the dwell time of the finger or cursor on the space representing the peer device reaches a threshold.

[0288] In this embodiment, the movement track of the finger or cursor on the corresponding display screen can be displayed on the corresponding configuration interface to identify the pairing relationship.

[0289] In some embodiments, each configuration interface may include a control for configuring the aforementioned filtering conditions to accurately match the pairable opposite-end devices. The control may include a text box, a list, or a check box, etc. For example, the text box may input the filtering conditions. The list may select the filtering conditions. The check box may check the filtering conditions. Before executing 501 or 506, the doctor may configure the filtering conditions first. In 501 or 506, the corresponding device may encapsulate the configured filtering conditions into the corresponding request and send it to the server, so that the server may filter out the matching opposite-end devices that meet the conditions based on the corresponding request.

[0290] <UI Interaction for Single-ended Calls>

[0291] In some embodiments, the present disclosure provides a method for pairing, see Fig.23 , the method comprising:

[0292] 531. The first device displays a first configuration interface on its first display screen, and in response to obtaining a trigger of a first control in the first configuration interface, sends a first request to a server.

[0293] 532. The server receives a first request sent by the first device, and sends second device information that can be paired with the second device to the first device based on the first request.

[0294] 533. The first device receives the second device information that can be paired with the second device sent by the server, and displays the second device information in the first configuration interface.

[0295] 534. The first device obtains target second device information of a second target device to be paired determined based on the second device information, and sends a first pairing request to the server.

[0296] 535. The server receives a first pairing request sent by the first device.

[0297] After receiving the first pairing request, the server may return a signaling indicating receipt of the first pairing request to the first device.

[0298] 536. The server sends a first pairing request to the target second device associated with the target second device information.

[0299] 537, the target second device receives the first pairing request sent by the server, displays the second configuration interface on the second display screen of the target second device, and generates the first control and the second control in the second configuration interface based on the first pairing request.

[0300] The first control may be, for example, a pop-up dialog box for notifying the doctor whether to accept the pairing of the first device. The second control may be, for example, a button, including a first button and a second button, wherein the first button is used to accept the pairing of the first device when triggered, and the second button is used to reject the pairing of the first device when triggered.

[0301] 538. The target second device obtains a trigger for the second control, and sends a response instruction generated by triggering the second control to the server.

[0302] If it is detected that the first button is triggered, it is determined that the target second device accepts pairing with the first device, and the process goes to 539 ; if it is detected that the second button is triggered, it is determined that the target second device refuses pairing with the first device, and the process goes to 543 .

[0303] 539. The server sends the device network information of the opposite device to at least one of the first device and the target second device.

[0304] 540 , at least one of the first device and the target second device receives the device network information of the opposite device sent by the server, and establishes pairing with the opposite device based on the device network information.

[0305] 541. The server sends a pairing success message to the first device and the target second device.

[0306] 542, the first device receives a pairing success message sent by the server, and displays the pairing success on the first configuration interface; the target second device receives a pairing success message sent by the server, and displays the pairing success on the second configuration interface.

[0307] 543. The server sends a pairing failure message to the first device.

[0308] 544. The first device receives a pairing failure message sent by the server and displays the pairing failure on the first configuration interface.

[0309] A dialog box may pop up on the corresponding configuration interface to indicate whether pairing is successful or failed.

[0310] The methods of 531 to 535 are the same as the methods of 501 to 505 in the above-mentioned embodiment, and will not be repeated here. The method of pairing failure and unpairing can also be the same as the principle described in the above-mentioned embodiment, and will not be repeated here.

[0311] <Administrator direct connection UI interaction>

[0312] In some embodiments, the present disclosure provides a method for pairing, see Fig.24 , the method comprising:

[0313] 601. Display the acquired first device information of the first device registered with the server in the configuration interface of the display screen.

[0314] 602. Obtain target first device information associated with the target first device determined based on the first device information.

[0315] 603. Based on the target first device information, match the second device information of the pairable second device registered with the server and capable of being paired with the target first device, and display the second device information in the configuration interface.

[0316] 604 , obtain target second device information associated with the target second device determined based on the second device information.

[0317] 605 , obtaining device network information of at least one of the target first device and the target second device.

[0318] 606, sending the device network information to a peer device associated with the network information.

[0319] 607, the opposite device receives the network information, and establishes pairing with the local device associated with the network information based on the network information to achieve direct communication.

[0320] In some embodiments, see Figure 25 to Figure 28 , the first device information can be displayed in the configuration interface through the list control 1a. Different first device information is associated with different list options of the list control 1a. When it is detected that the target list option is selected in the list option, it can be determined that the first device information associated with the target list option is the target first device information of the target first device expected to be paired.

[0321] At the same time or with a slight delay, when it is detected that the target list option in the list option 1a is selected, the second device information of the pairable second device that can be paired with the target first device can be matched from the second device registered to the server based on the target first device information associated with the target list option. Among them, the matched second device information of the pairable second device can be displayed in the configuration interface through another list control 1b for the doctor to configure. Different second device information is associated with different list options of the another list control 1b. When it is detected that the target list option in another list option 1b is selected, it can be determined that the second device information associated with the target list option is the target second device information of the target second device expected to be paired.

[0322] In some embodiments, after the target first device and the target second device are determined, the device network information of at least one of the target first device and the target second device can be obtained in response to the triggering of an event. The event includes the server reaching a delay time from the time the target second device is determined, or a control in the configuration interface is triggered, and the control is a control for triggering the acquisition of the device network information of at least one of the target first device and the target second device. For example, the control is Fig.28 The server obtains that the timing reaches the delay time, or obtains that the control is triggered, and obtains device network information of at least one of the target first device and the target second device.

[0323] In some embodiments, after the target first device and the target second device are paired, at least one of the target first device and the target second device may return a pairing success status to the server. The server receives the pairing success status, displays a message of successful pairing in the configuration interface, and sends a message of successful pairing to the target first device and the target second device. The configuration interface in the target first device and the target second device may display the pairing success message. For example, it may be displayed by a pop-up dialog box.

[0324] In some embodiments, see Figure 29 to Figure 31 , the first device information can be displayed on the configuration interface through the first drag control 1a'. Different first device information is associated with different first drag controls 1a'. The configuration interface may include a window control 1c' having a window. When it is detected that the target first drag control in the first drag control 1a' moves to the window of the window control 1c', the first device information of the first device associated with the target first drag control can be determined as the target first device information of the target first device for pairing.

[0325] At the same time or with a slight delay, when it is detected that the target first drag control in the first drag control 1a' moves to the window of the window control 1c', the second device information of the pairable second device that can be paired with the target first device can be matched from the second device registered to the server based on the target first device information associated with the target first drag control. The matched second device information of the pairable second device can be displayed in the configuration interface outside the window through the second drag control 1b', and different second device information is associated with different second drag controls 1b'. When it is detected that the target second drag control in the second drag control 1b' moves to the window 1c', it can be determined that the second device information of the second device associated with the target second drag control is the target second device information of the target second device to be paired. For example, Fig.29 , the first device that can be used for pairing includes the remote doctor console of Hospital A~D; Fig.30When the first drag control 1a' associated with the remote doctor console of Hospital A is moved to the window 1c', the server automatically matches the second device information of the second device that is compatible with the custom protocol supported by the remote doctor console of Hospital A and can be paired, such as the patient surgery platform of Hospitals A~E; Fig.31 When the second drag control 1b' associated with the patient surgery platform of Hospital B is moved to the window 1c', it is determined that the patient surgery platform of Hospital B is a device that is expected to be paired with the remote doctor console of Hospital A.

[0326] In the above embodiments, see Figure 32 to Figure 34 , the window control 1c' may include a first area 11c' and a second area 12c'. The first area 11c' may include a first sub-area 111c' and a second sub-area 112c', the first sub-area 111c' and the second sub-area 112c' are used to accommodate the first drag control 1a', the second area 12c' is used to accommodate the second drag control 1b', and the first sub-area 111c' and the second sub-area 112c' are configured to be associated with different control permissions or different pairing orders. Wherein, in the case where the first drag control 1a' is associated with the remote doctor console and the second drag control 1b' is associated with the patient surgical platform, when the second drag control 1b' moves to the second area 12c', a first drag control 1a' moves to the first sub-area 111c', and another first drag control 1a' moves to the second sub-area 112c', the remote doctor console associated with different first drag controls 1a' may be configured to have different control permissions or pairing orders for the patient surgical platform associated with the second drag control 1b'. For example, Fig.32 , the first device that can be used for pairing includes the remote doctor console of Hospital A~D; Fig.33 When the first drag control 1a' associated with the remote doctor console of Hospital A and the remote doctor console of Hospital B are moved to the first sub-area 111c' and the second sub-area 112c' respectively, the server automatically matches the second device information of the second device that can be paired with the custom protocol supported by the remote doctor console of Hospital A and the remote doctor console of Hospital B, for example, including the patient surgery platform of Hospitals A~C; Fig.34 When the second drag control 1b' associated with the patient surgery platform of Hospital B is moved to the second area 12c', it is determined that the patient surgery platform of Hospital B is a device that is expected to be paired with the remote doctor console of Hospital A and the remote doctor console of Hospital B. If the first sub-area 111c' and the second sub-area 112c' are associated with different control permissions or different pairing orders, the remote doctor console of Hospital A and the remote doctor console of Hospital B are configured to have different control permissions or different pairing orders for the patient surgery platform of Hospital B.

[0327] <Pairing success detection>

[0328] In some embodiments, when the remote doctor console and the patient surgery platform establish real-time pairing, a successful pairing test can be performed on the two to ensure that the remote surgery can proceed smoothly. Among them, relevant tests can be performed using at least one network channel (i.e., communication link) established by the remote doctor console and the patient surgery platform during real-time pairing to determine whether the pairing between the two is truly successful.

[0329] During an ultra-teleoperative procedure, the remote doctor console and the patient surgical platform may involve the interaction of multiple types of network information. For example, these types of network information include the first network information exchanged between the remote doctor console and the core equipment in the patient surgical platform, and the second network information exchanged between the remote doctor console and the auxiliary equipment in the patient surgical platform.

[0330] The first network information may include different types of network information, for example, at least one of motion control information, energy control information, multimedia interaction information, and human-machine interface interaction information. Among them, the motion control information can usually be sent by the remote doctor console and executed by the slave robot, such as master-slave follow-up control; the motion control information can also be sent by the slave robot and executed by the remote doctor console. For example, when the remote doctor console includes an operating unit in the form of a mechanical connecting rod, the slave robot sends motion control information of the posture of its medical device, and the operating unit of the remote doctor console performs the control of aligning the posture of the medical device. Energy control information is usually sent by the remote doctor console and executed by the energy platform, such as controlling the conduction of the unipolar circuit, bipolar circuit, ultrasonic transducer, radio frequency circuit, or microwave circuit of the energy platform. Multimedia interaction information includes video interaction information and audio interaction information. The video interaction information is usually collected from imaging equipment such as an endoscope, and is sent to the display screen of the remote doctor console after being processed by the imaging platform; the audio interaction information is usually collected by the audio intercom devices respectively configured at both ends of the remote doctor console and the slave robot, and is sent to the opposite device for playback after being processed by the imaging platform. Human-machine interaction information is usually operated by the remote doctor console on the touch screen of the display screen, and the interface changed after the operation is displayed on the display screen of the slave hand robot. The operation may be, for example, image annotation.

[0331] The second network information may also include different types of network information. The remote doctor console and different auxiliary devices usually have different network information interactions. The remote doctor console and the same auxiliary device have at least one type of network information interaction. For example, when the auxiliary device includes a monitor, the interaction information includes at least one of the heart rate, pulse, and blood pressure information; for example, when the auxiliary device includes an operating table, the remote doctor console may be configured to control the position or posture of the operating table, and the interaction information includes, for example, the motion control information of the operating table by the remote doctor console.

[0332] In some embodiments, when pairing is established between the remote doctor console and the patient surgical platform, at least one of the remote doctor console and the patient surgical platform creates a network channel for communication between the two based on the device network information sent by the server. In ultra-remote surgery, different network channels can be created to meet the transmission requirements of different types of network information between the remote doctor console and the patient surgical platform. By creating different network channels for the transmission of different types of network information, multiple advantages can be brought about, such as facilitating bandwidth optimization, facilitating priority management, facilitating data isolation to improve security, facilitating fault isolation to improve the fault tolerance of the network, and facilitating compliance of specific data transmission.

[0333] Among them, different network channels can be created by configuring the port numbers of the remote doctor console and the patient surgery platform to distinguish the transmission of different types of network information. For example, a motion control network channel can be created to transmit motion control information; an energy control network channel can be created to transmit energy control information; a multimedia interaction network channel can be created to transmit multimedia interaction information; and a human-machine interface interaction network channel can be created to transmit human-machine interface interaction information.

[0334] In some embodiments, the remote doctor console or the patient surgery platform can create different network channels for transmitting network information of corresponding data types in the remote doctor console and the patient surgery platform according to the different configured control permissions, wherein different control permissions can be associated with the transmission of different data types. In some embodiments, different network channels can be created for transmitting network information between corresponding device types in the remote doctor console and the patient surgery platform according to the different medical and patient information input in the remote doctor console or the patient surgery platform, wherein different medical and patient information can be associated with the transmission of network information between different device types. Exemplarily, medical and patient information includes, for example, the type of surgery or the surgical equipment to be used, and different medical and patient information may need to be used in conjunction with different core devices or auxiliary devices, and thus different network channels can be created based on the number or type of devices that need to be connected.

[0335] In some embodiments, the present disclosure also provides a method for detecting whether pairing is successful. Fig.35 , the method comprising:

[0336] 711. The server obtains information about a target network channel to be established between the first device and the second device, and based on the obtained information about the target network channel, sends device network information of a peer device associated with the target network channel to at least one of the first device and the second device.

[0337] The first device and the second device have a pairing relationship. Different network channels usually have different port numbers. The server sends a port number associated with the target network channel to at least one of the first device and the second device.

[0338] 712. At least one of the first device and the second device receives device network information of the opposite device associated with the target network channel sent by the server, and creates the target network channel with the opposite device based on the device network information.

[0339] 713. At least one of the first device and the second device evaluates a communication state of the target network channel.

[0340] In some embodiments, the communication status of the target network channel can be evaluated by detecting network connectivity. For example, a heartbeat mechanism can be used to detect the network connectivity of the target network channel. The use of the heartbeat mechanism requires the creation of a sender and a receiver at both ends of the target network channel. One of the first device and the second device can be used as the sender and the other can be used as the receiver. When the sender and the receiver are used as a pair, the two can use the TCP protocol or the UDP protocol. When the heartbeat mechanism is used for detection, the sender sends a message to the receiver via the target network channel. If the receiver returns a signal indicating that the message is received within a predetermined time, it indicates that the network connection between the sender and the receiver is normal, that is, the network connectivity of the target network channel between the two is normal; if the receiver does not return a signal indicating that the message is received within a predetermined time, it indicates that the network connection between the sender and the receiver is disconnected, that is, the network connectivity of the target network channel between the two is abnormal.

[0341] In some embodiments, the target network channel includes one or more. When the target network channel includes multiple, different sending ends and receiving ends can be created for different target network channels. In other words, when the target network channel includes a first target network channel and a second target network channel, for the first target network channel, the first device can be used as a sending end and the second device can be used as a receiving end; for the second target network channel, the second device can be used as a sending end and the first device can be used as a receiving end.

[0342] In some embodiments, the communication state of the target network channel can also be evaluated by detecting the network communication quality, for example, the network communication quality can be evaluated by detecting at least one of network delay, jitter, packet loss and disorder of the message transmitted in the target network channel. For example, it can be evaluated by evaluating the network delay. Similarly, a sending end and a receiving end are created at both ends of the target network channel, and the sending end sends a preset type of instruction to the receiving end through the target network channel. The preset type of the instruction can be related to the type of network information to be transmitted by the target network. The instruction is encapsulated into a message transmission according to the custom protocol agreed between the devices at both ends of the target network channel. The message includes a sending timestamp. After receiving the message, the receiving end returns a signal to the sending end through the target network channel. The signal includes a receiving timestamp when the receiving end receives the message. The sending end calculates the difference between the receiving timestamp and the sending timestamp, and compares the difference with the preset delay threshold corresponding to the target network channel. Exemplarily, when the difference is less than the preset delay threshold, the network communication quality is determined to be excellent; when the difference exceeds the first range of the preset delay threshold, the network communication quality is determined to be good; when the difference exceeds the second range of the preset delay threshold, the network communication quality is determined to be poor. In some embodiments, when the network communication quality is a first quality, such as excellent or good, it can be determined that the network communication quality of the target network channel is normal; and when the network communication quality is a second quality, such as poor, it can be determined that the network communication quality of the target network channel is abnormal.

[0343] 714. When the communication status of the evaluated target network channel is normal, at least one of the first device and the second device determines that the first device and the second device are successfully paired.

[0344] 715. When the communication state of the target network channel obtained through evaluation is abnormal, at least one of the first device and the second device determines that pairing of the first device and the second device fails.

[0345] The target network channel may include multiple ones. Whether the pairing between the first device and the second device is successful usually needs to comprehensively consider the communication status of multiple target network channels.

[0346] For example, network connectivity is a key indicator for evaluating communication status. If the network connectivity of all target network channels is normal, it can be determined that the first device and the second device are paired successfully; if the network connectivity of one or more target network channels is abnormal, it can be determined that the first device and the second device have failed to pair. For example, network communication quality is a key indicator for evaluating communication status. If the network communication quality of all target network channels is normal, it can be determined that the first device and the second device are paired successfully; if the network communication quality of one or more target network channels is abnormal, it can be determined that the first device and the second device have failed to pair.

[0347] In some embodiments, for example, when the first device or the second device is configured to have operator authority, it is possible to comprehensively evaluate whether the first device and the second device are successfully paired, based on the priority of the network information transmitted by the target network channel and the communication status of the target network channel. Some target network channels are used to transmit high-priority network information, such as motion control information, energy control information, and video information; some target network channels are used to transmit lower-priority network information, such as audio information and human-computer interaction information. In order to improve the pairing success rate, the system can have a higher degree of redundancy. For example, as long as the communication status of all target network channels used to transmit high-priority network information is normal, even if the communication status of all target network channels used to transmit low-priority network information is abnormal, it can be determined that the first device and the second device are successfully paired. For example, as long as the communication status of any target network channel used to transmit high-priority network information is abnormal, it can be determined that the pairing of the first device and the second device has failed.

[0348] After 714 or 715, a pairing success or pairing failure prompt may be provided in the first device and the second device.

[0349] In the above 711, at least one of the first device and the second device may obtain the configured control authority or the medical and patient information input by the doctor, and may determine the information of the target network channel expected to be established between the first device and the second device based on the control authority or the medical and patient information, and send the determined target network channel information to the server. The server may also obtain the configured control authority or the medical and patient information input by the doctor, and may determine the information of the target network channel expected to be established between the first device and the second device based on the control authority or the medical and patient information.

[0350] In some embodiments, alternatively, in 711, the server sends device network information of the opposite device to at least one of the first device and the second device. The device network information includes all network channels that may be created.

[0351] 712 Alternatively, at least one of the first device and the second device receives device network information of the peer device, and can determine device network information associated with the target network channel from the device network information based on the configured control authority or medical information, and then create a target network channel with the peer device based on the device network information of the target network channel for communication.

[0352] 712 Alternatively, at least one of the first device and the second device receives device network information of the peer device, and creates all network channels with the peer device based on the device network information for communication. 713 Alternatively, at least one of the first device and the second device can determine the target network channel from all network channels based on the configured control authority or medical information, and then evaluate the communication status of the target network channel. In this embodiment, the first device and the second device create all network channels, but can only detect the communication status of the necessary network channels, that is, the target network channels.

[0353] In some embodiments, when it is determined that the first device and the second device are successfully paired, the corresponding device, such as the first device or the second device, may allow or prohibit the use of corresponding control permissions according to the different network communication qualities of multiple target network channels; it may also allow or prohibit the implementation of corresponding surgical procedures according to the different network communication qualities of multiple target network channels. For example, when the network communication quality of multiple target network channels for transmitting high-priority network information, such as motion control information, energy control information, and video information, is better, relatively dangerous surgical procedures may be allowed, such as surgery on arteries, and organs such as lungs, liver, kidneys, and stomach; for example, when the network communication quality of any one of the multiple target network channels for transmitting motion control information, energy control information, and video information is average, only relatively safe surgical procedures may be allowed, such as surgery on skin and fat.

[0354] In some embodiments, the remote doctor console's control authority over the patient's surgical platform includes, but is not limited to, control authority over at least one of a hand robot, an imaging platform, and an energy platform.

[0355] Exemplarily, the control authority includes operator authority and observer authority, and the operator authority is of a higher level than the observer authority. The operator authority covers the observer authority, that is, the observer authority is part of the operator authority. Therefore, the network channels required to be enabled by the operator authority include the network channels required to be enabled by the observer authority, and the number of network channels required to be enabled by the operator authority is greater than the number of network channels required to be enabled by the observer authority.

[0356] In some embodiments, the observer authority is applicable to the observer identity, and is mainly used in the substitute teaching scenario. The intern can learn by observing the doctor's surgical implementation process, and the doctor can also observe the intern's surgical implementation process to provide guidance. The observer authority is mainly reflected in the imaging platform. When configuring the observer authority, it is usually necessary to create a network channel between the remote doctor console and the imaging platform. The imaging platform can process multimedia interactive information, and the imaging platform can also process human-computer interface interactive information. Multimedia interactive information includes, for example, video information and audio information, and human-computer interface interactive information includes, for example, the doctor's annotation information or annotation information of the surgical image collected by the endoscope and displayed on the display screen of the remote doctor console. The video information can come from an endoscope or an external camera installed on the slave robot and electrically connected to the imaging platform. The external camera is used to monitor the working status of at least part of the equipment of the patient's surgical platform. After the video information and the human-computer interface interactive information are processed by the imaging platform, they are transmitted to the remote doctor console through the network channel between the imaging platform and the remote console, and displayed on the display screen of the remote doctor console. The audio information can come from an audio device installed on the slave robot and electrically connected to the imaging platform. The audio device includes an input device and an output device. The input device is such as a microphone, and the output device is such as a speaker. The remote doctor console also includes an audio device. The input device of the remote doctor console and the slave robot can collect sound input, such as voice talk between users at both ends, and after processing by the imaging platform such as denoising, it is transmitted to the output device of the opposite device through the network channel between the remote doctor console and the imaging platform for playback. Among them, depending on the type of multimedia interactive information, the same or different network channels can be created between the remote doctor console and the imaging platform to transmit different types of multimedia interactive information. For example, under the observer authority, when creating different network channels, three network channels can be created respectively, one for transmitting video information, one for transmitting human-computer interface interaction information, and one for transmitting audio information.

[0357] In some embodiments, the operator authority applies to the operator identity, and the operator includes a doctor who performs surgery. The operator authority can be reflected in each device in the patient's surgical platform, including an imaging platform, a slave robot, and an energy platform. The process of the doctor performing the operation may include motion control of the medical equipment (including energy equipment) mounted on the slave robot under the surgical field of view provided by the imaging platform, and energy control of the energy equipment mounted on the slave robot through the control of the energy platform. During the operation, the doctor may mark or annotate the surgical image, or communicate with the doctor or patient on the side of the slave robot by voice. Therefore, under the operator authority, the remote doctor console may create multiple network channels with the imaging platform, the slave robot, the energy platform, and the auxiliary equipment for transmitting different types of network information. In some embodiments, multiple network channels can be created between the remote doctor console and any device according to the different types of signals transmitted between the two or the different physical communication links. In some embodiments, for example, for a laparoscope slave robot or an interventional slave robot, the slave robot includes multiple manipulators, each manipulator is used to assemble a medical device, and the remote doctor console's motion control of the medical device mainly lies in the motion control of the manipulator, and the remote doctor console's motion control of different manipulators is independent of each other, and their physical communication links are different. Therefore, when creating a motion control network channel between the remote doctor console and the slave robot, multiple motion control network channels associated with different manipulators can be created. In some embodiments, the energy platform may include processing of different types of energy control signals, and when creating an energy control network channel between the remote doctor console and the energy platform, multiple energy control network channels associated with different types of energy control signals can be created.

[0358] In some embodiments, different control permissions can be configured in a more detailed manner. When a specific permission is allowed, any device can open or create a network channel corresponding to the permission. When a specific permission is prohibited, any device can close or destroy the network channel corresponding to the permission. Disabling a specific permission helps to shield interference on the one hand; on the other hand, it helps to release bandwidth resources when the network bandwidth is insufficient. For example, when a visual permission that occupies a high network bandwidth is disabled, the released bandwidth resources help to ensure the transmission of other information.

[0359] In some embodiments, the observer rights may include a visible right, an audible and auditory right, and an annotable right, which correspond to the first network channel for transmitting video information, the second network channel for transmitting audio information, and the third network channel for transmitting human-computer interface interaction information. For example, the observer rights may be configured to include a visible right and an audible and auditory right, open or create the first network channel and the second network channel, and close or destroy the third network channel.

[0360] In some embodiments, the operator authority may include partial operator authority and full operator authority, and both partial operator authority and full operator authority may cover observer authority. A remote doctor console may obtain partial operator authority for a patient surgical platform, which is applicable when multiple remote doctor consoles are required to collaboratively operate a patient surgical platform to perform surgery. A remote doctor console may also obtain all operator authority for a patient surgical platform, which is applicable when a remote doctor console is required to independently operate a patient surgical platform to perform surgery.

[0361] In some embodiments, partial operator authority includes, for example, authority to control some manipulators or some types of medical devices in the slave robot. For example, the slave robot may include a first manipulator, a second manipulator, a third manipulator, and a fourth manipulator, one manipulator may be equipped with one medical device, and the medical devices equipped with different manipulators may be the same or different, and partial operator authority may be configured so that a remote doctor console can only control the first manipulator and the second manipulator, and the unconfigured third manipulator and the fourth manipulator may be configured to be controlled by one or more other remote doctor consoles, wherein the configuration of partial operator authority may be implemented based on the unique identification of the manipulator, such as the number of the manipulator. For another example, medical devices may include first type, second type, third type, and fourth type medical devices. The type of medical device is recorded in its storage device. When the medical device is installed on the manipulator of the slave hand robot, it is identified by the read-write device set in the manipulator, and can be sent to the remote doctor console through the motion control network channel between the slave hand robot and the remote doctor console. The remote doctor console can determine whether it can control the medical device based on the type of medical device obtained, wherein some operator permissions can be configured so that a remote doctor console can only control the first type and second type medical devices, and the unconfigured third type and fourth type medical devices can be configured to be controlled by one or more other remote doctor consoles. Exemplarily, the first type of medical device is surgical forceps, the second type of medical device is an endoscope, the third type of medical device is an electrosurgical unit, and the fourth type of medical device is a stapler.

[0362] In some embodiments, full operator privileges include, for example, privileges to control all manipulators in a hand robot or all types of medical instruments.

[0363] In some embodiments, after the above 715, when prompting the pairing failure, the target network channel with abnormal communication status can be prompted to encourage the doctor to detect or maintain the target network channel, or to encourage the doctor to reconfigure the control authority to avoid the image of pairing failure caused by the target network with abnormal communication status. For the latter, for example, in the substitute teaching scenario, when the doctor learns from the prompt of pairing failure that the network channel corresponding to the observer's visible authority is normal, while the network channel corresponding to the audible and auditory authority is abnormal, the observer's authority can be reconfigured to include only the visible authority to ensure successful pairing, and even if the network channel corresponding to the audible and auditory authority is closed or destroyed, there will be no major obstacles to the implementation of the substitute teaching function.

[0364] In some embodiments, when creating a target network channel with a peer device, target network channels with different communication protocol standards can be created according to the different control permissions obtained. For example, when the control authority is observer authority, a target network channel with UDP protocol standards can be created, such as multimedia network channels and human-machine interface interaction network channels that adopt UDP protocol standards, and signaling transmission speed is faster. For another example, when the control authority is operator authority, for observer authority covered by operator authority, a target network channel with UDP protocol standards can be created, and for other authorities, a target network channel with TCP protocol standards can be created, such as motion control network channels and energy control network channels that adopt TCP protocol standards, and their signaling transmission is more reliable, with very little packet loss and disorder, which can ensure the reliable implementation of remote surgery. Of course, each target network channel can also unify the communication protocol standards.

[0365] In some embodiments, a target network channel is created based on medical and patient information, and the medical and patient information may include the type of surgery that the doctor or patient wishes to perform. For example, when the type of surgery is laparoscopic surgery, a target network channel is created between the remote doctor console and the corresponding equipment of the (single-hole / multi-hole) laparoscopic slave robot; when the type of surgery is (bronchial / vascular) interventional surgery, a target network channel is created between the remote doctor console and the corresponding equipment of the (bronchial / vascular) interventional slave robot. Medical and patient information may include surgical equipment required for surgery. For example, when the medical and patient information includes that the surgical equipment requires a slave robot, a monitor, and a ventilator, a target network channel is created between the remote doctor console and the slave robot, the monitor, and the ventilator; when the medical and patient information includes that the surgical equipment requires a slave robot and does not require a monitor and a ventilator, a target network channel is created between the remote doctor console and the slave robot.

[0366] In some embodiments, the configuration of control authority may also be included during the entire pairing phase. Whether the control authority is successfully configured may affect whether the ultra-teleoperative surgery can be reliably implemented, and whether the control authority is successfully configured is an important reference for measuring whether the pairing is successful. Among the control authorities, the successful configuration of the operator authority is particularly important for ensuring the reliable implementation of ultra-teleoperative surgery. In most cases, an ultra-teleoperative surgery is mainly the control of the core equipment in the patient's surgical platform, including both the motion control of the slave robot by the remote doctor console and the energy control of the energy platform by the remote doctor console. Therefore, the operator authority usually involves motion control authority and energy control authority. In some cases, the remote doctor console that is paired with the patient's surgical platform in real time may include one or more. When multiple remote doctor consoles are included, one or more remote doctor consoles may be configured to have only observer authority, and one or more remote doctor consoles may be configured to have operator authority. Among them, a remote doctor console may be configured to have full operator authority, that is, the motion control authority of the slave robot and the energy control authority of the energy platform are both obtained by the remote doctor console. A remote doctor console may be configured to have partial operator authority, for example, including one of the motion control authority over the slave hand robot and the energy control authority over the energy platform being obtained by the remote doctor console; or, including partial motion control authority over the slave hand robot being obtained by the remote doctor console; or, including partial energy control authority over the energy platform being obtained by the remote doctor console, wherein the energy platform may include multiple energy output links, and different energy output links may be controlled by different remote doctor consoles, that is, multiple energy output links may include multiple energy control authorities.

[0367] In a master-slave surgical robot system, the operator authority is usually transparent to the operating end and the executing end, that is, the operating end and the executing end are usually aware of the operator authority they have. For example, the operating end knows which operations he can control the executing end to perform, and the executing end knows which operations controlled by the operating end he can perform. Among them, one of the operating end and the executing end is a remote doctor console and the other can be a patient surgical platform. For example, in master-slave control, the operating end is a remote doctor console, and the executing end is a slave robot or energy platform of the patient surgical platform; while in master-slave alignment, the operating end is a slave robot and the executing end is a remote doctor console.

[0368] In some embodiments, the successful configuration of operator permissions includes at least two aspects. The first aspect includes that the configuration is successful if the permissions are possessed (i.e., allowed), indicating that the operations that are expected to be performed can be performed; the second aspect includes that the configuration is successful if the permissions are not possessed (i.e., prohibited), indicating that the operations that are expected not to be performed cannot be performed. Whether the operator permissions are successfully configured includes the detection of at least one of the two aspects. Based on this, for a remote doctor console and a patient surgery platform that have established real-time pairing, the present disclosure provides a method for detecting whether the operator permissions are successfully configured, the method comprising:

[0369] 721, at least one of the remote doctor console and the patient surgery platform obtains the ownership authority among the configured operator authorities.

[0370] The ownership authority mainly includes authority attribution, and authority attribution includes association with the controlled object. The operating end can only control the controlled object in the execution end, but cannot control the uncontrolled object. From the perspective of the remote doctor's console, the controlled object may include a specific manipulator component in the slave hand robot that is expected to be controlled or a manipulator component associated with a specific type of medical device; the controlled object may include a specific energy output link in the energy platform that is expected to be controlled. From the perspective of the patient's surgical platform, the controlled object may include a specific manipulator component in the slave hand robot that is expected to be controlled by the remote doctor's console or a manipulator component associated with a specific type of medical device; the controlled object may include a specific energy output link in the energy platform that is expected to be controlled by the remote doctor's console. Therefore, whether from the perspective of the remote doctor's console or from the perspective of the patient's surgical platform, the two ends are corresponding in terms of authority attribution. Among them, "specific" includes all or part.

[0371] Different authority attributions can be closely associated with the authority type of the operator authority. For example, when the controlled object includes a manipulator component, the authority type is usually associated with motion control authority; for another example, when the controlled object includes a specific energy output link, the authority type is usually associated with energy control authority. That is, when configuring operator authority, it is usually sufficient to configure the authority attribution, and the associated authority type can be configured by default according to the authority attribution.

[0372] In addition, different types of control instructions are usually required for control based on the different types of permissions of the controlled object. For example, when the permission type is motion control permission, motion control instructions need to be sent to control the controlled object; when the permission type is energy control permission, energy control instructions need to be sent to control the controlled object.

[0373] 722. The remote doctor console determines the controlled object from the patient's surgical platform based on the ownership of the permissions, and determines the target control instruction associated with the controlled object from the preset control instruction set.

[0374] Even if the slave robots in the two patient surgical platforms are of the same type, the kinematics of the two slave robots may be slightly different due to differences in mechanical processing and mechanical assembly, so a preset control instruction set can be designed for each patient surgical platform. The preset control instruction set includes motion control instructions generated by simulating the motion of the operating part of the remote doctor console and energy control instructions generated by simulating the excitation of the foot pedal assembly of the remote doctor console, both of which may include at least one control instruction.

[0375] For example, in a laparoscope slave robot, different motion control instructions can be designed for different manipulator components in the slave robot. The motion control instruction mainly controls the medical device mounted on the manipulator by controlling the manipulator in the manipulator component. The motion control instruction is usually a posture instruction, which includes at least one of a position instruction and a posture instruction.

[0376] In some embodiments, the slave robot includes a main arm and a plurality of manipulators connected to the distal end of the main arm. When the slave robot is powered on and initialized, the main arm unfolds to drive each manipulator to reach a first initial position fixed relative to a base coordinate system. When the medical device is assembled to the manipulator, the manipulator performs initialization operations on the medical device, which also enables the medical device to be fixed relative to the base coordinate system and maintained at a second initial position, which is different from the first initial position. Medical devices include endoscopes and surgical instruments. Usually, the movement of an endoscope is relative to a base coordinate system, and the movement of a surgical instrument is relative to an endoscope coordinate system. However, when detecting whether the motion control authority is configured successfully, the control method can be simplified. For example, it can be defined that the remote doctor console controls the movement of all types of medical devices relative to the base coordinate system.

[0377] In the manipulator assembly of the same slave robot, the kinematic model of the manipulator is basically the same, and the kinematic model of the medical device may be the same or different.

[0378] Assuming that the kinematic models of different medical devices suitable for the slave robot are basically the same, when each medical device is in the second initial posture relative to the base coordinate system, the current joint parameters of each joint in the manipulator and the target joint increment of at least part of the joints can be combined, and the target posture of the medical device relative to the base coordinate system can be determined based on the kinematic model of the manipulator and the kinematic model of the medical device. The target joint increment is pre-designed and can be a smaller value. For example, when the joint parameters are all joint angles, the target joint increment can be designed to be 0.1°, 0.5°, 1°, 1.5°, 2°, or other values ​​between any two of the aforementioned values, etc., to reduce the subsequent movement amplitude used to verify whether the ownership authority is successfully configured. Of course, the target posture of each manipulator component can also be a directly specified posture relative to the base coordinate system, and the target posture is different from its corresponding second initial posture. For example, the target posture is an upward, downward, left, right, forward or backward posture relative to the second initial posture. In this case, the target posture of each manipulator component will not change because the manipulator is installed with different medical devices, that is, each manipulator component is associated with a relatively fixed target posture. The target posture designed here is a target motion control instruction for detecting whether the motion control authority is successfully configured. Further, in 722, the step of determining a controlled object from the patient surgical platform and determining a target control instruction associated with the controlled object from a preset control instruction set includes: determining a controlled manipulator component from the slave hand robot, and determining a target motion control instruction associated with the controlled manipulator component from a preset control instruction set based on the controlled manipulator component.

[0379] Assuming that the kinematic models of different medical devices suitable for the slave robot are basically different, the target postures of different medical devices installed on different manipulators can be pre-designed based on the above-mentioned similar methods when the manipulator and the medical device are in the corresponding initial posture state. When the same medical device is installed on different manipulators, the target postures of each manipulator component are different; when different medical devices are installed on the same manipulator, the target postures of the manipulator component are also different. That is, the target posture of the manipulator component is associated with the medical device itself and the manipulator on which the medical device is installed. Furthermore, in 722, the steps of determining the controlled object from the patient surgical platform and determining the target control instructions associated with the controlled object from the preset control instruction set include: determining the controlled manipulator component from the slave robot, identifying the medical device in the controlled manipulator component, and determining the target motion control instructions associated with the controlled manipulator component from the preset control instruction set based on the controlled manipulator component and the medical device assembled thereon.

[0380] In some embodiments, the design of the energy control instruction is relatively simple. When the energy platform includes multiple energy output links, the energy control instruction includes multiple energy control instructions corresponding to the multiple energy output links. These energy control instructions may include switch control instructions, current regulation instructions, voltage regulation instructions, power regulation instructions, or frequency regulation instructions, etc. Further, in 722, the steps of determining the controlled object from the patient surgical platform and determining the target control instruction associated with the controlled object from the preset control instruction set include: determining the controlled energy output link from the energy platform, and determining the target energy control instruction associated with the controlled energy output link from the preset control instruction set.

[0381] At 723, the remote doctor console sends a target control instruction to the patient's surgical platform.

[0382] The communication between the remote doctor console and the patient surgery platform is achieved through a network channel established between the two, and the communication includes the transmission of target control instructions and the transmission of the actual execution results of executing the target control instructions.

[0383] 724, the patient surgery platform receives the target control instruction, and the controlled object of the patient surgery platform executes the target control instruction.

[0384] In some embodiments, a doctor on the controlled object side can observe the controlled object's execution of the target control instruction and notify the remote doctor console or the patient's surgical platform of the observation results. The observation results include successful execution or failed execution. Successful execution may indicate successful configuration of the ownership authority in the operator's authority, and failed execution may indicate failed configuration of the ownership authority in the operator's authority.

[0385] In some embodiments, see Fig.36 , the method may further include:

[0386] 725. After the controlled object executes the target control instruction, the patient surgery platform returns the actual execution result to the remote doctor console.

[0387] If the target control instruction is a motion control instruction, the actual execution result may include the actual position and posture of the corresponding manipulator component relative to the base coordinate system. If the target control instruction is an energy control instruction, the actual execution result may include the actual energy output state of the corresponding energy transmission link, and the actual energy output state includes the actual switch state, the actual current output value, the actual voltage output value, the actual power output value or the actual frequency output value.

[0388] 726 , the remote doctor console receives the actual execution result and detects whether the actual execution result matches the expected execution result.

[0389] The expected execution result may be an execution result determined based on the target control instruction under an ideal state. If the target control instruction is a motion control instruction, the expected execution result may include the expected posture of the corresponding manipulator component relative to the base coordinate system. If the target control instruction is an energy control instruction, the expected execution result may include the expected energy output state of the corresponding energy transmission link, the expected energy output state, the expected switch state, the expected current output value, the expected voltage output value, the expected power output value, or the expected frequency output value.

[0390] 727, when it is detected that the actual execution result matches the expected execution result, it is determined that the permission configuration is successful.

[0391] The actual execution result matches the expected execution result, which includes at least one meaning. This meaning includes that the controlled object will respond to the target control instruction action. This meaning includes that the controlled object moves in response to the motion control instruction, or the controlled object outputs energy in response to the energy control instruction.

[0392] The actual execution result matches the expected execution result, and can also include another meaning. This meaning includes that the controlled object accurately responds to the target control instruction action. This meaning includes that the target control instruction is a motion control instruction, and in the same coordinate system, the deviation between the actual posture and the expected posture is within the deviation threshold; or, corresponding to the target control instruction is an energy control instruction, when the actual energy output state is the actual switch state and the expected energy output state is the expected switch state, the actual energy output state and the expected energy output state should be consistent, such as the open state; the actual energy output state is the actual current output value, the actual voltage output value, the actual power output value or the actual frequency output value, and the expected energy output state is the expected current output value, the expected voltage output value, the expected power output value or the expected frequency output value, the deviation between the actual energy output state and the expected energy output state is within the deviation threshold.

[0393] 728, when it is detected that the actual execution result does not match the expected execution result, it is determined that the permission configuration fails.

[0394] Through 725~728, it is possible to more intelligently determine whether the ownership permissions in the operator permissions are configured successfully.

[0395] In some embodiments, see Fig.37 , it is also possible to further detect whether the unowned permissions in the operator permissions are configured successfully, and the method may include:

[0396] 731, the remote doctor console and the patient surgery platform obtain the unpossessed permissions among the configured operator permissions.

[0397] Operator authority includes possessed authority and non-possessed authority. Non-possessed authority can be obtained independently or according to possessed authority in operator authority. As mentioned above, the authority of possessed authority is associated with the controlled objects in the patient surgical platform, and the authority of non-possessed authority is associated with the uncontrolled objects in the patient surgical platform. Assuming that different uncontrolled objects can be controlled, corresponding control instructions need to be sent. For example, when the uncontrolled object is a manipulator component, motion control instructions need to be sent, and when the uncontrolled object is an energy output link, energy control instructions need to be sent.

[0398] 732. The remote doctor console determines the non-controlled object from the patient's surgical platform based on the ownership of the authority that is not possessed, and determines the target control instruction associated with the non-controlled object from the preset control instruction set.

[0399] The design of the preset control instruction set for the non-controlled object can refer to the design of the preset control instruction set for the controlled object, and will not be repeated here.

[0400] When the kinematic models of different medical devices suitable for the slave robot are basically the same, in 732, the steps of determining the uncontrolled object from the patient surgical platform and determining the target control instructions associated with the uncontrolled object from the preset control instruction set include: determining the uncontrolled manipulator component from the slave robot, and determining the target motion control instructions associated with the uncontrolled manipulator component from the preset control instruction set based on the uncontrolled manipulator component.

[0401] When the kinematic models of different medical devices suitable for the slave robot are basically different, in 732, the steps of determining an uncontrolled object from the patient surgical platform and determining a target control instruction associated with the uncontrolled object from a preset control instruction set include: determining an uncontrolled manipulator component from the slave robot, identifying the medical device in the uncontrolled manipulator component, and determining the target motion control instruction associated with the uncontrolled manipulator component from the preset control instruction set based on the uncontrolled manipulator component and the medical device assembled thereon.

[0402] In 732, the steps of determining an uncontrolled object from the patient surgical platform and determining a target control instruction associated with the uncontrolled object from a preset control instruction set include: determining an uncontrolled energy output link from the energy platform, and determining a target energy control instruction associated with the uncontrolled energy output link from the preset control instruction set.

[0403] 733, the remote doctor console sends target control instructions to the patient's surgical platform.

[0404] 734, the patient surgery platform receives the target control instruction, and the non-controlled object of the patient surgery platform executes the target control instruction.

[0405] Wherein, if the configuration of the non-controlled object is successful without the permission, the non-controlled object will not receive the target control instruction, or even if the target control instruction can be received, the target control instruction will not be executed. The reason for not receiving the target control instruction includes that the network channel between the remote doctor console and the non-controlled object will not be created according to the configuration of the control permission, or even if the network channel between the remote doctor console and the non-controlled object is created, the target control instruction will not be transmitted between the two according to the configuration of the control permission. Accordingly, in 734, the patient's surgical platform may not receive the target control instruction, or its non-controlled object may not execute the target control instruction. That is, in any case, when the configuration of the non-controlled object is successful, there will be no change in the state of the non-controlled object, including that the motion state will not change or the energy output state will not change. When the configuration of the non-controlled object fails, the state of the non-controlled object will change, including that the motion state changes or the energy output state changes. Wherein, in an abnormal state, the reason for the failure of the configuration of the non-controlled object may include that the transmission of the target control instruction in the network channel is disturbed, or that the network channel is incorrectly created between the remote doctor console and the patient's surgical platform.

[0406] Whether the state of the uncontrolled object occurs can be determined by the doctor's observation on the uncontrolled object side. The doctor can notify the remote doctor console or the patient's surgery platform of the observation result, so as to manually determine whether the uncontrolled permission is successfully configured.

[0407] In some embodiments, see Fig.17 , the method may further include:

[0408] 735, after the non-controlled object executes the target control instruction, the patient surgery platform returns the actual execution result to the remote doctor console.

[0409] Regardless of whether the non-controlled object executes the target control instruction, the patient surgery platform can return the actual execution result to the remote doctor console, and the actual execution result includes whether the state of the non-controlled object changes.

[0410] 736 , the remote doctor console receives the actual execution result and detects whether the actual execution result matches the expected execution result.

[0411] When the authority is not possessed, the expected execution result associated with the target control instruction usually includes that the state of the non-controlled object has not changed. Among them, the state of the non-controlled object has not changed includes that the motion state has not changed or the energy output state has not changed. The motion state has not changed means that the posture of the non-controlled manipulator component has not changed; the energy output state has not changed means that the switch state of the non-controlled energy platform has not changed, the current output value has not changed, the voltage output value has not changed, the power output value has not changed, or the frequency output value has not changed.

[0412] 737: When it is detected that the actual execution result matches the expected execution result, it is determined that the permission configuration is not successful.

[0413] For example, when the actual execution result corresponds to the state of the non-controlled object not changing, which matches the expected execution result corresponding to the state of the non-controlled object not changing, it can be determined that the permission configuration is successful.

[0414] 738. When it is detected that the actual execution result does not match the expected execution result, it is determined that the permission configuration fails.

[0415] For example, when the state of the non-controlled object corresponding to the actual execution result changes, it does not match the expected execution result that the state of the non-controlled object does not change, and it can be determined that the configuration fails due to lack of permission.

[0416] Through 735~738, it is possible to more intelligently determine whether the unowned permissions in the operator permissions are configured successfully.

[0417] In some embodiments, when one or more remote doctor consoles are paired with the patient's surgical platform in real time, for any remote doctor console, when the remote doctor console has both permissions and permissions are successfully configured, it can be confirmed that the remote doctor console has actually been successfully paired with the patient's surgical platform; when the remote doctor console fails to have permissions or fails to have permissions, it can be confirmed that the remote doctor console has actually failed to be paired with the patient's surgical platform. Such successful pairing detection can fully guarantee the smooth implementation of ultra-remote surgery.

[0418] <Switch pairing>

[0419] In some embodiments, a device (local device) can be paired with multiple peer devices. For example, a remote doctor console can be paired with multiple patient surgical platforms. For another example, a patient surgical platform can also be paired with multiple remote doctor consoles. The doctor can configure the device to establish pairing with multiple peer devices at the same time, and the pairing established between them can be a scheduled pairing. The device can obtain pairing information with multiple peer devices from the server, and the pairing information includes the pairing order of the peer devices and the device network information. Since the device can record the pairing order with other peer devices, the pairing order can also be obtained by the device itself. The pairing order can be default, for example, the pairing configured first has an earlier pairing order; the pairing configured later has a later pairing order. The pairing order can be preset, for example, it can be preset to have a pairing order with the first peer device in front and a pairing order with the second peer device in the back. The pairing order can be determined by the scheduled pairing time. The pairing order with a relatively earlier scheduled pairing time is earlier. The pairing order can be determined according to the urgency of the operation. For example, in the medical and patient information input within the same time range, such as 0 to 30 minutes, the operation with a higher urgency is configured with a higher pairing order by default. When the time range is exceeded, the pairing order can be set according to the default pairing method.

[0420] In some surgical scenarios, to ensure the safety and privacy of the surgery, at the same time, the device can only be paired with one peer device in real time, and can be paired with other peer devices by appointment. For example, a remote doctor console can only be paired with one patient surgical platform in real time, and can be paired with other patient surgical platforms by appointment. For another example, a patient surgical platform can only be paired with one remote doctor console in real time, and can be paired with other remote doctor consoles by appointment.

[0421] In these surgical scenarios, the present disclosure provides a method for quickly switching pairings, see Fig.38 , the method comprising:

[0422] 801. A device obtains pairing information of multiple peer devices with which the device has established a scheduled pairing.

[0423] The pairing information includes the pairing order and device network information of the plurality of peer devices. The plurality of peer devices include a first peer device and a second peer device.

[0424] 802 , when the device determines that a first peer device among multiple peer devices has a priority pairing order based on the pairing order in the pairing information, the device establishes real-time pairing with the first peer device based on the device network information of the first peer device in the pairing information.

[0425] 803, when the device detects that the switching pairing condition is met, the device cancels the real-time pairing with the first peer device, and establishes the real-time pairing with the second peer device based on the device network information of the second peer device in the pairing information.

[0426] When the device cancels the real-time pairing with the first peer device, the device may update the pairing information, for example, it may mark that the first peer device has been paired, or it may delete the device network information of the first peer device to avoid real-time pairing with the first peer device again. The device may send the updated pairing information to the server for the server to maintain the pairing table, such as marking the pairing status of the relevant device.

[0427] In this embodiment, the device is allowed to establish a new real-time pairing with the second peer device only when the switching pairing condition is met, which can prevent accidental interruption of the ultra-teleoperative surgery being performed by the first peer device and ensure the continuous implementation of the ultra-teleoperative surgery.

[0428] In some embodiments, satisfying the switching pairing condition includes at least two aspects: the device and the first peer device satisfy a real-time pairing release condition; and the device and the second peer device satisfy a real-time pairing establishment condition.

[0429] In some embodiments, the device and the first peer device satisfy at least one of the conditions for releasing the real-time pairing: the operation is completed, the operation is abnormally interrupted, and the two end devices agree to switch the pairing.

[0430] The completion of the operation includes at least one of (1) to (3): (1) obtaining that the physical accessories necessary for the operation are detached from the hand robot or from the patient's body and the delay time has elapsed, or obtaining that the hand robot is restored to the preoperative preparation state and the delay time has elapsed; (2) obtaining that the imaging platform is shut down and the delay time has elapsed, or obtaining that the field of view provided by the imaging device such as an endoscope in the hand robot is switched from the surgical field of view to the non-surgical field of view and the delay time has elapsed; (3) obtaining that the doctor or patient leaves the surgical environment and the delay time has elapsed.

[0431] Regarding (1), for various types of master-slave surgical robot systems, for example, for laparoscopic surgical robot systems or interventional surgical robot systems, obtaining the necessary physical accessories for surgery to be detached from the slave robot includes: obtaining at least one of the following: all medical devices to be detached from the slave robot (its manipulator), the sterile cover to be detached from the slave robot, and the puncture device for guiding the insertion of medical devices into the patient's body to be detached from the slave robot (its manipulator). Obtaining the necessary physical accessories for surgery to be detached from the patient's body includes: obtaining at least one of the following: all medical devices to be withdrawn from the patient's body, the puncture device to be withdrawn from the patient's body, and auxiliary equipment such as a monitor or a ventilator to be detached from the patient's body. Obtaining the slave robot to be restored to the preoperative preparation state includes obtaining the slave robot's mechanical arm to be restored to the folded state, or the support feet of the slave robot chassis to be reset.

[0432] Regarding (2), during surgery, the provision of images is crucial, and the delay time when the image platform is shut down often indicates that the surgery is completed. Among them, the delay time when the field of view is switched from the surgical field of view to the non-surgical field of view includes: the delay time when the field of view is switched from the surgical field of view to the non-surgical field of view includes the endoscope being pulled out of the patient's body, or the image captured by the endoscope does not include human tissues or organs.

[0433] Regarding (3), obtaining that the doctor or patient has left the operating environment for a delay time includes: obtaining that the doctor has left the operating environment includes obtaining that the doctor has left the remote doctor console. Obtaining that the patient has left the operating environment includes obtaining that the patient has left the operating bed or that the operating bed carrying the patient has been removed from the operating room.

[0434] Regarding abnormal interruption of surgery, it includes detecting abnormal network status of the network channel, for example, detecting abnormal network connectivity or abnormal network communication quality. Further, confirming the abnormal network status can be superimposed with a judgment condition, which includes, for example, that the accumulated time of the abnormal network status reaches a time threshold, or that the accumulated number of abnormal network status reaches a number threshold.

[0435] Regarding the two end devices agreeing to switch pairing, it includes that either end initiates a switch pairing request to the other end, and the other end accepts the switch pairing request. The other end device can notify the end that initiates the switch pairing request.

[0436] In some embodiments, the device and the second peer device satisfying the real-time pairing condition include: the second peer device and the device have established a scheduled pairing. The establishment of a scheduled pairing between the two can speed up the speed of switching the pairing.

[0437] In some embodiments, when the device is paired with any peer device in real time, it also includes establishing a network channel with the peer device. Establishing a network channel includes establishing all network channels and only establishing a target network channel based on the configured control authority. When the device is unpaired from any peer device in real time, it also includes destroying all network channels or target network channels established with the peer device.

[0438] In some embodiments, when the device is paired with any peer device in real time, it also includes that the device and the peer device obtain the configured control authority. At least one of the device and the peer device can create a target network channel based on the obtained configured control authority. When the device is unpaired from any peer device in real time, it also includes that the device and the peer device release the configured control authority.

[0439] In some embodiments, in 802, the device establishes a real-time pairing with a first peer device, and also includes establishing a first master-slave mapping relationship between the device and the first peer device. In 803, the device releases the real-time pairing with the first peer device, and also includes the device disconnecting the first master-slave mapping relationship between the peer device, and when the first master-slave mapping relationship is disconnected, the master-slave control is interrupted, including the master-slave motion control or the master-slave energy control interruption. Wherein, for safety reasons, when the master-slave motion control is interrupted, the manipulator component can be configured to maintain at least one of the current position and posture, and when the master-slave energy control is interrupted, the energy platform can be configured to reduce or shut down the energy output. In 803, the device establishes a real-time pairing with a second peer device, and also includes establishing a second master-slave mapping relationship between the device and the second peer device. Exemplarily, one of the device and the peer device includes a remote doctor console, and the other includes a slave hand robot or an energy platform. The device and the peer device are usually controlled according to the master-slave mapping relationship when performing motion control or energy control. Among them, motion control occurs between the remote doctor console and the slave robot. The remote doctor console can control the movement of the slave robot, such as in master-slave control; the slave robot can also control the movement of the remote doctor console, such as in the master-slave alignment of the laparoscopic surgical robot system. Energy control occurs between the remote doctor console and the energy platform. The remote doctor console controls the switch, current regulation, voltage condition, power regulation, or frequency regulation of the energy platform.

[0440] When the device is paired with the first peer device in real time, the two establish a first master-slave mapping relationship and control each other through the first master-slave mapping relationship. When the device cancels the real-time pairing with the first peer device and establishes a real-time pairing with the second peer device, since the first peer device and the second peer device may be of different device types, and different device types usually correspond to different robotic arm configurations or energy output methods, etc., it may be inappropriate for the two to still be controlled through the first master-slave mapping relationship, and it is necessary to re-establish a master-slave mapping relationship that is suitable for the device and the second peer device. Assuming that the reconstructed master-slave mapping relationship is the second master-slave mapping relationship, then when the device switches from real-time pairing with the first peer device to real-time pairing with the second peer device, in order to ensure the smooth implementation of remote surgery, it is necessary to switch the first master-slave mapping relationship to the second master-slave mapping relationship.

[0441] In some embodiments, the master-slave mapping relationship between the device and the peer device includes at least one of a first master-slave mapping logic and a second master-slave mapping logic. The first master-slave mapping logic includes a master-slave mapping logic in which the device controls the peer device. The second master-slave mapping logic includes a master-slave mapping logic in which the peer device controls the device.

[0442] In some embodiments, the master-slave mapping logic includes a master-slave motion mapping logic. Take the device as a remote doctor console and the peer device as a slave robot as an example. Different types of slave robots usually have different mechanical arm structures, and their controlled structures, such as the structure of the manipulator assembly used to perform surgery, are often different. Different manipulator assemblies may involve different connecting rod parameters. During master-slave control, different kinematic models should be determined according to the different manipulator assemblies, and then the manipulator assembly movement is controlled based on the corresponding kinematic model. Different types of slave robots may need to control the movement of the manipulator assembly according to different motion scaling ratios when executing the same posture instruction because the structure of the manipulator assembly may be different. Different types of slave robots often include manipulator assemblies arranged in different numbers or positions. During master-slave control, an operating unit usually controls a manipulator assembly. When the manipulator assembly controlled by the operating unit needs to be switched, the manipulator assembly may need to be switched according to a specific instrument switching logic, and different types of slave robots may correspond to different instrument switching logics. In the master-slave control, different types of slave robots may have different instrument operation logics for controlling the movement of different medical instruments. For example, in a single-hole laparoscope slave robot, two operating parts are manipulated to move simultaneously to generate control instructions for controlling the movement of the endoscope. In a multi-hole laparoscope slave robot, one operating part is manipulated to move to generate control instructions for controlling the movement of the endoscope. Therefore, the master-slave motion mapping logic may include at least one of the kinematic model, motion scaling, instrument switching logic, and instrument operation logic involved in the master-slave control. Among them, the kinematic model involved in the master-slave control includes at least the kinematic model of the controlled structure such as the manipulator assembly in the slave robot, and it may also include the kinematic model of the robotic arm in the operating part of the remote doctor's console.

[0443] In some embodiments, the master-slave mapping logic includes a master-slave energy mapping logic. Take the device as a remote doctor console and the peer device as an energy platform as an example. Different energy platform types may have different types of energy output forms. The remote doctor console sends energy control instructions to the energy platform, and the energy output based on the energy control instructions includes specific conversion relationships. For example, some conversion relationships include current size conversion, some conversion relationships include power size conversion, and some conversion relationships include frequency size conversion. Therefore, the master-slave energy mapping logic may include energy output conversion relationships during master-slave control, etc.

[0444] In some embodiments, for example, in a laparoscopic surgical robot system, the remote doctor console includes a first type of remote doctor console and a second type of remote doctor console, the first type of remote doctor console has an operating unit in the form of a mechanical link, and the second type of remote doctor console has an operating unit in the form of a magnetic navigation. For example, when the device refers to the remote doctor console and the peer device refers to the slave robot:

[0445] If the remote doctor console is a first type remote doctor console, the remote doctor console can perform master-slave (follower) control on the slave hand robot, and the slave hand robot can also control the remote doctor console for master-slave alignment. The former requires the first master-slave mapping logic, and the latter requires the second master-slave mapping logic, that is, the master-slave mapping relationship includes the first master-slave mapping logic and the second master-slave mapping logic.

[0446] If the remote doctor console is the second type of remote doctor console, the remote doctor console can perform master-slave (follower) control of the slave-hand robot, but the slave-hand robot cannot control the remote doctor console for master-slave alignment. Only the former requires the first master-slave mapping logic, that is, the master-slave mapping relationship can only include the first master-slave mapping logic.

[0447] In some embodiments, the device information of the remote doctor console and the patient surgery platform may include the information included in the master-slave mapping logic, and when registering with the server, this information may be stored in the server, and when pairing, this information may be sent to the peer device. Furthermore, a master-slave mapping relationship is established based on the master-slave mapping logic of at least one of the two ends.

[0448] In some embodiments, when the device is a remote doctor console and the peer device is a patient surgery platform, when the device is paired with any peer device in real time, it also includes updating the UI interface on the device's display screen. Specifically, when the device is paired with a first peer device in real time, the device's display screen displays a first UI interface; when the device switches from real-time pairing with a first peer device to real-time pairing with a second peer device, the device's display screen displays a second UI interface. The first UI interface is associated with the information of the first peer device, and the second UI interface is associated with the information of the second peer device. Different peer devices may have at least one difference in the number, type, and status of the devices, resulting in different information of different peer devices, which needs to be accurately displayed accordingly. For example, the first peer device includes a single-port laparoscope slave robot, and the second peer device includes a multi-port laparoscope slave robot. At least the changes in the slave robot model and status may cause the two UI interfaces to be different.

[0449] In some embodiments, when it is found that the remote doctor console has an operating part of a robotic arm, when the device is paired with any peer device in real time, in order to facilitate and quickly complete preoperative preparations, one or more remote doctor consoles that have obtained operator authority can be automatically aligned with the master and slave. Fig.39 , the master-slave alignment method includes:

[0450] 8031, the patient surgical platform sends the current posture of the end of the medical instrument of a manipulator component in the hand robot in the endoscopic coordinate system to the remote doctor console that has operator authority over the manipulator component.

[0451] The operator authority mainly refers to the motion control authority. The transmission of the current posture can be based on the motion control network channel created by the remote doctor console and the patient surgery platform according to the operator authority.

[0452] 8032, the remote doctor console obtains the current posture of the end of the medical instrument in the endoscope coordinate system sent by the patient's surgical platform.

[0453] 8033, based on the current posture of the end of the medical device in the endoscope coordinate system, the remote doctor console converts the current posture of the end of the medical device in the endoscope coordinate system into the target posture of the operating part in the display screen coordinate system in the remote doctor console.

[0454] 8034, the remote doctor console obtains the target joint parameters of each joint of the robot arm in the operating part by analyzing the target posture based on inverse kinematics.

[0455] 8035, the remote doctor console controls the movement of the corresponding joints in the robot arm based on the target joint parameters of each joint, so that the end of the operating part reaches the target posture in the display screen coordinate system, so that the posture of the operating part is aligned with the posture of the end of the medical device, realizing master-slave alignment.

[0456] Through the above 8031~8035, the operation part and the medical device can be aligned in posture, which is beneficial to quickly complete preoperative preparation on the one hand, and is beneficial to the doctor to realize hand-eye intuition when controlling the associated medical device by manipulating the operation part on the other hand.

[0457] <Exchange of Control Rights>

[0458] In some embodiments, in some surgical scenarios such as substitute teaching scenarios, at the same time, multiple remote doctor consoles can be paired with one patient surgical platform in real time, wherein different remote doctor consoles are configured to have different control permissions. In the substitute teaching scenario, it is assumed that there are a first remote doctor console and a second remote doctor console paired with the same patient surgical platform in real time, the first remote doctor console is configured to have one of operator permissions and observer permissions, and the second remote doctor console is configured to have the other of operator permissions and observer permissions. The remote doctor console with operator permissions focuses on "teaching", and the remote doctor console with observer permissions focuses on "learning"; alternatively, the remote doctor console with operator permissions focuses on "drilling", and the remote doctor console with observer permissions focuses on "guidance". In order to quickly switch between teaching and learning, or between drill and guidance, the present disclosure also provides a method for quickly switching control permissions, see. Fig.40 , the method comprising:

[0459] 901, the first remote doctor console sends a request for exchange control authority to the patient surgery platform.

[0460] The control authority exchange request is used to request to exchange control authority with a target second remote doctor console in at least one second remote doctor console. The first remote doctor console and at least one second remote doctor console have different control authorities, for example, the first remote doctor console has a first control authority, and at least the second remote doctor console has a second control authority. Multiple second remote doctor consoles may have different second control authorities.

[0461] 902, the patient surgery platform receives the exchange control authority request sent by the first remote doctor console, and forwards it to the target second remote doctor console.

[0462] Since the first remote doctor console and the second remote doctor console do not communicate directly, the patient surgery platform can act as a server to transfer relevant information.

[0463] 903, the target second remote doctor console receives the exchange control authority request and obtains a response instruction generated in response to the exchange control authority request.

[0464] The second remote doctor console may generate and play a notification based on the received exchange control authority request to facilitate the doctor to respond to the exchange control authority request based on the notification.

[0465] The content of the notification may be to notify the second remote doctor console whether to accept the exchange control authority request initiated by the first remote doctor console. The notification may be played in the form of a UI interface or in the form of sound. The doctor may respond to the exchange control authority request through an operable control of the UI interface or through voice recognition. The response includes acceptance or rejection.

[0466] 904, the target second remote doctor console sends a response instruction to the patient's surgical platform.

[0467] 905. The patient surgery platform receives the response instruction. When the response instruction is an affirmative response instruction, the first control authority of the first remote doctor console is configured as the second control authority of the target second doctor console, and the second control authority of the target second remote doctor console is configured as the second control authority of the first doctor console.

[0468] The response instruction includes an affirmative response instruction or a negative response instruction. An affirmative response instruction refers to a response instruction generated when the target second remote doctor console obtains a request to accept the exchange control authority. A negative response instruction refers to a response instruction generated when the target second remote doctor console obtains a request to reject the exchange control authority.

[0469] In addition, when the response instruction is a negative response instruction, the patient surgery platform does not reallocate the control authority of the first remote doctor console and the target second remote doctor console, and both maintain the original control authority.

[0470] In S905, the patient surgery platform usually needs to receive an affirmative response instruction within a preset time range before reconfiguring the control authority of the first remote doctor console and the target second remote doctor console. The preset time range usually refers to the time from when the patient surgery platform forwards the exchange control authority request to the target second remote doctor console, for example, the preset time range is within 3 minutes.

[0471] 906. The patient surgery platform sends the second control authority to the first remote doctor console, and sends the first control authority to the target second remote doctor console.

[0472] 907, the first remote doctor console obtains the second control authority, and the target second remote doctor console obtains the first control authority.

[0473] In some embodiments, the first remote physician console includes a first display screen, and the second remote physician console includes a second display screen. The method may include:

[0474] In response to obtaining the phased changes in the surgical process, the first remote doctor console can generate a control on the display interface of the first display screen, and the control is used to trigger a request to exchange control authority to the patient surgical platform. The phased changes in the surgical process may involve the need for control authority exchange.

[0475] Furthermore, in step 901, the first remote doctor console may send a request for exchange control authority to the patient's surgical platform in response to obtaining that the control is triggered. Of course, if the first remote doctor console does not obtain that the control is triggered, it will not send a request for exchange control authority to the patient's surgical platform and will still operate under the original control authority.

[0476] In some embodiments, the phased change of the surgical procedure includes at least one of the following: a change in the type of target surgical object during the surgical procedure; and a change in the type of target surgical action during the surgical procedure.

[0477] Exemplarily, the target surgical object type includes two types: important target surgical objects and non-important target surgical objects. For example, important target surgical objects include at least one of arteries, heart, liver, spleen, kidney, stomach, lung, and gallbladder. For example, non-important target surgical objects include at least one of veins, fat, large intestine, and small intestine. Generally, different types of target surgical objects can be associated with doctors with different experiences to perform surgery. The type of the target surgical object can be identified and determined by the first remote doctor console on the surgical image transmitted by the patient's surgical platform.

[0478] Exemplarily, the target surgical action type includes two types: important target surgical action and non-important target surgical action. For example, the important target surgical action includes at least one of resection and hemostasis. For example, non-important target surgical action includes at least one of suturing and drainage. Different types of target surgical actions can be associated with doctors with different experiences to perform the operation. Among them, different types of medical instruments are usually used to perform different surgical actions. The type of the target surgical action can be identified and determined by the first remote doctor console on the type of medical instrument currently used and transmitted by the patient's surgical platform.

[0479] Among them, important target surgical objects or important target surgical actions usually require more experienced doctors to perform surgery, while non-important target surgical objects or non-important target surgical actions can usually be performed by doctors with relatively less experience. Therefore, the control authority exchange prompt can be made based on the stage changes of the surgical process, so that doctors can determine whether to exchange control authority according to their needs.

[0480] In other embodiments, it is also possible to directly generate a control on the first display screen without depending on the stage changes of the surgical process, and the control is used for the doctor to trigger the sending of a request for exchange control authority to the patient's surgical platform according to actual needs.

[0481] In some embodiments, in order to ensure that the exchange control authority request issued by the first remote doctor console is reliable, the request can be encapsulated using a custom protocol agreed upon between the first remote doctor console and the patient surgery platform, and the request can be decapsulated on the patient surgery platform side to achieve authentication, which will not be repeated here.

[0482] In some embodiments, a prompt may be generated at the first remote doctor console or the target second remote doctor console based on the situation of the control authority exchange. When the control authority exchange is successful, a prompt is generated at both ends indicating that the authority exchange is successful. When the control authority is maintained, a prompt is generated at both ends indicating that the authority has not been exchanged.

[0483] In some embodiments, the two remote doctor consoles that can exchange control permissions are usually two remote doctor consoles of the same device type, or two remote doctor consoles with the same device functions. In some embodiments, the method may include a function to allow or prohibit any remote doctor console from initiating a request for exchange control permissions based on identifying the device type or device function of the two remote doctor consoles that are paired with the patient's surgical platform in real time. For example, when the device types of the two remote doctor consoles do not match and / or the device functions do not match, the function of any remote doctor console initiating a request for exchange control permissions is prohibited; when the device types of the two remote doctor consoles match or the device functions match, the function of any remote doctor console initiating a request for exchange control permissions is allowed. Based on such results, different configuration interfaces can be provided for the two remote doctor consoles. When allowed, a configuration interface including controls that can trigger a request for exchange control permissions is provided; when prohibited, a configuration interface that does not include controls that can trigger a request for exchange control permissions is provided.

[0484] Among them, when releasing the control authority, the remote doctor console with operator authority disconnects the master-slave control, including disconnecting the master-slave motion control or the master-slave energy control. When disconnecting the master-slave motion control, the manipulator component can be configured to maintain at least one of the current position and posture. When disconnecting the master-slave energy control, the energy platform can be configured to reduce or shut down the energy output to ensure safety.

[0485] In this embodiment, the first remote doctor console and the second remote doctor console can remain paired with the patient's surgical platform without the need to unpair them, and can seamlessly exchange control permissions throughout the entire surgical process, thereby improving the rapid switching of teaching and learning, or drill and guidance modes, and improving surgical efficiency.

[0486] In some embodiments, a first remote doctor console can also establish real-time pairing with multiple patient surgical platforms to watch the surgical procedures of different patient surgical platforms, or to guide the surgical procedures of different patient surgical platforms. However, at the same time, the first remote doctor console can only obtain operator authority to one of the patient surgical platforms at most, and the first remote doctor console can simultaneously watch multiple videos sent by different patient surgical platforms on its display screen. At the same time, these patient surgical platforms can also establish real-time pairing with multiple second remote doctor consoles. Similarly, a second remote doctor console can only obtain operator authority to one patient surgical platform at most. When the first remote doctor console and the second remote doctor console have different control permissions for the same patient surgical platform, such as one with operator authority and the other with observer authority, the two can switch control permissions based on the records of the aforementioned embodiments, which will not be repeated here.

[0487] In the above embodiment, based on the change of the pairing relationship or the change of the control authority, at least one of establishing a network channel at both ends of the pairing, establishing a master-slave mapping relationship, performing pairing success detection, and updating the UI interface can be performed. For the purpose of brevity, the above description can be referred to and will not be repeated here.

[0488] The above-mentioned various devices include a first device, a second device, a server or a portable mobile terminal, which may include a memory and at least one processor. When at least one program stored in the memory is processed by the at least one processor, the at least one processor implements the method described in any one of the above embodiments.

[0489] The present disclosure also provides a computer-readable storage medium, in which instructions are stored, and when the instructions are executed on at least one processor, the steps in the above-mentioned various method embodiments can be implemented. The memory 503 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory. The processor may be a central processing unit CPU, or an application-specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present disclosure, or a graphics processing unit GPU (Graphics Processing Unit). The one or more processors included in the control device may be processors of the same type, such as one or more CPUs, or one or more GPUs; or they may be processors of different types, such as one or more CPUs and one or more GPUs.

[0490] The present disclosure also provides a computer program product. When the computer program product runs on a device, the device can implement the steps in the above-mentioned method embodiments when the computer program product is executed.

[0491] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0492] The above-mentioned embodiments only express several implementation methods of the present disclosure, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present disclosure, and these all belong to the protection scope of the present disclosure. Therefore, the protection scope of the patent of the present disclosure shall be subject to the attached claims.

Claims

1. A method for interconnecting devices, characterized in that: The method is applied to a remote doctor console in a remote surgical robot system, the system comprising a server, the remote doctor console capable of communicating with the server, and a patient surgical platform, the remote doctor console and the patient surgical platform having a pairing relationship, and the method comprising: receiving device network information of the patient surgical platform sent by the server, wherein the device network information includes information of a target network channel expected to be established with the patient surgical platform; Creating a target network channel between the device and the patient surgical platform based on the device network information; evaluating a communication status of the target network channel; Acquire the permissions possessed and permissions not possessed when the remote doctor console is configured as operator permissions; Determine a controlled object from the patient surgery platform based on the first authority attribution having the authority, the first authority attribution being associated with the controlled object in the patient surgery platform; Determine a non-controlled object from the patient surgery platform based on the second authority attribution of the non-owned authority, the second authority attribution being associated with the non-controlled object in the patient surgery platform; Sending control instructions to the patient surgical platform; When detecting that the controlled object responds to the control instruction and the state of the uncontrolled object does not change, determining that the possessed permission and the unpossessed permission are configured successfully; When the communication state of the target network channel obtained based on the evaluation is normal, and the possessed permission and the non-possessed permission are successfully configured, determining that the pairing between the remote doctor console and the patient surgery platform is successful; Based on the different control permissions configured for the remote doctor console or the patient surgery platform, create the target network channel with different communication protocol standards; When the control authority is observer authority, the corresponding target network channel is created based on the UDP protocol; when the control authority is operator authority, for the observer authority included in the operator authority, the corresponding target network channel is created based on the UDP protocol, and for other authorities included in the operator authority, the corresponding target network channel is created based on the TCP protocol.

2. The method according to claim 1, characterized in that The server determines the device network information that needs to be sent based on the acquired control authority configured for the remote doctor console or the patient surgical platform; or, the server determines the device network information that needs to be sent based on the acquired medical and patient information configured for the remote doctor console or the patient surgical platform, and the medical and patient information is associated with at least one of the core devices and auxiliary devices in the remote doctor console and the patient surgical platform that need to establish a connection.

3. The method according to claim 1, characterized in that: The target network channel includes a first target network channel for transmitting high-priority network information and a second target network channel for transmitting low-priority network information.

4. The method according to claim 3, characterized in that: The first target network channel includes a motion control network channel, an energy control network channel, and a video interaction network channel. When it is evaluated that the communication status of the motion control network channel, the energy control network channel, and the video interaction network channel are all normal, it is determined that the pairing with the patient surgical platform is successful; when it is evaluated that the communication status of any one of the motion control network channel, the energy control network channel, and the video interaction network channel is abnormal, it is determined that the pairing with the patient surgical platform has failed.

5. The method according to claim 1, characterized in that The communication status of the target network channel is evaluated by detecting the network connectivity or network communication quality of the target network channel, and the network communication quality is evaluated by at least one of network delay, jitter, packet loss and disorder.

6. The method according to claim 5, characterized in that The method further comprises: When it is determined that the pairing with the patient surgical platform is successful, the use of corresponding control permissions is allowed or prohibited, or the implementation of corresponding surgical procedures is allowed or prohibited according to different network communication qualities of the target network channel.

7. The method according to claim 1, characterized in that The determining that the pairing between the remote doctor console and the patient surgery platform is successful includes: Determine a first target control instruction associated with the controlled object from a preset control instruction set, and send the first target control instruction to the patient surgical platform; Receiving a first actual execution result returned by the controlled object in the patient surgery platform after executing the first target control instruction; Detecting whether the first actual execution result matches a first expected execution result associated with the first target control instruction; When the first actual execution result and the first expected execution result match, it is determined that the ownership permission configuration is successful, and then it is determined that the pairing with the patient surgical platform is successful; or, when the first actual execution result and the first expected execution result do not match, it is determined that the ownership permission configuration has failed, and then it is determined that the pairing with the patient surgical platform has failed.

8. The method according to claim 1, characterized in that: The determining that the pairing between the remote doctor console and the patient surgery platform is successful includes: Determine a second target control instruction associated with the non-controlled object from a preset control instruction set, and send the second target control instruction to the patient surgical platform; receiving a second actual execution result returned by the non-controlled object in the patient surgery platform after executing the second target control instruction; detecting whether the second actual execution result matches a second expected execution result associated with the second target control instruction; When the second actual execution result and the second expected execution result match, it is determined that the non-authorization configuration is successful, and then the pairing with the patient surgical platform is successful; or, when the second actual execution result and the second expected execution result do not match, it is determined that the non-authorization configuration has failed, and then the pairing with the patient surgical platform has failed.

9. A remote surgical robot system, characterized in that: The system includes a server, a remote doctor console that can communicate with the server, and a patient surgery platform, the remote doctor console and the patient surgery platform have a pairing relationship, and the remote doctor console is configured to implement the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on at least one processor, the method according to any one of claims 1 to 8 is implemented.

Images