Patent Application
20230162852
The present invention is in the field of communication, particularly, communication configured for uploading data to the cloud.
A hotspot is a physical location where people may obtain Internet access, typically using Wi-Fi technology, via a wireless local-area network (WLAN) using a router connected to an Internet service provider.
Hotspots may be public hotspots, e.g. created by a business for use by customers to provide Internet access, controlled to some degree by the venue. In its simplest form, venues that have broadband Internet access can create public wireless access by configuring an access point (AP), in conjunction with a router to connect the AP to the Internet.
A private hotspot, often called tethering, may be configured on a smartphone or tablet that has a network data plan, to allow Internet access to other devices via Bluetooth pairing, or through the RNDIS protocol over USB, or even when both the hotspot device and the device(s) accessing it are connected to the same Wi-Fi network but one which does not provide Internet access. Similarly, a Bluetooth or USB OTG can be used by a mobile device to provide Internet access via Wi-Fi instead of a mobile network, to a device that itself has neither Wi-Fi nor mobile network capability.
Acknowledgement of the above references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter.
In accordance with one aspect of the subject matter of the present application, there is provided a Dynamic Connectivity System (DCS) comprising:
wherein said access point is configured for termination after an idle period of a predetermined idle time, and wherein said patient module is configured for at least the following:
The data uploaded to the network via said gateway device may be at least any one of the following:
The term ‘idle period’ should be understood herein in the context of the present application as a period of time in which no such data is transferred to the network via said gateway device.
The DCS may constitute part of a larger system comprising an HCP module, a gateway module comprising the gateway device, a medical kit comprising the patient module, and the cloud.
The DCS may be configured for providing communication between an in-vivo device (e.g. capsule endoscopy, pacemakers etc.) and the network. The patient module may be a wearable device configured for receiving data from said in-vivo device and said gateway device may be a mobile device such as a smartphone, tablet etc. In accordance with a specific example, the in-vivo device may be an endoscopy capsule, and the wearable device may be an adhesive patch (stick-to-skin solution), comprising the required communication components to send/receive data to/from the in-vivo device and for uploading data obtained from the in-vivo device to the cloud via said gateway device.
The gateway device may be configured for granting the patient module with access to the internet either by connecting it to a router which, in turn, provides access to the internet, or directly to the internet via a data plan (i.e. tethering). Under the above configuration, the gateway device constitutes an access point (AP) while the patient module constitutes the client.
Communication between the patient module and the gateway device may be performed using one or more communication channels, e.g. WiFi, Bluetooth, Bluetooth Low Energy (BLE) etc.
The communication between the patient module and the gateway device may facilitate at least the following:
In accordance with a specific example, the WiFi channel may be used for transferring of raw/processed data, while one or more BLE channels may be used for signaling and control. It should be noted that both the WiFi and BLE may operate at similar broadcasting frequencies but may have different bandwidths and occupy different timeslots during communication.
The predetermined idle time of the gateway device may be in the range of 60-100 seconds, more particularly between 75 and 85 seconds, and even more particularly, around 90 second. The pinging signal may have a period in the range of 40 to 80 seconds, more particularly 50 to 70 seconds, and even more particularly, around 60 seconds.
The patient module may be configured for chunking the data into chunks before transferring the data to the gateway device. The patient module may be configured for uploading these data chunks using said gateway device in predetermined time intervals, referred to herein as Data Upload time intervals or DU time intervals, corresponding to the time required for obtaining such chunks of data. The DU time intervals may be greater than said idle period, for example, in the range of 200 to 400 seconds, more particularly 250 to 350 seconds, and even more particularly, around 300 seconds. The data chunks may range between 10 MB and 100 MB, and, in accordance with a particular example, be between 40 MB and 60 MB;
The patient module may be configured to upload to the network, via said gateway device, data that has accumulated thereon during said DU time interval, wherein, within said DU time interval, the patient module may be configured for sending the pinging signal in order to prevent the gateway device from terminating owing to an extensive idle period.
The configuration may be such that during data transfer from the patient module to the network via the gateway device, the pinging signal to the gateway device is disabled. In other words, the pinging signal may be used only during an idle period of said gateway device.
The patient module may also be configured for sending a secondary pinging signal to the gateway device in order to verify that the gateway device is active. This secondary pinging signal may be sent periodically, with a period considerably shorter than said pinging signal, for example, 5, 10 or 15 seconds and may also use the BLE channel.
In accordance with the subject matter of the present application, the DCS may also be configured for accommodating communication with a data device configured for displaying and or further processing raw/processed data and/or information based thereon.
In accordance with one example, the data device may be configured for communicating directly with the patient module. Under this configuration, when a data device requests access to the patient module, the latter may be configured for switching from a client mode to an AP mode, providing access to the data device which, in turn, functions as the client. Hereinafter, this mode of operation will be referred herein as Real Time View (RTV). It should be noted that under this configuration, the patient module may continuously advertise its presence via a second BLE channel different than the first BLE channel in order to be discoverable by the data device.
The patient module may be configured for prioritizing the data device over uploading data to the network via said gateway device. In addition, when the RTV mode is active, uploading of data to the gateway device may be paused. However, the patient module may still be configured for prioritizing maintaining the hotspot alive over the RTV mode, wherein it may periodically switch back to a client mode in order to continue sending the pinging signal, after which it may revert to serving as the AP for the data device.
In accordance with another example, the data device may be configured for communication with the cloud and downloading therefrom the raw/processed data previously uploaded by the patient module. This mode of operation will be referred hereinafter as a Near Real Time View (NRTV).
Under this mode of operation, once a request by the data device is provided to the cloud it may also notify the patient module about said request, wherein the patient module may switch to transferring data to the gateway device continuously, rather than chunking the data, thereby improving the NRTV.
The DCS of the present application provides a seamless and dynamic switching between two operational modes: data upload to the cloud via the gateway device and data transfer to an HCP device. In addition, in each of the operational modes the data is transferred over a different network and under a different configuration, thereby enhancing data safety and creates a buffer between the HCP device and the patient's data uploaded to the cloud.
In accordance with another aspect of the subject matter of the present application there is provided a Dynamic Connectivity System (DCS) comprising a patient module configured for communication with an in-vivo device and for receiving data therefrom, said patient module being configured for communicating in at least the following modes:
and wherein said patient module is configured for dynamically switching between the client mode and the AP mode.
The DCS system may operate in the client mode by default, and configured for switching to the AP mode upon request from the data device. As in the previous aspect of the subject matter of the present application, the patient module is configured for prioritizing the AP mode over the client mode when access is requested by the data device. However, the patient module may prioritize keeping the gateway device's hotspot alive over the AP mode.
All features previously described in connection with the first aspect of the subject matter of the present application, e.g. the use of BLE channels for communication with the gateway device and the data device, advertising the presence of the patient module, sending a pinging signal etc. may be implemented in the current aspect mutatis mutandis.
In order to better understand the subject matter that is disclosed herein and to exemplify how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn accurately or to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity, or several physical components may be included in one functional block or element. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.
Attention is first drawn to
In the following example, the comprehensive system is shown as part of a capsule endoscopy procedure, wherein the medical kit 10 comprises a swallowable endoscopy capsule 50 constituting the in-vivo device and an adhesive patch 60 constituting a patient module, configured for communication therebetween using an uplink channel 62 and a downlink channel 64.
Attention is now drawn to
The patch 60 is configured for uploading data to the cloud 40 either by direct communication 84 with the router 80, or via a hotspot established by a mobile device 70. The patch 60 is configured for communicating with the mobile device 70 via secure Wi-Fi 72 and via a first Bluetooth Low Energy (BLE) channel 74. Under this configuration, the mobile device 70 serves as an Access Point (AP) while the patch 60 functions as the client. The WiFi channel 72 is used in order to transfer acquired/processed data to the mobile device 70 while the BLE channel 74 is used for providing the mobile device 70 with notification and instructions related to the CE procedure, as well as a control signal checking that the mobile device 70 is active, in range etc.
It is noted that when the mobile device 70 establishes a hotspot, it connects the patch 60 to the cloud 40 via a cell antenna 100 (indicated by connections 102 and 94), or to the router 80 via connection 82.
When the patch 60 is connected to the cloud 40 via the mobile device 70 and cell antenna 100, the mobile device 70 is configured for terminating the hotspot within ninety seconds if no data is provided thereto by the patch 60. On the other hand, the patch 60 is configured for uploading data to the cloud 40 in chunks of predetermined size, and until such a data chunk is accumulated, the patch 60 will not transmit it to the mobile device 70.
This can create a situation in which the mobile device's hotspot remains idle for over ninety seconds, causing termination of the hotspot. Thereafter, if the patch 60 is required to upload data there will be a need to reestablish the hotspot, causing a delay in communication. In order to overcome this deficiency, the DCS is provided, according to which the patch 60 is configured for periodically sending a pinging signal to the mobile device 70, with a time period shorter than ninety seconds (in this example—sixty seconds). Thus, even if data is not being uploaded to the cloud 40 via the hotspot during the entire idle period, the hotspot will remain active and the hotspot will not be terminated.
In accordance with a particular example, the patch 60 is also configured for sending a secondary pinging signal via the first BLE channel 74 every five to fifteen seconds, configured for verifying that the mobile device 70 is active (hadn't shut down, is in range etc.).
Turning now to
Under this configuration, the patch 60 continuously advertises its presence, via a second BLE channel 112, in order to be discoverable by the HCP device 110. When the HCP desires to view the data, the tablet 110 requests access from the patch 60 via BLE connection 112. The patch 60 then verifies that the tablet 110 is authorized to access (in order to prevent unauthorized parties from viewing a patient's data), and grants access.
When the patch 60 receives such a request, it prioritizes the establishment of such a connection with the tablet 110 and switches to functioning as an AP while the tablet 110 functions as a client. In this case, once the connection 112 is established, the patch 60 halts its connection 72 with the mobile device's hotspot, and the HCP can have a Real Time View (RTV) of the data.
However, the patch 60 still prioritizes maintaining the hotspot active over the RTV, wherein after sixty seconds of RTV, the patch 60 will temporarily terminate the connection 112, switch back to functioning as a client for the mobile device 70 and send the pinging signal to maintain the channel 72 open. Thereafter, the patch 60 can switch back to the connection 112 and continue RTV with the HCP tablet 110.
With further reference to
Those skilled in the art to which this invention pertains will readily appreciate that numerous changes, variations, and modifications can be made without departing from the scope of the invention, mutatis mutandis.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IL2021/050560 | 5/13/2021 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63026139 | May 2020 | US |
