Dynamic Content Delivery Architecture for Mobile Adaptability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current mobile device content delivery technologies, such as WAP, SMS, and cell broadcast, lack customization and intelligence, failing to adapt to user-specific capabilities and device limitations, necessitating a more dynamic and adaptable solution for delivering diverse content.

Innovation Solution

A dynamic content delivery architecture that employs metadata to provide intelligence to processing elements, allowing for layered metadata models, plug-in registration, and a mixed push/pull content delivery model, enabling flexible content handling and fragmentation to accommodate various devices and applications without modifying the underlying architecture.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If WAP is used to push content, then content delivery capability is provided, but websites must be rewritten to satisfy the protocol and provide uniform content that does not adapt to user capabilities

Engineering Contradiction:
Improvecontent customization to user capabilitiesVSAvoidwebsite rewriting requirement
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The content delivery system is segmented into multiple independent components: content providers, push proxies, push clients, and application layers. Each component operates independently with defined interfaces, allowing content to be delivered without requiring website rewrites. The push proxy acts as an intermediary that handles protocol-specific adaptations while content providers maintain their original content formats.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The push proxy serves as an intermediary between content providers and push clients. It receives content from providers, processes metadata, applies processing rules, and delivers content to appropriate clients. This intermediary layer eliminates the need for content providers to rewrite websites for different protocols, as the proxy handles all protocol-specific transformations.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If SMS based push or cell broadcast is used, then push delivery capability is achieved, but delivery cannot be customized to individual user needs or device capabilities

Engineering Contradiction:
Improvedelivery customization to user needsVSAvoidintelligence in delivery system
Core Design Contradiction:
Adaptability or versatilityVSExtent of automation

Solution Approach 1:

The system employs dynamic processing rules that can be modified in real-time based on user preferences, device capabilities, and network conditions. The push proxy dynamically selects and applies appropriate processing rules from a rule set, allowing delivery customization without requiring manual intervention. This dynamic approach provides both adaptability and automation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system incorporates feedback mechanisms where push clients report their capabilities and preferences to the push proxy. The proxy uses this feedback information to select appropriate processing rules and customize content delivery. This feedback loop enables intelligent, adaptive delivery that responds to actual user needs and device states.

Inventive Principle:
Principle #23Feedback

3Adaptability or versatility

If a fixed content delivery architecture is used, then system simplicity is maintained, but applications and content providers cannot be added without modifying the architecture

Engineering Contradiction:
Improveability to add applications and content providersVSAvoidarchitecture modification requirement
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The push proxy is designed as a universal platform that can handle multiple content types, protocols, and client applications through a standardized interface. It supports multiple processing rules that can be applied to different content providers and clients without requiring architectural changes. This universality allows new applications and content providers to be integrated by simply adding new processing rules rather than modifying the core architecture.

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

4Adaptability or versatility

If content is delivered without processing rules, then delivery speed is maintained, but content cannot be prioritized or customized based on user preferences and network conditions

Engineering Contradiction:
Improvecontent prioritization and customizationVSAvoidprocessing time for content
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

Processing rules are pre-configured and stored in the push proxy before content delivery occurs. When content arrives, the proxy quickly matches it against the pre-defined rule set and applies the appropriate processing. This preliminary preparation of processing rules minimizes real-time processing overhead while still enabling sophisticated content prioritization and customization based on user preferences and network conditions.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8019892B2Multi-layered enveloped method and system for push content metadata
Publication Date: 2011.09.13 MALIKIE INNOVATIONS LTD
  • US8019892B2 patent drawing
  • US8019892B2 patent drawing
  • US8019892B2 patent drawing

AI summary

A method and system for adding processing intelligence to content payload in a dynamic content delivery architecture having at least a first processing element and a second processing element, the method having the steps of: creating a first envelope, the first envelope including content payload and second processing element metadata, the second processing element metadata adapted to be run on the second processing element; and forming a second envelope, the second envelope containing the first envelope and first processing element metadata adapted to be run on the first processing element.