On-Demand Application Permissions for Privacy Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software applications require users to grant broad permissions at installation, which may include unnecessary access to sensitive information or device features, leading to potential privacy concerns and inefficient use of device resources, as not all permissions are required for all app functions.
Innovation Solution
Implementing on-demand application permissions, where users are prompted for consent only when specific app functions require access to sensitive information or device features, allowing users to grant permissions on an as-needed basis, with options for 'Yes', 'No', or 'Defer' for each feature, and storing consent settings locally or globally for future use.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If users are asked to provide permissions at installation time, then the app can access all required features immediately, but users may be forced to grant unnecessary permissions and experience privacy concerns
Solution Approach 1:
The patent segments permission requests by function, dividing the permission granting process into discrete functional units. Instead of requesting all permissions at once during installation, the system requests permissions on-demand when specific functions are invoked, allowing users to grant permission for individual functions rather than the entire application.
Solution Approach 2:
The patent implements preliminary consent management by storing consent settings locally or globally for future use. The system pre-establishes a consent framework that can be applied across multiple function requests, reducing repeated permission prompts while maintaining user control over privacy-sensitive access.
2Object-affected harmful factors
If users are prompted for consent for each function, then user control over privacy is enhanced, but the complexity of permission management increases
Solution Approach 1:
The patent implements a universal consent management system that handles multiple permission types through a unified interface. The consent mechanism works across different functions and data types (camera, microphone, contacts, storage, etc.) using consistent user interactions and storage methods, simplifying the overall management complexity despite the variety of permissions.
Solution Approach 2:
The patent uses local or global consent settings that are stored and reused across multiple function requests. Instead of repeatedly prompting users for the same permission, the system copies previously granted consent settings and applies them to subsequent requests, reducing the frequency of complex permission dialogs.
3Loss of energy
If permissions are requested on-demand, then unnecessary permissions are not granted, but additional prompts during app usage increase user interaction overhead
Solution Approach 1:
The patent stores consent settings in advance (locally or globally) so that once a user grants permission for a function, the consent is cached and automatically applied to future requests for the same function. This preliminary storage of consent decisions eliminates repeated permission prompts, reducing user interaction overhead while maintaining on-demand permission benefits.
4Productivity
If broad permissions are granted at installation, then app functionality is fully available, but device resources may be inefficiently used
Solution Approach 1:
The patent segments app functionality by function, allowing the application to operate with partial functionality until specific permissions are granted. Each function is independently enabled or disabled based on its associated permission status, ensuring that device resources are only consumed when the user has explicitly authorized that specific function to run.
Data Source
AI summary
On-demand application permissions is described, including obtaining one or more consents associated with one or more functions of an application, where the application does not allow using the functions without associated consents; receiving, from a user, a consent associated with a function; activating to allow that function to be executed; when a request from the user to use another function is received, determining that the another function requires an associated consent to activate; determining that there is no consent from the user associated with the another function; prompting for a consent associated with the another function; receiving the consent associated with another function; and activating to allow the another function to be executed.