Virtualization Layer for Mobile App Class Lifecycle Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing mobile application wrapping methods are inefficient as they have a strong dependency on the target application and operating system, limiting the control over the lifecycle of classes and thus restricting policy enforcement and access controls.

Innovation Solution

A virtualization layer is introduced by parsing the application code to identify and replace the original classes with new ones that do not inherit from the original classes, providing additional functions and enforcing policies, allowing for better management of the application's lifecycle and functionality.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If application wrapping methods are used to control mobile application execution, then policy enforcement capability is improved, but dependency on target application and operating system increases, limiting control effectiveness

Engineering Contradiction:
Improvepolicy enforcement capabilityVSAvoidcontrol effectiveness
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a virtualization layer as an intermediary component between the mobile application and the operating system. This virtualization layer includes virtual classes that mediate all interactions, allowing policy enforcement without direct dependency on the target application's internal structure or the operating system's implementation details. The virtualization layer acts as a universal interface that can control any application regardless of its specific framework or lifecycle management approach.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the application control mechanism into distinct virtual classes that correspond to the application's original classes but operate independently. By creating separate virtual class instances with the same names and structures as the original classes, the system achieves fine-grained control over specific application components without affecting the entire application or relying on the original class hierarchy. This segmentation enables targeted policy enforcement on individual classes while maintaining overall system independence.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If management layer controls application lifecycle through inheritance, then integration with operating system is improved, but control over class lifecycle is lost due to operating system implementation

Engineering Contradiction:
Improveintegration with operating systemVSAvoidlifecycle control capability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

Instead of having the management layer inherit from and control the original classes (traditional approach), the patent inverts the control relationship by creating virtual classes that replicate the original class interfaces. The virtual classes are instantiated and controlled by the virtualization layer, which then manages their lifecycle independently of the operating system's inheritance mechanisms. This inversion allows the virtualization layer to maintain full control over class lifecycle while still providing the expected integration behavior to the operating system.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent creates virtual classes that are copies of the original application classes, with the same names, structures, and interfaces. These copied virtual classes serve as substitutes that can be controlled independently by the virtualization layer. By copying rather than inheriting, the system achieves lifecycle control without being constrained by the operating system's inheritance-based lifecycle management, while maintaining compatibility through interface replication.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If original classes are replaced with virtual classes providing different functions, then policy enforcement flexibility is improved, but complexity of class management increases

Engineering Contradiction:
Improvepolicy enforcement flexibilityVSAvoidclass management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates virtual classes that serve multiple functions: they replicate the original class interfaces for compatibility, provide independent lifecycle management for control, and enable policy enforcement for security. Each virtual class acts as a universal component that can fulfill the role of the original class while adding layers of control and policy enforcement capability. This multi-functionality reduces the need for separate mechanisms for compatibility, control, and security.

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

Solution Approach 2:

The virtual classes are designed to be self-contained with all necessary control logic embedded within them. Each virtual class manages its own lifecycle, state, and policy enforcement requirements independently, without requiring external management infrastructure. This self-service approach simplifies class management by distributing control responsibilities to individual virtual classes rather than requiring centralized management of complex class hierarchies.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10768903B2Virtualization layer for mobile applications
Publication Date: 2020.09.08 CITRIX SYSTEMS INC
  • US10768903B2 patent drawing
  • US10768903B2 patent drawing
  • US10768903B2 patent drawing

AI summary

Methods, systems, and computer-readable media for providing a virtualization layer for mobile applications are presented. A computing device may parse code of an application to identify a first set of one or more classes in the application. The computing device may transmit code usable by the first set of one or more classes to a module accessible to the application and create a second set of one or more classes in the application to replace the first set of one or more classes, wherein the second set of one or more classes does not inherit from the first set of one or more classes in an object hierarchy. In some embodiments, the second set of one or more classes provides at least one different function from the first set of one or more classes. The computing device may execute the application comprising the second set of one or more classes.