Methods and systems to process user consent securely

Abstract

Embodiments include methods, electronic device, storage medium, and computer program for user consent management. In one embodiment, a method comprises: obtaining (402) a consent parameter setting for an application to execute the application on a premises; based on the consent parameter setting, transmitting (404) a consent request for the application to be executed upon a detection of an end user device of the user on the premises; receiving (406) a consent response responsive to the consent request, the consent response including an encrypted combination of a consent identifier of a user and a consent setting for the user; granting (408) a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing (410) the consent setting of the user in a distributed ledger.

Description

METHODS AND SYSTEMS TO PROCESS USER CONSENT SECURELY TECHNICAL FIELD

[0001] Embodiments of the invention relate to the field of networking; and more specifically, to processing user consent securely. BACKGROUND ART

[0002] Many technologies are used to obtain consent from a user of an application or a bystander who is included in the use of an application. The notable examples are the following:

[0003] (1). Digital consent forms. These are forms that can be filled out electronically on a computer or mobile device. They often include electronic signature capabilities and can be stored and retrieved as needed.

[0004] (2). Biometric authentication. This involves using a person’s unique physical characteristics, such as their fingerprint or facial features, to confirm their identity and grant access or consent.

[0005] (3). Interactive voice response (IVR) systems. These are automated systems that interact with users via voice commands and can be used to obtain consent for a variety of purposes.

[0006] (4). Video recording consent. Video recording of consent can be obtained by using cameras and other recording devices.

[0007] (5). Electronic consent management platforms. These are software platforms that can be used to manage consent processes and track user interactions with digital consent forms, biometric authentication, and other consent-related technologies.

[0008] (6). Law compliance technologies. These technologies ensure that an application collecting, storing, and using personal data in compliance with laws like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA), where processing of personal data follows the consent by a user of the application or a bystander who is included in the use of the application.

[0009] The consent is often stored by the user or by the application. For example, cookies may be used to store user consent used in web tracking. Cookies are small text files that are stored on a user’s computer or mobile device, and the storing is performed by a website or an application (e.g., a mobile app). Cookies can be used to track a user’s browsing habits and preferences, and they can also be used to obtain consent for the use of certain types of cookies, such as those used for targeted advertising or analytics. Cookies may be first-party cookies or third-party cookies. The former recognizes a user and stores their preferences so that user’s preferences can beapplied while browsing through webpages or using the application; and the latter inserts additional tracking code that can record a user’s online activity for third-party (e.g., for advertisement and / or data analytics).

[0010] Cookies tend to expose user’s privacy as the website and application may obtain user’s habits and preferences based on the cookies. To overcome the deficiency, privacy-focused technologies have been developed. For example, Federated Learning Cohorts (FLoC) is developed to improve online advertising while respecting user privacy. FLoC is designed to replace traditional third-party cookies. Additionally, consent management platforms (CMPs) are formed for cookies, including One Trust and TrustArc Privacy Management Platform.

[0011] Yet the existing approaches to handle user consent are based on web-interface-specific, application-specific, hardware-specific, or experience-specific consent protocols that require fixed and active user intervention to authenticate their identity and provide consent for experiences. These approaches introduce overhead for users by forcing them to interrupt the experience to frequently verify their identity and select a consent option that aligns with their preferences. Furthermore, it is often not clear for a user where and how to review or update / withdraw from already given consent preferences outside of a web-based interface. This leaves users without autonomy over their consent preferences, and leaves application hosts or business providers without non-web-hosted, non-centralized options for obtaining, storing, and updating user consent setting. SUMMARY OF THE INVENTION

[0012] Embodiments include methods, electronic device, storage medium, and computer program for user consent management. In one embodiment, a method comprises: obtaining a consent parameter setting for an application to execute the application on a premises; based on the consent parameter setting, transmitting a consent request for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application; receiving a consent response responsive to the consent request, the consent response including an encrypted combination of a consent identifier of the user and a consent setting for the user, where the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier; granting a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing the consent setting of the user in a distributed ledger.

[0013] Embodiments include electronic devices for consent management. In one embodiment,an electronic device is disclosed to comprise a processor and non-transitory machine-readable storage medium that provides instructions that, when executed by the processor, are capable of causing the processor to perform: obtaining a consent parameter setting for an application to execute the application on a premises; based on the consent parameter setting, transmitting a consent request for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application; receiving a consent response responsive to the consent request, the consent response including an encrypted combination of a consent identifier of a user and a consent setting for the user, where the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier; granting a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing the consent setting of the user in a distributed ledger.

[0014] Embodiments include machine-readable storage media for consent management. In one embodiment, a machine-readable storage medium is disclosed and it provides instructions that, when executed by a processor, are capable of causing the processor to perform: obtaining a consent parameter setting for an application to execute the application on a premises; based on the consent parameter setting, transmitting a consent request for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application; receiving a consent response responsive to the consent request, the consent response including an encrypted combination of a consent identifier of the user and a consent setting for the user, where the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier; granting a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing the consent setting of the user in a distributed ledger.

[0015] By implementing embodiments as described, user consent may be exchanged, stored, validated, traced, and revised / withdrawn with user privacy maintained in the whole process. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0017] Figure 1 illustrates operations of consent management per some embodiments.

[0018] Figure 2 illustrates operations of consent management per additional embodiments.

[0019] Figure 3 illustrates the encryption of a consent response per some embodiments.

[0020] Figure 4 is a flow diagram illustrating operations of consent management on one electronic device per some embodiments.

[0021] Figure 5 is a flow diagram illustrating operations of consent management on another electronic device per some embodiments.

[0022] Figure 6 illustrates an electronic device to perform consent management per some embodiments.

[0023] Figure 7 illustrates an example of a communication system per some embodiments.

[0024] Figure 8 illustrates a user equipment (UE) per some embodiments.

[0025] Figure 9 illustrates a network node per some embodiments.

[0026] Figure 10 is a block diagram of a host, which may be an embodiment of the host of Figure 7, per various aspects described herein.

[0027] Figure 11 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

[0028] Figure 12 illustrates a communication diagram of a host communicating via a network node with a user equipment (UE) over a partially wireless connection per some embodiments. DETAILED DESCRIPTION

[0029] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

[0030] Data is fundamental to the digital world. In many applications, from metaverse to generative artificial intelligence (AI), all types of data are needed to develop new features and services, train machine learning (ML) and AI models, and provide experiences in various settings (e.g., coffee shops, libraries, natural parks, adventure park), including volumetric data(e.g., three-dimensional (3D) data), audio data, and location data.

[0031] Collecting data by a data collector (e.g., an application) requires the data collector to obtain various levels of user consent based on privacy laws and regulations that vary based on locations / jurisdictions (e.g., European Union or the United States), data types (e.g., health data or financial data), user characteristics (e.g., minors or adults). The consent levels and the type of consented data (audio, video, 3D, location etc.) may enable the data collector to provide various kinds of data to a third party such as an application developer, with mandatory requirement of maintaining user’s privacy in such data transfer. Additionally, it is preferrable that the user preferences in the consent are stored in a traceable or identifiable way across sessions.

[0032] Embodiments of the invention provide approaches for user consent to be exchanged, stored, validated, traced, and revised / withdrawn with user privacy maintained in the whole process. The processing of user consent may be managed in a variety of ways. In some embodiments, the user consent process is coordinated by a consent manager on a premises which is where a user is to execute an available application. A user is a person who is in control of an end user device that reaches the premises. The user may execute the application through either an end user device on the premises or an edge / cloud device through which the user may execute the available application. The consent manager may also be referred to as a local consent manager. Note that executing an application is also referred to as using / deploying / running / applying the application, and it refers to application execution by a user who controls an end user device that is on the premises and providing an experience by the application through the premises.

[0033] The process may also be coordinated by (1) a consent manager on a premises as well as (2) a cloud consent manager that manages at least a portion of consent management of a user (e.g., the cloud consent manager may offload the portion of consent management of the user from the corresponding end user device). The two approaches are discussed in further detail herein. Note that the processing of user consent discussed herein encompasses a variety of operations on user consent, including exchanging, storing, validating, tracing, revising / withdrawing, or otherwise operating on the user consent parameter setting (e.g., provided by an application) and user consent setting (e.g., provided by a user / third party) as discussed in further detail herein. Operations of Consent Management

[0034] Figure 1 illustrates operations of consent management per some embodiments. The consent management system 100 includes an end user device 102, a local consent manager (LCM) 104, and an application 106 that is to be executed by a user who controls an end user device 102 that arrives at a premises through which application 106 is executed. Each of these entities may be an electronic device or implemented within an electronic device, the componentsof which are discussed in further details herein (e.g., relating to electronic device 502 of Figure 5).

[0035] End user device 102 is capable of storing and communicating a persistent digital identifier and consent setting (which is also referred to as consent preferences / choices / information) that indicates the level of consent that an application executed by the user is granted for processing user data. End user device 102 may also be capable of performing changes to consent preferences and generate unique consent identifiers, or may cache changes pushed through consent management software through cloud assets. End user device 102 represents any number of end user devices that come within the range of a premises on which an application (represented by application 106) is available and gives a user an experience that requires user consent.

[0036] The term “local” in the local consent manager (LCM) 104 refers to LCM 104’s reach, which is within the range of a premises (thus on premises of LCM 104) that provides application 106, the use of which requires user consent. LCM 104 is capable of (1) detecting an end user device when the end user device comes within the range of the premises, (2) communicating consent setting of a user that controls the end user device on the premises, (3) performing the consent processing disclosed herein. LCM 104 may communicate with end user device 102 and application 106 either wirelessly (e.g., based on cellular, Bluetooth, or another wireless communication standard discussed herein) or through wireline.

[0037] Note that the premises may be a geographic space or a digital space. The geographic space may be a physical location such as a coffee shop, a library, and a natural / adventure park. A digital space may be a virtual environment such as virtual / augmented realty (e.g., metaverse), online social platforms or marketplaces, and virtual conferences / tour / games. Within the range of the premises may be at the vicinity of the premises (e.g., within a certain distance) or on the premises.

[0038] LCM 104 includes a consent management module 150 that manages processing of user consent by LCM 104. The consent management module 150 communicates with modules at other entities for user consent management, including the ones in end user device 102, application 106, and a consent management module 250 within a cloud consent manager (CCM) 208 discussed herein below. Each of the consent management modules may be a software module or hardware logic.

[0039] A number of identifiers are used in consent management per some embodiments. They may be generated by different entities and play different roles in the consent management process. Identifiers in Consent Management

[0040] The identifiers in consent management discussed herein include a persistent identifier (IDp), a private consent identifier (IDc), and a session identifier (session ID).

[0041] The persistent identifier (IDp) is a unique and private identifier that is bound to a single user and not transferable to another user. The IDp is assigned to a user or device to help manage the user’s consent setting across different websites and services. The IDp of users are used to recognize their users and their consent preferences consistently, even when they visit various geographic or digital spaces. The IDp of a user can be any unique ID for the user, including a universal user identifier tied to a user's profile, a user-provided ID (e.g., email address or another ID provided by the user during consent process), a blockchain based ID, a mobile advertising ID, or a vendor-specified identifier.

[0042] The private consent ID, or IDc, is a unique identifier that is derived from the persistent identifier (IDp). The IDc is only used for a single consent session (thus referred to as a one-time or one-session ID), thus valid once for each application and expires after a certain time period. For example, a session can be the duration of a user’s restaurant visit. The origin of an IDc from a specific persistent identifier, which can be approved and validated; yet one must not be able to derive the specific persistent identifier from one or multiple IDcs.

[0043] The session ID is a unique ID that identifies a session. Each session has one session ID. A session ID may include multiple users using an application. In that case, the IDcs are used to identify unique users with the same session ID.

[0044] These identifiers are used in different stages of the consent management, where the stages include consent session initialization, consent handoff, and consent session update / termination, each of which is discussed in further details below. Consent session initialization

[0045] Prior to initiating a consent session, the consent parameter setting of an application and the consent setting of a user needs to be determined. The consent parameter setting of an application indicates the consent parameters that the application is to be set for processing user data upon a user executing the application. The setting of the consent parameters may be mandated by laws / regulations, or may be needed for properly executing the application The consent setting of the user indicates the levels of consent corresponding to consent parameters, so the application may only process the user data based on the levels of consent indicated by the consent setting of the user.

[0046] Referring to Figure 1, application 106 may register / update a consent parameter setting with LCM 104 for the application at operation 112. LCM 104 thus learns the consent parameters of application 106 from the registration / update. The consent parameter setting indicates level options of consent indicated by the user for the application execution. In some embodiments, theconsent parameter setting is obtained from somewhere else where application 106 stores its consent parameter setting, e.g., from a cloud provider that hosts application 106 or a cloud consent manager (e.g., CCM 208).

[0047] The levels of consent may include different types of consent based on data types. For example, common consent levels include the following: (1) implied consent (e.g., for basic interaction with the application by a user through actions such as clicking a link and scrolling a website), (2) explicit consent (e.g., for more sensitive data processing, which a user is required to agree through checkboxes, buttons, or other interactive elements), (3) informed consent (e.g., for collecting and processing personal or sensitive data, where the application provides clear and concise information about what data will be collected, how it will be used, and who it will be shared with and the user then acknowledges with an interactive element, (4) granular consent (e.g., for specific data processing activities, where a user chooses which types of data they are willing to share or allow for specific purposes, (5) age consent (e.g., age-specific consent that mandates parental consent for a user under a certain age before collecting the user personal information), (6) explicit marketing consent (e.g., for collecting user data for marketing purposes, where an user is required to agree through an interactive element), (7) third-party consent (e.g., for sharing user data with third-party services or partners, where an user is required to agree through an interactive element).

[0048] The number / types of consent parameters for an application and the levels of consent for the application vary significantly, e.g., based on the jurisdiction in which the application is to be used. That is because the consent parameters setting of the application must comply with applicable laws / regulations, such as, but not limited to, the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). The consent parameter setting of an application may include multiple levels of consent based on the data involved in the application, and the consent parameter setting of an application may be viewed as an consent parameter array, each element of which indicates a consent parameter factor, e.g., consent parameter setting = [consent parameter 1, consent parameter 2…], and each element of the consent parameter array has a number of options.

[0049] Applications such as application 106 may store and transmit their consent parameter settings to LCM 104 in a variety of formats and protocols, such as JavaScript Object Notation (JSON) and Extensible Markup Language (XML). Multiple applications may store their consent parameter settings next to each other, and / or transmit their consent parameter settings in one message / session, e.g., when the consent management module 150 is initiated on the premises. Pseudo Code 1 below shows consent parameter settings of two applications as an example.Pseudo code 1: Consent parameter setting { / / Consent parameter settings for multiple applications “Application1_Consent_Request”:[ “Application_ID”:”8c7986bf-2484-4c00-85cc-a8fd42ca93db”, “consent_location_data”: [ “consent_option”: “express / implied / opt_in / opt_out”, “time_expire”:”1751234567” ], “consent_buy_product”: [ “consent_option”: “express / implied / opt_in / opt_out”, “time_expire”:”1751234567” ], “consent_analytics”: [ “consent_option”: “express / implied / opt_in / opt_out”, “time_expire”:”1751234567” ], ],[ “Application_ID”:”c5778552-bbba-4281-bab1-e9970e6aaf97”, “consent_location_data”: [ “consent_option”: “express / implied / opt_in / opt_out”, “time_expire”:”1751234567” ], “consent_buy_product”: [ “consent_option”: “express / implied / opt_in / opt_out”, “time_expire”:”1751234567” ], “consent_analytics”: [ “consent_option”: “express / implied / opt_in / opt_out”, ],}

[0050] Note that for each of Application 1 and Application 2, the user has several consent options for a setting parameter, for example, for the setting of whether to consent to share location data, buy products, and allow user data analysis, a user may provide expressed or implied consent, and the user may opt in or opt out a consent.

[0051] A consent session is to be initiated so that applications such as application 106 may get a response from a user, securely, before the execution of the application, and the response is to address each element of the consent parameter setting. For end user device 102 to respond, a user may configure user consent setting for the applications. At operation 114, the user may configure one or more user consent settings for one or more applications. The consent setting of a user may correspond to the levels of consent discussed herein above relating to different types ofdata / users. In some embodiments, the consent setting of the user is associated with the user’s persistent identifier (IDp).

[0052] In some embodiments, another party may configure the user consent settings for the applications on behalf of the user, when the user is unable or ineligible to configure the user consent settings themselves, e.g., when the user is a minor or dependent. The other party, a parent and / or guardian, may create a consent setting for the minor or dependent using the other party’s persistent identifier (IDp).

[0053] The user consent settings for the applications may be stored and / or transmitted to LCM 104 in a variety of formats and protocols, such as JSON and XML. One or more users may transmit their consent settings for multiple applications in one message / session, e.g., when the consent management module 150 is initiated / reset on the premises. While the user consent settings may be transmitted by the end user device 102 to LCM 104 as shown in Figure 1, they may be transmitted by a third party as well, e.g., by a end user device of a parent and / or guardian or by a cloud consent manager 208 as shown in Figure 2. Pseudo code 2 shows consent setting of a user, where each consent setting for an application includes setting values of different consent parameters. Pseudo Code 2: Consent setting of a user { / / Consent parameter settings for multiple applications “Application1_Consent”:[ 2484-4c00-85cc-a8fd42ca93db”,“timestamp”: “1751230000”, “time_expire”:”1751234567” ], ],[ “Application_ID”:”c5778552-bbba-4281-bab1-e9970e6aaf97”, “consent_location_data”: [ “consent_option”: “opt_in”, “timestamp”: “1751230000”,“time_expire”:”1751234567” ], }

[0054] Asfor the two applications for the same setting parameter. For example, the user opts out of location data collection by application 1 but opts in for the location data collection by application 2. The user thus can set their privacy preference regarding consent on a per application basis. The user consent setting for an application in this example includes a timestamp indicating when the consent setting is selected, and a timer to indicate the duration that the consent setting is valid. In alternative embodiments, more or less information may be associated with the consent setting, e.g., more may be added to an opt-in for allowing providing product buy information so that the opt-in is only valid in certain time of the day (e.g., before 9:00 pm).

[0055] The user consent setting for an application may be viewed as a consent array of a user that corresponds to the consent parameter array of application 106, where the consent array includes elements of setting values, each setting value corresponding to one parameter in the consent array. For example, the consent parameter array of application 106 is [consent_location_ data, consent_by_product, consent_analytics], and the corresponding consent arrays for Application 1 and Application 2 are [opt_out, implied, opt_out] and [opt_in, implied, opt_in], respectively.

[0056] Note that each of consent parameter settings of applications and consent settings of users may be stored in a repository at or accessible by the corresponding applications and end user devices, respectively. LCM 104 may store the consent parameter settings of applications and consent settings of users in a repository at or accessible by LCM 104. Each repository may include a structured data storage system. The structured data storage system is intended to store data (which may be voluminous) for possible consumption by multiple clients. The structured data storage system includes those which typically store persist data (e.g., an on-disk database) and those which typically store non-persist data (e.g., an in-memory database, a streaming platform, a key-value datastore, a document store, etc.).

[0057] Through a consent session, application 106 may get a response from the user indicating the user consent setting. Based on the response, application 106 may process user data based on the consent setting provided by the user or a third party in charge of the user (e.g., a parent or guardian) so that application 106 may collect (1) the type of data and (2) for the purpose specified by the user consent setting. Through the consent session, a user may dictate how application 106 may process the user data from end user device 102 using the consent setting as conveyed to application 106 through a consent session, while maintaining user privacy in the whole consent session through embodiments disclosed herein.

[0058] The consent session is initiated through a handshake process between end user device 102 and LCM 104 at operation 118. The handshake process establishes the consent session upon detection of end user device 102 on premises at operation 116. The session is indicated by a session ID, with a unique ID that identifies the session for consent processing. In some embodiments, an IDc for the user is mapped to the unique session ID. If the consent session has been established previously, the ID session ID is known to LCM 104, and no initiation of the consent session is necessary.

[0059] The detection of the end user device 102 on premises is through the radio-to-device technique in some embodiments. In these embodiments, LCM 104 maintains a beacon (“radio”) employing radio frequency messaging across a frequency recognized by end user device 102 (“device”) and prompts end user device 102 to respond with a signal registering the user’s presence with LCM 104. LCM 104 then establishes a session. The initiation may be expressed in pseudo code in Pseudo Code 3 below. The pseudo code registers a new user coming to the range of the premises based on a new consent ID, which is the private consent ID (IDc) generated, e.g., by end user device 102 or a third party on behalf of a user. Pseudo Code 3: User detection through radio beacon function identifyNewUsers() / / Initialize beacon with a unique ID and an empty list of registered ConsentIDs beaconID = generateUniqueID() registeredUserIDs = getRegisteredConsentIDs() / / Continuously sweep for new users using a radio signal while (true) / / Scan for new users in the vicinity newUsers = scanForNewUsers() / / Send a registration request to each new user for each newUser in newUsers / / Check if the user is already registered if (registeredUserIDs.contains(newUser.ConsentIDs)) continue / / go to end of the function identifyNewUsers() end if / / Send a registration request to the user request = createRegistrationRequest(beaconID, newUser.ConsentIDs) send(request, newUser) / / Wait for a response from the user response = waitForResponse() / / If the response is valid, add the user to the list of registered users if (isValidResponse(response)) addNewUserToRegisteredUsers(response.ConsentIDs) end if end for end while end function

[0060] In alternative or in addition, the detection of end user device 102 on premises uses Joint Communication and Sensing (JCAS) technique. When a new user comes to the range of the premises, a JCAS capable radio equipment present in the premises scans the environment and detects with the help of JCAS localization data and overlays positions of entities (via sensing) and devices (via communication). As an extension of this, information from local cameras or other sensors (Bluetooth, beacon technologies) can be used for the sensing part and corroborated with the JCAS based information. The entities are abstract representations of real-world object while devices are physical or logical units that contain entities. In detecting the user or associated end user device in a consent session, the detection of both entities and devices through JCAS are applicable and the detection allows the consent session to be initiated between end user device 102 and LCM 104.

[0061] Through either detection techniques, end user device 102 is detected on premises, and LCM 104 establishes the consent session at operation 118.Transmission and storage of user consent

[0062] Once a consent session is initiated, LCM 104 may transmit a consent request at operation 120 to end user device 102 on behalf of application 106. The consent request may be transmitted upon a user on a premises initiating a request to execute application 106, or it may be initiated by LCM 104 upon detection of end user device 102 on the premises.

[0063] Responsive to the consent request, end user device 102 may indicate the user consent setting based on the stored user consent setting for the application (e.g., see Pseudo Code 2). The indication may be done without the user’s involvement, e.g., when the consent for the data in the application is implicit. Yet for some applications, LCM 104 may require an active consent (e.g., explicit consent, informed consent, granular consent, age consent, explicit marketing consent). In these and other applications, a display may be shown on end user device 102 to cause the user to respond to an interactive element and indicate one or more specific consent settings of the user. For some applications, LCM 104 may require a consent from a third party (e.g., a parent or guardian). The display may be shown on another end user device of the third party for the third party to indicate one or more specific consent setting on behalf of the user. The indicated one or more specific consent settings on behalf of the user are then provided to end user device 102. The active informed consent and / or third-party consent is shown at operation 122.

[0064] Once the user consent setting for the application is indicated, end user device 102 associates the user consent setting for the application with the persistent digital identifier (IDp) of the user. This process starts with the IDp and the user consent setting (which includes a set of consent preference variables, e.g., see the ones in Pseudo Code 2) as input, and encrypts the IDp using a secret key (e.g., the private key of a private-public key pair), a cryptographic nonce (or simply nonce, and the two terms are used interchangeably herein) so that it is secret to other devices but end user device 102 (the sender) to generate a private consent identifier (IDc). The encryption uses a digital signature to sign a message containing IDc and the consent setting to LCM 104 (the receiver). End user device 102 then uses the public key of the receiver (LCM 104 in this example) to encrypt the message and sends the message with encrypted consent response to LCM 104 at operation 124.

[0065] The encryption process in some embodiments may be expressed in Pseudo Code 4 below. Pseudo Code 4: Encryption of IDp and user consent setting function sendIDc(persistentID: string, consent1: string, consent2: string, consent3: string, receiverPublicKey: publicKey) / / Generate a random noncenonce = generateNonce() / / Encrypt persistent ID with secret key and nonce IDc = encryptWithNonce(persistentID, secret key, nonce) / / Create a message containing the encrypted ID and consent preferences message = createMessage(IDc, consent1, consent2, consent3) / / Sign the message using a digital signature signature = signMessage(message) / / Encrypt the signed message using the receiver's public key encryptedMessage= encryptWithPublicKey(signature + message, receiverPublicKey) / / Send the encrypted message to the receiver send(encryptedMessage) end function

[0066] Note that for a minor / dependent, the IDp and IDc are for the parent / guardian who is responsible for the minor / dependent, and the encrypted message may indicate as such.

[0067] At operation 126, LCM 104 validates the encrypted consent response and stores upon validation the embedded consent setting for the application to a distributed ledger at operation 126. LCM 104 validates the encrypted consent response by decrypting the consent response, e.g., through its private key within the public and private key pairs to derive the IDc and the consent setting corresponding to the IDc for application 106. LCM 104 now possesses the consent setting of the user in control of end user device 102 for application 106 without knowing the persistent ID (IDp) of the user. The user thus maintains the user’s privacy in the consent session while providing the user’s consent to application 106 through LCM 104. If the decryption of consent response 124 fails, where LCM 104 can derive from response 124 no valid response to the consent parameter setting of Application 106, LCM 104 may discard response 124. In some embodiments, LCM 104 responsively transmits a failure response to notify end user device 102.

[0068] The distributed ledger that stores the consent setting for application 106 may be implemented in a variety of platforms using blockchains and smart contracts, and notable examples of such platforms include Ethereum, Hyperledger Fabric, Hedera Hashgraph, Solana, Cardano, Avalanche, and Polygon. The embodiments of the invention are not limited to aparticular implementation of the distributed ledger.

[0069] Blockchain technology may be used to create a secure and transparent record of user consent in some embodiments. It can be used to create digital consent tokens that can be stored on a blockchain, which can then be verified and tracked as needed. This can be used for data sharing and other digital transactions where consent is needed.

[0070] Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. They can be used to create digital consent forms where users can provide consent in a secure, tamper-proof way in some embodiments, where the terms of the agreement are automatically enforced.

[0071] For illustration, the process of generating the blockchain for storing the user consent setting is shown in the Pseudo Code 5. Pseudo Code 5: Generation of a block chain to store user consent setting function createConsentBlockchain() / / Initialize the blockchain with a genesis block, the first block in a blockchain genesisBlock = createGenesisBlock() blockchain = [genesisBlock] / / Loop over all received messages and add them to the blockchain for each receivedMessage in receivedMessages / / Verify the digital signature of the message signature = getSignatureFromMessage(receivedMessage) message = getMessageFromSignature(signature) isValid = verifySignature(signature, message) / / If the signature is valid, add the message to the blockchain if (isValid) / / Create a new block with the message and add it to the blockchain newBlock = createBlock(blockchain[-1], receivedMessage) blockchain.append(newBlock) end if end for return blockchain end function

[0072] Note that a new block in the blockchain is created to store the message in the response from end user device 102 at operation 124, including IDc and user consent setting (as indicated in Pseudo Code 4, message = createMessage(IDc, consent1, consent2, consent3)).

[0073] The IDc and the user consent setting as stored in the distributed ledger may be visible to all parties involved in the consent session. Such distributed ledger for storing user consent settings provides (1) security to counter a single point of failure, (2) transparency to show all the transactions of user consent settings on record to prevent fraud and tampering of the record, (3) efficiency to streamlining transactions and eliminating the need of intermediaries, and (4) trust among the parties (e.g., user / parent / guardian, application, and regulator).

[0074] The block creation through createBlock() in Pseudo Code 5 may be implemented though operations shown in Pseudo Code 6. Pseudo Code 6: Creation of a block to storing user consent setting function createBlock(previousBlock: Block, message: string) / / Get the index and hash of the previous block previousIndex = previousBlock.index previousHash = previousBlock.hash / / Generate a new index and nonce for the new block newIndex = previousIndex + 1 newNonce = generateNonce() / / Create a new block header by concatenating the index, previoushash, message hash, and nonce header = newIndex + previousHash + sha256(message) + newNonce / / Find a hash for the block header that meets the required difficulty level difficultyLevel = [DIF] / / Example difficulty level of DIF leading zeroes hash = findHashWithDifficulty(header, difficultyLevel) / / Create the new block by combining the header, message, and hash newBlock = { "index": newIndex, "previousHash": previousHash, "message": message, "nonce": newNonce,"hash": hash } return newBlock end function

[0075] In some embodiments, LCM 104 responsively transmits an acknowledgement response at operation 128 to notify end user device 102 that the consent response 124 has been successfully received / accepted by LCM 104. In addition and / or in alternative, the acknowledgement response may be initiated from Application 106 once the application starts to process user data based on the received user consent setting.

[0076] At operation 130, LCM 104 grants a permission for execution of the application based on the consent setting for the user of end user device 102. Application 106 is then executed by the user (e.g., through end user device 102) at operation 132 and the application processes data from the application execution based on the consent setting for the user at operation 134. The data processing may include data collection, analysis, distribution to a third party, and other operations on the data; and the consent setting dictates how application 106 may process the data generated relating to the user from executing application 106. For example, application 106 won’t process one type of user data from end user device 102 if the consent setting indicates opt_out for the one type of user data (e.g., the setting being current_location_data, consent_option: opt_out).

[0077] Note that the user consent setting may have a timer in some embodiments as shown in Pseudo Code 2, and once the timer expires, Application 106 stops the data processing based on the user consent setting, and may request LCM 104 for an updated user consent setting. In that case, LCM 104 may send a consent request at 120, receive an encrypted consent response at operation 124, validate and store upon validation of the embedded consent setting for the application, and grant permission for execution of the application based on the renewed user consent setting. The same consent session ID may be used in the whole user consent setting renewal process.

[0078] Through using IDc, a unique identifier that is derived from the persistent identifier (IDp), for the consent session to represent the user, the persistent identifier (IDp) of the user is protected so that only the original sender of the IDc (e.g., end user device 102 and / or cloud consent manager 208) can establish the mapping between IDc and IDc, and the user consent setting is thus protected. User consent update

[0079] User consent setting for an application may be updated after the user consent setting is provided to an application in some embodiments. Such update gives users autonomy over their consent settings, and leaves application hosts and business providers ways to update the consent settings.

[0080] At operation 142, end user device 102 sends a consent update request at operation 142. The consent update request may be for updating a consent level of a consent parameter setting or withdrawal of consent for application 106 to process certain types of user data for the session to execute application 106 between end user device 102 and application 106.

[0081] In some embodiments, the consent update request indicates (1) the session ID, the unique ID that identifies the session for consent processing used in session initiation at operation 118, (2) the IDc, the unique identifier that is derived from the persistent identifier (IDp), for the consent session to represent the user, and (3) one or more updated setting values of corresponding consent parameter (e.g., a setting value of “opt_out” to change the current value of “opt_in” may be changed). These values of (1) to (3) are then included in a consent update request (e.g., the message containing the consent update request may be created through the operations similar to the one discussed relating to operations 118 to 120 and Pseudo Code 3 and Pseudo Code 4).

[0082] In some embodiments, the consent update is to withdraw consent, and the user is the only user for the consent session. The consent update may be used to close the consent session and initiate a new session with a new session ID. In such embodiments, end user device 102 generates a new unique IDc (e.g., a new private ConsentID in Pseudo Code 7) with an indication the change to the new session ID (see at operation 142). In some embodiments, IDc entries through generation and withdrawal do not differ in length or another characteristic that is detectable without decrypting the IDc entries (e.g., the IDc entries being encrypted with padding); maintaining the length uniformity of the IDc entries preventing an observer from learning the changes of IDc entries.

[0083] For illustration, the process of consent withdrawal through terminating an existing session and opening a new one is shown in Pseudo Code 7. Pseudo Code 7: User consent withdrawal through terminating an existing session and opening a new session function sendChangeToNewConsent(previousMessage: string, newIndicator: string, metadata: string, publicKey: publicKey) / / Close previous session close(previousSessionID) / / Begin new session newSessionID = generateNewSessionID() initiate(newSessionID) / / Generate a random nonce nonce = generateNonce() / / Encrypt the previous session ID with the persistent ID, secret key using a new nonce (e.g., for session continuity upon timeout and / or session logging) encryptedPreviousSessionID = encryptWithNonce(previousSessionID, persistent ID, secret key, nonce) / / Create a new message with the encrypted previous SessionID, new indicators of consent, and metadata, and the new message is the new consent ID newMessage = createChangeMessage(encryptedPreviousSessionID, newIndicators, metadata) / / Sign the new message using a digital signature signature = signMessage(newMessage) / / Encrypt the signed message using the receiver's public key encryptedMessage = encryptWithPublicKey(signature + newMessage, publicKey) / / Send the encrypted message to the receiver; the encrypted message contains encryptedPreviousSessionID for session continuity along with additional indicators and metadata specifying the new preference send(encryptedMessage) end function

[0084] LCM 104 receives the consent update request, and validates and stores upon validation, the embedded consent update for the application, to the distributed ledger at operation 144. The operation is similar to the one discussed herein above relating to operation 126. The consent update request may be stored in a new block next to the last block in the blockchain (e.g., the last block was added in the operation at operation 126) for the consent session of the application for the user.

[0085] At operation 146, LCM 104 requests to update the permission based on the consent update. Responsively, application 106 updates data processing for the session between end user device 102 and application 106 based on the consent update at operation 148. For example, when a setting value changes from level of “opt_in” to “opt_out” as indicated in the consent update request at operation 142 and relayed through the request to update the permission at operation 146, Application 106 stop collecting the corresponding data type based on the setting value change.

[0086] Through these consent operations, the consent setting of a user may be changed dynamically based on user preference, and such change does not reveal the persistent identifier (IDp) of the user. Thus, the user privacy is protected throughout the consent update process. Operations of Consent Management with a Cloud Consent Manager

[0087] In some embodiments, the operations of user consent processing may be coordinated by both a consent manager on a premises as well as (2) a cloud consent manager that manages at least a portion of consent management of a user. Figure 2 illustrates operations of consent management per additional embodiments. In these embodiments, a cloud consent manager (CCM) 208 includes a consent management module 250 coordinates the consent session, along with LCM 104. CCM 208 may be implemented on another electronic device apart from LCM 104 that is on premises. The operations in Figure 2 are similar to the ones in Figure 1, and the differences are discussed herein.

[0088] At operation 215, end user device 102 synchronizes the user consent setting with CCM 208. A user configures a set of user consent settings for a set of applications at operation 114 as in Figure 1, and end user device 102 then synchronizes the user consent settings with CCM 208.

[0089] The cloud based storage of the user consent settings offers a few advantages. For example, for user consent management, CCM 208 offers centralized management (the user may manage many user consent settings on multiple end user devices), remote access (the user may manage an end user device even though the user is not physically on premises, and it is particularly convenient for third-party consent grant), backup / redundancy (these can be easily done in a cloud environment), cross-device promulgation (the synchronized user setting from one end user device may be promulgated to multiple end user devices controlled by the same user), and enhanced security (available in many cloud platforms). Because of these advantages, end user devices sometimes automatically synchronize user consent settings after user configuration. A user may indicate that CCM 208 is the proxy for managing the set of user consent settings for the set of applications and identify CCM 208 using an indication so that LCM 104 may reach out to CCM 208.

[0090] After end user device 102 is detected on premises at operation 116, a consent session isinitiated at operation 218. Through this consent session initiation, LCM 104 determines that CCM 208 is the proxy for managing the user consent setting for application 106 (e.g., based on an indication that CCM 208 is the proxy). In some embodiments, LCM 104 obtains the unique IDc for the consent session. Afterward, LCM 104 interacts with CCM 208 for the consent session. The operations are similar as the ones discussed in Figure 1, and they are shown in the same operation numbers to denote the similarity.

[0091] While this set of embodiments adds a cloud consent manager as an additional entity for user consent management, the user consent session offers similar benefits as the local consent manager alone approach, with additional benefit of the user consent setting being managed through the cloud as discussed herein.

[0092] Note that the communication between the parties in a consent session may be additionally protected through existing security communication channel such as transport layer security (TLS), secure sockets layer (SSL), secure shell (SSH), Quck User Datagram Protocol (UDP) Intenet Connection (Quic), and Datagram Transport Layer Security (DTLS). Yet the embodiments provide additional protection through encryption of persistent identifier (IDp) so that the user identity, being kept on behalf of the user (e.g., by end user device 102 or CCM 208 as the user’s proxy), may be hidden from the whole consent session, and the intermediaries such as LCM 104 as well as application 106 never learn the IDp, even if the security communication channel for execution of application 106 is breached for some reason.

[0093] Figure 3 illustrates the encryption of a consent response per some embodiments. A private consent identifier (IDc) 312 is formed through encryption of persistent identifier (IDp) 302 with a secret key 306 and a cryptographic nonce 308. The secret key 306 is a key known only to the entity that maintains the secret key, e.g., a private key of a private-public key pair. the cryptographic nonce 308 is a number used only once. They may be combined (e.g., hashed) to generate IDc 312.

[0094] A message may then be created using consent setting 320 and IDc 312, and the message can then be signed by a digital signature (e.g., one based on a certificate for the IDc). The IDc certificate may be derived through a variety of ways, including hashing or privacy-preserving certificate discussed in “Privacy-Preserving Outsourced Certificate Validation” by Tarek Galal, et al. dated August 2023. The signed message may then be encrypted by an encryption module 350, using a public key of the receiver, which is LCM 104 as shown at operation 322. The encryption then produces an encrypted consent response 352. An example of the encryption is shown at Pseudo Code 4. Operations per some embodiments

[0095] Figure 4 is a flow diagram illustrating operations of consent management on one electronic device per some embodiments. The operations of method 400 may be implemented in an electronic device (e.g., electronic device 602) that includes consent management module 150.

[0096] At operation 402, a consent parameter setting is obtained for an application to execute the application on a premises. The obtainment of the consent parameter setting is discussed relating to operation 112 herein above.

[0097] At operation 404, based on the consent parameter setting, a consent request is transmitted for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application. The transmission of the consent request and the determination of the end user device to be one premises are discussed relating to operations 116 to 120.

[0098] At operation 406, a consent response is received responsive to the consent request, the consent response including an encrypted combination of a consent identifier of the user and a consent setting for the user, where the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier. The consent response is discussed related to operation 124 and Figure 3.

[0099] At operation 408, a permission for execution of the application is granted based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user. The grant of the permission is discussed relating to operation 130.

[0100] At operation 410, the consent setting of the user is stored in a distributed ledger. The storing of the consent setting of the user is discussed relating to operation 126.

[0101] In some embodiments, the end user device is determined to be on the premises upon detection of the end user device through a response to a beacon signal transmitted on the premises. In some embodiments, the end user device is determined to be on the premises upon detection of the end user device through sensing one or more entities associated with the user or the end user device. The former is referred to as the radio-to-device technique and the latter is referred to as JCAS technique in the discussion herein above.

[0102] In some embodiments, the consent response is transmitted upon consent by a third party on behalf of the user. For example, the party may be a parent or guardian of the user as discussed herein above.

[0103] In some embodiments, the consent response is transmitted by an electronic device apart from the end user device, wherein the electronic device stores the consent setting for the user. For example, CCM 208 may transmit the consent response as discussed herein above.

[0104] In some embodiments, acknowledgement of the consent response is sent upon the validation of the consent setting for the user, as shown at operation 128.

[0105] In some embodiments, the method further comprises the following: receiving at operation 412 a request to update the consent setting for the session, the request to update including an encrypted combination of an identifier of the session, the consent identifier of the user, and one or more setting values to be set for the user in the consent setting to execute the application; transmitting a request at operation 414 to update the permission for the execution of the application based on the one or more setting values received from the request to update upon decryption of the request to update and validation of the one or more setting values, and storing the request at operation 416 to update in the distributed ledger. The operations are discussed herein above relating to operations 142 to 146.

[0106] In some embodiments, the request to update is for consent withdrawing, wherein updating the permission for the execution of the application is to terminate the session to prevent further data processing (e.g., data collection) in execution of the application, and the session termination is stored in the distributed ledger. The consent withdrawing is discussed relating to the subsection of “User consent update” herein above.

[0107] Through these embodiments, user consent may be exchanged, stored, validated, traced, and revised / withdrawn with user privacy maintained in the whole process, since user consent setting is not mapped to a persistent identifier of the user, and only a consent identifier that is generated for a consent session is used for consent processing. Such protection of user privacy (no persistent ID exposure in the whole consent session) allows a user to dictate how user data is collected and processed by another party (e.g., the application vendor / host) without concerns over compromising one’s privacy.

[0108] Figure 5 is a flow diagram illustrating operations of consent management on another electronic device per some embodiments. The operations of method 500 may be implemented in an electronic device (e.g., electronic device 602) that includes consent management module 250.

[0109] At operation 502, a consent setting for an application is received from an end user device. At operation 504, a consent request is received for the application to be executed upon detection of an end user device of a user on a premises, the consent request for establishing a session to execute the application. The receipt of the consent setting and the consent request is discussed herein above relating to operations 215 and 120, respectively.

[0110] At operation 506, a consent response is transmitted responsive to the consent request, the consent response including an encrypted combination of a consent identifier of a user and a consent setting for the user, where the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from theconsent identifier, where the permission for execution of the application is granted based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user, and where the consent setting of the user is stored in a distributed ledger. The consent response related operations are shown in Figures 1 to 3 and discussed herein above.

[0111] In some embodiments, the end user device is determined to be on the premises upon detection of the end user device through a response to a beacon signal transmitted on the premises. In some embodiments, the end user device is determined to be on the premises upon detection of the end user device through sensing one or more entities associated with the user or the end user device. The former is referred to as the radio-to-device technique and the latter is referred to as JCAS technique in the discussion herein above.

[0112] In some embodiments, the consent response is transmitted upon consent by a party other than the user. For example, the party may be a parent or guardian of the user as discussed herein above.

[0113] In some embodiments, receiving the user consent setting from the end user device is responsive to a synchronization operation as shown at operation 215.

[0114] In some embodiments, acknowledgement of the consent response is sent upon the validation of the consent setting for the user, as shown at operation 128.

[0115] In some embodiments, the method further comprises the following: transmitting a request at operation 512 to update the consent setting for the session, the request to update including an encrypted combination of an identifier of the session, the consent identifier of the user, and one or more setting values to be set for the user in the consent setting to execute the application, where the request to update causes updating the permission for the execution of the application based on the one or more setting values received from the request to update upon decryption of the request to update and validation of the one or more setting values, and where the request to update is stored in the distributed ledger. The operations are discussed herein above relating to operations 142 to 146.

[0116] In some embodiments, the request to update is for consent withdrawing, wherein updating the permission for the execution of the application is to terminate the session to prevent further data collection in execution of the application, and the session termination is stored in the distributed ledger. The consent withdrawing is discussed herein above relating to the subsection of “User consent Update” herein above.

[0117] While method 500 is operated on an additional entity for user consent management, the user consent session offers similar benefits as the local consent manager alone approach, withadditional benefit of the user consent setting being managed through the cloud as discussed herein. Devices and Environments for Implementing Embodiments of the Invention

[0118] Figure 6 illustrates an electronic device to perform consent management per some embodiments. The electronic device 602 may be a host in a cloud system, or a network node in a wireless / wireline network, and the operating environment and further embodiments the host and the network node are discussed in more details discussed relating to Figures 7 to 12. The electronic device 602 may be implemented using custom application–specific integrated–circuits (ASICs) as processors and a special-purpose operating system (OS), or common off-the-shelf (COTS) processors and a standard OS. In some embodiments, electronic device 602 implements the operations discussed herein relating to Figures 1 to 5.

[0119] The electronic device 602 includes hardware 640 comprising a set of one or more processors 642 (which are typically COTS processors or processor cores or ASICs) and physical NIs 646, as well as non-transitory machine-readable storage media 649 having stored therein software 650. During operation, the one or more processors 642 may execute the software 650 to instantiate one or more sets of one or more applications 664A-N. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment, the virtualization layer 654 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 662A-N called software containers that may each be used to execute one (or more) of the sets of applications 664A-N. The multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run. The set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment, the virtualization layer 654 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 664A-N run on top of a guest operating system within an instance 662A-N called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that run on top of the hypervisor - the guest operating system and application may not know that they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and / or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some, or all of the applications are implemented as unikernel(s), which can be generated by compiling directly with an applicationonly a limited set of libraries (e.g., from a library operating system (LibOS) including drivers / libraries of OS services) that provide the particular OS services needed by the application. As a unikernel can be implemented to run directly on hardware 640, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikernels running directly on a hypervisor represented by virtualization layer 654, unikernels running within software containers represented by instances 662A-N, or as a combination of unikernels and the above-described techniques (e.g., unikernels and virtual machines both run directly on a hypervisor, unikernels, and sets of applications that are run in different software containers).

[0120] The software 650 includes a consent management module 655 that performs operations described with reference to operations as discussed relating to Figures 1 to 5. The consent management module 655 may perform operations of consent management module 150 or 250. The consent management module 655 be instantiated within the applications 664A-N. The instantiation of the one or more sets of one or more applications 664A-N, as well as virtualization if implemented, are collectively referred to as software instance(s) 652. Each set of applications 664A-N, corresponding virtualization construct (e.g., instance 662A-N) if implemented, and that part of the hardware 640 that executes them (be it hardware dedicated to that execution and / or time slices of hardware temporally shared), forms a separate virtual electronic device 660A-N.

[0121] A network interface (NI) may be physical or virtual. In the context of Internet Protocol (IP), an interface address is an IP address assigned to an NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). The NI is shown as network interface card (NIC) 644. The physical network interface 646 may include one or more antenna of the electronic device 602. An antenna port may or may not correspond to a physical antenna. The antenna comprises one or more radio interfaces. A Wireless Network per Some Embodiments

[0122] Figure 7 illustrates an example of a communication system 700 per some embodiments. In the example, the communication system 700 includes a telecommunication network 702 that includes an access network 704, such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710A and 710B (one or more of which may be generally referred to as network nodes 710), or any other similar 3rdGenerationPartnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 702 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 702 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 702, including one or more network nodes 710 and / or core network nodes 708.

[0123] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 710 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 712A, 712B, 712C, and 712D (one or more of which may be generally referred to as UEs 712) to the core network 706 over one or more wireless connections.

[0124] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 700 mayinclude and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0125] The UEs 712 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 710 and other communication devices. Similarly, the network nodes 710 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 712 and / or with other network nodes or equipment in the telecommunication network 702 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 702.

[0126] In the depicted example, the core network 706 connects the network nodes 710 to one or more hosts, such as host 716. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 706 includes one more core network nodes (e.g., core network node 708) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 708. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0127] The host 716 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and / or the telecommunication network 702, and may be operated by the service provider or on behalf of the service provider. The host 716 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0128] As a whole, the communication system 700 of Figure 7 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal MobileTelecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0129] In some examples, the telecommunication network 702 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunication network 702 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 702. For example, the telecommunication network 702 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs.

[0130] In some examples, the UEs 712 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 704. Additionally, a UE may be configured for operating in single- or multiple radio access technology (multi-RAT) or multi- standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E- UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC).

[0131] In the example, the hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 712C and / or 712D) and network nodes (e.g., network node 710B). In some examples, the hub 714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 714 may be a broadband router enabling access to the core network 706 for the UEs. As another example, the hub 714 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 710, or by executable code, script, process, or other instructions in the hub 714. As another example, the hub 714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 714 may be a content source. For example, for a UE that is a virtual reality (VR) headset, display, loudspeaker or other media deliverydevice, the hub 714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 714 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 714 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices.

[0132] The hub 714 may have a constant / persistent or intermittent connection to the network node 710b. The hub 714 may also allow for a different communication scheme and / or schedule between the hub 714 and UEs (e.g., UE 712C and / or 712D), and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and / or one or more UEs via a wired connection. Moreover, the hub 714 may be configured to connect to a machine-to-machine (M2M) service provider over the access network 704 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 710 while still connected via the hub 714 via a wired or wireless connection. In some embodiments, the hub 714 may be a dedicated hub – that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 710B. In other embodiments, the hub 714 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 710B, but which is additionally capable of operating as a communication start and / or end point for certain data channels. In some embodiments, the electronic device 602 that implements the consent management module 655 may be, comprise, or be coupled to one of network nodes 708, 710A- B, or host 717. UE per Some Embodiments

[0133] Figure 8 illustrates a UE 800 per some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. End user device 102 may be or comprise a UE.

[0134] A UE may support device-to-device (D2D) communication, for example byimplementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, a user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0135] The UE 800 includes processing circuitry 802 that is operatively coupled via a bus 804 to an input / output interface 806, a power source 808, a memory 810, a communication interface 812, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 8. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0136] The processing circuitry 802 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 810. The processing circuitry 802 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 802 may include multiple central processing units (CPUs) or graphics processing units (GPUs).

[0137] In the example, the input / output interface 806 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 800. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, amagnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0138] In some embodiments, the power source 808 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 808 may further include power circuitry for delivering power from the power source 808 itself, and / or an external power source, to the various parts of the UE 800 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 808. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 808 to make the power suitable for the respective components of the UE 800 to which power is supplied.

[0139] The memory 810 may be or be configured to include memory such as random-access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read- only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 810 includes one or more application programs 814, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 816. The memory 810 may store, for use by the UE 800, any of a variety of various operating systems or combinations of operating systems.

[0140] The memory 810 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a Universal Subscriber Identity Module (USIM) and / or IP Multimedia Services Identity Module (ISIM), other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 810 may allow the UE 800 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodiedas or in the memory 810, which may be or comprise a device-readable storage medium.

[0141] The processing circuitry 802 may be configured to communicate with an access network or other network using the communication interface 812. The communication interface 812 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 822. The communication interface 812 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 818 and / or a receiver 820 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 818 and receiver 820 may be coupled to one or more antennas (e.g., antenna 822) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0142] In the illustrated embodiment, communication functions of the communication interface 812 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), Quick UDP Internet Connections (QUIC), Hypertext Transfer Protocol (HTTP), and so forth.

[0143] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 812, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0144] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or theswitch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0145] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 800 shown in Figure 8.

[0146] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0147] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.Network Node per Some Embodiments

[0148] Figure 9 illustrates a network node 900 per some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

[0149] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0150] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0151] The network node 900 includes a processing circuitry 902, a memory 904, a communication interface 906, and a power source 908. The network node 900 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 900 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair may in some instances be considered a single separate network node. In some embodiments, the network node 900 may be configured to support multiple radio access technologies (RATs). In such embodiments, some componentsmay be duplicated (e.g., separate memory 904 for different RATs) and some components may be reused (e.g., a same antenna 910 may be shared by different RATs). The network node 900 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 900, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 900.

[0152] The processing circuitry 902 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 900 components, such as the memory 904, to provide network node 900 functionality.

[0153] In some embodiments, the processing circuitry 902 includes a system on a chip (SOC). In some embodiments, the processing circuitry 902 includes one or more of radio frequency (RF) transceiver circuitry 912 and baseband processing circuitry 914. In some embodiments, the radio frequency (RF) transceiver circuitry 912 and the baseband processing circuitry 914 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 912 and baseband processing circuitry 914 may be on the same chip or set of chips, boards, or units.

[0154] The memory 904 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 902. The memory 904 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 902 and utilized by the network node 900. The memory 904 may be used to store any calculations made by the processing circuitry 902 and / or any data received via the communication interface 906. In some embodiments, the processing circuitry 902 and memory 904 is integrated.

[0155] The communication interface 906 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, thecommunication interface 906 comprises port(s) / terminal(s) 916 to send and receive data, for example to and from a network over a wired connection. The communication interface 906 also includes radio front-end circuitry 918 that may be coupled to, or in certain embodiments a part of, the antenna 910. Radio front-end circuitry 918 comprises filters 920 and amplifiers 922. The radio front-end circuitry 918 may be connected to an antenna 910 and processing circuitry 902. The radio front-end circuitry may be configured to condition signals communicated between antenna 910 and processing circuitry 902. The radio front-end circuitry 918 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 918 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 920 and / or amplifiers 922. The radio signal may then be transmitted via the antenna 910. Similarly, when receiving data, the antenna 910 may collect radio signals which are then converted into digital data by the radio front-end circuitry 918. The digital data may be passed to the processing circuitry 902. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0156] In certain alternative embodiments, the network node 900 does not include separate radio front-end circuitry 918, instead, the processing circuitry 902 includes radio front-end circuitry and is connected to the antenna 910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 912 is part of the communication interface 906. In still other embodiments, the communication interface 906 includes one or more ports or terminals 916, the radio front-end circuitry 918, and the RF transceiver circuitry 912, as part of a radio unit (not shown), and the communication interface 906 communicates with the baseband processing circuitry 914, which is part of a digital unit (not shown).

[0157] The antenna 910 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 910 may be coupled to the radio front-end circuitry 918 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 910 is separate from the network node 900 and connectable to the network node 900 through an interface or port.

[0158] The antenna 910, communication interface 906, and / or the processing circuitry 902 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 910, the communication interface 906, and / or the processing circuitry 902 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another networknode and / or any other network equipment.

[0159] The power source 908 provides power to the various components of network node 900 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 908 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 900 with power for performing the functionality described herein. For example, the network node 900 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 908. As a further example, the power source 908 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0160] Embodiments of the network node 900 may include additional components beyond those shown in Figure 9 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 900 may include user interface equipment to allow input of information into the network node 900 and to allow output of information from the network node 900. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 900. In some embodiments, the network node 900 may implement the consent management module 652 and perform operations described herein. Host per Some Embodiments

[0161] Figure 10 is a block diagram of a host 1000, which may be an embodiment of the host 716 of Figure 7, per various aspects described herein. As used herein, the host 1000 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1000 may provide one or more services to one or more UEs. In some embodiments, the host 1000 may implement the consent management module 655 and perform operations described herein.

[0162] The host 1000 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input / output interface 1006, a network interface 1008, a power source 1010, and a memory 1012. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 8 and 9, such that the descriptions thereof are generally applicable to the corresponding components of host 1000.

[0163] The memory 1012 may include one or more computer programs including one or more host application programs 1014 and data 1016, which may include user data, e.g., data generated by a UE for the host 1000 or data generated by the host 1000 for a UE. Embodiments of the host 1000 may utilize only a subset or all of the components shown. The host application programs 1014 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Moving Picture Experts Group (MPEG), VP9) and audio codecs (e.g., Free Lossless Audio Codec (FLAC), Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1014 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1000 may select and / or indicate a different host for over-the-top services for a UE. The host application programs 1014 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc. Virtualization Environment per Some Embodiments

[0164] Figure 11 is a block diagram illustrating a virtualization environment 1100 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. The virtualization environment may also implement pods and containers as shown in Figure 3.

[0165] Applications 1102 (which may alternatively be called software instances, virtualappliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q500 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. In some embodiments, Applications 1102 may implement the consent management module 655 and perform operations described herein.

[0166] Hardware 1104 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108A and 1108B (one or more of which may be generally referred to as VMs 1108), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1106 may present a virtual operating platform that appears like networking hardware to the VMs 1108.

[0167] The VMs 1108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1106. Different embodiments of the instance of a virtual appliance 1102 may be implemented on one or more of VMs 1108, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0168] In the context of NFV, a VM 1108 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1108, and that part of hardware 1104 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1108 on top of the hardware 1104 and corresponds to the application 1102.

[0169] Hardware 1104 may be implemented in a standalone network node with generic or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1110, which, among others, oversees lifecycle management of applications 1102. In some embodiments, hardware 1104 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or moreantennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1112 which may alternatively be used for communication between hardware nodes and radio units. Communication among host, network node, and UE per Some Embodiments

[0170] Figure 12 illustrates a communication diagram of a host 1202 communicating via a network node 1204 with a UE 1206 over a partially wireless per some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 712A of Figure 7 and / or UE 800 of Figure 8), network node (such as a network node 710 of Figure 7 and / or network node 900 of Figure 9), and host (such as host 716 of Figure 7 and / or host 1000 of Figure 10) discussed in the preceding paragraphs will now be described with reference to Figure 12. Either host 1202 or network node 1204 may implement the consent management module 655 and perform operations described herein.

[0171] Like host 1000, embodiments of host 1202 include hardware, such as a communication interface, processing circuitry, and memory. The host 1202 also includes software, which is stored in or accessible by the host 1202 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1206 connecting via an over-the-top (OTT) connection 1250 extending between the UE 1206 and host 1202. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1250.

[0172] The network node 1204 includes hardware enabling it to communicate with the host 1202 and UE 1206. The connection 1260 may be direct or pass through a core network (like core network 706 of Figure 7) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0173] The UE 1206 includes hardware and software, which is stored in or accessible by UE 1206 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1206 with the support of the host 1202. In the host 1202, an executing host application may communicate with the executing client application via the OTT connection 1250 terminating at the UE 1206 and host 1202. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1250 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the userdata that it provides to the host application through the OTT connection 1250.

[0174] The OTT connection 1250 may extend via a connection 1260 between the host 1202 and the network node 1204 and via a wireless connection 1270 between the network node 1204 and the UE 1206 to provide the connection between the host 1202 and the UE 1206. The connection 1260 and wireless connection 1270, over which the OTT connection 1250 may be provided, have been drawn abstractly to illustrate the communication between the host 1202 and the UE 1206 via the network node 1204, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0175] As an example of transmitting data via the OTT connection 1250, in step 1208, the host 1202 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1206. In other embodiments, the user data is associated with a UE 1206 that shares data with the host 1202 without explicit human interaction. In step 1210, the host 1202 initiates a transmission carrying the user data towards the UE 1206. The host 1202 may initiate the transmission responsive to a request transmitted by the UE 1206. The request may be caused by human interaction with the UE 1206 or by operation of the client application executing on the UE 1206. The transmission may pass via the network node 1204, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1212, the network node 1204 transmits to the UE 1206 the user data that was carried in the transmission that the host 1202 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1214, the UE 1206 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1206 associated with the host application executed by the host 1202.

[0176] In some examples, the UE 1206 executes a client application which provides user data to the host 1202. The user data may be provided in reaction or response to the data received from the host 1202. Accordingly, in step 1216, the UE 1206 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 1206. Regardless of the specific manner in which the user data was provided, the UE 1206 initiates, in step 1218, transmission of the user data towards the host 1202 via the network node 1204. In step 1220, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1204 receives user data from the UE 1206 and initiates transmission of the received user data towards the host 1202. In step 1222, the host 1202 receives the user data carried in the transmission initiated by the UE 1206.

[0177] In an example scenario, factory status information may be collected and analyzed by thehost 1202. As another example, the host 1202 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1202 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1202 may store surveillance video uploaded by a UE. As another example, the host 1202 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1202 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0178] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1250 between the host 1202 and UE 1206, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1202 and / or UE 1206. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1250 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1250 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1204. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1202. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1250 while monitoring propagation times, errors, etc.

[0179] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into otherinformation, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0180] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally. Terms

[0181] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” and so forth, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0182] The description and claims may use the terms “coupled” and “connected,” along with their derivatives. These terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electricalcontact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of wireless or wireline communication between two or more elements that are coupled with each other. A “set,” as used herein can refer to any whole number of items including one item.

[0183] An electronic device (such as the electronic device 102) stores and transmits (internally and / or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as a computer program code or a computer program) and / or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical, or other form of propagated signals – such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., of which a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), other electronic circuitry, or a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed). When the electronic device is turned on, that part of the code that is to be executed by the processor(s) of the electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random-access memory (DRAM), static random-access memory (SRAM)) of the electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and / or receive code and / or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and / or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of (1) receiving data from other electronic devices over a wireless connection and / or (2) sending data out to other devices through a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and / or transceiver(s) suitable for radio frequency communication. The radio circuitry may convert digital data into a radio signal having the proper parameters (e.g., frequency, timing, channel, bandwidth, and so forth). The radio signal may then be transmitted through antennas to the appropriate recipient(s). In someembodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate with wire through plugging in a cable to a physical port connected to an NIC. One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and / or hardware.

[0184] The terms “module,” “logic,” and “unit” used in the present application, may refer to a circuit for performing the function specified. In some embodiments, the function specified may be performed by a circuit in combination with software such as by software executed by a general-purpose processor.

[0185] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0186] The term unit may have conventional meaning in the field of electronics, electrical devices, and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

Claims

CLAIMS What is claimed is:

1. A method for user consent management, comprising: obtaining (402) a consent parameter setting for an application to execute the application on a premises; based (404) on the consent parameter setting, transmitting a consent request for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application; receiving (406) a consent response to the consent request, the consent response including an encrypted combination of a consent identifier of the user and a consent setting for the user, wherein the consent identifier of the user is derived from a cryptographic nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier; granting (408) a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing (410) the consent setting of the user in a distributed ledger.

2. The method of claim 1, wherein the end user device is determined to be on the premises upon detection of the end user device through a response to a beacon signal transmitted on the premises.

3. The method of claim 1 or 2, wherein the end user device is determined to be on the premises upon detection of the end user device through sensing one or more entities associated with the user or the end user device.

4. The method of any of claims 1 to 3, wherein the consent response is transmitted upon consent by a third party on behalf of the user.

5. The method of any of claims 1 to 4, wherein the consent response is transmitted by an electronic device apart from the end user device, wherein the electronic device stores the consent setting for the user.

6. The method of any of claims 1 to 5, wherein an acknowledgement of the consent response is sent upon the validation of the consent setting for the user.

7. The method of any of claims 1 to 6, further comprising:receiving (412) a request to update the consent setting for the session, the request to update including an encrypted combination of an identifier of the session, the consent identifier of the user, and one or more setting values to be set for the user in the consent setting to execute the application; transmitting (414) a request to update the permission for the execution of the application based on the one or more setting values received from the request to update upon decryption of the request to update and validation of the one or more setting values; and storing (416) the request to update in the distributed ledger.

8. The method of claim 7, wherein the request to update is for consent withdrawing, wherein updating the permission for the execution of the application is to terminate the session to prevent further data processing in execution of the application, and the session termination is stored in the distributed ledger.

9. An electronic device (602) for user consent management, comprising: a processor (642) and non-transitory machine-readable storage medium (649) that provides instructions that, when executed by the processor, are capable of causing the processor (642) to perform: obtaining (402) a consent parameter setting for an application to execute the application on a premises; based (404) on the consent parameter setting, transmitting a consent request for the application to be executed upon detection of an end user device of a user on the premises, the consent request for establishing a session to execute the application; receiving (406) a consent response to the consent request, the consent response including an encrypted combination of a consent identifier of a user and a consent setting for the user of the end user device, wherein the consent identifier of the user is derived from a nonce, a secret key, and a persistent identifier of the user that is different from the consent identifier; granting (408) a permission for execution of the application based on the consent setting received from the consent response upon decryption of the consent response and validation of the consent setting for the user; and storing (410) the consent setting of the user in a distributed ledger.

10. The electronic device of claim 9, wherein the end user device is determined to be on the premises upon detection of the end user device through a response to a beacon signal transmitted on the premises.

11. The electronic device of claim 9 or 10, wherein the end user device is determined to be on the premises upon detection of the end user device through sensing one or more entities associated with the user or the end user device.

12. The electronic device of any of claims 9 to 11, wherein the consent response is transmitted upon consent by a party other than the user.

13. The electronic device of any of claims 9 to 12, wherein the consent response is transmitted by an electronic device apart from the end user device, wherein the electronic device stores the consent setting for the user.

14. The electronic device of any of claims 9 to 13, wherein an acknowledgement of the consent response is sent upon the validation of the consent setting for the user.

15. The electronic device of any of claims 9 to 14, wherein the instructions that, when executed by the processor, are capable of causing the processor (642) to further perform: receiving (412) a request to update the consent setting for the session, the request to update including an encrypted combination of an identifier of the session, the consent identifier of the user, and one or more setting values to be set for the user in the consent setting to execute the application; transmitting (414) a request to update the permission for the execution of the application based on the one or more setting values received from the request to update upon decryption of the request to update and validation of the one or more setting values; and storing (416) the request to update in the distributed ledger.

16. The electronic device of claim 15, wherein the request to update is for consent withdrawing, wherein updating the permission for the execution of the application is to terminate the session to prevent further data processing in execution of the application, and the session termination is stored in the distributed ledger.

17. A machine-readable storage medium (649) that provides instructions that, when executed by a processor, are capable of causing the processor to perform any of methods 1 to 8.

Images