Interoperability Component for Browser-Desktop Protocol Translation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing desktop applications face challenges in seamlessly communicating between browser-executable code and non-browser executable code, particularly in implementing request-response protocols across different execution environments.

Innovation Solution

An architectural software model that includes a request translator and a response translator to facilitate communication between browser-executable code and non-browser executable code, allowing them to use a request-response protocol despite the non-browser executable code not being equipped to handle such protocols directly, and ensuring appropriate routing for scalability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If non-browser executable code is used to operate underlying non-user-interface facing functions, then functionality and power are improved, but communication complexity increases due to protocol incompatibility between browser-executable code and non-browser executable code

Engineering Contradiction:
ImprovefunctionalityVSAvoidcommunication complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an interoperability component as an intermediary layer between browser-executable code and non-browser executable code. This component includes a request translator that converts browser protocol requests into a format understandable by non-browser code, and a response translator that converts responses from non-browser code back into browser protocol format. This mediator resolves the protocol incompatibility without requiring changes to the core functionality of either code type.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If browser-executable code and non-browser executable code are distributed across different execution environments, then scalability and deployment flexibility are improved, but communication overhead and protocol translation requirements increase

Engineering Contradiction:
Improvedeployment flexibilityVSAvoidcommunication overhead
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary action by pre-configuring the interoperability component with translation rules and protocols before distribution. The request and response translators are established in advance to handle protocol conversions, allowing distributed code to communicate efficiently without ad-hoc translation overhead. The system prepares the communication infrastructure beforehand to minimize runtime translation delays.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If an interoperability component is added to enable communication between browser-executable code and non-browser executable code, then communication capability is improved, but system complexity increases

Engineering Contradiction:
Improvecommunication capabilityVSAvoidsystem complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent merges the interoperability component's translation functions into a unified interface layer that handles both request translation and response translation. Rather than implementing separate complex translation mechanisms for each direction of communication, the system combines these functions into a single interoperability component that manages bidirectional protocol conversion, thereby reducing overall system complexity while maintaining full communication capability.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS10802844B2Distributed application based off of stateful desktop application
Publication Date: 2020.10.13 MICROSOFT TECHNOLOGY LICENSING LLC
  • US10802844B2 patent drawing
  • US10802844B2 patent drawing
  • US10802844B2 patent drawing

AI summary

An architectural software model in which browser-executable code and non-browser executable code of an application are distributed. The browser-executable code (such as markup language and script) is executed by a browser on perhaps a client machine, whilst the non-browser executable code (such as C# code as an example) is executed on a server or by a service. Such code typically is included within a single desktop application with an interoperability component operating between. The browser-executable code is able to communicate with the non-browser executable code using a request-response protocol. In order to facilitate communication with the non-browser-executable code, the non-browser executable code is provided in an environment that includes a request translator and a response translator. The environment includes an interface which honors the request/response protocol followed by the browser-executable code.