Offline Client Replay and Sync for Intermittent Connectivity

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Networked software applications face challenges in handling intermittent network connectivity, leading to loss of data and functionality when field service workers experience network disconnection and reconnection, as conventional caching methods are insufficient for maintaining operational efficiency.

Innovation Solution

A method that determines when a networked software application is offline and online, intercepts and stores request messages, and replays them in a synchronized order upon reconnection, using a JavaScript Extension Toolkit to capture and replay REST calls, and provides mock responses when offline, ensuring data integrity and functionality across browsers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If conventional browser caching is used, then some data can be stored locally, but the cached data is of limited use for needed software operations and functions

Engineering Contradiction:

Improveamount of cached dataVSAvoidusefulness of cached data for software operations

Core Design Contradiction:

Quantity of substanceVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary synchronization mechanism that intercepts, stores, and replays network requests. This mediator layer between the client and server enables comprehensive caching of operational data while maintaining full functionality through request replay, resolving the contradiction between data quantity and functional versatility.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary actions by intercepting and storing network requests before they fail due to disconnection. By preparing and queuing requests in advance, the system ensures that all necessary software operations can be re-executed with complete data when connectivity restores, eliminating the limitations of conventional caching.

Inventive Principle:

Principle #10Preliminary action

2Reliability

If the browser refreshes the page upon reconnection, then fresh data is obtained, but any work performed using locally cached data is lost

Engineering Contradiction:

Improvedata freshnessVSAvoidloss of work performed with cached data

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The system performs preliminary actions by intercepting and storing all network requests before disconnection occurs. When reconnection happens, these pre-stored requests are replayed in sequence, ensuring that all work performed with cached data is preserved and synchronized with the server without requiring page refreshes that would lose local changes.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The synchronization mechanism provides feedback by tracking which requests were intercepted and stored. This feedback loop allows the system to selectively replay only the necessary requests, maintaining data freshness while preserving all work performed locally, thus preventing information loss upon reconnection.

Inventive Principle:

Principle #23Feedback

3Reliability

If request messages are intercepted and stored offline, then data integrity is maintained, but the complexity of handling network transitions increases

Engineering Contradiction:

Improvedata integrityVSAvoidcomplexity of network transition handling

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the network communication handling into distinct phases: request interception during offline mode, storage in a queue, and sequential replay upon reconnection. This segmentation simplifies the overall complexity by breaking down the network transition handling into manageable, discrete operations that maintain data integrity automatically.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The synchronization mechanism is self-service oriented, automatically detecting network status changes and managing the interception/replay process without requiring complex manual intervention. The system self-regulates the complexity of network transitions by monitoring connectivity state and autonomously executing the appropriate caching and replay operations to maintain data integrity.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS11477298B2Offline client replay and sync

Publication Date: 2022.10.18 ORACLE INT CORP

AI summary

An example system and method facilitates operation of a networked software application that communicates with a network resource during periods of intermittent network connectivity and includes determining when a networked software application is offline and when it is online; selectively intercepting one or more request messages from the networked software application addressed to a network resource when the software application is offline, resulting in a store of intercepted request messages; detecting when the networked software application transitions from being offline to being online; and selectively issuing the one or more request messages to the network resource in a sequence in which the one or more request messages were stored in the store of intercepted request messages. In a more specific embodiment, the system is implemented via an offline toolkit for capturing REpresentational State Transfer (REST) calls when the networked software application (client) is offline; then selectively replaying the calls when the client reconnects, i.e., goes online.