InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Technique to prevent unintended user input on an application triggered pop-up.

IP.com Disclosure Number: IPCOM000236968D
Publication Date: 2014-May-23
Document File: 4 page(s) / 39K

Publishing Venue

The IP.com Prior Art Database


The disclosure is to disable the keyboard action which can input a user action for the displayed message, whenever there is a User input request or a pop-up from a Background application. This is done to avoid an action being taken accidentally i.e without the user reading the complete message and then take appropriate action.

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

Page 01 of 4

Technique to prevent unintended user input on an application triggered pop -up.

The problem to be addressed is in a scenario where a user input is passed to requesting application without intending to do so.

The example scenario is when a user is running or installing an application in the background and at the same time working on another task (or an application). It is expected that during installation of an application, the application needs some manual user intervention, seeing user inputs. The background application requests for a user action by throwing a popup message.

Now since the user is working on an another task, which also requires a carriage return the pop up message having the tab takes the input of the carriage return and does some action the user did not intend to do.

Let's consider some typical use cases, where this is foreseen as a problem:

Scenario 1: Desktop

Consider a scenario where an user has initiated an installation of an application on his Personal Computer, now since the installation is running in the background the user switches to another activity of updating an MS Word document. The case in point is when the user is about to press the return key to move to the next line and at the same time the background application returns a

pop-up to specify a path to the installation. Now as the return key is pressed the installation path is taken to default while the user wanted to install it in a different path. Now since we know that the pop up is triggered by the background application and not an user triggered pop up, disabling the return key at this time would prevent the unintended user input.

Scenario 2: Mobile

The same technique could be extended on a mobile device. Consider a scenario where an user is working on his mobile device and has initiated a download and install of an application, now while the installation is happening the user decides to do some other random operation on his touch screen, the case in point is when the application is about to display a pop up to install the trail copy or the full version, and while doing random operations on his screen he accidentally clicks on the trial while he wanted to install the full version of the application, thus creating an unintended user input. This can be avoided...