Messenger Plug-in Mediator for Cross-Instance Content Conversion

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Messenger application plug-ins are not universally accessible across all participants in a conversation thread, limiting functionality and user experience due to optional installation, resulting in inconsistent content and feature availability.

Innovation Solution

A plug-in communicates with both supplemented and unsupplemented messenger application instances, providing enhanced content to the former while converting it to thread-native content for the latter, enabling interactive features, location-specific services, and tailored advertisements based on shared data.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a plug-in is installed on a messenger application instance, then enhanced functionality and rich content are provided, but not all participants in the conversation thread can access the same functionality

Engineering Contradiction:
ImprovefunctionalityVSAvoidconsistency
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system introduces a server as an intermediary that receives requests from messenger application instances, determines the appropriate content format based on plug-in availability, and delivers customized content. This mediator ensures that all participants receive relevant content in formats their instances can handle, resolving the inconsistency caused by selective plug-in installation.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system provides different content formats to different participants based on their local capabilities. Supplemented instances receive rich, interactive content while unsupplemented instances receive thread-native content. This local adaptation ensures each participant receives the optimal content type for their specific instance configuration.

Inventive Principle:
Principle #3Local quality

2Ease of operation

If a plug-in provides rich, non-thread-native content to supplemented instances, then user experience is enhanced, but unsupplemented instances cannot display or interact with the same content

Engineering Contradiction:
Improveuser experienceVSAvoidcontent compatibility
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The system changes the format parameter of content based on the recipient's capabilities. The server detects whether the receiving instance has the plug-in installed and dynamically adjusts the content format accordingly - serving rich content to supplemented instances and thread-native content to unsupplemented instances, ensuring universal compatibility.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The content delivery system is made dynamic by continuously assessing the capabilities of each participant instance and adjusting the content format in real-time. This dynamic adaptation allows the system to provide enhanced experiences where possible while maintaining compatibility where plug-ins are absent.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If the plug-in handles additional input options beyond native messenger capabilities, then interactive features are expanded, but unsupplemented instances have limited interaction options

Engineering Contradiction:
Improveinput optionsVSAvoidinteraction capability
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The server acts as an intermediary that receives input from any participant regardless of their instance capabilities, processes the input appropriately, and routes it to the supplemented instance that can handle it. This allows unsupplemented instances to participate in interactive features through simplified input methods while still contributing to the overall interaction.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

Instead of requiring all instances to have advanced input capabilities to participate in interactive features, the system inverts the approach by allowing unsupplemented instances to use basic input methods while the supplemented instance with advanced capabilities handles the complex interaction. This reversal ensures universal participation.

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

4Adaptability or versatility

If plug-in installation is optional, then user choice and flexibility are maintained, but functionality and user experience become inconsistent across participants

Engineering Contradiction:
Improveuser choiceVSAvoidexperience consistency
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The server is designed to handle multiple content formats and delivery scenarios universally. It can serve both rich content to supplemented instances and thread-native content to unsupplemented instances through a single unified system, maintaining experience consistency across all participants while respecting their different capabilities.

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

Solution Approach 2:

The system maintains optional plug-in installation by allowing each user to choose their level of enhancement, while ensuring consistent experience quality through localized content adaptation. Each participant receives content optimized for their specific instance configuration, ensuring the best possible experience for their chosen setup.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS10313296B2Plug-in for extending functionality of messenger application across supplemented and unsupplemented application instances
Publication Date: 2019.06.04 META PLATFORMS INC
  • US10313296B2 patent drawing
  • US10313296B2 patent drawing
  • US10313296B2 patent drawing

AI summary

A first instance of a messenger application having a plug-in communicates with a second instance of the messenger application lacking the plug-in. The plug-in provides enhanced functionality to the first instance of the messenger application, while also providing corresponding functionality to the second instance, which lacks the plug-in. For example, the plug-in may provide rich, non-thread-native content to the first instance, while also providing corresponding thread-native content to the second instance. As another example, the plug-in may obtain data from the second instance and provide tailored advertisements to the second instance based upon that data. An another example, the plug-in may obtain location data from one or more of the instances and provide access to location-specific services that take the location data into account.