System for automated carry-on verification of portable items with BLE-ExitGuard, GATT profile control and time-controlled server heartbeat
The system addresses delays and unreliability in existing Bluetooth trackers by using a time-controlled server heartbeat and adjustable beacon profiles to ensure rapid and reliable detection of item departure with minimal energy consumption and reduced false alarms, maintaining app functionality.
Patent Information
- Application Number
- DE202025003031
- Authority / Receiving Office
- DE · DE
- Patent Type
- Utility models
- Current Assignee / Owner
- Filing Date
- 2025-10-10
- Publication Date
- 2026-01-08
- Estimated Expiration
- 2035-10-31
AI Technical Summary
Commercially available Bluetooth trackers like Apple AirTag, Samsung SmartTag, and Tile experience delays and unreliable detection of abandoned items due to periodic scans, connection interruptions, and inconsistent platform behavior, leading to delayed or missed alarms, especially when the app is terminated or deactivated.
A system with a time-controlled server heartbeat ensures the app remains operational, uses a dynamically defined geofence near the home, and employs BLE beacons with adjustable transmission profiles (Home, Transit, Stay) to minimize energy consumption and delay in detecting item departure, utilizing GATT commands for profile control and a hysteresis logic to classify locations as 'stay' or 'transit', and extends the wake time window for reliable detection.
Ensures rapid and reliable detection of item departure with minimal energy consumption, reduces false alarms, and maintains functionality even if the app is deactivated, providing immediate feedback and cost-effective implementation with low-power beacons.
Abstract
Description
1. Technical field
[0001] The invention relates to a system for the automated carry-on inspection of portable items with BLE-ExitGuard, GATT profile control and a time-controlled server heartbeat based on user-defined activation periods.
[0002] The invention is particularly suitable for reminding people to carry critical everyday items, such as emergency medical medications (e.g., inhaler, adrenaline auto-injector, insulin pen), as well as keys, wallet, work equipment and similar everyday items. 2. State of the art
[0003] Bluetooth trackers like Apple AirTag, Samsung SmartTag, or Tile periodically send short advertising signals (advertising packets) via Bluetooth Low Energy (BLE). The corresponding smartphone applications scan for these radio signals, mostly in the background. Once a tracker is paired with a smartphone, the operating system stores the tracker's unique identifier (ID).
[0004] Popular systems for remembering forgotten items, such as Apple's "Notify When Left Behind" feature, continuously monitor whether the user's location has changed and whether a registered tracker moves out of range. Apple describes this as follows: "You'll receive an alert every time the device sharing your location becomes separated from the item." Samsung works on a similar principle: The alarm is triggered as soon as the Bluetooth connection to the SmartTag is lost and the device is therefore "far enough away."
[0005] In practice, this means that the smartphone primarily reacts to the absence of the BLE signal. Since the range of BLE is typically around 80-100 m (even more under favorable conditions), the notification often only occurs when the user has already moved approximately 100-200 m away from the object. User reports confirm this delay.
[0006] The operating systems utilize deep OS integrations that allow apps to be briefly activated in the background by system-based triggers ("wake events"). During these short activation windows, the apps perform both a location query and a Bluetooth Low Energy (BLE) scan. If a signal from the tracker is detected, the item is considered to be carried. If no signal is received, it can only be reliably determined that the item is missing after several repeated wake phases. Since many trackers operate with extended transmission intervals in standby mode, the probability increases that a signal will not be detected during individual wake phases. Only by correlating several consecutive wake phases in combination with location changes can the app confirm that the item is "not carried." In practice, this regularly leads to delays of several minutes between the item actually being left behind and the alarm being triggered.This makes it more difficult to return to the forgotten item in time. Trigger conditions (Geofencing / Significant Location Chance)
[0007] Manufacturers compared • Apple AirTag / Find My AirTags, like all trackers, use a constant base interval, but extend this interval in standby mode to conserve battery power. This is achieved through an integrated motion sensor in the tag. When the tag is moved, it transmits more frequently. This makes detection more dynamic and reliable in everyday life. The app is activated in short bursts, for example, by leaving a defined zone. • Samsung SmartTag / SmartThings find SmartTags essentially operate at fixed intervals. Here too, the following applies: if the connection is lost and the smartphone leaves a predefined safe-place zone, a warning is issued. The logic is essentially push-based – the phone detects that it can no longer reach the tag and then triggers the alarm. • Tile Smart Alerts Tile relies more heavily on geofencing. If the smartphone leaves a defined location (e.g., home) for several minutes, the app checks whether a saved Tile is still within range. If the signal is missing, a push notification is sent. Delays and typical problems
[0008] In practice, all manufacturers experience delays between actual loss and alarm activation. This is due to the tension between energy consumption and reliability. • Trackers do not transmit continuously, but at intervals to extend battery life. • Smartphones also do not scan continuously, but in short windows. • Different platform restrictions (iOS / Android) mean that detection and alerting can be very inconsistent depending on the device. • If the app is manually terminated by the user (“Force Quit”) or deactivated by the operating system for energy saving reasons, many systems no longer function in everyday use - without the user noticing.
[0009] To avoid false alarms, the systems analyze location changes and multiple missed signals together. This often results in a warning being triggered with a slight delay—sometimes only after several meters or minutes. Apple partially mitigates this problem with its motion sensor, but also consciously accepts this drawback: better to warn a little later but with greater certainty. 3. Object of the invention
[0010] Commercially available Bluetooth Low Energy trackers (e.g., Apple AirTag, Samsung SmartTag, Tile) typically detect abandoned items through periodic scans, connection interruptions, or location-based geofence triggers. This approach leads to noticeable delays and sometimes unreliable results. For example, Tile's "Smart Alerts" typically only notifies the user about 5-10 minutes after leaving a defined area. Such time-consuming processes can result in an abandoned item being detected too late or not at all.
[0011] At the same time, rigid triggering mechanisms (e.g., automatically generated large geofences or simple location changes) carry the risk of delayed alarms when leaving the home. They also do not protect against the risk of an app being inadvertently deactivated or terminated during everyday use, thus rendering the security function completely ineffective.
[0012] Against this background, the object of the invention is to provide a system for the detection of abandoned objects that • Detects the departure of an object with minimal delay, • Avoids false alarms in everyday life, • ensures economical energy consumption, and • additionally ensures that the application remains reliably functional through a time-controlled operational check, even if it has been terminated unnoticed by the user or the operating system. 4. Solution to the task
[0013] According to the invention, the system first ensures that the application itself remains reliably operational. To this end, it includes a time-controlled server heartbeat, during which the user can define specific activation periods (e.g., days of the week and times). At these times, a server checks whether the mobile application is active in the background. If it detects that the app has been terminated or deactivated, the server triggers a fallback notification so that the user can reopen the application in time. This prevents the protective function from being deactivated unnoticed.
[0014] Furthermore, the system is designed to initially establish a BLE tracker with a transmission range of 1-2 meters. This ensures maximum energy savings while simultaneously guaranteeing the reliability of identifying the item when carried on the body. Unlike automatic or general geofencing zones, this system utilizes a dynamically and individually defined geofence in front of the home address. This geofence extends from the front door, defining the "home exit zone." Upon entering this geofence, the operating system generates an entry event, passively waking the application (app) from sleep mode. Immediately following this entry event, the app performs a brief BLE scan—a presence check—to determine if the beacon associated with the item is within range.
[0015] If the beacon is detected, the item is considered "present," and the app briefly connects to the beacon via Bluetooth Low Energy (BLE). In this case, the app switches the beacon to the transit profile to ensure energy-efficient detection at the next destination. This guarantees that at least one beacon packet is received within the typically short wake-up window of the mobile device. If the beacon is not found upon entry, the system interprets this as the item not being taken (the item is lost).
[0016] To control the beacon profiles, the app manages predefined transmission profiles: Home, Transit, and Stay. These differ in their BLE advertising intervals (for example, approximately 2 seconds, 2.5 seconds, and 5 seconds). The Home profile with the short interval (~2 seconds) is primarily used in the vicinity of the home to directly detect a signal within the short wake interval. The Transit profile (~2.5 seconds) is used in the context of movement ("on the go") and offers a compromise between energy conservation and detection reliability. The Stay profile with a long interval (~5 seconds) is used at locations identified as places where the user is staying to conserve battery power. The app uses a GATT command to selectively activate the profile that corresponds to the current user behavior after detecting a change in context.
[0017] The system identifies permanent locations (stay places) based on a hysteresis logic with a minimum dwell time requirement. A location is only considered a permanent location ("stay") if the user remains there continuously for a predetermined minimum duration (preferably around 40-50 minutes). Shorter stays remain in transit status. This hysteresis prevents frequent profile switching (fluttering) and reduces false alarms – for example, during short stops (fueling or errands) that fall below the threshold. Only after several longer stays at the same location (e.g., multiple visits per week of 40-50 minutes each) is a location definitively classified as a stay place.
[0018] When leaving a location classified as "Stay," the ExitGuard mechanism is also activated. The app knows that the beacon is transmitting in the Stay profile (with a long interval). It therefore specifically extends the active wake time window provided by the operating system (typically by a few seconds, e.g., to -5-8 seconds). This ensures that at least one BLE signal from the beacon is detected, despite the slow advertising interval.
[0019] The ExitGuard extension thus compensates for the long interval of the beacon and enables reliable presence detection even with very short OS wake windows.
[0020] If an exit event occurs: If no beacon signal is received, the app assumes the item has been forgotten and immediately triggers an alarm (e.g., vibration and a "Forgotten Item" warning message on the device). If, however, a signal is detected, the item is considered to be carried – no alarm is triggered. In this case, the app switches the beacon via GATT to the profile appropriate for the new context.
[0021] As a fallback trigger at home, other operating system events serve as alerts if a geofence entry event is unavailable. Specifically, a Wi-Fi connection loss or reconnection, as well as a significant location change event, can be used as a wake-up signal for the app. As soon as such a secondary event occurs, the app also promptly performs a short BLE scan to carry out profile control and presence verification as described. 5. System Overview
[0022] The system consists of a mobile application on a device (e.g., a smartphone) and at least one configurable BLE tag. The application is activated exclusively by operating system-based triggers (e.g., geofence entry and exit, SLC (Significant Location Change), Wi-Fi signal strength, or activity changes). After activation, the application performs a brief BLE scan to check for the presence of the BLE tag.
[0023] The BLE tag serves as a low-power beacon and is not self-contained. It features a configurable advertising interval and adjustable transmission power. To minimize energy consumption, the transmission power is significantly reduced, limiting the effective range to 1-2 meters.
[0024] The mobile application defines operating profiles for the BLE tag (Home, Transit, Stay). Depending on the user context, the application uses GATT commands to control the currently active profile of the BLE tag. These profiles define parameters such as the advertising interval and the beacon's transmission power.
[0025] The distance to the BLE tag is not determined via RSSI values. Instead, the system simply checks whether a beacon signal has been received or not. The results of the brief BLE scan are then passed to the application, which makes the subsequent decisions.
[0026] All decision-making processes, including the evaluation of dwell times, profile switching, and alerts, are carried out exclusively within the mobile application. The mobile application continuously assesses the device's dwell time within the monitored area and, based on this, controls the activation of new profiles or the triggering of an alert. No external processing of the data outside the application takes place. 6. Operating modes / transmission profiles
[0027] In a preferred embodiment, the system combines two types of operational control: 1. Time-based activation periods: The user can define on which days and times the application is active. The app only reacts to operating system triggers (e.g., geofencing, SLC, Wi-Fi) and performs the heartbeat check during these time windows. On inactive days or outside of these time periods, the app remains passive, thus saving energy and avoiding unnecessary notifications. 2. BLE tag transmission profiles: Within active time periods, three advertising profile operating modes are defined for the beacon, each of which is permanently active (until a profile change): • Home: A short advertising interval ensures that at least one advertising packet from the beacon is received within the typically short wake time window of the operating system (e.g., when leaving home). • Transit: Advertising interval of approximately 2.5 seconds, suitable for movement. It represents a compromise between energy saving and detection reliability – slower than Home, faster than Stay. This ensures that, for example, a signal is usually detected during Significant Location Change events, even without ExitGuard. • Stay: Advertising interval of approximately 5 seconds for longer stays. The beacon saves energy here because it transmits less frequently. When leaving, the app compensates for the longer interval with ExitGuard by extending the wake-up time window.
[0028] The values mentioned (2 s / 2.5 s / 5 s) are preferred guidelines. Deviations are possible as long as the technical effect – a reliable, fast presence check with minimal energy consumption – is maintained. 7. Sample processes
[0029] Before each scenario, the system also includes a time-controlled activation logic: The user defines on which days and at what times the application is active. Only during these defined time windows does a server heartbeat check whether the app is still running in the background. If it detects that the application has been deactivated, the server triggers a fallback notification. If the app is active, it reacts to operating system triggers (e.g., geofence entry, significant location change, Wi-Fi events) within these time periods and controls the processes described below. Outside of the active time periods, the system remains passive, thus saving energy and avoiding unnecessary notifications. 7.1 Leaving his home Example: The user leaves his home OS event (geofence entry)
[0030] Upon entering the defined zone, which is specifically placed a few meters in front of the apartment / house door, the operating system wakes up the app. The application immediately starts a BLE scan for the beacon. 1. Scan: The app scans for the beacon for a short time (typically 5 to 8 seconds). If the beacon, with its short range, is located on the body, at least one advertising signal will be received during this period. Since the beacon transmits in its home profile, it is operating at its fastest transmission frequency. 2. In-person exam: If no signal is received from the beacon, the system assumes that the item is not being carried. An alarm is immediately triggered, e.g., by vibration and the display of the warning message "Forgotten item" on the smartphone. • If a signal is detected, the beacon is still in close proximity – the object is considered “present”. In this case, no alarm is triggered. 3. Profile Switching and Sleep Mode: If the presence check determines that the item is being carried, the app adjusts the beacon profile to the new situation. For example, a beacon that was previously in the Home or Stay profile is now switched to the Transit profile via a GATT command, since the user is now on the move. The application then returns to sleep mode until the next relevant event occurs. If the beacon is not found and an alarm is triggered, the app attempts to notify the user as quickly as possible. 7.2 Arrival at a location (stay event)
[0031] Example: The user arrives at a new location (e.g., an office or a frequently visited place).
[0032] Upon entering the zone (e.g., detection of a visit "arrival" event by the OS), the application briefly activates and performs a BLE scan. If it detects the beacon, it connects and switches the beacon to the Stay profile (approximately every 5 seconds) via GATT, as it is assumed that the user will remain at this location for a while. The location is then marked as a Stay candidate. Only if the user actually stays at this location for an extended period is the location definitively classified as a Stay location. Otherwise (a short visit below the threshold), the location is not classified as a permanent residence.
[0033] Note: If the beacon cannot be found upon arrival at a location (i.e., the user arrives without the item), this may mean that the item was left behind. In this case, the app will display a notification during the "Arrival" event indicating that the item is missing. 7.3 Short stopover (transit remains active)
[0034] Example: The user only stops briefly (less than 40 minutes) during a journey or on the way.
[0035] Such short stops remain in transit mode within the system. The application avoids unnecessary profile changes and checks during very brief stays. In practice, this means that if the user stays at a location for less than the minimum duration, that location is not recognized as a permanent "stay." The app remains in transit profile (the beacon continues to transmit at the transit interval), and no additional carry checks or alarms are triggered, as it is assumed that the user will not lose the item from close range during this brief moment. 7.4 Return to home (Home-Enter) Example: The user returns home.
[0036] Optionally, a brief check can also be performed upon returning to the home area. If the operating system detects a geofence entry (entering the home zone), the application can perform a short BLE scan. If the beacon is found, the app may switch the beacon back to the home profile (approximately every 2 seconds). This ensures that the highest transmission frequency is used the next time the home area is left, guaranteeing a rapid alarm in critical situations (forgetting an item at home). If the beacon is not detected upon returning home, this means the user has returned without the item – in this case, however, an alarm would have already been generated earlier (when leaving the location where the item was left). 8. Advantages of the invention • Reliability even when the app is deactivated: The integration of a time-controlled server heartbeat ensures that the application remains reliably available even if it is manually closed by the user or shut down by the operating system in the background. In these cases, the user receives • a fallback notification, ensuring that the protection function is maintained at all times. • Lem / hysteresis logic: The system only recognizes permanent locations after a minimum dwell time has been exceeded, thus avoiding unnecessary switching between profiles ("fluttering") and reducing false alarms. • Transmit power (TX power): The beacon's TX power should preferably be set low, especially indoors. This forces a short-range test – the beacon signal can only be received reliably within a few meters (1-2 meters). Reduced transmit power decreases false alarms, as distant or almost forgotten objects are no longer detected, and also saves energy. • Fast, deterministic response: The decision as to whether an item is carried is made within seconds, precisely at the moment relevant to the user – namely, when leaving a location or during similar context changes. Compared to conventional systems, which often only trigger an alarm after minutes, the invention offers immediate feedback and allows the user to quickly turn back. • High energy efficiency: The system operates without continuous scanning or constantly high-frequency beacon signals. The beacon's BLE advertising intervals are fast during normal operation and are only adjusted as needed based on events. The application is only passively active in the background for short periods when absolutely necessary. • Low false alarm rate: By combining location hysteresis (minimum stay duration for locations) and deliberately limiting the beacon range (low TX power), false alarms are significantly reduced. The system is robust against inaccurate GPS data or short-term location deviations and ignores irrelevant short stops, resulting in more reliable alarm logic. • Simple hardware: A cost-effective, connectable "dumb" BLE beacon without its own intelligence is sufficient for implementation. All sophisticated functions—from location tracking to profile control—are handled by the app software. This simplifies manufacturing and maintenance (the beacon firmware remains simple) and reduces costs, as no additional sensors (e.g., motion sensors) are required in the beacon. • ExitGuard time window: By specifically extending the operating system wake time window when leaving a stay location, reliable detection is ensured despite long advertising intervals. Industrial applicability
[0037] The invention can be implemented directly using commercially available components and manufactured in large quantities. Obvious applications lie in the consumer sector (e.g., medication reminders for keys and wallets), but it can also be applied to professional scenarios. The robust, energy-efficient, and scalable architecture enables diverse use wherever the carrying of critical items needs to be monitored.
Claims
[1] System for automated carry-on screening of portable items, characterized by : a) a time-controlled activation with server heartbeat, where user-defined activation periods (days and times) are set, during which the server checks whether the mobile application is active in the background and triggers a fallback notification in case of deactivation, b) wherein the application provides a dynamically configurable geofence whose geozone is defined such that its area lies directly in front of the apartment door, so that when the user leaves the apartment, they first enter the geozone and thereby trigger an activation signal, c) a mobile application on an end device that is activated in particular by operating system events, selected from: - Geofence entry or exit, - Significant location change, - WLAN reconnect or disconnect, - User activity change, d) at least one Bluetooth Low Energy (BLE) tag that transmits a unique identifier, e) where the transmission power of the BLE tag is reduced, so that the effective range is limited to a maximum of 2 meters, f) wherein, upon the occurrence of an operating system event, the application performs a quick scan to check for the presence of the BLE tag, (g) wherein the application switches the BLE tag between at least three predefined profiles via GATT commands, comprising: - Home profile with short advertising interval, - Transit profile with medium advertising interval, - Stay profile with long advertising interval, h) and wherein, upon exiting a geozone from a “Stay” area (high transmit interval of the tracker for energy saving), an extra ExitGuard mechanism is activated, which extends the operating system wake time window contextually, so that at least one beacon signal is received even during long advertising intervals. i) wherein, on each activation event triggered by an operating system event, the application evaluates the quality of the terminal's position determination to distinguish between typical indoor GPS drift and actual outdoor movement, the evaluation being based on one or more of the following parameters: - current GPS accuracy (horizontal accuracy), - Number of satellites received, - Signal-to-noise ratio of the position signals, - Stability of the position fix over a short-term interval, - optionally supplementary inertial sensor data such as step start or acceleration pattern, whereby the BLE short scan is only activated in situations classified as "outdoor", while no BLE scan is performed in drift situations recognized as "indoor". j) wherein the application is activated from the passive background state exclusively by geofencing events of the operating system and does not perform continuous location queries, but specifically uses the natural GPS drift occurring indoors to be repeatedly woken up by sporadic geofencing triggers, wherein the application evaluates the current quality of the position determination (GPS accuracy, number of satellites, SNR, stability of the fix) at each of these triggers to distinguish whether the user is still indoors or is already outdoors, and wherein a BLE short scan is only started if an outdoor location is detected based on the position quality parameters. [2] System according to claim 1, characterized by, that the user-defined activation periods can be set in the form of recurring weekly schedules (e.g. Monday-Friday) or freely selectable individual days with times. [3] System according to any one of the preceding claims, characterized by , that the server heartbeat, upon reaching an activation time, checks whether a sign of life from the application has been received within a defined time window, and in case of absence, triggers a visible notification on the end device. [4] System according to any one of the preceding claims, characterized by , that the dynamically configurable geofence is set so that its outer edge lies directly within the area of a physical access point (e.g. apartment door) and an activation signal is generated immediately upon first leaving the interior area. [5] System according to any one of the preceding claims, characterized by, that the application automatically performs a BLE short scan when an activation signal is triggered, in order to determine the presence of the BLE tag assigned to the object. [6] System according to any one of the preceding claims, characterized by , that the application triggers an alarm in the form of vibration, acoustic signal or screen notification in the event of an unrecognized BLE tag. [7] System according to any one of the preceding claims, characterized by , that the application switches the BLE tag between a home profile, a transit profile and a stay profile via GATT commands, with each profile defining different advertising intervals and transmission powers. [8] System according to any one of the preceding claims, characterized by, that when leaving a location classified as Stay, an ExitGuard mechanism is activated, which extends the wake time window provided by the operating system in order to receive at least one beacon signal despite long advertising intervals. [9] System according to any one of the preceding claims, characterized by , that in addition to the geofence event, WLAN reconnect, WLAN disconnect or significant location change are also used as fallback triggers. [10] System according to claim 1, characterized by , that the distance to the BLE tag is not determined by RSSI values, but solely by receiving or not receiving a beacon signal. [11] System according to any one of the preceding claims, characterized by , that permanent places of residence (stay places) are identified by a hysteresis logic, in which a place is only classified as a stay place after a minimum period of residence. [12] System according to any one of the preceding claims, characterized by , that the transmission power of the BLE tag is set so that the effective reception range is limited to a narrow reception area (of 1 to 2 meters), so that the beacon can only be received in the immediate vicinity.