Unified Virtual Machine API Translation for Mobile Apps

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Wireless mobile devices face challenges in supporting multiple application types due to the need for duplicating sets of APIs, libraries, and engines, which is costly and resource-intensive, especially given processor and memory constraints.

Innovation Solution

A method and apparatus that groups common application interfaces to create application containers, translating calls between these containers and shared APIs, using a class loading structure and API call translators to enable the running of different application types on a single virtual machine, reducing memory and flash requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple application types are supported by duplicating sets of APIs, libraries and engines, then application versatility is improved, but device complexity and resource consumption increase

Engineering Contradiction:
Improveapplication type supportVSAvoidresource duplication
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal execution environment that can run multiple application types (MIDlets, Doja applications, Xlet applications, native applications) through a single virtual machine. The system uses a unified set of shared APIs and libraries that serve all application types, eliminating the need for separate execution environments for each application type. This multi-functional approach allows one virtual machine to handle diverse application requirements.

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

Solution Approach 2:

The patent introduces an API translator as an intermediary component that translates API calls from different application types into a unified set of shared APIs. The translator acts as a mediator between the diverse application interfaces and the common library layer, enabling application types to coexist without requiring duplicate libraries. This intermediary layer resolves the contradiction by maintaining application versatility while using a single set of shared resources.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If multiple execution environments are used for different application types, then application compatibility is improved, but memory and flash storage requirements increase

Engineering Contradiction:
Improveapplication compatibilityVSAvoidmemory and flash usage
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent merges multiple execution environments into a single virtual machine that can execute different application types. Instead of having separate execution environments for MIDlets, Doja applications, Xlet applications, and native applications, the system combines them into one unified environment with shared APIs and libraries. This merging directly reduces the memory and flash storage requirements while maintaining compatibility across application types.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The virtual machine is designed as a universal execution environment that can handle multiple application types through a single set of shared resources. The unified architecture allows the same memory space and flash storage to serve multiple purposes across different application types, eliminating the need for separate execution environment copies and thereby reducing overall resource consumption.

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

3Reliability

If different security models are employed for each application type, then application security is improved, but system complexity and management difficulty increase

Engineering Contradiction:
Improveapplication securityVSAvoidsecurity model variety
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a security translator as an intermediary that mediates between different application security models and a unified security framework. The translator converts security requirements from various application types into a common security model, allowing the system to maintain application-specific security needs while using a single unified security implementation. This reduces the complexity of managing multiple security models.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent uses virtualization to create virtual copies of security contexts for different application types within a unified security framework. Each application type gets its own virtual security context that can be isolated and managed independently, while the underlying security infrastructure remains unified. This virtual copying approach maintains application-specific security without requiring separate physical security models.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS7810105B2Method and apparatus for running different types of applications on a wireless mobile device
Publication Date: 2010.10.05 GOOGLE TECHNOLOGY HOLDINGS LLC
  • US7810105B2 patent drawing
  • US7810105B2 patent drawing
  • US7810105B2 patent drawing

AI summary

A method and wireless mobile device runs different types of applications and groups a set of common application interfaces (APIs) that are associated with an application type to produce an application container (902). The wireless mobile device and method translates calls between at least one of the linked or grouped common APIs of the application container and a shared API that is shared for example among applications of different types (904). If desired the method and device also groups a set of common application interfaces associated with another application type to produce another application container. The applications of different types use APIs from the multiple application containers. In one embodiment, the translating of calls is accomplished by employing a class loading structure using, for example, a class loader that looks at certain path locations to obtain resources.