Mobile Device Update Management via Centralized ESB and TSM

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing mobile commerce systems face challenges in efficiently updating services on mobile devices, as users often need to manually request updates, which can be sub-optimal in timing and may not account for device availability, and existing technologies struggle with processing updates for large groups of devices independently.

Innovation Solution

A system utilizing an enterprise service bus (ESB) and central trusted service manager (TSM) to manage and schedule updates, allowing for concurrent processing of workflows across multiple devices without user intervention, using a framework that identifies and processes devices meeting predefined criteria, and coordinates updates through a common proxy, enabling batch processing and error handling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If manual update requests are required from users, then user control over update timing is improved, but user burden and update timeliness deteriorate

Engineering Contradiction:
Improveuser controlVSAvoidupdate timing
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The system enables self-service updating where the mobile device automatically receives and processes service updates without requiring user initiation. The device monitors for updates, downloads them when available, and installs them according to system-defined policies, freeing users from manual update requests while ensuring timely updates.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary actions by pre-configuring update policies, pre-downloading updates when device resources are available, and pre-scheduling update installations for optimal times. This prepares the device in advance so that updates are ready to install without user intervention when the time comes.

Inventive Principle:
Principle #10Preliminary action

2Ease of operation

If auto updating is used, then user interaction is reduced, but it cannot process functions available for mobile devices

Engineering Contradiction:
Improveuser interactionVSAvoidfunction processing
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The update system is made dynamic by allowing update policies to be configured and modified without requiring user interaction. The system can adapt update behavior based on device state, network conditions, and service priorities, enabling sophisticated processing of multiple functions while maintaining automatic operation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

An intermediary update management system is introduced between the user and the update process. This intermediary component handles all update operations automatically, interpreting service requirements, managing download/installation timing, and coordinating with multiple services, thereby reducing user interaction while expanding functional processing capabilities.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If updates are processed individually for each device, then device-specific customization is improved, but processing efficiency for large groups deteriorates

Engineering Contradiction:
Improvedevice customizationVSAvoidprocessing efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The system merges update processing operations by implementing a centralized update distribution mechanism that pushes updates to multiple devices simultaneously. The update management server can broadcast updates to numerous devices in parallel, maintaining device-specific customization through targeted delivery while dramatically improving processing efficiency for large device groups.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The update processing is segmented into centralized management functions and distributed execution functions. The server handles update selection, packaging, and distribution centrally, while individual devices handle local installation and configuration. This segmentation allows efficient bulk processing at the server level while preserving device-specific customization at the execution level.

Inventive Principle:
Principle #1Segmentation

4Reliability

If the mobile device is disconnected or busy, then device availability is reduced, but update timing becomes sub-optimal or impossible

Engineering Contradiction:
Improvedevice availabilityVSAvoidupdate timing
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements periodic action by scheduling update checks and installations during specific time periods when device availability is likely, such as nighttime or low-usage periods. The update mechanism periodically attempts to contact the device, and if unavailable, automatically retries at scheduled intervals, ensuring updates occur when possible without requiring user intervention.

Inventive Principle:
Principle #19Periodic action

Solution Approach 2:

The system performs preliminary actions by pre-scheduling update installations for times when device availability is expected to be high. The update management system anticipates device availability patterns and proactively prepares updates for installation during optimal windows, reducing the impact of device disconnection or busyness on update timing.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9292345B2Systems, methods, and computer program products for processing sets of instructions for mobile devices
Publication Date: 2016.03.22 GOOGLE LLC
  • US9292345B2 patent drawing
  • US9292345B2 patent drawing
  • US9292345B2 patent drawing

AI summary

Systems, methods, and computer program products are provided for managing processes. A command is received to process one or more workflows, each of the one or more workflows including a set of instructions. A request for identification of one or more devices meeting predefined criteria is issued. A device identifier (ID) and data corresponding to each of the one or more devices meeting the predefined criteria are stored in a database. The one or more workflows are processed for each of the one or more devices meeting the predefined criteria by executing the set of instructions included in the one or more workflows. Executing the set of instructions included in the one or more workflows includes calling one or more functions to be performed by one or more communicatively coupled systems.