Patent Description:
Police officers carry various types of equipment on their person and in their vehicles. Each of these devices may perform various functions. For example, a body camera may be configured to record audio and video. A radio may be configured to transmit and receive audio. A mobile phone may be configured to transmit and receive data over a network. <CIT> discloses a method, comprising: detecting, by a wearable smart gateway (WSG) implemented on one or more processors, a first device within a proximity threshold of the wearable smart gateway device, wherein the first device operates using a first communication protocol; detecting, by the WSG, a second device within the proximity threshold of the wearable smart gateway device, wherein the second device operates using a second communication protocol that is a different communication protocol than the first communication protocol; establishing, by the WSG, a personal area network with the first device and the second device, the personal area network comprising a first communication link between first device and the wearable smart gateway using the first communication protocol, and a second communication link between the second device and the wearable smart gateway using the second communication protocol; receiving, by the WSG, first data from the first device over the first communication link and second data from the second device over the second communication link; and performing, by the WSG, interoperability gateway functions to communicate the first data and the second data to an agency via a wide area data network. A further communication method and apparatus is known from <CIT>.

A police officer carries multiple devices on his or her person in the course of duty. These devices may be connected such that they form a personal area network for the officer. Often, wireless communication by a portable device will significantly impact the device's power levels, potentially leading to an inability to function for an officer's entire shift.

A hub is communicatively coupled to the various connected devices in the officer's personal area network. The hub is aware of the functionality of the various connected devices in the personal area network. The hub may be located in a vehicle of the officer or on the officer's person. The hub may maintain intelligent and optimal communication with the officer's devices, as well as dispatch, and potentially with other officers. Power can be saved through device management by the hub utilizing the least power-consuming communication protocol to fully carry out the function of the device. The connected devices may be configured to communicate using short range radio, or some other low power communication protocol. Other connected devices may be configured to utilize higher power-consuming protocols. When the communication functionality is needed on a connected device that functionality is enabled. However, if the connected device has only low-power communication abilities and is outside of the range of other devices or repeaters, the hub can coordinate the communication of a low-power device, e.g., a device that has only a low powered communication protocol with limited range, through a high-power device, e.g., a device that has a low and high-powered communication protocol, to act as a real-time relay for the low-powered device.

The utilization of a connected device to relay communication of a low-powered device may be based on the context. The context may include when the officer is associated with an event and/or within a geographic and temporal proximity of an event and/or when the current context/environment of the officer corresponds to a high priority, or high-risk situation, etc. For example, there may be a need to stream video content captured by a low-power body camera of an officer as it occurs while the body camera is outside the body camera's communication range with the hub. In this example, the hub may cause another connected device of the officer, or another officer, to act as a relay.

According to a first aspect of the present invention, the present invention provides a computer-implemented method according to independent claim <NUM>. The dependent claims <NUM> to <NUM> show further preferred embodiments of the said method. The method includes the actions of receiving, by a first computing device, data indicating that a second computing device is configured to communicate using a first communication protocol; receiving, by the first computing device, data indicating that a third computing device is configured to communicate using the first communication protocol and a second communication protocol; determining, by the first computing device, that the second computing device is unable to communicate with a fourth computing device; determining, by the first computing device, a context of a user of the second computing device; based on determining that the second computing device is unable to communicate with the fourth computing device and the context of the user of the second computing device, generating, by the first computing device, an instruction for the third computing device to communicate with the second computing device using the first communication protocol; and providing, for output by the first computing device and to the third computing device, the instruction for the third computing device to communicate with the second computing device using the first communication protocol.

These and other implementations can each optionally include one or more of the following features. The actions include determining, by the first computing device, a context of any of the first, second, third, or fourth computing devices that are not in a vicinity of the user of the second computing device. The action of generating the instruction for the third computing device to communicate with the second computing device using the first communication protocol is further based on the context of any of the first, second, third, or fourth computing devices that are not in a vicinity of the user of the second computing device. The actions include receiving, by the first computing device and from the fourth computing device, data indicating that the fourth computing device is unable to communicate with the second computing device. The action of determining that the second computing device is unable to communicate with a fourth computing device is based on the data indicating that the fourth computing device is unable to communicate with the second computing device.

The actions include determining, by the first computing device, that the second computing device is able to communicate with the fourth computing device; based on determining that the second computing device is able to communicate with the fourth computing device, generating, by the first computing device, an instruction for the third computing device to cease communicating with the second computing device using the first communication protocol; and providing, for output by the first computing device and to the third computing device, the instruction for the third computing device to cease communicating with the second computing device using the first communication protocol. The actions include, after providing the instruction to the third computing device to cease communicating with the second computing device using the first communication protocol: determining, by the first computing device, that the second computing device is unable to communicate with the fourth computing device; determining, by the first computing device, an additional context of the user of the second computing device; and, based on determining that the second computing device is unable to communicate with the fourth computing device and the additional context of the user of the second computing device, determining to bypass generating, by the first computing device, an additional instruction for the third computing device to communicate with the second computing device using the first communication protocol.

The instruction for the third computing device to communicate with the second computing device using the first communication protocol includes instructions for the third computing device to receive additional data from the second computing device using the first communication protocol and to transmit the additional data to the fourth computing device using the second communication protocol. The instruction for the third computing device to communicate with the second computing device using the first communication protocol includes a time limit for the third computing device to communicate with the second computing device using the first communication protocol.

According to other aspects of the present invention, the present invention provides a system according to independent claim <NUM> and one or more non-transitory computer-readable media of a computing device storing computer-executable instruction according to independent claim <NUM>. The dependent claims <NUM> to <NUM> show further embodiments of the said system.

Particular implementations of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. The hub manages connected devices in a personal area network, including suspending and activating functionality of each device in accordance with any given context and other factors. The hub maintains a messaging broker to communicate with the connected devices. The hub maintains functionality of the personal area network. The hub activates and deactivates the functionality of the connected devices based on emergent conditions. The hub enables low-powered devices to communicate with receivers that may be beyond the range of the low-powered devices. The hub manages the power of devices that have both low and high-power communication options. The hub may selectively identify a suitable high-power relay for low-power devices when necessary.

The detailed description is described with reference to the accompanying figures, in which the left-most digit(s) of a reference number identifies the figure in which the reference number first appears.

<FIG> illustrates an example system <NUM> that is configured to manage the communication functions of various devices. Briefly, and as described in more detail below, the user <NUM> may be utilizing multiple devices. These devices may include a body camera <NUM>, a radio <NUM>, a mobile phone <NUM>, and a laptop computer <NUM>. The laptop computer <NUM> may operate as a hub that is configured to manage the operations of the body camera <NUM>, the radio <NUM>, the mobile phone <NUM>, and any other connected devices. The operations may include how the devices communicate with each other and with other devices. The laptop computer <NUM> may determine the various communication protocols that each device is configured to utilize and with which devices each device is typically configured to communicate. The laptop computer <NUM> may determine that a device is unable to communicate in a manner that the device is configured to. For example, the body camera <NUM> may be configured to transmit video data to the mobile phone <NUM>, but the mobile phone <NUM> is out of range of the body camera <NUM>. In this case, the laptop computer <NUM> may determine that the body camera <NUM> may transmit the video data to the radio <NUM>. The radio <NUM> may then transmit the video data to the mobile phone <NUM>. In some implementations, the laptop computer <NUM> may determine the context of any of the devices that the laptop computer <NUM> manages. Based on that context, the laptop computer <NUM> may determine whether to instruct any of the devices to change communication protocols or destination devices. <FIG> includes various stages A through G that may illustrate the performance of actions and/or the movement of data between various components of the system <NUM>. The system <NUM> may perform these stages in any order.

In more detail, the user <NUM> may be a police officer who is carrying various types of equipment in the vehicle <NUM> of the user <NUM> and the body of the user <NUM>. The equipment may include a radio <NUM> that includes a microphone <NUM>, a speaker <NUM>, and a communications interface <NUM>. The communications interface <NUM> may be configured to transmit and receive voice communications using various techniques that may involve different communication modules. These communication modules may include a short range radio <NUM>, a radio frequency communication module <NUM>, and a cellular communication module <NUM>. In some implementations, the communications interface <NUM> may include additional communication modules that may utilize wireless or wired communication techniques or protocols. The microphone <NUM> may be configured to detect audio and transmit that audio to the communications interface <NUM>. The communications interface <NUM> may output the audio data to another device and/or a communications network. The speaker <NUM> may be configured to receive audio data from the communications interface <NUM> and output the audio data.

The radio <NUM> may include radio sensors <NUM> that are configured to detect various characteristics of the radio <NUM> and/or the environment of the radio <NUM>. For example, the radio sensors <NUM> may include an accelerometer, a gyroscope, a GPS receiver, a barometer, an ambient light sensor, a compass, a gravity sensor, a proximity sensor, a magnetometer, hygrometer, water sensor, solar flux sensor, ultraviolet light detector, and/or any other similar sensors. The radio <NUM> may include a battery <NUM> to provide power to the various components. The radio <NUM> may be configured to receive power from another device such as a power supply, power adapter, and/or any other similar device. This power may be used to charge the battery <NUM>. In some implementations, the radio <NUM> may provide the power to the various components of the radio <NUM>.

The radio <NUM> may include a radio controller <NUM> that is configured to manage the various components of the radio <NUM>. The radio controller <NUM> may be implemented by one or more processors executing software stored on a storage device accessible by the processors. The radio controller <NUM> may manage the processing of the audio data detected by the microphone <NUM> before and during the communications interface <NUM> outputting of the processed audio data. The radio controller <NUM> may manage the processing of audio data received through the communications interface <NUM> before and during the speaker <NUM> outputting the received audio data. The radio controller <NUM> may receive the sensor data from the radio sensors <NUM> and provide the sensor data to the various destinations that may include the communications interface <NUM>.

In some implementations, the radio controller <NUM> may select the communication module from the communication interface <NUM> when the communication interface <NUM> is preparing to transmit and/or receive data. The radio controller <NUM> may also be configured to select the device to which to transmit data. This selection may occur if the intended destination device is not available because the intended destination device is out of range, is powered off, has a low battery, and/or any other similar reason. The radio controller <NUM> may store data related to the communication interface <NUM> in the communication status <NUM>. The communication status <NUM> may be located in a storage device or storage medium in or accessible to the radio <NUM>. The communication status <NUM> may include data related to the status of other devices with which the radio <NUM> communicates. The status of other devices may include data indicating which ones are out of range or which devices may not be available using some of the communication modules. For example, the communication status <NUM> may include data indicating that the mobile phone <NUM> and the laptop computer <NUM> are unavailable using short range radio. The communication status <NUM> may also include whether the radio <NUM> is being used as an intermediary between other devices or whether the radio <NUM> should use a specific device as an intermediary. An intermediary device may act as a repeater or relay that receives data from a transmitting device and forwards the data to a receiving device that may not be able to communicate directly with the transmitting device.

The equipment that the user <NUM> may carry may also include a body camera <NUM>. The body camera <NUM> may be located on the chest of the user <NUM>. The body camera <NUM> may include a video sensor <NUM>, a microphone <NUM>, and a communications interface <NUM>. The communications interface <NUM> may be configured to transmit and receive voice communications using various techniques that may involve different communication modules. These communication modules may include a short range radio <NUM>. In some implementations, the communications interface <NUM> may include additional communication modules that may utilize wireless or wired communication techniques or protocols. The microphone <NUM> may be configured to detect audio. The video sensor <NUM> may be configured to generate video data. The microphone <NUM> and the video sensor <NUM> may be configured to output the audio and video data to a storage device and/or a communications network using the communications interface <NUM>. The storage device may be located on or accessible by the body camera <NUM>.

The body camera <NUM> may include body camera sensors <NUM> that are configured to detect various characteristics of the body camera <NUM> and/or the environment of the body camera <NUM>. For example, the body camera sensors <NUM> may include an accelerometer, a gyroscope, a GPS receiver, a barometer, an ambient light sensor, a compass, a gravity sensor, a proximity sensor, a magnetometer, hygrometer, water sensor, solar flux sensor, ultraviolet light detector, and/or any other similar sensors. The body camera <NUM> may include a battery <NUM> to provide power to the various components. The body camera <NUM> may be configured to receive power from another device such as a power supply, power adapter, and/or any other similar device. This power may be used to charge the battery <NUM>. In some implementations, the body camera <NUM> may provide the power to the various components of the body camera <NUM>.

The body camera <NUM> may include a body camera controller <NUM> that is configured to manage the various components of the body camera <NUM>. The body camera controller <NUM> may be implemented by one or more processors executing software stored on a storage device accessible by the processors. The body camera controller <NUM> may manage the processing of the audio data detected by the microphone <NUM> before and during the communications interface <NUM> outputting of the processed audio data and/or storing the audio data. The body camera controller <NUM> may manage the processing of video data generated by the video sensor <NUM> before and during the communications interface <NUM> outputting of the processed video data and/or storing the video data. The body camera controller <NUM> may receive the sensor data from the body camera sensors <NUM> and provide the sensor data to the various destinations that may include the communications interface <NUM>.

In some implementations, the body camera controller <NUM> may select the communication module from the communication interface <NUM> when the communication interface <NUM> is preparing to transmit and/or receive data. The body camera controller <NUM> may also be configured to select the device to which to transmit data. This selection may occur if the intended destination device is not available because the intended destination device is out of range, is powered off, has a low battery, and/or any other similar reason. The body camera controller <NUM> may store data related to the communication interface <NUM> in the communication status <NUM>. The communication status <NUM> may be located in a storage device or storage medium in or accessible to the body camera <NUM>. The communication status <NUM> may include data related to the status of other devices with which the body camera <NUM> communicates. The status of other devices may include data indicating which ones are out of range or which devices may not be available using some of the communication modules. For example, the communication status <NUM> may include data indicating that the radio <NUM>, the mobile phone <NUM>, and/or the laptop computer <NUM> are unavailable using short range radio. The communication status <NUM> may also include whether the body camera <NUM> is being used as an intermediary between other devices or whether the body camera <NUM> should use a specific device as an intermediary. An intermediary device may act as a repeater or relay that receives data from a transmitting device and forwards the data to a receiving device that may not be able to communicate directly with the transmitting device.

The equipment that the user <NUM> may carry may also include a mobile phone <NUM>. The user <NUM> may carry the mobile phone <NUM>, but the mobile phone <NUM> may not be attached to the user <NUM>. In this case, the user <NUM> may leave the mobile phone <NUM> in the vehicle <NUM> while the user <NUM> is away from the vehicle <NUM>. The body camera <NUM> may include a communications interface <NUM>. The communications interface <NUM> may be configured to transmit and receive communications and other data using various techniques that may involve different communication modules. These communication modules may include a short range radio <NUM>, a cellular communication module <NUM>, a radio frequency communication module <NUM>. In some implementations, the communications interface <NUM> may include additional communication modules that may utilize wireless or wired communication techniques or protocols.

The mobile phone <NUM> may include mobile phone sensors <NUM> that are configured to detect various characteristics of the mobile phone <NUM> and/or the environment of the mobile phone <NUM>. For example, the mobile phone sensors <NUM> may include an accelerometer, a gyroscope, a GPS receiver, a barometer, an ambient light sensor, a compass, a gravity sensor, a proximity sensor, a magnetometer, hygrometer, water sensor, solar flux sensor, ultraviolet light detector, video sensor, image sensor, microphone, and/or any other similar sensors. The mobile phone <NUM> may include a battery <NUM> to provide power to the various components. The mobile phone <NUM> may be configured to receive power from another device such as a power supply, power adapter, and/or any other similar device. This power may be used to charge the battery <NUM>. In some implementations, the mobile phone <NUM> may provide the power to the various components of the mobile phone <NUM>.

The mobile phone <NUM> may include a mobile phone controller <NUM> that is configured to manage the various components of the mobile phone <NUM>. The mobile phone controller <NUM> may be implemented by one or more processors executing software stored on a storage device accessible by the processors. The mobile phone controller <NUM> may manage the processing of the audio data detected by a microphone before and during the communications interface <NUM> outputting of the processed audio data and/or storing the audio data. The mobile phone controller <NUM> may manage the processing of video data generated by a video sensor before and during the communications interface <NUM> outputting of the processed video data and/or storing the video data. The mobile phone controller <NUM> may manage and execute various applications on the mobile phone <NUM>. The mobile phone controller <NUM> may receive sensor data from the mobile phone sensors <NUM> and process the sensor data and/or provide the sensor data to various destinations that may include the communications interface <NUM>.

In some implementations, the mobile phone controller <NUM> may select the communication module from the communication interface <NUM> when the communication interface <NUM> is preparing to transmit and/or receive data. The mobile phone controller <NUM> may also be configured to select the device to which to transmit data. This selection may occur if the intended destination device is not available because the intended destination device is out of range, is powered off, has a low battery, and/or any other similar reason. The mobile phone controller <NUM> may store data related to the communication interface <NUM> in the communication status <NUM>. The communication status <NUM> may be located in a storage device or storage medium in or accessible to the mobile phone <NUM>. The communication status <NUM> may include data related to the status of other devices with which the mobile phone <NUM> communicates. The status of other devices may include data indicating which ones are out of range or which devices may not be available using some of the communication modules. For example, the communication status <NUM> may include data indicating that the radio <NUM>, the body camera <NUM>, and/or the laptop computer <NUM> are unavailable using short range radio. The communication status <NUM> may also include whether the mobile phone <NUM> is being used as an intermediary between other devices or whether the mobile phone <NUM> should use a specific device as an intermediary. An intermediary device may act as a repeater or relay that receives data from a transmitting device and forwards the data to a receiving device that may not be able to communicate directly with the transmitting device.

The equipment that the user <NUM> utilizes may also include a laptop computer <NUM>. The laptop computer <NUM> may include various components that facilitate the laptop computer <NUM> operating as a hub that manages the various components that the user <NUM> carries and the various components that the user <NUM> utilizes but may not carry. In this way, the laptop computer <NUM> may manage the personal area network of the user <NUM>. The personal area network may include the laptop computer <NUM>, the mobile phone <NUM>, the radio <NUM>, the body camera <NUM>, and any other devices that laptop computer <NUM> may be able to manage. The laptop computer <NUM> includes a hub controller <NUM>. The hub controller <NUM> may be implemented by one or more processors executing software stored on a storage device accessible by the processors. The hub controller <NUM> may be configured to manage the various components of the laptop computer <NUM>. The components may include a communications interface <NUM>, hub sensors <NUM>, a communication status selector <NUM>, and a context determiner <NUM>. The communications interface <NUM> may be configured to transmit and receive data using various techniques. These techniques may include radio frequency communications, Wi-Fi, short range radio, cellular communications, and/or any other similar wireless or wired communication technique. The hub controller <NUM> may be configured to instruct the communications interface <NUM> to utilize a particular communications technique and/or prevent communications using a particular communications technique. For example, the hub controller <NUM> may instruct the communications interface <NUM> to deactivate the cellular communications. As another example, the hub controller <NUM> may instruct the communications interface <NUM> to only utilize short range radio.

The hub sensors <NUM> may include an accelerometer, a gyroscope, a GPS receiver, a barometer, an ambient light sensor, a compass, a gravity sensor, a proximity sensor, a magnetometer, image sensor, video sensor, microphone, hygrometer, water sensor, solar flux sensor, ultraviolet light detector, and/or any other similar sensors. The hub controller <NUM> may be configured to activate or deactivate any of the hub sensors <NUM>. The hub controller <NUM> may also be configured to provide the hub sensor data to the communications interface <NUM> for output, to a storage device, and/or to another component of the laptop computer <NUM> for further processing.

The context determiner <NUM> may be configured to determine the context of the laptop computer <NUM>, any other devices communicating with the laptop computer <NUM>, and/or the user <NUM>. The context determiner <NUM> may analyze the hub sensor data, the radio sensor data, the body camera sensor data, the phone sensor data, audio data from the radio <NUM>, video and audio data from the body camera <NUM>, data from the mobile phone <NUM>, and/or additional data from other devices. The context determiner <NUM> may determine a likely context of the laptop computer <NUM>, the user <NUM>, and/or any other devices communicating with the laptop computer <NUM> based on this analysis. The context may indicate the likely actions in which the user <NUM> may be participating, the activities that may likely be occurring around the user <NUM>, the likely path of the user <NUM>, the weather around the user <NUM>, and/or any other similar context.

The hub controller <NUM> may maintain a record of the devices that the hub controller <NUM> manages. This record may include identifiers for each of the devices and data related to each device such as the characteristics of the devices and the functions of the devices. The laptop computer <NUM> may include a connected devices storage <NUM>. The connected devices storage <NUM> may implemented in a storage device that is accessible by the hub controller <NUM>. The connected devices storage <NUM> may include the device identifiers <NUM>. The device identifiers <NUM> may include data identifying each of the devices that the laptop computer <NUM> is managing. In the example of <FIG>, the device identifiers <NUM> may include data identifying the body camera <NUM>, data identifying the radio <NUM>, and data identifying the mobile phone <NUM>.

The connected devices storage <NUM> may include the device characteristics <NUM> and the communication statuses <NUM> for the devices referenced in the device identifiers <NUM>. The communication statuses <NUM> may include data related to the communication capabilities of the corresponding devices. The communication capabilities may include the communication modules that are included in each device. The communication statuses <NUM> may include data related to the devices with which each device is able to communicate. This may include the devices that are within range of each device for communication interfaces that may be limited by range, for example, wireless communication techniques. In some implementations, the communication statuses <NUM> may include similar information to the communication status <NUM> of the body camera <NUM>, the communication status <NUM> of the radio <NUM>, the communication status <NUM> of the mobile phone <NUM>, and/or any other devices connected to the laptop computer <NUM>. The communication statuses <NUM> may include instructions provided to connected devices related to communication techniques and protocols. These instructions may include when a device should act as an intermediary and for which other devices the device is the intermediary. The instructions may include the timing of acting as an intermediary such as the start time and/or the end time. The instructions may include a condition that indicates when to start and/or end acting as an intermediary. The instructions may be updated as the communication status selector <NUM> generates additional instructions. The communication statuses <NUM> may also include details whether the corresponding device confirmed the instructions.

The device characteristics <NUM> may be related to the aspects of the devices that change other than changes in communication protocols and techniques. In some implementations, the device characteristics <NUM> may include sensor data received from the connected devices. For example, the device characteristics <NUM> may include body camera sensor data, radio sensor data, mobile phone sensor data, and/or sensor data from other connected devices. The device characteristics <NUM> may also include sensor data collected by the hub sensors <NUM>.

In stage A, the hub controller <NUM> may access the device identifiers <NUM> and determine that the radio <NUM>, the body camera <NUM>, and the mobile phone <NUM> are communicating with the laptop computer <NUM>. The hub controller <NUM> may determine that the communication statuses <NUM> may not include data indicating the various communication capabilities of the body camera <NUM>, the mobile phone <NUM>, and the radio <NUM>. In some implementations, the hub controller <NUM> may determine that the device functions <NUM> for the radio <NUM>, the mobile phone <NUM>, and/or the body camera <NUM> have not been updated in a threshold period of time. The hub controller <NUM> may attempt to communicate with each of the devices. The hub controller <NUM> may generate a communication request to each of the devices. The hub controller <NUM> may generate a communication request <NUM> and provide the communication request <NUM> to the communications interface <NUM> along with instructions to provide the communication request <NUM> to the mobile phone <NUM>. The communications interface <NUM> may attempt to transmit the communication request <NUM> using various communication techniques in an attempt to communicate with the mobile phone <NUM>. The communications interface <NUM> receives the communication request <NUM> and provides the communication request <NUM> to the mobile phone controller <NUM>. The mobile phone controller <NUM> determines that the communication techniques of the mobile phone <NUM> are short range radio, radio frequency communications, and cellular communication. The mobile phone controller <NUM> may generate the communication response <NUM> that indicates these communication techniques. The mobile phone controller <NUM> may provide the communication response <NUM> to the communication interface <NUM> that then provides the communication response <NUM> to the communication interface <NUM> of the laptop computer <NUM>. The hub controller <NUM> stores the communication response <NUM> in the communication statuses <NUM>. The communication statuses <NUM> then indicate that the mobile phone <NUM> has the capability of communicating using short range radio, cellular, and radio frequency. In some implementations, the exchange of the communication request <NUM> and the communication response <NUM> may occur when the devices that include the laptop computer <NUM> and the mobile phone <NUM> are assigned to the user <NUM>.

The hub controller <NUM> may generate a communication request <NUM> and provide the communication request <NUM> to the communications interface <NUM> along with instructions to provide the communication request <NUM> to the radio <NUM>. The communications interface <NUM> transmits the communication request <NUM> to the radio <NUM>. The communications interface <NUM> receives the communication request <NUM> and provides the communication request <NUM> to the radio controller <NUM>. The radio controller <NUM> determines that the communication techniques of the radio <NUM> are short range radio, radio frequency communications, and cellular communication. The radio controller <NUM> may generate the communication response <NUM> that indicates these communication techniques. The radio controller <NUM> may provide the communication response <NUM> to the communication interface <NUM> that then provides the communication response <NUM> to the communication interface <NUM> of the laptop computer <NUM>. The hub controller <NUM> stores the communication response <NUM> in the communication statuses <NUM>. The communication statuses <NUM> then indicate that the radio <NUM> has the capability of communicating using short range radio, cellular, and radio frequency. In some implementations, the exchange of the communication request <NUM> and the communication response <NUM> may occur when the devices that include the laptop computer <NUM> and the radio <NUM> are assigned to the user <NUM>.

The hub controller <NUM> may generate a communication request <NUM> and provide the communication request <NUM> to the communications interface <NUM> along with instructions to provide the communication request <NUM> to the body camera <NUM>. The communications interface <NUM> transmits the communication request <NUM> to the body camera <NUM>. The communications interface <NUM> receives the communication request <NUM> and provides the communication request <NUM> to the body camera controller <NUM>. The body camera controller <NUM> determines that the communication technique of the body camera <NUM> is short range radio. The body camera controller <NUM> may generate the communication response <NUM> that indicates this communication technique. The body camera controller <NUM> may provide the communication response <NUM> to the communication interface <NUM> that then provides the communication response <NUM> to the communication interface <NUM> of the laptop computer <NUM>. The hub controller <NUM> stores the communication response <NUM> in the communication statuses <NUM>. The communication statuses <NUM> then indicate that the body camera <NUM> has the capability of communicating using short range radio. In some implementations, the exchange of the communication request <NUM> and the communication response <NUM> may occur when the devices that include the laptop computer <NUM> and the body camera <NUM> are assigned to the user <NUM>.

In some implementations, the communication response <NUM> and/or the communication response <NUM> may indicate that the body camera <NUM> is configured to transmit the video and audio data to the mobile phone <NUM>, and the mobile phone <NUM> transmits the video and audio data to the destination requested by the body camera <NUM>. In this way, the communication response <NUM> and/or the communication response <NUM> indicates that the mobile phone <NUM> is the intermediary of the body camera <NUM>. In some implementations, the communication response <NUM> and/or the communication response <NUM> may indicate that the mobile phone <NUM> is the intermediary for the body camera <NUM> in instances when the body camera <NUM> is unable to communicate with the device that the body camera <NUM> intends to transmit audio and/or video data.

In some implementations, the hub controller <NUM> analyzes the communication statuses <NUM> and determines that the mobile phone <NUM> should act as the intermediary for the body camera <NUM>. The hub controller <NUM> may determine that the body camera <NUM> is only able to communicate using short range radio. Based on this, the hub controller <NUM> may identify the mobile phone <NUM> or the radio <NUM> as devices that can act as intermediaries for the body camera <NUM>. In this case, the hub controller <NUM> may transmit an instruction to the mobile phone <NUM> to act as the intermediary for the body camera <NUM> and an instruction to the body camera <NUM> to utilize the mobile phone <NUM> as an intermediary. These instructions may be stored in the communication status <NUM> of the body camera <NUM> and the communication status <NUM> of the mobile phone <NUM>.

The user <NUM> may be in the vehicle <NUM>. In this case, the body camera <NUM> may be in the vicinity of the mobile phone <NUM> if the body camera <NUM> needs to use the mobile phone <NUM> as an intermediary. In some implementations, the user <NUM> may not be in the vehicle <NUM>. Instead, the user <NUM> may be carrying the mobile phone <NUM> while wearing the body camera <NUM>. In stage B, the user <NUM> may be separated from the mobile phone <NUM>. This may occur if the user <NUM> leaves the vehicle <NUM> and the mobile phone <NUM> remains in the vehicle <NUM>.

After the user <NUM> leaves the vehicle <NUM>, the mobile phone <NUM> and the body camera <NUM> may be unable to communicate. This inability to communicate may be because the mobile phone <NUM> is out of range of the short range radio <NUM> of the body camera <NUM>. When the mobile phone <NUM> detects that the mobile phone <NUM> is no longer connected to the body camera <NUM> over short range radio, the mobile phone controller <NUM> may generate a communication notice <NUM> that indicates that the mobile phone <NUM>. The mobile phone controller <NUM> may provide the communication notice <NUM> to the communications interface <NUM>. The mobile phone controller <NUM> may also store body camera communication status data <NUM> in the communication status <NUM>. The body camera communication status data <NUM> may indicate that the mobile phone <NUM> is unable to communicate with the body camera <NUM>.

The communication interface <NUM> of the laptop computer <NUM> may receive the communication notice <NUM>. The hub controller <NUM> may update the communication statuses <NUM> based on the communication notice <NUM>. The hub controller <NUM> may store data indicating that the body camera <NUM> and the mobile phone <NUM> are unable to communicate.

In some implementations, the hub controller <NUM> may determine that the radio <NUM> is able to act as an intermediary for the body camera <NUM> while the body camera <NUM> is unable to communicate with the mobile phone <NUM>. In this case, the hub controller <NUM> may instruct the radio <NUM> to act as an intermediary for the body camera <NUM>. The hub controller <NUM> may also notify the mobile phone <NUM> that the radio <NUM> is acting as an intermediary for the body camera <NUM> while the mobile phone <NUM> is unable to communicate with the body camera <NUM>.

In some implementations, the hub controller <NUM> may not automatically instruct the radio <NUM> to act as an intermediary for the body camera <NUM> in instances when the body camera <NUM> is unable to communicate with the mobile phone <NUM>. Instead, the hub controller <NUM> may determine the context of the user <NUM>, the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM> to determine whether to instruct the radio <NUM> to act as an intermediary for the body camera <NUM>. Based on that context, the hub controller <NUM> may determine whether to instruct the radio <NUM> to act as an intermediary for the body camera <NUM> or bypass instructing the radio <NUM> to act as an intermediary for the body camera <NUM>. If the hub controller <NUM> bypasses instructing the radio <NUM> to act as an intermediary for the body camera <NUM>, then the body camera <NUM> may be unable to output audio and/or video data for the period of time while the body camera <NUM> is unable to communicate with the mobile phone <NUM>.

In stage C, the hub controller <NUM> may request data to determine the context of the user <NUM>, the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM>. This determination may involve analyzing the characteristics of the user <NUM>, the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM>. The hub controller <NUM> may access the device characteristics <NUM> to determine whether the device characteristics for the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM> have been updated within a threshold period of time. If the hub controller <NUM> determines that the device characteristics for the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM> have been updated within a threshold period of time, then the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the user <NUM>, the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM>. If the hub controller <NUM> determines that the device characteristics for the body camera <NUM>, the radio <NUM>, the laptop computer <NUM>, and/or the mobile phone <NUM> have not been updated within a threshold period of time, then the hub controller <NUM> may update the device characteristics <NUM>.

In some implementations, the hub controller <NUM> may determine with which devices the laptop computer <NUM> is capable of communicating. The hub controller <NUM> may access the communication statuses <NUM>. Based on accessing the communication statuses <NUM>, the hub controller <NUM> may determine that the communications interface <NUM> can communicate with the mobile phone <NUM> using short range radio, radio frequency communications, and/or cellular communications. The hub controller <NUM> may determine that the communications interface <NUM> can communicate with the radio <NUM> using short range radio, radio frequency communications, and/or cellular communications. The hub controller <NUM> may determine that the communications interface <NUM> can communicate with the body camera <NUM> using short range radio.

The hub controller may generate a characteristics request <NUM> and provide the characteristics request <NUM> to the communications interface <NUM> along with instructions to provide the characteristics request <NUM> to the radio <NUM>. The communications interface <NUM> transmits the characteristics request <NUM> to the radio <NUM> using one or more of the available communication techniques. The communications interface <NUM> receives the characteristics request <NUM> and provides the characteristics request <NUM> to the radio controller <NUM>. The radio controller <NUM> determines that the characteristics of the radio <NUM> include the location of the radio <NUM> being <NUM> Elm Street, the radio <NUM> moving at two miles per hour, the ambient light in the vicinity of the radio <NUM> being seven thousand lux, and the radio battery <NUM> having a capacity of three thousand milliamp hours with forty percent remaining. The radio controller <NUM> may generate the characteristics response <NUM> that indicates these characteristics. In some implementations, the radio controller <NUM> may access the sensor data generated by the radio sensors <NUM> in response to receiving the characteristics request <NUM>. For example, the radio controller <NUM> may determine a location of the radio <NUM>, the movement of the radio <NUM>, and/or any other similar environmental conditions of the radio <NUM>. The radio controller <NUM> may include those conditions in the characteristics response <NUM>.

The radio controller <NUM> may provide characteristics response <NUM> to the communications interface <NUM> that then provides the characteristics response <NUM> to the communications interface <NUM> of the mobile phone <NUM> using one or more of the available communication techniques. The hub controller <NUM> stores the characteristics response <NUM> in the device characteristics <NUM>. The device characteristics <NUM> then indicate that the radio <NUM> is located at <NUM> Elm Street, is moving at two miles per hour, has ambient light in the vicinity of the radio <NUM> of seven thousand lux, and has the battery <NUM> with a capacity of three thousand milliamp hours with forty percent remaining.

The hub controller <NUM> may generate a characteristics request <NUM> and provide the characteristics request <NUM> to the communications interface <NUM> along with instructions to provide the characteristics request <NUM> to the mobile phone <NUM>. The communications interface <NUM> transmits the characteristics request <NUM> to the mobile phone <NUM> using one or more of the available communication techniques. The communications interface <NUM> receives the characteristics request <NUM> and provides the characteristics request <NUM> to the mobile phone controller <NUM>. The mobile phone controller <NUM> determines that the characteristics of the mobile phone <NUM> include the location of the mobile phone <NUM> being <NUM> Elm Street, the mobile phone <NUM> facing northwest and not moving, the ambient light in the vicinity of the mobile phone <NUM> being five thousand lux, and the battery <NUM> being a two thousand milliamp battery with seventy percent remaining. The mobile phone controller <NUM> may generate the characteristics response <NUM> that indicates these characteristics. In some implementations, the mobile phone controller <NUM> may access the sensor data generated by the mobile phone sensors <NUM> in response to receiving the characteristics request <NUM>. For example, the mobile phone controller <NUM> may determine a location of the mobile phone <NUM>, the movement of the mobile phone <NUM>, and/or any other similar environmental conditions of the mobile phone <NUM>. The mobile phone controller <NUM> may include those conditions in the characteristics response <NUM>.

The mobile phone controller <NUM> may provide characteristics response <NUM> to the communications interface <NUM> that then provides the characteristics response <NUM> to the communications interface <NUM> of the laptop computer <NUM> using one or more of the available communication techniques. The hub controller <NUM> stores the characteristics response <NUM> in the device characteristics <NUM>. The device characteristics <NUM> then indicate that the mobile phone <NUM> is located at <NUM> Elm Street, is facing northwest and not moving, has ambient light in its vicinity of five thousand lux, and the battery <NUM> is a two thousand milliamp battery with seventy percent remaining.

In some implementations, the hub controller <NUM> may also generate a characteristics request for the body camera <NUM>. The communication interface <NUM> may attempt to transmit the characteristics request using short range radio, which is the available communication technique between the laptop computer <NUM> and the body camera <NUM>. Given that the mobile phone <NUM> is out of range of the body camera <NUM> using short range radio, the laptop computer <NUM> is also likely out of range of the body camera <NUM>. Because of this, the characteristics request for the body camera <NUM> sent by the laptop computer <NUM> may be received by the body camera <NUM>. In some implementations, the hub controller <NUM> may determine that because the mobile phone <NUM> is in the vicinity of the laptop computer <NUM> and because the mobile phone <NUM> is out of range of the short range radio <NUM> of the body camera <NUM>, the laptop computer <NUM> may be unable to communicate with the body camera <NUM> using short range radio. In this case, the hub controller <NUM> may not attempt to transmit a characteristics request to the body camera <NUM>.

The hub controller <NUM> determines that the device characteristics are up to date and include data that corresponds to some devices in the device identifiers <NUM>. The hub controller <NUM> may also determine that other devices in the device identifiers <NUM> may not include up to date device characteristics maybe because, for example, the laptop computer <NUM> is unable to communicate with the other devices. Based on this determination and in stage D, the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the user <NUM>, the radio <NUM>, the mobile phone <NUM>, the laptop computer <NUM>, and/or the body camera <NUM>.

In some implementations, the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the user <NUM> by identifying the devices that are likely in the vicinity of the user <NUM>. The hub controller <NUM> may determine that the radio <NUM>, the body camera <NUM>, and the mobile phone <NUM> are likely on the person of the user <NUM>. The hub controller <NUM> may determine that the radio <NUM> and the mobile phone <NUM> are in different locations based on the device characteristics <NUM>. The hub controller <NUM> may determine that the radio <NUM> is more likely to be on the person of the user <NUM> than the mobile phone <NUM> because the radio <NUM> is attached to the clothing of the user <NUM>. Based on this determination, the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the user <NUM> based on the device characteristics of the radio <NUM>.

In some implementations, the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the device that is having difficulty communicating. In this case, because the laptop computer <NUM> received indication from the mobile phone <NUM> that the body camera <NUM> is unable to communicate with the mobile phone <NUM> using short range radio, then the hub controller <NUM> may determine to determine the context of the body camera <NUM>. Doing so may help the hub controller <NUM> determine whether the hub controller <NUM> should identify an alternative way for the body camera <NUM> to communicate. In this case, the hub controller <NUM> may identify the device that is likely in the vicinity of the body camera <NUM>. The hub controller <NUM> may determine that the radio <NUM>, the body camera <NUM>, and the mobile phone <NUM> are likely on the person of the user <NUM>. Therefore, the radio <NUM> and the mobile phone <NUM> are likely in the vicinity of the body camera <NUM>. The hub controller <NUM> may determine that the radio <NUM> and the mobile phone <NUM> are in different locations based on the device characteristics <NUM>. The hub controller <NUM> may determine that the radio <NUM> is more likely to be in the vicinity of the body camera <NUM> because the radio <NUM> is more likely to be on the person of the user <NUM> than the mobile phone <NUM> because the radio <NUM> is attached to the clothing of the user <NUM>. Based on this determination, the hub controller <NUM> may instruct the context determiner <NUM> to determine the context of the body camera <NUM> based on the device characteristics of the radio <NUM>.

The context determiner <NUM> may receive the request to determine the context of the body camera <NUM> and/or the user <NUM> based on the characteristics of the radio <NUM>. In this case, the context determiner <NUM> may effectively determine the context of the radio <NUM>. The context determiner <NUM> may access data from various devices of the user <NUM> and other sources. In some implementations, the context determiner <NUM> may bypass utilizing the device characteristics of the body camera <NUM> because that data may be out of date with the communication challenges of the body camera <NUM>.

The context determiner <NUM> may access the hub sensor data generated by the hub sensors <NUM>. The context determiner <NUM> may access the device characteristics <NUM> that may include sensor data collected by the sensors such as the radio sensors <NUM> and the mobile phone sensors <NUM>. The context determiner <NUM> may also access public sources of information that may relate to news, weather, current event, public crime data, court records, and/or any other similar activity that may be affecting what is occurring in the vicinity of the radio <NUM>, the body camera <NUM>, the user <NUM>, and/or any other devices of the user <NUM>. These public sources may include websites available on the internet, public APIs, radio signals, and/or any other similar public data. The context determiner <NUM> may also access private data sources. The private data sources may include intranet data related to an employer of the user <NUM>. For example, the user <NUM> may be a police officer and the private data may relate information related to ongoing investigations, non-public crime data, and/or any other similar internal police data.

In some implementations, the connected devices may include the built-in computer of the vehicle <NUM>. With the vehicle <NUM> being a connected device, the device identifiers may include data identifying the vehicle <NUM> and the built-in computer of the vehicle <NUM>. The device characteristics may include the various characteristics of the vehicle <NUM> and the built-in computer of the vehicle <NUM>, which may also include sensor data collected from the various sensors of the vehicle <NUM> and the built-in computer of the vehicle <NUM>. These sensors may include a speedometer, a location sensor, vehicle accessory monitors that may monitor the usage of various accessories of the vehicle <NUM> (such as headlights, interior lights, air conditioning systems, heating systems, audio recording and output systems, sirens, flashing lights, radar gun, license plate reader, video recording and output systems, automatic door operators, and/or any other similar vehicle accessory), battery level monitors that measure the capacity of any batteries in the vehicle <NUM> and the remaining power left in those batteries, a voltmeter that measures the voltage those batteries, various thermometers that measure the temperature of various components of the vehicle <NUM> (for example, the temperature of various portions of the batteries, various portions of the motor, the ambient temperature, and any other similar locations), a hygrometer that measures the moisture content of the ambient air and/or the air inside any component of the vehicle <NUM>, a water sensor that may detect the presence of water in and/or around any component of the vehicle <NUM>, and/or any other similar sensors.

The context determiner <NUM> may analyze each of these sources of data to determine a likely context of the user <NUM>, the body camera <NUM>, and/or the radio <NUM>. The context may indicate the likely activity in which the user <NUM> is participating; the likely destination of the user <NUM>, the body camera <NUM>, and/or the radio <NUM>; the likely path that the user <NUM>, the body camera <NUM>, and/or the radio <NUM> will take to reach the likely destination, events that are likely occurring around the user <NUM>, the body camera <NUM>, and/or the radio <NUM>; a crime level of the location of the user <NUM>, the body camera <NUM>, and/or the radio <NUM>; and/or any other similar details related to the user <NUM>, the body camera <NUM>, and/or the radio <NUM>.

The context determiner <NUM> may analyze the hub sensor data generated by the hub sensors <NUM>, the communication statuses <NUM>, the device identifiers <NUM>, the device characteristics <NUM>, public data sources, and/or private data sources. Based on this analysis, the context determiner <NUM> may determine that the user <NUM> is likely conducting a traffic stop and that the location of the user <NUM>, the radio <NUM>, and/or the body camera <NUM> has a crime score of three out of ten. This determination may be based on image data captured by the mobile phone <NUM> and movement data generated by the sensors of the mobile phone <NUM>, the radio <NUM>, and/or the laptop computer <NUM>. This determination may also be based on the movement of the vehicle <NUM> as well as the movement of the radio <NUM> relative to the movement of the vehicle <NUM>. This determination may be based on the communications from the body camera <NUM> before the body camera <NUM> lost communications with the mobile phone <NUM>. This determination may also be based on the usage of lights and/or sirens and that usage relative to the movement of the vehicle <NUM>, the radio <NUM>, and/or the mobile phone <NUM>. This determination may also be based on analysis of public crime data and/or private data that may be related to crime and/or investigations.

The context determiner <NUM> may generate the context data that indicates the crime score of three out of ten and that the user <NUM> is likely conducting a traffic stop. The context determiner <NUM> may provide this context data to the communication status selector <NUM>. In some implementations, the context determiner <NUM> may continuously update the context of the user <NUM> and/or any of the connected devices and provide updated context data to the communication status selector <NUM>. The context determiner <NUM> may perform this continuous analysis in response to an instruction from the hub controller <NUM> and may provide updated context data to the communication status selector <NUM>. The hub controller <NUM> may later provide an instruction to the context determiner <NUM> to cease determining the context of the user <NUM> and/or any of the connected devices.

The communication status selector <NUM> may receive the context data. The communication status selector <NUM> may receive an instruction from the hub controller <NUM> to determine whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>. The instruction may also indicate that if the communication status selector <NUM> determines to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>, then determine how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>. The communication status selector <NUM> may analyze the context data, the communication statuses <NUM>, and/or the device characteristics <NUM> to determine whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> and, if so, how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>.

The process that the communication status selector <NUM> may utilize to determine whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> and, if so, how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> will be discussed in more detail with respect to <FIG>. To summarize, the communication status selector <NUM> may use one or more models and/or rules to analyze the communication statuses <NUM>, the context data, and the device characteristics <NUM>. In some implementations, the communication status selector <NUM> may select the rules and/or models based on the context data. In some implementations, the communication status selector <NUM> may also analyze the hub sensor data generated by the hub sensors <NUM>. In some implementations, the device characteristics <NUM> may include the radio sensor data generated by the radio sensors <NUM>, the mobile phone sensor data generated by the mobile phone sensors <NUM>, and the body camera sensor data generated by the body camera sensors <NUM>. The rules may specify how to compare the device functions <NUM>, the context data, the device characteristics <NUM>, and/or the hub sensor data. The rules may include various thresholds and/or ranges to compare to the device functions <NUM>, the context data, the device characteristics <NUM>, and/or the hub sensor data. Based on how those thresholds and/or ranges compare to the device functions <NUM>, the context data, the device characteristics <NUM>, and/or the hub sensor data, the rules may specify whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> and, if so, how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>. The models may be configured to receive the communication statuses <NUM>, the context data, the device characteristics <NUM>, and/or the hub sensor data and output data indicating whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> and, if so, how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>.

As illustrated in the example of <FIG>, the communication status selector <NUM> may access the communication statuses <NUM>, the context data, and the device characteristics <NUM>. The communication statuses <NUM> may indicate that the radio <NUM> may communicate using short range radio, radio frequency communications, and cellular communications. The communication statuses <NUM> may indicate that the mobile phone <NUM> may communicate using short range radio, radio frequency communications, and cellular communications. The communication statuses <NUM> may indicate that the mobile phone <NUM> may communicate using short range radio. The communication statuses <NUM> may indicate that the body camera <NUM> is unable to utilize the mobile phone <NUM> as an intermediary. The device characteristics <NUM> may indicate that the radio <NUM> is located at <NUM> Elm Street, is moving at two miles per hour, has ambient light in the vicinity of the radio <NUM> of seven thousand lux, and has the battery <NUM> with a capacity of three thousand milliamp hours with forty percent remaining. The device characteristics <NUM> that the mobile phone <NUM> is located at <NUM> Elm Street, is facing northwest and not moving, has ambient light in its vicinity of five thousand lux, and the battery <NUM> is a two thousand milliamp battery with seventy percent remaining. The context data may indicate that the user <NUM> is located in an area with a crime score of three out of ten and the user <NUM> is likely conducting a traffic stop.

The communication status selector <NUM> may analyze each of these sources of data and may apply the rules and/or models. The rules and/or models may specify whether to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM> and, if so, how to adjust the communication techniques, protocols, and/or intermediaries for the body camera <NUM>. For example, the communication status selector <NUM> may indicate that even though the body camera <NUM> is unable to communicate with the intermediary of the mobile phone <NUM>, the context of the user <NUM> does not warrant the body camera <NUM> using another device as an intermediary. The context indicates a traffic stop in a neighborhood with a three out of ten crime score, which is a low risk situation for the user <NUM>. As another example, the communication status selector <NUM> may indicate that the body camera <NUM> should utilize the mobile phone <NUM> as an intermediary. This determination may be based on the radio <NUM> having at least a threshold percentage of battery power remaining and the time period that that the user <NUM> has been conducting the traffic stop being greater than a threshold period of time.

In the example of <FIG>, the communication status selector <NUM> may analyze the communication statuses <NUM>, the context data, and the device characteristics <NUM>. The communication status selector <NUM> may determine that the radio <NUM> should act as an intermediary relay for the body camera <NUM>. In stage E, the communication status selector <NUM> may generate a relay instruction <NUM>. The relay instruction <NUM> may indicate for the radio <NUM> to be an intermediary for the body camera <NUM>. The relay instruction <NUM> may also indicate for the radio <NUM> to instruct the body camera <NUM> to use the radio <NUM> as an intermediary instead of the mobile phone <NUM>. The communication status selector <NUM> may provide the relay instruction <NUM> to the communication interface <NUM> for output to the radio <NUM>. The communication interface <NUM> may receive the relay instruction <NUM>. The radio controller <NUM> may store the relay status <NUM> in the communication status <NUM>.

The radio controller <NUM> may generate instructions for the body camera <NUM>. The instructions may indicate to utilize the radio <NUM> as an intermediary. The body camera <NUM> may receive the instructions and store intermediary instructions <NUM> in the communication status <NUM>. The intermediary instructions <NUM> may indicate to transmit body camera data from the body camera <NUM> to the radio <NUM> and to transmit data indicating where the new intermediary should transmit the data. In this case, the body camera <NUM> may transmit instructions to the radio <NUM> to transmit the body camera data to the mobile phone <NUM>. The instructions may also include a destination for the body camera data where the mobile phone <NUM> will transmit the data. In some implementations, the body camera <NUM> may transmit instructions that indicate a destination that does not utilize a previous intermediary. For example, the instructions may indicate for the radio <NUM> to transmit body camera data to the laptop computer <NUM> instead of from the mobile phone <NUM> to the laptop computer <NUM>.

The communication status selector <NUM> may also indicate to the communication interface <NUM> to output the relay instructions <NUM> to the mobile phone <NUM>. The communication interface <NUM> may receive the relay instruction <NUM>. The mobile phone controller <NUM> may store the relay status <NUM> in the communication status <NUM>.

In some implementations, the relay instruction <NUM> may include information related to when the relay instruction <NUM> will expire. In some cases, the relay instruction <NUM> may be in place until the communication status selector <NUM> generates an relay instruction that overrides the relay instruction <NUM>. In some cases, the relay instruction <NUM> may include a time limit. For example, the relay instruction <NUM> may indicate that the body camera <NUM> should use the radio <NUM> as an intermediary for a period of ten minutes. In some cases, the relay instruction <NUM> may indicate a condition that should be met to cease following the relay instruction <NUM>. For example, the condition may indicate that if the battery <NUM> drops below a threshold percentage, then the radio <NUM> should cease operating as an intermediary.

After instructing the various devices on updating the intermediary for the body camera <NUM>, the body camera <NUM> may collect new data. The body camera controller <NUM> may instruct the communications interface <NUM> to transmit the new body camera data and/or transmit body camera data buffered on the body camera <NUM> while the mobile phone <NUM> was unavailable to the radio <NUM>. The body camera controller <NUM> may include destination data with the body camera data. The destination data may indicate where the radio <NUM> should forward the body camera data.

In stage F, the body camera controller <NUM> generates the body camera data packet <NUM> that includes the body camera data and any additional data such as the destination data. The body camera controller <NUM> provides the body camera data packet <NUM> to the communications interface <NUM> that transmits the body camera data packet <NUM> to the communications interface <NUM> of the radio <NUM>. The communications interface <NUM> uses short range radio <NUM> to transmit the body camera data packet <NUM> to the communications interface <NUM> of the radio <NUM>.

The radio controller <NUM> analyzes the body camera data packet <NUM>. In the case of the body camera data packet <NUM> including destination instructions, the radio controller <NUM> may instruct the communications interface <NUM> to transmit the body camera data packet to the requested destination. In the case of the body camera data packet <NUM> not including destination instructions, the radio controller <NUM> may determine the destination of the body camera data packet <NUM> by accessing the communication status <NUM> and the relay status <NUM> that may indicate the destination of packets received from the body camera <NUM>.

In stage G, the radio controller <NUM> determines that the destination of the body camera data packet <NUM> is the mobile phone <NUM>. The radio controller <NUM> may provide a forwarded body camera data packet <NUM> to the communications interface <NUM>. The radio controller <NUM> provides instructions to the communications interface <NUM> to transmit the forwarded body camera data packet <NUM> to the mobile phone <NUM>. The communications interface <NUM> may determine the communications technique to use to transmit the forwarded body camera data packet <NUM> to the mobile phone <NUM>. In this example, the communications interface <NUM> may use the radio frequency communications <NUM> or the cellular communications <NUM>. The communications interface <NUM> transmits the forwarded body camera data packet <NUM> to the communications interface <NUM> of the mobile phone <NUM>. The mobile phone <NUM> may be expecting the forwarded body camera data packet <NUM> and other forwarded body camera data packets because of the relay status <NUM> in the communication status <NUM> indicating that the radio <NUM> is acting as an intermediary. The mobile phone controller <NUM> may perform any action on the forwarded body camera data packet <NUM> that the mobile phone controller <NUM> would have performed had the body camera <NUM> transmitted the body camera data directly to the mobile phone <NUM>. This action may include analyzing the body camera data to determine whether to perform any additional actions such as calling for a backup officer, alerting a dispatcher, storing the data in a manner compliant with any regulations, and/or any other similar action.

<FIG> illustrates an example server that is configured to manage the communication functions of various devices. The device <NUM> may be any type of computing device that is configured to communicate with other computing devices. The device <NUM> may communicate with other computing devices using a wide area network, a local area network, the internet, a wired connection, a wireless connection, and/or any other type of network or connection. The wireless connections may include Wi-Fi, short-range radio, infrared, and/or any other wireless connection. The device <NUM> may be similar to the laptop computer <NUM> of <FIG>. Some of the components of the device <NUM> may be implemented in a single computing device or distributed over multiple computing devices. Some of the components may be in the form of virtual machines or software containers that are hosted in a cloud in communication with disaggregated storage devices.

The device <NUM> may include a communication interface <NUM>, one or more processors <NUM>, memory <NUM>, and hardware <NUM>. The communication interface <NUM> may include communication components that enable the device <NUM> to transmit data and receive data from other devices and networks. In some implementations, the communication interface <NUM> may be configured to communicate over a wide area network, a local area network, the internet, a wired connection, a wireless connection, and/or any other type of network or connection. The wireless connections may include Wi-Fi, short-range radio, infrared, and/or any other wireless connection.

The hardware <NUM> may include additional user interface, data communication, or data storage hardware. For example, the user interfaces may include a data output device (e.g., visual display, audio speakers), and one or more data input devices. The data input devices may include, but are not limited to, combinations of one or more of keypads, keyboards, mouse devices, touch screens that accept gestures, microphones, voice or speech recognition devices, and any other suitable devices.

The memory <NUM> may be implemented using computer-readable media, such as computer storage media. Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), high-definition multimedia/data storage disks, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism.

The one or more processors <NUM> may implement a hub controller <NUM>. The hub controller <NUM> may be similar to the hub controller <NUM> of <FIG>. The hub controller <NUM> may be configured to perform multiple tasks. Those tasks may include managing the components of the device <NUM>. For example, the hub controller <NUM> may instruct the communications interface <NUM> what type of connection to use to communicate with other devices. The hub controller <NUM> may instruct the communications interface <NUM> to communicate with a first device using short range radio and communicate with a second device using a cellular network. The tasks of the hub controller <NUM> may also include determining whether the device <NUM> should operate as the hub. The hub may be the device that provides instructions to other devices regarding what communication protocols a device should use and whether a device should communicate with an intermediary device. If the device <NUM> is not operating as the hub, then the device <NUM> may receive instructions regarding what communication protocols a device should use and whether a device should communicate with an intermediary device.

The hub may change between various devices. There may be several devices that are capable of operating as the hub. Each user may have a group of devices with which the user interacts. These devices may make up the personal area network of the user. For example, a police officer may have a radio, body camera, mobile phone, laptop computer, dashboard camera, storage device, watch, tablet, a built-in computer of a vehicle, and/or any other similar device. Only some of these devices may be configured to operate as a hub. The mobile phone, vehicle computer, and/or laptop computer may be capable of operating as the hub. Each of these devices may include a hub controller that is similar to the hub controller <NUM>.

To select the hub, each of the devices may have a series of rules and a hierarchy to determine which device should be the hub and/or determine which devices should not be the hub. The rules may relate to whether each device can detect other devices. The rules may also relate to the characteristics of each device such as the battery capacity. An example rule may indicate that if the hub controller <NUM> determines that the device <NUM> can communicate with each of the devices of the user, then the hub should be the device <NUM> unless the battery capacity is below thirty percent. If the battery capacity is below thirty percent, then the hub should be the built-in computer of the vehicle. Another example rule may indicate that if the hub controller <NUM> determines that the device <NUM> cannot communicate with each of the devices of the user, then the hub should be the built-in computer of the vehicle.

If the device <NUM> is operating as the hub, then the device <NUM> may operate as a gateway for communications between the devices and another network. The device <NUM> or another device acting as the hub may operate as a gateway according to instructions from the function selector <NUM>. For example, the hub controller <NUM> may instruct a connected device to cease communicating over Wi-Fi and a cellular network and communicate with the device <NUM> using short range radio. The communications interface <NUM> may receive the communications from the connected device over short range radio and output the communications using another communications technique to the recipient. Similarly, the communications interface <NUM> may receive communications intended for the connected device and provide those communications to the connected device over short-range radio.

In some implementations, the hub controller <NUM> may determine that a device is out of range for communicating with the device <NUM> using short range radio. In this case, the hub controller <NUM> may identify another device that can act as an intermediary for the out of range device to communicate with. The intermediary can forward the data from the out of range device to the device <NUM>.

The status of whether the device <NUM> is operating as the hub may be located in the hub status <NUM>. The hub status <NUM> may be located in the memory <NUM> of the device <NUM>. The hub status <NUM> may include data indicating whether the device <NUM> is operating as the hub. If the status data indicates that the device <NUM> is not operating as the hub, then the hub status <NUM> may include data identifying the device operating as the hub.

The device <NUM> may include hub sensors <NUM>. The hub sensors <NUM> may be similar to the hub sensors <NUM> of <FIG>. The hub sensors <NUM> may include an accelerometer, a gyroscope, a GPS receiver, a barometer, an ambient light sensor, a compass, a gravity sensor, a proximity sensor, a magnetometer, image sensor, video sensor, microphone, hygrometer, water sensor, solar flux sensor, ultraviolet light detector, and/or any other similar sensors. The hub sensors <NUM> may continuously generate sensors data, generate sensor data in response to an instruction from the hub controller <NUM>, generate sensor data in response to an instruction from another device acting as the hub, generate sensor data periodically, generate sensor data in response to an event such as other sensor data satisfying a threshold, and/or generate sensor data in any other similar instance.

The memory <NUM> may include the connected devices storage <NUM>. The connected devices storage <NUM> may be similar to the connected devices storage <NUM> of <FIG>. In the case of the device <NUM> acting as the hub, the device <NUM> may be managing the connected devices. In the case of the device <NUM> not acting as the hub, the device <NUM> may store data related to the devices that the device <NUM> previously managed when the device <NUM> was acting as the hub. The connected devices storage <NUM> may also include instructions received from the hub. These instructions may include how and when to use various communication techniques of the device <NUM> and whether to communicate with any device as an intermediary.

The connected devices storage <NUM> may include the communication statuses <NUM>, the device identifiers <NUM>, and the device characteristics <NUM> that may be similar to the communication statuses <NUM>, the device identifiers <NUM>, and the device characteristics <NUM> of <FIG>, respectively. The device identifiers <NUM> may store an identifier of the devices that the device <NUM> is configured to manage and identifiers of other devices that may be designated as the hub. The device <NUM> may mange devices that may later be designated as the hub.

The device characteristics <NUM> may store data related to the devices included in the device identifiers <NUM>. The device characteristics <NUM> may include data related to features or qualities of the connected devices that may change over time. This change may occur because of usage of the device, movement of the device, environmental changes, changes in nearby devices, and/or any other similar change. In some implementations, the device characteristics <NUM> may include sensor data generated by sensors of the connected devices. In some implementations, the connected devices may provide the device characteristics periodically, in response to a request from the device <NUM>, in response to an event, and/or any other similar reason. In some implementations, the device characteristics <NUM> may be unrelated to changes in the device that may occur because of hardware and/or software changes. In some implementations, the device characteristics <NUM> may indicate a field of view of the cameras, a sensitivity of a microphone, any low light capabilities of the cameras, noise filtering capabilities of the microphone, and/or any other similar feature.

The communication statuses <NUM> may store data related to the communication capabilities of the devices included in the device identifiers <NUM>. The communication statuses <NUM> may be similar to the communication statuses <NUM> of <FIG>. The device functions <NUM> may include data related to the communication capabilities of the connected devices that may not change without a modification or addition to the hardware and/or software of the device. The communication statuses <NUM> may be related to the types of communication modules that the devices have, whether any device has or is currently using or acting as an intermediary, power consumption information for each of the communication techniques of a device, and/or any other similar information related to the communication capabilities of the devices.

The communication statuses <NUM> may include instructions that other devices have received related to what communication capabilities to utilize, whether to use an intermediary, and/or whether to act as an intermediary. The communication statuses <NUM> may include data indicating when some of those instructions may expire. Some instructions may not expire. The instructions that may expire may indicate a time limit, a battery charging threshold, a context requirement, and/or any other similar requirement.

The memory <NUM> may include user characteristics <NUM>. The user characteristics <NUM> may include data that describe the type of user who is using the device <NUM> and the connected devices. The type of user may include an occupation of the user, demographic information of the user, an employer of the user, and/or any other similar information. In some implementations, the user may provide the user characteristics <NUM> to the device <NUM>. The user may provide the user characteristics <NUM> in response to prompts from the device <NUM>.

The one or more processors <NUM> may implement a context determiner <NUM>. The context determiner <NUM> may be similar to the context determiner <NUM> of <FIG>. The context determiner <NUM> may be configured to determine a context of the device <NUM> and/or any of the connected devices. The context determiner <NUM> may be configured to analyze the sensor data generated by the hub sensors <NUM> and/or sensor data generated by sensors of any of the connected devices. The context determiner <NUM> may also be configured to determine events that may be occurring near or around the device <NUM> and/or connected devices. The context determiner <NUM> may determine events by analyzing news sources, websites, internet locations with current event information, first responder dispatch feeds, and/or any other similar information source. These sources may include public sources and private sources. In some implementations, the context determiner <NUM> may access communications between the device <NUM> and other devices and other communications between the user of the device <NUM> and other users. The context determiner <NUM> may analyze these various sources of information and determine the context of the device <NUM> and/or any connected device.

In some implementations, the context determiner <NUM> may be configured to select a context from a predetermined list of contexts. This list of contexts may be dependent on the user of the device <NUM> or the user of any of the connected devices. For example, the list of contexts may be based on the employer of the user. If the user of the device is a police officer, then the list of contexts may be situations in which the user may be involved during the course of performing duties. The list of contexts may be dependent on the position of the user. For example, a list of contexts may be different for a police supervisor than a police officer. In some implementations, the list of contexts may be dependent on the equipment issued to the user. For example, some members of the police may receive marked police vehicles and others may unmarked vehicles. These different types of vehicles may include different types of equipment such as different lights and sirens. The list of contexts for these different groups may depend on the differences between these vehicles.

The one or more processors <NUM> may implement a communication status selector <NUM>. The communication status selector <NUM> may be similar to the communication status selector <NUM> of <FIG>. The communication status selector <NUM> may be configured to analyze the communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the context from the context determiner <NUM>, the user characteristics <NUM>, and/or any other similar data to determine whether change the communication techniques and/or intermediaries for any of the connected devices.

The communication status selector <NUM> may use the communication status selection models <NUM> and/or the communication status selection rules <NUM> to analyze these data sources. The communication status selection models <NUM> and/or the communication status selection rules <NUM> may output data identifying one or more communication techniques that one or more of the connected devices should use, whether a device should use or change intermediaries, when a device should use or change intermediaries, and/or any other similar communication adjustment. The communication status selector <NUM> may output those instructions related to these determinations to the corresponding connected device.

The communication status selection rules <NUM> may include various thresholds, ranges, hierarchies, and/or any other similar comparison tools to determine how the communication interfaces of the connected devices should operate. An example rule may specify that if the user is conducting a traffic stop and the crime score for the location of the stop is greater than a threshold, such as five out of ten, then any devices that have to not have the ability to transmit data to the device <NUM> should utilize an intermediary. The rule may indicate that is more than one intermediary is available, then the one with the greater battery capacity remaining should be the intermediary until the battery of the selected intermediary is drained to less than the other available intermediaries. Another example rule may specify that if the user is conducting a traffic stop and the crime score for the location of the traffic stop is less than a threshold, then devices that have lost the ability to transmit data to the device <NUM> may utilize an intermediary if the devices that need an intermediary have a battery capacity above fifty percent. If the crime score is less than three out of ten, then rule may specify bypass utilizing an intermediary for the devices that have lost the ability to transmit data to the device <NUM>.

As another example, a rule may specify that if the user is within a threshold distance of a gunshot that occurred in the last fifteen minutes, then devices that have lost connectivity with the device <NUM> should utilize an intermediary. This rule may not use battery capacity as a factor. This rule may further specify that if the user manually deactivates a device, then that device should not be reactivated even if the device would automatically be communicating with the device <NUM> through an intermediary based on the current context.

Another example rule may be related to device <NUM> acting as a communication hub for the connected devices. The rule may state that the connected devices should communicate with the device <NUM> using short range radio and the device <NUM> may transmit communications from the connected devices and receive communications for the connected devices. The device <NUM> may use higher power communications such as cellular communications. In other words, the device <NUM> acts as a communication hub for the connected devices because the device <NUM> communicates on behalf of the connected devices. This rule may indicate that each of the connected devices should be in short range radio range of the device <NUM> to be applicable.

In some implementations, this example rule may also include references to the battery power of the connected devices and/or the device <NUM>. For example, the rule may not apply if the battery capacity of the connected device is above sixty percent. As another example, the rule may not apply if the battery capacity of the device <NUM> is below forty percent. As another example, the rule may apply if the device <NUM> has a hardwired power supply. As another example, the rule may not apply if the signal strength of the device is below a threshold signal strength. As another example, the rule may indicate that one of the connected devices or the device <NUM> should operate as the communication hub if one of the connected devices or the device <NUM> has a signal strength that is above a threshold and the other devices have a signal strength that is below a threshold. This rule may be valid for devices that are capable of communicating with additional devices that the ones that the devices are intended to communicate with.

The communication status selection models <NUM> may be configured to receive the communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the context data from the context determiner <NUM>, the user characteristics <NUM>, and/or any other similar data. The communication status models <NUM> may output data which connected devices should utilize an intermediary and/or under what conditions those devices should cease to utilize the intermediary.

The communication status models <NUM> may be trained using machine learning and the historical data <NUM>. The historical data <NUM> may include previous sensor data collected from the hub sensors <NUM>, previous sensor data collected from the sensors of the connected devices, previous contexts, previous user characteristics, and/or any other similar data. The historical data <NUM> may also include data related to instances when the device <NUM> or another hub may have been managing the communication interfaces of the connected devices and/or periods when the communication capabilities of the connected devices may be limited. The historical data <NUM> may also include data related to how the user adjusted the communication interfaces in an attempt to move data from one device to another.

The one or more processors <NUM> may implement the model trainer <NUM>. The model trainer <NUM> may be configured to analyze the historical data <NUM>. The model trainer <NUM> may train the communication status selection models <NUM> using the historical data <NUM> and machine learning. The model trainer <NUM> may generate various data samples based on the historical data <NUM>. Each data sample may indicate the state of the previous sensor data collected from the hub sensors, previous sensor data collected from the sensors of the connected devices, previous contexts, previous user characteristics, and/or any other similar data at a point in time. Each data sample may also include a label that indicates the state of the various communication interfaces and/or any intermediaries of the connected devices and/or how the devices were communicating with each other and/or with other devices and networks. The resulting models may be able to receive communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the context from the context determiner <NUM>, the user characteristics <NUM>, and/or any other similar data and output data indicating which whether a connected device should utilize an intermediary, the identity of that intermediary, and, if utilizing the intermediary, when that device should cease utilizing the intermediary. Other recommendations may include how the connected devices should communicate with the device <NUM> and/or with other devices, which device should operate as the hub, and/or any other similar recommendation.

In some implementations, the communication status selector <NUM> may implement the recommendation. The model trainer <NUM> may continue to collect the historical data <NUM> as the device <NUM> operates and the connected devices operate. In this case, the model trainer <NUM> may update the historical data <NUM> and retrain the function selection models <NUM> using the updated historical data <NUM> and machine learning. The communication status selector <NUM> may utilize the updated function selection models <NUM> to analyze the communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the context from the context determiner <NUM>, the user characteristics <NUM>, and/or any other similar data that may have updated since the last analysis.

In some implementations, the model trainer <NUM> may train the communication status selection models <NUM> without context data. In this case, the data used by the context determiner <NUM> may be part of the data samples. In this way, the resulting models may be able to receive communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the user characteristics <NUM>, and/or any other similar data and output data indicating which whether a connected device should utilize an intermediary, the identity of that intermediary, and, if utilizing the intermediary, when that device should cease utilizing the intermediary. Other recommendations may include how the connected devices should communicate with the device <NUM> and/or with other devices, which device should operate as the hub, and/or any other similar recommendation.

The model trainer <NUM> may also be configured to analyze the historical data <NUM> and generate the communication status selection rules <NUM>. The model trainer <NUM> may analyze the historical data <NUM> for patterns to identify ranges and threshold and other similar comparison techniques to use to analyze the communication statuses <NUM>, the device characteristics <NUM>, the sensor data from the hub sensors <NUM>, the sensor data from the connected devices, the context from the context determiner <NUM>, the user characteristics <NUM>, and/or any other similar data. In some implementations, the model trainer <NUM> may receive goals from a user that the model trainer <NUM> should try to achieve when generating the communication status selection rules <NUM>. For example, the goals may include preserving battery life, ensuring audio and video is captured in areas with crime rates above a threshold, and/or any other similar goal. In addition to relating to communication interfaces, the communication status selection rules <NUM> may be related to selecting a device for a hub. In some implementations, the device <NUM> may also receive communication status selection rules <NUM> from a user. These rules may also be related to specific goals of the user and may be specifically tailored for particular devices.

<FIG> is a flowchart of an example process <NUM> for managing the communication functions of various devices. In general, the process <NUM> determines the communication capabilities of various devices. The process <NUM> determines that one of those devices is unable to communicate with some of the other devices. The process <NUM> determines the context of one or more of the various devices. Based on the context, the process <NUM> determines whether to implement an alternate communication processes for the device that is unable to communicate with some of the other devices. The process <NUM> will be described as being performed by the laptop computer <NUM> of <FIG> and will include references to other components in <FIG>. The process <NUM> may also be performed by the device <NUM> of <FIG>.

The laptop computer <NUM> receives data indicating that a second computing device is configured to communicate using a first communication protocol (<NUM>). For example, the second computing device may be the body camera <NUM> and the first communication protocol may be a short range radio.

The laptop computer <NUM> receives data indicating that a third computing device is configured to communicate using the first communication protocol and a second communication protocol (<NUM>). For example, the third computing device may be a radio <NUM>. The second communication protocol may be cellular communications.

The laptop computer <NUM> determines that the second computing device is unable to communicate with a fourth computing device (<NUM>). In some implementations, the fourth computing device may be the mobile phone <NUM>. In some implementations, the fourth computing device and the laptop computer <NUM> may be the same device. In some implementations, the laptop computer <NUM> may receive, from the fourth computing device, data indicating that the fourth computing device is unable to communicate with the second computing device. The fourth computing device may be unable to communicate with the second computing device using the first communication protocol and the second computing device may be unable to communicate with the fourth computing device using any other communication protocols. The laptop computer <NUM> may determine that the second computing device is unable to communicate with a fourth computing device based on the data indicating that the fourth computing device is unable to communicate with the second computing device.

The laptop computer <NUM> determines a context of a user of the second computing device (<NUM>). In some implementations, the laptop computer <NUM> determines the context of the laptop computer <NUM>, the second computing device, the third computing device, and/or the fourth computing device. In some instances, these devices may not be in the vicinity of the user. The context may be based on sensor data collected from any of the devices, sensor data generate by the sensor of the laptop computer <NUM>, data from public sources, data from private sources, functions of the devices, battery capacity of the devices, remaining battery capacity of the devices, and/or any other similar data source.

Based on determining that the second computing device is unable to communicate with the fourth computing device and the context of the user of the second computing device, the laptop computer <NUM> generates an instruction for the third computing device to communicate with the second computing device using the first communication protocol (<NUM>). In some implementations, the laptop computer <NUM> generates the instructions based on the context of the laptop computer <NUM>, the second computing device, the third computing device, and/or the fourth computing device. In some implementations, the instruction includes a time limit for the third computing device to communicate with the second computing device using the first communication protocol.

In some implementations, the laptop computer <NUM> may bypass generating the instruction for the third computing device to communicate with the second computing device using the first communication protocol. This may be the case even if the second computing device is unable to communicate with the fourth computing device. The laptop computer <NUM> may make this determination if the context does not warrant the third computing device to communicate with the second computing device using the first communication protocol. This may be because the situation that the user is in is below a threshold level of danger.

Claim 1:
A computer-implemented method (<NUM>), comprising
receiving, by a first computing device (<NUM>), data indicating that a second computing device (<NUM>) is configured to communicate using a first communication protocol;
receiving, by the first computing device (<NUM>), data indicating that a third computing device (<NUM>) is configured to communicate using the first communication protocol and a second communication protocol; characterized in that the method further comprises
determining, by the first computing device (<NUM>), that the second computing device (<NUM>) is unable to communicate with a fourth computing device (<NUM>);
determining, by the first computing device (<NUM>), a context of a user (<NUM>) of the second computing device (<NUM>);
based on determining that the second computing device (<NUM>) is unable to communicate with the fourth computing device (<NUM>) and the context of the user (<NUM>) of the second computing device (<NUM>), generating, by the first computing device (<NUM>), an instruction for the third computing device (<NUM>) to communicate with the second computing device (<NUM>) using the first communication protocol; and
providing, for output by the first computing device (<NUM>) and to the third computing device (<NUM>), the instruction for the third computing device (<NUM>) to communicate with the second computing device (<NUM>) using the first communication protocol.