Flow-based Dynamic Connection System

Abstract

The dynamic connectivity system (DCS) comprises a patient module configured for communication with an in-vivo device and for communication with at least one additional device, the DCS further comprising a gateway device configured to provide an access point for the patient module to access a network, the access point being configured for termination after an idle period of a predetermined idle time, the patient module being configured to upload data to the network via a mobile device during non-idle periods of the gateway device, the patient module also being configured to send a ping signal to the mobile device during the idle period that is different from the data and has a duration shorter than the predetermined idle time, thereby interrupting the idle period and preventing termination of the access point.

Description

Technical Field

[0001] The present invention relates to the field of communications, and more particularly to communications configured to upload data to a cloud.

Background Art

[0002] A hotspot is a physical location where people can access the Internet via a Wireless Local Area Network (WLAN) that typically uses Wi-Fi technology and a router connected to an Internet service provider.

[0003] A hotspot may be, for example, a public hotspot created by a company for customers to use, providing a certain degree of controlled Internet access at that location. In its simplest form, a location with broadband Internet access can provide public wireless access by configuring an Access Point (AP) together with a router that connects the AP to the Internet.

[0004] Often, a private hotspot, called tethering, can be configured on a smartphone or tablet with a network data plan to enable Internet access to other devices, even when both the hotspot device and the device accessing it are connected to the same Wi-Fi network, but one of them is not providing Internet access. This can be done via Bluetooth® pairing, or through the RNDIS protocol over USB, or when both devices are connected to the same Wi-Fi network but one is not providing Internet access. Similarly, 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 capabilities.

[0005] The approval of the above references in this specification should not be construed to imply that they are in any way relevant to the patentability of the subject matter disclosed herein.

SUMMARY OF THE INVENTION

MEANS FOR SOLVING THE PROBLEM

[0006] According to one aspect of the subject matter of the present application, - a patient module configured for communication with an in-vivo device that receives data from the patient module and for communication with at least one additional device, - a gateway device configured to provide an access point for the patient module to access a network is provided, wherein the access point is configured for termination after an idle period of a predetermined idle time, and the patient module is at least - uploading data to the network via the gateway device while the access point is active, and - sending a ping signal to the gateway device at predetermined time intervals having a time shorter than the predetermined idle time during the idle period, thereby preventing termination of the access point A dynamic connection system (DCS) is provided that is configured for this purpose.

[0007] The data uploaded to the network via the gateway device may be at least any one of - raw data obtained from an in-vivo device, - processed data obtained from an in-vivo device, - data processed by the patient module based on raw / processed data obtained from the device, - data based on any of the above among others.

[0008] The term "idle period" shall be understood herein in the context of this application as the period of time during which such data is not transferred to the network via the gateway device.

[0009] The DCS may form part of a larger system comprising an HCP module, a gateway module comprising a gateway device, a medical kit comprising a patient module, and a cloud.

[0010] The DCS may be configured to provide communication between an in-vivo device (e.g., an endoscopic capsule, a pacemaker, etc.) and a network. The patient module may be a wearable device configured to receive data from the in-vivo device, and the gateway device may be a mobile device such as a smartphone or a tablet. According to a particular example, the in-vivo device may be an endoscopic examination capsule, and the wearable device may be an adhesive patch (skin application solution) comprising the necessary communication components for transmitting and receiving data to and from the in-vivo device and uploading the data obtained from the in-vivo device to the cloud via the gateway device.

[0011] The gateway device may be configured to provide the patient module with access to the Internet by connecting the patient module to a router that provides access to the Internet, or direct access to the Internet via a data plan (i.e., tethering). Under the above configuration, the gateway device forms an access point (AP), while the patient module forms a client.

[0012] Communication between the patient module and the gateway device may be performed using one or more communication channels, such as WiFi, Bluetooth®, Bluetooth Low Energy (BLE), etc.

[0013] Communication between the patient module and the gateway device can facilitate at least the following: - Information transfer - Provide notifications and instructions to the patient. If the gateway device is also a display device (e.g., a smartphone), such notifications and instructions may be provided to the patient via an appropriate app. - Data transfer - Data obtained from in-vivo devices and / or processed by in-vivo and / or wearable devices. - Control - Notify the patient module about additional devices attempting to access the patient module.

[0014] According to a specific example, a WiFi channel may be used to transfer raw / processed data, while one or more BLE channels may be used for information transfer and control. It should be noted that both WiFi and BLE may operate at similar broadcast frequencies, but may have different bandwidths and occupy different time slots during communication.

[0015] A predetermined idle time of the gateway device may be 60 - 100 seconds, more specifically 75 - 85 seconds, and even more specifically about 90 seconds. The ping signal may have a period of 40 - 80 seconds, more specifically 50 - 70 seconds, and even more specifically about 60 seconds.

[0016] The patient module may be configured to aggregate data into chunks before transferring the data to the gateway device. The patient module may be configured to upload these data chunks using the gateway device at a predetermined time interval, herein referred to as the data upload time interval or DU time interval, corresponding to the time required to obtain such a chunk of data. The DU time interval may be greater than the idle period, for example, 200 - 400 seconds, more specifically, 250 - 350 seconds, and even more specifically, about 300 seconds. The data chunk may be 10MB - 100MB, and according to a specific example, may be 40MB - 60MB.

[0017] The patient module may be configured to upload the data accumulated on the chunk to the network via the gateway device during the DU time interval. During the DU time interval, the patient module may be configured to send a ping signal to prevent the gateway device from timing out due to a large idle period.

[0018] The configuration may be such that the ping signal to the gateway device is invalid during the transfer of data from the patient module to the network via the gateway device. In other words, the ping signal may be used only during the idle period of the gateway device.

[0019] The patient module may also be configured to send a secondary ping signal to the gateway device to verify that the gateway device is active. This secondary ping signal may be sent periodically, for example, at a period much shorter than the ping signal, such as 5, 10, or 15 seconds, and the BLE channel may also be used.

[0020] In accordance with the subject matter of the present application, the DCS may also be configured to accommodate communication with a data device configured for display and / or further processing of raw / processed data and / or information based thereon.

[0021] According to one example, the data device may be configured to communicate directly with the patient module. Under this configuration, when the data device requests access to the patient module, the patient module may switch from client mode to AP mode and then may be configured to provide access to the data device that functions as a client. Hereinafter, this mode of operation is referred to as real-time view (RTV) in this specification. It should be noted that under this configuration, the patient module may continuously advertise its presence via a second BLE channel different from the first BLE channel in order to be discoverable by the data device.

[0022] The patient module may be configured to prioritize the data device over uploading data to the network via the gateway device. Further, when the RTV mode is active, the uploading of data to the gateway device may be interrupted. However, the patient module may still be configured to prioritize taking advantage of the hot spot over the RTV mode, and the patient module may periodically return to client mode to continue sending ping signals, and then the patient module may return to acting as an AP for the data device.

[0023] According to another example, the data device may be configured for communication with the cloud and may download raw / processed data previously uploaded by the patient module from the cloud. This mode of operation is hereinafter referred to as near real-time view (NRTV).

[0024] Under this mode of operation, when a request by the data device is provided to the cloud, it may notify the patient module about the request, and the patient module may switch to continuously transferring the data to the gateway device instead of aggregating the data, thereby improving the NRTV.

[0025] The DCS of the present application provides seamless and dynamic switching between two operating modes: data upload to the cloud via a gateway device and data transfer to an HCP device. Further, in each operating mode, data is transferred over different networks and under different configurations, thereby enhancing data security and creating a buffer between the HCP device and the patient data uploaded to the cloud.

[0026] According to another aspect of the subject matter of the present application, a dynamic connection system (DCS) is provided that includes a patient module configured for communication with an in-vivo device and for receiving data from the in-vivo device, the patient module comprising at least - a client mode in which the patient module communicates with a gateway device configured to provide an access point for the patient module to access a network, and - an access point (AP) mode in which the patient module permits access to a data device configured to receive data from the patient module and is configured to communicate in, and the patient module is configured to dynamically switch between the client mode and the AP mode.

[0027] The DCS system may operate in client mode by default and may be configured to switch to AP mode upon request from a data device. As in the previous aspect of the subject matter of the present application, the patient module is configured to prioritize the AP mode over the client mode when access is requested by a data device. However, the patient module may prioritize continuing to take advantage of the gateway device's hotspot over the AP mode.

[0028] All of the features described above in connection with the first aspect of the subject matter of this application, such as the use of the BLE channel for communication with the gateway device and the data device, advertising the presence of the patient module, transmitting ping signals, etc., may be implemented in the current aspect with the necessary changes.

[0029] To better understand the subject matter disclosed and illustrated herein as to how it is actually implemented, embodiments will be described by reference to the accompanying drawings only as non-limiting examples.

Brief Description of the Drawings

[0030]

Figure 1

Figure 2A

Figure 2B

Modes for Carrying Out the Invention

[0031] For the sake of brevity and clarity of explanation, it will be understood that the elements shown in the drawings are not necessarily drawn exactly or to scale. For example, the size of some 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 appropriate, reference numerals may be repeated throughout the drawings to indicate corresponding or similar elements.

[0032] First, attention is drawn to FIG. 1, which shows an overall system generally referred to as 1 and comprising a medical kit module 10, a gateway module 20, an HCP module 30, and a cloud 40. The dynamic connection system (DCS) of the present application is established between the medical kit 10 and the gateway module 20 and between the medical kit 10 and the HCP module 30.

[0033] In the following example, the overall system is shown as part of a capsule endoscopy procedure, and the medical kit 10 comprises a swallowable endoscopy capsule 50 that constitutes an in-vivo device configured for communication therebetween using an uplink channel 62 and a downlink channel 64, and an adhesive patch 60 that constitutes a patient module.

[0034] Now, attention is drawn to FIG. 2A, which shows the DCS that provides communication between the medical kit 10 and the gateway module 20. The patch 60 is configured to receive data from the capsule 50 and to upload data to the cloud 40. The data uploaded to the cloud may be - raw data obtained from the in-vivo device, - processed data obtained from the in-vivo device, - data processed by the patient module based on the raw / processed data obtained from the device, - data based on any of the above It should be noted that it may be any of these.

[0035] Patch 60 is configured to upload data to cloud 40 either by direct communication with router 80 or via a hotspot established by mobile device 70. Patch 60 is configured to communicate with mobile device 70 via secure Wi-Fi 72 and via a first Bluetooth Low Energy (BLE) channel 74. Under this configuration, mobile device 70 acts as an access point (AP), while patch 60 functions as a client. The Wi-Fi channel 72 is used to transfer acquired / processed data to mobile device 70, while the BLE channel 74 is used to provide mobile device 70 with notifications and instructions related to CE procedures and control signals for verifying that mobile device 70 is active and within range, etc.

[0036] Note that when mobile device 70 establishes a hotspot, the hotspot connects patch 60 to cloud 40 (shown by connections 102 and 94) via cell antenna 100 or to router 80 via connection 82.

[0037] When patch 60 is connected to cloud 40 via mobile device 70 and cell antenna 100, if data is not provided to cloud 40 by patch 60, mobile device 70 is configured to terminate the hotspot within 90 seconds. On the other hand, patch 60 is configured to upload data to cloud 40 in chunks of a predetermined size and does not transfer data to mobile device 70 until such data chunks are accumulated.

[0038] This can create a situation where the mobile device's hotspot remains idle for over 90 seconds, which may cause the hotspot to end. Subsequently, if Patch 60 is requested to upload data, it is necessary to resume the hotspot, which causes communication delays. To overcome this defect, a DCS is provided where Patch 60 is configured to periodically transmit a ping signal to the mobile device 70 at a time period shorter than 90 seconds (in this example, 60 seconds). Thus, even if data is not being uploaded to the cloud 40 via the hotspot throughout the idle period, the hotspot remains active and does not end.

[0039] According to a specific example, Patch 60 is also configured to transmit a secondary ping signal every 5 - 15 seconds via the first BLE channel 74 to verify that the mobile device 70 is active (not shut down, within range, etc.).

[0040] Referring now to FIG. 2B, a DCS is shown that provides communication between the HCP module 30, the gateway module 20, and the medical kit 10. In particular, during a capsule endoscopy procedure, the HCP may desire to review data uploaded from the capsule 50 to Patch 60. In this case, a display device such as the tablet 110 may be used by the HCP to view the data.

[0041] Under this configuration, Patch 60 continuously advertises its presence via the second BLE channel 112 to be discoverable by the HCP device 110. When the HCP desires to view the data, the tablet 110 requests access from Patch 60 via the BLE connection 112. Patch 60 then verifies that the tablet 110 is granted access (to prevent an unauthorized party from viewing the patient's data) and allows the access.

[0042] Upon receiving such a request, Patch 60 prioritizes establishing such a connection with Tablet 110 and switches to function as an AP, while Tablet 110 functions as a client. In this case, when Connection 112 is established, Patch 60 stops its connection 72 with the mobile device's hotspot, and the HCP can have a real-time view (RTV) of the data.

[0043] However, Patch 60 still prioritizes keeping the hotspot active during the RTV. After 60 seconds of RTV, Patch 60 temporarily terminates Connection 112, reverts to functioning as a client of Mobile Device 70, and sends a ping signal to maintain the release of Channel 72. Then, Patch 60 returns to Connection 112 and can continue the RTV by the HCP Tablet 110.

[0044] Referring further to FIG. 2B, the HCP may also operate under a near real-time view (NRTV). In that case, Router 120 of HCP Module 30 establishes a connection 126 with the cloud and downloads data therefrom. Under this configuration, Patch 60 does not buffer data into chunks but rather continuously uploads data to the cloud via the hotspot. Also, in this case, since Channel 72 with Mobile Device 70 is always in use (i.e., not an idle time), there is no need to send a ping signal.

[0045] Those skilled in the art related to the present invention will readily understand that numerous changes, modifications, and improvements can be made without departing from the scope of the present invention by making necessary changes. (Item 1) - A patient module configured for communication with an in-vivo device that receives data from the patient module and for communication with at least one additional device. - A gateway device configured to provide an access point for the patient module to access the network and comprising the access point is configured for termination after an idle period of a predetermined idle time, and the patient module is at least - uploading data to the network via the gateway device while the access point is active, and - sending a ping signal having a period shorter than the predetermined idle time to the gateway device during the idle period, thereby preventing termination of the access point configured for a dynamic connection system (DCS). (Item 2) The DCS forms part of a larger system comprising an HCP module, a gateway module, a medical kit, and a cloud The DCS according to Item 1. (Item 3) The DCS is configured to provide communication between an in-vivo device and the network The DCS according to Item 1 or 2. (Item 4) The patient module is a wearable device configured to receive data from the in-vivo device The DCS according to Item 1, 2, or 3. (Item 5) The gateway device is a mobile device The DCS according to any one of Items 1 to 4. (Item 6) The mobile device is at least one of a smartphone, a tablet, a digital notepad, and a router The DCS according to Item 5. (Item 7) The wearable device is in the form of an adhesive patch The DCS according to Item 4. (Item 8) The adhesive patch includes necessary communication components for receiving data from the in-vivo device and uploading the data to the cloud via the gateway device. The DCS according to Item 7. (Item 9) The gateway device is configured to provide access to the Internet to the patient module. The DCS according to any one of Items 1 to 8. (Item 10) The access is provided by connecting to a router that then provides access to the Internet. The DCS according to Item 9. (Item 11) Direct access to the Internet via the mobile device is provided. The DCS according to Item 9. (Item 12) The gateway device constitutes an access point (AP), while the patient module constitutes a client. The DCS according to any one of Items 1 to 11. (Item 13) Communication between the patient module and the gateway device is performed using one or more communication channels. The DCS according to any one of Items 1 to 12. (Item 14) The communication utilizes at least a WiFi channel and a first Bluetooth (registered trademark) channel. The DCS according to Item 13. (Item 15) The first Bluetooth (registered trademark) channel is BLE. The DCS according to Item 14. (Item 16) Communication between the patient module and the gateway device facilitates at least information transmission, data transfer, and control. The DCS according to item 13, 14, or 15. (Item 17) The WiFi channel is used for data transfer, while the first BLE channel is used for information transmission and control. The DCS according to item 16. (Item 18) The predetermined idle time of the gateway device may be 60 to 100 seconds, more specifically 75 to 85 seconds, and even more specifically about 90 seconds, for the DCS according to any one of items 1 to 17. The ping signal may have a period of 40 to 80 seconds, more specifically 50 to 70 seconds, and even more specifically about 60 seconds. (Item 19) The patient module is configured to upload data using the gateway device at a predetermined data upload (DU) time interval. The DCS according to item 18. (Item 20) The DU time interval is greater than the idle period. The DCS according to item 19. (Item 21) The DU time interval is 200 to 400 seconds, more specifically 250 to 350 seconds, and even more specifically about 300 seconds. The DCS according to item 20. (Item 22) The DCS is configured to accommodate communication with a viewing / display device. The DCS according to any one of items 1 to 21. (Item 23) The viewing / display device is configured to display raw / processed data and / or information based on the raw / processed data. The DCS according to item 22. (Item 24) The data device is configured to communicate directly with the patient module. The DCS according to item 22 or 23. (Item 25) The patient module is configured to switch from client mode to AP mode and provide access to the data device. The DCS according to item 22, 23 or 24. (Item 26) The patient module continuously advertises its presence via a second BLE channel different from the first BLE channel so as to be discoverable by the data device. The DCS according to any one of items 22 to 25. (Item 27) The patient module is configured to prioritize the data device over uploading data to the cloud via the gateway device. The DCS according to any one of items 22 to 26. (Item 28) The patient module prioritizes maintaining the connection with the gateway device over the connection with the data device. The DCS according to any one of items 22 to 27. (Item 29) The patient module is configured to periodically return to client mode to continue sending the ping signal, and then the patient module may return to acting as the AP for the data device. The DCS according to item 28. (Item 30) The data device is configured for communication with the cloud and downloads the raw / processed data previously uploaded by the patient module from the cloud. The DCS according to any one of items 22 to 29. (Item 31) When the data device is downloading the data from the cloud, the patient module is configured to continuously upload data to the cloud without buffering. The DCS according to item 30. (Item 32) A dynamic connection system (DCS) comprising a patient module configured for communication with an in-vivo device and for receiving data from said in-vivo device, wherein the patient module is at least, - in a client mode communicating with a gateway device configured to provide an access point for the patient module to access a network, and - in an access point (AP) mode permitting access to a data device configured to receive data from the patient module configured to communicate in, wherein the patient module is configured to dynamically switch between the client mode and the AP mode, a dynamic connection system (DCS). (Item 33) wherein the system is configured to operate in the client mode by default and switch to the AP mode upon request from the data device, the DCS system according to item 32. (Item 34) wherein the patient module is configured to prioritize the AP mode over the client mode when access is requested by the data device, the DCS system according to item 33. (Item 35) wherein the patient module prioritizes continuing to take advantage of the gateway device's hotspot over the AP mode, the DCS system according to item 34.

Claims

1. A patient module comprising an in-vivo device and a wearable device, wherein the patient module is configured to receive data from the in-vivo device, operate in a client mode to transfer the data to a gateway module, and dynamically switch from the client mode to an access point (AP) mode in which the patient module permits access to the data by the HCP module upon request from the HCP module. The patient module is configured to perform the above operations, The gateway module comprises a mobile device and is configured to receive the data from the patient module and upload the data to a cloud server while the patient module is operating in the client mode. The HCP module is configured to connect to the patient module and directly access the data from the patient module while the patient module is operating in the AP mode. The gateway module provides an access point while the patient module is operating in the client mode. In the AP mode, the patient module is further configured to switch from the AP mode to the client mode, send a ping signal to the gateway module, where the ping signal is operative to prevent termination of the access point of the gateway module, and periodically resume operation in the AP mode. A system configured as described above.

2. The system according to claim 1, wherein the wearable device is an adhesive patch.

3. The system according to claim 2, wherein the adhesive patch comprises a communication component configured to receive the data from the in-vivo device and transfer the data to the gateway module.

4. The system according to any one of claims 1 to 3, wherein the gateway module is further configured to provide the patient module with access to the Internet.

5. The system according to any one of claims 1 to 4, wherein communication between the patient module and the gateway module is performed using one or more communication channels.

6. ​ ​ The system according to claim 5, wherein the one or more communication channels comprise a WiFi channel and a first Bluetooth Low Energy (BLE) channel.

7. The system according to claim 6, wherein the WiFi channel is used for data transfer and the first BLE channel is used for information transmission and control.

8. The access point of the gateway module is configured to end after an idle period of a predetermined idle time, The patient module is further configured to send the ping signal to the gateway module during the idle period, the ping signal is sent at a time interval shorter than the predetermined idle time, and operates to prevent the access point of the gateway module from ending. The system according to any one of claims 1 to 4.

9. The system according to claim 8, wherein the patient module is configured to transfer the data to the gateway module during a predetermined data upload (DU) time interval.

10. The system according to claim 9, wherein the predetermined DU time interval is longer than the predetermined idle time.

11. The system according to any one of claims 1 to 10, wherein the HCP module comprises a display device.

12. The system according to claim 11, wherein the display device is configured to display at least one of the data or information based on the data.

13. The system according to claim 11 or 12, wherein the display device is configured to communicate directly with the patient module while the patient module operates in the AP mode.

14. The system according to claim 6, wherein the patient module advertises its presence via a second BLE channel different from the first BLE channel for discovery by the HCP module.

15. The patient module is further configured to switch between the client mode and the AP mode, The system according to claim 1, wherein the patient module is configured to prioritize communication with the HCP module over communication with the gateway module.

16. The patient module is further configured to switch between the client mode and the AP mode. The system according to claim 1, wherein the patient module is configured to prioritize maintaining a connection with the gateway module over communicating with the HCP module. **Claim 17** The system according to any one of claims 1 to 16, wherein the HCP module is further configured to communicate with the cloud server and download the data pre-uploaded by the gateway module. **Claim 18** While the HCP module is downloading the data from the cloud server, the patient module is configured to continuously transfer the data to the gateway module without buffering, and the gateway module is configured to continuously upload the data to the cloud server without buffering. The system according to claim 17.

Images