(19)Fresh off Patent
(45) Week of Oct 19, 2026 No. 7 3,667 lapsed 70 listed
Cybersecurity & privacy · lapsed Sep 9, 2026

Policy-driven app-risk enforcement for managed mobile devices

A server-side service collects an installed-app list from a managed mobile device, maps each app to a stored risk score, compares those scores to a highest-allowed risk derived from the user’s profile (job/pay/access level or recent incident history), and notifies the device or administrator to remove apps that exceed the allowed risk. Enterprises or mobile-device-management teams use it to enforce application policies on employee devices.

Sheet 1 of the patent drawingsSheet 2 of the patent drawingsSheet 3 of the patent drawings

(57) What the patent covered

This write-up was generated by AI from the patent's text and may contain mistakes, so check it against the original patent before relying on it.

The independent claim required: receiving a list of apps from a user device; obtaining stored application profiles that each provide a risk level (first scores) for those apps; retrieving a user profile that contains job/pay level, access privileges, or security-incident history; computing a highest permitted risk (second score) from the user profile; comparing each app’s first score to the second score; and transmitting a notification to remove apps whose risk exceeds the permitted level.

Distinguishing feature: Combining per-application risk scores with a user-specific highest-permitted-risk computed from job/pay/access/incident history and enforcing removals.

Novelty 3/5. Per-app reputation or enterprise MDM blocking was already common; the patent’s novelty is the specific mapping from user job/pay/access/incident-derived threshold to per-app risk enforcement.

Implementation

A small team would deploy an agent on iOS/Android to report installed packages via an authenticated API to a cloud service; build a backend service that stores user profiles and an app-risk table (hash keyed by package name/bundle id) and a policy engine that computes an allowed-risk threshold from user attributes; run scheduled or on-demand comparisons and push removal or quarantine commands via existing MDM APIs or send user notifications prompting uninstall.

Components: Managed mobile device agent (MDM/agent), server with user-profile and app-risk database, API and push/notification channel to device (e.g., APNs/FCM), policy engine that computes allowed-risk threshold.

Buildability 5/5. The main work is collecting reliable app-risk data and integrating with device management APIs; engineering, not hardware, is required.

Market demand

Comparable products exist; none doing exactly this was found. Several vendors offer app-reputation and threat-detection signals integrated with MDM/EMM to enforce application policies; the market includes Trellix MTD, Ivanti App Reputation, and Appdome’s identity/reputation capabilities, indicating an active, growing segment around mobile app risk management for managed devices.

Demand check by web search, week of Oct 12, 2026. Listings change frequently.

Buyers: Enterprise IT / mobile-device-management teams.

Before manufacturing

No related continuation or divisional patents in force were found. Design patents, trademarks and unrelated patents may still cover the product.

Practical risks include accuracy and freshness of app-risk scores, integration limits of platform MDM APIs, user privacy and consent requirements, and a crowded existing market of MDM and app-reputation vendors.

About 1.5% of lapsed patents are later revived by their owners. This page is a research lead, not legal advice. Obtain a freedom-to-operate opinion before manufacturing.

Claim 1, as granted

1. A method, comprising: receiving, by a server device, an instruction to determine whether a user device has stored an unauthorized application; obtaining, from the user device and as a result of the instruction, a list of one or more applications that are stored on the user device; obtaining, by the server device, one or more application profiles associated with the list of one or more applications, where each of the one or more application profiles identify a respective level of risk associated with each of the one or more applications of the list; obtaining, by the server device, a plurality of first scores that are associated with the respective level of risk associated with the one or more applications; retrieving, from a memory associated with the server device, a user profile associated with a user of the user device, where the user profile identifies at least one of: a job level associated with a job held by the user, a privilege level of the user for accessing confidential information, or a usage history for identifying whether the user has been associated with a security incident within a period of time before receiving the instruction; identifying, by the server device, a highest level of risk that is authorized for the one or more applications of the list based on the job level, the privilege level, or the usage history; generating, by the server device, a second score that corresponds to the highest level of risk associated with the one or more applications; determining, by the server device, whether a level of risk, associated with an application, of the one or more applications of the list, is greater than the identified highest level of risk, based on a comparison of one of the plurality of first scores and the second score; and transmitting, to the user device, a notification that the application is not authorized to be stored on the user device when the level of risk is greater than the identified highest level of risk.