Server-Based Auxiliary Account Management for Smart Devices
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for controlling smart devices are inefficient as they allow only one account associated with the device to control it, requiring frequent release and re-association for multiple users to access and control the device.
Innovation Solution
A method where a server manages control relationships by allowing additional accounts to be recorded as auxiliary control accounts, enabling them to control the device without needing to release the primary account, through a device association request and acknowledgement process.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If only one account is associated with a smart device for control, then the device security and ownership are protected, but the efficiency of device management deteriorates when multiple users need access
Solution Approach 1:
The control account system is segmented into two distinct roles: primary control account and auxiliary control account. This segmentation allows the device to be controlled by multiple accounts simultaneously without confusion, as each account type has clearly defined permissions and responsibilities. The primary account maintains full control while auxiliary accounts have granted permissions, resolving the contradiction by enabling efficient multi-user management while maintaining clear ownership structure.
Solution Approach 2:
The server is designed to universally manage multiple control relationships for a single device. Instead of limiting control to one account, the server infrastructure supports multiple auxiliary control accounts being associated with the same device simultaneously. This multi-functionality enables the system to handle diverse user access scenarios (family members, guests, colleagues) without requiring separate devices or complex workarounds, thus improving device management efficiency.
2Ease of operation
If the primary account is released to allow other users to control the device, then multiple users can access the device, but the time and operations required for release and re-association increase
Solution Approach 1:
The system performs preliminary actions by establishing auxiliary control account associations in advance. Instead of releasing and re-associating accounts when users need access, the auxiliary control relationships are pre-configured through the server. When a user needs to control the device, they simply use their pre-associated auxiliary account without any release or re-association operations, eliminating time loss and simplifying the access process.
Solution Approach 2:
The server acts as an intermediary that manages control relationships between the device and multiple accounts. Instead of direct account-device binding that requires release and re-association, the server mediates control requests from both primary and auxiliary accounts. This intermediary layer enables seamless account switching and access management, making device control easy while eliminating the time-consuming release and re-association operations.
3Adaptability or versatility
If multiple accounts are allowed to control a device simultaneously, then user accessibility is improved, but the complexity of managing control relationships increases
Solution Approach 1:
The control relationship structure uses asymmetry by clearly differentiating between primary control accounts and auxiliary control accounts. The primary account has asymmetric full control rights, while auxiliary accounts have asymmetric granted permissions. This asymmetric design simplifies management by establishing clear hierarchies and permission levels, preventing the complexity that would arise from symmetric equal-access models. The server efficiently manages this asymmetric relationship structure without increasing operational complexity.
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
A method for managing control relationships between an account and a device includes: receiving (101) a device association request sent from a first terminal, the device association request carrying a device identifier of a target device broadcasted from the target device and a first account identifier corresponding to an account logged in at the first terminal; determining (102) a second account identifier corresponding to a primary control account associated with the target device; transmitting (103) a association inquiry message to a second terminal where an account corresponding to the second account identifier is logged in, the association inquiry message carrying the first account identifier and the device identifier; and recording (104) the account corresponding to the first account identifier as an auxiliary control account of the target device if a first acknowledgement message corresponding to the association inquiry message is received from the second terminal.