Patent Application
20220039055
Contact tracing systems may enable individual mobile device operators to be notified of potential exposure to conditions such as infections diseases. In such systems, the mobile devices may both emit beacons, and listen for beacons from other mobile devices. Physical proximity between the devices (and therefore the operators of those devices) may be determined, e.g. at a server, from various properties of the beacons. In some implementations, however, reporting of beacon detections to the server may negatively affect network performance.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
Examples disclosed herein are directed to a method in a computing device, the method including: via a short-range interface of a computing device, detecting a plurality of beacons emitted by another computing device, each beacon containing an identifier of the other computing device; obtaining respective proximity indicators corresponding to the beacons; generating a first set of aggregated attributes from the proximity indicators; storing the first set of aggregated attributes in association with the identifier of the other computing device; and transmitting the first set of aggregated attributes to a server configured to detect physical proximity between the computing device and the other computing device based on the first set of aggregated attributes.
Additional examples disclosed herein are directed to a computing device, comprising: a first short-range communications interface; a memory; and a controller configured to: via the short-range interface, detect a plurality of beacons emitted by another computing device, each beacon containing an identifier of the other computing device; obtain respective proximity indicators corresponding to the beacons; generate a first set of aggregated attributes from the proximity indicators; store the first set of aggregated attributes in association with the identifier of the other computing device; and transmit the first set of aggregated attributes to a server configured to detect physical proximity between the computing device and the other computing device based on the first set of aggregated attributes.
The system 100 includes a plurality of mobile computing devices 104, of which four examples 104-1, 104-2, 104-3, and 104-4 are shown in
Each device 104 may be carried by an operator (e.g. a worker in the facility 102), e.g. alone or along with other computing devices worn or carried by the operator. The device 104 periodically emits a beacon using the short-range interface mentioned above. The interval between beacons is configurable. For example, each device 104 can be configured to emit a beacon at one-second intervals. Different devices 104 may use different beacon intervals, however. Each device 104 also scans for beacons emitted by the other devices 104. Thus, for example, the device 104-2 emits a beacon 112, which may be detected by the devices 104-1 and 104-3. The device 104-4 may be too distant from the device 104-2 to detect the beacon 112. The devices 104-1 and 104-3, responsive to detecting the beacon 112, can be configured to report, via wireless connections 116-1 and 116-3 to the WLAN 108, attributes obtained from the beacon 112.
In particular, the devices 104-1 and 104-3 may report the above-mentioned attributes to a server 120 via the WLAN 108 and, in some examples, a network 124 (e.g. a wide area network, which may include the Internet). In other examples, the server 120 may be located at the facility 102, and connected directly to the WLAN 108. In any event, the server 120 can be configured to process the data reported by the devices 104 and determine whether any of the devices 104 have been within a predefined proximity of one another (e.g. within about two meters). For instance, the devices 104-1 and 104-3 may report an indication of signal strength associated with the beacon 112 to the server 120, and the server 120 can estimate a distance between the device 104-2 and each of the devices 104-1 and 104-3 when the beacon 112 was detected by those devices 104.
The server 120 can also, when a pair of devices 104 are determined to have come within the predefined proximity mentioned above, transmit a message to the relevant devices 104 themselves, or other computing devices associated with the operators of the affected devices 104. In some examples, transmission of the above messages may be performed only when the server 120 receives (e.g. from a separate source, not illustrated in
The above-mentioned proximity detection and notification functionality need not be performed by the server 120 itself. For example, the server 120 can host a data lake or other form of repository, while a further computing device retrieves data from the repository and performs the contact tracing functionality.
As will be apparent to those skilled in the art, each device 104 emits beacons as well as detecting beacons emitted by other devices 104. The total number of beacons detected across the set of devices 104 deployed in the facility 102 may therefore be sufficient to cause congestion or outages of the WLAN 108. The devices 104 are therefore, as discussed in detail herein, configured to generate and report aggregated attributes derived from detected beacons, rather than the individual beacon detections. The aggregated reporting processes implemented by the devices 104 may enable the server 120 to continue performing the contact tracing functionality mentioned above, while reducing the operational load on the WLAN 108. Further, the aggregated reporting processes may be deployed with relatively low-cost devices such as the bridge devices mentioned above.
Turning to
The device 104 includes a controller 200, such as a central processing unit (CPU), application-specific integrated circuit (ASIC) or the like, coupled with a non-transitory computer readable storage medium, such as a memory 204. The memory 204 can include a suitable combination of volatile memory (e.g. Random Access Memory or RAM) and non-volatile memory (e.g. read only memory or ROM, Electrically Erasable Programmable Read Only Memory or EEPROM, flash memory). The controller 200 and the memory 204 each comprise one or more integrated circuits.
The device 104 also includes a short-range communications interface 208, such as a Bluetooth™ interface, enabling the device 104 to communicate with other devices, and also to emit and detect beacons as summarized in connection with
The memory 204 can store computer readable instructions for execution by the controller 200. In the present example, the memory 204 stores a data aggregation application 216 which, when executed by the controller 200, configures the controller 200 to detect beacons from other devices 104 and generate aggregated attributes corresponding to those beacons for reporting to the server 120. The memory 204 also stores a repository, which may also be referred to as a buffer 220, in which aggregated attributes are stored for subsequent reporting to the server 120.
Turning to
At block 305, the device 104-1 is configured to begin scanning for beacons from other devices 104. For example, the short-range interface 208 can be configured to initiate a scan window, in which the interface 208 is employed to listen for beacons from other devices 104 for a predetermined time period (e.g. 30 seconds).
At block 310, the device 104-1 is configured to detect a beacon emitted by another device 104. In the present example performance of block 310, it is assumed that the device 104-1 detects, via the short-range interface 208, the beacon 112 emitted by the device 104-2, as shown in
At block 310, the device 104-1 is also configured to obtain a proximity indicator corresponding to the beacon 112. The proximity indicator is an indication of the distance between the device 104-1 itself and the device 104-2 that emitted the beacon 112. The proximity indicator can be, for example, an indication of signal strength associated with the beacon 112. For example, the device 104-1 can determine a received signal strength indicator (RSSI) from the beacon 112, such as a value between zero and one hundred, a value between −100 and zero, or the like, with greater values indicating greater received signal strength.
Having detected the beacon 112 and determined the proximity indicator, the device 104-1 can store a record, e.g. in the memory 204, containing the proximity indicator and the identifier(s) of the device 104-2 extracted from the beacon 112.
At block 315, the device 104-1 is configured to determine whether a record to track beacons from the device 104-2 (i.e. from the emitter of the beacon detected at block 310) exists in the memory 204. The determination at block 315 is affirmative if a previous performance of block 310 within the same scan window detected a beacon from the same device (104-2, in this example). If the beacon detected at block 310 is the first beacon from the device 104-2 in the current scan window, the determination at block 315 is negative. In the present example, it is assumed that the beacon 112 is the first beacon from the device 104-2 detected in the scan window initiated at block 305.
Following a negative determination at block 315, therefore, the device 104-1 proceeds to block 320. At block 320, the device 104-1 generates a set of aggregated attributes from the beacon detected at block 310. As will be discussed in greater detail below, the attributes generated at block 320 are also updated based on subsequent beacons detected from the device 104-2, such that the set of attributes can represent a plurality of individual beacons from a given emitting device.
The aggregated attributes generated at block 320 can include a variety of attributes based on the proximity indicator (e.g. RSSI) obtained at block 310. For example, turning to
Various other aggregated attributes can be employed in addition to, or instead of, those shown in
Returning to
Referring to
Therefore, the device 104-1 proceeds to block 330. At block 330, the device 104-1 updates the aggregated attributes in the record 404. As shown in
As will now be apparent, the device 104-1 may perform numerous further instances of blocks 310, 315 and 320 or 330 during a given scan window, accumulating data for a plurality of beacons from various other devices 104. The device 104-1 generates an aggregated record for each other device 104 and updates the attributes therein with each subsequently detected beacon from that device 104.
Turning to
Returning to
Following storage of the aggregated record(s), the device 104-1 proceeds to block 340. At block 340, the device 104-1 is configured to determine whether to transmit (which may also be referred to as reporting, or posting), the aggregated records to the server 120. The determination at block 340 can be based on a predefined post interval, e.g. according to which aggregated records are posted every five minutes (although both shorter and longer time periods may also be employed). In other examples, the determination at block 340 can be based on network conditions within the WLAN 108, such as signal strength, congestion levels, and the like. In further examples, the determination at block 340 can be based on storage capabilities of the device 104-1. For example, the determination at block 340 can be affirmative when the available storage capacity in the buffer 220 falls below a threshold relative to the total capacity (e.g. 10%).
When the determination at block 340 is negative, the device 104-1 returns to block 305 to initiate the next scan window. The next scan window can immediately follow the termination of the current scan window, but in some implementations scan windows can be separated by a configurable time period.
When the determination at block 340 is affirmative, the device 104-1 proceeds to block 345. At block 345, the device 104-1 transmits the aggregated record(s) in the buffer 220 to the server 120, via the network 108 (and the network 124, as needed). The device 104-1 may then discard the aggregated record(s), releasing the buffer 220 for the next performance of the method 300.
As will now be apparent, the transmission of the aggregated records, instead of individual beacon records, can reduce the volume of data transmitted by each device 104 to the server 120. In particular, the size of each aggregated record is substantially constant, regardless of the number of individual beacons detected from a given device 104. The aggregated attributes, however, still represent the full set of beacons detected from that device. The representation of beacons from a device 104 by the aggregated attributes is likely to be imperfect, but the loss in fidelity of representation is balanced by a potentially significant reduction in resource usage at the devices 104 and in network traffic within the WLAN 108.
Further variations to the above are contemplated. For example, each device 104 may evaluate each beacon detected at block 310 before proceeding to block 315. For example, the device 104 may determine whether the proximity indicator is above a predefined threshold. When the proximity indicator does not exceed the threshold, the beacon may simply be discarded, and a further performance of block 310 may be initiated. That is, beacons detected with insufficient signal strength may be ignored, and therefore not represented in the aggregated attributes. The threshold may be selected to exclude beacons that are likely to be sufficiently distant from the detecting device 104 as to not represent potential contacts for the purpose of the contact tracing function performed at the server 120.
In other examples, beacons may be discarded as above when the device identifiers contained therein fail to meet certain criteria. For example, the facility 102 may contain various types of devices that broadcast beacons, some of which may not be directly relevant to the above-mentioned contact tracing functionality. The devices 104 may therefore be configured to only process beacons from other devices having predefined identifiers (e.g. identifiers within a predefined range).
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.
The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
It will be appreciated that some embodiments may be comprised of one or more specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.
Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
