Mobile Search Suggestions via Latency Prediction and Cache Selection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Mobile applications face user experience degradation due to high network latency, as they struggle to provide timely search results, leading to frustrating interactions when network conditions change.

Innovation Solution

Implement a method on mobile devices to predict expected network latency by measuring and categorizing it, allowing the application to adjust its behavior by retrieving results from a local cache or a remote server based on the latency category, ensuring timely information delivery.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the application retrieves results from a remote server, then the results are up-to-date and comprehensive, but the response time increases due to network latency

Engineering Contradiction:
Improveresult accuracyVSAvoidresponse time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The application pre-loads and stores search results in a local cache before they are needed. When a user submits a query, the application first checks the local cache for matching results, allowing immediate display without waiting for remote server response. This preliminary storage action resolves the contradiction by providing fast local access while maintaining result availability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The application implements a hybrid result retrieval strategy where frequently accessed or predictable results are stored locally with high-quality cache storage, while less frequent results remain on the remote server. The system dynamically selects between local cache and remote server based on query characteristics, network conditions, and cache hit probability, optimizing the balance between speed and comprehensiveness.

Inventive Principle:
Principle #3Local quality

2Loss of time

If the application uses local cache for results, then the response time is fast, but the results may be outdated or incomplete

Engineering Contradiction:
Improveresponse timeVSAvoidresult accuracy
Core Design Contradiction:
Loss of timeVSReliability

Solution Approach 1:

The application implements a feedback mechanism that monitors cache hit rates, query patterns, and network conditions. When the cache becomes outdated or network conditions improve, the system automatically refreshes cached results or adjusts its retrieval strategy. This feedback loop ensures local results remain accurate while maintaining fast response times.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The application dynamically adjusts its cache refresh strategy based on real-time conditions. For time-sensitive queries, it prioritizes remote server retrieval even with higher latency. For less time-critical queries, it uses local cache. The system also dynamically invalidates or updates cache entries based on content freshness requirements, making the result reliability adaptive to different query types and network states.

Inventive Principle:
Principle #15Dynamics

3Measurement precision

If the application monitors network calls to predict latency, then the latency prediction accuracy improves, but the device consumes additional processing resources

Engineering Contradiction:
Improvelatency prediction accuracyVSAvoidprocessing overhead
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The application monitors only a subset of network calls rather than all network traffic. It selectively tracks latency for specific types of requests (e.g., HEAD requests, lightweight GET requests) that are representative of overall network conditions. This partial monitoring approach provides sufficient prediction accuracy without the excessive processing overhead of comprehensive monitoring.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The application uses lightweight, disposable latency measurement objects that are created temporarily for each measurement and then discarded. Instead of maintaining complex persistent monitoring structures, it uses simple transient objects that consume minimal memory and processing resources, achieving adequate prediction accuracy with low overhead.

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

4Ease of operation

If the application adapts behavior based on network latency category, then the user experience is optimized, but the application logic becomes more complex

Engineering Contradiction:
Improveuser experienceVSAvoidapplication logic
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The application segments network conditions into discrete latency categories (e.g., low, medium, high latency) with clear thresholds. Each category triggers specific, pre-defined behaviors such as choosing between local cache and remote server retrieval. This segmentation simplifies the adaptation logic compared to continuous threshold checking, making the system easier to implement and maintain while still providing optimized user experience.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS10673722B2Search result suggestions based on dynamic network latency classification
Publication Date: 2020.06.02 UBER TECHNOLOGIES INC
  • US10673722B2 patent drawing
  • US10673722B2 patent drawing
  • US10673722B2 patent drawing

AI summary

An application on a mobile device, in response to received partial queries from users, displays suggested results based upon the received partial query, allowing the user to select a suggested result without having to input the complete query. In order to ensure that suggested results can be provided to the user in a timely manner, the application determines an expected latency of a network connection of the mobile device by periodically measuring the latency of network requests and predicting an expected future latency based upon the measured latency values. Based upon the expected latency, the application may retrieve the suggested results from a server, or from a local cache storing results of previous queries by the users as well as popular results associated with a geographic area of the user, or some combination thereof.