Transaction Query Engine Token Consolidation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed architectures, synchronizing changes between a server and multiple clients, especially when handling changes made by multiple users to shared folders, is complex and inefficient, leading to increased client complexity and resource usage due to the need for multiple requests and transaction logs.

Innovation Solution

A server manages both private and shared file systems, creating a single token with transaction information for each, which is sent to clients, allowing them to request and receive a unified transaction log, reducing client complexity by presenting a single log and optimizing resource usage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the server sends separate transaction logs for private and shared file systems, then the client can track changes accurately, but the client complexity and resource usage increase

Engineering Contradiction:
Improvedata consistencyVSAvoidclient complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent merges separate transaction logs for private and shared file systems into a single unified transaction log. The server consolidates transaction information from both file systems and sends it as one combined log to the client, reducing the number of separate synchronization operations the client must handle while maintaining complete tracking of all changes.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The unified transaction log serves multiple functions simultaneously: it tracks changes in both private and shared file systems, provides a single synchronization reference point, and enables the client to synchronize multiple file systems using one standardized interface rather than requiring different handling mechanisms for each file system type.

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

2Loss of information

If the client handles multiple transaction logs separately, then all file system changes are tracked, but the number of client requests and resource usage increase

Engineering Contradiction:
Improvetransaction tracking completenessVSAvoidsynchronization efficiency
Core Design Contradiction:
Loss of informationVSProductivity

Solution Approach 1:

The server combines multiple transaction logs into a single unified log that contains all transaction information from both private and shared file systems. This consolidation reduces the number of separate client requests needed from multiple individual log fetches to a single unified log retrieval operation.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The server performs preliminary consolidation of transaction logs before sending them to the client. By pre-aggregating all transaction information into one unified log on the server side, the system eliminates the need for the client to perform multiple separate retrieval operations, thereby improving synchronization efficiency.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If separate synchronization mechanisms are used for private and shared file systems, then each file system can be synchronized independently, but the overall synchronization process becomes more complex

Engineering Contradiction:
Improvefile system independenceVSAvoidsynchronization mechanism complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The unified transaction log mechanism provides a universal synchronization interface that works for both private and shared file systems. The client uses the same synchronization logic and process for both file system types, eliminating the need for separate synchronization mechanisms while maintaining the ability to handle different file system types appropriately.

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

Solution Approach 2:

Instead of having the client implement separate synchronization logic for different file systems, the patent inverts the approach by having the server consolidate all file system transaction information into a single unified log. This shifts the complexity management from the client side to the server side, simplifying the client's synchronization mechanism.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentEP3044682B1Transaction query engine
Publication Date: 2020.04.01 HITACHI VANTARA LLC
  • EP3044682B1 patent drawingFigure 1
  • EP3044682B1 patent drawingFigure 2A
  • EP3044682B1 patent drawingFigure 2B

AI summary

Example implementations described herein are directed to a transaction query engine involving a token that is generated by the server and sent to the corresponding the client. The client uses the token to query transactions made on the server. The token can include mount point information detailing shared and private information of the file systems, transaction identifiers identifying transactions of a file system, and a file system identifier to identify the corresponding file system. The server processes this token and updates the token based on the transaction information of the file system, and sends the token back to the corresponding client.