Mobile App Interprocess Communication via Server-Mediated Key Exchange
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current mobile deep linking mechanisms are limited by the size and security of messages exchanged, as they rely on uniform resource identifiers (URIs) that restrict data capacity and are insecure when using plain text, and encryption increases message length, compromising security and data type flexibility.
Innovation Solution
A secure communication system where a first app generates a key and message, sent to a server for encoding, allowing secure and flexible data exchange between apps without size or type limitations, using a server to decrypt and return the original message upon app launch, ensuring message security.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data in URI is encrypted to improve security, then message security is improved, but message length increases which reduces data capacity
Solution Approach 1:
The patent introduces a server as an intermediary to handle the encrypted message. The server receives the encrypted message from the first app, decrypts it using a shared secret key, and forwards the decrypted message to the second app. This mediator approach allows the use of encryption for security while avoiding the problem of transmitting long encrypted strings through URI parameters, as the decryption happens on the server side rather than requiring the encrypted data to fit within URI length limits.
2Ease of operation
If URI length is limited to maintain platform compatibility, then ease of operation is improved, but message size is restricted
Solution Approach 1:
The patent moves the message transmission from the URI dimension (which has length constraints) to a different dimension - server-based communication. Instead of embedding the entire message in the URI, the system uses the URI only to trigger the communication flow, while the actual message is transmitted through server-mediated channels that are not constrained by URI length limitations. This dimensional shift allows arbitrary message sizes while maintaining platform compatibility.
3Ease of manufacture
If plain text is used in URI to simplify implementation, then ease of manufacture is improved, but security is compromised
Solution Approach 1:
The patent applies preliminary encryption to the message before it is transmitted. The first app encrypts the message using a shared secret key before sending it to the server. This preliminary security measure ensures that even if the transmission channel is intercepted, the message remains secure. The encryption is performed in advance (preliminarily) in the first app, maintaining implementation simplicity while achieving strong security.
4Reliability
If message is encrypted to protect sensitive information, then reliability is improved, but message length increases reducing capacity
Solution Approach 1:
The server acts as a mediator that handles the encrypted message decryption. The first app sends the encrypted message to the server, which then decrypts it using a pre-shared secret key and forwards the decrypted message to the second app. This intermediary approach allows the system to use strong encryption for data protection while avoiding the URI length constraints that would otherwise limit message capacity, as the decryption occurs on the server rather than requiring the encrypted data to fit in URI parameters.
Data Source
AI summary
Systems and methods for secure communications between mobile applications installed on a user's mobile device. In some embodiments, a first application installed on a user's mobile device generates a key and transmits the key and a message to a server, where the message is to be communicated to a second application. According to disclosed embodiments, there is no limit on the size or a type of data included in the message. The server receives the message and the key from the first application. The first application shares the key with the second application which is then transmitted to the server for authenticating the second application. Upon authenticating the second application, the server transmits the message to the second application. In some embodiments, the applications and/or the server exchanges data with goods/services providers associated with the applications.