Onetrust, LLC

Vmware, Inc.

Sharath Chandra Chavva

Jonathan Blake Brannon

Patrick Whitney

Jeffrey Baucom

Kevin Jones

Mithun Babu

Amit Kumar Yadav

Ali Mohsin

Nischit Shetty

Sanjay Satagopan

Ujwal Naik

Soorya Rajasoorya

Nikhil Mehta

Nidhi Aggarwal

Ryan Turner

Embodiments of the present invention provide methods, apparatus, systems, computing devices, computing entities, and/or the like for permitting or blocking tracking tools used through webpages. In particular embodiments, the method involves: scanning a webpage to identify a tracking tool configured for processing personal data; determining a data destination location that is associated with the tracking tool; and generating program code configured to: determine a location associated with a user who is associated with a rendering of the webpage; determine a prohibited data destination location based on the location associated with the user; determine that the data destination location associated with the tracking tool is not the prohibited data destination location; and responsive to the data destination location associated with the tracking tool not being the prohibited data destination location, permit the tracking tool to execute.

Systems and methods for automatically blocking the use of tracking tools

Various aspects involve forgoing updates to consent data for at least one consent rejection generated by an automated consent rejection tool. For instance, a consent management system can be communicatively coupled to a user device. The user device can detect invocations of a consent rejection function, such as when browser states of a browser application indicate requests for web pages or other online content. The consent management system can document a consent rejection for one or more of the invocations. The consent management system can also prevent documentation of consent being rejected for at least one invocation initiated by an automated consent rejection tool.

Data processing systems and methods for preventing execution of an action documenting a consent rejection

Systems and methods are disclosed detecting whether calls to consent rejection functions originate with an automated tool or a human user. The system can determine that a calls to a consent rejection function are likely from an automated tool by determining that a rate and/or number of calls to a function exceeds a threshold and/or that the calls are received before the interface requesting user consent preferences has been rendered to the user. The system can also require that a function call include a token that an automated tool would not have knowledge of or access to and reject function calls without this token. The system can also use private consent rejection function calls with obfuscated names and/or provide a follow up consent rejections confirmation interface requiring human user input before process a consent rejection.

Data processing systems and methods for detecting tools for the automatic blocking of consent requests

In particular embodiments, a consent conversion optimization system is configured to test two or more test consent interfaces against one another to determine which of the two or more consent interfaces results in a higher conversion percentage (e.g., to determine which of the two or more interfaces lead to a higher number of end users and/or data subjects providing a requested level of consent for the creation, storage and use or cookies by a particular website). The system may, for example, analyze end user interaction with each particular test consent interface to determine which of the two or more user interfaces: (1) result in a higher incidence of a desired level of provided consent; (2) are easier to use by the end users and/or data subjects (e.g., take less time to complete, require a fewer number of clicks, etc.); (3) etc.

Consent conversion optimization systems and related methods

A portal application can receive a listing of available applications in response to a request sent to a management server. The listing can include a plurality of attributes for each available application, such as the requirements for using the features of each application or a dependency upon another application. Based on the plurality of attributes received, the portal application can determine that a first application requires installation of a second application in order for the first application to provide additional functionality. The portal application can display icons corresponding to the available applications and display one or more UI elements, indicating that the first application requires installation of the second application. The portal application can also push the second application to the device and assist in installing and initializing the second application on the device.

Identifying and displaying application dependencies

Growing community of inventors

Atlanta, GA, United States of America

Sharath Chandra Chavva