Privacy manager for connected TV application and over the top application

Abstract

To provide a system for processing privacy acceptance of a consumer with using a vendor application.SOLUTION: A system according to the present invention allows a consent transaction executed by a user as a data subject to be recorded, stored and acquired in a data schema. When receiving a request for acquiring subject data, the system uses IDs with hash values generated through generation of subject IDs obtained by hashing an organization ID associated with a vendor or an application and an identification value associated with the subject. The subject ID, the organization ID, and a schema ID of the schema associated with the subject are hashed to generate the subject data ID. Subsequently, the subject data ID is used to acquire the consent transaction and acceptance associated with the subject.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 092,961, filed October 16, 2021, which is incorporated herein by reference in its entirety. [Background technology]

[0002] The field of the invention is protecting consumer privacy in compliance with privacy regulations for publishers of connected TV (CTV) and over-the-top (OTT) applications. Under privacy laws and regulations, such as the California Consumer Privacy Act (CCPA) and the General Data Protection Regulation (GDPR), publishers of CTV and OTT applications are required to comply with the same information (notice) and choice (opt-in / opt-out) requirements as web and mobile applications. However, the mechanisms used to protect consumer privacy in mobile and web applications do not work for CTV and OTT applications.

[0003] Regulators around the world are working on stricter privacy regulations, with the CCPA and GDPR now in place and more expected to be implemented in the future. At the same time, browsers and other software are eliminating third-party cookie mechanisms, making it more difficult to manage preferences in any shape or form. Companies attempt to provide the best digital services to end users using a myriad of technologies and segregated data flows, while struggling to navigate a patchwork of different regulations and technological changes. Managing preferences and consent at the consumer level and correctly processing personal data is becoming, and will continue to become, increasingly difficult.

[0004] Due to technical constraints, CTV and OTT services have either stopped using data processing to improve their service features and provide them to their partners, or implemented non-compliant consent solutions. Both the CCPA (California Consumer Privacy Act) and the GDPR (General Data Protection Regulation), in their context, require consumers or data subjects to be provided with information before or at the time of data collection. Additionally, these laws provide consumers and data subjects with the right to opt out or consent before their data is processed and / or distributed. CTV and OTT applications cannot store information on the device itself (i.e., there are no cookies) and therefore must store all information server-side based on device ID or a user ID tied to the device ID. While many technologies have been developed to help service providers comply with privacy regulations in the case of web and mobile applications, these types of technologies do not work for CTV and OTT applications. Therefore, new technologies are needed to provide consent configuration and opt-out or consent string generation for CTV and OTT applications to certify their compliance with privacy regulations and to offer these capabilities to downstream partners.

[0005] The references mentioned in this background section are not admitted to be prior art with respect to the present invention. Summary of the Invention

[0006] The present invention is directed to a system and method for managing consumer privacy (e.g., in CTV and OTT applications) that enables a provider server or servers to record consent transactions conducted by users (sometimes referred to as "data subjects") and store all information necessary to demonstrate compliance with privacy regulations governing the collection and use of consumer information in online environments. Generally, consent transactions facilitated by the present system and method result in a set of values ​​stored for the data subject, which can later be recalled via a dedicated endpoint. These values ​​are determined by fields in the data schema modified by each consent section and can include user preferences (e.g., newsletters, profiling, etc.). In this regard, the present system and method functions as a consent and preference management solution operated remotely from the provider server, particularly suitable for CTV and OTT applications. In certain embodiments, the present system and method provides a central repository for selective curation, logging, and distribution of longitudinal customer preference records across an enterprise's data assets and vendor relationships. These embodiments of the present invention provide consumers with a single, easy-to-use preference or trust center user interface for easily collecting preferences, with features focused on application compliance with privacy regulations. Embodiments further enable maintaining a single user-level view of consumer preferences across data collection points, integrating data schemes or vendor accounts for downstream persistence of user preferences, and programmatic or manual retrieval of user preferences based on a given identifier within a given schema. Finally, embodiments also enable control over which vendors have access to which specific preference attributes within a particular data section.

[0007] Privacy and compliance regulations are rapidly evolving and growing in scope and complexity. Consumers have come to expect a high level of transparency and control over their user data, and if companies fail to properly address consumer privacy, they risk customer churn and significant fines. Certain embodiments of the present invention provide a technical solution for maintaining consumer privacy in CTV and OTT applications, ultimately enabling the creation and management of user data and privacy-related versions of various types of user content. The systems and methods of the present invention provide a technical solution useful for seamlessly and compliantly managing customer consents and preferences across systems for all of a company's associated data sets.

[0008] This technical improvement is particularly well-suited for such applications because it enables companies to generate and store consents for data subjects based on a company-provided deterministic identifier. The consents are stored server-side, can be verified for rigor, accuracy, fidelity, and appropriateness, and can be retrieved by companies and their downstream partners to comply with consenting data subjects. The systems and methods of the present invention provide application programming interface (API) endpoints for applications to communicate consumer or data subject selections and interface with server-side APIs to validate and generate the necessary consent information and pull the consent information back into the application.

[0009] The systems and methods of the present invention provide a technical solution that enables organizations to manage consents and preferences through server-to-server integration. This solution enables integration with identity providers to establish data subject identities, which in certain embodiments can store data subject information related to hashed IDs (MIDs) or email addresses. Furthermore, these embodiments enable connecting consents and preferences to hashed user IDs that can be integrated with identity provider solutions, storing consents for multiple types of data categories, and synchronizing and updating preferences across organizations.

[0010] These and other features, objects and advantages of the present invention will be better understood from the following detailed description of the preferred embodiment, considered in conjunction with the drawings described below. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a schematic diagram illustrating an embodiment of a method for storing subject data, according to an embodiment of the present invention; [Figure 2] 1 is a schematic diagram illustrating an embodiment of a method for obtaining subject data, according to an embodiment of the present invention. [Figure 3] FIG. 4 is a schematic diagram illustrating an embodiment of a method for obtaining subject data, according to another embodiment of the present invention. [Figure 4] FIG. 2 is a schematic diagram illustrating an example of a schema structure and architecture, according to an embodiment of the present invention. [Figure 5] FIG. 1 is a schematic diagram illustrating an example of an architecture for storing subject data using a vendor key, according to an embodiment of the present invention. [Figure 6] 1 is a schematic diagram illustrating one way for integrating the system and method of the present invention into a CTV application, according to one embodiment of the present invention. [Figure 7-1] FIG. 2 illustrates an example of a schema table according to one embodiment of the systems and methods of this invention. [Figure 7-2] FIG. 2 illustrates an example of a schema table according to one embodiment of the systems and methods of this invention. [Figure 8] FIG. 2 shows an example of a subject table in accordance with one embodiment of the systems and methods of the present invention. [Figure 9] FIG. 2 illustrates an example of a subject data table according to one embodiment of the systems and methods of the present invention. [Figure 10] FIG. 2 illustrates an example transaction database table according to one embodiment of the systems and methods of this invention. [Figure 11] FIG. 2 illustrates an example of a schema integration table, in accordance with one embodiment of the systems and methods of this invention. [Figure 12] FIG. 1 illustrates an embodiment of a system of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0012] Before describing the present invention in further detail, it should be understood that the present invention is not limited to the specific embodiments described in any section of this specification, and that the terminology used in describing specific embodiments is for the purpose of describing those specific embodiments only, and is not intended to be limiting, since the scope of the present invention will be limited only by the claims of any subsequent non-provisional patent application.

[0013] The present invention is directed to a system and method for managing consumer privacy by a company or service provider (referred to herein as a "provider"; the present invention may be particularly suitable where the provider offers CTV and OTT applications), which enables recording consent transactions performed by users (sometimes referred to as "data subjects"), makes user preferences persistently available for providing them to the provider's downstream partners (sometimes referred to herein as "vendors"), and stores all information necessary to demonstrate compliance with privacy regulations governing the collection and use of consumer information in technology environments. The system and method of the present invention provides a technical solution utilizing a central repository for selective curation, logging, and distribution of long-term records of data subject consents and preferences across the provider's data assets and vendor relationships. The technical solution enables maintaining a single customer view across data collection points regarding consumer preferences, persistence of user preferences downstream, programmatic retrieval of user preferences, and downstream vendor access to control consent and preference status.

[0014] Before providing more specific information about the components and functionality of the technical solution provided by the system and method of the present invention, it is necessary to describe the entities involved in the technical transaction. As mentioned above, the system and method of the present invention are particularly well-suited for interactions between consumers and service providers, where the consumer is sometimes referred to as the "data subject" and the service provider as the "provider." Data subjects require a clear way to opt out or consent to the processing or collection of their personal information based on information provided by the issuer (this is sometimes referred to as a "notice" requirement). Similarly, data subjects in these technological environments must also be able to change their specific preferences from a particular brand or partner before or at the time of data collection. Finally, these data subjects must also be able to adjust their choices and preferences at a later point in time. In short, a data subject is someone about whom personal data may be collected and typically corresponds to a user of a provider's platform or application. Personal information that may be collected about a data subject may include, for example, the data subject's email address, phone number, customer relationship management identifier (CRM ID), or other similar data. A data subject most commonly relates to a user of a provider, but a data subject could also be a device, a company, or an account.

[0015] Providers, on the other hand, must be able to register various forms of consent and preferences of data subjects in static / deterministic identifiers managed by the provider. Providers must also be able to access the registered information via authorized access key management, determine the data subject information that can be accessed by downstream vendors based on consent and preference settings, and honor and comply with opt-out requests received directly from data subjects. Furthermore, providers must provide valid transparency consent strings (TC strings) to their partners to enable messaging on the provider platform.

[0016] As previously mentioned, central to the system and method of the present invention are consent transactions, which represent individual consent events recorded when a data subject provides consent. Each consent transaction contains all information necessary to uniquely identify a particular consent transaction as determined by the schema. For example, a consent transaction includes data such as the identity of the person who performed the consent transaction, the preferences expressed in that consent, legal notices accepted by the data subject, proof of consent (e.g., a form presented to the user), and other similar information related to the consent transaction. Consent transactions can be written and read, but cannot be modified once they exist. Instead, consent transactions represent a history of consents provided by a data subject; thus, a new consent transaction can be performed to modify a data subject's existing consent preferences, while previous consent transactions with their original preferences remain available in history.

[0017] As mentioned above, a data subject represents an entity (e.g., an individual, a device, a company, an account, etc.) about which data is collected and processed by a provider. The data structure associated with a data subject is defined by a schema, preferably using the JSON data format. An example data structure for a data subject named "John Doe" is shown below:

number

[0018] FIG. 1 illustrates one embodiment of a method for storing subject data using a vendor access key. As shown, the process begins in step 10 with input of an identification field, a subject data payload, and a vendor key. A schema validation is performed (12), and then the organization ID and identification value are hashed (14) to determine a subject ID 16 associated with the input data. The system then determines (18) whether the subject ID exists in the subject database; if not, a new subject ID is created (20). Once the subject ID is created (or the determined subject ID matches an existing subject ID), the subject data 22 associated with the subject ID can be stored, the subject data can be associated with the subject's consent transactions 24, and notifications can be sent according to the subject's preferences and consent transactions (26).

[0019] One embodiment of a method for retrieving subject data using a vendor access key is provided in Figure 2. As shown, the process begins with inputting (28) an identification field (having an identification value) and a vendor key (associated with an organization ID). A hash function is applied (30) to the identification value and the organization ID to determine a subject ID 16. Once the subject ID 16 is determined, the subject data can be retrieved (32) by matching the subject ID with the subject data associated with that subject ID in a database of subject IDs 16 and a database of subject data 22.

[0020] Transaction data can be retrieved from a transaction database, and in one embodiment, this is done using the process shown in Figure 3. The process begins with inputting an identification field (having an identification value) and an organizational key (34). In one embodiment, an optional schema ID can also be provided. The identification value is then hashed (36) to determine a subject ID 16. The subject ID 16 can then be used to retrieve data for the associated data subject (32), which in turn can retrieve transactions 24 associated with the particular data subject.

[0021] Figure 5 shows the process for applying the save / reject function (90) to a subject using inputs as identification fields, a vendor key, and a Privacy Manager application ID. The latest vendor list is retrieved (92) and the Privacy Manager configuration is retrieved (94). From this data, a transaction consent string (TC string) or data can be created (96) and the subject data can be saved using the vendor key (98).

[0022] Access to data associated with an organization is determined by a console access management system. In one embodiment, a single administrative privilege is manually assigned to a given console user. Any console user with administrative privileges can manage access keys for an organization. Access keys are how requests sent to the system are authorized; authorization determines whether a client can access system resources. Depending on the action being performed, one of two types of authorization keys must be provided. First, application programming interface (API) authorization is implemented as hypertext transfer protocol (HTTP) basic authentication over transport layer security (TLS) (HTTP Secure or HTTPS). API keys can be obtained from the console user interface (UI), and connections to the API can be established using TLS 1.2 (or higher). One of the most common calls clients make through the API is to post or retrieve subject data. A simple way to authenticate is to use an organization API key or a vendor API key, depending on the situation. The vendor API key may be used, for example, to store and retrieve subject data, and the organization API key may be used to manage organization resources.

[0023] In a preferred embodiment of the system and method of the present invention for storing and retrieving subject data, a vendor key 130 must be provided. A console user with administrator privileges can generate a vendor key 130 within an integration and then use that vendor key 130 in the header when sending a request. It is important to note that each write and read operation impacts computational costs. Organization API keys, on the other hand, are keys used by organizations to access and manage their data and resources outside of the console application. Organization API keys can be used to create and list schemas, manage data fields, add and modify integrations, retrieve subject or transaction data, and so on. However, they do not grant permission to create and store subject data or to create new organization keys. Organization keys are created through the console application, and there is no limit to the number of organization keys that can be created. Organization keys never expire and remain valid and usable until they are deleted.

[0024] Referring to FIG. 6, consent and access for an end user 100 is illustrated. In this example, the system is a CTV system. A publisher CTV app 102 is accessed by the end user 100, and the publisher CTV app 102 presents a sign-in or sign-up interface (104). An option to proceed without registration may also be provided. The system checks for local consent (106) using data from a publisher service consent store 108. If the result is no at decision block 110 for consent presence, processing proceeds to consent screen 112, indicating that consent was not provided. If consent is provided, decision block 114 determines whether consent is appropriate as measured by the system. Appropriateness may be tested using an appropriateness adapter 116, which applies the method described below using the consent string. If consent is not appropriate, processing returns to consent screen 112, indicating that consent was not appropriate. If consent is found to be appropriate, CTV access is provided (118).

[0025] In the systems and methods of the present invention, data is structured using a data schema, such as that shown in Figure 4. The data schema is defined via an API or user interface and has the following properties: (a) Name—the name of the schema; (b) Purpose—used to log the purpose for which transaction data is processed; (c) Legal Basis—used to log the legal basis for which transaction data is processed; and (d) Data Fields—used for structure and data validation. Data schema templates may be used to pre-configure data schemas for specific purposes and uses. The templates may include, for example, the purpose, legal basis, and data fields of the data schema.

[0026] Data fields are used to structure data and validate it and should be predetermined via an API or user interface. Data fields have the following properties: (a) name—the name of the data field; (b) type—the type of data stored in the data field; (c) description—a description of the data stored in the data field; (d) category—the data category of the data stored in the data field; and (e) validator—used to validate the data stored in the data field. Public data fields are preconfigured data fields that already have a data category, type, and validator. The systems and methods of the present invention utilize a schema database to contain data schemas and data fields (including public data fields).

[0027] The schema table and the subject table are connected to the Schema API. An exemplary schema table 38 is shown in FIG. 9. The schema database (e.g., a NoSQL database) includes a data schema, data fields, and public data fields. The subject table includes a mapping from subject IDs to subject data IDs. In situations where fast response times are required (e.g., a get subject data request, described in more detail below), the organization function queries the cache layer or cluster; if the query is not cached, the query is executed against a database (e.g., a non-relational or NoSQL database). The subject ID is a hash of the organization ID and an identification field, and the subject data ID is a hash of the subject ID, organization ID, and schema ID.

[0028] An exemplary subject table 40 is shown in FIG. 8. The subject data table contains the latest state of the subject data. Because this data requires fast response times, a caching layer is placed in front of the subject table to optimize performance. An exemplary subject data table 42 is shown in FIG. 11. Fields included in the subject data table may include, for example, (a) a data field containing the subject data; (b) an expiration date indicating the expiration date after which the subject data will be deleted; (c) an id field providing the subject data ID (a hash of the subject ID, organization ID, and schema ID); (d) a notification configuration field for configuring notifications for data change webhooks and identifying which data fields to pass in the webhook; (e) a notification URL field identifying the destination endpoint for the notification webhook; (f) an organization ID field that is a unique ID for the customer's organization; (g) a schema ID field that is a unique ID for the data schema; (h) a subject ID field that is a hash of the organization ID and identification fields; and (i) a timestamp field.

[0029] As described above, transactions are stored in a transaction database 24 so that historical transactions can be retrieved. The transaction database may include a data table having the following fields: (a) a data field containing the subject data; (b) an expiration date field indicating the expiration date after which the subject data will be deleted; (c) an ID field identifying the subject data ID (a hash of the subject ID, organization ID, and schema ID); (d) an organization ID field that is a unique ID for the customer's organization; (e) a schema ID field that is a unique ID for the data schema; (f) a subject ID field that is a hash of the organization ID and identification fields; and (g) a timestamp field that is a timestamp. An exemplary transaction database table 44 is shown in FIG. 10.

[0030] An integration table 122 (FIG. 4) is utilized to store access keys and permissions per vendor and per schema. The integration table 122 may include, among other items, the following fields: (a) an ID field, which is a unique ID assigned to the integration and also serves as the vendor API key; (b) a name field, which is the integration name; (c) an organization ID field 126, which is a unique ID for the customer's organization; (d) a read access field, which provides read access; (e) a schema ID field 128, which is a unique ID for the data schema; (f) a subscription ID field, which is a unique ID for the customer's subscription; (g) a vendor ID field 124, which is a unique ID for the vendor assigned to the integration; and (h) a write access field, which provides write access. An exemplary integration table 46 is shown in FIGS. 7-1 and 7-2. Each schema is associated with, potentially, multiple vendor keys 130. Functions that can be invoked within the API include organizational functions that assist in managing data fields, public data fields, data schemas, schema templates, and the like. Other features allow creating schemas from schema templates with predefined values, retrieving all schema properties for a given schema, etc. The integration API includes organizational key management and key management per schema. Each schema integration represents an API key (vendor key), and customers can control access rights per key. Notification webhooks can be configured per integration. Consent transactions are sent in batches via the API or directly via an adapter. Calls to the system include the API key and identification fields, which allow checking the validity of the schema and managing the transaction.Functions that operate within the Integration API include functions for managing organization keys (organization keys are used to manage data across schemas and should not be shared outside of an organization), for managing vendors (vendors have an ID, name, and description and are assigned by integration level to track which vendors have access to schemas), for managing integrations (schema integration represents access to a given vendor's schema), and for managing schema integration keys.

[0031] The Subject Data API includes functions operable to (a) generate a subject ID by hashing identification fields, (b) store the subject ID in the subject table and the subject data ID in the subject data table, (c) execute a process to retrieve subject data, (d) delete subject data from the subject data table and the transaction table, (e) add additional identification fields that map to the subject ID, (f) send a billing event to a message queue, (g) retrieve all historical transaction data from the transaction table, and (h) process the API key and return an access policy message. Finally, the API functions invoked through the infrastructure endpoints include functions for retrieving subject data and storing the subject data in the transaction database, and for sending a billing event.

[0032] Generally, the above can be described with reference to specific hardware components and systems. In a preferred embodiment, the systems and methods of the present invention are cloud-based and rely on managed services (such as AWS managed services offered by Amazon). The core infrastructure may utilize the following services: NoSQL databases, NoSQL database caching layers, relational databases, message queues, APIs, serverless computing services, authentication, authorization, and user management services, and event-based billing system services.

[0033] Having described the various components of the system of the present invention, one example of how the present invention can be used to create a subject can be described with reference to Figure 12. As shown, the process begins with receiving a request from a vendor 48 at a vendor API gateway 50, which invokes an authorizer function 52. The request to create a subject can take the following form in one example:

number

[0034] The authorizer function 52 retrieves the API value key ("apiKey") from the event header, and if the API key value is null or undefined, a denial policy message is returned. In the authorization cache layer 54, a query is performed to look up the API key in a schema integration table. If it is not cached, a query is performed in the authorization key database 56, which is a NoSQL database. If the API key is not found, a denial policy message is returned. Otherwise, the system matches the type and integration of the request from the query result with the permissions. If the request is not authorized, a denial policy message is returned. A context object is created using the integration properties organization ID, integration ID, subscription ID, schema ID, notification configuration, and notification URL. An authorization policy message is returned along with the context object.

[0035] At this stage, the vendor API gateway 50 invokes the subject creation function object (which includes properties from the previous authorizer context object). The system checks whether the event object includes an organization ID and returns an error message if it does not. The system then checks whether the event object includes a subscription ID and returns an error message if it does not. The message is then sent to the messaging queue 60 for processing by the billing event send function 62. The system also checks whether the request body contains valid JSON and returns an error message if it does not. The schema ID is retrieved from the event context object in the schema API 64. The schema ID and organization ID are used to retrieve the schema from the schema table. If the schema is not found, an error message is displayed. The request body is then checked for identification field properties, and if the request body does not include identification field properties, a random unique identifier (UUID) is generated. The request body is then validated against the schema definition and, if not valid, an error message is returned. If valid, a subject ID is created by hashing the identification value and organization ID, and the subject ID is applied to the subject ID mapping database 68 via the schema cache layer 66. The subject ID can then be used to retrieve the subject from the subject table via the subject data API 70, the subject cache layer 72, and the subject database 74. If the principal is not found, the principal is saved as a new principal in the subject database 74. An expiration date can then be calculated, and the subject ID, organization ID, and schema ID are hashed to obtain a unique subject data ID in the subject ID mapping database 68. The subject data is saved, overwriting any existing subject data. If the create subject function reaches this stage, it is considered successful, and a success status response is returned along with the subject data. Otherwise, an error response is returned.

[0036] A similar process can be used to retrieve subject data using the get subject data function. The API gateway 50 receives the request and invokes the authorizer function 52, passing an event object. An exemplary request message to retrieve subject data can take the following form: GET https: / / api.preferencelink.com / data-api / subjects / identifying-values / test-subject@email.com apiKey:e6a8f345-2253-4796-a9f8-e85490b34816

[0037] The integration API 58 retrieves the API key value from the event header and returns a reject policy message if the value is null or undefined. If the API key is successfully retrieved, a query is performed to look up the API key in the schema integration table in the schema database 76. If the API key is not found in the schema integration table, a reject policy message is returned. Otherwise, the system matches the type and integration of the request (from the query result) with the permissions. If there is no permission for the request, a reject policy message is returned. Otherwise, the system creates a context object using the integration properties, namely, organization ID, integration ID, subscription ID, schema ID, notification configuration, and notification URL. An allow policy message is returned to the API gateway 50 along with the context object.

[0038] At this stage, the vendor API gateway 50 invokes the get subject data function, passing the event object (which contains properties from the previous authorizer context object). The get subject data function checks whether the event object contains an organization ID, and if it does not, returns an error message. If it does, the system checks whether the event object contains a subscription ID (e.g., from a billing system), and if it does not, returns an error message. If it does contain a subscription ID, the message is sent via the messaging queue 60 to be processed by the send billing event function 62. Next, the identification value is obtained from the header, and a validation check is set in the API gateway 50 on this identification value; therefore, the identification value cannot be null. A hash function is applied to the identification value and the organization ID to obtain the subject ID. A get item operation is performed on the subject table to obtain the subject using the subject ID. If the subject is not found in the subject table, a message is returned indicating that the subject does not exist. If the subject is found, the schema ID is retrieved from the event context object and a hash is applied to the subject ID, organization ID, and schema ID to create a unique subject data ID. The system then uses the subject data ID to perform a get subject data operation in the NoSQL database. If the subject data does not exist, a message is returned indicating that the subject data was not found. Otherwise, a subject data DTO (data transfer out) object is created, a success message is returned, and the subject data is transferred.

[0039] Currently, based on known identification fields for a subject (such as the subject's email, phone number, etc.), consent and authorization records for the subject corresponding to those identification fields can be created, and such records can later be accessed (or overwritten) to determine whether a subject associated with some identification field has granted consent to a particular organization or vendor. In this regard, when a user logs into an organization or vendor application (such as a CTV application) and provides some identification field, the system can retrieve the consent records and consent transactions associated with the subject to determine consent and authorization.

[0040] The system allows data to be stored in the transaction database 24 via a transaction data storage service 78, and webhooks may be sent via a webhook sending service 80, allowing real-time status and updates to exit the system. Customer 82 access to the system is achieved through an administrative UI 84. As previously mentioned, this UI allows access to the system via two APIs: administrative API authentication 86 and administrative API gateway 88.

[0041] In the implementations described herein and various alternative implementations, the invention may be implemented by any combination of hardware and software. For example, in one embodiment, the systems and methods may be implemented by a computer system or collection of computer systems, each of which includes one or more processors that execute program instructions stored on a computer-readable storage medium coupled to the processors. The program instructions may perform the functions described herein. The various systems and displays depicted in the figures and described herein represent example implementations. The order of any methods may be changed, and various elements may be added, modified, or omitted.

[0042] The computing system or computing device described herein may implement the hardware portion of a cloud computing system or a non-cloud computing system, forming part of various implementations of the present invention. The computing system may be any of various types of devices, including, but not limited to, a general-purpose server, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a handheld computer, a workstation, a network computer, a consumer device, an application server, a storage device, a telephone, a mobile phone, or generally any type of computing node, computational node, computational device, and / or computing device. The computing system includes one or more processors (any processor may include multiple processing cores, which may be single-threaded or multi-threaded) coupled to system memory via input / output (I / O) interfaces. The computing system may further include a network interface coupled to the I / O interfaces.

[0043] In various embodiments, the computer system may be a uniprocessor system including one processor or a multiprocessor system including multiple processors. The processor may be any suitable processor capable of executing computational instructions. For example, in various embodiments, the processor may be a general-purpose processor or an embedded processor implementing any of a variety of instruction set architectures. In a multiprocessor system, each of the processors may generally, but need not, implement the same instruction set. The computer system also includes one or more network communication devices (e.g., network interfaces) for communicating with other systems and / or components over a communications network, such as a local area network, a wide area network, or the Internet. For example, a client application executing on a computing device may use the network interface to communicate with a server application executing on a single server or a cluster of servers implementing one or more of the components of the systems described herein in a cloud computing environment or a non-cloud computing environment, such as those implemented in various subsystems. In another example, an instance of a server application executing on a computer system may use the network interface to communicate with other instances of the application, which may be implemented on other computer systems.

[0044] A computing device also includes one or more persistent storage devices and / or one or more I / O devices. In various embodiments, the persistent storage device may correspond to a disk drive, a tape drive, solid-state memory, other mass storage device, or any other persistent storage device. A computer system (or a distributed application or operating system running on the computer system) may store instructions and / or data to the persistent storage device as desired and retrieve the stored instructions and / or data as needed. For example, in some embodiments, a computer system may implement one or more nodes of a control plane or control system, and the persistent storage device may include SSDs attached to the server nodes. Multiple computer systems may share the same persistent storage device or may share a pool of persistent storage devices, where the devices in the pool represent the same or different storage technologies.

[0045] A computer system includes one or more system memories capable of storing code / instructions and data accessible by a processor. System memory may include, for example, multiple levels of memory and memory caches within the system, designed to swap information within memory based on access speed. Interleaving and swapping may also extend to persistent storage in virtual memory implementations. Technologies used to implement memory may include, by way of example, static random-access memory (RAM), dynamic RAM, read-only memory (ROM), nonvolatile memory, or flash memory. Similar to persistent storage, multiple computer systems may share the same system memory or may share a pool of system memory. One or more system memories may store program instructions executable by the processor to implement the routines described herein. In various embodiments, the program instructions may be coded in binary, assembly language, any interpreted language such as Java, a compiled language such as C / C++, or any combination thereof; the specific languages ​​shown herein are merely examples. In some embodiments, the program instructions may implement multiple separate client, server nodes, and / or other components.

[0046] In some implementations, the program instructions may include executable instructions to implement an operating system (not shown), which may be any of a variety of operating systems, such as UNIX, LINUX, Solaris, MacOS, or Microsoft Windows. Any or all of the program instructions may be provided as a computer program product or software, which may include a non-transitory computer-readable storage medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to various implementations. A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). Generally speaking, a non-transitory computer-accessible medium may include a computer-readable storage medium or memory medium, such as a magnetic or optical medium, e.g., a disk or DVD / CD-ROM coupled to a computer system via an I / O interface. Non-transitory computer-readable storage media may also include any volatile or non-volatile media, such as RAM or ROM, that may be included as system memory or another type of memory in some embodiments of a computer system. In other implementations, program instructions may be communicated using optical, acoustic, or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) conveyed over a communications medium, such as a network and / or a wired or wireless link, as may be implemented via a network interface. The network interface may be used to interface with other devices, which may include other computer systems or any type of external electronic device.In general, system memory, persistent storage, and / or remote storage on other devices accessible over a network may store data blocks, replicas of data blocks, metadata associated with the data blocks and / or the state of the data blocks, database configuration information, and / or any other information usable in performing the routines described herein.

[0047] In particular implementations, the I / O interface may coordinate I / O traffic between the processor, system memory, and any peripheral devices in the system, including those via a network interface or other peripheral interface. In some embodiments, the I / O interface may perform any necessary protocol conversion, timing conversion, or other data conversion to convert data signals from one component (e.g., system memory) into a format suitable for use by another component (e.g., processor). In some embodiments, the I / O interface may include support for devices attached via various types of peripheral buses, such as variations of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. Also, in some embodiments, some or all of the functionality of the I / O interface, such as the interface to system memory, may be incorporated directly within the processor.

[0048] A network interface may, for example, enable data exchange between the computer and other devices attached to the network, such as other computer systems (which may implement server nodes, primary nodes, read-only nodes of one or more storage systems, and / or clients of the database systems described herein). Additionally, an I / O interface may enable communication between the computer system and various I / O devices and / or remote storage devices. In some embodiments, the input / output devices may include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for inputting or retrieving data by one or more computer systems. An input / output device may be directly connected to a particular computer system or may generally connect to multiple computer systems in a cloud computing environment, a grid computing environment, or other system including multiple computer systems. Multiple input / output devices may be in communication with the computer system or may be distributed among various nodes of a distributed system including the computer system. The user interfaces described herein may be visible to a user using various types of display screens, which may include CRT displays, LCD displays, LED displays, and other display technologies. In some implementations, input may be received through a display using touchscreen technology, while in other implementations, input may be received through a keyboard, mouse, touchpad, or other input technology, or any combination of these technologies.

[0049] In some embodiments, similar input / output devices may be separate from the computer system and may interact with one or more nodes of a distributed system that includes the computer system via a wired or wireless connection, such as a network interface. The network interface may generally support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11 or another wireless networking standard). The network interface may support communication over any suitable wired or wireless general-purpose data network, such as other types of Ethernet networks. Furthermore, the network interface may support communication over a telecommunications / telephony network, such as an analog voice network or a digital fiber communications network, a storage area network, such as a Fibre Channel SAN, or any other suitable type of network and / or protocol.

[0050] Any of the embodiments of the distributed system described herein, or any of the components of the embodiments, may be implemented as one or more network-based services in a cloud computing environment. For example, read-write and / or read-only nodes in a database hierarchy of a database system may present database services and / or other types of data storage services using the distributed storage system described herein to clients as network-based services. In some embodiments, the network-based services may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format, such as the Web Services Description Language (WSDL). Other systems may interact with the network-based service in a manner specified by the network-based service's interface description. For example, a network-based service may define various operations that other systems can invoke and may define specific application programming interfaces (APIs) to which other systems may be expected to conform when requesting the various operations.

[0051] In various embodiments, a network-based service may be requested or invoked by using a message containing parameters and / or data associated with the network-based service request. Such messages may be formatted according to a particular markup language, such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol, such as Simple Object Access Protocol (SOAP). To perform a network-based service request, a client of the network-based service may assemble a message containing the request and communicate the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the web service using an Internet-based application-layer transport protocol, such as Hypertext Transfer Protocol (HTTP). In some embodiments, the network-based service may be implemented using Representational State Transfer (REST) ​​techniques rather than message-based techniques. For example, a network-based service implemented according to REST techniques may be invoked by parameters included within an HTTP method, such as PUT, GET, or DELETE.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the concept of the present invention.

[0053] All terms used herein should be interpreted as broadly as possible in accordance with the context. When groupings are used herein, it is intended to include all individual elements of the group and all possible combinations and subcombinations of the group individually. When ranges are described herein, it is intended that the ranges include all subranges and individual points within the range. All references cited herein are incorporated herein by reference unless they contradict the disclosure of this specification.

Claims

1. 1. A system for managing consents associated with a plurality of consent-activating devices, wherein the consent-activating devices are not capable of storing consent data locally, the system comprising: a vendor API gateway configured to receive a request to create a principal, the request including an API key; an approved API key database; an authorizer configured to communicate with the vendor API gateway, search the API key database, and return a matching context object if the API key in the request is found in the approved API key database; an integration API configured to communicate with the vendor API gateway, obtain a schema identifier (ID), search the schema ID in a schema database, and return an integration identifier (ID) and an organization identifier (ID); a subject identifier (ID) database; a schema application programming interface (API) in communication with the vendor API gateway and the subject identity database, the schema API configured to create a subject identity using the schema ID and an organization ID and apply the subject identity to the subject identity database; a subject data database; a subject data application programming interface (API) in communication with the vendor API gateway and the subject data database, the subject data API configured to search the subject data database and return subjects; and Including, the system.

2. The system of claim 1 , wherein the consent activation device is a connected television (CTV) device.

3. The system of claim 1 , wherein the consent activation device is an over-the-top (OTT) device.

4. 10. The system of claim 1, further comprising: a messaging queue in communication with the subject data API and configured to generate a billing message; and a billing event sending function configured to receive the billing message and generate a billing event to the consent-activating device.

5. 10. The system of claim 1, further comprising a transaction data storage service in communication with the subject data database and the transaction database, the transaction data storage service configured to store a record of each transaction in the system in the transaction database.

6. 10. The system of claim 1, further comprising a webhook transmission service that communicates with the subject data database to transmit status or updates from the system in real time.

Images