WO2022000028A1

WO2022000028A1 - Methods, systems and devices for tracking interactions between individuals

Info

Publication number: WO2022000028A1
Application number: PCT/AU2021/050687
Authority: WO
Inventors: Robert Cumming; Theo Boegman; Gys van Nieuwenhuizen; Jan du Plooy
Original assignee: Urban.io PTY LTD
Priority date: 2020-06-29
Filing date: 2021-06-29
Publication date: 2022-01-06

Abstract

Embodiments generally relate to a device for facilitating tracking of interactions between individuals. The device comprises a housing defining a battery compartment; a clip portion coupled to the housing, wherein the clip portion allows the device to be releasably coupled to a garment; an antenna for transmitting data to external devices; a memory; and a processor. The processor is configured to execute program code to broadcast a first signal; receive at least one response signal from a first external device in response to the first signal; determine a proximity event with the first external device based on the at least one response signal; and store data relating to the proximity event in a memory. The antenna, memory and processor are located on the clip portion of the device.

Description

"Methods, systems and devices for tracking interactions between individuals" Technical Field

Described embodiments generally relate to tracking interactions between individuals. In particular, described embodiments are directed to systems, methods and devices for tracing and tracking contact and interactions between individuals using wearable devices.

Background

Communicable diseases can spread rapidly in a community via human contact, sometimes resulting in an epidemic or pandemic. These diseases can cause harm to human health and in the worst case may cause death.

Some techniques that may be employed by a government or community to reduce the spread of communicable diseases include social distancing and self-isolation. Social distancing is a technique that requires individual people moving around an environment to remain physically distant from one another, or to only be in close proximity to one another for limited periods of time. Self-isolation requires an individual person to remain physically isolated from other people, and may be employed during a period where the individual has or is thought to have contracted a disease, to reduce the likelihood of that disease spreading to another individual.

Contact tracing is a technique that can be used to ensure compliance with social distancing and self-isolation, or which can be used as an independent technique to trace the potential spread of a disease in a community. Contact tracing involves detecting and tracking physical interactions between individuals over time. In the event that one individual is identified as having contracted a communicable disease, contact tracing makes it possible to rapidly identify, isolate and test all other individuals who have been in contact with the infected individual and who therefore have a possibility of also having been infected.

While mechanisms for facilitating the process of contact tracing exist, known devices and techniques are inaccurate, time consuming and expensive, and suffer from poor detection accuracy, detection range, distance accuracy, detection frequency, detection concurrency and associating a detection event with an identifiable position. Furthermore, known devices and techniques can be invasive of user privacy. It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior systems, methods and devices for tracing and tracking contact and interactions between individuals, or to at least provide a useful alternative thereto.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

In this document, a statement that an element may be “at least one of’ a list of options is to be understood to mean that the element may be any one of the listed options, or may be any combination of two or more of the listed options. Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

Summary

Some embodiments relate to a device for facilitating tracking of interactions between individuals, the device comprising: a housing defining a battery compartment; a clip portion coupled to the housing, wherein the clip portion allows the device to be releasably coupled to a garment; an antenna for transmitting data to external devices; a memory; and a processor configured to execute program code to: broadcast a first signal; receive at least one response signal from a first external device in response to the first signal; determine a proximity event with the first external device based on the at least one response signal; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device.

Some embodiments are further configured to transmit the stored data relating to the proximity event to a second external device.

According to some embodiments, the first signal comprises a unique identification number associated with the device. In some embodiments, the data relating to the proximity event comprises a unique identification number received from and associated with the first external device. In some embodiments, the data relating to the proximity event comprises a time at which the proximity event occurred.

According to some embodiments, the processor is further configured to determine an RSSI based on the at least one response signal. In some embodiments, the data relating to the proximity event comprises a distance between the device and the first external device determined based on the RSSI. In some embodiments, the proximity event is determined based on comparing a distance between the device and the first external device determined based on the RSSI with a predetermined distance threshold. According to some embodiments, a proximity event is determined if the distance between the device and the first external device is less than the predetermined distance threshold.

In some embodiments, the proximity event is determined based on comparing a duration of an interaction between the device and the first external device with a predetermined duration threshold. According to some embodiments, a proximity event is determined if the duration of an interaction between the device and the first external device is longer than the predetermined duration threshold.

According to some embodiments, the processor is further configured to: listen for a broadcast receive at least one response signal from a first external device in response to the first signal; determine a proximity event with the first external device based on the at least one response signal; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device. Some embodiments relate to a device for facilitating tracking of interactions between individuals, the device comprising: a housing defining a battery compartment; a clip portion coupled to the housing, wherein the clip portion allows the device to be releasably coupled to a garment; an antenna for transmitting data to external devices; a memory; and a processor configured to execute program code to: listen for a broadcast signal; receive at least one broadcast signal from a first external device; send at least one response signal to the first external device; and determine a proximity event with the first external device; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device.

According to some embodiments, the response signal comprises a unique identification number associated with the device.

In some embodiments, the data relating to the proximity event comprises a unique identification number received from and associated with the first external device. According to some embodiments, the data relating to the proximity event comprises a time at which the proximity event occurred.

According to some embodiments, the processor is further configured to determine an RSSI based on the at least one broadcast signal. In some embodiments, the data relating to the proximity event comprises a distance between the device and the first external device determined based on the RSSI. In some embodiments, the proximity event is determined based on comparing a distance between the device and the first external device determined based on the RSSI with a predetermined distance threshold. According to some embodiments, a proximity event is determined if the distance between the device and the first external device is less than the predetermined distance threshold.

Brief Description of Drawings

Embodiments are described in further detail below, by way of example and with reference to the accompanying drawings, in which:

Figure 1 shows a diagram of a system for tracing and tracking contact and interactions between individuals according to some embodiments;

Figure 2 shows a block diagram of the components of devices for tracing and tracking contact and interactions between individuals as shown in Figure 1 ;

Figure 3A shows a perspective view of a wearable device for tracing and tracking contact and interactions between individuals as shown in Figure 1 ;

Figure 3B shows a side view of the wearable device of Figure 3A;

Figure 3C shows a front view of the wearable device of Figure 3A;

Figure 3D shows a top view of the wearable device of Figure 3A;

Figure 3E shows a bottom view of the wearable device of Figure 3A;

Figure 4A shows a front view of clip component of a wearable device according to some embodiments;

Figure 4B shows a perspective view of the clip of Figure 4A;

Figure 4C shows a top view of the clip of Figure 4A;

Figure 5A shows the device of Figure 3A with a battery compartment in a closed, locked state;

Figure 5B shows the device of Figure 3A with a battery compartment in a closed, unlocked state;

Figure 5C shows the device of Figure 3A with a battery compartment in an open, unlocked state;

Figure 5D shows the device of Figure 3A with a battery compartment removed;

Figure 6A shows a side exploded view of a wearable device according to some embodiments; Figure 6B shows a perspective exploded view of the embodiment of Figure 6A;

Figure 7A shows a side exploded view of a wearable device according to some embodiments;

Figure 7B shows a perspective exploded view of the embodiment of Figure 7A;

Figure 8A shows a side exploded view of a wearable device according to some embodiments;

Figure 8B shows a perspective view of the embodiment of Figure 8A;

Figure 9A shows a wearable device according to some embodiments worn in a pocket; Figure 9B shows a wearable device according to some embodiments coupled to a badge;

Figure 9C shows a wearable device according to some embodiments coupled to a lanyard;

Figure 10 shows a method performed by a wearable device according to some embodiments;

Figure 11 shows a method performed by two wearable devices according to some embodiments;

Figure 12 shows a method performed by three wearable devices according to some embodiments;

Figure 13 shows a timing diagram of a conversation between two wearable devices according to some embodiments;

Figure 14A shows a diagram illustrating a proximity event detected by a wearable device according to some embodiments;

Figure 14B shows a diagram illustrating distances between wearable devices that may cause a proximity event detected according to some embodiments;

Figure 15A shows a diagram illustrating a first example proximity event according to some embodiments;

Figure 15B shows a diagram illustrating a second example proximity event according to some embodiments;

Figure 15C shows a diagram illustrating a third example proximity event according to some embodiments;

Figure 16 shows a flowchart illustrating a method performed by a wearable device and a fixed device according to some embodiments;

Figure 17 shows a series of example interactions between a wearable device and a fixed device according to some embodiments;

Figure 18 shows a flowchart illustrating a method performed by a fixed device and a gateway device according to some embodiments; Figure 19 shows a diagram illustrating an example of system 100 operating within an indoor environment;

Figure 20 shows a diagram illustrating an example of system 100 operating within an outdoor environment;

Figure 21 A shows an ideal signal transmitting and receiving environment;

Figure 2 IB shows a non-ideal signal transmitting and receiving environment;

Figure 22A shows a first signal sending method;

Figure 22B shows a second signal sending method;

Figure 22C shows a third signal sending method;

Figure 22D shows a combination of the methods of Figures 22A, 22B and 22C;

Figure 23A shows previously known wearable devices;

Figure 23B shows a first identified problem with the devices of Figure 23A;

Figure 23C shows a second identified problem with the devices of Figure 23A;

Figure 24 shows a first group of potential users of the system of Figure 1;

Figure 25 shows a second group of potential users of the system of Figure 1;

Figure 26A shows a first configuration of a wearable device according to some embodiments;

Figure 26B shows a second configuration of a wearable device according to some embodiments;

Figure 27A shows a first group of embodiments of a disposable wearable device according to some embodiments;

Figure 27B shows a group of potential users of the device of Figure 27A;

Figure 27C shows a second group of embodiments of a disposable wearable device according to some embodiments; and

Figure 27D shows a group of potential users of the device of Figure 27C.

Detailed Description

Figure 1 shows a system 100 according to some embodiments. System 100 may be used by a government, business or organisation to track contact, interactions and proximity between individuals. According to some embodiments, the tracking may be of individuals attending an event or a premises such as a room or building. System 100 comprises at least one wearable tracking device 110. In the illustrated embodiments, four wearable tracking devices 110A, 110B, HOC and 110D are shown, but any number of wearable devices 110 may be used and tracked by system 100. According to some embodiments, wearable tracking devices 110 may be configured to be activated and associated with an individual user via an enrolment process, as described below. The individual may then keep device 110 with them by wearing device 110 on their person, as described below with reference to Figures 9A to 9C, 24, 25, 27B and 27D. Wearable device 110 may be designed to be small, so as not to cause inconvenience to the user when worn. Device 110 may be between 40 and 80mm tall and between 10 and 50mm in diameter. Device 110 may be around 60mm tall and around 20mm in diameter, for example.

When a wearable device 110 comes within a predefined distance with another wearable device 110 for a predetermined time period, each wearable device 110 may be configured to detect and log a proximity event and to store data relating to the proximity event, as described in further detail below with reference to Figures 10 to 14. Forms of wearable devices 110 are described in further detail below with reference to Figures 2 to 8, 26A, 26B, 27A and 27C .

System 100 further comprises at least one fixed tracking device 120 in communication with wearable tracking devices 110. Fixed tracking device 120 may be configured to be positioned in a fixed indoor and/or outdoor location, and to communicate with any devices 110 within its communication range. Wearable tracking devices 110 may be configured to send proximity event data to fixed tracking devices 120, as described in further detail below with reference to Figure 16 and 17. While the illustrated embodiment shows two fixed tracking devices 120A and 120B, system 100 may include any number of fixed tracking devices 120. According to some embodiments, fixed tracking devices 120 may be configured to operate within an indoor venue, as described below in further detail with reference to Figure 19. According to some embodiments, fixed tracking devices 120 may be configured to operate outdoors, as described below in further detail with reference to Figure 20.

Fixed tracking devices 120 are further in communication with a gateway device 130. Fixed tracking devices 120 may be configured to communicate received proximity event data to gateway 130 for processing, as described in further detail below with reference to Figure 18.

Gateway 130 may be configured to subsequently send the data to an external computing device or server system 140, which may be a cloud server system such as system 140 as illustrated. According to some embodiments, server system 140 may store the data in a database 160. This data may then be made available for access to members of the government, business or organisation running system 100, to allow them to trace any proximity event data in the event of a communicable disease being identified in one of the individuals who had been wearing a wearable tracking device 110.

According to some embodiments, system 100 further includes one or more computing devices 150 which may be used to associate devices 110 with an individual, and devices 120 with a location. According to some embodiments, devices 110 and 120 may be configured to be activated and associated with an individual user or a location via an enrolment or mapping process. The data relating device 110 to an individual or relating a device 120 to a location may be communicated to server system 140 and stored in database 160, or in a third party database.

The components of devices 110 and 120 are described in further detail with reference to Figure 2. Device 110 includes a processor 210. Processor 210 may include one or more data processors for executing instructions, and may include one or more of a microcontroller-based platform, a suitable integrated circuit, and one or more application- specific integrated circuits (ASIC's). Processor 210 may include an arithmetic logic unit (ALU) for mathematical and/or logical execution of instructions, such as operations performed on the data stored in internal registers of processor 210. According to some embodiments, processor 210 may include an ultra-low power RF- microcontroller, such as the ON Semiconductor® AX8052F143-3 microcontroller, for example.

Processor 210 may have access to memory 220. According to some embodiments, memory 220 may form part of processor 210. Memory 220 may include one or more memory storage locations, which may be in the form of ROM, RAM, flash, or other memory types. Memory 220 may store program code 221, which may be executable by processor 210 to cause processor 210 to perform functions as described in further detail below.

For example, according to some embodiments program code 221 include a proximity event module 222. When executing proximity event module 222, device 110 may be configured to periodically emits a radio signal via antenna 250 containing a packet of data including identification number 225, and to periodically listen for signals emitted by other devices 110. When device 110 detects the presence of another device 110, it may begin a conversation with the device, where it will more frequently transmit its identification number 225 and more frequently listen for other transmissions containing identification numbers of other devices 110. This is described below in further detail with reference to Figures 10 to 13.

According to some embodiments, program code 221 may also include a data sending module 223, which may be executable by processor 210 to cause processor 210 to send proximity event data generated during execution of module 222 to a device 120. This is described in further detail below with reference to Figures 16 and 17.

Memory 220 may also comprise data 224. Data 224 may include a unique identification number 225 that may be used to identify device 110. Identification number 225 may be stored in memory 220 as permanent or un-rewritable data. Data 224 may also include proximity event data 226, which may be temporary data used to record information relating to proximity events identified by device 110 when executing proximity event module 222.

Device 110 further comprises a power source in the form of battery 230. Battery 230 may comprise one or more batteries in some embodiments. As described in further detail below with reference to Figures 5 A to 8B, battery 230 may be removable and replaceable from device 110. Battery 230 may be a Lithium Metal/Ion battery in some embodiments. According to some embodiments, battery 230 may provide a battery life of around 12 months to device 110, assuming regular use.

Device 110 may also comprise a communications module 240, which may be configured to facilitate communication between device 110 and one or more other devices. For example, communications module 240 may facilitate communications between device 110 and one or more fixed tracking devices 120. Communications module 240 may form part of processor 210 in some embodiments.

According to some embodiments, communications module 240 may comprise a micro electronic radio transmitter and receiver. Communications module 240 may facilitate communication via a wireless communications protocol such as Wi-Fi or Bluetooth, or may use a custom communications protocol in some embodiments. According to some embodiments, communications module 240 may send data as described below with reference to Figures 22A to 22D. According to some embodiments, communications module 240 may comprise a radio frequency transmitter and receiver.

According to some embodiments, communications module 240 may comprise an oscillator, to stabilise frequencies to assist in transmission and receipt of signals by communications module 240. The oscillator may be a crystal oscillator, such as the EPSON TSX-3225 crystal oscillator, for example.

To facilitate communications, device 110 may further comprise an antenna 250. According to some embodiments, antenna 250 may form part of communications module 240. Antenna 250 may be a specifically tuned antenna, and may be printed on a circuit board in some embodiments. An example antenna 250 is shown in further detail in Figure 4A, and described with reference to Figures 22A to 22D.

Device 110 may also include a user interface 260. In order to keep the power consumption of device 110 low, user interface 260 may be a low power consumption user interface. According to some embodiments, user interface 260 may comprise a light emitting component. User interface 260 may include one or more LEDs, for example. According to some embodiments, user interface 260 may comprise one or more RGB LEDs. According to some embodiments, user interface 260 may additionally or alternatively comprise a buzzer, speaker, motor, or other user interface device.

Turning to fixed tracking device 120, device 120 includes a processor 270. Processor 270 may include one or more data processors for executing instructions, and may include one or more of a microcontroller-based platform, a suitable integrated circuit, and one or more application- specific integrated circuits (ASIC's). Processor 270 may include an arithmetic logic unit (ALU) for mathematical and/or logical execution of instructions, such as operations performed on the data stored in internal registers of processor 270.

Processor 270 may have access to memory 280. According to some embodiments, memory 280 may form part of processor 270. Memory 280 may include one or more memory storage locations, which may be in the form of ROM, RAM, flash, or other memory types. Memory 280 may store program code 281, which may be executable by processor 270 to cause processor 270 to perform functions as described in further detail below.

For example, according to some embodiments program code 281 include a data send/receive module 228, which may be executable by processor 270 to cause processor 270 to receive proximity event data from a device 110, and to send proximity event data received from a device 110 to a gateway device 130. This is described in further detail below with reference to Figures 16 to 18.

Memory 280 may also comprise data 283. Data 283 may include a unique identification number 284 that may be used to identify device 120. Identification number 284 may be stored in memory 280 as permanent or un-rewritable data. Data 283 may also include proximity event data 285, which may be temporary data used to record information relating to proximity events received from device 110 when executing data send/receive module 281.

Device 120 further comprises a power source in the form of battery 290. Battery 290 may comprise one or more batteries in some embodiments.

Device 120 may also comprise a communications module 292, which may be configured to facilitate communication between device 120 and one or more other devices. For example, communications module 240 may facilitate communications between device 120 and one or more devices 110 and gateways 130. Communications module 292 may form part of processor 270 in some embodiments.

According to some embodiments, communications module 292 may comprise a micro electronic radio transmitter and receiver. Communications module 292 may facilitate communication via a wireless communications protocol such as Wi-Fi or Bluetooth, or may use a custom communications protocol in some embodiments. According to some embodiments, communications module 292 may comprise a radio frequency transmitter and receiver.

To facilitate communications, device 110 may further comprise an antenna 294. According to some embodiments, antenna 294 may form part of communications module 292.

Figures 3A to 3E show the physical features of device 110 in further detail. Device 110 comprises a battery housing 310, and a clip 320. Battery housing 310 defines a cavity configured to contain battery 230, while clip 320 comprises the other electronic components such as the processor 210, memory 220, communications module 240 and antenna 250. A user interface 260 in the form of an LED may be positioned on clip 320. According to some embodiments, housing 310 and clip 320 may be formed to meet IP67 standards, making device 110 washable.

As shown in Figures 3B, clip 320 comprises a bridge portion 322, and an end portion 326. Bridge portion 322 connects housing 310 to clip 320 both physically and electrically, providing a means for power from battery 230 to be supplied to processor 210, memory 220, communications module 240, antenna 250 and user interface 260. According to some embodiments, bridge portion 322 comprises a clip joining bar 410, as described below in further detail with reference to Figures 4B and 4C. Clip joining bar 410 may be configured to slide into a mating slot 610 formed in battery housing 310, allowing clip 320 to be selectively coupled and decoupled from battery housing 310, as shown in Figures 6A to 8B. Bridge portion 322 may be between 5mm and 20 mm long, between 1mm and 10mm wide, and between 1mm and 5mm thick according to some embodiments. For example, bridge portion may be around 10mm long, 5mm wide, and around 3mm thick according to some embodiments.

End portion 326 allows clip 320 to hold identification cards and access cards, as described in further detail below with reference to Figures 9B and 9C. This also allows device 110 to be integrated with existing known processes for access to events and premises by individuals, who may already be required to wear a lanyard or nametag, such as users shown in Figures 25 and 27B, for example.

Clip 320 allows device 110 to be positioned in a reliably oriented place on an individual’s body, such as a position on the torso. For example, device 110 may be attached via clip 320 to a user’s chest pocket, belt or waistband. This avoids some of the reliability issues caused by devices that may be worn on a user’s wrist, which may be subject to frequent movement and orientation shifts. A position on the torso is also a safer position, as it is less at risk of being caught during de-gloving or operation of machinery, and is less susceptible to bloods or other fluids contacting the device in a medical environment. This means device 110 may need less cleaning and sanitation than devices worn on a wrist, for example.

According to some embodiments, the body of clip 320 may function as antenna 250. Specifically, the body of clip 320 may be configured to act as a micro multi-frequency radio transmission module and tuned antenna board. According to some embodiments, clip 320 may be between 10mm and 50mm long, between 10mm and 20mm wide, and between 0.5mm and 2mm thick. For example, clip 320 may be around 30mm long, 14mm wide and 1mm thick.

Figures 4A to 4C show clip 320 in further detail. As seen in Figures 4B and 4C, clip 320 comprises a clip joining bar 410, to enable clip 320 to be attached to a variety of different housings 320, as shown in Figures 6A to 8B. Figures 4A and 4B also show an example antenna 250 which includes a spiral portion 420, as described below in further detail with reference to Figures 22B and 22D.

Figures 5A to 5B show housing 310 and battery 230 in further detail. Figure 5A shows a view of device 110 showing a battery compartment cover 510. In Figure 5A, cover 510 is in a locked position. In Figure 5B, cover 510 has been rotated or twisted, causing it to adopt an unlocked position, allowing cover 510 and battery 230 to be removed from device 110. Figure 5C shows cover 510 being removed, with battery 230 becoming visible. Figure 5D shows battery 230 removed from device 110, exposing cavity 530, which may be configured to contain battery 230. As illustrated, the interior of cover 510 may act as a holder for battery 230. Together, cavity 530 and cover 510 may be adapted to receive and electrically couple to one or more batteries 230, which may include CR123, AA, AAA, CR2032, other coin cell CR20XX batteries or other battery types. For example, battery 230 may be a CR123 Lithium 3V battery in some embodiments.

Figures 6A to 8B show alternative configurations of housing 310 for accepting different form factors of battery 230. Figures 6A and 6B show a housing 310 configured to accept a battery 230 that is a AA or CR123 battery. Figures 6A and 6B further show clip 320 separated from housing 310. Clip joining bar 410 is configured to slidably couple with mating slot 610 formed in housing 310.

Figures 7A and 7B show a housing 310 configured to accept a battery 230 that comprises two AAA batteries. Figures 7A and 7B also show clip 320 separated from housing 310.

Figures 8A and 8B show a housing 310 configured to accept a battery 230 that comprises a coin cell battery, which may be a CRXX type battery. For example, battery 230 may be a CR2032 or CR2477 battery in some embodiments. Figures 8A and 8B also show clip 320 separated from housing 310.

Figures 9A to 9C show different way in which device 110 may be worn on the body of an individual. In Figure 9A, device 110 is worn in a pocket 910, with battery housing 310 located inside the pocket and clip 320 located outside the pocket. In Figure 9B, device 110 further allows an identification or access card or badge 920 to be coupled to end portion 326 of clip 320.

In Figure 9C, device 110 is worn on a lanyard 930, with a badge 920 coupled to clip 320 as in Figure 9B. Device 110 may include a hook 940 to allow a lanyard 930 to be clipped to device 110, so device 110 can be worn as shown.

A method of determining a proximity event as executed by processor 210 of device 110 executing proximity event module 222 is shown in Figure 10. At step 1005, device 110 is turned on or activated, which may be done by inserting battery 230, switching on a switch or button as described below with reference to Figures 26A and 26B, or another means. Once device 110 is turned on and activated, processor 210 begins executing module 222 to determine whether a proximity event has occurred. At optional step 1010, processor 210 executing module 222 may be configured to associate device 110 with an individual, such as by receiving details of the individual and storing them in memory 220. According to some alternative embodiments, device 110 may be associated with an individual by storing the identification number 225 in a database external to device 110 in association with details of the individual with whom the device is associated. For example, association data may be stored in database 160, as described above with reference to Figure 1.

At step 1015, processor 210 executing module 222 may cause communications module 240 to listen for broadcast signals. According to some embodiments, communications module 240 may constantly be listening to broadcast signals from other devices. According to some embodiments, communications module 240 may be configured to listen for broadcast signals periodically.

At step 1020, processor 210 executing module 222 checks whether any signals have been received by communications module 240. If no signals have been received, processor 210 continues by executing step 1045, as described below. If processor 210 determines that a broadcast signal has been received, processor 210 instead executes step 1025.

At step 1025, processor 210 executing module 222 sends a conversation packet to the device from which the detected broadcast signal was received. At step 1030, processor 210 executing module 222 checks whether an acknowledgement was received from the device. If an acknowledgement was received, processor 210 returns to step 1025, sending a further conversation packet, and awaiting further acknowledgement.

If no acknowledgment is received, processor 210 moves to step 1035, at which it determines whether the recent interaction resulted in a proximity event. According to some embodiments, processor 210 may determine whether the interaction was a proximity event by comparing data relating to the interaction with data stored in data 224 of memory 220. For example, processor 210 may determine whether the device with which the interaction occurred was within a predetermined distance from device 110. Furthermore, processor 210 may determine whether the duration of the interaction exceeded a predetermined threshold. Examples of proximity events are described below in further detail with reference to Figures 14A to 15C. If processor 210 determines that a proximity event has not occurred, processor 210 returns to step 1015, and continues to listen for broadcast signals. If processor 210 determines that a proximity event has occurred, processor 210 continues to step 1040. At step 1040, processor 210 executing module 222 records proximity event data in memory 220 as data 226. The stored data may include an identification number of the device with which the proximity event occurred, the duration of the proximity event, and the distance between device 110 and the device with which the proximity event occurred during the event. The distance may be determined by processor 210 based on an Received Signal Strength Indicator (RSSI) of the signal received from the device. Once the data is recorded, processor 210 returns to step 1015, and continues to listen for broadcast signals.

If a broadcast signal is not detected at step 1020, processor 210 then executes step 1045. At step 1045, processor 210 checks whether it is time for device 110 to broadcast a signal. According to some embodiments, device 110 may broadcast signals periodically, in order to save power. If it is not time to broadcast a signal, processor 210 returns to step 1015, and continues to listen for broadcast signals.

If it is time to broadcast a signal, processor 110 moves to step 1050. At step 1050, processor 210 executing module 222 broadcasts a signal. The signal may include the identification number 225 of device 110. At step 1055, processor 210 checks whether a conversation packet was received in response to the broadcast signal.

If no response was received, processor 210 continues by executing step 1035, as described above. If a response was received, processor 210 proceeds to step 1060.

At step 1060, processor 210 executing module 222 sends an acknowledgement in response to the received response, and returns to step 1055 to see if a further conversation packet is received.

Figure 11 shows an example flowchart 1100 of method 1000 being executed by two devices, 110A and 110B.

At steps 1102 and 1112, both devices 110A and 110B are activated, as described above with reference to step 1005 of method 1000. At step 1104 and 1114, devices 110A and 110B are optionally also associated with an identity record of a person, as described above with reference to optional step 1010 of method 1000. Whether or not devices 110A/110B were associated with an individual, at step 1106 and 1116 devices 110A and 110B may be configured to enter an “Alone” mode, as no proximity has yet been detected, and caused to scan for nearby devices.

At steps 1108 and 1118, devices 110A and 110B listen for broadcasts, as described above with reference to step 1015 of method 1000. At step 1110, device 110A transmits a packet, as described above with reference to step 1050 of method 1000.

At step 1120, device 110B detects the broadcast signal, as described above with reference to step 1020 of method 1000. Device 110B further receives and records a RSSI signal from device 110A, to assist device 110B in determining the distance between device 110A and 110B.

At step 1122, device 110B becomes the master in the conversation between device 110A and 110B. Acting as a master, device HOB sends a conversation packet to device 110A, as described above with reference to step 1025 of method 1000.

At step 1124, device 110A acting as the slave receives the conversation packet, as described above with reference to step 1055 of method 1000. At step 1126, device 110A acknowledges the conversation packet, as described above with reference to step 1060 of method 1000.

At step 1128, device HOB acting as the master receives the acknowledgement, as described above with reference to step 1030 of method 1000. At step 1130, device HOB sends a further conversation packet to device 110A, as described above with reference to step 1025 of method 1000.

At step 1132, device 110A acting as the slave receives the further conversation packet, as described above with reference to step 1055 of method 1000. At step 1134, device 110A acknowledges the further conversation packet, as described above with reference to step 1060 of method 1000.

At step 1136, device HOB acting as the master receives the acknowledgement, as described above with reference to step 1030 of method 1000. At step 1138, steps 1122 to 1136 are repeated until device 110A and device 110B can no longer detect one another. According to some alternative embodiments, method 1100 may also terminate if a specified duration or an incremental number of short distance signals have been detected during the conversation between devices 110A and 110B, or if a specific duration of medium or long distance signals have been detected, at which point each device 110A and 110B may determine that a proximity event has occurred.

Figure 12 shows an example flowchart 1200 of method 1000 being executed by three devices, 110A, 110B and HOC. In flowchart 1200, devices 110A and 110B are already in conversation when the method begins.

Flowchart 1200 starts at step 1202, with device 110B, acting as a master, sending a conversation packet to device 110A, as described above with reference to step 1025 of method 1000.

At step 1204, device 110A acting as the slave receives the conversation packet, as described above with reference to step 1055 of method 1000. At step 1206, device 110A acknowledges the conversation packet, as described above with reference to step 1060 of method 1000.

At step 1208, device 110B acting as the master receives the acknowledgement, as described above with reference to step 1030 of method 1000. At step 1210, device 110B sends a further conversation packet to device 110A, as described above with reference to step 1025 of method 1000.

At step 1212, device 110A acting as the slave receives the further conversation packet, as described above with reference to step 1055 of method 1000. At step 1214, device 110A acknowledges the further conversation packet, as described above with reference to step 1060 of method 1000.

At step 1216, device 110B acting as the master receives the acknowledgement, as described above with reference to step 1030 of method 1000.

At step 1218, device 110B transmits a broadcast packet, as described above with reference to step 1050 of method 1000. In the meantime, the exchange between devices 110A and 110B continues as described above. According to some embodiments, each device 110 may be able to participate in up to 20 concurrent conversations.

Device HOC enters “Alone” mode at step 1220, and is listening for a broadcast at step 1222, as described above with reference to step 1015 of method 1000.

At step 1224, device HOC detects the broadcast signal, as described above with reference to step 1020 of method 1000, and becomes the slave in the conversation between device HOB and HOC.

At step 1226, device HOC acknowledges the conversation packet, as described above with reference to step 1060 of method 1000.

At step 1228, device HOB receives the acknowledgement, as described above with reference to step 1030 of method 1000.

At step 1230, steps 1218 to 1228 are repeated until device HOB and device HOC can no longer detect one another.

A further example of the interaction between two devices 110A and HOB is shown in Figure 13.

At steps 1305 and 1310, devices 110A and HOB are each listening for a broadcast signal, as described above with reference to step 1015 of method 1000. According to some embodiments, devices 110A and HOB may listen continuously. According to some embodiments, devices 110A and HOB may listen periodically. For example, devices 110A and 110 may listen every 0.1 to 1 second, and may listen every 0.5 seconds in some embodiments.

At step 1315, device HOB broadcasts a signal, as described above with reference to step 1050 of method 1000. According to some embodiments, devices 110A and HOB may be configured to broadcast periodically. For example, devices 110A and HOB may be configured to broadcast every 1 to 5 minutes, and may broadcast every 2 minutes in some embodiments. Once device 110A detects the broadcast, devices 110A enter a conversation, as shown by steps 1320 and as described above with reference to steps 1025, 1030, 1055 and 1060 of method 1000. According to some embodiments, during the conversation steps 1320, devices 110A and 110B may be configured to transmit and receive packets more rapidly than their periodic broadcast when they are not in a conversation. For example, devices 110A and 110B may transmit packets every 15 to 45 seconds, and may transmit every 30 seconds in some embodiments. Each time a packet is received by a device 110A or 110B, processor 210 of the device 110A or 110B records an RSSI for the received packet, and translates this into a distance between devices 110A and 110B.

Once a conversation is complete, being when devices 110A and 110B can no longer detect one another, processor 210 determines whether to log the conversation or interaction as a proximity event, as described in further detail above with reference to step 1035 of method 1000. According to some embodiments, processor 210 may determine that a proximity event has occurred when a predetermined condition has been met, as described below in further detail with reference to Figures 14A and 14B. The conditions may include:

1) when processor 210 determines that the conversation between devices 110A and 110B continued for more than a first predetermined time period Tn at a distance less than a first distance threshold Dl;

2) when processor 210 determines that multiple periods of conversation between devices 110A and 110B when aggregated add up to more than a second predetermined time period, which may be 2 x Tn, at a distance less than a first distance threshold Dl; or

3) when processor 210 determines that the conversation between devices 110A and 110B continued for more than a third predetermined time period Te at a distance less than a second distance threshold D2, wherein the third predetermined time period Te is longer than the first predetermined time period Tn and the second distance threshold D2 is larger than the first distance threshold Dl.

A conversation may be considered to be interrupted if devices 110A and 11B move out of each other’s detection range for a period of three consecutive scans. According to some embodiments, an interrupted conversation may be logged by processor 210 as a proximity event if the devices were within the first distance threshold at any point in time during a conversation. If processor 210 determines a proximity event, at steps 1325 and 1330, and as described in further detail above with reference to step 1040 of method 1000, the conversation data is recorded to memory 220 as proximity event data 226.

Once proximity event data 226 has been recorded, processor 210 may commence executing data sending module 223, in an attempt to send the proximity event data 226 to a fixed tracking device 120. At steps 1335 and 1340, devices 110A and 110B scan for a fixed tracking device 120. Once they locate a fixed tracking device 120, at steps 1345 and 1350 devices 110A and 110B send proximity event data 226 to fixed tracking device 120 via communications module 240 using antenna 250. Steps 1335, 1340, 1345 and 1350 are described in further detail below with reference to Figures 16 and 17.

Figures 14A and 14B shows diagrams 1400 and 1450 illustrating four examples of interaction between devices 110 and device 120.

Interaction 1410 involves devices 110A and 110B coming within a first distance threshold D1 of each other for a time threshold of Tn. According to some embodiments, the time threshold Tn may be met with a series of aggregated interactions. This interaction would result in a proximity event being generated by processor 210. According to some embodiments, processor 210 may determine this interaction to be a “contact” event. According to some embodiments, D1 may be around 1.5m. Interaction 1420 involves devices 110A and HOC coming within a second distance threshold D2 of each other, which may be longer than Dl, for a time threshold of T2, which may be longer than Tl. According to some embodiments, the time threshold T2 may be met with a series of aggregated interactions. This interaction would result in processor 210 generating a proximity event. According to some embodiments, processor 210 may determine this interaction to be a “warning” event. According to some embodiments, D2 may be around 5m.

Interaction 1430 involves devices 110A and 110D coming within a third distance threshold D3 of each other, which may be longer than D2, for a time threshold of T3, which may be longer than T2. According to some embodiments, the time threshold T3 may be met with a series of aggregated interactions. This interaction would result in a proximity event being generated by processor 210. According to some embodiments, processor 210 may determine this interaction to be a “vicinity” event.

Interaction 1440 involves device 110A coming within a fourth distance threshold D4 with a fixed tracking device 120. Once devices 110A and 120 are in range, device 110A can transfer proximity event data 226 to device 120, as described below with reference to Figures 16 and 17. The time at which the data is transferred and the position when the data is sent may be recorded as Tp. According to some embodiments, D4 may be around 20m.

Once fixed tracking device 120 receives the data 226, device 120 may send this to gateway 130 as described below with reference to Figure 18, which may transmit the data to server system 140. The data may then be stored in database 160. According to some embodiments, database 160 may be configured to assimilate information from multiple devices 110 and 120, including information regarding identification number 225 of each device 110 and an individual with whom the device is associated; the identification number 284 of each device 120 and a location with which the device is associated; contact events including contact, warning and vicinity events recorded by each device 110 and the device with which they interacted; and contact events including contact, warning and vicinity events recorded by each device 120 and the device from which they received the contact data.

With the data stored in database 160, a government, business or organisation in charge of system 100 may be able to determine whether contact occurred based on their own definitions of a contact event. Figures 15A to C shows a number of example contact events that a government, business or organisation may wish to track using system 100.

Figure 15A shows a scenario 1500, where a contact event is defined similarly to the contact events described above with reference to Figure 14. Contact is defined as a proximity of distance A or less for a duration of B or more.

Figure 15B shows a scenario 1530, where a contact event is defined as proximity at any distance within an enclosed space for a duration of C or more. System 100 may allow for the detection of contact events as per scenario 1530 by detecting any devices 110 within range of a device 120 that is configured as an indoor device. As an indoor device 120 may be configured such that it cannot transmit through walls, any devices 110 that interact with device 120 can be considered to have made contact with one another.

Figure 15C shows a further scenario C, where an individual 1570 has a communicable disease with an infectious period D. Any interaction with the device 110 of individual 1570 may be considered a contact event.

Figure 16 shows a method 1600 performed by a device 110 and a fixed tracking device 120 that allows for contact events recorded by device 110 to be transmitted to device 120. The steps performed by device 110 may be performed by processor 210 executing data sending module 223, while the steps performed by device 120 may be performed by processor 270 executing data send/receive module 282.

At step 1605, device 110 is activated, and at step 1610, device 110 is in “Alone” mode. At step 1615, device 110 listens for broadcast signals.

In the meantime, at step 1620 device 120 is activated, and at optional step 1625 device 120 is associated with a known point in space in which device 120 is located. According to some embodiments, device 120 may be configured to store a location with which it is associated in an internal memory location. According to some alternative embodiments, device 120 may be associated with a location by storing an identification number of device 120 in a database external to device 120 in association with the location information. For example, association data may be stored in database 160, as described above with reference to Figure 1. At step 1630, device 120 listens for broadcast packets.

At step 1635, device 110 transmits a broadcast packet, and at step 1640 the packet is received by device 120. At step 1640, device 120 becomes the master of the interaction, and sends a conversation packet to device 110.

At step 1650, device 110 becomes the slave and receives the conversation packet. At step 1655, device 110 acknowledges the conversation packet, and device 120 received the acknowledgement at step 1660. Also at step 1660, device 120 determines the RSSI of the received acknowledgement signal. At step 1665, device 110 transfers the stored proximity event data 226 to device 120 as one or more contact event log packets, which are received by device 120 as step 1670.

At step 1675, device 120 transmits an acknowledgement of the receipt of the data, which is received by device 110 at step 1680. Having received the acknowledgement, device 110 may delete the proximity event data 226 from memory 220.

Figure 17 shows a diagram 1700 illustrating a number of scenarios relating to device 110 transmitting data to device 120. Device 110 may be configured to scan for devices 120 to transmit to as soon as a proximity event is recorded in proximity event data 226.

In scenario 1710, device 110 records a proximity event at step 1701 and scans for devices 120 at step 1702. According to some embodiments, device 110 may perform a scan for devices 120 every 5 to 20 minutes, which may be every 10 minutes in some embodiments. At step 1702, a device 120 is detected and device 110 transmits data 226 as described above with reference to Figure 16.

In scenario 1720, device 110 undertakes a number of regular scans. No device 120 is detected, so device 110 undertakes a power scan at step 1711. A power scan may use more power and increase the range of detection of device 110. If the power scan detects a device 120, device 110 then transmits data 226 to device 120 using a power transmit at step 1712, which uses more power and increases the range of transmission of device 110.

In scenario 1730, the power scan is unsuccessful, and device 110 goes back to regular scans at step 1731. A device 120 is detected and data is transmitted with a regular transmit procedure.

In scenario 1740, device 120 is unable to be detected by device 110 for a duration of a configurable infectious period D. For example, period D may be between one week and four weeks, and may be two weeks in some embodiments. After duration D has elapsed, device 110 may discard proximity event data 226, or allow it to be overwritten.

Figure 18 shows a method 1800 performed by device 120 and gateway 130, that causes received proximity event data to be transmitted from device 120 to gateway 130. The steps performed by device 120 may be performed by processor 270 executing data send/receive module 282.

At step 1805, device 120 is activated, and at step 1810 device 120 scans for a gateway device 130. Meanwhile, at step 1820 gateway 130 is activated, and at step 1825 it is associated with a server system 140 and/or a database 160.

At step 1830, gateway 130 transmits beacon packets to all devices within range, and at step 1815 device 120 detects a gateway beacon packet.

At steps 1835 and 1840, devices 120 and 130 perform a secure handshake.

At step 1845, device 120 transfers one or more packets containing proximity event data in the form of a contact event log to device 130. This transmission may be by a Long Range Radio Network Technology which can reach more than 1 km. Device 130 receives the packets at step 1850, and transmits acknowledgement at step 1855.

At step 1860, device 120 receives the acknowledgement, and may delete the contact event log from memory. At step 1865, gateway 130 then transmits the received log to database 160 via server system 140.

If an individual is found to have contracted a communicable disease, the identification number that was associated with their device 110 may be searched for within database 160, returning all contact events recorded for that identification number. Each contact event may contain the corresponding identification numbers for other devices 110 associated with individuals who are at risk of contracting the disease. A government, business or organisation can use this information to rapidly isolate and test only the people identified within the search. Furthermore, a government, business or organisation can also use this information to identify which zones in a specific location should be quarantined for deep cleaning to disinfect the area.

The targeted contact tracing method as described above with reference to Figures 10 to 18 removes the need for unnecessarily shutting down an entire facility or site and/or forcing entire populations to self-isolate for long periods of time. This reduces the health risk of individuals so they can gain treatment faster and also prevent spread of infection to others as well as reduce the financial and productivity loss impact of shutdowns and workforce isolations

Figure 19 shows an example diagram 1900 of devices 110 and 120 being used in an indoor environment, such as an office building. According to some embodiments, device 120 may be configured for indoor use. When device 120 is configured for indoor use, device 120 may have a range of 500m, and may be able to transmit and receive through walls and obstructions. According to some embodiments, the network strength and/or frequency of device 120 may be tuned to prevent false detection between floors of a multi- storey building.

Figure 20 shows an example diagram 2000 of devices 110 and 120 being used in an outdoor environment, such as on a campus or work site. According to some embodiments, device 120 may be configured for outdoor use. When device 120 is configured for outdoor use, device 120 may have a range of 5 kilometers, but may only be able to transmit and receive signals in a line of sight.

Previously used mechanisms to facilitate the process of contact tracing include human memory, witnesses, video and audio recordings, mobile phones and wearable devices. However, these mechanisms each have a number of deficiencies. For example, contact tracing processes using manual means to gather data to identify historical human interactions is imperfect, inaccurate, time consuming and expensive. Contact tracing using mobile phone data can be considered to be invasive of user privacy, and businesses and organisations cannot force an individual to install software on their personal phone to issue the tracing data to the government, business or organisation. Contact tracing processes using existing proximity detection technology in wearable electronics is problematic due to limitations in detection accuracy, detection range, distance accuracy, detection frequency, detection concurrency (density) and associating a detection event with an identifiable position.

Proximity detection and subsequent interpretation of physical distance between two wireless devices is typically achieved via mathematical algorithms applied to the Received Signal Strength Indicator (RSSI) detected between the Radio Network Transceiver (Tx) and Radio Network Receiver (Rx) of each respective device. Measured RSSI accuracy can be affected by many variables, such as the orientation of radio antennas, reflections of network signal off surfaces, physical objects in between the two radio antennas, and interference from other radio signals.

Previous methods for tracking and tracing interactions between devices often resulted in inaccuracies due to weaknesses in the data transmission protocol. Figure 21 A shows an ideal scenario, where in an anechoic chamber it is possible to accurately determine distance 2130 between two devices 2110 and 2120 based on the RSSI of a radio signal emitted from one transceiver 2110 and detected by another 2120.

However, as shown in Figure 2 IB, radio transceivers 2160 placed on individuals in enclosed environments are subject to constant environmental factors that interfere with RSSI which effects the ability to estimate distance with accuracy. These factors include obstacles such as walls, as well as the orientation of transmission. Radio devices 20160 worn on humans that are constantly moving around an environment are subject to constant change and exposure to these variables that affect accurate position measurement.

In order to improve the accuracy of distance measurement and positioning using radio networks, existing wearable technologies rely on a variety of complex mathematical algorithms and approaches. These approaches involve more computational intensive processing capabilities on the wearable device, driving up device cost and overall power consumption. These approaches can require that the radio transceiver and receivers spend more time “on air”, also driving up overall power consumption and network interference levels.

High power consumption limits battery life, requiring the battery to be frequently replaced or recharged, both of which can make cost and maintenance of the device impractical in large scale use. The battery size and charging requirements also mean wearable devices with contact tracing capability may generally be formed as either wristband devices or as pendants. However, these can both be inconvenient to wear and unsuitable for some workplaces, such as workplaces where health and safety regulations prevent external worn items that can be caught in machinery or interfere with work activities such as factory line focus tasks or patient care. Some described embodiments relate to wearable network devices 110 comprising radio frequency (RF) transmission and receivers that use low power wireless network communication to provide tracking and tracing of individuals.

Figures 22A to 22D illustrate an ultra-low power multi-frequency technique that can be used to improve RSSI accuracy.

At locations with many reflective surfaces where the direct signal and reflected signal path-length differ a half wavelength, the direct wave and reflected wave may be subtracted from one another and cancel each other out. As a result, the path loss may have sharp dips caused by reflections. One method for overcoming this issue is to use a wide band radio transceiver to listen for packets emitted over multiple frequency bands with significantly different frequencies, as shown in Figure 22A. As the deep null that can be caused by reflections in the one frequency band should not be present in other frequency bands having significantly different frequencies, the cancellation of the signal caused by reflections can be mitigated. For example, a packet can be transmitted at both 433 MHz and 923 MHz, as shown in Figure 22A. While the RSSI for the 923 MHz packet may return a distance of zero due to reflections in some circumstances, in those circumstances the RSSI for the 433 MHz packet should return a more accurate measurement. The RSSI returning a distance of zero can therefore be ignored.

A further technique to improve transmissions is illustrated in Figure 22B. Taking the distance between two transceivers to be r, in the far field the signal level attenuates at a rate of 1/r, but in the near field the signal attenuates at a rate of 1/r². By transmitting out of band using an antenna tuned for a specific frequency, the far field properties of the detected RSSI will be attenuated or reduced to near zero, while near field laws will be amplified to more than 2 wavelengths. For example, a packet can be transmitted at 433 MHz via a 923MHz antenna. This enables a high accuracy RSSI measurement to be determined when two devices 110 are within 2m of each other. As shown in the illustrated embodiment, in the far field the signal is 0.1 wavelength, while in the near field this is amplified to 2 wavelengths, allowing an accurate RSSI and therefore distance to be determined. To utilise the technique of Figure 22B, additional elements may be added to antenna 230 to tune it to a specific frequency. For example, as illustrated in Figure 22B and in further detail in Figure 4A, spiral elements 420 may be incorporated into antenna 250. Sound travels at approximately 0.34 meter/millisecond. By transmitting a third very low frequency signal, which may be a 40 kHz ultrasonic signal, for example, a very accurate range over short distance can be detected. This is illustrated in Figure 22C. Antenna 230 comprises an additional ultrasonic resonator, which allows a third frequency mode to be transmitted, targeting different elements of the antenna 230. For example, a packet may be transmitted at 40 kHz using the additional resonator element. By comparing the delta between the speed that electromagnetic waves travel between points and the time that sound travels, very accurate range over short distance can be detected.

The combination of the three techniques described above with reference to Figures 22A, 22B and 22C can provide highly accurate contact detection and range estimates at short distances. As shown in Figure 22D, transmission of all three frequencies during provides four range values which are evaluated using a software algorithm by processor 210 to determine the most likely range improving accuracy in short distances.

Figures 23A to 23C illustrate some other known issues with previous wearable tracking devices. As shown in Figure 23A, personal mobile phones, smart watches and pendants are undesirable to use as tracking devices due to privacy issues. Providing a duplicate phone to users for tracking purposes is also expensive and impractical to carry around.

Furthermore, as shown in Figure 23B, previous wearables needed frequent recharging, making them inconvenient to use over long periods of time. For example, some previously known devices need charging every 48 hours, or even more frequently.

As shown in Figure 23C, lanyards and or neck bracelets pose an Occupational Health and Safety issue as they can get caught in machinery and pose a choking risk. Wristbands also pose an Occupational Health and Safety issue as they can get caught in machinery and pose a "de-gloving"' risk. They are also more subject to contamination by contaminants in the environment due to being located close to a user’s hands, so are a less hygienic option.

Figure 24 shows a number of industrial users 2400 of device 110, working in workplaces or occupations that require hands free, neck free, concealed PPE. These may include construction workers, mining/oil/gas workers, emergency workers, law enforcement workers, military workers, factory line workers, food preparation workers, medical workers, health care workers and travel assistance workers, for example. Workers 2400 as shown in Figure 24 may wear device 110 as shown in Figure 9A in some embodiments.

Figure 25 shows a number of corporate users 2500 of device 110, working in standard office environments. According to some embodiments, workers 2500 as shown in Figure 25 may wear device 110 with their workplace identification badge on a lanyard, as shown in Figure 9C.

Figures 26A and 26B show disposable form factors of device 110. Specifically, Figure 26A shows front and back views of a wristband format 2600 of device 110, while Figure 26B shows front and back views of an alligator clip format 2650 of device 110.

Wristband 2600 comprises an adjustable strap 2602, that allows a size of wristband 2600 to be adjusted, and a fastener 2604 that allows wristband 2600 to be secured to the wrist of a wearer. According to some embodiments, fastener 2604 may be a tamper proof fastener, such that it cannot be easily unfastened after having been fastened.

Wristband 2600 further comprises a communication portion 2606, which may hold an embodiment of device 110. Device 110 may be coupled to a one-way dome latch switch 2610, which may cause device 110 to activate upon being pressed. Wristband 2600 may be formed as a fully encapsulated plastic moulded form. Battery 230 of device 2600 may comprise two CR2018 batteries, in some embodiments.

Alligator clip 2650 comprises a clip portion 2660 to allow clip 2650 to be attached to a pocket, waistband, belt, or other garment or accessory. Clip 2650 further comprises a communication portion 2670, which may hold an embodiment of device 110. Device 110 may be coupled to a one-way dome latch switch 2680, which may cause device 110 to activate upon being pressed. Clip 2650 may be formed as a fully encapsulated plastic moulded forms. Battery 230 of device 2650 may comprise two CR2018 batteries, in some embodiments.

Figure 27A shows a first group of embodiments 2700 of a disposable form factor of wearable device 110. Disposable devices 2700 may be in the form of lanyards 2710 or badge clips 2720 incorporating clips 2650. Figure 27B shows a group of potential users 2730 of disposable devices 2700. Users 2730 may include temporary visitors to an office space, or attendees at a conference, for example. Figure 27C shows a second group of embodiments 2740 of a disposable form factor of wearable device 110. Disposable devices 2740 may be in the form of wristbands, such as wristband 2600.

Figure 27D shows a group of potential users 2750 of disposable devices 2740. Users 2750 may include temporary visitors to a concert venue, fun park, or hospital, for example.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A device for facilitating tracking of interactions between individuals, the device comprising: a housing defining a battery compartment; a clip portion coupled to the housing, wherein the clip portion allows the device to be releasably coupled to a garment; an antenna for transmitting data to external devices; a memory; and a processor configured to execute program code to: broadcast a first signal; receive at least one response signal from a first external device in response to the first signal; determine a proximity event with the first external device based on the at least one response signal; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device.

2. The device of claim 1, further configured to transmit the stored data relating to the proximity event to a second external device.

3. The device of claim 1 or claim 2, where the first signal comprises a unique identification number associated with the device.

4. The device of any one of claims 1 to 3, wherein the data relating to the proximity event comprises a unique identification number received from and associated with the first external device.

5. The device of any one of claims 1 to 4, wherein the data relating to the proximity event comprises a time at which the proximity event occurred.

6. The device of any one of claims 1 to 5, wherein the processor is further configured to determine an RSSI based on the at least one response signal.

7. The device of claim 6, wherein the data relating to the proximity event comprises a distance between the device and the first external device determined based on the RSSI.

8. The device of claim 6 or claim 7, wherein the proximity event is determined based on comparing a distance between the device and the first external device determined based on the RSSI with a predetermined distance threshold.

9. The device of claim 8, wherein a proximity event is determined if the distance between the device and the first external device is less than the predetermined distance threshold.

10. The device of any one of claims 1 to 9, wherein the proximity event is determined based on comparing a duration of an interaction between the device and the first external device with a predetermined duration threshold.

11. The device of claim 10, wherein a proximity event is determined if the duration of an interaction between the device and the first external device is longer than the predetermined duration threshold.

12. The device of any one of claims 1 to 11, wherein the processor is further configured to: listen for a broadcast receive at least one response signal from a first external device in response to the first signal; determine a proximity event with the first external device based on the at least one response signal; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device.

13. A device for facilitating tracking of interactions between individuals, the device comprising: a housing defining a battery compartment; a clip portion coupled to the housing, wherein the clip portion allows the device to be releasably coupled to a garment; an antenna for transmitting data to external devices; a memory; and a processor configured to execute program code to: listen for a broadcast signal; receive at least one broadcast signal from a first external device; send at least one response signal to the first external device; and determine a proximity event with the first external device; and store data relating to the proximity event in a memory; wherein the antenna, memory and processor are located on the clip portion of the device.

14. The device of claim 13, further configured to transmit the stored data relating to the proximity event to a second external device.

15. The device of claim 13 or claim 14, where the response signal comprises a unique identification number associated with the device.

16. The device of any one of claims 13 to 15, wherein the data relating to the proximity event comprises a unique identification number received from and associated with the first external device.

17. The device of any one of claims 13 to 16, wherein the data relating to the proximity event comprises a time at which the proximity event occurred.

18. The device of any one of claims 13 to 17, wherein the processor is further configured to determine an RSSI based on the at least one broadcast signal.

19. The device of claim 18, wherein the data relating to the proximity event comprises a distance between the device and the first external device determined based on the RSSI.

20. The device of claim 18 or claim 19, wherein the proximity event is determined based on comparing a distance between the device and the first external device determined based on the RSSI with a predetermined distance threshold.

21. The device of claim 20, wherein a proximity event is determined if the distance between the device and the first external device is less than the predetermined distance threshold.

22. The device of any one of claims 13 to 21, wherein the proximity event is determined based on comparing a duration of an interaction between the device and the first external device with a predetermined duration threshold.

23. The device of claim 22, wherein a proximity event is determined if the duration of an interaction between the device and the first external device is longer than the predetermined duration threshold.

24. The steps, features, integers, compositions and/or compounds disclosed herein or indicated in the specification of this application individually or collectively, and any and all combinations of two or more of said steps or features.