Collaborative Document Forking for Private Real-Time Edits
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing collaborative software applications struggle to efficiently manage synchronous and asynchronous changes in a collaborative document environment, particularly in real-time scenarios where private edits are made without disrupting the shared document state.
Innovation Solution
Implementing groupware features that support asynchronous collaboration within a synchronous collaboration environment by creating user-specific forks in the change list to store private changes, suppressing their broadcast, and allowing for controlled sharing and reconciliation of these changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If private changes are made in a synchronous collaboration environment, then user-specific editing flexibility is improved, but system complexity and resource requirements increase due to managing multiple change lists
Solution Approach 1:
The system segments the change list management by creating user-specific forks that isolate private changes from the main collaborative change list. Each user's private edits are contained in their own fork, preventing interference with other users' work while maintaining the ability to integrate changes when needed.
Solution Approach 2:
The patent implements temporary, disposable fork structures that can be created and discarded as needed for private editing sessions. These forks are not permanent system components but transient objects that exist only for the duration of private editing, reducing long-term system complexity.
2Stability of the object's composition
If private changes are broadcast to all collaborators, then document consistency is improved, but conflicts and interruptions in synchronous collaboration increase
Solution Approach 1:
The system extracts private changes from the main collaborative document flow by placing them in separate user-specific forks. This extraction prevents private changes from being automatically broadcast to all collaborators, eliminating the source of potential conflicts while maintaining the option to selectively integrate changes later.
Solution Approach 2:
The fork structure acts as an intermediary between private user edits and the main collaborative document. It mediates the integration process by providing a controlled mechanism for selecting and merging private changes, preventing direct interference with the main document state and other users' work.
3Reliability
If all changes are tracked in a single change list, then document integrity is maintained, but resource requirements and processing overhead increase
Solution Approach 1:
The system segments the change tracking infrastructure into multiple isolated change lists (one main list and multiple user-specific forks). This segmentation reduces the amount of data each user's changes need to process, as private changes only need to be tracked in their respective forks rather than in a single large centralized list.
Solution Approach 2:
The patent implements partial tracking by only maintaining full change list integrity for the main collaborative document, while using simplified, isolated tracking for private forks. This partial approach reduces overall processing overhead while maintaining sufficient document integrity for collaborative work.
Data Source
Figure 1A
Figure 1B~1C
Figure 2
AI summary
Groupware features are described that support asynchronous collaboration for a synchronous collaboration environment. During a synchronous collaboration session, a document is displayed at a user's computing device. As changes to the document are received at the user's computing device, a change list is updated and the modified document is displayed. Any changes from the user are broadcast to other participants. For asynchronous collaboration during the session, a user-specific fork is created in the change list to contain private changes for the user. For each private change from the user, the groupware updates the change list in the user-specific fork with the private change, which is not broadcast to the other participants for reconciliation.