Consent Management Platform Synchronization via Flat Database

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing consent management systems face complexity in managing user consent for operational features and services across multiple content-presentation devices, requiring efficient and flexible solutions to ensure synchronization and compliance with varying legal and jurisdictional regulations.

Innovation Solution

A consent management platform in a computing cloud that uses authentication certificates to establish secure connections with content-presentation devices, retrieves device records, and initiates synchronization procedures to ensure consent choices are up-to-date, leveraging a flat database for rapid access and efficient tracking of consent status through device tokens and sequence numbers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional consent management systems are used to manage user consent across multiple devices, then consent tracking capability is provided, but system complexity increases and synchronization efficiency decreases

Engineering Contradiction:
Improvesynchronization efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system segments consent management into device-specific device records stored locally on each content-presentation device and a centralized flat database on the server. Each device record contains device-specific consent choices and a sequence number, allowing independent management and rapid synchronization without complex inter-device dependencies.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The server pre-generates device tokens cryptographically signed with its private key and stores them in the flat database alongside device records. These pre-generated tokens are ready for immediate use when devices check in, eliminating the need for complex authentication negotiations during runtime and improving synchronization efficiency.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If secure authentication protocols are implemented for device verification, then trust relationship is established, but communication overhead increases

Engineering Contradiction:
Improvetrust relationshipVSAvoidcommunication overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The server pre-generates device tokens cryptographically signed with its private key and stores them in the flat database alongside device records. These pre-generated tokens are ready for immediate use when devices check in, eliminating the need for complex authentication negotiations during runtime and improving synchronization efficiency.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The server creates a copy of the device record and sends it to the device during check-in. The device then compares its local device record with the server's copy using sequence numbers. This copying approach avoids complex real-time synchronization protocols while maintaining data consistency and reducing communication overhead.

Inventive Principle:
Principle #26Copying

3Stability of the object's composition

If device records are stored and synchronized across distributed devices and server, then consent data consistency is achieved, but data access speed decreases

Engineering Contradiction:
Improvedata consistencyVSAvoiddata access speed
Core Design Contradiction:
Stability of the object's compositionVSSpeed

Solution Approach 1:

The system segments consent management into device-specific device records stored locally on each content-presentation device and a centralized flat database on the server. Each device record contains device-specific consent choices and a sequence number, allowing independent management and rapid synchronization without complex inter-device dependencies.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The server creates a copy of the device record and sends it to the device during check-in. The device then compares its local device record with the server's copy using sequence numbers. This copying approach avoids complex real-time synchronization protocols while maintaining data consistency and reducing communication overhead.

Inventive Principle:
Principle #26Copying

4Speed

If flat database structure is used for device record storage, then data retrieval speed is improved, but query complexity increases

Engineering Contradiction:
Improvedata retrieval speedVSAvoiddatabase structure complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The flat database structure stores multiple device records in a unified, simplified format without complex relationships or joins. Each record contains all necessary device-specific information including consent choices, sequence numbers, and device identifiers. This universal structure enables rapid retrieval using simple key-based lookups while maintaining data integrity across diverse device types and consent scenarios.

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

Data Source

PatentUS11991296B2Consent management system with check-in and synchronization process
Publication Date: 2024.05.21 UNIVERSAL ELECTRONICS INC
  • US11991296B2 patent drawing
  • US11991296B2 patent drawing
  • US11991296B2 patent drawing

AI summary

A method may include receiving a check-in request at a server of a consent management platform from a content-presentation device. The request may by or include an authentication certificate for establishing a secure communicative connection. A device token cryptographically-signed by the server, a global identifier (GID) unique to the content-presentation device, and a device-based device record may be received over the secure communicative connection. The server may retrieve a server-based device record for the device from a flat database using the GID as an index key, and then compare a device-based sequence number in the device-based device record with a server-based sequence number in the server-based device record. If the sequence numbers match, the server may send a check-in complete message to the content-presentation. If the sequence numbers do not match, the server may initiate a synchronization procedure with the content-presentation device.