Hub Device Protocol Conversion for IoT Event Data

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current communication systems between electronic devices, such as IoT devices and mobile devices, are limited, with devices typically acting as passive displays or companions, lacking integration and interoperability, which restricts their ability to share and act upon event data effectively.

Innovation Solution

A method where a hub device receives event messages from event devices, converts them into understandable chunks, and transmits these chunks to an action device via a communication protocol, allowing the action device to take appropriate actions based on the event data, even if the devices are remotely located.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a hub device receives and converts event messages from remote event devices to transmit to action devices, then device integration and interoperability are improved, but system complexity increases

Engineering Contradiction:
Improvedevice integrationVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The hub device serves as an intermediary between event devices and action devices. It receives event messages from remote event devices, converts them to the appropriate communication protocol format, and transmits them to action devices. This mediator approach enables integration between devices with different protocols without requiring each device to support multiple protocols directly, thus improving adaptability while managing system complexity through centralized protocol conversion.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The hub device performs multiple functions: receiving event messages from various event devices, converting different message formats to a universal protocol, routing messages to appropriate action devices, and managing communication between heterogeneous devices. This multi-functional design allows a single device to handle diverse communication requirements, improving overall system integration without proportionally increasing complexity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If event messages are divided into multiple chunks for transmission, then data transmission reliability is improved within protocol limits, but transmission time increases

Engineering Contradiction:
Improvedata transmission reliabilityVSAvoidtransmission time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The hub device divides large event messages into multiple smaller chunks that fit within the data value update limits of the communication protocol (e.g., Bluetooth Low Energy packet size constraints). Each chunk is transmitted separately and reliably received by the action device, which then reassembles them into the complete event message. This segmentation ensures reliable transmission of large data sets without exceeding protocol limitations, though it requires multiple transmission cycles.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The hub device performs preliminary actions by pre-dividing the event message into appropriately sized chunks before transmission begins. It also pre-establishes the communication connection and subscribes the action device to receive updates. This preliminary preparation optimizes the transmission process, allowing chunks to be sent efficiently without real-time formatting or connection establishment delays.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If action devices can respond to events from various sources, then user experience customization is improved, but device complexity increases

Engineering Contradiction:
Improveuser experience customizationVSAvoidaction device complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The hub device acts as an intermediary that consolidates event data from multiple sources and presents it to the action device in a unified format. The action device receives pre-processed event messages containing information about different event types (e.g., heart rate, ambient light, media playback state) without needing to implement complex protocols for each event source. This enables rich customization capabilities while keeping the action device relatively simple.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The action device subscribes to event message updates from the hub device and automatically receives relevant event data without needing to actively query multiple sources. The hub device proactively pushes event information to subscribed action devices, allowing them to respond to events with minimal complexity. The action device simply needs to implement response logic for received events rather than managing complex data collection from multiple sources.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3350966B1Communicating event data from an event device to an action device
Publication Date: 2019.12.11 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP3350966B1 patent drawingFigure 1
  • EP3350966B1 patent drawingFigure 2
  • EP3350966B1 patent drawingFigure 3

AI summary

A hub device receives a first event message from an event device that describes an event on the event device. The hub device converts the first event message to a second event message that is understandable to the action device that is communicatively coupled with the hub device through a communication protocol and divides the second event message into multiple chunks, each of which having a size within a data value update limit of the communication protocol. The action device is subscribed to receive updates from the hub device. The hub device transmits each respective one of the chunks over the communication protocol to the action device to allow the action device to take one or more actions in response to the second event message.