Patent Description:
Beacon-based systems, methods, and apparatuses for managing communicative pairing of an apparatus (or device) with a medical system will be described herein. The systems and methods described herein may be implemented as part of or in conjunction with a medical system, such as a computer-assisted surgical system. As such, an illustrative computer-assisted surgical system will now be described. The following illustrative computer-assisted surgical system is illustrative and not limiting, as the systems and methods described herein may be implemented as part of or in conjunction with other suitable medical systems.

<FIG> shows an illustrative computer-assisted surgical system <NUM> ("surgical system <NUM>"). As shown, surgical system <NUM> may include a manipulating system <NUM>, a user control system <NUM>, and an auxiliary system <NUM> communicatively coupled one to another. In some examples, surgical system <NUM> may be implemented by one or more of these components. However, surgical system <NUM> is not limited to these components, and may include additional components as may suit a particular implementation, such as but not limited to a patient operating table, third-party components (e.g., electrosurgical units) connected to surgical system <NUM>, and the like.

Surgical system <NUM> may be utilized by a surgical team to perform a computer-assisted surgical procedure on a patient <NUM>. As shown, the surgical team may include a surgeon <NUM>-<NUM>, an assistant <NUM>-<NUM>, a nurse <NUM>-<NUM>, and an anesthesiologist <NUM>-<NUM>, all of whom may be collectively referred to as "surgical team members <NUM>. " Additional or alternative surgical team members may be present during a surgical session as may serve a particular implementation.

While <FIG> illustrates an ongoing minimally invasive surgical procedure, surgical system <NUM> may similarly be used to perform open surgical procedures or other types of surgical procedures that may similarly benefit from the accuracy and convenience of surgical system <NUM>. Additionally, it will be understood that the surgical session throughout which surgical system <NUM> may be employed may not only include an operative phase of a surgical procedure, as is illustrated in <FIG>, but may also include preoperative, postoperative, and/or other suitable phases of the surgical procedure. A surgical procedure may include any procedure in which manual and/or instrumental techniques are used on a patient to investigate, diagnose, and/or treat a physical condition of the patient. Additionally, a surgical procedure may include any non-clinical procedure, e.g., a procedure that is not performed on a live patient, such as a calibration or testing procedure, a training procedure, and an experimental or research procedure.

As shown in <FIG>, manipulating system <NUM> may include a plurality of manipulator arms <NUM> (e.g., manipulator arm <NUM>-<NUM> through <NUM>-<NUM>) to which a plurality of surgical instruments (not shown in <FIG>) may be coupled. Each surgical instrument may be implemented by any suitable therapeutic instrument (e.g., a tool having tissue-interaction functions), imaging device (e.g., an endoscope), diagnostic instrument, or the like that may be used for a computer-assisted surgical procedure (e.g., by being at least partially inserted into patient <NUM> and manipulated to perform a computer-assisted surgical procedure on patient <NUM>). In some examples, one or more of the surgical instruments may include force-sensing and/or other sensing capabilities. While manipulating system <NUM> is depicted and described herein as including four manipulator arms <NUM>, it will be recognized that manipulating system <NUM> may include only a single manipulator arm <NUM> or any other number of manipulator arms as may serve a particular implementation.

Manipulator arms <NUM> and/or surgical instruments attached to manipulator arms <NUM> may include one or more sensors (e.g., displacement transducers, orientational sensors, positional sensors, etc.) used to generate (i.e., uncorrected) kinematics information (hereinafter "surgical system sensors"). Kinematics information may include information such as pose (e.g., position and/or orientation), movement (e.g., velocity, direction, acceleration, etc.), state (e.g., open, closed, stowed, etc.), and/or other attributes of manipulator arms <NUM>, surgical instruments coupled to manipulator arms <NUM>, and/or any other components of manipulating system <NUM> (e.g., boom arms). One or more components of surgical system <NUM> may be configured to use the kinematics information to track (e.g., determine poses, movements, and/or states of) and/or control manipulator arms <NUM> and/or surgical instruments. Manipulating system <NUM> may also include other sensors configured to generate other information as may suit a particular implementation. Such sensors may also be referred to as "surgical system sensors" and may include, for example, draping sensors, boom height sensors, and the like.

Surgical instruments attached to manipulator arms <NUM> may each be positioned at a surgical area associated with a patient. A "surgical area" may, in certain examples, be entirely disposed within a patient and may include an area within the patient at or near where a surgical procedure is planned to be performed, is being performed, or has been performed, For example, for a minimally invasive surgical procedure being performed on tissue internal to a patient, the surgical area may include the tissue, anatomy underlying the tissue, as well as space around the tissue where, for example, surgical instruments being used to perform the surgical procedure are located. In other examples, a surgical area may be at least partially disposed external to the patient at or near where a surgical procedure is planned to be performed, is being performed, or has been performed on the patient. For instance, surgical system <NUM> may be used to perform an open surgical procedure such that part of the surgical area (e.g., tissue being operated on) is internal to the patient while another part of the surgical area (e.g., a space around the tissue where one or more surgical instruments may be disposed) is external to the patient. A surgical instrument may be referred to as being positioned or located at or within a surgical area when at least a portion of the surgical instrument (e.g., a distal portion of the surgical instrument) is located within the surgical area.

User control system <NUM> may be configured to facilitate control by surgeon <NUM>-<NUM> of surgical system <NUM> (e.g., manipulator arms <NUM> and surgical instruments attached to manipulator arms <NUM>). For example, surgeon <NUM>-<NUM> may interact with user input devices included in user control system <NUM> to remotely move or manipulate manipulator arms <NUM> and the surgical instruments coupled to manipulator arms <NUM>. To this end, user control system <NUM> may provide surgeon <NUM>-<NUM> with imagery (e.g., high-definition stereoscopic imagery) of a surgical area associated with patient <NUM> as captured by an imaging device (e.g., a stereoscopic endoscope). Surgeon <NUM>-<NUM> may utilize the imagery to perform one or more procedures with one or more surgical instruments coupled to manipulator arms <NUM>.

To facilitate control of surgical instruments, user control system <NUM> may include a set of master controls (not shown in <FIG>). These master controls may be manipulated by surgeon <NUM>-<NUM> to control movement of surgical instruments (e.g., by utilizing robotic and/or teleoperation technology). The master controls may be configured to detect a wide variety of hand, wrist, and finger movements by surgeon <NUM>-<NUM>. In this manner, surgeon <NUM>-<NUM> may intuitively perform a surgical procedure using one or more surgical instruments.

User control system <NUM> may further be configured to facilitate control by surgeon <NUM>-<NUM> of other components of surgical system <NUM>. For example, surgeon <NUM>-<NUM> may interact with user control system <NUM> to change a configuration or operating mode of surgical system <NUM>, to change a display mode of surgical system <NUM>, to generate additional control signals used to control surgical instruments attached to manipulator arms <NUM>, to facilitate switching control from one surgical instrument to another, or to perform any other suitable operation. To this end, user control system <NUM> may also include one or more additional user input devices (e.g., foot pedals, buttons, switches, touchscreen displays, etc.) configured to receive manual input from surgeon <NUM>-<NUM>. In some examples, user control system <NUM> may also include one or more audio input devices (e.g., microphones) configured to receive audio input (e.g., voice input) from one or more users, and one or more audio output devices (e.g., speakers).

Auxiliary system <NUM> may include one or more computing devices configured to perform primary processing operations of surgical system <NUM>. The one or more computing devices included in auxiliary system <NUM> may control and/or coordinate operations performed by various other components (e.g., manipulating system <NUM> and/or user control system <NUM>) of surgical system <NUM>. For example, a computing device included in user control system <NUM> may transmit instructions to manipulating system <NUM> by way of the one or more computing devices included in auxiliary system <NUM>. As another example, auxiliary system <NUM> may receive from manipulating system <NUM> (e.g., from an imaging device) and process image data representative of imagery captured by an endoscope attached to a manipulator arm <NUM>.

In some examples, auxiliary system <NUM> may be configured to present visual content to surgical team members <NUM> who may not have access to the imagery provided to surgeon <NUM>-<NUM> at user control system <NUM>. To this end, auxiliary system <NUM> may include a display monitor <NUM> configured to display one or more user interfaces, such as images (e.g., 2D images) of the surgical area, information associated with patient <NUM> and/or the surgical procedure, and/or any other visual content as may serve a particular implementation. For example, display monitor <NUM> may display images of the surgical area together with additional content (e.g., graphical content, contextual information, etc.) concurrently displayed with the images. In some embodiments, display monitor <NUM> is implemented by a touchscreen display with which surgical team members <NUM> may interact (e.g., by way of touch gestures) to provide user input to surgical system <NUM>.

While auxiliary system <NUM> is shown in <FIG> as a separate system from manipulating system <NUM> and user control system <NUM>, auxiliary system <NUM> may be included in, or may be distributed across, manipulating system <NUM> and/or user control system <NUM>. Additionally, while user control system <NUM> has been described as including one or more user input devices and/or audio input devices, other components of surgical system <NUM> (e.g., manipulating system <NUM> and/or auxiliary system <NUM>) may include user input devices, audio input devices, and/or audio output devices as may suit a particular implementation.

Manipulating system <NUM>, user control system <NUM>, and auxiliary system <NUM> may be communicatively coupled one to another in any suitable manner. For example, as shown in <FIG>, manipulating system <NUM>, user control system <NUM>, and auxiliary system <NUM> may be communicatively coupled by way of control lines <NUM>, which may represent any optical, wired, or wireless communication link as may serve a particular implementation. To this end, manipulating system <NUM>, user control system <NUM>, and auxiliary system <NUM> may each include one or more optical, wired, or wireless communication interfaces, such as one or more local area network interfaces, Wi-Fi network interfaces, cellular interfaces, etc..

As shown in <FIG>, surgical system <NUM> may also include an accessory cart <NUM>. Accessory cart <NUM> may be configured to carry or store certain accessories of surgical system <NUM> and/or supplies to be used during the surgical procedure. For example, accessory cart <NUM> may hold surgical instruments <NUM> that may be coupled with manipulator arms <NUM> as needed during the surgical procedure.

In alternative embodiments, accessory cart <NUM> is not included in surgical system <NUM> but is a standalone medical system. For example, accessory cart <NUM> may be used to deliver sterilized instruments from a sterile processing department ("SPD") of a hospital to various operating rooms throughout the hospital. Thus, in these embodiments accessory cart <NUM> is not included in surgical system <NUM> but may be a separate medical system.

In some examples, a medical system (e.g., surgical system <NUM>, accessory cart <NUM>, etc.) may be located within a medical facility that uses one or more ultrasonic beacons to facilitate communicative pairing of one or more devices with the medical system and/or to provide contextual information about the medical system, such as information about a medical procedure performed with the medical system, the location of the medical system, errors of the medical system, and the like.

<FIG> shows an illustrative configuration <NUM> of a medical facility <NUM>. As shown, medical facility <NUM> includes a predefined area <NUM> and a medical system <NUM> located within predefined area <NUM>. Medical facility <NUM> may be, for example, a hospital, a unit within a hospital (e.g., an emergency room, a trauma center, a maternity unit, an intensive care unit, etc.), a surgical facility, a deployable field hospital, a medical clinic, a doctor's office, a dentist's office, a nursing home, a hospice facility, a rehab facility, an assisted living facility, or any other similar facility. Predefined area <NUM> may be a particular area (e.g., a particular room) within medical facility <NUM> in which medical system <NUM> is located and/or used to perform one or more tasks or operations with respect to a patient. For example, predefined area <NUM> may be an operating room, a recovery room, a consulting room, a patient room, an examination room, an equipment room, and the like. In some examples, predefined area <NUM> is defined by and/or separated from other areas of medical facility <NUM> (e.g., from an adjoining operating room, from a hallway, from an equipment room, etc.) by one or more physical barriers (e.g., walls, windows, doors, curtains, etc.).

Medical system <NUM> may be implemented by any type of medical system that may be used to monitor, treat, and/or assist a patient located within medical facility <NUM>. For example, medical system <NUM> may be implemented by a surgical system (e.g., a computer-assisted surgical system, such as surgical system <NUM>), an imaging system (e.g., a computed tomography (CT) scanner, a magnetic resonance imaging (MRI) scanner, an X-ray machine, etc.), a dialysis machine, a heart-lung machine, a monitoring device (e.g., a heartrate monitor, a blood pressure monitor, etc.), a ventilator, a patient bed, an accessory cart, and/or the like. In some examples, medical system <NUM> is implemented by a mobile accessory cart (e.g., accessory cart <NUM>) that may move throughout medical facility <NUM>. For example, a mobile accessory cart may be an SPD cart that may be used to deliver sterilized instruments throughout medical facility <NUM> (e.g., to distribute sterilized instruments to various operating rooms).

A user <NUM> and a user device <NUM> associated with user <NUM> (e.g., used by, carried by, operated by, and/or logged into by user <NUM>) may move throughout medical facility <NUM>. As shown in <FIG>, user <NUM> and user device <NUM> are physically located within predefined area <NUM>. User device <NUM> is representative of any type of device (also referred to herein as an "apparatus") that may communicate, directly or indirectly, with medical system <NUM>, such as an auxiliary device, a component of medical system <NUM> (e.g., manipulating system <NUM>, user control system <NUM>, auxiliary system <NUM>, etc.), an accessory cart, and any other suitable device. An auxiliary device may include any device that is not part of medical system <NUM>, such as a user device, another medical device or medical system, an SPD cart, and/or any other suitable device. A user device (e.g., user device <NUM>) may be any device capable of presenting information to a user, whether in visual, audio, or haptic format, and/or receiving user input from the user. For example, a user device may be implemented by a mobile device (e.g., a mobile phone, a handheld device, a tablet computing device, a laptop computer, a personal computer, etc.), an audio device (e.g., a speaker, earphones, etc.), a wearable device (e.g., a smartwatch device, an activity tracker, a head-mounted display device, a virtual or augmented reality device, etc.), and/or a display device (e.g., a television, a projector, a monitor, a touch screen display device, etc.).

Medical system <NUM> may be configured to communicatively pair with user device <NUM> when user device <NUM> is in proximity to medical system <NUM>. For example, as shown in <FIG>, user <NUM> (e.g., a surgical team member <NUM>) located within medical facility <NUM> may gain access, by way of user device <NUM>, to one or more functional features (e.g., an endoscopic video feed, a settings menu, medical system controls, etc.) associated with medical system <NUM> when user device <NUM> is communicatively paired with medical system <NUM>. For instance, user <NUM> may, by way of an application executed by user device <NUM>, view content associated with medical system <NUM>, interact with medical system <NUM>, and/or communicate with other users via additional user devices that are communicatively paired with medical system <NUM>. Even when user device <NUM> is not communicatively paired with medical system <NUM>, user <NUM> may have access to other functional features associated with medical facility <NUM>. For example, user <NUM> may, by way of an application executed by user device <NUM>, view and/or edit medical personnel information, update user profile information, view training content, schedule tasks, schedule medical procedures, view patient information, and the like.

To facilitate communicative pairing of user device <NUM> with medical system <NUM>, a beacon generator <NUM> (e.g., an ultrasonic transducer) is located within predefined area <NUM> and configured to generate and emit an ultrasonic beacon <NUM> that is associated with medical system <NUM>. Ultrasonic beacon <NUM> comprises sound waves generally having a frequency above the human audible hearing range (e.g., above about <NUM> or above <NUM>). In some examples, ultrasonic beacon <NUM> has a frequency between about <NUM> and about <NUM>.

Ultrasonic beacon <NUM> may include repeated transmissions of a particular message. For each transmission of ultrasonic beacon <NUM>, beacon generator <NUM> may include (e.g., encode) the message in ultrasonic beacon <NUM> by modulating one or more of the amplitude, frequency, and waveform of ultrasonic signals, such as by using phase-shift keying (PSK), binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), amplitude-shift keying (ASK), frequency shift keying (FSK), on-off keying (OOK), quadrature amplitude modulation (QAM), an audio QR code format, by multi-frequency bit-coding, or any other suitable modulation technique.

The message included (e.g., encoded) in ultrasonic beacon <NUM> may include information (e.g., contextual information and/or identification information) associated with medical system <NUM>. In some examples, the message information encoded in ultrasonic beacon <NUM> associates, or may be used to associate, ultrasonic beacon <NUM> with medical system <NUM>. For example, ultrasonic beacon <NUM> may include a location identifier that identifies the predefined area (i.e., predefined area <NUM>) in which ultrasonic beacon <NUM> is located. The location identifier may be, for example, a unique identification ("ID") number (e.g., a room number) assigned to or otherwise representative of predefined area <NUM>. As another example, ultrasonic beacon <NUM> may include a medical system identifier (e.g., a surgical system identifier) that identifies the medical system (i.e., medical system <NUM>) with which ultrasonic beacon <NUM> is associated. The medical system identifier may be, for example, a unique medical system ID assigned to or otherwise representative of medical system <NUM>. Additionally or alternatively, the medical system identifier may be a network address for the medical system. As yet another example, ultrasonic beacon <NUM> may include a beacon generator identifier that identifies the particular beacon generator (i.e., beacon generator <NUM>) that emits ultrasonic beacon <NUM>. The beacon generator identifier may be a beacon generator ID assigned to or otherwise representative of beacon generator <NUM>. As a further example, ultrasonic beacon <NUM> may include a medical session identifier that identifies a particular medical session with which ultrasonic beacon <NUM> is associated. The medical session identifier may be a medical session ID assigned to or otherwise representative of a particular medical session (e.g., a patient ID, medical team personnel IDs, a surgeon ID, a room ID, a surgical session ID, etc.). In some examples, the identification information may comprise a combination of letters and numbers (e.g., a <NUM>-digit number). It will be recognized that the foregoing information that may be included in ultrasonic beacon <NUM> is merely illustrative and not limiting, as ultrasonic beacon <NUM> may include any other suitable information (e.g., GPS coordinates, error information, status information, security information, authentication information, etc.).

Each transmission of ultrasonic beacon <NUM> may include an information signal in which the message is encoded and a pilot signal, which may be used for synchronization of transmissions of ultrasonic beacon <NUM> and decoding the encoded message. The pilot signal may also help characterize the transmission and may carry some preamble information that may be used in decoding the information signal. In some examples, such as when the information included in ultrasonic beacon <NUM> has a small bit size, ultrasonic beacon <NUM> is transmitted over a single channel (e.g., in a single carrier communication scheme). In other examples, such as when the information included in ultrasonic beacon <NUM> has a relatively large bit-size (e.g., <NUM> bits, <NUM> bits, etc.), ultrasonic beacon <NUM> may be transmitted over multiple subchannels in a multi-carrier communication scheme (e.g., frequency division multiplexing (FDM) or orthogonal frequency division multiplexing modulation (OFDM)).

<FIG> shows an illustrative configuration <NUM> of a communication scheme for an ultrasonic beacon <NUM> ("beacon <NUM>"). While <FIG> shows a multi-channel communication scheme, in other embodiments the communication scheme may be a single-channel communication scheme. <FIG> shows a first transmission <NUM>-<NUM> of beacon <NUM> and a second transmission <NUM>-<NUM> of beacon <NUM>. Second transmission <NUM>-<NUM> is subsequent to first transmission <NUM>-<NUM>. For ease of discussion <FIG> shows two transmissions, but beacon <NUM> may have any other suitable number of transmissions. Transmissions <NUM> may be repeated continuously until beacon <NUM> is terminated (e.g., beacon generator <NUM> is turned off). For example, a third transmission identical to first transmission <NUM>-<NUM> may follow second transmission <NUM>-<NUM>, a fourth transmission identical to second transmission <NUM>-<NUM> may follow the third transmission, and so on. Beacon <NUM> may be transmitted with any suitable frequency (e.g., time between successive pilot signals <NUM>), such as <NUM>, <NUM>, <NUM>, etc..

Transmissions <NUM>-<NUM> and <NUM>-<NUM> of beacon <NUM> include a pilot signal <NUM>-<NUM> and a pilot signal <NUM>-<NUM>, respectively, and an information signal <NUM>-<NUM> and an information signal <NUM>-<NUM>, respectively. Pilot signals <NUM> and information signals <NUM> are transmitted on a plurality of subchannels <NUM> (e.g., subchannels <NUM>-<NUM> to <NUM>-<NUM>). For ease of discussion <FIG> shows that beacon <NUM> is transmitted on eight different subchannels <NUM>, but beacon <NUM> may be transmitted on any other number of subchannels as may serve a particular implementation (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.) or on a single channel in a single-channel communication scheme, Subchannels <NUM> may be within the ultrasonic range. In some examples, the bandwidth of the plurality of subchannels <NUM> is within about <NUM> to about <NUM>. However, the plurality of subchannels <NUM> may have any other suitable range as may serve a particular implementation.

In some examples, pilot signals <NUM> and information signals <NUM> are encoded in accordance with OOK. Accordingly, each bit is represented by the transmission of a particular frequency for a set period of time or the absence of transmission of a particular frequency for a set period of time. In alternative examples, pilot signals <NUM> and information signals <NUM> may be encoded with any other suitable encoding scheme, such as PSK, FSK, QAM, etc..

Pilot signals <NUM> are configured to provide information for synchronization of transmissions <NUM>. Pilot signals <NUM> may also contain other information that may be used for decoding information signals <NUM>. As shown in <FIG>, each pilot signal <NUM> includes a first set of signals <NUM>-<NUM> ("first set <NUM>-<NUM>") transmitted on subchannels <NUM> followed by a second set of signals <NUM>-<NUM> ("second set <NUM>-<NUM>") transmitted on subchannels <NUM>. Second set <NUM>-<NUM> is the inverse of first set <NUM>-<NUM> (e.g., a subchannel that transmits an ON signal (represented by a white box) in first set <NUM>-<NUM> transmits an OFF signal (represented by a black box) in second set <NUM>-<NUM>, and vice versa). As a result, the switch from first set <NUM>-<NUM> to second set <NUM>-<NUM> produces a strong edge that is easily detectable. This sharp edge, when detected by a device (e.g., user device <NUM>), indicates the start of each transmission <NUM> and thus facilitates synchronization of transmissions <NUM>. While pilot signals <NUM> are shown and described as having two sets <NUM> of signals, pilot signals <NUM> may have more or fewer sets of signals. In some examples, each pilot signal <NUM> may comprise a more compact signal for providing synchronization information and any other desired information.

First set <NUM>-<NUM> and second set <NUM>-<NUM> may have any suitable signal pattern as may serve a particular implementation. As shown in <FIG>, first set <NUM>-<NUM> and second set <NUM>-<NUM> each comprise an alternating pattern of ON/OFF signals. However, sets <NUM> are not limited to this configuration, and may have any other suitable configurations. In some examples, first set <NUM>-<NUM> and second set <NUM>-<NUM> may have a unique pattern configured to convey other information, such as a permutation order, as will be explained below in more detail.

Information signals <NUM> are configured to transmit message information such as identification information. In some examples, the message information encoded in information signals <NUM> may be divided into multiple subparts, and each subpart may include one or more bits. For ease of discussion, <FIG> shows that each information signal <NUM> is divided into eight message subparts denoted A through H, and each message subpart is transmitted in a single subchannel in four successive ON or OFF signals. For example, message subpart A of first transmission <NUM>-<NUM> is transmitted on subchannel <NUM>-<NUM> as signal A1, followed by signal A2, followed by signal A3, followed by signal A4. Message subparts B through H are transmitted on subchannels <NUM>-<NUM> to <NUM>-<NUM>, respectively, in a similar manner. It will be recognized that each information signal <NUM> may be divided into any suitable number of subparts (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.), and each message subpart may be transmitted as any one or more number of signals as may serve a particular implementation.

In some examples, the beacon generator permutes the message subparts that are transmitted on subchannels <NUM> for each successive transmission <NUM> of beacon <NUM>. The beacon generator may permute the message subparts in any suitable way. In some examples, the message subparts are shifted on subchannels <NUM> by one-half (<NUM>/<NUM>) of the total bandwidth of the spectrum of subchannels <NUM>. For example, as shown in <FIG> message subpart A is transmitted on subchannel <NUM>-<NUM> in first transmission <NUM>-<NUM> and is shifted to subchannel <NUM>-<NUM> in second transmission <NUM>-<NUM>. Similarly, message subparts B, C, and D are shifted from subchannels <NUM>, <NUM>, and <NUM> in first transmission <NUM>-<NUM> to subchannels <NUM>, <NUM>, and <NUM> in second transmission <NUM>-<NUM>, respectively. Message subparts E to H are shifted from subchannels <NUM> to <NUM> in first transmission <NUM>-<NUM> to subchannels <NUM>-<NUM> in second transmission <NUM>-<NUM>, respectively. First and second transmissions <NUM> may then be repeated indefinitely or until terminated.

When a device (e.g., user device <NUM>) detects first transmission <NUM>-<NUM> (e.g., detects pilot signal <NUM>-<NUM>), the device uses pilot signal <NUM>-<NUM> to decode information signal <NUM>-<NUM> by assembling each message subpart (e.g., signals A1 to A4), and then assembling message subparts A to H to reconstruct the complete message information. In this way, the multi-channel communication scheme shown in <FIG> may transmit, by beacon <NUM>, multi-digit information (e.g., a <NUM>-digit number represented by <NUM> bits, a <NUM>-digit number represented by <NUM> bits, etc.) and/or any other suitable information in a relatively short amount of time. Systems and methods for using pilot signals in transmitting and decoding ultrasonic beacons are described in more detail in International Patent Application No. <CIT>.

While <FIG> shows that transmissions <NUM> of beacon <NUM> include pilot signals <NUM> directly preceding information signals <NUM> in the same channels, transmissions <NUM> are not limited to this configuration. In other configurations, transmissions <NUM> may include pilot signals <NUM> and information signals <NUM> transmitted on different channels. In some examples, the pilot signals <NUM> and information signals <NUM> may be transmitted simultaneously or alternatingly in a predetermined pattern.

Referring again to <FIG>, user device <NUM> may detect ultrasonic beacon <NUM> (or beacon <NUM>) in any suitable way. For example, user device <NUM> may include an ultrasonic sensor (e.g., a microphone) configured to detect ambient sound waves, including ultrasonic beacon <NUM> or beacon <NUM>, and process the detected ambient sound waves to generate audio signals representative of the detected ambient sound waves. In some examples, an application executed by user device <NUM> may process the audio signals to filter out audio signals that do not meet a predefined set of criteria (e.g., audio signals that are not in the ultrasonic range, do not fall within a predefined amplitude range, etc.). The ultrasonic sensor may also be set, either automatically by the application or manually by a user, to an "always-on" state. In this way, user device <NUM> may continually monitor for ultrasonic beacon transmissions while user device <NUM> is located within medical facility.

User device <NUM> is configured to detect (e.g., via an ultrasonic sensor, such as a microphone, etc.) ultrasonic beacon <NUM> when user device <NUM> is in proximity to beacon generator <NUM>. In some examples, ultrasonic beacon <NUM> is configured to not transmit through solid barriers (e.g., walls) and/or is configured to be confined within predefined area <NUM>. Accordingly, user device <NUM> may detect ultrasonic beacon <NUM> only when user device <NUM> is located within the same predefined area (e.g., operating room) as beacon generator <NUM>, as shown in <FIG>. When user device <NUM> is not located within predefined area <NUM>, user device <NUM> does not detect ultrasonic beacon <NUM>. Examples of user device <NUM> detecting ultrasonic beacon <NUM> will be described below in more detail.

As shown in <FIG>, beacon generator <NUM> is a standalone device separate from medical system <NUM> (e.g., beacon generator <NUM> is not physically integrated with or controlled by medical system <NUM>), As a standalone device beacon generator <NUM> may be fixedly positioned at any suitable location within predefined area <NUM>, such as on a wall or ceiling of predefined area <NUM>. Alternatively, beacon generator <NUM> may be a movable standalone device that may be moved and positioned as desired within predefined area <NUM> and/or within medical facility <NUM>.

Alternatively to a standalone device separate from medical system <NUM>, beacon generator <NUM> may be included in medical system <NUM>, as shown in <FIG> shows another illustrative configuration <NUM> of medical facility <NUM>. <FIG> is similar to <FIG> except that in <FIG> beacon generator <NUM> is included in medical system <NUM>. Beacon generator <NUM> may be included in medical system <NUM> in any suitable way. For example, beacon generator <NUM> may be physically integrated with medical system <NUM> (e.g., mounted on a column of manipulating system <NUM>, included in user control system <NUM>, etc.). Thus, if medical system <NUM> is moved to a different area of medical facility <NUM>, beacon generator <NUM> also moves to the new area. Additionally or alternatively, beacon generator <NUM> may be controlled by medical system <NUM>. For example, medical system <NUM> (e.g., auxiliary system <NUM> of surgical system <NUM>) may configure ultrasonic beacon <NUM> to include information and may control the emission of ultrasonic beacon <NUM> by beacon generator <NUM>.

The illustrative configurations <NUM> and <NUM> of medical facility <NUM> described above include a single beacon generator <NUM> located within predefined area <NUM>. However, multiple beacon generators <NUM> may be located within predefined area <NUM>, as illustrated in <FIG> shows another illustrative configuration <NUM> of medical facility <NUM>. <FIG> is similar to <FIG> except that in <FIG> predefined area <NUM> includes three beacon generators <NUM> (e.g., beacon generators <NUM>-<NUM> through <NUM>-<NUM>) configured to emit ultrasonic beacons <NUM> (e.g., ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>) associated with medical system <NUM>. It will be recognized, however, that predefined area <NUM> may include any other number of beacon generators <NUM> as may suit a particular implementation.

Ultrasonic beacons <NUM> may each include information (e.g., information encoded in an information signal of ultrasonic beacon <NUM>) that may be used by a device pairing system to identify a particular medical system (i.e., medical system <NUM>) that is associated with ultrasonic beacons <NUM> and/or to control communicative pairing of user device <NUM> with medical system <NUM>. In some examples, ultrasonic beacons <NUM> each include the same information (e.g., the same location ID). In additional or alternative examples, each ultrasonic beacon <NUM> includes unique identification information. For example, ultrasonic beacon <NUM>-<NUM> may include a surgical system identifier, ultrasonic beacon <NUM>-<NUM> may include a location identifier, and ultrasonic beacon <NUM>-<NUM> may include a patient identifier. In some examples, one or more beacon generators <NUM> (or components or devices connected to or associated with beacon generators <NUM>) may be configured to listen for and detect ultrasonic beacons <NUM> emitted by the other beacon generators <NUM> located within predefined area <NUM> and use the detected ultrasonic beacons <NUM> to coordinate transmission of ultrasonic beacons <NUM> so as to avoid or minimize interference.

In some examples, multiple beacon generators <NUM> may be included in medical system <NUM>, as shown in <FIG> shows another illustrative configuration <NUM> of medical facility <NUM>. <FIG> is similar to <FIG> except that beacon generators <NUM> (e.g., beacon generators <NUM>-<NUM> through <NUM>-<NUM>) are included in medical system <NUM>. Beacon generators <NUM> may be included in medical system <NUM> in any suitable way. For example, beacon generators <NUM> may be physically integrated with and/or controlled by medical system <NUM>, as explained above. In some examples, each beacon generator <NUM> is included in a different component of medical system <NUM>. For instance, if medical system <NUM> is implemented by surgical system <NUM>, beacon generator <NUM>-<NUM> may be included in manipulating system <NUM>, beacon generator <NUM>-<NUM> may be included in user control system <NUM>, and beacon generator <NUM>-<NUM> may be included in auxiliary system <NUM>.

In some examples, ultrasonic beacons <NUM> include the same information (e.g., the same medical system ID). In additional or alternative examples, each ultrasonic beacon <NUM> includes unique information. For example, when medical system <NUM> includes multiple components, various components may each include a beacon generator <NUM> and each ultrasonic beacon <NUM> may include a unique component identifier (e.g., a component ID) assigned to or otherwise representative of the particular component in which the beacon generator <NUM> is included. For instance, referring again to the example in which medical system <NUM> is implemented by surgical system <NUM>, ultrasonic beacon <NUM>-<NUM> may include a unique component ID for manipulating system <NUM>, ultrasonic beacon <NUM>-<NUM> may include a unique component ID for user control system <NUM>, and ultrasonic beacon <NUM>-<NUM> may include a unique component ID for auxiliary system <NUM>.

In some configurations, medical facility <NUM> may also include additional beacon generators (not shown in <FIG> and <FIG>) in areas outside of predefined area <NUM>, as illustrated in <FIG> shows another illustrative configuration <NUM> of medical facility <NUM>. <FIG> is similar to <FIG> except that in <FIG> medical facility <NUM> includes an additional predefined area <NUM> (e.g., another operating room, a hallway, an equipment room, etc.) adjoining predefined area <NUM>, an additional medical system <NUM> located in predefined area <NUM>, and additional beacon generators <NUM> (e.g., beacon generators <NUM>-<NUM> through <NUM>-<NUM>) located within predefined area <NUM> and that emit ultrasonic beacons <NUM> (e.g., ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>) associated with additional medical system <NUM>. It will be recognized that any of beacon generators <NUM>-<NUM> through <NUM>-<NUM> may alternatively be included in medical system <NUM>, and any of beacon generators <NUM>-<NUM> through <NUM>-<NUM> may alternatively be included in medical system <NUM>, in the manner described above with reference to <FIG>. Additionally, predefined areas <NUM> and <NUM> may each include any other number of beacon generators <NUM> and <NUM>, respectively, as may suit a particular implementation. In some examples, predefined area <NUM> does not include a medical system but may nevertheless include one or more beacon generators <NUM>. For example, predefined area <NUM> may be a hallway, a break room, an office, or any other location.

It will be recognized that the foregoing configurations of medical facility <NUM> are merely illustrative and not limiting, as medical facility <NUM> may include any number and configuration of predefined areas, medical systems, and beacon generators as may suit a particular implementation. Moreover, any of the configurations described herein may be modified or combined as may suit a particular implementation.

As mentioned, ultrasonic beacons <NUM> may include information that may be used by a device pairing system to facilitate and/or manage communicative pairing of a device (e.g., user device <NUM>) with a medical system (e.g., medical system <NUM>). <FIG> shows an illustrative device pairing system <NUM> ("pairing system <NUM>") that may be configured to communicatively pair a device with a medical system and manage (e.g., control, configure, change, set parameters for etc.) a pairing state of the device. Pairing system <NUM> may be included in, implemented by, or connected to any medical systems, devices, or other computing systems described herein. For example, pairing system <NUM> may be implemented by a computer-assisted surgical system (e.g., surgical system <NUM>). As another example, pairing system <NUM> may be implemented by a standalone computing system communicatively coupled to a medical system. In some examples, pairing system <NUM> may be implemented, in whole or in part, by a device (e.g., user device <NUM>).

As shown in <FIG>, pairing system <NUM> includes, without limitation, a memory <NUM> and a processing unit <NUM> selectively and communicatively coupled to one another. Memory <NUM> and processing unit <NUM> may each include or be implemented by hardware and/or software components (e.g., processors, memories, communication interfaces, instructions stored in memory for execution by the processors, etc.). For example, memory <NUM> and processing unit <NUM> may be implemented by any component in a medical system. In some examples, memory <NUM> and processing unit <NUM> may be distributed between multiple devices and/or multiple locations as may serve a particular implementation.

Memory <NUM> may maintain (e.g., store) executable data used by processing unit <NUM> to perform any of the operations described herein. For example, memory <NUM> may store instructions <NUM> that may be executed by processing unit <NUM> to perform any of the operations described herein. Instructions <NUM> may be implemented by any suitable application, software, code, and/or other executable data instance, Memory <NUM> may also maintain any data received, generated, managed, used, and/or transmitted by processing unit <NUM>.

Processing unit <NUM> may be configured to perform (e.g., execute instructions <NUM> stored in memory <NUM> to perform) various operations associated with pairing a device with a medical system and managing a pairing state of the device with respect to the medical system and/or additional medical systems. Operations that may be performed by processing unit <NUM> are described herein. In the description that follows, any references to operations performed by pairing system <NUM> may be understood to be performed by processing unit <NUM> of pairing system <NUM>.

As mentioned, pairing system <NUM> may be implemented entirely by the medical system itself. For example, pairing system <NUM> may be implemented by one or more computing devices included in medical system <NUM> (e.g., in one or more computing devices included within manipulating system <NUM>, user control system <NUM>, and/or auxiliary system <NUM> of surgical system <NUM>).

<FIG> shows another illustrative implementation <NUM> of pairing system <NUM>. In implementation <NUM>, a remote computing system <NUM> may be communicatively coupled to medical system <NUM> by way of a network <NUM>. Remote computing system <NUM> may include one or more computing devices (e.g., servers) configured to perform any of the operations described herein. Network <NUM> may be a local area network, a wireless network (e.g., Wi-Fi), a wide area network, the Internet, a cellular data network, and/or any other suitable network. Data may flow between components connected to network <NUM> using any communication technologies, devices, media, and protocols as may serve a particular implementation. As shown, user device <NUM> may be connected to network <NUM> and thereby communicate with remote computing system <NUM>.

In some examples, remote computing system <NUM> and/or network <NUM> are located partly or entirely within a medical facility (e.g., medical facility <NUM>) as part of a medical facility management system (not shown). A medical facility management system may include one or more computing systems configured to generate and/or maintain medical facility data associated with the medical facility and its operations, such as data representative of medical systems included in the medical facility and locations of the medical systems, patient information, beacon generator information and locations of the beacon generators, medical session information, medical personnel information, schedule information, and the like.

In some examples, pairing system <NUM> is entirely implemented by remote computing system <NUM> or user device <NUM>. In alternative examples, pairing system <NUM> is distributed across any two or more of remote computing system <NUM>, medical system <NUM>, and user device <NUM>.

Pairing system <NUM> is configured to manage a pairing state of user device <NUM> with respect to one or more medical systems. A "pairing state" of user device <NUM> may include, without limitation, a "paired state," a "limited paired state," and an "unpaired state," as will now be described.

While operating in a "paired state," user device <NUM> is communicatively paired with medical system <NUM> and configured to exchange data with medical system <NUM>, thereby enabling user <NUM> to access, by way of user device <NUM>, one or more functional features associated with medical system <NUM>. For example, the user may, by way of the device, view content (e.g., an endoscopic video stream, patient information, surgical team information, etc.) associated with the medical system, interact with the medical system (e.g., control one or more features or settings of the medical system), view information (e.g., patient information, surgical team information, etc.) about a medical procedure being performed with the medical system (e.g., a surgical session performed with surgical system <NUM>), and/or communicate with other users by way of additional user devices that are communicatively paired with the medical system. As another example, a user control system for a proctor surgeon may, upon successful pairing with manipulating system <NUM>, be configured to control and interact with a manipulating system <NUM> that is primarily controlled by a primary user control system <NUM>.

User device <NUM> may be communicatively paired with medical system <NUM> in any suitable way. For example, user device <NUM> may be communicatively paired with medical system <NUM> by way of an indirect communication link (e.g., by way of remote computing system <NUM> and/or network <NUM>). Alternatively, user device <NUM> may be communicatively paired with medical system <NUM> by way of a direct (e.g., peer-to-peer, single hop, or ad hoc) communication link <NUM>. The direct communication link may include, for example, a direct wireless connection, such as a Bluetooth connection, a near field communication connection, a Wi-Fi connection, a Wi-Fi Direct connection, a smartphone ad hoc network (SPAN) connection, a mobile device ad hoc network (MANET) connection, etc. In some examples, user device <NUM> may be communicatively paired with medical system <NUM> only when user device <NUM> is physically proximate to medical system <NUM>, such as when user device <NUM> detects an ultrasonic beacon associated with medical system <NUM> (e.g., ultrasonic beacon <NUM>). It will be recognized, however, that in some examples, user device <NUM> is not communicatively paired with medical system <NUM>. Communicative pairing of user device <NUM> with medical system <NUM> will be described below in more detail.

In an "unpaired" or "not paired" state, user device <NUM> is not communicatively paired with medical system <NUM>, is not configured to exchange data with medical system <NUM>, and/or does not enable user <NUM> to access, by way of user device <NUM>, any functional features associated with medical system <NUM>,.

User device <NUM> may also operate in one or more other intermediate pairing states, such as a "limited paired state. " In a limited paired state, one or more functional features provided by the device are different (e.g., modified, prohibited, locked, temporarily suspended, conditioned, etc.) than when user device <NUM> is operating in a paired state. For instance, a proctor surgeon may be able to control operations of surgical system <NUM> by way of user device <NUM> while user device <NUM> is operating in a paired state. If the proctor surgeon leaves the operating room, user device <NUM> may transition to operate in a limited paired state in which the proctor surgeon may continue to view an endoscopic video feed by way of user device <NUM> but is not able to control operations of surgical system <NUM> by way of user device <NUM>.

In some examples, pairing system <NUM> may transition a device from operating in a limited paired state to operating in a paired state based on user input. For example, while user device <NUM> is operating in a limited paired state, the user <NUM> may provide user input via an application executed by the user device <NUM> directing the user device <NUM> to transition to operating in a paired state. In some examples, pairing system <NUM> may require evidence that the user is in proximity to the medical system prior to transitioning the device to operating in the paired state, such as by scanning a QR code or bar code associated with the medical system, capturing an image of the medical system, etc..

Various operations that may be performed by pairing system <NUM> (e.g., by processing unit <NUM> of pairing system <NUM>), and examples of these operations, will now be described. It will be recognized that the operations and examples described herein are merely illustrative of the many different types of operations that may be performed by pairing system <NUM>.

In some examples, pairing system <NUM> may determine that a device (e.g., user device <NUM>) detects an ultrasonic beacon transmission (e.g., first transmission <NUM>-<NUM>) that includes a pilot signal and an encoded information signal. Based on the pilot signal, pairing system <NUM> may decode the encoded information signal to identify a medical system associated with the ultrasonic beacon transmission. In response to identifying the medical system, pairing system <NUM> may direct the device to enter into a pairing state in which the device is communicatively paired with the medical system. In this way, a user of the device may interact with medical system by way of the device while it is paired with the medical system. For instance, user <NUM> may access, by way of user device <NUM>, one or more functional features associated with medical system <NUM>.

However, establishing and maintaining a communicative pairing state between a device and a medical system in a medical facility is often not a simple process. A medical facility is a busy and complex environment. For example, a medical facility may include many different medical systems and many different ultrasonic beacons (see, e.g., <FIG>). Additionally, various ultrasonic beacons may come and go as medical systems move throughout the medical facility and turn on or turn off, and as different medical procedures start or stop. The user of the device may also move with the device throughout the medical facility. For example, a technician may move back and forth between two or more operating rooms during two concurrent medical procedures. As a result of these variable conditions, the device might detect multiple ultrasonic beacons at the same time, and the ultrasonic beacons that are detected by the device might change. These conditions may result in unwanted changes of the pairing state of the device.

To further complicate management of the pairing state of the device, movement of the device (even slow movement on the order of <NUM> meter/second) may result in a Doppler shift of the information signal included in ultrasonic beacon transmissions. This may occur, for example, when a user is moving around in an operating room or within the medical facility, or when a beacon generator is moving. In OFDM, where the subcarriers are densely packed, the Doppler shift can make the message unrecoverable. Motion also creates problems related to the changing delays and path lengths during transmission. These issues are particularly severe because of the slow speed of sound relative to motion, short wavelengths, limited near-ultrasonic bandwidth, and challenging acoustic environment in an operating room. The Doppler shift may thus prevent or affect pairing of the device with a medical system.

To address these issues, pairing system <NUM> is configured to infer an intended pairing state of the device quickly and efficiently and with as little interruption to the user as possible. Accordingly, pairing system <NUM> may infer the intended pairing state of the device based on various inputs such as a current pairing state of the device, information obtained from detected ultrasonic beacon transmissions (e.g., pilot signals and/or information signals), information about motion of the device, user input, and/or any other suitable information (e.g., user preferences, user histories, predictive information, etc.). Pairing system <NUM> may use these inputs to determine whether and how the device will transition between different pairing states.

Ultrasonic beacon-based methods for establishing and managing a pairing state of a device will now be described with reference to <FIG> shows an illustrative method <NUM>. While <FIG> shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, combine, and/or modify any of the steps shown in <FIG>. While the operations shown in <FIG> are described as being performed by pairing system <NUM>, it will be understood that the operations may be performed by any components included in pairing system <NUM> and/or any implementation thereof (e.g., a device such as user device <NUM>, a medical system, a component of a medical system, a combination of devices, a remote computing system, etc.). Method <NUM> may begin, for example, when a device is turned on, when the device initiates execution of a particular application, when a user logs into the application executed by the device, when an ultrasonic sensor on the device is turned on, when the device connects to a particular network (e.g., a medical facility network), when the device moves into a particular geographic location (e.g., based on GPS or other location tracking methods), in accordance with a defined schedule, and/or any other suitable event or time.

In operation <NUM>, pairing system <NUM> (e.g., by way of an ultrasonic sensor included in the device) monitors for ultrasonic beacon transmissions. Operation <NUM> may be performed in any suitable way, including in any way described herein.

In operation <NUM>, pairing system <NUM> determines whether the device detects a pilot signal included in an ultrasonic beacon transmission. If pairing system <NUM> determines that the device does not detect a pilot signal, processing proceeds to operation <NUM>.

In operation <NUM>, pairing system <NUM> checks the current pairing state of the device. If pairing system <NUM> determines that the device is not paired with any medical system, processing returns to operation <NUM> to monitor for ultrasonic beacon transmissions. On the other hand, if pairing system <NUM> determines that the device is paired (e.g., in a paired state or a limited paired state) with a medical system when the device does not detect any pilot signal, processing proceeds to operation <NUM> and transitions the device to operate in a new pairing state for the device (e.g., an unpaired state, a limited paired state, etc.). Operation <NUM> will be described below in more detail. Processing then returns to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions.

Returning again to operation <NUM>, if pairing system <NUM> determines that the device detects a pilot signal in an ultrasonic beacon transmission, processing proceeds to operation <NUM>.

In operation <NUM>, pairing system determines a current pairing state of the device. If pairing system <NUM> determines that the device is not paired with any medical system, processing proceeds to operation <NUM>.

In operation <NUM>, pairing system <NUM> decodes, based on the detected pilot signal, an encoded information signal included in the detected ultrasonic beacon transmission to identify information included in the encoded information signal (e.g., a medical system associated with the ultrasonic beacon transmission). Operation <NUM> may be performed in any suitable way, including any way described herein.

In some examples, pairing system <NUM> may identify a medical system associated with the ultrasonic beacon by comparing the decoded information in the ultrasonic beacon with medical facility data. The medical facility data may take the form of one or more tables or other data structures that associate various attributes of a medical facility, such as predefined areas within the medical facility, medical systems located within the predefined areas of the medical facility, beacon generators located within the predefined areas of the medical facility, and medical sessions being performed within the medical facility and/or with the medical systems. In some examples, pairing system <NUM> may be configured to access the medical facility data from a medical facility management system. Alternatively, the medical facility data may be tracked, generated, and/or maintained by pairing system <NUM> and/or the device.

In some examples, pairing system <NUM> may identify a medical system that is physically located within the same predefined area as the beacon generator that emitted the ultrasonic beacon. For instance, pairing system <NUM> may identify, based on medical facility data, a medical system ID that is directly or indirectly associated with a location ID included in the ultrasonic beacon. As another example, pairing system <NUM> may identify a medical system that is being used to perform a medical session that is represented by a medical session identifier included in the ultrasonic beacon. For instance, pairing system <NUM> may identify, based on medical facility data, a medical system ID that is directly or indirectly associated with a surgical session ID included in the ultrasonic beacon. As yet another example, pairing system <NUM> may identify a medical system associated with the beacon generator that emitted the ultrasonic beacon. For instance, pairing system <NUM> may identify, based on medical facility data, a medical system ID that is directly or indirectly associated with a beacon generator ID included in the ultrasonic beacon. In some examples, pairing system <NUM> may identify a medical system associated with the ultrasonic beacon by identifying a medical system ID included in the ultrasonic beacon. For example, the beacon generator may be configured to include the medical system ID in the ultrasonic beacon when the medical system and the beacon generator are permanently located within a predefined area, or when the beacon generator is included in the medical system.

After pairing system <NUM> decodes the encoded information signal to identify the medical system associated with the ultrasonic beacon transmission, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> sets a new pairing state based on the identified medical system. For example, pairing system <NUM> may cause the device to enter into a paired state with the medical system.

In some embodiments, pairing of the device with the medical system may be conditioned on authentication of a user associated with the device. For example, a pairing process may not be complete until the user of the device has logged in to the device or to an application or service provided by pairing system <NUM> and accessible through the device. Additionally or alternatively, successful pairing may further be conditioned on other parameters, such as an identity of the authenticated user matching an identity of a surgical team member previously assigned to a surgical session (e.g., at initiation or creation of the surgical session), or upon the authenticated user successfully providing user input to identify, for example, a surgical session associated with the medical system with which the device is attempting to pair (e.g., by identifying surgical session ID information, etc.). Pairing system <NUM> may detect such successful authentication in any suitable manner (e.g., by receiving data representative of the successful authentication from the medical system and/or the device).

After transitioning the device from operating in an unpaired to state to operating in a paired state with the medical device, pairing system <NUM> may initialize a clock to an initial time t<NUM> in operation <NUM> (explained below in more detail), and then processing returns to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions.

Returning again to operation <NUM>, if pairing system <NUM> determines that the device is paired with a medical system (e.g., in a paired state or a limited paired state), processing proceeds to operation <NUM> in which pairing system <NUM> determines whether to perform a quick "pilot check" or a more robust "confirmation check. " The pilot check and the confirmation check are part of a maintenance process performed by pairing system <NUM> to determine whether to continue operating the device in the paired state (or in a limited paired state).

In operation <NUM>, pairing system <NUM> determines whether the device detects the pilot signal within a threshold time T of a pairing state initialization event. A pairing state initialization event may comprise any suitable event associated with establishing or maintaining the device in a paired state (or limited paired state). In some examples, a pairing state initialization event includes the most recent transition between pairing states (e.g., performance of operation <NUM>) and/or most recent decoding of an encoded information signal included in a detected ultrasonic beacon transmission (e.g., performance of operation <NUM> or operation <NUM>, which will be described below). Additionally or alternatively, a pairing state initialization event may include detection, by pairing system <NUM>, of a particular action performed by the medical system, an interaction by the user with the device to access a functional feature associated with the medical system (e.g., to control operations of the medical system by way of the user device), or any other suitable action. In yet further examples, a pairing state initialization event may include the passage of the threshold time T.

Operation <NUM> may be performed in any suitable way. For example, pairing system <NUM> may determine whether a time t at which the pilot signal is detected is greater than an initial time t<NUM> plus the threshold time T. The threshold time T may be any suitable time period, such as <NUM> minute, <NUM> seconds, <NUM> seconds, <NUM> second, <NUM> milliseconds, etc. Pairing system <NUM> may set the initial time t<NUM> when a pairing state initialization event occurs, such as by resetting (initializing) a clock to an initial time t<NUM>. For instance, as shown in operation <NUM>, pairing system <NUM> may reset the clock by setting the current time t to zero (t<NUM>). In some examples, the threshold time T may be set (either manually or automatically) based on one or more factors, such as the particular medical system or type of medical system, user role or user profile of the user logged in to the device, the device or type of device, current pairing state (e.g., paired state or limited paired state), whether the device is paired with other medical systems, the number and/or frequency of pairing state transition events, and/or any other suitable information.

In operation <NUM>, if pairing system <NUM> determines that the threshold time T has not elapsed since the pairing state initialization event (e.g., that the device detects the pilot signal within the threshold time T), the process returns to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions. By this pilot check, pairing system <NUM> causes the device to continue operating in the communicatively paired state based on the detection of the pilot signal of the ultrasonic beacon transmission but without decoding the encoded information signal of the ultrasonic beacon transmission.

If, however, pairing system <NUM> determines that the threshold time T has elapsed since the pairing state initialization event (e.g., the detection of the pilot signal is not within the threshold time T), processing proceeds to operation <NUM>.

In operation <NUM>, pairing system <NUM> decodes the encoded information signal of the ultrasonic beacon transmission to identify a medical system associated with the ultrasonic beacon transmission. Operation <NUM> may be performed in any suitable way, including any way described herein.

In operation <NUM>, pairing system determines whether the medical system associated with the ultrasonic beacon transmission corresponds to the medical system with which the device is currently paired. Operation <NUM> may be performed in any suitable way. For example, pairing system <NUM> may compare the decoded information from the encoded information signal with the medical facility data to determine whether the device is currently located in the same location as the medical facility with which the device is paired. Operation <NUM> may additionally or alternatively include performing an error correction process based on the information signal.

If pairing system <NUM> determines that the medical system associated with the ultrasonic beacon transmission corresponds to the medical system with which the device is currently paired, processing proceeds to operation <NUM> to initialize the clock and then returns to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions. By this confirmation check, pairing system <NUM> causes the device to continue operating in the communicatively paired state based on a confirmation that the medical system associated with the ultrasonic beacon transmission corresponds to the medical system with which the device is currently paired.

If, however, pairing system <NUM> determines in operation <NUM> that the medical system associated with the ultrasonic beacon transmission does not correspond to the medical system with which the device is presently paired, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> sets a new pairing state based on the medical system associated with the detected ultrasonic beacon transmission. For example, pairing system <NUM> may transition the device from operating in a paired state with the currently paired medical system to operating in an unpaired state with the medical system. Additionally or alternatively, pairing system <NUM> may cause the device to enter into a pairing state in which the device is communicatively paired with the medical system associated with the ultrasonic beacon transmission.

Processing then proceeds to operation <NUM> to initialize the clock and then returns to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions. By this confirmation check, pairing system <NUM> may transition to a new pairing state when a new medical system is detected. In the new pairing state, the device may be unpaired from any medical system, may pair only with the newly detected medical system, or may be paired with both the presently paired medical system and the newly detected medical system.

In the foregoing process, the pilot check may be performed more frequently than the confirmation check (e.g., with a frequency greater than <NUM>/T) because decoding an encoded information signal consumes more battery power than does detecting a pilot signal. Thus, method <NUM> accurately infers and intended pairing state and manages the pairing state while conserving battery power.

Various modifications may be made to method <NUM> to further refine establishment and management of the pairing state of the device, as will now be described.

For example, rather than performing a confirmation check only in response to a determination that the threshold time T has elapsed since the pairing state initialization event (operation <NUM> (Y)), pairing system <NUM> may additionally or alternatively decode the encoded information signal when some other detected condition indicates a possible change in conditions (e.g., that the device may have moved, another beacon generator has come online, etc.). For example, pairing system <NUM> may detect a change in quality of the pilot signal (e.g., a drop or increase in SNR), which may occur, for instance, when the device moves farther away from or closer to an ultrasonic beacon generator. In other examples, pairing system <NUM> may detect a sudden change in timing of pilot signal transmissions, different information encoded in the pilot signal, or any other suitable change in conditions. In response to detecting the change in quality of the pilot signal and/or other changed conditions, pairing system <NUM> may proceed to operation <NUM> and perform the confirmation check. In some examples, detection of the changed conditions may trigger the confirmation check even when the threshold time T has not elapsed since the pairing state initialization event.

In another modification, rather than monitoring only for pilot signals in operation <NUM>, pairing system <NUM> may instead monitor for any communication in the ultrasonic range. For example, the pilot signal may be the same as, or a part of, the information signal. Accordingly, pairing system <NUM> may detect a pilot signal simply by detecting the presence of a transmission in the ultrasonic range.

In some examples, the device does not transition directly from a paired state to an unpaired state if the pilot check or confirmation check fails. Rather, the device may transition from a paired state only to a limited paired state. In additional or alternative examples, the device transitions from a paired state to a limited paired state or an unpaired state only if the pilot check or confirmation check fails a threshold number of consecutive times.

In some examples, operation <NUM> is omitted from method <NUM> so that pairing system <NUM> does not perform a pilot check. In these examples, the device continues operating in the current pairing state only upon a successful confirmation check.

In yet further examples, operation <NUM> may be performed based on user input, as shown in <FIG> shows a method <NUM> that is similar to method <NUM> except that method <NUM> includes an operation <NUM> prior to performing operation <NUM>.

In operation <NUM>, pairing system <NUM> receives user input indicating a desired pairing state of the device, and in operation <NUM> pairing system sets the pairing state based on the received user input. The user input may be received in any suitable way. For example, pairing system <NUM> may prompt the user, by way of the device (e.g., by way of a graphical user interface, by an audio or haptic notification, or the like), to provide input in response to any one or more of operation <NUM> (Y), operation <NUM>, and operation <NUM> (N). The device may be configured to receive the user input in any suitable way, such as by touch input, voice command, or motion gesture of the device.

To illustrate, if operation <NUM> is reached from operation <NUM> (no pilot signal detected while operating in a paired state) or operation <NUM> (confirmation failed while operating in a paired state), the user input may indicate a desire to maintain operation of the device in the paired state even though no ultrasonic beacon transmission is detected. Accordingly, in operation <NUM> pairing system <NUM> may set the device to continue operating in the paired state or in a limited paired state.

If operation <NUM> is reached from operation <NUM>, the user may be prompted to confirm, by user input by way of the device, a desire to pair the device with the medical system associated with the ultrasonic beacon transmission.

Operation <NUM> may assist pairing system <NUM> to determine an appropriate pairing state when the device detects multiple different ultrasonic beacons. In some examples, method <NUM> is performed when the device detects multiple different ultrasonic beacons, and method <NUM> is performed when the device detects only one ultrasonic beacon.

While <FIG> shows that operation <NUM> may be performed in response to operations <NUM> (N), <NUM>, and <NUM> (Y), operation <NUM> may be performed in response to more or fewer operations and/or any other operations as may serve a particular implementation (e.g., operation <NUM> (N)).

In yet further modifications of methods <NUM> and <NUM>, operation <NUM> may further be performed based on preferences or a profile of the user or a role of the user (e.g., surgeon, nurse, technician, etc.). For example, a user may specify particular preferences for transitioning between pairing states. Additionally or alternatively, an administrator of pairing system <NUM> may limit certain functional features that may be accessed by way of the user device based on the user or user role.

As mentioned above, motion of the device may also generate a Doppler effect in the encoded information signal of an ultrasonic beacon transmission, making the encoded information signal unrecoverable. Accordingly, the device may be unable to pair with the medical system associated with the ultrasonic beacon transmission, and the confirmation check may fail, resulting in an unintended unpairing of the device. Accordingly, pairing system <NUM> may also be configured to use motion detection in the maintenance process and/or to set the pairing state of the device. Accordingly, operation <NUM> in <FIG> and <FIG> may be substituted as shown in <FIG>. Additionally or alternatively, operation <NUM> in <FIG> and <FIG> may be substituted as shown in <FIG>.

<FIG> shows illustrative alternative operations <NUM> to <NUM> that may be substituted for operation <NUM> in <FIG> and <FIG>.

Operation <NUM> is performed after operation <NUM> (N). In operation <NUM>, when the device is attempting to pair with a new medical system, pairing system <NUM> may determine whether the encoded information signal of the detected ultrasonic beacon transmission is decodable. Operation <NUM> may be performed in any suitable way, such as by a parity check, an error check, validation of the decoded information against reference information (e.g., medical facility data), or any other suitable validation method.

If pairing system <NUM> determines that the encoded information signal is decodable, pairing system <NUM> decodes the encoded information signal in operation <NUM> and then proceeds to operation <NUM>, which may be performed as described above to communicatively pair the device with the medical system associated with the ultrasonic beacon transmission.

If, however, pairing system <NUM> determines that the encoded information signal is not decodable, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> determines whether the device is in motion. Operation <NUM> may be performed in any suitable way. In some examples, pairing system <NUM> may determine that the device is in motion based on information generated by one or more motion sensors included in the device and configured to detect motion of the device. The motion sensor(s) may include, for example, an inertial measurement unit (IMU), an accelerometer, a gyroscope, a magnetometer, and/or any other suitable motion sensing device. Additionally or alternatively, pairing system <NUM> may process the encoded information signal to identify the Doppler shift in the encoded information signal.

If pairing system <NUM> determines that the device is not in motion, processing may return to operation <NUM>, which may be performed as described above to monitor for subsequent ultrasonic beacon transmissions. Additionally or alternatively, pairing system <NUM> may perform any other operations configured to improve reception and/or decoding of the encoded information signal, such as adjusting frequency filters or algorithms used to process encoded information signal.

If, however, pairing system <NUM> determines that the device is in motion, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> performs a motion mitigation process. In some examples, the motion mitigation process includes providing a notification to the user indicating that pairing was unsuccessful due to motion and/or instructing the user to hold the device still so the device can be paired. Additionally or alternatively, the motion mitigation process may include providing alternate means for pairing the device with the medical system. The alternate means may include any suitable means configured to establish that the device is in physical proximity to the medical system, such as a barcode, a QR code, an RFID tag, image recognition, user input, and the like. Additionally or alternatively, motion mitigation may comprise not attempting to pair while the device is in motion. In some examples, motion mitigation may include implementing changes to transmission or reception protocols, such as spacing out subchannel frequencies (refer to <FIG>) or storing and combining more ultrasonic beacon transmissions (e.g., transmissions <NUM>) together at the device. Such techniques may make pairing more robust at the expense of a slightly increased pairing time. In yet further examples, motion mitigation may include performing a Doppler correction of the corrupted information signal. Doppler correction may be performed in any suitable way.

Upon performing operation <NUM>, processing returns to operation <NUM>, which may be performed as described above to monitor for subsequent ultrasonic beacon transmissions.

Operation <NUM> is performed after operation <NUM> (Y) when pairing system <NUM> is attempting to confirm that the medical system associated with the detected ultrasonic beacon corresponds to the medical system device with which the device is presently paired. In operation <NUM>, pairing system <NUM> may determine whether the encoded information signal of the detected ultrasonic beacon transmission is decodable. Operation <NUM> may be performed in any suitable way, including any way described herein.

If pairing system <NUM> determines that the encoded information signal is decodable, pairing system <NUM> decodes the encoded information signal in operation <NUM> and then proceeds to operation <NUM>, which may be performed as described above.

If, however, pairing system <NUM> determines that the encoded information signal is not decodable, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> determines whether the device is in motion. Operation <NUM> may be performed in any suitable way, including in any way described herein.

If, however, pairing system <NUM> determines that the device is in motion, processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> performs a motion mitigation process. Operation <NUM> may be performed in any suitable way and may be similar to operation <NUM> described above. For example, operation <NUM> may comprise providing a notification to the user indicating that confirmation of pairing cannot be performed due to motion and/or instructing the user to hold the device still for the confirmation check, providing alternate means (as described above) for confirming the paired state of the device, not attempting to confirm the paired state of the device while the device is in motion, implementing changes to transmission or reception protocols, and/or performing a Doppler correction of the corrupted information signal. In additional or alternative examples, operation <NUM> may comprise transitioning the device to operate in a limited paired state, as described above.

In yet further examples, the motion mitigation process may include modifying one or more parameters to prevent unpairing while the device is in motion. For example, the motion mitigation process may comprise initializing the clock (e.g., setting the current time t = t<NUM> or to some other earlier time) and/or increasing the threshold time T.

In some examples, pairing system <NUM> may count a number of consecutive occurrences of an undecodable beacon (operation <NUM> (N) and/or operation <NUM> (N)) and/or a number of occurrences of motion detection and, in response, may perform an additional mitigation action. The additional mitigation action may include, for example, transitioning the device to operate in a new pairing state (e.g., an unpaired state, a limited paired state, etc.), requesting user input to indicate the appropriate pairing state, and/or any of the mitigation actions previously described.

<FIG> shows another illustrative method <NUM> that accounts for device motion. Method <NUM> is similar to method <NUM> except that in method <NUM> an operation <NUM> has been added and operations <NUM> and <NUM> have been removed.

In operation <NUM>, pairing system <NUM> determines whether the device is in motion. Operation <NUM> may be performed in any suitable way, including any way described herein.

If pairing system <NUM> determines that the device is in motion, processing returns to operation <NUM> to continue monitoring for ultrasonic beacon transmissions. Accordingly, pairing system <NUM> does not attempt to communicatively pair or confirm a paired state of the device while the device is in motion.

In an alternative configuration of method <NUM>, processing proceeds to operation <NUM>, as indicated by the dashed line, if pairing system <NUM> determines that the device is in motion. Thus, when the device is currently unpaired (operation <NUM> (N)), pairing system <NUM> does not attempt to communicatively pair the device while the device is in motion.

On the other hand, when the device is currently paired (operation <NUM> (Y)), processing proceeds to operation <NUM>. In operation <NUM>, pairing system <NUM> may set the device to operate in a limited paired state while the device is in motion. In this way, pairing system <NUM> maintains the device operating in a paired state based on detection of the pilot signal but prevents potentially undesired actions that may be taken by the user by setting the device to the limited paired state while the device is in motion.

Returning again to operation <NUM>, if pairing system <NUM> determines that the device is not in motion, processing proceeds to operation <NUM>, which may be performed as described above to determine whether the device is presently paired with a medical system. Pairing system <NUM> may then either proceed to communicatively pair the device with a medical system (operations <NUM> and <NUM>) or perform a confirmation check (operations <NUM> and <NUM>).

Certain foregoing embodiments have described establishing and/or managing a pairing state of a device with respect to a single medical system based on a single detected ultrasonic beacon. In other embodiments, pairing system <NUM> may be configured to pair or manage a paired state of a device with one or more medical systems based on detection of multiple ultrasonic beacons. For example, as described above and as shown in <FIG> and <FIG>, medical facility <NUM> may include multiple beacon generators <NUM> within predefined area <NUM> and/or included in medical system <NUM>, and, as shown in <FIG>, medical facility <NUM> may include additional beacon generators <NUM> located outside of predefined area <NUM> (e.g., within predefined area <NUM>). Methods <NUM>, <NUM>, and <NUM> may be used in such multi-beacon configurations.

In some examples, pairing system <NUM> is configured to pair or confirm a pairing state of a device with a medical system only if pairing system <NUM> determines that the device detects a set of multiple ultrasonic beacons associated with a particular medical system. For example, in operation <NUM> of methods <NUM>, <NUM>, and/or <NUM>, pairing system <NUM> may determine that the device detects multiple distinct pilot signals of multiple different ultrasonic beacon transmissions (e.g., ultrasonic beacon transmissions of different ultrasonic beacons). If the device is not in a paired state (operation <NUM> (N)), or if the device is in a paired state and the pilot signals are detected after the threshold time T (operation <NUM> (Y)), pairing system <NUM> may decode the encoded information signals of each ultrasonic beacon transmission to identify a medical system associated each of the detected ultrasonic beacon transmissions (operation <NUM>). In operation <NUM>, pairing system <NUM> may set the pairing state of the device or confirm the pairing state based on the information included in the decoded encoded information signals.

For example, pairing system <NUM> may pair or confirm a pairing state of the device with a medical system that is associated with two or more of the detected ultrasonic beacon transmissions. For instance, with reference to <FIG>, pairing system <NUM> may communicatively pair or maintain a paired state of user device <NUM> with medical system <NUM> only if pairing system <NUM> determines that user device <NUM> detects any two or more of ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>.

In other examples, pairing system <NUM> may pair or confirm a pairing state of the device with a medical system only if pairing system <NUM> determines that the device detects the set of all ultrasonic beacons associated with the medical system. For instance, with reference to <FIG>, pairing system <NUM> may communicatively pair or maintain a paired state of user device <NUM> with medical system <NUM> only if pairing system <NUM> determines that user device <NUM> detects all ultrasonic beacons <NUM> (e.g., ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>) associated with medical system <NUM>. If pairing system <NUM> determines that user device <NUM> does not detect all ultrasonic beacons <NUM> associated with medical system <NUM>, pairing system <NUM> does not communicatively pair user device <NUM> with medical system <NUM> (or pairs user device <NUM> in a limited paired state with medical system <NUM>) or determines that the confirmation check has failed and proceeds to operation <NUM> (e.g., transitions to an unpaired state or a limited paired state).

In some examples, the set of ultrasonic beacons comprises all ultrasonic beacons included in components of the medical system. For instance, the set of ultrasonic beacons may include a unique component identifier (encoded in the information signal in each ultrasonic beacon transmission) for each component included in the medical system. In this way, pairing system <NUM> does not pair the device with the medical system unless pairing system <NUM> determines that the device has detected an ultrasonic beacon associated with each component of the medical system (e.g., an ultrasonic beacon included in manipulating system <NUM>, an ultrasonic beacon included in user control system <NUM>, and an ultrasonic beacon included in auxiliary system <NUM>). Pairing system <NUM> may determine whether a device detects a set of all ultrasonic beacons associated with a medical system in any suitable way. For example, pairing system <NUM> may refer to medical facility data to determine whether the device detects all ultrasonic beacons associated with a particular medical system.

In some examples, pairing system <NUM> may condition pairing or confirmation of a pairing state of a device with a medical system on a determination that the device does not detect any ultrasonic beacons that are not associated with the currently paired medical system. For instance, as shown with reference to <FIG>, pairing system <NUM> may communicatively pair or confirm pairing of user device <NUM> with medical system <NUM> only if pairing system <NUM> determines that user device <NUM> does not detect any ultrasonic beacons other than ultrasonic beacons <NUM> (e.g., any of ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>). If pairing system <NUM> determines that user device <NUM> detects any ultrasonic beacon <NUM>, and even if user device <NUM> detects one or more (or all) ultrasonic beacons <NUM>, pairing system <NUM> does not communicatively pair user device <NUM> with medical system <NUM> (or pairs user device <NUM> in a limited paired state with medical system <NUM>) or determines that the confirmation check has failed and proceeds to operation <NUM> (e.g., transitions to an unpaired state or a limited paired state).

In yet further examples, pairing system <NUM> may pair a device with a medical system in a limited paired state if pairing system <NUM> determines that the device detects ultrasonic beacons not associated with the currently paired medical system. For instance, as shown with reference to <FIG>, pairing system <NUM> may communicatively pair user device <NUM> with medical system <NUM> in a limited paired state if pairing system <NUM> determines that user device <NUM> detects ultrasonic beacons associated with medical system <NUM> (e.g., any of ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>). If pairing system <NUM> determines that user device <NUM> detects any ultrasonic beacon <NUM>, pairing system <NUM> does not communicatively pair user device <NUM> with medical system <NUM>, even if user device <NUM> detects one or more (or all) ultrasonic beacons <NUM>.

In additional or alternative examples, in operation <NUM> pairing system <NUM> may pair a device with a medical system that is associated with the most ultrasonic beacons detected by the device. For example, pairing system <NUM> may pair user device <NUM> with medical system <NUM> in response to determining that user device <NUM> detects three ultrasonic beacons (e.g., ultrasonic beacons <NUM>-<NUM> through <NUM>-<NUM>) associated with medical system <NUM> and detects only two ultrasonic beacons (e.g., ultrasonic beacons <NUM>-<NUM> and <NUM>-<NUM>) associated with medical system <NUM>.

In any of the examples described herein, pairing or confirming a pairing state of a device may also be based on a signal strength of the detected ultrasonic beacons. For example, pairing system <NUM> may pair or confirm a pairing of a device with a medical system only if the signal strengths of the ultrasonic beacons associated with the medical system exceed a predetermined threshold.

Referring again to operation <NUM>, if the device is in a paired state or a limited paired state (operation <NUM> (Y)) after detecting multiple pilot signals and the pilot signals are detected within the threshold time T (operation <NUM> (N)), then pairing system <NUM> may maintain operation of the apparatus in the current paired state and return to operation <NUM> to monitor for subsequent ultrasonic beacon transmissions. In some examples, pairing system <NUM> may maintain operation of the apparatus in the currently paired state only if the number of pilot signals detected in operation <NUM> corresponds to (e.g., matches, or is equal to or greater than, or is within a certain number of) the number of ultrasonic beacons required for initially pairing the device with the medical system. For instance, as shown with reference to <FIG>, if user device <NUM> is paired with medical system <NUM> based on detection of ultrasonic beacons <NUM>-<NUM> to <NUM>-<NUM>, user device <NUM> may continue operating in the paired state with medical system <NUM> if user device <NUM> detects at least three pilot signals, or if user device <NUM> detects only three pilot signals.

In some examples, if the device detects fewer than a necessary number of pilot signals (e.g., operation <NUM> (N)) while operating in a paired state (operation <NUM> (Y)), pairing system <NUM> may set, in operation <NUM>, a new pairing state based on the number of pilot signals detected (e.g., transition to a limited paired state if some but not all pilot signals are detected).

In the methods and examples described above, pairing system <NUM> may establish and manage a pairing state of a device with respect to a single medical system. In some examples, pairing system <NUM> may establish and manage a pairing state of a device with respect to multiple medical systems simultaneously. For instance, a technician may move between multiple operating rooms and an equipment room while multiple medical procedures are being performed concurrently. Accordingly, the device may detect ultrasonic beacon transmissions associated with multiple different medical systems. Pairing system <NUM> may be configured to use the current pairing state and any other suitable inputs to determine a proper pairing state of the device even when multiple different ultrasonic beacons are detected.

For example, as shown in <FIG> pairing system <NUM> may rely on user input (operation <NUM>) to determine which medical system or systems to pair with the device. Additionally or alternatively, pairing system <NUM> may set a pairing state based on the signal strength of the detected ultrasonic beacons. For instance, as shown in <FIG>, a signal strength of ultrasonic beacons <NUM>-<NUM> to <NUM>-<NUM> detected by user device <NUM> may be stronger than a signal strength of ultrasonic beacons <NUM>-<NUM> to <NUM>-<NUM>. Accordingly, pairing system <NUM> may pair user device <NUM> with medical system <NUM> and not with medical system <NUM>. Alternatively, pairing system <NUM> may pair user device <NUM> in a paired state with medical system <NUM> and in a limited paired state with medical system <NUM>.

In some examples, pairing system <NUM> may default to maintain the currently paired state rather than transition to a new paired state. For instance, as shown in <FIG>, user device <NUM> may be in a paired state with medical system <NUM> when medical system <NUM> comes online and ultrasonic beacons <NUM> are first transmitted. If user device <NUM> now also detects ultrasonic beacons <NUM>, pairing system <NUM> may maintain user device in a paired state with medical system <NUM>. Of course, other default settings may be set and may be changed by the user. For example, pairing system <NUM> may default to request user input and/or transition the user device to operate in a limited paired state with medical system <NUM> and/or medical system <NUM>.

In some examples, pairing system <NUM> may rely on unprompted user input to determine which medical system or systems to pair with the device. For instance, as shown in <FIG>, user device <NUM> may be operating in a paired state with medical system <NUM> and may also detect ultrasonic beacons <NUM>. If the user attempts to access a functional feature associated with medical system <NUM>, pairing system <NUM> may infer that user <NUM> and user device <NUM> are located in proximity to medical system <NUM> and thus may continue operation of user device <NUM> in a paired state with medical system <NUM>. As another example, if the user attempts to access a functional feature associated with medical system <NUM> while user device <NUM> detects ultrasonic beacons <NUM>, pairing system <NUM> may request user input specifying a desired pairing state of user device with respect to medical system <NUM> and medical system <NUM>.

In some alternative examples of the methods described above, an ultrasonic beacon may not be associated with a medical system. For example, the ultrasonic beacon may be associated with a particular location within the medical facility that is not associated with a particular medical system, such as a hallway, a break room, an equipment room, a cafeteria, an office, or a lab room. In these examples, pairing system <NUM> may use the decoded information signal of such ultrasonic beacon transmission as another input to determine an appropriate pairing state. For example, as shown in <FIG>, user device <NUM> may be paired with medical system <NUM> while user device <NUM> is located within predefined area <NUM>. If user <NUM> leaves predefined area <NUM> and carries user device <NUM> into a break room, user device <NUM> may detect an ultrasonic beacon associated with the break room but no longer detect ultrasonic beacon <NUM> associated with medical system <NUM>. Accordingly, pairing system <NUM> may set the pairing state (operation <NUM>) based on the determination that user <NUM> is located in the break room. For example, pairing system <NUM> may transition user device <NUM> to operate in a limited paired state with medical system <NUM> so that user <NUM> may continue to receive and view information associated with the medical procedure occurring in predefined area <NUM>. Alternatively, pairing system <NUM> may unpair user device <NUM> from medical system <NUM> or may maintain the paired state. In yet further examples, pairing system <NUM> may prompt the user to provide user input indicating the desired pairing state and may set the pairing state based on the user input.

The foregoing configurations and embodiments have focused on ultrasonic beacon-based systems. However, the present disclosure is not limited to these configurations and embodiments, as various modifications and changes may be made thereto without departing from the scope of the inventive principles described herein. For example, the systems and methods described herein may be based additionally or alternatively on any other suitable beacon or other push notifications, such as electromagnetic signals (e.g., infrared, radio-frequency identification (RFID), etc.), wireless data signals (e.g., Bluetooth, near-field communication, Wi-Fi, etc.), offline data transfer, and the like. Additionally or alternatively, the systems and methods described herein may be used in facilities and environments other than a medical facility, such as recreational facilities (e.g., amusement parks, sports stadiums, parks, etc.), educational facilities (e.g., schools, universities, etc.), shopping centers, business facilities (e.g., offices, research parks, etc.), laboratories, manufacturing facilities, transportation facilities (e.g., airports, train stations, etc.), and the like.

Illustrative non-volatile storage media include, but are not limited to, read-only memory, flash memory, a solid-state drive, a magnetic storage device (e.g. a hard disk, a floppy disk, magnetic tape, etc.), ferroelectric random-access memory ("RAM"), and an optical disc (e.g., a compact disc, a digital video disc, a Blu-ray disc, etc.). Illustrative volatile storage media include, but are not limited to, RAM (e.g., dynamic RAM).

<FIG> shows an illustrative computing device <NUM> that may be specifically configured to perform one or more of the processes described herein. Any of the systems, units, computing devices, and/or other components described herein may be implemented by computing device <NUM>.

As shown in <FIG>, computing device <NUM> may include a communication interface <NUM>, a processor <NUM>, a storage device <NUM>, and an input/output ("I/O") module <NUM> communicatively connected one to another via a communication infrastructure <NUM>, While an illustrative computing device <NUM> is shown in <FIG>, the components illustrated in <FIG> are not intended to be limiting. Additional or alternative components may be used in other embodiments. Components of computing device <NUM> shown in <FIG> will now be described in additional detail.

Claim 1:
An apparatus comprising:
one or more processors; and
memory storing executable instructions that, when executed by the one or more processors, cause the apparatus to:
detect a first pilot signal included in a first ultrasonic beacon transmission, the first ultrasonic beacon transmission further including a first encoded information signal;
decode, based on the first pilot signal, the first encoded information signal to identify a first medical system associated with the first ultrasonic beacon transmission;
enter, based on the decoding of the first encoded information signal, into a first pairing state in which the apparatus is communicatively paired with the first medical system;
detect, while operating in the first pairing state and within a threshold time of entering the first pairing state, a second pilot signal included in a second ultrasonic beacon transmission, the second ultrasonic beacon transmission further including a second encoded information signal; and
continue, based on the detection of the second pilot signal within the threshold time, operating in the first pairing state without decoding the second encoded information signal.