Browse Prior Art Database

A system to incept and transform link protocols on mobile device

IP.com Disclosure Number: IPCOM000240819D
Publication Date: 2015-Mar-05
Document File: 4 page(s) / 63K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes a solution to use the best fit application to open the resounces on the mobile device . Resources can be http links or any other kind of resources. The solution adds an inception layer in the container before any resource is handled on the device. The inception layer can know what's the resources and what applications are installed on the device, based on those information, it can then calcualte which is the best application to open the resource. The inception layer can further be managed by a MDM(Mobile Device Management) system as well.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 4

A system to incept and transform link protocols on mobile device

When we send emails or other kind of messages to people, usually we may include a link in the message to point to another resource. Most of the cases on desktop, the link is a http link. By clicking the link, web browser will be open to read the resource details.

While on mobile devices, usually we have a native application which can be used to open the specific resource. We would like to use that native application to open the resource instead of mobile browser. In this case , we have to use a custom protocol in the link. When the link is clicked on mobile device, mobile OS can find which application can response to that specific protocol , and will use that application to open the link. For example if the email contains a link to allow mobile user to launch a native application to read a blog, the email creator may embed below link in the email body, instead of the traditional HTTP link:

blog://server.host/blogs?action=BlogEntries&handle=

This brings a problem that how the sender would compose the message correctly to make sure each device can use the best way to open the resource, and also to make sure web browser users who do not have the mobile app installed can launch mobile browser to load the resources without problem.

Current solution is to add a custom control protocol in the message, all the links with different protocol for different devices are included in the control. When the custom control is clicked, it contains logic to determine the devices type and returns the link for the device. The control may contain a javascript code to detect the user agent type, if it finds it's in a mobile browser, it will use the custom protocol, if it's on a desktop browser, it will use the http protocol. Another solution today is the email composer will include 2 links in the email, one HTTP/HTTPs and the other one is the custom protocol, and device user can choose which link to click.

This solution has several drawbacks:


1. It's inconvenient for senders to include a custom control in the message. Not all the time, the sender is possible to add that control.


2. For historic message, only http link is included in the message. It's not possible to change the historic message to include the control.

3. It's not possible or very hard to copy/paste a custom control to other applications on mobile device, since other application may not recognize the control.

4. Different applications need to develop their own custom controls, this wastes developer's effort.

We want to have a simple solution to use best way to open the link on different devices, and still keep the link simple.

The core idea is to add an inception layer in the container before any link is processed. The inception layer can be managed by MDM

1



Page 02 of 4

(Mobile Device Management) system .The inception layer in the container is a native component in the mobile device.It will incept the link URL before it's p...