Dynamic Map Rendering via Client-Side Context Merging

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current online maps are static and do not dynamically adjust based on a user's location or scheduled tasks, failing to provide relevant information in real-time contexts.

Innovation Solution

A method and system that send mapping data requests from client devices including geographic location and time, allowing for dynamic map rendering by referencing user's scheduled tasks and preferences, modifying map data based on time differences and user-specific data to highlight relevant elements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If static map data is returned for all users regardless of context, then data consistency and simplicity are maintained, but relevance and personalization deteriorate

Engineering Contradiction:
ImproveRelevance of map informationVSAvoidSystem complexity for dynamic content delivery
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system pre-fetches and caches application data (calendar events, emails, contacts) on the client device before map rendering is needed. This preliminary data preparation enables dynamic map personalization without adding server-side processing complexity during actual map requests, resolving the contradiction between information relevance and system complexity

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies different rendering styles and content priorities to different map elements based on their relevance to the user's current application context. For example, locations of upcoming meetings are highlighted differently than generic POIs, allowing the map to maintain overall simplicity while providing targeted relevant information in specific areas

Inventive Principle:
Principle #3Local quality

2Adaptability or versatility

If map data is customized based on user context and preferences, then personalization and relevance improve, but data processing time and complexity increase

Engineering Contradiction:
ImproveMap customization capabilityVSAvoidMap rendering time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

User preferences, application data, and contextual information are cached locally on the client device in advance. When a map is requested, the system performs a client-side merge of the cached map template with the cached application data, eliminating the need for time-consuming server-side processing and data retrieval during actual map rendering

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system uses a template-based approach where only the essential map structure and styling are defined once as templates. The dynamic personalization is achieved by selectively overlaying application-specific data onto these templates, rather than generating complete customized maps from scratch, thus reducing processing time while maintaining adaptability

Inventive Principle:
Principle #16Partial or excessive action

3Productivity

If identical map requests from different users return the same data, then server processing efficiency is maintained, but user-specific relevance is lost

Engineering Contradiction:
ImproveServer processing efficiencyVSAvoidUser-specific map personalization
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent uses template copying where a base map template is created once and then copied for each user request. The copied template is then locally customized on the client device by merging with user-specific application data. This approach maintains server processing efficiency (since the template is generated once) while enabling user-specific personalization through client-side customization

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent introduces an intermediary layer of application data that sits between the static map template and the final personalized map display. This intermediary data layer (containing calendar events, emails, contacts) allows the same map template to serve multiple users with different personalization needs without requiring server reprocessing, thus maintaining efficiency while enabling adaptability

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2943752B1Displaying dynamic content on a map based on user's location and scheduled task
Publication Date: 2020.09.23 GOOGLE LLC
  • EP2943752B1 patent drawingFigure 1A
  • EP2943752B1 patent drawingFigure 1B~1D
  • EP2943752B1 patent drawingFigure 1E

AI summary

Graphic elements for a computer-implemented mapping system may be displayed based on scheduled task data, routine data, or other data corresponding to an application of a client computing device. The application data may include a location and a scheduled time. A user may request a map for the scheduled task location. If a difference between the request time and the scheduled task time is below a threshold, then the mapping system may display or modify graphic elements for the location that are relevant to the scheduled task. For example, a user may include appointment data for an airline flight in a calendar application of a mobile computing device. If the user requests a map of the departure airport within a short amount of time before the flight, the map may include only relevant graphic elements such as a check in counter, a security checkpoint, and a departure gate.