EP3796282A2 - Device, system and method for fall detection - Google Patents

Device, system and method for fall detection Download PDF

Info

Publication number
EP3796282A2
EP3796282A2 EP20188159.6A EP20188159A EP3796282A2 EP 3796282 A2 EP3796282 A2 EP 3796282A2 EP 20188159 A EP20188159 A EP 20188159A EP 3796282 A2 EP3796282 A2 EP 3796282A2
Authority
EP
European Patent Office
Prior art keywords
fall detection
detection device
data
fall
sensor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20188159.6A
Other languages
German (de)
French (fr)
Other versions
EP3796282A3 (en
Inventor
Cristina Soaz González
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qolware GmbH
Original Assignee
Qolware GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qolware GmbH filed Critical Qolware GmbH
Publication of EP3796282A2 publication Critical patent/EP3796282A2/en
Publication of EP3796282A3 publication Critical patent/EP3796282A3/en
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08BSIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02Alarms for ensuring the safety of persons
    • G08B21/04Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0407Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons based on behaviour analysis
    • G08B21/043Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons based on behaviour analysis detecting an emergency event, e.g. a fall
    • GPHYSICS
    • G08SIGNALLING
    • G08BSIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02Alarms for ensuring the safety of persons
    • G08B21/04Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0438Sensor means for detecting
    • G08B21/0446Sensor means for detecting worn on the body to detect changes of posture, e.g. a fall, inclination, acceleration, gait
    • GPHYSICS
    • G08SIGNALLING
    • G08BSIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02Alarms for ensuring the safety of persons
    • G08B21/04Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0438Sensor means for detecting
    • G08B21/0453Sensor means for detecting worn on the body to detect health condition by physiological monitoring, e.g. electrocardiogram, temperature, breathing

Definitions

  • the present invention generally relates to a device, system and method for activity monitoring, more precisely a device, system and method for fall detection.
  • a well-known solution is to provide an alarm button that may be worn by the elderly person, who can trigger an alarm signal by pushing the button in case of a fall.
  • a person might be immobile due to injuries or even unconscious and thus unable to push the button.
  • the present invention relates to a fall detection device.
  • the fall detection device comprises at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data, at least one movement sensor, configured to generate data on the movement and/or orientation of the fall detection device, and at least one ambient sensor, configured to generate data on the ambient conditions of the fall detection device.
  • the present invention relates to a device for detecting a fall of the user, wherein the fall detection device comprises at least 3 different sensors.
  • the status sensor may sense if a device is worn which may be advantageous to rule out events wherein the fall detection is falling down when not being worn, for example from a table to the floor.
  • the movement sensor may detect the movement and or orientation of the device.
  • the ambient sensor may provide data on ambient conditions, for example temperature, pressure and/or altitude. This may be advantageous as it may further improve the accuracy of the fall detection. Further, it may for example provide valuable context for the calculation of the certainty of a fall occurrence.
  • such a fall detection device may enable a more reliable detection of falls of the user, i.e. it may reduce false positives and/or false negatives. This may be advantageous as it may reduce false alarms being send for example to care takers or family members of the user and for example increase the security of the user.
  • the fall detection device may be configured to be a wearable device, that is the fall detection device may be configured to be worn by a user. This may be advantageous as it may enable the user to take the fall detection to any location, i.e. it may be flexible. Additionally, the fall detection device can be configured to be worn around the wrist, e.g. in the form of a wristwatch. This may further be advantageous as a wristwatch may be easily accessible and comfortable to wear. Moreover, a fall detection device worn around the wrist may for example provide further functionality, such as the functionality of a watch, a smart watch, a health monitor and/or fitness tracker.
  • the at least one status sensor of the fall detection device may be at least one of a proximity sensor, configured to sense any object in close proximity, a heart rate sensor, configured to generate data on the users heart rate (HR), and a pulse oximeter, configured to generate data on the user's oxygen saturation and HR.
  • a proximity sensor configured to sense any object in close proximity
  • a heart rate sensor configured to generate data on the users heart rate (HR)
  • HR heart rate
  • a pulse oximeter configured to generate data on the user's oxygen saturation and HR.
  • the status may for example also be determined by the presence (or absence) of a vital sign.
  • This may be advantageous, as the presence of a vital sign may be a more reliable signal compared to a proximity sensor which only senses the presence of an object in close proximity.
  • a vital sign may be much harder to accidentally (or purposefully) generate without the fall detection device being worn. Again, this may be advantageous, as a fall may only be detected if the fall detection device is worn and thus providing a reliable status sensor may reduce the number of false alarms, e.g., as a result of the device falling on the floor without being worn.
  • the ambient sensor of the fall detection device may be an altimeter, configured to generate data on changes in altitude. This may be advantageous as a fall typically comprises a change in altitude, thus sensor data may provide a further indication if a fall has happened or not.
  • the altimeter may comprise a barometric pressure sensor configured to generate data on changes in the barometric pressure. Additionally, the altimeter may comprise a temperature sensor configured to generate data on the ambient temperature. This may be beneficial as the barometric pressure may also depend on the ambient temperature; thus, it may provide the means to estimate the altitude more precisely by also considering the ambient temperature.
  • the fall detection device may comprise a proximity sensor configured to sense objects in close proximity and provide corresponding data. Such a proximity sensor may therefore indicate if the device is worn.
  • a proximity sensor located on the inside of a wristwatch may sense the skin of the user when being worn, i.e. it may sense an object in close proximity which may indicate that the device is worn.
  • the fall detection device may comprise a heart rate sensor, configured to generate data on the heart rate (HR) of a user.
  • the heart rate sensor can be at least one of an electrocardiography (ECG) sensor and a photoplethysmography (PPG) sensor.
  • ECG electrocardiography
  • PPG photoplethysmography
  • the heart rate sensor may provide data on the heart rate of the user and/or through monitoring the sensor data determine if a vital sign is present as indication that the device is being worn.
  • the fall detection device may comprise a pulse oximeter configured to generate data on the HR and oxygen saturation of the user.
  • the pulse oximeter may also be a photoplethysmography (PPG) sensor, i.e. the sensor may sometimes be configured to generate data on the HR and oxygen saturation of the user.
  • PPG photoplethysmography
  • Knowledge of the oxygen saturation may provide a further indication of a fall of the user and/or may for example provide information on the severity of the fall and/or the user's condition.
  • the at least one movement sensor may be at least one of an accelerometer, configured to generate data on a physical acceleration of the fall detection device, a gyroscope, configured to generate data on an orientation of the fall detection device, and a magnetometer, configured to generate data on the orientation of the fall detection device. That is, the accelerometer may generate data on the physical acceleration of the device in at least one direction, preferably in three directions that are perpendicular to each other. The gyroscope and/or magnetometer may be configured to generate data on the orientation of the fall detection device within the three-dimensional space.
  • the fall detection device may comprise a memory, configured to store data and computer program code.
  • the memory may comprise at least one non-volatile storage device (e.g. a solid-state drive (SSD)) and/or at least one volatile storage device (e.g. random-access memory (RAM)).
  • SSD solid-state drive
  • RAM random-access memory
  • the fall detection device may comprise a processing unit, configured to operate the fall detection device.
  • the processing unit may comprise at least one microprocessor, such as a central processing unit (CPU) and/or at least one circuit, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), etc.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • FPGA field-programmable gate arrays
  • the processing unit may be configured to acquire data from at least one of the sensors continuously, at specified intervals or based on specific events. This may be advantageous for reducing the power consumption of the fall detection device.
  • the times at which data is acquired may vary for each sensor. For example, some sensor data may only be acquired in consequence to sensor data acquired (and potentially processed) form different sensors.
  • the processing unit may be configured to pre-process at least a subset of the acquired data.
  • the processing unit may pre-process the sensor data from the barometric pressure sensor and the temperature sensor to express the sensor data in terms of altitude.
  • the processing unit may further be configured to store at least a subset of the acquired and/or pre-processed data in the memory at specified intervals, continuously or based on specific events.
  • the processing unit may further be configured to process at least a subset of the acquired, pre-processed and/or stored sensor data. For example, it may be configured to extract statistical values, such as an average or a deviation, from at least a subset of the sensor data. Additionally or alternatively, the processing unit may be configured to run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data. That is, the acquired, pre-processed, processed and/or stored sensor data.
  • the processing unit may be configured to process at least a subset of the sensor data and/or run a fall detection algorithm with the aim of identifying fall events of the user. That is, based on the sensor data the processing may, through data processing and/or running of a fall detection algorithm identify potential fall events of the user.
  • the fall detection algorithm may further be configured to estimate the severity of a fall event based on at least a subset of the sensor data. This may be advantageous as for example different actions may be taken depending on different severity levels of the fall. For example, in case of a very severe fall an alarm may be directly send professional emergency services, whereas for a less severe fall only a family member may be contacted.
  • machine-readable program code may be stored in the memory, which may be configured to cause the processing unit to execute tasks and steps required to operate the fall detection device when executed on the processor or circuit.
  • the fall detection device may further comprise a user interface, configured to enable interactions with the user. This may be advantageous as it may for example provide the user with information, enable the user to modify settings and/or receive feedback from the user.
  • the user interface may comprise a screen, wherein the screen may be a touch screen.
  • the touch screen may further be configured to be pressure sensitive, i.e. the screen can distinguish between different levels of force. This may be beneficial as it may allow to provide different functionality of the user interface to the user, depending on the applied pressure.
  • the screen may be configured to adjust the level of brightness. This may be advantageous for reducing the power consumption, for example by reducing the level of brightness of the screen in low light situations.
  • the fall detection device may further comprise an ambient light sensor, configured to generate data on the illuminance.
  • the screen may be configured to adjust the brightness according to the ambient light sensor data.
  • the user interface may comprise at least one physical button configured to execute a predetermined action when actuated by the user. Additionally or alternatively, the user interface may comprise at least one virtual button configured to execute a predetermined action when actuated by the user.
  • a virtual button may for example be a button displayed on a touch screen, or a gesture detected though at least one sensor of the fall detection device, e.g., a certain movement registered by the movement sensor, such as tapping the fall detection device three times,
  • the predetermined action executed when the physical or virtual button is actuated may be one of triggering an alarm and aborting an alarm.
  • the predetermined action may depend on the alarm status of the fall detection device. For example, if the fall detection device has detected a fall based on at least a subset of the sensor data and subsequently triggered an alarm, the user may abort the alarm by actuating the corresponding physical or virtual button. Alternatively, if a user for example fell and the device did not register the fall, the user may still trigger an alarm by actuating the same button.
  • processing unit may be configured to control the user interface.
  • the fall detection device may comprise a communication unit, configured to communicate with external devices.
  • the communication unit can comprise at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM). Further, the communication unit may comprise at least one of a modem and a network device.
  • SIM card Subscriber Identity Module
  • eSIM embedded SIM
  • the communication unit may be configured to exchange data with a server via cellular and/or wireless networks.
  • the communication unit may send sensor data to a remote server, which may for example further analyse the data, or provide a subset of the data to a third party such as an emergency service.
  • the communication unit may be configured to establish a two-way communication between the fall detection device and another device such as a smartphone. That is, the fall detection device can for example establish and receive calls.
  • the communication unit may be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth®, ANT+ or ZigBee. Additionally or alternatively, the communication unit may be configured to communicate and exchange data via a low power wide area network (LPWAN), such as a Long Range Wide Area Network (LoRaWAN) or SigFox.
  • WPAN wireless personal area network
  • LPWAN low power wide area network
  • LiRaWAN Long Range Wide Area Network
  • SigFox SigFox
  • the communication unit may be configured to communicate with digital assistants, such as voice assistants, e.g. Alexa, Siri or Google Assistant. Further, the communication unit may be configured to communicate with smart home devices.
  • digital assistants such as voice assistants, e.g. Alexa, Siri or Google Assistant.
  • the communication unit may be configured to communicate with smart home devices.
  • the processing unit may be configured to send and receive processing instructions, sensor data, operational data, or the like via the communication unit.
  • the fall detection device may further comprise a battery, configured to power the fall detection device.
  • the battery may be removable. This may be advantageous for exchanging the battery, e.g., to keep the fall detection device ready for use.
  • the battery may comprise a capacity of at least 100mAh, preferably at least 300 mAh, even more preferably at least 500 mAh.
  • the battery may be rechargeable.
  • the fall detection device may be configured to recharge the battery wirelessly, e.g. through electromagnetic induction. Additionally or alternatively, the fall detection device may comprise a connector configured to receive a cable for a wired connection.
  • the connector may comprise a magnetic component. This may be advantageous for establishing a good connection between the connector and the device.
  • the connector may be configured to recharge the battery.
  • the connector is configured to communicate with external devices, e.g. via a Universal Serial Bus (USB) connection.
  • USB Universal Serial Bus
  • the processing unit may be configured to manage the power consumption of the device. This may be advantageous to prolong the time the fall detection device may be utilized without recharging.
  • the fall detection device may be configured to run for at least 1 day, preferably at least 3 days, more preferably at least 7 days without recharging or changing the battery.
  • the fall detection device can comprise at least one position sensor configured to determine and provide data on the position based on a global navigation satellite system, such as GPS or Gallileo. This may be advantageous when a user experiences a fall and requires help. In such situations the position may be determined and for example shared with an emergency service or a family member of the user.
  • a global navigation satellite system such as GPS or Gallileo.
  • the fall detection device may comprise a microphone, configured to generate data on an acoustic signal.
  • the microphone may be configured to generate data on acoustic signals within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the microphone may be configured to generate data on acoustic signals in at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. This may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • the fall detection device may comprise a loudspeaker, configured to produce sounds.
  • the loudspeaker may be configured to produce sounds within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the loudspeaker may be configured to produce sounds within at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. Again, this may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • the fall detection device may further comprise a blood sugar sensor, configured to generate data on the blood glucose level of the user.
  • the fall detection device may further comprise a blood pressure sensor, configured to generate data on the blood pressure of the user.
  • the fall detection device may further comprise a temperature sensor, configured to generate data on at least one of the ambient temperature and the body temperature of the user.
  • the additional sensors may provide further information for detecting fall events. Further they may for example provide data for estimating a probability for a fall of the user and/or data to estimate the severity of a fall event. Further, some data may for example be provided to emergency services or family members of the user to support them making evidence-based decisions about the actions needed to better help the user particularly in case of a fall.
  • the fall detection device may further comprise a haptic feedback unit configured to provide a haptic feedback to the user, e.g. in case of an alarm.
  • the haptic feedback unit may comprise at least one vibration motor configured to provide vibrations as feedback to the user. This may be advantageous for getting the users attention, for example if an alarm is triggered.
  • the fall detection device may be configured to connect to an external handheld device, such as a smartphone. Additionally, the fall detection device may be configured to be utilized as user interface for the handheld device, i.e. enable input to and output from the handheld device. Further, the fall detection device may be configured to display content from the external handheld device, such as messages, (push) notifications, applications or controls for applications, etc.
  • the fall detection device may comprise a radar sensor configured to generate data on a distance.
  • the fall detection device may further comprise an electrodermal activity sensor configured to measure the skin conductance. This may be advantageous as it may for example be indicative of the activity of the sympathetic nervous system and/or provide an indication for the hydration of the user, which may be particularly relevant for the elderly.
  • the present invention relates to a fall detection system for identifying a fall and triggering an alarm, the fall detection system comprising a fall detection device as described above.
  • the fall detection system may further comprise at least one external sensor, configured to provide additional data, e.g. on the vital signs or weight of a user.
  • a fall detection system may comprise a fall detection device and further at least one external sensor, e.g. a scale, an external heart rate monitor or a blood sugar sensor. This may be advantageous, as it may provide the system with sensor data of sensors that may for example not easily be incorporated in the fall detection device itself.
  • the fall detection device may be configured to communicate with and receive data from the external sensors via a wired or wireless connection.
  • the external sensors can be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth® or ANT+, and/or a wireless local area network (WLAN). This may enable reliable, fast and/or user-friendly transmission of data between the fall detection device and the at least one external sensor.
  • WPAN wireless personal area network
  • WLAN wireless local area network
  • the external sensors may comprise at least one of a blood sugar sensor, configured to generate data on the blood glucose level the user, a blood pressure sensor, configured to generate data on the blood pressure of the user, an ECG sensor, configured to generate data on the HR and the heart's electrical activity of the user, a pulse oximeter, configured to generate data on the HR and oxygen saturation of the user, a scale, configured to generate data on at least the weight of a user, and a blood coagulometer, configured to generate data on the coagulation efficiency of the user's blood.
  • a blood sugar sensor configured to generate data on the blood glucose level the user
  • a blood pressure sensor configured to generate data on the blood pressure of the user
  • an ECG sensor configured to generate data on the HR and the heart's electrical activity of the user
  • a pulse oximeter configured to generate data on the HR and oxygen saturation of the user
  • a scale configured to generate data on at least the weight of a user
  • a blood coagulometer configured to generate data on the coagulation efficiency of the user's blood
  • the fall detection system may further comprise a professional service, such as a professional service provider, an emergency service or call centre.
  • the fall detection system may comprise at least one emergency contact, such as a family member or a friend.
  • the fall detection device may be configured to directly send an alarm to the professional service and/or emergency contacts, e.g. family members, friends etc. This may be advantageous as the alarm may for example be send automatically, that is without any further interaction with the user, which may particularly be beneficial if the user got injured in a fall event.
  • the fall detection system may further comprise a remote server, also referred to as server.
  • the server may be configured to communicate and exchange data with the fall detection device. Additionally, the server may be configured to store data received from the fall detection device.
  • the fall detection device may be configured to send an alarm to the server. Additionally, the server may be configured to, upon receiving an alarm from the fall detection device, send an alarm to at least one third party, such as a professional service or an emergency contact. That is in some embodiments an alarm may first be send to the server and not directly to the professional service and/or emergency contact.
  • a third party such as a professional service or an emergency contact. That is in some embodiments an alarm may first be send to the server and not directly to the professional service and/or emergency contact.
  • the server may be configured to store data on past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. Further, the server may be configured to store sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines or a stumble of the user. Generally, the stored data may be beneficial for improving the fall detection algorithm, e.g. for personalizing the fall detection algorithm to a specific user. Moreover, the sensor data may also provide insights for healthcare providers, and or family and friends. For example, it may indicate a long-term decline of physical activity or it may enable association of particular activities with a higher risk of falling.
  • the remote server may at least be one of a dedicated server, a cloud-based server or any combination thereof, e.g. a dedicated server with additional cloud-based storage.
  • the present invention relates to a method.
  • the method comprising a fall detection system as described above, wherein the method comprises collecting sensor data from a plurality of the sensors of the fall detection system, determining the device status, i.e. if the fall detection device is worn by the user, based on data from at least one status sensor, utilizing a fall detection algorithm to determine if a fall has happened or not based on at least a subset of the sensor data, and triggering an alarm if a fall event is detected.
  • the step of collecting the sensor data may comprise pre-processing at least part of the sensor data. Further, the step of collecting sensor data may comprise storing at least part of the (pre-processed) sensor data in the memory.
  • the sensor data may be collected repeatedly, wherein the frequency at which the sensor data is collected may be specific to each sensor.
  • the data of the movement sensor may be collected repeatedly with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1 Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz.
  • the device status may be determined by analysing the data of one or a plurality of status sensors. For example, sensor data from a proximity sensor and/or a heart rate sensor. It will be understood that the heart rate data may also be utilized for the fall detection, i.e. the HR data may also be utilized as indication of a fall of the user. Further, the device status may be determined repeatedly with a frequency in a range of 100 mHz to 1 kHz, preferably 500 mHz to 100 Hz, such as 1 Hz.
  • determining the device status may be part of the fall detection algorithm.
  • the device status may also be determined as part of the fall detection algorithm whereas in other embodiments it may determined separately form the fall detection algorithm. In the latter case, the fall detection algorithm may for example only executed when the device is worn.
  • the fall detection algorithm may comprise at least one or a plurality of one or more steps of comparing at least a subset of the collected sensor data to pre-defined thresholds, and one or more steps of classifying a feature set and/or raw data derived from at least a subset of the collected sensor data, to determine if a fall has happened or not.
  • the step of classifying a feature set may be based on statistical or machine learning methods.
  • the collected sensor data may comprise data from at least one status sensor, data from at least one movement sensor, and data from at least one ambient sensor.
  • the data from the at least one status sensor may comprise HR data from a HR sensor. Additionally or alternatively, the data from the at least one status sensor may comprise data from a proximity sensor. Further, the data from at least one status sensor may comprise HR data and/or oxygen saturation data from a pulse oximeter.
  • the data from at least one movement sensor may comprise acceleration data from at least one accelerometer and/or orientation data from a gyroscope. Additionally or alternatively, the data from at least one movement sensor may comprise data from a magnetometer.
  • the data from the at least one ambient sensor may comprise barometric pressure data from a barometer. Additionally or alternatively, the data from at least one ambient sensor may comprise illuminance data form an ambient light sensor and/or temperature data from at least one temperature sensor. Further, the data from the at least one ambient sensor may comprise acoustic signal data from a microphone.
  • the collected data may comprise blood pressure data from at least one blood pressure sensor and/or blood glucose level data from a blood sugar sensor. Additionally or alternatively, the collected data may comprise distance data from a radar sensor.
  • the fall detection algorithm may comprise estimating the severity of a fall based on at least a subset of the sensor data.
  • the step of triggering an alarm may comprise a de-escalation phase enabling the user to abort an alarm. This may be advantageous as it may enable the user to abort an alarm., e.g., in case the user recovered quickly from the fall or no fall happened (false positive).
  • the de-escalation phase may comprise providing a visual feedback, such as a countdown showing the time remaining to abort the alarm on the screen of the fall detection device. Further, the de-escalation phase may comprise providing an audio feedback and/or a haptic feedback.
  • the de-escalation phase may comprise a length and the length of the de-escalation phase may be in a range of 0 s to 20 s, preferably 0 s to 10 s.
  • the length of the de-escalation phase may depend on the estimated severity of the fall event. For example, for a very severe fall the de-escalation phase may be shorter than for a less severe fall to ensure that help will be provided to the user as soon as possible in case of a very severe fall.
  • the alarm may be aborted through manual input to the user interface, e.g. by voice command, actuating a physical or virtual button or through a touch screen.
  • the communication unit may establish two-way communication between the fall detection device and another device such as a smartphone, e.g. in case of a fall or based on a user input.
  • the alarm may further be triggered manually through an input to the user interface, e.g. by voice command, pressing a physical or virtual button or through a touch screen.
  • triggering an alarm may comprise an escalation phase.
  • the escalation phase may follow the de-escalation phase in case the alarm is still active, i.e. it was not aborted during the de-escalation phase.
  • the escalation phase may comprise sending an alarm message to at least one of a professional service and an emergency contact.
  • the loudspeaker may generate a sound to draw attention during the escalation phase, e.g. a loud alarm signal or a call for help.
  • the escalation phase may comprise establishing a call with at least one of a professional service and an emergency contact. Further, the escalation phase may comprise establishing a call using the microphone and the loudspeaker of the fall detection device to enable hands-free operation.
  • the method may comprise determining the device position and generating position data through at least one of collecting data from the at least one position sensor, localizing the device utilizing the method of a Wi-Fi positioning system, e.g. WLAN fingerprinting or triangulation, localizing the device through the Global System for Mobile Communications (GSM), localizing the device utilizing Bluetooth beacons, or any combination thereof.
  • a Wi-Fi positioning system e.g. WLAN fingerprinting or triangulation
  • GSM Global System for Mobile Communications
  • the alarm message may comprise information on the fall event, e.g. time or estimated severity. Additionally or alternatively, the alarm message may further comprise user information, e.g. a user ID, name or medical history. This may be advantageous, as the professional service or emergency contact may thus tailor the response to the action based on the data received. For example, a professional service may check the medical history of a user and for example take into account known diseases of the user.
  • the alarm message may further comprise position data, e.g. from a position sensor, derived from the cellular network or a known WLAN. This may be advantageous for quickly finding the user in case of a fall, e.g., if the user is unconscious or does not remember his current location.
  • the alarm message may further comprise sensor data, e.g. HR, oxygen saturation, blood pressure or blood glucose level. This may be beneficial for judging the current health status of the user and taking the required actions. For example, it may allow the receiver of an alarm message to judge if a professional emergency service is required based on some of the vital signs of the user.
  • sensor data e.g. HR, oxygen saturation, blood pressure or blood glucose level.
  • the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. This may be advantageous for improving the performance of the fall detection device, i.e. it may for example reduce occurrence of false positives and false negatives in the process of detecting potential fall events.
  • the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data that is specific to a group of users, e.g. defined by age, activity level or pre-existing conditions.
  • the fall detection algorithm may be personalized based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data, wherein the database is specific to the user.
  • the database may further contain sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines. This may be beneficial for training of the fall detection algorithm since some activities may lead to sensor data very similar to fall events, e.g. going down stairs or taking an elevator. Thus, the fall detection may be trained to better distinguish such activities from actual fall events.
  • the input to the fall detection algorithm may further comprise information on ambient conditions, i.e. the algorithm may be context aware.
  • the fall detection algorithm may be adaptive, that is it may change e.g. depending on ambient conditions or physical activity of the user. For example, the algorithm may take into account current weather and/or lighting conditions when checking for potential fall events of the user. This may further improve the performance of the fall detection algorithm.
  • the method may comprise receiving user input through the user interface, e.g. for changing device settings or updating user information.
  • the method may further comprise receiving feedback following the detection of a fall event, e.g. confirmation that a fall happened or feedback on the severity of a fall by the user, a family member, a care taker, etc.
  • the method may comprise triggering different events depending on the pressure applied to the pressure sensitive touch screen.
  • the touch screen may be force sensitive such that depending on the applied force different actions may be triggered.
  • collecting the sensor data may comprise determining the acceleration of the device in all three dimensions, and separating the acceleration data into static (gravity) acceleration and dynamic (linear) acceleration by means of a low-pass filter. Further, collecting the sensor data may comprise determining an orientation angle of the device with respect to the vertical axis defined by the gravity component, i.e. static acceleration. The angle may for example be estimated by comparing the measured static acceleration to the expected gravitational component.
  • the fall detection device comprises a gyroscope
  • collecting the sensor data may comprise determining the orientation angle of the fall detection device. This may be advantageous as a gyroscope may enable more precise determination of the orientation of the device. Further, the method may comprise combining the orientation data obtained by the accelerometer and the gyroscope.
  • the method may further comprise determining the orientation angle of the device for a set time interval I1, wherein the length of the time interval I1 may be in a range of 1 s to 20 s, preferably 4s to 10 s, such as 6 s.
  • collecting the sensor data may comprise detecting the ambient pressure and deducing the corresponding altitude. Further, deducing the altitude corresponding to the ambient pressure can be supported by current weather data and/or position data. This may be beneficial as it may improve the accuracy of deducing the altitude. Further, collecting the sensor data of the altimeter may comprise storing the raw barometric pressure and/or the deduced altitude.
  • the method can comprise monitoring the acceleration to detect an impact, determining the orientation angle of the fall detection device to detect an unnatural orientation of the fall detection device, confirming a change in altitude of the fall detection device based on the measurements of the altimeter, and triggering an alarm.
  • An unnatural orientation of the fall detection device may correspond to a posture of the user that may not typically be assumed when standing or walking. In other words, a position that may be assumed following a fall.
  • the method may further comprise determining the amount of movement of the fall detection device to detect motionlessness. That is, the movement of the user may be checked, for example within a time interval. If the movement stays below a pre-defined threshold, e.g. the average of the movement within a predefined interval stays below a threshold, the user may be characterized as motionless. It will be understood that depending on the threshold the user may not literally be motionless but the overall movement may be smaller than a threshold. This may for example further indicate a fall from which the user cannot recover independently.
  • a pre-defined threshold e.g. the average of the movement within a predefined interval stays below a threshold
  • the method may further comprise comparing the sensor data of a potential fall event to sensor data of known activity patterns and determining if the sensor data corresponds to a known activity pattern. This may be advantageous for avoiding false alarms in case of known activities which may produce sensor readings that could indicate a fall such taking an elevator to go down. For example, by comparing a time series of at least a subset of the sensor data to the sensor data corresponding to known activities the number of false alarms may be reduced.
  • the step of detecting an impact may comprise comparing the linear acceleration to a pre-set threshold, wherein a value above said threshold detects an impact.
  • the frequency at which the acceleration is monitored may be in a range of 1 Hz to 500 Hz, preferably 1 Hz to 100 Hz, such as 50 Hz.
  • the step of detecting an unnatural position of the fall detection device may comprise determining the orientation angle of the fall detection device for the time interval I1, and determining if the orientation angle is above a pre-set threshold for at least a fixed fraction F1 of the time interval to detect an unnatural position of the fall detection device.
  • the zero angle may be associated with the most common position of the device for a person that is standing or walking and large deviations for a prolonged time (e.g. multiple seconds) may indicate an unnatural position, i.e. a position that may correspond to a fall.
  • the step of confirming a change in altitude can comprise comparing the relative change in the average altitude determined in an interval 12 before and in an interval 13 after the impact to a threshold to determine if the altitude of the fall detection device has changed sufficiently to indicate a fall of the user.
  • the intervals 12 and 13 may each comprise a length in the range of 1 s to 15 s, preferably 3 s to 10 s such as 5 s. That is, a relative change of altitude before and after the impact of a potential fall may be determined. This may be advantageous as a fall typically results in a change of altitude particularly for the upper body parts of the user and thus the change of altitude may again be indicative of a fall of the user.
  • the step of detecting motionlessness may comprise determining the amount of movement during the time interval I1, and determining if the amount of movement is below a pre-set threshold to detect motionlessness. Additionally, determining the amount of movement may comprise at least one of determining acceleration and determining changes in orientation during the time interval I1.
  • the collected data on HR and/or oxygen saturation may be used for determining the status of the device and as part of the sensor data for the fall detection algorithm.
  • the sensor data may be used for both, determining if the device is worn and as indication of potential fall events.
  • the step of collecting sensor data may comprise detecting ambient noises and sounds and providing the corresponding sound data, i.e. data on acoustic signals.
  • the method may further comprise analysing sound data from the microphone to identify sounds and noises associated with a fall event. This may be advantageous as typical sound patterns of a fall may be identified, e.g. through comparison. This may for example include the sound of impacts of a body on certain surfaces and/or moaning or screaming of a user in case of injuries and/or shock.
  • the method may further comprise determining the respiratory rate based on the noises and sounds detected by the microphone.
  • the respiratory rate may be determined through sound data provided by the microphone. This may for example indicate the severity of a fall or provide information on the current heath status of a user.
  • the collected data may comprise respiratory rate data.
  • the method may comprise optimizing the power consumption of the device through at least one or a plurality of optimizing the sampling frequency for each sensor to reduce power consumption while maintaining a high precision of the fall detection, adjusting the brightness of the screen automatically depending on ambient conditions, adjusting the design of the user interface depending on current usage, switching the screen on and off depending on position of the device, optimizing the sampling frequency of the HR sensor or pulse oximeter according to the physical activity of the user, optimizing the sampling frequency of the movement sensor(s) according to the HR or pulse oximeter sensor data, and optimize frequency at which components such as communication unit or processing unit are woken up.
  • the position sensor may be switched off or send into a power saving mode if the user is within a known wireless network. Additionally or alternatively, the position may only be updated, i.e. the position sensor may be woken up, if the user is moving based on the sensor data from the at least one movement sensor.
  • the frequency at which the position is determined may depend on the latest position. For example, the position may be determined with a low frequency if the device is close to the home of a user and high if the device is far away from the home of a user.
  • the method may further comprise recharging the battery of the fall detection device via a cable connected to the connector and/or wirelessly recharging the battery of the fall detection device.
  • the method may further comprise connecting to an external handheld device. Further, the method may comprise utilizing the fall detection device as a user interface for the handheld device. The method may further comprise displaying content of the external handheld device.
  • the present invention relates to the use of the device, system or method as described above for the detection of falls of a user.
  • the use may further comprises triggering an alarm in case a fall of the user is detected.
  • the present invention may provide a device, system and method for fall detection which may provide an improved accuracy of fall detection, i.e. it may reduce the number of false positive alarms and/or false negatives. This may be advantageous as it may improve the safety of the user and for example enable the user to live a more independent life.
  • the fall detection device 100 also simply referred to as device 100, may very generally comprise a plurality of sensors 110,120,130, a user interface 140, a processing unit 150, a communication unit 160, a memory 170 and a battery 180.
  • the at least one status sensor 110 may be configured to provide data on the status of the device, that is if the device is worn or not. This information may be particularly important if the device is falling down without being worn, which could lead to false alarms (FP). It is a goal of the invention to reduce the occurrence of false alarms and thus the status sensor 110 is important for the overall functionality.
  • worn may be understood as worn on the body. That is, it may refer to a device 100 that is worn tightly attached to some part of the body, such as on the wrist or clipped to the waist, however it may also refer to a device 100 that is worn more loosely, such as in a pocket, a backpack, on a necklace or in a hand.
  • the status sensor 110 may have further functionality, i.e. in some instances it may provide more data than just the status of the device.
  • the status sensor 110 may primarily be a sensor for vital signs.
  • the status of the device may be determined through the presence or absence of a vital sign.
  • a HR sensor only provides HR data if the device is worn. This may be advantageous to a common proximity sensor, which may provide false readings if the sensor is blocked (accidentally or purposefully).
  • At least one movement sensor 120 may provide data on the movement of the device and subsequently on the movement of the user in case the device is worn.
  • the one or more movement sensor is at least one of an accelerometer 121, a gyroscope and a magnetometer. These sensors may be used to monitor movements and/or the orientation of the device 100.
  • the at least one ambient sensor 130 may provide data on the ambient conditions of the device.
  • the device 100 comprises at least one altimeter 131 configured to measure the altitude of the device 100.
  • the altimeter 131 comprises a barometric pressure sensor configured to measure changes in the ambient barometric pressure. Based on a change in the barometric pressure a change in altitude may be estimated.
  • the altimeter may also comprise a temperature sensor configured to sense the ambient temperature which may be considered when estimating the altitude based on the measured pressure.
  • the device is operated through a processing unit 150 which typically comprises a central processing unit (CPU) or at least one circuit, such as an application specific integrated circuit (ASIC).
  • a processing unit 150 typically comprises a central processing unit (CPU) or at least one circuit, such as an application specific integrated circuit (ASIC).
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • the processing unit 150 may acquire and store data from the sensors and run algorithms for processing and analysing the sensor data to identify a fall event and subsequently take corresponding measures according to the situation, e.g. send an alarm to a call centre or family members.
  • the frequency of acquiring sensor data can be specific to each sensor and happen at pre-defined intervals or conditional on specific events, such as certain values measured by other sensors.
  • the processing unit 150 may run an algorithm to estimate the level of severity of a fall event. This may enable to choose the actions to take based on the likely severity of the detected fall. For example, a light fall may only require a call centre or family member to call and check if everything is ok, whereas a severe fall may even require dispatching of emergency personnel.
  • the communication unit 160 of the device 100 may serve to send and receive instructions, sensor data, operational data or the like, e.g. it may communicate with external sensors, servers and call centres. Most importantly, the processing unit 150 may send an alarm via the communication unit 160 in case a fall of the device user is detected. Therefore, the communication unit 160 may provide means to establish wireless connections to external sensors, severs, phones and other devices relevant to the operation, for example via a cellular network, WLAN or WPAN (e.g. Bluetooth® or ANT+).
  • a cellular network e.g. Bluetooth® or ANT+
  • Part of the memory 170 may store sensor data for further processing and analysis.
  • this part of the memory is configured as a ring memory. That is, the memory has a finite size and is filled successively with sensor data until the memory is full. Subsequently, the oldest data point is replaced with the latest data point, therefore keeping the x latest data points, where x is the maximum of data points that can be stored in the memory.
  • Another part of the memory 170 may store machine-readable program code, that, when executed on the processing unit 150, causes the processing unit 150 to execute the tasks and steps required to operate the fall detection device 100. That is, the memory may for example store machine-readable program code corresponding to a fall detection algorithm that identifies a fall detection event based on the sensor data when run by the processing unit 150.
  • the battery 180 is designed to power the device 100 and is either removable or rechargeable (or both). In other words, in some embodiments the battery can be removed from the device whereas in other embodiments it is not designed to be removed by the user. In the latter case, the battery is rechargeable via a cable or wirelessly, while in the first case it may not be rechargeable.
  • the power consumption of the device 100 may be managed by the processing unit 150 in order to extend the battery lifetime while ensuring reliable operation of the device 100, e.g. by sending individual parts into a power saving mode or powering down components temporarily for intervals in which they are not required.
  • the power consumption of the device 100 may be optimized by the processing unit 150 in order to reduce the energy consumption while ensuring save operation of the device 100.
  • the device may utilise a HR sensor 112 as status sensor 110, i.e. the device checks if it is worn by checking if a valid HR signal is measured.
  • a HR sensor 112 may either be an electrocardiography (ECG) sensor or, preferably, a photoplethysmography (PPG) sensor.
  • ECG electrocardiography
  • PPG photoplethysmography
  • the measurement of a pulse and/or HR signal indicates that the device 100 is worn. This may be advantageous as such a vital signal is hard to synthetically create and thus provides a good indicator of the device status.
  • the device 100 may be a wristwatch with an optical (PPG) HR sensor that will measure the HR of the user once the watch is placed on the wrist.
  • PPG optical
  • an optical (PPG) HR sensor may be able to also measure the oxygen saturation in the blood.
  • the sensor data of the status sensor 110 may also be used as data for the fall detection algorithm.
  • the HR of the user may also provide an indication if a user has fallen or not. That is, the status sensor data is not necessarily exclusive for the determination of the device status.
  • the fall detection device 100 may also comprise a proximity sensor as a status sensor 110. That is, the status of the device may be determined by a means of a proximity sensor. Further, the status may also be determined based on a combination of data from the proximity sensor and the heart rate sensor 121.
  • the movement sensor 120 in the depicted embodiment is an accelerometer 121, which may provide data on the static and dynamic acceleration of the device and thus enable to extract information of the device orientation relative to the surface of the earth.
  • the acceleration data may be filtered by means of a low-pass filter, e.g. a Butterworth filter, in order to extract the gravity component, which is basically static. Therefore, the sensor 121 may provide data on the dynamic (linear) acceleration corresponding to the movement of the device 100 and on the orientation relative to the gravitational field (i.e. the earth surface) by relating the dynamic acceleration data to the (static) gravity component.
  • a low-pass filter e.g. a Butterworth filter
  • the sensor 121 may provide data on the dynamic (linear) acceleration corresponding to the movement of the device 100 and on the orientation relative to the gravitational field (i.e. the earth surface) by relating the dynamic acceleration data to the (static) gravity component.
  • Such an accelerometer may for example be based on a microelectromechanical system (MEMS).
  • MEMS microelectromechanical system
  • the device 100 may comprise three ambient sensors 130.
  • the altimeter 131 also referred to as barometer 131, may provide data on the ambient barometric pressure. Through comparison of the estimated altitude at different times (or time intervals) a relative change in altitude may be determined. In other words, since the barometric pressure also depends on the altitude a relative change in height of the device can be estimated from the altimeter data.
  • the data of the altimeter may also allow to estimate the absolute altitude of the device, for this, context data such as current weather may be used to improve the accuracy.
  • a light sensor 132 may measure the illuminance in the surrounding of the device 100, and thus provide data for adjusting the brightness of a screen 141. This way, the brightness can for example be chosen such that the power consumption is reduced while still ensuring readability for the user.
  • the ambient lighting conditions may also serve to provide context data for the fall detection algorithm since darker conditions may increase the risk of falling if a user is moving.
  • a position sensor 133 may provide data on the global position of the device based on a global navigation satellite system such as GPS or Gallileo. This may be important in case of an alarm, as it enables the device 100 to provide data on the position of the user to the emergency contacts or services. This data may also be used to improve the accuracy of determining the absolute altitude.
  • a global navigation satellite system such as GPS or Gallileo.
  • the position detection may be supported by the cellular network and/or WLAN, as well as other signals that may enable localisation.
  • cellular networks may enable for mobile phone tracking, e.g. through localization based on the global system for mobile communications (GSM).
  • GSM global system for mobile communications
  • IP localization or a Wi-Fi positioning system may provide means to localise the fall detection device.
  • Such techniques may be combined with the position sensor to allow for a localization indoors and outdoors and additionally may enable reduction of the power consumption of the device.
  • the user interface 140 may comprise a screen 141 which may for example show notifications for the user, information on the device status and charging status of the battery, settings of the device, current time, etc.
  • the screen 141 may be a touch screen, allowing the user to interact with the device, for example to change device settings, abort or trigger an alarm, edit personal information of the user, etc.
  • the brightness of the screen 141 may be adjustable to optimise power consumption and readability depending on ambient conditions and operating condition, e.g. in case of an alarm the screen brightness may be maximised to ensure readability.
  • the user interface 140 may comprise a physical button 142, allowing the user to manually trigger an alarm in case of a fall, or potentially another emergency situation, if the device did not automatically detect the event. That is, the user can manually trigger an alarm by actuating the button on the device.
  • the button may also enable the user to abort an alarm during a de-escalation phase in case it has been triggered. Such a de-escalation phase my generally follow the triggering of an alarm to inform the user and provide a possibility to abort the alarm in case it has been a false alarm (FP).
  • FP false alarm
  • the user interface may comprise a virtual button instead of or in addition to the physical button 142.
  • a virtual button may for example be an area of the touch screen 141, a pressure sensitive area on the device, or a motion sensor configured for gesture control.
  • a virtual button can for example be realised by registering a tapping on the device with the accelerometer 121 or repeated covering of the light sensor 132.
  • a virtual button may provide the same functionality as a physical button 142 when actuated.
  • a button may also provide functionalities other than triggering or aborting an alarm, e.g. a button may be used for changing settings of the device or for reacting to a message shown on the screen 141.
  • the user interface 140 may further comprises a loudspeaker 143.
  • the speaker may for example generate a beeping sound or an alarm sound during the de-escalation phase following an alarm.
  • the device 100 may also comprises a microphone 144 which is part of the user interface 140, e.g. for voice commands. However, it may also function as a sensor. For example, the microphone 144 can detect sounds and noises in the surrounding of the device 100, that may be associated with a fall through sound recognition patterns. Further, the microphone 144 may provide data on the breathing of the user by monitoring the corresponding sounds.
  • a microphone 144 which is part of the user interface 140, e.g. for voice commands. However, it may also function as a sensor.
  • the microphone 144 can detect sounds and noises in the surrounding of the device 100, that may be associated with a fall through sound recognition patterns. Further, the microphone 144 may provide data on the breathing of the user by monitoring the corresponding sounds.
  • microphone 144 and loudspeaker 143 may further allow the user to have a phone call with the corresponding emergency contact or the emergency services.
  • the device 100 may also comprise a haptic feedback unit 145 which may comprise at least one vibrational motor.
  • a haptic feedback can be provided, e.g. during the de-escalation phase or in case of a notification.
  • the device comprises a processing unit 150, a communication unit 160, a memory 170 and a battery 180 as described above.
  • the device status may be checked in regular intervals (not shown in Fig 3 ). That is, the data of the at least one status sensor 110 may regularly be analysed to confirm that the device 100 is worn. In the case of the HR sensor 112 this means, that the presence of a valid HR signal is regularly checked to validate that the device 100 is worn, whereas for a proximity sensor it may be checked that an object is in close proximity to the proximity sensor and thus the device 100.
  • checking the device status may be part of the fall detection algorithm, that is it may be one of the steps of the fall detection algorithm.
  • the fall detection algorithm depicted in Fig. 3 may then monitor the data generated by the accelerometer 121 to identify any impact (step 210), wherein the acceleration data may be received either directly from the sensor or via the memory. As discussed earlier, the acceleration data may be pre-processed to be separated in to the gravity component and the linear (dynamic) acceleration.
  • a fall consists of a phase of reduced acceleration due to the (approximately) free fall and then a moment with a high spike in the acceleration due to an impact, e.g. on the floor.
  • the algorithm may compare the acceleration to a threshold value set to identify such an impact.
  • the acceleration data may be preferably collected and analysed with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz. That is in the case of 100 Hz the algorithm checks for an impact 100 times per second.
  • the sound data may be analysed (step 220). That is, sounds and noises recorded by the microphone 144 may be analysed to determine if a fall might have happened. That is, for example recorded sound patterns around the time of the impact may be analysed to recognize sound patterns which are associated with a fall, e.g. sound of an impact on a floor or a scream of a user. This may further increase the accuracy of the fall detection algorithm.
  • the biomechanical posture of the user of the fall detection device 100 may be checked (230).
  • the orientation angle of the device may be checked to detect an unnatural orientation of the fall detection device.
  • the orientation may be estimated by extracting the gravitational vector from the acceleration data. This may be done by low-pass filtering the data since the gravitational component can be approximated to be static. By evaluating the direction of the gravitational acceleration, the angle of the device relative to the earth surface may be estimated.
  • the fall detection may further comprise a gyroscope to provide additional orientation data and thus improve the precision at which the orientation angle of the device may be determined.
  • the orientation angle may be determined only based on the gyroscope data or, preferably, based on the gyroscope and the accelerometer data.
  • the orientation angle of the device may be indicative of the posture of the user.
  • the fall detection device 100 is a wrist watch, it may indicate if the arm of the user is within the biomechanical constraints of the human musculoskeletal system.
  • Certain postures may be associated with a high likelihood of a preceding fall (these postures may be referred to as unnatural position) and thus the algorithm may proceed to the next step, alternatively the algorithm may return to step 210 if for example the identified posture indicates that the user has recover from a fall.
  • the movement of the user may be checked (step 240).
  • the movement of the device within the interval may be analysed and in case the overall movement of the device 100 (and thus the user) stays below a pre-defined threshold the algorithm proceeds to the next step. Only if there is sufficient movement of the device registered, the algorithm goes back to 210. If the user is moving but still requires help, the alarm may be triggered manually.
  • step 250 the algorithm evaluates the data from the altimeter 131, e.g. the barometric pressure, to estimate the altitude in an interval before and after the fall detection event, respectively.
  • the changes in altitude may be indicative of a fall of the device (and the user).
  • the algorithm may simply compare the average altitude in the two intervals to estimate a relative change in altitude, or alternatively the algorithm may for example check if changes in the altitude signal within these two intervals match a specific signal pattern. If changes in the altitude are considered to be indicative of a fall, the algorithm may move to the next step. If the data of the altimeter indicates no changes in altitude typical of a fall, e.g. the changes do not match this pattern, the algorithm may for example go back to step 210. For estimating the altitude also other data may be considered, for example data on the ambient temperature.
  • the leg length is typically above 60 cm, thus if the fall detection device is worn at the upper body or the wrist a change in altitude of at least 50 cm may be expected.
  • the threshold may be personalized according to the body proportions and the place where the fall detection device is worn.
  • the step of determining the change in altitude may be advantageous for example to prevent alarms in case a user is hitting a table with his hand, e.g. during playing cards. This may lead to a detection of an impact and an orientation angle above the threshold but does of course not correspond to a fall event.
  • checking the altitude provides means to reduce the occurrence of FP, improving the accuracy of the fall detection device.
  • the algorithm may compare the activity pattern to known activity patterns to avoid false alarms (step 260). That is, based on the collected sensor data, the algorithm may determine if the sensor data around the point of the identified impact or potential fall event can be can be associated to a known activity pattern, e.g. stored in a database of known activity patterns. That is, the sensor data may be compared to the sensor data of known activity patterns to rule out that an alarm is triggered due to a known activity which may lead to sensor readings that mimic a fall event.
  • taking an elevator may result in sensor readings that may cause the fall detection algorithm to detect an impact, alongside with a change of altitude and potentially reduced movement such that it may lead to the result that a fall may have happened.
  • the sensor data By comparing the sensor data to known activity patterns it may be identified that the user was taking an elevator and thus a false alarm may be prevented.
  • the fall detection may trigger an alarm if all the preceding steps indicate that a fall has happened (step 270).
  • the fall detection algorithm may for example also comprise a step of estimating the severity of a fall based on the measured sensor data.
  • the severity may be based on the amplitude of the impact and/or the amount by which a threshold is exceeded.
  • the fall detection algorithm may return to its first step upon finding that in one step the data does not correspond to a fall event, e.g. if there was no sufficient change in altitude.
  • a further step may be executed to confirm that no fall has happened.
  • only one of two steps may be required to indicate that a fall has happened for the algorithm to continue.
  • it is enough if either a sufficient change of altitude was measured (step 250) or the movement was below a pre-defined threshold (260).
  • both of the steps are required to indicate that a fall has happened.
  • the fall detection device 100 may be part of a fall detection system 200, also referred to as system 200.
  • a system 200 may further comprise at least one or a plurality of external sensors 310 which may provide additional data for the fall detection device. These data may provide further sensor data for the fall algorithm and/or provide medical background data, e.g. in case of a fall event.
  • the fall detection device 100 may communicate and exchange data with the external sensors via a wired connection or, preferably, a wireless connection, such as a wireless personal area network, e.g. Bluetooth® or ANT+ or WLAN.
  • a wireless connection such as a wireless personal area network, e.g. Bluetooth® or ANT+ or WLAN.
  • the system 200 may comprise a professional service 320, which may for example be a professional service provider or call centre.
  • the fall detection device 100 may be configured to send an alarm message to and/or establish a phone call with the professional service 320 in case an alarm is triggered and not aborted.
  • the fall detection device 100 may share data with the professional service 320, such as medical data, summary of activity of the user or the like. This way, the professional service 320 may also be informed about the general health status of the user and may be enabled to provide preventive measures and assistance to the user and/or his family and friends.
  • the professional service 320 may also be informed about the general health status of the user and may be enabled to provide preventive measures and assistance to the user and/or his family and friends.
  • the system 200 may comprise at least one emergency contact 330, such as a family member or a friend.
  • the one or more emergency contacts may be contacted by the emergency device 100 in case of an alarm that is triggered and not aborted. That is the fall detection device may send an alarm message and/or establish a phone call between the user and the emergency contact 330.
  • An alarm message may for example contain information about the estimated severity of a fall, timing information, user ID, medical background information, sensor data such as position and vital signs. This may be advantageous as it may enable the professional service 320 or the emergency contact 330 to get a better judgement of the situation and enable them to take the appropriate measures.
  • an alarm message may be sent or a phone call established in case an alarm has been aborted.
  • the fall detection system 200 may further comprise a server 340 which may be configured to communicate and exchange data with the fall detection device 100.
  • the server may store data received from the fall detection device 100, e.g. for training or personalization of the fall detection algorithm.
  • the fall detection device 100 may send an alarm message to the sever 340 in case an alarm has been triggered and not aborted. This may be either instead or in addition to an alarm message or phone call to an professional service 320 and/or emergency contact 330.
  • the server 340 may also store data regarding past alarms that have been triggered either manually or automatically alongside a part (or all) of the corresponding sensor data. These data may represent datasets corresponding to TP (automatically triggered) or FN (manually triggered), which may serve to train and improve and/or personalize the fall detection algorithm.
  • the server 340 may also store information on aborted alarms together with at least a subset of the corresponding sensor data. This data would correspond to FPs which may also be used for training, improving and/or personalizing the fall detection algorithm.
  • the stored data may be supplemented by information from the user, professional service 320 and/or emergency contact 330 to provide more detailed feedback on the fall event.
  • the server may in some embodiments also store sensor data that does not correspond to a triggering or aborting of an alarm, i.e. data on TNs, which could for example be sensor data corresponding to a specific activity or a standard routine or also a stumble of the user. This data may also be used for training, improving and/or personalizing the fall detection algorithm.
  • the data stored may also comprise sensor data on the ambient conditions, which may also be used as an input to the fall detection algorithm.
  • Part of the above-mentioned data may also be helpful for identifying preventative measures.
  • the data may reveal potentially risky situations for the user which may be avoided through certain measures, such as adjusting medication, changing furniture position, etc.
  • the server 340 may also communicate and exchange data with one, or a plurality of, external sensor(s) 310, e.g. to collect their data and store it and/or send it to the fall detection device 100.
  • the server 340 may be a remote server, more precisely it may be a dedicated server, a cloud-based server or for example a combination of a dedicated server and cloud-based storage.
  • a de-escalation step 410 may be entered during which the user may be able to still abort the alarm. This is particularly useful in cases of FP or if the user was able to recover from the fall and does not require further assistance, i.e. the severity was low. This step may also be referred to as de-escalation phase 410.
  • the de-escalation phase 410 will last for a pre-defined time, e.g. 5 s or 10 s.
  • the length of the de-escalation phase 410 may be 0 s, that is the de-escalation step 410 may be skipped.
  • the length of the time interval may be defined with respect to the estimated severity of a fall. That is, there may be more time for the user in case of a less severe fall event in comparison to a sever fall event where the de-escalation step 410 may be very short or, in some instances, skipped.
  • a countdown may be shown on the screen 141, indicating the time remaining until the alarm message is sent. Further, the countdown may be accompanied by a sound played via the loudspeaker 143, e.g. there may be a "beep" every second of the countdown.
  • the haptic feedback unit 145 may also indicate the presence of a countdown and thus the possibility to cancel the alarm, e.g. the device may vibrate during the countdown.
  • the user may be enabled to abort the alarm in different ways.
  • the user may use the button 142 to cancel an alarm that hast already been triggered. That is, the button triggers an alarm in case no alarm has been triggered yet and aborts an alarm in case the device is in the de-escalation phase 410.
  • the device may have two buttons, one button 142 to trigger an alarm and another button to cancel an alarm during the de-escalation phase 410.
  • the user may cancel an alarm by tapping on the touch screen 141.
  • the user may be required to tap the screen three times in order to reduce the likelihood of accidently cancelling an alarm.
  • a voice command may be a predefined command, e.g. "stop”, "cancel alarm”, or similar phrases.
  • the escalation step 420 may include sending an alarm message, e.g. an SMS, to at least one of a professional service 320 and an emergency contact 330.
  • the message may include information about the event, e.g. estimated severity of the fall, user ID, medical background of the user, location of the user, e.g. GPS coordinates of the device location, and/or summary of the vital signs measured by some of the sensors of the device 100.
  • the user may specify a list of contacts that receive an alarm message upon entering the escalation step 420.
  • the device 100 may trigger a phone call to an emergency service 320 or an emergency contact 330 enabling the user to speak to the emergency contact or service using the microphone 144 and the loudspeaker 143 of the device 100.
  • the user may specify a list of emergency contacts 330.
  • the device 100 may then attempt to establish a phone call with the first emergency contact 330 and only call the second emergency contact 330 in case the first cannot be reached and so forth. This may increase chances of reaching at least one emergency contact 330.
  • the de-escalation phase 410 may be skipped, however in order to avoid FP due to accidentally triggering the alarm, the de-escalation phase 410 may still be entered in case of a manually triggered alarm.
  • the fall algorithm may be based on statistical classification methods, such as machine learning methods.
  • a first step for generating a model may be the collection of data that is accurate enough to generate a proper training file.
  • a data collection may involve exemplary sensor data for fall events in different situations and surroundings, e.g. fall from a standing position to the front, back or side, fall onto a piece of furniture, fall during a physical activity etc., furthermore the data collection may comprise exemplary sensor data on near fall events, e.g. a person stumbling but not falling, on physical activities, e.g. a person running or jumping or on activities normally performed when at home, e.g. sitting down on a bed or sofa, cleaning or cutting vegetables and fruits.
  • Such a data collection may enable identifying and training of an appropriate classification algorithm that is able to distinguish between fall and non-fall events with a high success rate, i.e. limited number of FP and TN.
  • the features required for the classification may be assessed and refined.
  • a final model may be generated using the selected features and the classification algorithm.
  • This model may then be implemented into the real time application, e.g. the fall detection device 100, with the capability to update the model. This way, the model may be adaptable for different users and/or groups of users.
  • the processing unit 150 may receive and analyses the sensor data to extract corresponding features.
  • Such features may be statistical quantities of a data set, such as the mean or standard deviation, or other measurable or characterising properties, e.g. maximum/minimum value, a certain ratio, etc. These features may then form a feature set that may be characteristic for a certain instance in time.
  • a feature set includes at least one feature of a status sensor 110, a movement sensor 120 and an ambient sensor 130, respectively.
  • the feature set may be provided to the fall detection algorithm which may be based on a predetermined model that may classify the data into fall and non-fall events. It will be understood, that the fall detection algorithm comprises an implementation of the model.
  • sensor data may be stored to later serve as training data for improving the classification algorithm and/or the model that is based on said classification algorithm.
  • data may particularly be data of FP (i.e. when the alarm is aborted by the user), FN (i.e. when the alarm is triggered by the user) and TP (i.e. when an automatically triggered alarm is not aborted by the user).
  • TN data may be saved, i.e. for example data that corresponds to a certain physical activity.
  • the training data may be improved through feedback of the user with reference to certain fall and non-fall events. For example, the user may be asked to confirm a fall and/or rate the severity thereof.
  • the fall detection device 100 may further comprise means for realizing contact tracing and/or proximity tracing. That is, very generally during an epidemic and/or pandemic, e.g. with a contagious virus, such as an influenza or corona virus, it may be desirable to be able to determine who was in close proximity of an infected person during a period where the person may already have been contagious. That is, such viruses may for example spread via aerosols in the breath of a person, which may typically be particularly contagious over a distance of 1.5 to 2 m.
  • contract tracing may be conducted via interviews, wherein an infected person would be asked to recall the contact persons and visited places during the potentially contagious period, e.g. 2 weeks.
  • Bluetooth® and specifically Bluetooth Low Energy BLE
  • BLE Bluetooth Low Energy
  • each device may periodically share a respective identifier, which will be received by nearby devices and can be stored to record potential proximity to another person.
  • the principal would be similar (or the same) as for Bluetooth beacons, which may typically also rely on broadcasting an ID via Bluetooth Low Energy.
  • the storage of such an ID may for example depend on the time two devices were in close proximity and the estimated distance between the two devices.
  • the distance to other device may for example be estimated via the signal strength of the received Bluetooth signal in comparison to the signal strength at which it was send out, which may for example also be shared as information).
  • Such a method may have the advantage, that only proximity to other persons may be tracked and no location, such that it may be impossible, or at least hard, to deduct a movement pattern of a person.
  • the fall detection device which may for example be a wristwatch, such as a smartwatch, may further be configured for proximity tracing. That is, the fall detection device may be configured to implement proximity tracing, in particular privacy-preserving proximity tracing, such as PEPP-PT or DP3T.
  • the communication unit 160 may be configured to provide and receive a Bluetooth Low Energy signal, particularly to broadcast and receive respective identifiers, such as an Ephemeral Identifier.
  • said identifiers may be encrypted.
  • the identifiers may for example be based on a secret seed which may be generated when the respective feature is initially activated on the fall detection device, e.g. when a respective program or application is installed.
  • Each identifier may typically only be utilized for a pre-set time interval, e.g. 15 min, 20 min or 60 min 45 min or 60 min in order to comply with privacy obligations. That is, the fall detection device 100 may generate a number of different identifiers, e.g. based on a secret seed and utilizing a pseudo random function as well as a stream cipher.
  • Received identifiers which are broadcasted by nearby devices may for example be stored in the local memory 170 alongside an indication of the date and/or time it was received.
  • Storage of an identification may depend on the estimated distance of the corresponding device, e.g. from the signal strength, and the time the corresponding device was in close proximity. Furthermore, the stored identifiers may be automatically deleted after a set period of time, which may for example correspond to the time period a person is considered to be contagious, e.g. 14 days or 21 days.
  • the fall detection device may notify the user that there may be an increased risk for an infection and for example inform the user of further steps.
  • the fall detection device may further be configured to also notify an emergency contact 330 and/or an emergency service 320.
  • the fall detection device may be utilized to inform (anonymously or at least pseudo anonymously) other devices (and their users) that have been in close proximity during the relevant contagious period according to the rules and implementation of the utilized protocol, e.g. DP3T or PEPP-PT.
  • the fall detection device may generally be designed such that it can be worn without significantly restricting the user, which may increase the likelihood of it being worn and decrease the chances for forgetting it, since it is typically (unlike a smart phone) attached to the body, e.g. as a wristwatch.
  • particularly elderly people are often at risk during an epidemic or pandemic may not own a smartphone.
  • they may already utilise a fall detection device, such that the additional functionality of proximity/contact tracing may be implemented without affecting the routine of these people.
  • the willingness to carry a fall detection device which may be small and easy to handle, e.g. as a wrist watch, may be higher than getting a smartphone only for being able to have access to proximity tracing.
  • step (X) preceding step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), ..., followed by step (Z).
  • step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), ..., followed by step (Z).

Abstract

The present invention relates to a fall detection device, wherein the fall detection device comprises at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data, at least one movement sensor, configured to measure and provide data on the movement and/or orientation of the fall detection device, and at least one ambient sensor, configured to measure and provide data on the ambient conditions of the fall detection device. Further, the fall detection device comprises a processing unit, configured to operate the fall detection device and run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data, and a communication unit, configured to communicate with external devices, wherein the communication unit comprises at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM). The invention also relates to a fall detection system for identifying a fall and triggering an alarm and a corresponding method.

Description

    Field
  • The present invention generally relates to a device, system and method for activity monitoring, more precisely a device, system and method for fall detection.
  • Introduction
  • The increasing average age of the population is a worldwide phenomenon fuelled by the rising life expectancy and the increasing number of elderly people. Further, it is a particular burden for health care systems. One of the most common reasons for injuries and accidents of elderly people are falls. A fall may cause fractures and lead to immobility, or in the worst case could be fatal.
  • Further, recurrent falls even without severe injuries lead to fear of falling, a reduction in mobility and physical function, and social isolation. In very severe cases the loss of mobility and independence together with the loneliness caused by the isolation may result in depression.
  • There is a big interest in helping elderly people in overcoming their insecurities and reducing response times in case of falls. A well-known solution is to provide an alarm button that may be worn by the elderly person, who can trigger an alarm signal by pushing the button in case of a fall. However, particularly after a severe fall, a person might be immobile due to injuries or even unconscious and thus unable to push the button.
  • This problem has been overcome in recent years by providing systems, that incorporate accelerometers which are worn close to a person's body. By monitoring changes in the acceleration, falls may be detected and an automated alarm can be triggered. However, it is often difficult to distinguish between falls and natural movements and the rate of falls positives (FP) (or false negatives (FN)) is usually quite high. This is a disadvantage as too many FPs may result in the user refusing to wear the device/sensor, whereas FNs mean that no alarm is triggered even though a fall happened, which may undermine the trust of a user and could in the worst case lead to undetected severe falls.
  • Summary
  • In light of the above, it is an object to overcome or at least alleviate the shortcomings and disadvantages of the prior art. That is, it is an object of the present invention to provide an improved device, system and method for detecting falls and generating an alarm signal.
  • These objects are met by the present invention.
  • In a first embodiment, the present invention relates to a fall detection device. The fall detection device comprises at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data, at least one movement sensor, configured to generate data on the movement and/or orientation of the fall detection device, and at least one ambient sensor, configured to generate data on the ambient conditions of the fall detection device. In other words, the present invention relates to a device for detecting a fall of the user, wherein the fall detection device comprises at least 3 different sensors. The status sensor may sense if a device is worn which may be advantageous to rule out events wherein the fall detection is falling down when not being worn, for example from a table to the floor. The movement sensor may detect the movement and or orientation of the device. This may be beneficial as it can indicate an impact of the device when a user is falling and/or enable to estimate a posture of the user based on the device's orientation or for example trajectory. The ambient sensor may provide data on ambient conditions, for example temperature, pressure and/or altitude. This may be advantageous as it may further improve the accuracy of the fall detection. Further, it may for example provide valuable context for the calculation of the certainty of a fall occurrence.
  • Overall, such a fall detection device may enable a more reliable detection of falls of the user, i.e. it may reduce false positives and/or false negatives. This may be advantageous as it may reduce false alarms being send for example to care takers or family members of the user and for example increase the security of the user.
  • In some embodiments, the fall detection device may be configured to be a wearable device, that is the fall detection device may be configured to be worn by a user. This may be advantageous as it may enable the user to take the fall detection to any location, i.e. it may be flexible. Additionally, the fall detection device can be configured to be worn around the wrist, e.g. in the form of a wristwatch. This may further be advantageous as a wristwatch may be easily accessible and comfortable to wear. Moreover, a fall detection device worn around the wrist may for example provide further functionality, such as the functionality of a watch, a smart watch, a health monitor and/or fitness tracker.
  • The at least one status sensor of the fall detection device may be at least one of a proximity sensor, configured to sense any object in close proximity, a heart rate sensor, configured to generate data on the users heart rate (HR), and a pulse oximeter, configured to generate data on the user's oxygen saturation and HR.
  • That is, the status may for example also be determined by the presence (or absence) of a vital sign. This may be advantageous, as the presence of a vital sign may be a more reliable signal compared to a proximity sensor which only senses the presence of an object in close proximity. A vital sign may be much harder to accidentally (or purposefully) generate without the fall detection device being worn. Again, this may be advantageous, as a fall may only be detected if the fall detection device is worn and thus providing a reliable status sensor may reduce the number of false alarms, e.g., as a result of the device falling on the floor without being worn.
  • Further, the ambient sensor of the fall detection device may be an altimeter, configured to generate data on changes in altitude. This may be advantageous as a fall typically comprises a change in altitude, thus sensor data may provide a further indication if a fall has happened or not. The altimeter may comprise a barometric pressure sensor configured to generate data on changes in the barometric pressure. Additionally, the altimeter may comprise a temperature sensor configured to generate data on the ambient temperature. This may be beneficial as the barometric pressure may also depend on the ambient temperature; thus, it may provide the means to estimate the altitude more precisely by also considering the ambient temperature.
  • In some embodiments, the fall detection device may comprise a proximity sensor configured to sense objects in close proximity and provide corresponding data. Such a proximity sensor may therefore indicate if the device is worn. For example, a proximity sensor located on the inside of a wristwatch may sense the skin of the user when being worn, i.e. it may sense an object in close proximity which may indicate that the device is worn.
  • Additionally or alternatively, the fall detection device may comprise a heart rate sensor, configured to generate data on the heart rate (HR) of a user. The heart rate sensor can be at least one of an electrocardiography (ECG) sensor and a photoplethysmography (PPG) sensor. The heart rate sensor may provide data on the heart rate of the user and/or through monitoring the sensor data determine if a vital sign is present as indication that the device is being worn.
  • Further, the fall detection device may comprise a pulse oximeter configured to generate data on the HR and oxygen saturation of the user. In some embodiments, the pulse oximeter may also be a photoplethysmography (PPG) sensor, i.e. the sensor may sometimes be configured to generate data on the HR and oxygen saturation of the user. Knowledge of the oxygen saturation may provide a further indication of a fall of the user and/or may for example provide information on the severity of the fall and/or the user's condition.
  • In some embodiments, the at least one movement sensor may be at least one of an accelerometer, configured to generate data on a physical acceleration of the fall detection device, a gyroscope, configured to generate data on an orientation of the fall detection device, and a magnetometer, configured to generate data on the orientation of the fall detection device. That is, the accelerometer may generate data on the physical acceleration of the device in at least one direction, preferably in three directions that are perpendicular to each other. The gyroscope and/or magnetometer may be configured to generate data on the orientation of the fall detection device within the three-dimensional space.
  • The fall detection device may comprise a memory, configured to store data and computer program code. The memory may comprise at least one non-volatile storage device (e.g. a solid-state drive (SSD)) and/or at least one volatile storage device (e.g. random-access memory (RAM)).
  • The fall detection device may comprise a processing unit, configured to operate the fall detection device. The processing unit may comprise at least one microprocessor, such as a central processing unit (CPU) and/or at least one circuit, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), etc.
  • In some embodiments, the processing unit may be configured to acquire data from at least one of the sensors continuously, at specified intervals or based on specific events. This may be advantageous for reducing the power consumption of the fall detection device. In particular, the times at which data is acquired may vary for each sensor. For example, some sensor data may only be acquired in consequence to sensor data acquired (and potentially processed) form different sensors.
  • Further, the processing unit may be configured to pre-process at least a subset of the acquired data. For example, the processing unit may pre-process the sensor data from the barometric pressure sensor and the temperature sensor to express the sensor data in terms of altitude. The processing unit may further be configured to store at least a subset of the acquired and/or pre-processed data in the memory at specified intervals, continuously or based on specific events.
  • The processing unit may further be configured to process at least a subset of the acquired, pre-processed and/or stored sensor data. For example, it may be configured to extract statistical values, such as an average or a deviation, from at least a subset of the sensor data. Additionally or alternatively, the processing unit may be configured to run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data. That is, the acquired, pre-processed, processed and/or stored sensor data.
  • In other words, the processing unit may be configured to process at least a subset of the sensor data and/or run a fall detection algorithm with the aim of identifying fall events of the user. That is, based on the sensor data the processing may, through data processing and/or running of a fall detection algorithm identify potential fall events of the user.
  • The fall detection algorithm may further be configured to estimate the severity of a fall event based on at least a subset of the sensor data. This may be advantageous as for example different actions may be taken depending on different severity levels of the fall. For example, in case of a very severe fall an alarm may be directly send professional emergency services, whereas for a less severe fall only a family member may be contacted.
  • In some embodiments, machine-readable program code may be stored in the memory, which may be configured to cause the processing unit to execute tasks and steps required to operate the fall detection device when executed on the processor or circuit.
  • The fall detection device may further comprise a user interface, configured to enable interactions with the user. This may be advantageous as it may for example provide the user with information, enable the user to modify settings and/or receive feedback from the user.
  • In some embodiments, the user interface may comprise a screen, wherein the screen may be a touch screen. The touch screen may further be configured to be pressure sensitive, i.e. the screen can distinguish between different levels of force. This may be beneficial as it may allow to provide different functionality of the user interface to the user, depending on the applied pressure.
  • Further, the screen may be configured to adjust the level of brightness. This may be advantageous for reducing the power consumption, for example by reducing the level of brightness of the screen in low light situations.
  • In some embodiments, the fall detection device may further comprise an ambient light sensor, configured to generate data on the illuminance. In such embodiments, the screen may be configured to adjust the brightness according to the ambient light sensor data.
  • Further, the user interface may comprise at least one physical button configured to execute a predetermined action when actuated by the user. Additionally or alternatively, the user interface may comprise at least one virtual button configured to execute a predetermined action when actuated by the user. A virtual button may for example be a button displayed on a touch screen, or a gesture detected though at least one sensor of the fall detection device, e.g., a certain movement registered by the movement sensor, such as tapping the fall detection device three times,
  • The predetermined action executed when the physical or virtual button is actuated may be one of triggering an alarm and aborting an alarm. In some embodiments, the predetermined action may depend on the alarm status of the fall detection device. For example, if the fall detection device has detected a fall based on at least a subset of the sensor data and subsequently triggered an alarm, the user may abort the alarm by actuating the corresponding physical or virtual button. Alternatively, if a user for example fell and the device did not register the fall, the user may still trigger an alarm by actuating the same button.
  • Further, the processing unit may be configured to control the user interface.
  • In some embodiments, the fall detection device may comprise a communication unit, configured to communicate with external devices. The communication unit can comprise at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM). Further, the communication unit may comprise at least one of a modem and a network device.
  • The communication unit may be configured to exchange data with a server via cellular and/or wireless networks. For example, the communication unit may send sensor data to a remote server, which may for example further analyse the data, or provide a subset of the data to a third party such as an emergency service. Further, the communication unit may be configured to establish a two-way communication between the fall detection device and another device such as a smartphone. That is, the fall detection device can for example establish and receive calls.
  • In some embodiments, the communication unit may be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth®, ANT+ or ZigBee. Additionally or alternatively, the communication unit may be configured to communicate and exchange data via a low power wide area network (LPWAN), such as a Long Range Wide Area Network (LoRaWAN) or SigFox.
  • The communication unit may be configured to communicate with digital assistants, such as voice assistants, e.g. Alexa, Siri or Google Assistant. Further, the communication unit may be configured to communicate with smart home devices.
  • The processing unit may be configured to send and receive processing instructions, sensor data, operational data, or the like via the communication unit.
  • The fall detection device may further comprise a battery, configured to power the fall detection device. In some embodiments, the battery may be removable. This may be advantageous for exchanging the battery, e.g., to keep the fall detection device ready for use.
  • The battery may comprise a capacity of at least 100mAh, preferably at least 300 mAh, even more preferably at least 500 mAh.
  • In some embodiments, the battery may be rechargeable. The fall detection device may be configured to recharge the battery wirelessly, e.g. through electromagnetic induction. Additionally or alternatively, the fall detection device may comprise a connector configured to receive a cable for a wired connection. The connector may comprise a magnetic component. This may be advantageous for establishing a good connection between the connector and the device. In embodiments where the battery is rechargeable, the connector may be configured to recharge the battery.
  • Further, the connector is configured to communicate with external devices, e.g. via a Universal Serial Bus (USB) connection. This may be advantageous for example for configuring and/or updating the fall detection device or for transferring large amounts of data.
  • The processing unit may be configured to manage the power consumption of the device. This may be advantageous to prolong the time the fall detection device may be utilized without recharging. In some embodiments, the fall detection device may be configured to run for at least 1 day, preferably at least 3 days, more preferably at least 7 days without recharging or changing the battery.
  • The fall detection device can comprise at least one position sensor configured to determine and provide data on the position based on a global navigation satellite system, such as GPS or Gallileo. This may be advantageous when a user experiences a fall and requires help. In such situations the position may be determined and for example shared with an emergency service or a family member of the user.
  • In some embodiments, the fall detection device may comprise a microphone, configured to generate data on an acoustic signal. The microphone may be configured to generate data on acoustic signals within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the microphone may be configured to generate data on acoustic signals in at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. This may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • In some embodiments, the fall detection device may comprise a loudspeaker, configured to produce sounds. The loudspeaker may be configured to produce sounds within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the loudspeaker may be configured to produce sounds within at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. Again, this may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • In some embodiments, the fall detection device may further comprise a blood sugar sensor, configured to generate data on the blood glucose level of the user. The fall detection device may further comprise a blood pressure sensor, configured to generate data on the blood pressure of the user. The fall detection device may further comprise a temperature sensor, configured to generate data on at least one of the ambient temperature and the body temperature of the user. The additional sensors may provide further information for detecting fall events. Further they may for example provide data for estimating a probability for a fall of the user and/or data to estimate the severity of a fall event. Further, some data may for example be provided to emergency services or family members of the user to support them making evidence-based decisions about the actions needed to better help the user particularly in case of a fall.
  • In some embodiments, the fall detection device may further comprise a haptic feedback unit configured to provide a haptic feedback to the user, e.g. in case of an alarm. The haptic feedback unit may comprise at least one vibration motor configured to provide vibrations as feedback to the user. This may be advantageous for getting the users attention, for example if an alarm is triggered.
  • In some embodiments, the fall detection device may be configured to connect to an external handheld device, such as a smartphone. Additionally, the fall detection device may be configured to be utilized as user interface for the handheld device, i.e. enable input to and output from the handheld device. Further, the fall detection device may be configured to display content from the external handheld device, such as messages, (push) notifications, applications or controls for applications, etc.
  • In some embodiment, the fall detection device may comprise a radar sensor configured to generate data on a distance.
  • In some embodiments, the fall detection device may further comprise an electrodermal activity sensor configured to measure the skin conductance. This may be advantageous as it may for example be indicative of the activity of the sympathetic nervous system and/or provide an indication for the hydration of the user, which may be particularly relevant for the elderly.
  • In another embodiment the present invention relates to a fall detection system for identifying a fall and triggering an alarm, the fall detection system comprising a fall detection device as described above. The fall detection system may further comprise at least one external sensor, configured to provide additional data, e.g. on the vital signs or weight of a user. In other words, a fall detection system may comprise a fall detection device and further at least one external sensor, e.g. a scale, an external heart rate monitor or a blood sugar sensor. This may be advantageous, as it may provide the system with sensor data of sensors that may for example not easily be incorporated in the fall detection device itself.
  • Further, the fall detection device may be configured to communicate with and receive data from the external sensors via a wired or wireless connection. The external sensors can be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth® or ANT+, and/or a wireless local area network (WLAN). This may enable reliable, fast and/or user-friendly transmission of data between the fall detection device and the at least one external sensor.
  • In some embodiments, the external sensors may comprise at least one of a blood sugar sensor, configured to generate data on the blood glucose level the user, a blood pressure sensor, configured to generate data on the blood pressure of the user, an ECG sensor, configured to generate data on the HR and the heart's electrical activity of the user, a pulse oximeter, configured to generate data on the HR and oxygen saturation of the user, a scale, configured to generate data on at least the weight of a user, and a blood coagulometer, configured to generate data on the coagulation efficiency of the user's blood.
  • The fall detection system may further comprise a professional service, such as a professional service provider, an emergency service or call centre. The fall detection system may comprise at least one emergency contact, such as a family member or a friend. Further, the fall detection device may be configured to directly send an alarm to the professional service and/or emergency contacts, e.g. family members, friends etc. This may be advantageous as the alarm may for example be send automatically, that is without any further interaction with the user, which may particularly be beneficial if the user got injured in a fall event.
  • In some embodiments, the fall detection system may further comprise a remote server, also referred to as server. The server may be configured to communicate and exchange data with the fall detection device. Additionally, the server may be configured to store data received from the fall detection device.
  • The fall detection device may be configured to send an alarm to the server. Additionally, the server may be configured to, upon receiving an alarm from the fall detection device, send an alarm to at least one third party, such as a professional service or an emergency contact. That is in some embodiments an alarm may first be send to the server and not directly to the professional service and/or emergency contact.
  • The server may be configured to store data on past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. Further, the server may be configured to store sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines or a stumble of the user. Generally, the stored data may be beneficial for improving the fall detection algorithm, e.g. for personalizing the fall detection algorithm to a specific user. Moreover, the sensor data may also provide insights for healthcare providers, and or family and friends. For example, it may indicate a long-term decline of physical activity or it may enable association of particular activities with a higher risk of falling. The remote server may at least be one of a dedicated server, a cloud-based server or any combination thereof, e.g. a dedicated server with additional cloud-based storage.
  • In another embodiment, the present invention relates to a method. The method comprising a fall detection system as described above, wherein the method comprises collecting sensor data from a plurality of the sensors of the fall detection system, determining the device status, i.e. if the fall detection device is worn by the user, based on data from at least one status sensor, utilizing a fall detection algorithm to determine if a fall has happened or not based on at least a subset of the sensor data, and triggering an alarm if a fall event is detected.
  • The step of collecting the sensor data may comprise pre-processing at least part of the sensor data. Further, the step of collecting sensor data may comprise storing at least part of the (pre-processed) sensor data in the memory. The sensor data may be collected repeatedly, wherein the frequency at which the sensor data is collected may be specific to each sensor.
  • In some embodiments, the data of the movement sensor may be collected repeatedly with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1 Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz.
  • The device status may be determined by analysing the data of one or a plurality of status sensors. For example, sensor data from a proximity sensor and/or a heart rate sensor. It will be understood that the heart rate data may also be utilized for the fall detection, i.e. the HR data may also be utilized as indication of a fall of the user. Further, the device status may be determined repeatedly with a frequency in a range of 100 mHz to 1 kHz, preferably 500 mHz to 100 Hz, such as 1 Hz.
  • Additionally or alternatively, determining the device status may be part of the fall detection algorithm. In other words, the device status may also be determined as part of the fall detection algorithm whereas in other embodiments it may determined separately form the fall detection algorithm. In the latter case, the fall detection algorithm may for example only executed when the device is worn.
  • In some embodiments, the fall detection algorithm may comprise at least one or a plurality of one or more steps of comparing at least a subset of the collected sensor data to pre-defined thresholds, and one or more steps of classifying a feature set and/or raw data derived from at least a subset of the collected sensor data, to determine if a fall has happened or not. The step of classifying a feature set may be based on statistical or machine learning methods.
  • In some embodiments, the collected sensor data may comprise data from at least one status sensor, data from at least one movement sensor, and data from at least one ambient sensor.
  • The data from the at least one status sensor may comprise HR data from a HR sensor. Additionally or alternatively, the data from the at least one status sensor may comprise data from a proximity sensor. Further, the data from at least one status sensor may comprise HR data and/or oxygen saturation data from a pulse oximeter.
  • The data from at least one movement sensor may comprise acceleration data from at least one accelerometer and/or orientation data from a gyroscope. Additionally or alternatively, the data from at least one movement sensor may comprise data from a magnetometer.
  • The data from the at least one ambient sensor may comprise barometric pressure data from a barometer. Additionally or alternatively, the data from at least one ambient sensor may comprise illuminance data form an ambient light sensor and/or temperature data from at least one temperature sensor. Further, the data from the at least one ambient sensor may comprise acoustic signal data from a microphone.
  • In some embodiments, the collected data may comprise blood pressure data from at least one blood pressure sensor and/or blood glucose level data from a blood sugar sensor. Additionally or alternatively, the collected data may comprise distance data from a radar sensor.
  • In some embodiments, the fall detection algorithm may comprise estimating the severity of a fall based on at least a subset of the sensor data.
  • The step of triggering an alarm may comprise a de-escalation phase enabling the user to abort an alarm. This may be advantageous as it may enable the user to abort an alarm., e.g., in case the user recovered quickly from the fall or no fall happened (false positive). The de-escalation phase may comprise providing a visual feedback, such as a countdown showing the time remaining to abort the alarm on the screen of the fall detection device. Further, the de-escalation phase may comprise providing an audio feedback and/or a haptic feedback.
  • The de-escalation phase may comprise a length and the length of the de-escalation phase may be in a range of 0 s to 20 s, preferably 0 s to 10 s. In some embodiments, the length of the de-escalation phase may depend on the estimated severity of the fall event. For example, for a very severe fall the de-escalation phase may be shorter than for a less severe fall to ensure that help will be provided to the user as soon as possible in case of a very severe fall.
  • The alarm may be aborted through manual input to the user interface, e.g. by voice command, actuating a physical or virtual button or through a touch screen.
  • In some embodiments, the communication unit may establish two-way communication between the fall detection device and another device such as a smartphone, e.g. in case of a fall or based on a user input.
  • The alarm may further be triggered manually through an input to the user interface, e.g. by voice command, pressing a physical or virtual button or through a touch screen.
  • In some embodiments, triggering an alarm may comprise an escalation phase. The escalation phase may follow the de-escalation phase in case the alarm is still active, i.e. it was not aborted during the de-escalation phase. Further, the escalation phase may comprise sending an alarm message to at least one of a professional service and an emergency contact. In some embodiments, the loudspeaker may generate a sound to draw attention during the escalation phase, e.g. a loud alarm signal or a call for help.
  • The escalation phase may comprise establishing a call with at least one of a professional service and an emergency contact. Further, the escalation phase may comprise establishing a call using the microphone and the loudspeaker of the fall detection device to enable hands-free operation.
  • In some embodiments, the method may comprise determining the device position and generating position data through at least one of collecting data from the at least one position sensor, localizing the device utilizing the method of a Wi-Fi positioning system, e.g. WLAN fingerprinting or triangulation, localizing the device through the Global System for Mobile Communications (GSM), localizing the device utilizing Bluetooth beacons, or any combination thereof.
  • The alarm message may comprise information on the fall event, e.g. time or estimated severity. Additionally or alternatively, the alarm message may further comprise user information, e.g. a user ID, name or medical history. This may be advantageous, as the professional service or emergency contact may thus tailor the response to the action based on the data received. For example, a professional service may check the medical history of a user and for example take into account known diseases of the user.
  • The alarm message may further comprise position data, e.g. from a position sensor, derived from the cellular network or a known WLAN. This may be advantageous for quickly finding the user in case of a fall, e.g., if the user is unconscious or does not remember his current location.
  • The alarm message may further comprise sensor data, e.g. HR, oxygen saturation, blood pressure or blood glucose level. This may be beneficial for judging the current health status of the user and taking the required actions. For example, it may allow the receiver of an alarm message to judge if a professional emergency service is required based on some of the vital signs of the user.
  • In some embodiments, the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. This may be advantageous for improving the performance of the fall detection device, i.e. it may for example reduce occurrence of false positives and false negatives in the process of detecting potential fall events.
  • Further, the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data that is specific to a group of users, e.g. defined by age, activity level or pre-existing conditions.
  • In some embodiments, the fall detection algorithm may be personalized based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data, wherein the database is specific to the user.
  • The database may further contain sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines. This may be beneficial for training of the fall detection algorithm since some activities may lead to sensor data very similar to fall events, e.g. going down stairs or taking an elevator. Thus, the fall detection may be trained to better distinguish such activities from actual fall events.
  • The input to the fall detection algorithm may further comprise information on ambient conditions, i.e. the algorithm may be context aware. In some embodiments, the fall detection algorithm may be adaptive, that is it may change e.g. depending on ambient conditions or physical activity of the user. For example, the algorithm may take into account current weather and/or lighting conditions when checking for potential fall events of the user. This may further improve the performance of the fall detection algorithm.
  • In some embodiments, the method may comprise receiving user input through the user interface, e.g. for changing device settings or updating user information. The method may further comprise receiving feedback following the detection of a fall event, e.g. confirmation that a fall happened or feedback on the severity of a fall by the user, a family member, a care taker, etc.
  • In some embodiments, the method may comprise triggering different events depending on the pressure applied to the pressure sensitive touch screen. In other words, the touch screen may be force sensitive such that depending on the applied force different actions may be triggered.
  • In embodiments wherein the fall detection device comprises an accelerometer, collecting the sensor data may comprise determining the acceleration of the device in all three dimensions, and separating the acceleration data into static (gravity) acceleration and dynamic (linear) acceleration by means of a low-pass filter. Further, collecting the sensor data may comprise determining an orientation angle of the device with respect to the vertical axis defined by the gravity component, i.e. static acceleration. The angle may for example be estimated by comparing the measured static acceleration to the expected gravitational component.
  • In embodiments, wherein the fall detection device comprises a gyroscope, collecting the sensor data may comprise determining the orientation angle of the fall detection device. This may be advantageous as a gyroscope may enable more precise determination of the orientation of the device. Further, the method may comprise combining the orientation data obtained by the accelerometer and the gyroscope.
  • The method may further comprise determining the orientation angle of the device for a set time interval I1, wherein the length of the time interval I1 may be in a range of 1 s to 20 s, preferably 4s to 10 s, such as 6 s.
  • In some embodiments collecting the sensor data may comprise detecting the ambient pressure and deducing the corresponding altitude. Further, deducing the altitude corresponding to the ambient pressure can be supported by current weather data and/or position data. This may be beneficial as it may improve the accuracy of deducing the altitude. Further, collecting the sensor data of the altimeter may comprise storing the raw barometric pressure and/or the deduced altitude.
  • In embodiments wherein the fall detection device comprises an accelerometer, the method can comprise monitoring the acceleration to detect an impact, determining the orientation angle of the fall detection device to detect an unnatural orientation of the fall detection device, confirming a change in altitude of the fall detection device based on the measurements of the altimeter, and triggering an alarm. An unnatural orientation of the fall detection device may correspond to a posture of the user that may not typically be assumed when standing or walking. In other words, a position that may be assumed following a fall.
  • The method may further comprise determining the amount of movement of the fall detection device to detect motionlessness. That is, the movement of the user may be checked, for example within a time interval. If the movement stays below a pre-defined threshold, e.g. the average of the movement within a predefined interval stays below a threshold, the user may be characterized as motionless. It will be understood that depending on the threshold the user may not literally be motionless but the overall movement may be smaller than a threshold. This may for example further indicate a fall from which the user cannot recover independently.
  • The method may further comprise comparing the sensor data of a potential fall event to sensor data of known activity patterns and determining if the sensor data corresponds to a known activity pattern. This may be advantageous for avoiding false alarms in case of known activities which may produce sensor readings that could indicate a fall such taking an elevator to go down. For example, by comparing a time series of at least a subset of the sensor data to the sensor data corresponding to known activities the number of false alarms may be reduced.
  • In some embodiments, the step of detecting an impact may comprise comparing the linear acceleration to a pre-set threshold, wherein a value above said threshold detects an impact.
  • The frequency at which the acceleration is monitored may be in a range of 1 Hz to 500 Hz, preferably 1 Hz to 100 Hz, such as 50 Hz.
  • The step of detecting an unnatural position of the fall detection device may comprise determining the orientation angle of the fall detection device for the time interval I1, and determining if the orientation angle is above a pre-set threshold for at least a fixed fraction F1 of the time interval to detect an unnatural position of the fall detection device. For example, the zero angle may be associated with the most common position of the device for a person that is standing or walking and large deviations for a prolonged time (e.g. multiple seconds) may indicate an unnatural position, i.e. a position that may correspond to a fall.
  • In some embodiments, the step of confirming a change in altitude can comprise comparing the relative change in the average altitude determined in an interval 12 before and in an interval 13 after the impact to a threshold to determine if the altitude of the fall detection device has changed sufficiently to indicate a fall of the user. The intervals 12 and 13 may each comprise a length in the range of 1 s to 15 s, preferably 3 s to 10 s such as 5 s. That is, a relative change of altitude before and after the impact of a potential fall may be determined. This may be advantageous as a fall typically results in a change of altitude particularly for the upper body parts of the user and thus the change of altitude may again be indicative of a fall of the user.
  • In some embodiments, the step of detecting motionlessness may comprise determining the amount of movement during the time interval I1, and determining if the amount of movement is below a pre-set threshold to detect motionlessness. Additionally, determining the amount of movement may comprise at least one of determining acceleration and determining changes in orientation during the time interval I1.
  • In some embodiments, the collected data on HR and/or oxygen saturation may be used for determining the status of the device and as part of the sensor data for the fall detection algorithm. In other words, the sensor data may be used for both, determining if the device is worn and as indication of potential fall events.
  • In some embodiments, the step of collecting sensor data may comprise detecting ambient noises and sounds and providing the corresponding sound data, i.e. data on acoustic signals. The method may further comprise analysing sound data from the microphone to identify sounds and noises associated with a fall event. This may be advantageous as typical sound patterns of a fall may be identified, e.g. through comparison. This may for example include the sound of impacts of a body on certain surfaces and/or moaning or screaming of a user in case of injuries and/or shock.
  • The method may further comprise determining the respiratory rate based on the noises and sounds detected by the microphone. In other words, the respiratory rate may be determined through sound data provided by the microphone. This may for example indicate the severity of a fall or provide information on the current heath status of a user. In some embodiments, the collected data may comprise respiratory rate data.
  • The method may comprise optimizing the power consumption of the device through at least one or a plurality of optimizing the sampling frequency for each sensor to reduce power consumption while maintaining a high precision of the fall detection, adjusting the brightness of the screen automatically depending on ambient conditions, adjusting the design of the user interface depending on current usage, switching the screen on and off depending on position of the device, optimizing the sampling frequency of the HR sensor or pulse oximeter according to the physical activity of the user, optimizing the sampling frequency of the movement sensor(s) according to the HR or pulse oximeter sensor data, and optimize frequency at which components such as communication unit or processing unit are woken up.
  • In some embodiments, the position sensor may be switched off or send into a power saving mode if the user is within a known wireless network. Additionally or alternatively, the position may only be updated, i.e. the position sensor may be woken up, if the user is moving based on the sensor data from the at least one movement sensor.
  • The frequency at which the position is determined may depend on the latest position. For example, the position may be determined with a low frequency if the device is close to the home of a user and high if the device is far away from the home of a user.
  • The method may further comprise recharging the battery of the fall detection device via a cable connected to the connector and/or wirelessly recharging the battery of the fall detection device.
  • The method may further comprise connecting to an external handheld device. Further, the method may comprise utilizing the fall detection device as a user interface for the handheld device. The method may further comprise displaying content of the external handheld device.
  • In some embodiments the present invention relates to the use of the device, system or method as described above for the detection of falls of a user. The use may further comprises triggering an alarm in case a fall of the user is detected.
  • That is, the present invention may provide a device, system and method for fall detection which may provide an improved accuracy of fall detection, i.e. it may reduce the number of false positive alarms and/or false negatives. This may be advantageous as it may improve the safety of the user and for example enable the user to live a more independent life.
  • Below, reference will be made to fall detection device embodiments. These embodiments are abbreviated by the letter "D" followed by a number. Whenever reference is herein made to "device embodiments", these embodiments are meant.
    • D1. A fall detection device comprising
      at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data;
      at least one movement sensor, configured to generate data on the movement and/or orientation of the fall detection device; and
      at least one ambient sensor, configured to generate data on the ambient conditions of the fall detection device.
    • D2. The fall detection device according to the preceding embodiment, wherein the fall detection device is configured to be a wearable device, that is the fall detection device is configured to be worn by a user.
    • D3. The fall detection device according to the preceding embodiment, wherein the fall detection device is configured to be worn around the wrist.
    • D4. The fall detection device according to any of the preceding embodiments, wherein the at least one status sensor is at least one of
      a proximity sensor, configured to sense any object in close proximity;
      a heart rate sensor, configured to generate data on the user's heart rate (HR); and
      a pulse oximeter, configured to generate data on the user's oxygen saturation and HR.
    • D5. The fall detection device according to any of the preceding embodiments, wherein the ambient sensor is an altimeter, configured to generate data on changes in altitude.
    • D6. The fall detection device according to the preceding embodiment, wherein the altimeter comprises a barometric pressure sensor configured to generate data on changes in the barometric pressure.
    • D7. The fall detection device according to the preceding embodiment, wherein the altimeter comprises a temperature sensor configured to generate data on ambient temperature.
    • D8. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a proximity sensor configured to sense objects in close proximity and provide corresponding data.
    • D9. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a heart rate sensor, configured to generate data on the heart rate (HR) of a user.
    • D10. The fall detection device according to the preceding embodiment, wherein the heart rate sensor is at least one of an electrocardiography (ECG) sensor and a photoplethysmography (PPG) sensor.
    • D11. The fall detection device according any of the preceding embodiments, wherein the fall detection device comprises a pulse oximeter configured to generate data on the HR and oxygen saturation of the user.
    • D12. The fall detection device according to any of the preceding embodiments, wherein the at least one movement sensor is at least one of
      an accelerometer, configured to generate data on a physical acceleration of the fall detection device;
      a gyroscope, configured to generate data on an orientation of the fall detection device; and
      a magnetometer, configured to generate data on the orientation of the fall detection device.
    • D13. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a memory, configured to store data and computer program code.
    • D14. The fall detection device according to the preceding embodiment, wherein the memory comprises at least one non-volatile storage device (e.g. a solid-state drive (SSD)) and/or at least one volatile storage device (e.g. random-access memory (RAM)).
    • D15. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a processing unit, configured to operate the fall detection device.
    • D16. The fall detection device according to the preceding embodiment, wherein the processing unit comprises at least one microprocessor, such as a central processing unit (CPU) and/or at least one circuit, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), etc.
    • D17. The fall detection device according to any of the 2 preceding embodiments, wherein the processing unit is configured to acquire data from at least one of the sensors continuously, at specified intervals or based on specific events.
    • D18. The fall detection device according to the preceding embodiment, wherein the processing unit is configured to pre-process at least a subset of the acquired data.
    • D19. The fall detection device according to any of the 2 preceding embodiments with the features of D13, wherein the processing unit is further configured to store at least a subset of the acquired and/or pre-processed data in the memory at specified intervals, continuously or based on specific events.
    • D20. The fall detection device according to any of the 3 preceding embodiments, wherein the processing unit is further configured to process at least a subset of the acquired, pre-processed and/or stored sensor data.
    • D21. The fall detection device according to any of the 4 preceding embodiments, wherein the processing unit is configured to run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data.
    • D22. The fall detection device according to the preceding embodiment, wherein the fall detection algorithm is further configured to estimate the severity of a fall event based on at least a subset of the sensor data.
    • D23. The fall detection device according to any of the preceding embodiments with the features of D13 and D15, wherein machine-readable program code is stored in the memory, configured to cause the processing unit to execute tasks and steps required to operate the fall detection device when executed on the processor or circuit.
    • D24. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a user interface, configured to enable interactions with the user.
    • D25. The fall detection device according to the preceding embodiment, wherein the user interface comprises a screen.
    • D26. The fall detection device according to the preceding embodiment, wherein the screen is a touch screen.
    • D27. The fall detection device according to the preceding embodiment, wherein the touch screen is configured to be pressure sensitive.
    • D28. The fall detection device according to any of the 3 preceding embodiments, wherein the screen is configured to adjust the level of brightness.
    • D29. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises an ambient light sensor, configured to generate data on the illuminance.
    • D30. The fall detection device according to the preceding embodiment with the features of D28, wherein the screen is configured to adjust the brightness according to the ambient light sensor data.
    • D31. The fall detection device according to any of the preceding embodiments with the features of D24, wherein the user interface comprises at least one physical button configured to execute a predetermined action when actuated by the user.
    • D32. The fall detection device according to any of the preceding embodiments with the features of D24, wherein the user interface comprises at least one virtual button configured to execute a predetermined action when actuated by the user.
    • D33. The fall detection device according to the preceding embodiment, wherein the predetermined action executed when the physical or virtual button is actuated is one of
      triggering an alarm; and
      aborting an alarm.
    • D34. The fall detection device according to any of the 3 preceding embodiments, wherein the predetermined action is depending on the alarm status of the fall detection device.
    • D35. The fall detection device according to any of the preceding embodiments with the features of D15 and D24, wherein the processing unit is configured to control the user interface.
    • D36. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a communication unit, configured to communicate with external devices.
    • D37. The fall detection device according to the preceding embodiment, wherein the communication unit comprises at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM).
    • D38. The fall detection device according to any of the 2 preceding embodiments, wherein the communication unit further comprises at least one of a modem and a network device.
    • D39. The fall detection device according to the preceding embodiment, wherein the communication unit is configured to exchange data with a server via cellular and/or wireless networks.
    • D40. The fall detection device according to the penultimate embodiment, wherein the communication unit is configured to establish a two-way communication between the fall detection device and another device such as a smartphone.
    • D41. The fall detection device according to any of the 5 preceding embodiments, wherein the communication unit is configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth®, ANT+ or ZigBee.
    • D42. The fall detection device according to any of the 6 preceding embodiments, wherein the communication unit is configured to communicate and exchange data via a low power wide area network (LPWAN).
    • D43. The fall detection device according to any of the preceding embodiments with the features of D36, wherein the communication unit is configured to communicate with digital assistants, such as voice assistants.
    • D44. The fall detection device according to any of the preceding embodiments with the features of D36, wherein the communication unit is configured to communicate with smart home devices.
    • D45. The fall detection device according to any of the preceding embodiments with the features of D15 and D36, wherein the processing unit is configured to send and receive processing instructions, sensor data, operational data, or the like via the communication unit.
    • D46. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a battery, configured to power the fall detection device.
    • D47. The fall detection device according to the preceding embodiment, wherein the battery is removable.
    • D48. The fall detection device according to any of the 2 preceding embodiments, wherein the battery comprises a capacity of at least 200 mAh, preferably at least 300 mAh, even more preferably at least 500 mAh.
    • D49. The fall detection device according to any of the 3 preceding embodiments, wherein the battery is rechargeable.
    • D50. The fall detection device according to the preceding embodiment, wherein the fall detection device is configured to recharge the battery wirelessly, e.g. through electromagnetic induction.
    • D51. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a connector configured to receive a cable for a wired connection.
    • D52. The fall detection device according to the preceding embodiment, wherein the connector comprises a magnetic component.
    • D53. The fall detection device according to any of the 2 preceding embodiments with the features of D49, wherein the connector is configured to recharge the battery.
    • D54. The fall detection device according to any of the 3 preceding embodiments with the features of D36, wherein the connector is configured to communicate with external devices, e.g. via a Universal Serial Bus (USB) connection.
    • D55. The fall detection device according to any of the preceding embodiments with the features of D15, wherein the processing unit is configured to manage the power consumption of the device.
    • D56. The fall detection device according to any of the preceding embodiments with the features of D46, wherein the fall detection device is configured to run for at least 1 day, preferably at least 3 days, more preferably at least 7 days without recharging or changing the battery.
    • D57. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises at least one position sensor configured to determine and provide data on the position based on a global navigation satellite system.
    • D58. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a microphone, configured to generate data on an acoustic signal.
    • D59. The fall detection device according to the preceding embodiment, wherein the microphone is configured to generate data on acoustic signals within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz.
    • D60. The fall detection device according to any of the 2 preceding embodiments, wherein the microphone is configured to generate data on acoustic signals in at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz.
    • D61. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a loudspeaker, configured to produce sounds.
    • D62. The fall detection device according to the preceding embodiment, wherein the loudspeaker is configured to produce sounds within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz.
    • D63. The fall detection device according to any of the 2 preceding embodiments, wherein the loudspeaker is configured to produce sounds within at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz.
    • D64. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a blood sugar sensor, configured to generate data on the blood glucose level of the user.
    • D65. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a blood pressure sensor, configured to generate data on the blood pressure of the user.
    • D66. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a temperature sensor, configured to generate data on at least one of the ambient temperature and the body temperature of the user.
    • D67. The fall detection device according to any of the preceding embodiments, wherein the fall detection device further comprises a haptic feedback unit configured to provide a haptic feedback to the user.
    • D68. The fall detection device according to the preceding embodiment, wherein the haptic feedback unit comprises at least one vibration motor configured to provide vibrations as feedback to the user.
    • D69. The fall detection device according to any of the preceding embodiments with the features of D36, wherein the fall detection device is configured to connect to an external handheld device.
    • D70. The fall detection device according to the preceding embodiment, wherein the fall detection device is configured to be utilized as user interface for the handheld device, i.e. enable input to and output from the handheld device.
    • D71. The fall detection device according to the preceding embodiment with the features of D25, wherein the fall detection device is configured to display content from the external handheld device, such as messages, (push) notifications, applications or controls for applications, etc.
    • D72. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises a radar sensor configured to generate data on a distance.
    • D73. The fall detection device according to any of the preceding embodiments, wherein the fall detection device comprises an electrodermal activity sensor configured to measure the skin conductance.
    • D74. The fall detection device according to any of the preceding embodiments, wherein the fall detection device is configured for contact/proximity tracing.
    • D75. The fall detection device according to the preceding embodiment and with the features of embodiment D36, wherein the communication unit is configured to broadcast and receive identifiers via Bluetooth Low Energy.
    • D76. The fall detection device according to the preceding embodiment and with the features of D13, wherein the fall detection device is configured to store received identifiers in the memory.
    • D77. The fall detection device according to any of the 2 preceding embodiments, wherein each received identifier is assigned with at least one parameter, wherein the at least one parameter comprises one or a plurality of
      receiving date;
      receiving time;
      contact time; and
      estimated distance.
    • D78. The fall detection device according to embodiments D77 and D76, wherein the fall detection device is configured to store received identifiers depending on at least one of the at least one assigned parameter.
    • Below, reference will be made to fall detection system embodiments. These embodiments are abbreviated by the letter "S" followed by a number. Whenever reference is herein made to "system embodiments", these embodiments are meant.
    • S1. A fall detection system for identifying a fall and triggering an alarm, the fall detection system comprising a fall detection device according to any of the preceding device embodiments.
    • S2. The fall detection system according to the preceding system embodiment, wherein the fall detection system further comprises at least one external sensor, configured to provide additional data, e.g. on the vital signs or weight of a user.
    • S3. The fall detection system according to the preceding system embodiment, wherein the fall detection device comprises the features of D36, wherein the fall detection device is configured to communicate with and receive data from the external sensors via a wired or wireless connection.
    • S4. The fall detection system according to the preceding system embodiment, wherein the external sensors are configured to communicate and exchange data via a wireless personal area network (WPAN) and/or a wireless local area network (WLAN).
    • S5. The fall detection system according to any of the 3 the preceding system embodiments, wherein the external sensors comprise at least one of
      a blood sugar sensor, configured to generate data on the blood glucose level the user;
      a blood pressure sensor, configured to generate data on the blood pressure of the user;
      an ECG sensor, configured to generate data on the HR and the heart's electrical activity of the user;
      a pulse oximeter, configured to generate data on the HR and oxygen saturation of the user;
      a scale, configured to generate data on at least the weight of a user; and
      a blood coagulometer, configured to generate data on the coagulation efficiency of the user's blood.
    • S6. The fall detection system according to any of the preceding system embodiments, wherein the fall detection device comprises the features of D36, wherein the fall detection system further comprises a professional service, such as a professional service provider, an emergency service or call centre.
    • S7. The fall detection system according to any of the preceding system embodiments, wherein the fall detection device comprises the features of D36, wherein the fall detection system comprises at least one emergency contact, such as a family member or a friend.
    • S8. The fall detection system according to any of the 2 preceding system embodiments, wherein the fall detection device is configured to directly send an alarm to the professional service and/or emergency contacts, e.g. family members, friends etc.
    • S9. The fall detection system according to any of the preceding system embodiments, wherein the fall detection system further comprises a remote server.
    • S10. The fall detection system according to the preceding system embodiment, wherein the fall detection device comprises the features of D36, wherein the server is configured to communicate and exchange data with the fall detection device.
    • S11. The fall detection system according to the preceding system embodiment, wherein the server is configured to store data received from the fall detection device.
    • S12. The fall detection system according to the penultimate system embodiment, wherein the fall detection device is configured to send an alarm to the server.
    • S13. The fall detection system according to the preceding system embodiment, wherein the server is configured to, upon receiving an alarm from the fall detection device, send an alarm to at least one third party, such as a professional service or an emergency contact.
    • S14. The fall detection system according to any of the preceding system embodiments with the features of S9, wherein the server is configured to store data on past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data.
    • S15. The fall detection system according to any of the preceding system embodiments with the features of S9, wherein the server is configured to store sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines or a stumble of the user.
    • S16. The fall detection system according to any of the preceding system embodiments with the features of S9, wherein the remote server is at least one of a dedicated server, a cloud-based server or any combination thereof.
    • Below, reference will be made to method embodiments. These embodiments are abbreviated by the letter "M" followed by a number. Whenever reference is herein made to "method embodiments", these embodiments are meant.
    • M1. A method comprising a fall detection system according to any of the preceding system embodiments, wherein the fall detection device comprises the features of D15 and D36, wherein the method comprises
      collecting sensor data from a plurality of the sensors of the fall detection system;
      determining the device status, i.e. if the fall detection device is worn by the user, based on data from at least one status sensor;
      utilizing a fall detection algorithm to determine if a fall has happened or not based on at least a subset of the sensor data; and
      triggering an alarm if a fall event is detected.
    • M2. The method according to the preceding method embodiment, wherein the step of collecting the sensor data comprises pre-processing at least part of the sensor data.
    • M3. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D13, wherein the step of collecting sensor data comprises storing at least part of the (pre-processed) sensor data in the memory.
    • M4. The method according to any of the preceding method embodiments, wherein the sensor data is collected repeatedly.
    • M5. The method according to the preceding method embodiment, wherein the frequency at which the sensor data is collected is specific to each sensor.
    • M6. The method according to any of the preceding method embodiments, wherein data of the movement sensor is collected repeatedly with a frequency in the range of 0.1 Hz to 1 kHz, preferably in the range of 1 Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz.
    • M7. The method according to any of the preceding method embodiments, wherein the device status is determined by analysing the data of one or a plurality of status sensors.
    • M8. The method according to the preceding method embodiment, wherein the device status is determined repeatedly with a frequency in a range of 100 mHz to 1 kHz, preferably 500 mHz to 100 Hz, such as 1 Hz.
    • M9. The method according to any of the 2 preceding method embodiments, wherein determining the device status is part of the fall detection algorithm.
    • M10. The method according to any of the preceding method embodiments, wherein the fall detection algorithm comprises at least one or a plurality of
      one or more steps of comparing at least a subset of the collected sensor data to pre-defined thresholds; and
      one or more steps of classifying a feature set and/or raw data derived from at least a subset of the collected sensor data;
      to determine if a fall has happened or not.
    • M11. The method according to the preceding method embodiment, wherein classifying a feature set is based on statistical or machine learning methods.
    • M12 The method according to any of the preceding method embodiments with the features of M10, wherein the collected sensor data comprises
      data from at least one status sensor;
      data from at least one movement sensor; and
      data from at least one ambient sensor.
    • M13 The method according to the preceding method embodiment, wherein the data from the at least one status sensor comprises HR data from a HR sensor.
    • M14 The method according to any of the 2 preceding method embodiments, wherein the data from the at least one status sensor comprises data from a proximity sensor.
    • M15 The method according to any of the 3 preceding method embodiments, wherein the data from at least one status sensor comprises HR data from a pulse oximeter.
    • M16 The method according to any of the 4 preceding method embodiments, wherein the data from at least one status sensor comprises oxygen saturation data from a pulse oximeter.
    • M17 The method according to any of the 5 preceding method embodiments, wherein the data from at least one movement sensor comprises acceleration data from at least one accelerometer.
    • M18 The method according to any of the 6 preceding method embodiments, wherein the data from at least one movement sensor comprises orientation data from a gyroscope.
    • M19 The method according to any of the 7 preceding method embodiments, wherein the data from at least one movement sensor comprises data from a magnetometer.
    • M20 The method according to any of the 8 preceding method embodiments, wherein the data from the at least one ambient sensor comprises barometric pressure data from a barometer.
    • M21 The method according to any of the 9 preceding method embodiments, wherein the data from at least one ambient sensor comprises illuminance data form an ambient light sensor.
    • M22 The method according to any of the 10 preceding method embodiments, wherein the data from at least one ambient sensor comprises temperature data from at least one temperature sensor.
    • M23 The method according to any of the 11 preceding method embodiments, wherein the data from the at least one ambient sensor comprises acoustic signal data from a microphone.
    • M24 The method according to any of the 12 preceding method embodiments, wherein the collected data comprises blood pressure data from at least one blood pressure sensor.
    • M25 The method according to any of the 13 preceding method embodiments, wherein the collected data comprises blood glucose level data from a blood sugar sensor.
    • M26 The method according to any of the 14 preceding method embodiments, wherein the collected data comprises distance data from a radar sensor.
    • M27. The method according to any of the preceding method embodiments, wherein the fall detection algorithm comprises estimating the severity of a fall based on at least a subset of the sensor data.
    • M28. The method according to any of the preceding method embodiments, wherein triggering an alarm comprises a de-escalation phase enabling the user to abort an alarm.
    • M29. The method according to the preceding method embodiment, wherein the fall detection device comprises the features of D25, wherein the de-escalation phase comprises providing a visual feedback, such as a countdown showing the time remaining to abort the alarm on the screen of the fall detection device.
    • M30. The method according to any of the 2 preceding method embodiments, wherein the fall detection device comprises the features of D61, wherein the de-escalation phase comprises providing an audio feedback.
    • M31. The method according to any of the 3 preceding method embodiments, wherein the fall detection device comprises the features D67, wherein the de-escalation phase comprises providing a haptic feedback.
    • M32. The method according to any of the 4 preceding method embodiments, wherein the de-escalation phase comprises a length and wherein the length of the de-escalation phase is in a range of 0 s to 20 s, preferably 0 s to 10 s.
    • M33. The method according to the preceding method embodiment with the features of M27, wherein the length of the de-escalation phase depends on the estimated severity of the fall event.
    • M34. The method according to the any of the preceding method embodiments with the features of method embodiment M28, wherein the fall detection device comprises the features of D24, wherein the alarm is aborted through manual input to the user interface.
    • M35. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D39, wherein the communication unit establishes two-way communication between the fall detection device and another device such as a smartphone.
    • M36. The method according to any of the preceding method embodiments, wherein the fall detection device comprises features D24, wherein the alarm is further triggered manually through an input to the user interface.
    • M37. The method according to any of the preceding method embodiments, wherein triggering an alarm comprises an escalation phase.
    • M38. The method according to the preceding method embodiment comprising the features of M28, wherein the escalation phase follows the de-escalation phase in case the alarm is still active, i.e. it was not aborted during the de-escalation phase.
    • M39. The method according to any of the 2 preceding method embodiments, wherein the escalation phase comprises sending an alarm message to at least one of a professional service and an emergency contact.
    • M40. The method according to any of the 3 preceding method embodiments, wherein the fall detection device comprises the features of D61, wherein during the escalation phase the loudspeaker generates a sound to draw attention.
    • M41. The method according to any of the 4 preceding method embodiments, wherein the fall detection device comprises the features of D39, wherein the escalation phase comprises establishing a call with at least one of a professional service and an emergency contact.
    • M42. The method according to the preceding method embodiment, wherein the fall detection device comprises the features of D58 and D61, wherein establishing a call comprises using the microphone and the loudspeaker of the fall detection device to enable hands-free operation.
    • M43. The method according to any of the preceding method embodiments, wherein the method comprises determining the device position and generating position data through at least one of
      collecting data from the at least one position sensor;
      localizing the device utilizing the method of a Wi-Fi positioning system, e.g. WLAN fingerprinting or triangulation;
      localizing the device through the Global System for Mobile Communications (GSM);
      localizing the device utilizing Bluetooth beacons;
      or any combination thereof.
    • M44. The method according to any of the preceding method embodiments with the features of M39, wherein the alarm message comprises information on the fall event.
    • M45. The method according to the preceding method embodiment, wherein the alarm message further comprises user information.
    • M46. The method according to any of the 2 preceding method embodiments with the features of M43, wherein the alarm message further comprises position data.
    • M47. The method according to any of the 3 preceding method embodiments, wherein the alarm message further comprises sensor data.
    • M48. The method according to any of the preceding method embodiments, wherein the fall detection algorithm is trained and updated based on a database of past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data.
    • M49. The method according to the preceding method embodiment, wherein the fall detection algorithm is trained and updated based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data that is specific to a group of users.
    • M50. The method according to any of the preceding method embodiments, wherein the fall detection algorithm is personalized based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data, wherein the database is specific to the user.
    • M51. The method according to any of the 3 preceding embodiments, wherein the database further contains sensor data not corresponding to a triggering or aborting of an alarm.
    • M52. The method according to any of the preceding method embodiments, wherein the input to the fall detection algorithm further comprises information on ambient conditions, i.e. the algorithm is context aware.
    • M53. The method according to any of the preceding method embodiments, wherein the fall detection algorithm is adaptive.
    • M54. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D24, wherein the method comprises receiving user input through the user interface.
    • M55. The method according to any of the preceding method embodiments, wherein the method further comprises receiving feedback following the detection of a fall event.
    • M56. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D27, wherein the method comprises triggering different events depending on the pressure applied to the pressure sensitive touch screen.
    • M57. The method according to any of the preceding method embodiments, wherein the fall detection device comprises an accelerometer and wherein collecting the sensor data comprises
      determining the acceleration of the device in all three dimensions; and
      separating the acceleration data into static (gravity) acceleration and dynamic (linear) acceleration by means of a low-pass filter.
    • M58. Method according to the preceding method embodiment, wherein collecting the sensor data further comprises determining an orientation angle of the device with respect to the vertical axis defined by the gravity component, i.e. static acceleration.
    • M59. Method according to any of the preceding method embodiments, wherein the fall detection device comprises a gyroscope and wherein collecting the sensor data comprises determining the orientation angle of the fall detection device.
    • M60. Method according to the 2 preceding method embodiments, wherein the method further comprises combining the orientation data obtained by the accelerometer and the gyroscope.
    • M61. The method according to any of the 3 preceding method embodiments, wherein the method further comprises determining the orientation angle of the device for a set time interval I1.
    • M62. The method according to the preceding embodiment, wherein the length of the time interval I1 is in a range of 1 s to 20 s, preferably 4s to 10 s, such as 6 s.
    • M63. The method according to any of the preceding embodiments, wherein the fall detection device comprises the features D6, wherein collecting the sensor data comprises detecting the ambient pressure and deducing the corresponding altitude.
    • M64. The method according to the preceding embodiment, wherein deducing the altitude corresponding to the ambient pressure is supported by current weather data and/or position data.
    • M65. The method according to any of the 2 preceding embodiments, wherein collecting the sensor data of the altimeter comprises storing the raw barometric pressure and/or the deduced altitude.
    • M66. The method according to any of the preceding method embodiments, wherein the fall detection device comprises an accelerometer and the features of D5, wherein the method comprises
      monitoring the acceleration to detect an impact;
      determining the orientation angle of the fall detection device to detect an unnatural orientation of the fall detection device; and
      confirming a change in altitude of the fall detection device based on the measurements of the altimeter; and
      triggering an alarm.
    • M67. The method according to the preceding method embodiment, wherein the method further comprises determining the amount of movement of the fall detection device to detect motionlessness.
    • M68. The method according to any of the 2 preceding method embodiments, wherein the method further comprises comparing the sensor data of a potential fall event to sensor data of known activity patterns and determining if the sensor data corresponds to a known activity pattern.
    • M69. The method according to any of the 3 preceding method embodiments with the features of M57, wherein the step of detecting an impact comprises comparing the linear acceleration to a pre-set threshold, wherein a value above said threshold detects an impact.
    • M70. The method according to any of the 4 preceding method embodiments, wherein the frequency at which the acceleration is monitored is in a range of 1 Hz to 500 Hz, preferably 1 Hz to 100 Hz, such as 50 Hz.
    • M71. The method according to any of the 5 preceding method embodiments with the features of M61, wherein the step of detecting an unnatural position of the fall detection device comprises
      determining the orientation angle of the fall detection device for the time interval I1; and
      determining if the orientation angle is above a pre-set threshold for at least a fixed fraction F1 of the time interval to detect an unnatural position of the fall detection device.
    • M72. The method according to any of the preceding method embodiments with the features of M66, wherein the step of confirming a change in altitude comprises comparing the relative change in the average altitude determined in an interval I2 before and in an interval I3 after the impact to a threshold to determine if the altitude of the fall detection device has changed sufficiently to indicate a fall of the user.
    • M73. The method according to the preceding method embodiment, wherein the intervals I2 and I3 each comprise a length in the range of 1 s to 15 s, preferably 3 s to 10 s such as 5 s.
    • M74. The method according to any of the preceding method embodiments with the features of M67, wherein the step of detecting motionlessness comprises
      determining the amount of movement during the time interval I1; and
      determining if the amount of movement is below a pre-set threshold to detect motionlessness.
    • M75. The method according to the preceding method embodiment, wherein determining the amount of movement comprises at least one of determining acceleration and determining changes in orientation during the time interval I1.
    • M76. The method according to any of the preceding method embodiments, wherein the fall detection device comprises features D9 and/or D11, wherein the collected data on HR and/or oxygen saturation is used for determining the status of the device and as part of the sensor data for the fall detection algorithm.
    • M77. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D58, wherein the step of collecting sensor data comprises detecting ambient noises and sounds and providing the corresponding sound data.
    • M78. The method according to the preceding method embodiment, wherein the method further comprises determining the respiratory rate based on the noises and sounds detected by the microphone.
    • M79. The method according to any of the preceding method embodiment, wherein the collected data comprises respiratory rate data.
    • M80. The method according to any the preceding method embodiments with the features of M66 and M77, wherein the method further comprises analysing sound data from the microphone to identify sounds and noises associated with a fall event.
    • M81. The method according to any of the preceding method embodiments, wherein the method comprises optimizing the power consumption of the device through at least one or a plurality of
      optimizing the sampling frequency for each sensor to reduce power consumption while maintaining a high precision of the fall detection;
      adjusting the brightness of the screen automatically depending on ambient conditions;
      adjusting the design of the user interface depending on current usage;
      switching the screen on and off depending on position of the device;
      optimizing the sampling frequency of the HR sensor or pulse oximeter according to the physical activity of the user;
      optimizing the sampling frequency of the movement sensor(s) according to the HR or pulse oximeter sensor data; and
      optimize frequency at which components such as communication unit or processing unit are woken up.
    • M82. The method according to any of the preceding method embodiments, wherein the fall detection device comprises features D36 and D57, wherein the position sensor is switched off or send into a power saving mode if the user is within a known wireless network.
    • M83. The method according to any of the preceding method embodiments, wherein the fall detection device comprises features D36 and D57, wherein the position is only updated, if the user is moving based on the sensor data from the at least one movement sensor.
    • M84. The method according to any of the preceding method embodiments, wherein the fall detection device comprises features D35 and D56, wherein the frequency at which the position is determined depends on the latest position.
    • For example, the position may be determined with a low frequency if the device is close to the home of a user and high if the device is far away from the home of a user.
    • M85. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D53, wherein the method further comprises recharging the battery of the fall detection device via a cable connected to the connector.
    • M86. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D50, wherein the method further comprises wirelessly recharging the battery of the fall detection device.
    • M87. The method according to any of the preceding method embodiments, wherein the fall detection device comprises the features of D36, wherein the method further comprises the fall detection device connecting to an external handheld device.
    • M88. The method according to the preceding method embodiment, wherein the method further comprises utilizing the fall detection device as a user interface for the handheld device.
    • M89. The method according to the preceding method embodiment, wherein the method further comprises displaying content of the external handheld device.
    • M90. The method according to any of the preceding method embodiments, wherein the method further comprises tracing the proximity of other devices.
    • M91. The method according to the preceding method embodiment, wherein the step of tracing the proximity of other devices comprises broadcasting and receiving identifiers via Bluetooth Low Energy.
    • M92. The method according to any of the 2 preceding method embodiments, wherein the step of tracing the proximity of other devices is implemented according to the PEPP-PT or DP3T system proposal.Below, reference will be made to use embodiments. These embodiments are abbreviated by the letter "U" followed by a number. Whenever reference is herein made to "use embodiments", these embodiments are meant.
    • U1. Use of the device, system or method according to the preceding device, system or method embodiments for the detection of falls of a user.
    • U2. The use according to the preceding use embodiment, wherein the use further comprises triggering an alarm in case a fall of the user is detected.
  • Embodiments of the present invention will now be described with reference to the accompanying drawings. These embodiments should only exemplify, but not limit, the present invention.
  • Brief description of the drawings
    • Fig. 1 depicts a schematic of a fall detection device according to a general embodiment;
    • Fig. 2 depicts a further embodiment of a fall detection device;
    • Fig. 3 schematically depicts a method for identifying a fall event;
    • Fig. 4 depicts an embodiment of a fall detection system; and
    • Fig. 5 depicts the de-escalation and the escalation phase when an alarm is triggered.
    Detailed description of embodiments
  • It is noted that not all the drawings carry all the reference signs. Instead, in some of the drawings, some of the reference signs have been omitted for the sake of brevity and simplicity of the illustration. Embodiments of the present invention will now be described with reference to the accompanying drawings.
  • With reference to Fig. 1, an embodiment of a fall detection device 100 is schematically shown. The fall detection device 100, also simply referred to as device 100, may very generally comprise a plurality of sensors 110,120,130, a user interface 140, a processing unit 150, a communication unit 160, a memory 170 and a battery 180.
  • The at least one status sensor 110 may be configured to provide data on the status of the device, that is if the device is worn or not. This information may be particularly important if the device is falling down without being worn, which could lead to false alarms (FP). It is a goal of the invention to reduce the occurrence of false alarms and thus the status sensor 110 is important for the overall functionality. It will be appreciated that worn may be understood as worn on the body. That is, it may refer to a device 100 that is worn tightly attached to some part of the body, such as on the wrist or clipped to the waist, however it may also refer to a device 100 that is worn more loosely, such as in a pocket, a backpack, on a necklace or in a hand.
  • In some embodiments, the status sensor 110 may have further functionality, i.e. in some instances it may provide more data than just the status of the device. In particular, the status sensor 110 may primarily be a sensor for vital signs. In other words, the status of the device may be determined through the presence or absence of a vital sign. For example, a HR sensor only provides HR data if the device is worn. This may be advantageous to a common proximity sensor, which may provide false readings if the sensor is blocked (accidentally or purposefully).
  • In addition, at least one movement sensor 120 may provide data on the movement of the device and subsequently on the movement of the user in case the device is worn. Typically, the one or more movement sensor is at least one of an accelerometer 121, a gyroscope and a magnetometer. These sensors may be used to monitor movements and/or the orientation of the device 100.
  • Further, the at least one ambient sensor 130 may provide data on the ambient conditions of the device. Preferably, the device 100 comprises at least one altimeter 131 configured to measure the altitude of the device 100. Typically, the altimeter 131 comprises a barometric pressure sensor configured to measure changes in the ambient barometric pressure. Based on a change in the barometric pressure a change in altitude may be estimated. In order to improve the accuracy of the estimated change in altitude the altimeter may also comprise a temperature sensor configured to sense the ambient temperature which may be considered when estimating the altitude based on the measured pressure.
  • Generally, the device is operated through a processing unit 150 which typically comprises a central processing unit (CPU) or at least one circuit, such as an application specific integrated circuit (ASIC).
  • During operation of the device 100 the processing unit 150 may acquire and store data from the sensors and run algorithms for processing and analysing the sensor data to identify a fall event and subsequently take corresponding measures according to the situation, e.g. send an alarm to a call centre or family members.
  • The frequency of acquiring sensor data can be specific to each sensor and happen at pre-defined intervals or conditional on specific events, such as certain values measured by other sensors.
  • In some embodiments, the processing unit 150 may run an algorithm to estimate the level of severity of a fall event. This may enable to choose the actions to take based on the likely severity of the detected fall. For example, a light fall may only require a call centre or family member to call and check if everything is ok, whereas a severe fall may even require dispatching of emergency personnel.
  • Further, the communication unit 160 of the device 100 may serve to send and receive instructions, sensor data, operational data or the like, e.g. it may communicate with external sensors, servers and call centres. Most importantly, the processing unit 150 may send an alarm via the communication unit 160 in case a fall of the device user is detected. Therefore, the communication unit 160 may provide means to establish wireless connections to external sensors, severs, phones and other devices relevant to the operation, for example via a cellular network, WLAN or WPAN (e.g. Bluetooth® or ANT+).
  • Part of the memory 170 may store sensor data for further processing and analysis. Preferably this part of the memory is configured as a ring memory. That is, the memory has a finite size and is filled successively with sensor data until the memory is full. Subsequently, the oldest data point is replaced with the latest data point, therefore keeping the x latest data points, where x is the maximum of data points that can be stored in the memory. There may be a ring memory provided separately for every sensor, which can vary in size depending on the sensor and the corresponding data.
  • Another part of the memory 170 may store machine-readable program code, that, when executed on the processing unit 150, causes the processing unit 150 to execute the tasks and steps required to operate the fall detection device 100. That is, the memory may for example store machine-readable program code corresponding to a fall detection algorithm that identifies a fall detection event based on the sensor data when run by the processing unit 150.
  • The battery 180 is designed to power the device 100 and is either removable or rechargeable (or both). In other words, in some embodiments the battery can be removed from the device whereas in other embodiments it is not designed to be removed by the user. In the latter case, the battery is rechargeable via a cable or wirelessly, while in the first case it may not be rechargeable.
  • The power consumption of the device 100 may be managed by the processing unit 150 in order to extend the battery lifetime while ensuring reliable operation of the device 100, e.g. by sending individual parts into a power saving mode or powering down components temporarily for intervals in which they are not required. In other words, the power consumption of the device 100 may be optimized by the processing unit 150 in order to reduce the energy consumption while ensuring save operation of the device 100.
  • A more specific embodiment of the present invention is discussed with reference to Fig. 2.
  • The device may utilise a HR sensor 112 as status sensor 110, i.e. the device checks if it is worn by checking if a valid HR signal is measured. Such a HR sensor 112 may either be an electrocardiography (ECG) sensor or, preferably, a photoplethysmography (PPG) sensor. Here, the measurement of a pulse and/or HR signal indicates that the device 100 is worn. This may be advantageous as such a vital signal is hard to synthetically create and thus provides a good indicator of the device status. For example, the device 100 may be a wristwatch with an optical (PPG) HR sensor that will measure the HR of the user once the watch is placed on the wrist.
  • Furthermore, an optical (PPG) HR sensor may be able to also measure the oxygen saturation in the blood.
  • The sensor data of the status sensor 110 may also be used as data for the fall detection algorithm. For example, the HR of the user may also provide an indication if a user has fallen or not. That is, the status sensor data is not necessarily exclusive for the determination of the device status.
  • It is noted that in other embodiments the fall detection device 100 may also comprise a proximity sensor as a status sensor 110. That is, the status of the device may be determined by a means of a proximity sensor. Further, the status may also be determined based on a combination of data from the proximity sensor and the heart rate sensor 121.
  • The movement sensor 120 in the depicted embodiment is an accelerometer 121, which may provide data on the static and dynamic acceleration of the device and thus enable to extract information of the device orientation relative to the surface of the earth.
  • In other words, the acceleration data may be filtered by means of a low-pass filter, e.g. a Butterworth filter, in order to extract the gravity component, which is basically static. Therefore, the sensor 121 may provide data on the dynamic (linear) acceleration corresponding to the movement of the device 100 and on the orientation relative to the gravitational field (i.e. the earth surface) by relating the dynamic acceleration data to the (static) gravity component. Such an accelerometer may for example be based on a microelectromechanical system (MEMS).
  • Further, the device 100 may comprise three ambient sensors 130.
  • The altimeter 131, also referred to as barometer 131, may provide data on the ambient barometric pressure. Through comparison of the estimated altitude at different times (or time intervals) a relative change in altitude may be determined. In other words, since the barometric pressure also depends on the altitude a relative change in height of the device can be estimated from the altimeter data.
  • The data of the altimeter may also allow to estimate the absolute altitude of the device, for this, context data such as current weather may be used to improve the accuracy.
  • A light sensor 132 may measure the illuminance in the surrounding of the device 100, and thus provide data for adjusting the brightness of a screen 141. This way, the brightness can for example be chosen such that the power consumption is reduced while still ensuring readability for the user.
  • Further, the ambient lighting conditions may also serve to provide context data for the fall detection algorithm since darker conditions may increase the risk of falling if a user is moving.
  • Further, a position sensor 133 may provide data on the global position of the device based on a global navigation satellite system such as GPS or Gallileo. This may be important in case of an alarm, as it enables the device 100 to provide data on the position of the user to the emergency contacts or services. This data may also be used to improve the accuracy of determining the absolute altitude.
  • Generally, the position detection may be supported by the cellular network and/or WLAN, as well as other signals that may enable localisation. For example, cellular networks may enable for mobile phone tracking, e.g. through localization based on the global system for mobile communications (GSM). Further, if a WLAN is present IP localization or a Wi-Fi positioning system may provide means to localise the fall detection device. Such techniques may be combined with the position sensor to allow for a localization indoors and outdoors and additionally may enable reduction of the power consumption of the device.
  • The user interface 140 may comprise a screen 141 which may for example show notifications for the user, information on the device status and charging status of the battery, settings of the device, current time, etc. Preferably, the screen 141 may be a touch screen, allowing the user to interact with the device, for example to change device settings, abort or trigger an alarm, edit personal information of the user, etc.
  • The brightness of the screen 141 may be adjustable to optimise power consumption and readability depending on ambient conditions and operating condition, e.g. in case of an alarm the screen brightness may be maximised to ensure readability.
  • In addition, the user interface 140 may comprise a physical button 142, allowing the user to manually trigger an alarm in case of a fall, or potentially another emergency situation, if the device did not automatically detect the event. That is, the user can manually trigger an alarm by actuating the button on the device. The button may also enable the user to abort an alarm during a de-escalation phase in case it has been triggered. Such a de-escalation phase my generally follow the triggering of an alarm to inform the user and provide a possibility to abort the alarm in case it has been a false alarm (FP).
  • In other embodiments of the present invention the user interface may comprise a virtual button instead of or in addition to the physical button 142. A virtual button may for example be an area of the touch screen 141, a pressure sensitive area on the device, or a motion sensor configured for gesture control. Furthermore, a virtual button can for example be realised by registering a tapping on the device with the accelerometer 121 or repeated covering of the light sensor 132. Generally, a virtual button may provide the same functionality as a physical button 142 when actuated.
  • Generally, a button may also provide functionalities other than triggering or aborting an alarm, e.g. a button may be used for changing settings of the device or for reacting to a message shown on the screen 141.
  • For providing acoustic feedback to the user, e.g. in case an alarm has been triggered, the user interface 140 may further comprises a loudspeaker 143. The speaker may for example generate a beeping sound or an alarm sound during the de-escalation phase following an alarm.
  • The device 100 may also comprises a microphone 144 which is part of the user interface 140, e.g. for voice commands. However, it may also function as a sensor. For example, the microphone 144 can detect sounds and noises in the surrounding of the device 100, that may be associated with a fall through sound recognition patterns. Further, the microphone 144 may provide data on the breathing of the user by monitoring the corresponding sounds.
  • In case of an alarm, microphone 144 and loudspeaker 143 may further allow the user to have a phone call with the corresponding emergency contact or the emergency services.
  • In addition to an acoustic feedback through the loudspeaker 143, the device 100 may also comprise a haptic feedback unit 145 which may comprise at least one vibrational motor. Thus, a haptic feedback can be provided, e.g. during the de-escalation phase or in case of a notification.
  • Finally, the device comprises a processing unit 150, a communication unit 160, a memory 170 and a battery 180 as described above.
  • In the following, a method for fall detection using a fall detection device 100 is discussed with reference to Fig. 3.
  • The device status may be checked in regular intervals (not shown in Fig 3). That is, the data of the at least one status sensor 110 may regularly be analysed to confirm that the device 100 is worn. In the case of the HR sensor 112 this means, that the presence of a valid HR signal is regularly checked to validate that the device 100 is worn, whereas for a proximity sensor it may be checked that an object is in close proximity to the proximity sensor and thus the device 100.
  • In other embodiments of the present invention, checking the device status may be part of the fall detection algorithm, that is it may be one of the steps of the fall detection algorithm.
  • The fall detection algorithm depicted in Fig. 3 may then monitor the data generated by the accelerometer 121 to identify any impact (step 210), wherein the acceleration data may be received either directly from the sensor or via the memory. As discussed earlier, the acceleration data may be pre-processed to be separated in to the gravity component and the linear (dynamic) acceleration.
  • Typically, a fall consists of a phase of reduced acceleration due to the (approximately) free fall and then a moment with a high spike in the acceleration due to an impact, e.g. on the floor. The algorithm may compare the acceleration to a threshold value set to identify such an impact.
  • The acceleration data may be preferably collected and analysed with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz. That is in the case of 100 Hz the algorithm checks for an impact 100 times per second.
  • If an impact is detected, that is if the acceleration exceeds the pre-set threshold, the sound data may be analysed (step 220). That is, sounds and noises recorded by the microphone 144 may be analysed to determine if a fall might have happened. That is, for example recorded sound patterns around the time of the impact may be analysed to recognize sound patterns which are associated with a fall, e.g. sound of an impact on a floor or a scream of a user. This may further increase the accuracy of the fall detection algorithm.
  • In a next step, the biomechanical posture of the user of the fall detection device 100 may be checked (230). For example, the orientation angle of the device may be checked to detect an unnatural orientation of the fall detection device. As discussed earlier, the orientation may be estimated by extracting the gravitational vector from the acceleration data. This may be done by low-pass filtering the data since the gravitational component can be approximated to be static. By evaluating the direction of the gravitational acceleration, the angle of the device relative to the earth surface may be estimated.
  • In some embodiments, the fall detection may further comprise a gyroscope to provide additional orientation data and thus improve the precision at which the orientation angle of the device may be determined. In these embodiments, the orientation angle may be determined only based on the gyroscope data or, preferably, based on the gyroscope and the accelerometer data.
  • The orientation angle of the device, may be indicative of the posture of the user. For example, if the fall detection device 100 is a wrist watch, it may indicate if the arm of the user is within the biomechanical constraints of the human musculoskeletal system. Certain postures may be associated with a high likelihood of a preceding fall (these postures may be referred to as unnatural position) and thus the algorithm may proceed to the next step, alternatively the algorithm may return to step 210 if for example the identified posture indicates that the user has recover from a fall.
  • Additionally or alternatively the movement of the user may be checked (step 240). In this step, the movement of the device within the interval may be analysed and in case the overall movement of the device 100 (and thus the user) stays below a pre-defined threshold the algorithm proceeds to the next step. Only if there is sufficient movement of the device registered, the algorithm goes back to 210. If the user is moving but still requires help, the alarm may be triggered manually.
  • In step 250 the algorithm evaluates the data from the altimeter 131, e.g. the barometric pressure, to estimate the altitude in an interval before and after the fall detection event, respectively. The changes in altitude may be indicative of a fall of the device (and the user). For example, the algorithm may simply compare the average altitude in the two intervals to estimate a relative change in altitude, or alternatively the algorithm may for example check if changes in the altitude signal within these two intervals match a specific signal pattern. If changes in the altitude are considered to be indicative of a fall, the algorithm may move to the next step. If the data of the altimeter indicates no changes in altitude typical of a fall, e.g. the changes do not match this pattern, the algorithm may for example go back to step 210. For estimating the altitude also other data may be considered, for example data on the ambient temperature.
  • For an adult person the leg length is typically above 60 cm, thus if the fall detection device is worn at the upper body or the wrist a change in altitude of at least 50 cm may be expected. However, the threshold may be personalized according to the body proportions and the place where the fall detection device is worn.
  • The step of determining the change in altitude may be advantageous for example to prevent alarms in case a user is hitting a table with his hand, e.g. during playing cards. This may lead to a detection of an impact and an orientation angle above the threshold but does of course not correspond to a fall event. Thus, checking the altitude provides means to reduce the occurrence of FP, improving the accuracy of the fall detection device.
  • In a further step, the algorithm may compare the activity pattern to known activity patterns to avoid false alarms (step 260). That is, based on the collected sensor data, the algorithm may determine if the sensor data around the point of the identified impact or potential fall event can be can be associated to a known activity pattern, e.g. stored in a database of known activity patterns. That is, the sensor data may be compared to the sensor data of known activity patterns to rule out that an alarm is triggered due to a known activity which may lead to sensor readings that mimic a fall event.
  • For example, taking an elevator may result in sensor readings that may cause the fall detection algorithm to detect an impact, alongside with a change of altitude and potentially reduced movement such that it may lead to the result that a fall may have happened. By comparing the sensor data to known activity patterns it may be identified that the user was taking an elevator and thus a false alarm may be prevented.
  • Finally, the fall detection may trigger an alarm if all the preceding steps indicate that a fall has happened (step 270).
  • It will be understood, that the depicted fall detection algorithm merely serves as an example. That is, further steps may be added, shown steps may be omitted and/or their respective order may be changed. Thus, it will be appreciated by the person skilled in the art, that other sensor data and thresholds may be part of the algorithm by adding more steps or replacing current steps. For example, HR sensor data may not only be used to determine if the device is worn, but a change in HR during the fall event may be a further indicator for a fall event.
  • The fall detection algorithm may for example also comprise a step of estimating the severity of a fall based on the measured sensor data. For example, the severity may be based on the amplitude of the impact and/or the amount by which a threshold is exceeded.
  • Generally, the fall detection algorithm may return to its first step upon finding that in one step the data does not correspond to a fall event, e.g. if there was no sufficient change in altitude. However, in some implementations of the algorithm, a further step may be executed to confirm that no fall has happened. In other words, there may be implementations wherein only one of two steps may be required to indicate that a fall has happened for the algorithm to continue. For example, there may be embodiments, where it is enough if either a sufficient change of altitude was measured (step 250) or the movement was below a pre-defined threshold (260). Whereas in other embodiments both of the steps are required to indicate that a fall has happened.
  • With reference to Fig. 4, the fall detection device 100 may be part of a fall detection system 200, also referred to as system 200. Such a system 200 may further comprise at least one or a plurality of external sensors 310 which may provide additional data for the fall detection device. These data may provide further sensor data for the fall algorithm and/or provide medical background data, e.g. in case of a fall event.
  • The fall detection device 100 may communicate and exchange data with the external sensors via a wired connection or, preferably, a wireless connection, such as a wireless personal area network, e.g. Bluetooth® or ANT+ or WLAN.
  • Further, the system 200 may comprise a professional service 320, which may for example be a professional service provider or call centre. The fall detection device 100 may be configured to send an alarm message to and/or establish a phone call with the professional service 320 in case an alarm is triggered and not aborted.
  • Further, the fall detection device 100 may share data with the professional service 320, such as medical data, summary of activity of the user or the like. This way, the professional service 320 may also be informed about the general health status of the user and may be enabled to provide preventive measures and assistance to the user and/or his family and friends.
  • Similarly, the system 200 may comprise at least one emergency contact 330, such as a family member or a friend. The one or more emergency contacts may be contacted by the emergency device 100 in case of an alarm that is triggered and not aborted. That is the fall detection device may send an alarm message and/or establish a phone call between the user and the emergency contact 330.
  • An alarm message may for example contain information about the estimated severity of a fall, timing information, user ID, medical background information, sensor data such as position and vital signs. This may be advantageous as it may enable the professional service 320 or the emergency contact 330 to get a better judgement of the situation and enable them to take the appropriate measures.
  • In some embodiments, an alarm message may be sent or a phone call established in case an alarm has been aborted.
  • The fall detection system 200 may further comprise a server 340 which may be configured to communicate and exchange data with the fall detection device 100. The server may store data received from the fall detection device 100, e.g. for training or personalization of the fall detection algorithm.
  • In some embodiments the fall detection device 100 may send an alarm message to the sever 340 in case an alarm has been triggered and not aborted. This may be either instead or in addition to an alarm message or phone call to an professional service 320 and/or emergency contact 330.
  • The server 340 may also store data regarding past alarms that have been triggered either manually or automatically alongside a part (or all) of the corresponding sensor data. These data may represent datasets corresponding to TP (automatically triggered) or FN (manually triggered), which may serve to train and improve and/or personalize the fall detection algorithm.
  • The server 340 may also store information on aborted alarms together with at least a subset of the corresponding sensor data. This data would correspond to FPs which may also be used for training, improving and/or personalizing the fall detection algorithm. The stored data may be supplemented by information from the user, professional service 320 and/or emergency contact 330 to provide more detailed feedback on the fall event.
  • Further, the server may in some embodiments also store sensor data that does not correspond to a triggering or aborting of an alarm, i.e. data on TNs, which could for example be sensor data corresponding to a specific activity or a standard routine or also a stumble of the user. This data may also be used for training, improving and/or personalizing the fall detection algorithm.
  • The data stored may also comprise sensor data on the ambient conditions, which may also be used as an input to the fall detection algorithm.
  • Part of the above-mentioned data may also be helpful for identifying preventative measures. For example, the data may reveal potentially risky situations for the user which may be avoided through certain measures, such as adjusting medication, changing furniture position, etc.
  • The server 340 may also communicate and exchange data with one, or a plurality of, external sensor(s) 310, e.g. to collect their data and store it and/or send it to the fall detection device 100.
  • The server 340 may be a remote server, more precisely it may be a dedicated server, a cloud-based server or for example a combination of a dedicated server and cloud-based storage.
  • The triggering of the alarm is described in further detail with reference to Fig. 5. Once an alarm is triggered, either by the algorithm or the user, a de-escalation step 410 may be entered during which the user may be able to still abort the alarm. This is particularly useful in cases of FP or if the user was able to recover from the fall and does not require further assistance, i.e. the severity was low. This step may also be referred to as de-escalation phase 410.
  • The de-escalation phase 410 will last for a pre-defined time, e.g. 5 s or 10 s. In some instances, the length of the de-escalation phase 410 may be 0 s, that is the de-escalation step 410 may be skipped. Generally, the length of the time interval may be defined with respect to the estimated severity of a fall. That is, there may be more time for the user in case of a less severe fall event in comparison to a sever fall event where the de-escalation step 410 may be very short or, in some instances, skipped.
  • During the de-escalation phase 410 a countdown may be shown on the screen 141, indicating the time remaining until the alarm message is sent. Further, the countdown may be accompanied by a sound played via the loudspeaker 143, e.g. there may be a "beep" every second of the countdown. In addition, the haptic feedback unit 145 may also indicate the presence of a countdown and thus the possibility to cancel the alarm, e.g. the device may vibrate during the countdown.
  • The user may be enabled to abort the alarm in different ways. For example, the user may use the button 142 to cancel an alarm that hast already been triggered. That is, the button triggers an alarm in case no alarm has been triggered yet and aborts an alarm in case the device is in the de-escalation phase 410. In some embodiments, the device may have two buttons, one button 142 to trigger an alarm and another button to cancel an alarm during the de-escalation phase 410.
  • Further, the user may cancel an alarm by tapping on the touch screen 141. For example, the user may be required to tap the screen three times in order to reduce the likelihood of accidently cancelling an alarm.
  • In some cases, it may be inconvenient for the user to reach the device and press the button 142 or touch the screen 141. Thus, it may also be possible to cancel the alarm using a voice command detected by the microphone 144 of the device 100. A voice command may be a predefined command, e.g. "stop", "cancel alarm", or similar phrases.
  • In case an alarm is still active after the de-escalation phase 410, i.e. it has not been aborted, the next step is the escalation step 420, also referred to as escalation phase 420. During this step, the alarm is communicated according to predefined rules and protocols. The escalation step 420 may include sending an alarm message, e.g. an SMS, to at least one of a professional service 320 and an emergency contact 330. The message may include information about the event, e.g. estimated severity of the fall, user ID, medical background of the user, location of the user, e.g. GPS coordinates of the device location, and/or summary of the vital signs measured by some of the sensors of the device 100. The user may specify a list of contacts that receive an alarm message upon entering the escalation step 420.
  • Further or alternatively, the device 100 may trigger a phone call to an emergency service 320 or an emergency contact 330 enabling the user to speak to the emergency contact or service using the microphone 144 and the loudspeaker 143 of the device 100.
  • The user may specify a list of emergency contacts 330. The device 100 may then attempt to establish a phone call with the first emergency contact 330 and only call the second emergency contact 330 in case the first cannot be reached and so forth. This may increase chances of reaching at least one emergency contact 330.
  • When the user manually triggers an alarm, the de-escalation phase 410 may be skipped, however in order to avoid FP due to accidentally triggering the alarm, the de-escalation phase 410 may still be entered in case of a manually triggered alarm.
  • In another embodiment the fall algorithm may be based on statistical classification methods, such as machine learning methods.
  • Very generally, a first step for generating a model may be the collection of data that is accurate enough to generate a proper training file. Such a data collection may involve exemplary sensor data for fall events in different situations and surroundings, e.g. fall from a standing position to the front, back or side, fall onto a piece of furniture, fall during a physical activity etc., furthermore the data collection may comprise exemplary sensor data on near fall events, e.g. a person stumbling but not falling, on physical activities, e.g. a person running or jumping or on activities normally performed when at home, e.g. sitting down on a bed or sofa, cleaning or cutting vegetables and fruits.
  • Such a data collection may enable identifying and training of an appropriate classification algorithm that is able to distinguish between fall and non-fall events with a high success rate, i.e. limited number of FP and TN.
  • In a next step the features required for the classification may be assessed and refined. In other words, there may be a feature selection process to explore the possibility of reducing the number of features required for the classification. This may enable to reduce the required number of features and thus the amount of sensor data that needs to be processed, which may be advantageous to improve speed and efficiency of the classification algorithm.
  • Once the required features are selected a final model may be generated using the selected features and the classification algorithm. This model may then be implemented into the real time application, e.g. the fall detection device 100, with the capability to update the model. This way, the model may be adaptable for different users and/or groups of users.
  • That is during operation of the fall detection device 100, the processing unit 150 may receive and analyses the sensor data to extract corresponding features. Such features may be statistical quantities of a data set, such as the mean or standard deviation, or other measurable or characterising properties, e.g. maximum/minimum value, a certain ratio, etc. These features may then form a feature set that may be characteristic for a certain instance in time. Such a feature set includes at least one feature of a status sensor 110, a movement sensor 120 and an ambient sensor 130, respectively. The feature set may be provided to the fall detection algorithm which may be based on a predetermined model that may classify the data into fall and non-fall events. It will be understood, that the fall detection algorithm comprises an implementation of the model.
  • During the operation of the device data may be stored for improvements of the model and/or the fall detection algorithm. That is, sensor data may be stored to later serve as training data for improving the classification algorithm and/or the model that is based on said classification algorithm. Such data may particularly be data of FP (i.e. when the alarm is aborted by the user), FN (i.e. when the alarm is triggered by the user) and TP (i.e. when an automatically triggered alarm is not aborted by the user). Further, also TN data may be saved, i.e. for example data that corresponds to a certain physical activity. The training data may be improved through feedback of the user with reference to certain fall and non-fall events. For example, the user may be asked to confirm a fall and/or rate the severity thereof.
  • In some embodiments the fall detection device 100 may further comprise means for realizing contact tracing and/or proximity tracing. That is, very generally during an epidemic and/or pandemic, e.g. with a contagious virus, such as an influenza or corona virus, it may be desirable to be able to determine who was in close proximity of an infected person during a period where the person may already have been contagious. That is, such viruses may for example spread via aerosols in the breath of a person, which may typically be particularly contagious over a distance of 1.5 to 2 m. Traditionally such contract tracing may be conducted via interviews, wherein an infected person would be asked to recall the contact persons and visited places during the potentially contagious period, e.g. 2 weeks. However, it may often be difficult to remember all details and further, there may be contacts in public spaces such as public transport which may not be traced in such a way, as no contact data of other users of the public transport may be available.
  • Therefore, it may be advantageous to utilize technological devices to aid with tracing relevant contacts. This may for example be achieved utilizing a device, such as a smartphone, for logging the location of a person, e.g. utilizing GPS. However, there may be data privacy concerns and continuously logging a position via GPS may further require relatively high energy.
  • Alternate methods have been proposed, particularly utilizing Bluetooth® and specifically Bluetooth Low Energy (BLE), which may allow to log other devices nearby by sharing an identification, such as an Ephemeral Identifier. That is, each device may periodically share a respective identifier, which will be received by nearby devices and can be stored to record potential proximity to another person. In other words, the principal would be similar (or the same) as for Bluetooth beacons, which may typically also rely on broadcasting an ID via Bluetooth Low Energy. The storage of such an ID may for example depend on the time two devices were in close proximity and the estimated distance between the two devices. The distance to other device may for example be estimated via the signal strength of the received Bluetooth signal in comparison to the signal strength at which it was send out, which may for example also be shared as information). Such a method may have the advantage, that only proximity to other persons may be tracked and no location, such that it may be impossible, or at least hard, to deduct a movement pattern of a person.
  • There are multiple ideas to implement such protocols in a way that complies with data protection regulations. For example, Google and Apple consider to implement respective APIs which may be directly included in the respective operating system of a smartphone and similarly, projects like Decentralized Privacy-Preserving Proximity Tracing (DP3T) and Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) are developing proposals and protocols for secure privacy-preserving proximity tracing systems.
  • However, such a system only works, if the designated devices, e.g. smartphones, are constantly carried by the user. While a large fraction of smartphone users tends to keep their phone with them for most activities, they may sometimes forget the phone, or for example during sports, deliberately leave the phone at home. Moreover, there is still a significant part of the population that does not own a smartphone, in particular elderly people but also children.
  • Therefore, the fall detection device, which may for example be a wristwatch, such as a smartwatch, may further be configured for proximity tracing. That is, the fall detection device may be configured to implement proximity tracing, in particular privacy-preserving proximity tracing, such as PEPP-PT or DP3T. For example, the communication unit 160 may be configured to provide and receive a Bluetooth Low Energy signal, particularly to broadcast and receive respective identifiers, such as an Ephemeral Identifier. Preferably, said identifiers may be encrypted. The identifiers may for example be based on a secret seed which may be generated when the respective feature is initially activated on the fall detection device, e.g. when a respective program or application is installed. Each identifier may typically only be utilized for a pre-set time interval, e.g. 15 min, 20 min or 60 min 45 min or 60 min in order to comply with privacy obligations. That is, the fall detection device 100 may generate a number of different identifiers, e.g. based on a secret seed and utilizing a pseudo random function as well as a stream cipher.
  • Received identifiers, which are broadcasted by nearby devices may for example be stored in the local memory 170 alongside an indication of the date and/or time it was received.
  • Storage of an identification may depend on the estimated distance of the corresponding device, e.g. from the signal strength, and the time the corresponding device was in close proximity. Furthermore, the stored identifiers may be automatically deleted after a set period of time, which may for example correspond to the time period a person is considered to be contagious, e.g. 14 days or 21 days.
  • In case any of the users of a device that was considered to be in close proximity is tested positive for the virus, the fall detection device may notify the user that there may be an increased risk for an infection and for example inform the user of further steps. In some cases, the fall detection device may further be configured to also notify an emergency contact 330 and/or an emergency service 320. Similarly, if the user of the fall detection device is tested positive for the virus, the fall detection device may be utilized to inform (anonymously or at least pseudo anonymously) other devices (and their users) that have been in close proximity during the relevant contagious period according to the rules and implementation of the utilized protocol, e.g. DP3T or PEPP-PT.
  • Implementing such proximity tracing on a fall detection device may be advantageous, since the user of a fall detection device may already wear the fall detection device anyway. Furthermore, the fall detection device may generally be designed such that it can be worn without significantly restricting the user, which may increase the likelihood of it being worn and decrease the chances for forgetting it, since it is typically (unlike a smart phone) attached to the body, e.g. as a wristwatch. Additionally, particularly elderly people are often at risk during an epidemic or pandemic may not own a smartphone. However, they may already utilise a fall detection device, such that the additional functionality of proximity/contact tracing may be implemented without affecting the routine of these people. Furthermore, the willingness to carry a fall detection device, which may be small and easy to handle, e.g. as a wrist watch, may be higher than getting a smartphone only for being able to have access to proximity tracing.
  • Whenever a relative term, such as "about", "substantially" or "approximately" is used in this specification, such a term should also be construed to also include the exact term. That is, e.g., "substantially straight" should be construed to also include "(exactly) straight".
  • Whenever steps were recited in the above or also in the appended claims, it should be noted that the order in which the steps are recited in this text may be accidental. That is, unless otherwise specified or unless clear to the skilled person, the order in which steps are recited may be accidental. That is, when the present document states, e.g., that a method comprises steps (A) and (B), this does not necessarily mean that step (A) precedes step (B), but it is also possible that step (A) is performed (at least partly) simultaneously with step (B) or that step (B) precedes step (A). Furthermore, when a step (X) is said to precede another step (Z), this does not imply that there is no step between steps (X) and (Z). That is, step (X) preceding step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), ..., followed by step (Z). Corresponding considerations apply when terms like "after" or "before" are used.
  • While in the above, a preferred embodiment has been described with reference to the accompanying drawings, the skilled person will understand that this embodiment was provided for illustrative purpose only and should by no means be construed to limit the scope of the present invention, which is defined by the claims.

Claims (15)

  1. A wearable fall detection device comprising
    at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data;
    at least one movement sensor, configured to measure and provide data on the movement and/or orientation of the fall detection device;
    at least one ambient sensor, configured to measure and provide data on the ambient conditions of the fall detection device;
    a processing unit, configured to
    operate the fall detection device and
    run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data; and
    a communication unit, configured to communicate with external devices, wherein the communication unit comprises at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM).
  2. The fall detection device according to the preceding claim, wherein the fall detection device comprises a user interface, configured to enable interactions with the user and comprising
    a screen; and
    a physical or virtual button configured to execute a predetermined action when actuated by a user.
  3. A fall detection system for identifying a fall and triggering an alarm, wherein the fall detection system comprises a fall detection device according to any of claims 1 to 2 and wherein the system comprises at least one of a professional service and an emergency contact.
  4. The system according to the preceding claim, wherein the fall detection device is configured to send an alarm directly to the professional service and/or emergency contacts.
  5. The system according to any of claims 3 and 4, wherein the system comprises a remote server configured to
    communicate and exchange data with the fall detection device, and
    store data received from the fall detection device.
  6. The system according to any of claims 3 to 5, wherein the fall detection device is configured to send an alarm to the server, wherein the server is configured to, upon receiving an alarm from the fall detection device, send an alarm to at least one third party, such as a professional service or an emergency contact.
  7. The system according to any of claims 3 to 6, wherein the system comprises at least one external sensor and wherein the fall detection device is configured to communicate with and receive data from the at least one external sensor via a wired or wireless connection.
  8. Method comprising a fall detection device according to any of claims 1 to 2 or a fall detection system according to any of claims 3 to 7, wherein the method comprises
    measuring and collecting sensor data from a plurality of the sensors of the fall detection system;
    determining the device status, i.e. if the fall detection device is worn by a user, based on data from at least one status sensor;
    utilizing a fall detection algorithm to determine if a fall has happened or not based on at least a subset of the sensor data; and
    triggering an alarm if a fall event is detected.
  9. The method according to the preceding claim, wherein the fall detection algorithm comprises at least one or a plurality of
    one or more steps of comparing at least a subset of the measured and collected sensor data to pre-defined thresholds; and
    one or more steps of classifying a feature set and/or raw data derived from at least a subset of the measured and collected sensor data;
    to determine if a fall has happened or not;
    wherein the measured and collected sensor data comprises data from at least one status sensor, at least one movement sensor and at least one ambient sensor.
  10. The method according to any of claims 8 to 9, wherein triggering an alarm comprises a de-escalation phase enabling the user to abort an alarm and an escalation phase, wherein the escalation phase follows the de-escalation phase in case the alarm is still active, i.e. it was not aborted during the de-escalation phase.
  11. The method according to any of the preceding method embodiments, wherein the fall detection device comprises an accelerometer and an altimeter, wherein the method comprises
    monitoring the acceleration to detect an impact;
    determining the orientation angle of the fall detection device to detect an unnatural orientation of the fall detection device; and
    confirming a change in altitude of the fall detection device based on the measurements of the altimeter; and
    triggering an alarm.
  12. The method according to the preceding claim, wherein the method further comprises determining the amount of movement of the fall detection device to detect motionlessness.
  13. The method according to any of the 2 preceding claims, wherein the fall detection device comprises a microphone and
    wherein the step of collecting sensor data comprises detecting ambient noises and sounds and providing the corresponding sound data, and
    analysing sound data from the microphone to identify sounds and noises associated with a fall event.
  14. The method according to any of claims 8 and 13, wherein the fall detection algorithm comprises estimating the severity of a fall based on at least a subset of the sensor data.
  15. Use of the fall detection device according to any of claims 1 to 2, the fall detection system according to any of Claims 3 to 7 or the method according any of the claims 8 to 14, wherein the use comprises
    automated detection of a fall of a user; and
    triggering of an alarm if a fall of a user is detected.
EP20188159.6A 2019-07-29 2020-07-28 Device, system and method for fall detection Withdrawn EP3796282A3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19188875 2019-07-29

Publications (2)

Publication Number Publication Date
EP3796282A2 true EP3796282A2 (en) 2021-03-24
EP3796282A3 EP3796282A3 (en) 2021-05-26

Family

ID=67539179

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20188159.6A Withdrawn EP3796282A3 (en) 2019-07-29 2020-07-28 Device, system and method for fall detection

Country Status (1)

Country Link
EP (1) EP3796282A3 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023098278A1 (en) * 2021-12-03 2023-06-08 International Business Machines Corporation Initiating communication on mobile device responsive to event

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8179268B2 (en) * 2008-03-10 2012-05-15 Ramot At Tel-Aviv University Ltd. System for automatic fall detection for elderly people
US9049998B2 (en) * 2012-06-22 2015-06-09 Fitbit, Inc. Biometric monitoring device with heart rate measurement activated by a single user-gesture
US10624559B2 (en) * 2017-02-13 2020-04-21 Starkey Laboratories, Inc. Fall prediction system and method of using the same
EP3724864A1 (en) * 2017-09-29 2020-10-21 Koninklijke Philips N.V. Wrist fall detector based on arm direction

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023098278A1 (en) * 2021-12-03 2023-06-08 International Business Machines Corporation Initiating communication on mobile device responsive to event

Also Published As

Publication number Publication date
EP3796282A3 (en) 2021-05-26

Similar Documents

Publication Publication Date Title
US9959732B2 (en) Method and system for fall detection
US10485452B2 (en) Fall detection systems and methods
WO2017049958A1 (en) Paralysis detection and alarming apparatus and processing method thereof
US11047706B2 (en) Pedometer with accelerometer and foot motion distinguishing method
EP3188569B1 (en) Method for detecting fall-off of wearable device, and wearable device
RU2584459C2 (en) Gesture control for monitoring vital body signs
RU2685815C1 (en) Method for responding to detected fall and apparatus for implementing same
KR101638408B1 (en) Wearable motion sensor device for detecting falls, fall detection system, and fall detection method
KR101797854B1 (en) System and method for fall detection using smart band
US20180008191A1 (en) Pain management wearable device
US10332378B2 (en) Determining user risk
JP2002251681A (en) Action detector, action detecting system, abnormal action notification system, game system, prescribed action notification method and center device
EP3144911B1 (en) Enhancing exercise safety
WO2011055255A1 (en) Method and system for revoking a fall alarm field of the invention
WO2019097248A1 (en) Improvements in or relating to fall detectors and fall detection
CN205665839U (en) Wearable intelligent fall detection alarm notice system
Colon et al. Human fall detection with smartphones
EP3796282A2 (en) Device, system and method for fall detection
JP4494843B2 (en) Pet management system
KR101754576B1 (en) Biological signal analysis system and method
Singh et al. Implementation of safety alert system for elderly people using multi-sensors
US20230389880A1 (en) Non-obtrusive gait monitoring methods and systems for reducing risk of falling
US11520410B2 (en) Evaluating movement of a subject
CN111000542B (en) Method and device for realizing body abnormity early warning based on intelligent medicine chest
TWI656502B (en) Method, apparatus and system for portable safety care

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: QOLWARE GMBH

RIC1 Information provided on ipc code assigned before grant

Ipc: G08B 21/04 20060101AFI20210420BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210628

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230621

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20231103