Smart Lock Status Broadcasts for Faster, Lower-Power Retrieval

Solution Overview

Problem

Existing smart locks require frequent status requests from a receiver device, leading to prolonged connection times, reduced availability for digital operations, ambiguity in event timelines, and excessive battery power consumption due to unnecessary processing demands.

Innovation Solution

A smart lock that transmits its status independently of a receiver device, using a processor to encode the lock mechanism's status and timestamp into an information packet, which is broadcast wirelessly or via a wired connection, reducing the need for connection procedures and processing power.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the hub connects to the smart lock to request status, then the status can be retrieved, but the connection time is prolonged (up to five seconds) and the lock is unavailable for other operations

Engineering Contradiction:

Improvestatus retrievalVSAvoidconnection time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The smart lock proactively transmits status information before the hub requests it. The processor continuously monitors lock status and automatically sends updates to the hub, eliminating the need for the hub to initiate a time-consuming connection to retrieve status information.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

Instead of the hub initiating a connection to request status (traditional approach), the smart lock inverts the communication pattern by automatically pushing status updates to the hub. This reverses the active/passive roles and eliminates connection delays.

Inventive Principle:

Principle #13The other way round (Inversion)

2Reliability

If the hub connects to the smart lock to request status, then the status can be retrieved, but the availability for digital operations is reduced

Engineering Contradiction:

Improvestatus retrievalVSAvoidavailability for operations

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The smart lock proactively transmits status information before the hub requests it. The processor continuously monitors lock status and automatically sends updates to the hub, eliminating the need for the hub to initiate a time-consuming connection to retrieve status information.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The smart lock serves itself by automatically generating and transmitting status updates without requiring the hub to initiate connections. This self-service approach ensures continuous availability for user operations while maintaining accurate status reporting.

Inventive Principle:

Principle #25Self-service

3Reliability

If the hub is delayed in connecting to the smart lock, then the connection may eventually succeed, but multiple status requests are made and battery power is consumed

Engineering Contradiction:

Improvestatus retrievalVSAvoidbattery power consumption

Core Design Contradiction:

ReliabilityVSUse of energy by moving object

Solution Approach 1:

The smart lock proactively transmits status information before the hub requests it. The processor continuously monitors lock status and automatically sends updates to the hub, eliminating the need for the hub to initiate a time-consuming connection to retrieve status information.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The smart lock transmits status updates periodically or on-event basis, rather than responding to repeated hub connection attempts. This periodic self-service transmission model reduces unnecessary processing and battery consumption while ensuring the hub receives current status information.

Inventive Principle:

Principle #19Periodic action

Data Source

PatentUS20250299520A1Smart lock and method of transmitting a status of a smart lock

Publication Date: 2025.09.25 GLUE AB

AI summary

A smart lock is provided comprising: a drive train for actuating a lock mechanism between an unlocked position and a locked position; an electric actuator arranged to drive the drive train to actuate the lock mechanism; a manual actuator arranged to drive the drive train to actuate the lock mechanism; a sensor arranged to output a signal indicative of a status of the lock mechanism, the status representing whether the lock mechanism is in the unlocked position or the locked position; and a processor. The processor is configured to: receive the signal; encode the status and a timestamp into an information packet; and transmit the information packet independent of the presence of a receiver device.