Shared Playlist Synchronization via Ordered Change Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems for synchronizing shared lists across multiple devices often face conflicts due to differing edit operations, leading to loss of older versions and disruptions in the ordering of items, particularly in media playlists.

Innovation Solution

A synchronization service computing machine processes change operations in a specific order, prioritizing delete operations, followed by add operations, and then re-order operations, while maintaining changes from multiple devices, ensuring the final playlist aligns with user expectations and respects the ordering of items.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If only the most recently received edits are maintained, then the synchronization process is simple, but older versions of edits from different devices are discarded causing loss of information

Engineering Contradiction:
Improvesynchronization process complexityVSAvoidloss of older edit versions
Core Design Contradiction:
Device complexityVSLoss of information

Solution Approach 1:

The patent segments change operations into distinct categories (add, delete, re-order) and processes them in a specific sequence. By dividing the complex synchronization problem into manageable segments, the system can maintain simplicity while preserving all edit versions through structured processing of each segment type in order.

Inventive Principle:
Principle #1Segmentation

2Productivity

If change operations are processed in a fixed order, then the processing is efficient, but the ordering of items in the shared list may be disrupted

Engineering Contradiction:
Improvechange operation processing efficiencyVSAvoiditem ordering stability
Core Design Contradiction:
ProductivityVSStability of the object's composition

Solution Approach 1:

The patent applies preliminary action by processing delete operations before add operations, and add operations before re-order operations. This predetermined sequence prevents ordering disruptions by establishing a stable foundation first (deleting items), then building upon it (adding items), and finally adjusting positions (re-ordering), thus maintaining efficiency while preserving stability.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If all change operations are applied to the current version, then the shared list is updated completely, but conflicts between simultaneous edits from multiple devices occur

Engineering Contradiction:
Improveshared list update completenessVSAvoidconflict resolution information loss
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The patent segments change operations into distinct types (add, delete, re-order) and processes them in a predetermined sequence. This segmentation allows the system to apply changes systematically without conflicts, as each segment type is processed in a specific order that prevents simultaneous edit conflicts while maintaining complete updates.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies preliminary action by processing delete operations before add operations. This sequence ensures that deletions are applied to the current version first, establishing a clean state, and then additions are made. This prevents conflicts by ensuring that no two add operations compete for the same position, while still applying all changes completely.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9367883B2Shared playlist synchronization
Publication Date: 2016.06.14 MICROSOFT TECHNOLOGY LICENSING LLC
  • US9367883B2 patent drawing
  • US9367883B2 patent drawing
  • US9367883B2 patent drawing

AI summary

Various embodiments relating to synchronizing changes to a shared list of items between different devices are provided. In one embodiment, a first set of change operations for a first version of a shared list may be received from a first device. The first set of change operations may be performed on the first version of the shared list to produce a second version of the shared list. A second set of change operations for the first version of the shared list may be received from a second device. The second set of change operations may be performed on the second version of the shared list to produce a third version of the shared list that maintains changes that are made by the first set of change operations but that are not made by the second set of change operations.