Remote Stand-Alone Exception Handler Module

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional error or exception handling in mobile devices is often customized and compiled statically, making it challenging for developers to account for all possible exceptions, leading to application crashes and unexpected behavior due to unhandled exceptions.

Innovation Solution

An application framework that allows field configuration of exception handlers, enabling exceptions to be handled uniformly across applications by a remote stand-alone exception handler module, which can be executed by a host server or another remote computing device, and communicates with local applications to centralize error reporting and handling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If static exception handling is used, then exception handling is customized and compiled, but it is challenging to account for all possible exceptions leading to application crashes

Engineering Contradiction:
Improveexception handling coverageVSAvoidexception handling complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts exception handling functionality from the local application and relocates it to a remote server. The local device generates exceptions and transmits them to the remote exception handler, which processes and returns handling instructions. This extraction allows comprehensive exception coverage without burdening the local device with complex exception handling logic.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The remote exception handler serves multiple applications and devices universally, providing centralized exception handling for all possible exception types. This universal handler can account for all possible exceptions across different applications without requiring each application to implement its own comprehensive exception handling.

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

2Reliability

If dynamic exception handling is used, then code operates in the event of an error, but processing burdens remain on local devices

Engineering Contradiction:
Improveerror handling capabilityVSAvoidlocal device processing burden
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent extracts the computationally intensive exception processing from the local device and relocates it to the remote server. The local device only generates exceptions and transmits them, while the remote exception handler performs the actual error handling processing, significantly reducing the processing burden and energy consumption on local devices.

Inventive Principle:
Principle #2Taking out (Extraction)

3Ease of operation

If centralized error reporting is implemented, then processing burdens are removed from local devices, but network communication is required

Engineering Contradiction:
Improveerror reporting simplicityVSAvoidsystem architecture complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent introduces a network communication intermediary to connect local devices with the remote exception handler. This intermediary enables centralized error reporting by facilitating exception transmission from local devices to the remote server and returning handling instructions, simplifying local error reporting while managing the architectural complexity through standardized communication protocols.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11500710B1Stand-alone exception handler module
Publication Date: 2022.11.15 T MOBILE US INC
  • US11500710B1 patent drawing
  • US11500710B1 patent drawing
  • US11500710B1 patent drawing

AI summary

An application framework that provides field configuration of exception handlers by one or more applications, rather than defining exceptions at runtime. The exception handler may operate as a remote service in communication with an application executing locally. When an exception is received, the exception handler can consume the exception and return a defined object based on the exception type.