Consent information services

The proposed API framework for SPs to manage and expose end-user consent addresses the challenge of cumbersome consent capture for ASPs, ensuring legal compliance and improving user experience by enabling upfront consent detection and management.

WO2026088174A1PCT designated stage Publication Date: 2026-04-30TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
PCT/IB2025/060936
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-10-25
Filing Date
2025-10-27
Publication Date
2026-04-30

AI Technical Summary

Technical Problem

Current systems lack a consistent and user-friendly mechanism for Application Service Providers (ASPs) to determine end-user consent for data access via APIs, leading to cumbersome consent capture processes and potential API call failures due to lack of upfront consent detection, resulting in timeouts and out-of-bounds notifications.

Method used

A method and API framework for Service Providers (SPs) to expose end-user consent information, allowing ASPs to retrieve consent status and register for consent changes, integrated into the application flow to ensure legal compliance and user convenience.

Benefits of technology

Enables ASPs to implement user-friendly and legally compliant consent capture, reducing API call failures and enhancing user experience by providing upfront consent detection and management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2025060936_30042026_PF_FP_ABST
    Figure IB2025060936_30042026_PF_FP_ABST
Patent Text Reader

Abstract

A method, apparatus and system are provided and performed at Service Provider (SP) entity for providing consent information for one or more application to an Application Service Provider, ASP, based on determining end -user consent for the application or ASP to invoke consent information API and / or consent information notification API to be notified of any changes of end user consent, the method comprising receiving by the SP from an ASP a request for onboarding or to sign-up to invoke consent information and / or notification of consent information API(s) for an end user for one or more ASP applications and transmitting to the ASP a response comprising SP information indicating whether the ASP has automatic access to invoke consent information / consent information notification APIs and / or whether the ASP requires consent from the end user to invoke consent information / consent information notification API(s) for one or more ASP applications.
Need to check novelty before this filing date? Find Prior Art

Description

P112082W002 1Consent Information ServicesRelated Application

[0001] This application claims the benefit of provisional patent application serial number PCT / CN2024 / 127292, filed on 10 / 25 / 2024, the disclosure of which is hereby incorporated herein by reference in its entirety.Technical Field

[0002] The present disclosure relates to handling and exposure of personal data maintained by a service provider (SP), e.g. a communication service provider (CSP).Background

[0003] Service Providers (SPs), e.g., Communication Service Providers (CSPs) engage in making end user (the CSP's subscriber) data, device information, and network information available via Application Programming Interfaces (APIs) for consumption by Application Service Providers (ASP). ASPs use this information to implement different use cases within their applications, e.g. fraud prevention.

[0004] When SPs process personal data in the European Union (EU), they fall under the regulations of General Data Protection Regulation (GDPR). In other jurisdictions, other legal frameworks apply. Typically, when the SPs expose personal data, they must obtain the end user's consent; however, for some use cases, other legal bases may be used.

[0005] GDPR introduces a legal framework for protecting the processing of "personal data" linked to natural persons, and introduces the terminology of "Controller", "Processor", and "data subject." As defined in Article 4 of the GDPR, '"personal data' means any information relating to an identified or identifiable natural person ('data subject')); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person." As defined in Article 4 of the GDPR, "'controller' means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where theP112082W002 2purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law." As defined in Article 4 of the GDPR, "'processor' means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller."

[0006] SPs act as controllers of their subscriber's personal data, in GDPR terminology the subscribers are called data subject, owning their personal data. The SP, as controller, is responsible for ensuring that they have a legal basis for the processing of their subscribers', the data subject's, personal data, this means that when relying on consent as a legal basis, they are responsible for collecting the data subject's consent. When exposing the personal data to external consumers, e.g. applications, via APIs, SPs need to make sure that the consent of the data subject (or its legal representative if the data subject is not legally responsible) is available.

[0007] When collecting consent, the intended processing must have a clearly specified context (e.g. indicated by the ASP's application), purpose and scope; this information must be presented to the user during the consent collection process.For good user experience, the consent collection process must be tightly integrated into the application flow to assure that the user is not too much distracted when using the application and in parallel, all necessary consent data is available so that the application can leverage on Network APIs to implement its intended functionality.

[0008] Embodiments of the solution(s) disclosed herein address the needs of ASPs that need to trigger consent capture and SPs that need to capture consent in a user friendly, legally compliant, and trusted way.

[0009] The embodiments of the present disclosure propose a method for an SP or CSP network to expose end user consent for ASPs to invoke consent information APIs such as an API for requesting consent information or API for requesting consent information notification. The SP or the CSP network exposes that end user consent has to either be captured from the end user or the end user consent for invoking the APIs is automatic. The consent can be provided per ASP application or more granular for one or more data scope (e.g., location or position).

[0010] The ASP application / back-end application or another ASP node can use the proposed API to obtain upfront information about the consent status to invoke an APIP112082W002 3for consent information. If the end user consent is to be captured and not automatic, trigger a consent capture dialog realized via an API Service Provider's app plugin or application or a web frontend provided by the SP.

[0011] More specifically, a method performed by one or more network nodes of a Service Provider (SP) or an aggregation node for providing end-user consent to an Application Service Provider, ASP is provided. The method comprises the step of receiving from an ASP node in the ASP a first message such as for example a request for onboarding the one or more ASP applications, or a request to signup for one or more consent information APIs in order to invoke one or more consent information Application Programming Interfaces (APIs) for an end user for one or more ASP applications and in response to the request, transmitting to the ASP node a second message comprising the SP information indicating at least one of whether the one or ASP applications have automatic access to invoke the one or more consent information APIs and whether consent from the end user to invoke the one or more consent information API(s) for one or more ASP applications is required.

[0012] For example, the consent information APIs comprise at least one of an API for requesting consent information for the one or more ASP applications and an API for requesting consent information notification to notify the ASP of any update of consent information.

[0013] In another example, the second message indicates that consent from the end user is required and further includes a Uniform Resource Locator (URL) to a consent capture portal or consent application at the SP.

[0014] In another example, when the second message comprises the SP information indicating that consent from the end user to invoke the one or more consent information API(s) for the one or more ASP applications is required, the method further comprises the step of receiving a request to trigger by the one or more network nodes at the SP a procedure to capture end user consent for the one or more ASP Applications to invoke the one or more consent information APIs, and wherein the request comprises a purpose and at least one of zero or more data scopes relevant for the one or more ASP applications for which end user consent is required. The method further includes the step of obtaining the end user consent to invoke the one or more consent information APIs for the one or more ASP applications wherein the end user consent is indicated for zero or more data scopes and the one or more network nodes in theP112082W002 4SP / CSP network indicating to the ASP node or the aggregator that the end user consent has been captured.

[0015] For example, the captured end user consent is stored in a consent registry at the SP and in one aspect the one or more network nodes in the SP / CSP network sends a response to the request to trigger the consent capture indicating that the end user consent has been captured.

[0016] In some aspect, the method further comprises the step of receiving by the one or more network nodes in the SP from the ASP node or from the aggregator a check request to check consent status as captured by the SP for invoking consent information API(s) for the one or more applications and providing the consent status to the ASP node or the aggregator in response to the check request.

[0017] For example, the check request further indicates one or more data scopes for which consent status is to be checked against the end user captured consent. For example, the consent status indicates end user consent for the one or more data scopes and may be obtained from a consent management at the SP.

[0018] In another aspect, the method further comprises the step of receiving a POST message to request consent information of the end user for an ASP application, the POST message comprising one or more of an identifier of the ASP application, a data subject identifier associated to the end user, zero or more data scopes and sending a response to the POST message, where the response comprises the consent information in accordance with the end user consent captured for the ASP application and for the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

[0019] In another aspect, the method further comprises the steps of receiving a subscription request to request consent information notification of updates to consent information, the subscription request comprises an identifier of the ASP application, one or more data subject identifiers identifying one or more end users, and zero or more data scopes for which consent information update is requested to be notified. The method further includes the step of sending a subscription response indicating a subscription status in accordance with the end user consent captured for the ASP application and the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.P112082W002 5

[0020] For example, the subscription response to the subscription request includes for each indicated data scope in the subscription request a consent status for notification of the ASP upon update.

[0021] According to some embodiment, upon detecting a change in the user consent for invoking the consent information API for an ASP application or for one or more data scope, sending by the one or more nodes in the SP a notification for notifying the ASP of the end user consent status change.

[0022] According to an embodiment, a method performed by an Application Service Provider (ASP) node for getting end user consent for one or more ASP applications is provided. The method comprises the step of transmitting to an aggregator or to a service provider (SP) network a first message to invoke one or more consent information Application Programming Interfaces (APIs) for an end user for one or more ASP applications. The method further comprises the step of receiving a second message in response to the first message, the second message comprising SP information that indicate at least one of whether the one or more ASP applications have automatic access to invoke the one or more consent information APIs and whether consent from the end user to invoke the one or more consent information API(s) for one or more ASP applications is required.

[0023] For example, the first message is one of a request for onboarding the one or more ASP applications, or a request to signup for one or more consent information APIs.

[0024] For example, the consent information APIs comprise at least one of an API for requesting consent information for the one or more ASP applications and an API for requesting consent information notification to notify the ASP of any update of consent information.

[0025] For example, the second message indicates that consent from the end user is required, the second message further includes a Uniform Resource Locator (URL) to a consent capture portal or consent application at the SP.

[0026] In one aspect, the method further comprises initiating caching of the received SP information including at least one ofIndication of Automatic consent;Consent from the end user required;URL to consent capture portal or a consent application at the SP.P112082W002 6

[0027] In one example, initiating caching comprises transmitting by the ASP node a message to an ASP application backend to cache the received SP information.

[0028] In one aspect, the above method performed by the ASP node further comprises the steps of receiving a sign-in request for an application from the end user; checking whether consent to the consent information / consent information notification API(s) is automatic or whether end user consent is required for the application, and when consent is automatic, the ASP node invokes the API for requesting consent information or API for requesting consent information notification at the SP directly or via an aggregator and when access requires consent from the end user, the ASP node redirects to the consent capture portal or to the consent application for capturing the end user consent.For example, in response to redirecting to the consent capture portal or the consent application for capturing the end user consent, the ASP node receives information indicating that the end user consent has been captured and triggers a consent status check to verify consent status for invocation of the one or more consent information APIs for one or more ASP application. For example, triggering the consent status check further comprises sending a notification to an ASP application backend to indicate that the end user consent has been captured.

[0029] For example, the consent status check indicates consent status check for one or more data scopes.

[0030] In one aspect, the method at the ASP node further comprises the step of transmitting to the aggregator or the SP provider network a POST message to request consent information of the end user for an ASP application, the POST message comprising one or more of an identifier of the ASP application, a data subject identifier associated to the end user, zero or more data scopes. The method further comprises the step of receiving a response to the POST message, the response comprising the consent information in accordance with the end user consent captured for the ASP application and for the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

[0031] In another aspect, the method further comprises the step of sending by the ASP node to the SP network a subscription request to request consent information notification of updates to consent information, the subscription request comprises anP112082W002 7identifier of the ASP application, one or more data subject identifiers identifying one or more end users, and zero or more data scopes for which consent information update is requested to be notified. The method further comprises the step of receiving a subscription response indicating a subscription status in accordance with the end user consent captured for the ASP application and the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

[0032] For example, the subscription response to the subscription request includes for each indicated data scope in the subscription request a consent status for notification of the ASP upon update.

[0033] For example, the method further comprises the step of receiving a notification from the SP network indicating end user consent status change.In accordance with some embodiment, a network node in ASP or SP or aggregator is provided and is configured to perform any one of the embodiment here in.

[0034] In accordance with other embodiment, a network node is provided wherein the network node comprises one or more processors and memory comprising instructions which when executed by the one or more processors enable the network node to perform any one of the embodiments herein.Brief Description of the DrawingsThe accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.Figure 1 illustrates one example of a system 100 in which embodiments of the present disclosure may be implemented;Figures 2A illustrates a sequence diagram of accessing consent info API and Consent Notify API via an aggregator in accordance with embodiments of the present disclosure; Figures 2B illustrates sequence diagrams of accessing consent info API directly from API Service Provider in accordance with embodiments of the present disclosure;Figure 3A illustrates a sequence diagram of Getting Consent Info of an end-user via aggregator in accordance with embodiments of the present disclosure;Figure 3B illustrates a sequence diagram of Getting Consent Info of an end-user directly from API Service Provider in accordance with embodiments of the present disclosure;P112082W002 8Figure 4A illustrates a sequence diagram of Consent Notification via an Aggregator in accordance with embodiments of the present disclosure;Figure 4B illustrates a sequence diagram of Consent Notification directly from API Service Provider in accordance with embodiments of the present disclosure;Figures 5 is an example system where embodiments of the present disclosure can be implemented.Figures 6, 7, and 8 are schematic block diagrams of a network node implementing embodiments of the present disclosure.Detailed Description

[0035] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0036] There currently exist certain challenge(s). Consent management functionality and especially consent capture is an almost white space in the industry. Only consent capture related to cookie handling is a common functionality, and it has not been implemented in a consistent way.

[0037] US 63 / 662144 incorporated herein by reference describes a user friendly or convenient mechanism via app plugin or application for SPs to collect end user consent in order to make personal data that the SP holds, available to ASPs.

[0038] However, there is no mechanism for ASPs to decide, whether they should bring up the consent capture app plugin I application provided by the SP. Until now, the applications have no chance to detect whether a user has given consent to the SP for exposing personal data to the app via network APIs. Only when they try to call the network API directly from the SP or via aggregators, then SPs will run a consent check and eventually decline the API execution and associated data exposure.

[0039] Also, there is no mechanisms to inform application functions, if users have provided or withdrawn their consent allowing the application to access their personal data via an out of bounds mechanism, not part of an API call flow.P112082W002 9

[0040] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the solution(s) disclosed herein address the needs of ASPs that need to trigger consent capture and SPs that need to capture consent in a user friendly, legally compliant, and trusted way.

[0041] Without the embodiments in the present disclosure, collecting end user consent is a cumbersome task without a good way of detecting upfront on whether consent capture is needed or not.

[0042] The need for consent capture might only be detected during the API call, which can result in timeouts and subsequent denial of API calls, or out of bounds notifications, which might force the user to leave the application context when aiming for consent capture.

[0043] The embodiments in the present disclosure propose an API, which is provided by the SP and exposes the consent information details already collected for the requesting application from the end user. The ASP application can use the API to get upfront information about the consent status and thus decide whether to bring up or not bring up a consent capture dialog realized via an API Service Provider's app plugin or application or even a web frontend.

[0044] The proposed API will interact with the SP's consent management function to retrieve the consent needs of an ASP's application in line with the previously registered application data and the SP's legal configuration and combine this information with the user specific consent choices, already captured for this application.

[0045] In addition, the embodiments of the present disclosure propose a mechanism for application backends to register for consent changes (approvals or withdrawals) done by users related to the triplet of application, data scope & purpose.

[0046] Embodiments of the solution described herein may include either or both of the following aspects:

[0047] An API provided by Service Provider, which is exposed to an application, and allows to retrieve information about a user's consent choices related to the application

[0048] An API provided by Service provider, which is exposed to an application, and allows to register for changes to consent entries provided by users, which are related to the application.

[0049] A mechanism of securing the exposure of privacy sensitive data provided by these APIs by treating these API as Network (NW) capability APIs.P112082W002 10

[0050] A mechanism which allows consent APIs to be used also in scenarios when an aggregator is acting between an application and SP(s).

[0051] Certain embodiments may provide one or more of the following technical advantage(s). Embodiments of the present disclosure provide new mechanisms that allow an application service provider (ASP) to implement a user-friendly solution for consent capture integrated into the application flow while SPs can comply with their legal obligations for capturing user consent when exposing and processing the personal data of their end users.

[0052] Ultimately this will remove the barrier for ASPs to interact with SPs on Network (NW) API exposure.

[0053] Figure 1 illustrates a system 100 in accordance with example embodiments of the present disclosure. As illustrated, the system 100 illustrates the functions involved in the embodiments of the present disclosure and their interaction with external functions during consent management related processes.• Application• Application backend function• Consent management function• Consent Info API• Consent Notification API

[0054] The Service Provider will offer the "Consent Info API", that an ASP's Application backend function can invoke on behalf of ASP's Application, to understand the end-user consent information available with Service Provider for that specific Application and subsequently determine if it is needed or not to launch the Service Provider's App plugin for capturing the consent.

[0055] The Consent Info API could be made available by the Service Provider's "Consent Management" function to external application backend functions of an ASP. To realize the Consent Info API, the Service Provider's Consent Management function interacts with,• the Service Provider's Application Registry to retrieve the ASP's pre-registered application configuration and the consent choices applicable to an end user, • the SP's consent management function to determine existing consent choices that an end-user might have already provided to Service Provider.P112082W002 11

[0056] The Service Provider will offer the "Consent Notification API", that an ASP's Application backend function can invoke to register for notifications when the end-user consent information available with Service Provider for that specific Application is changed, e.g. when the end-user grants or withdraw his consent by some mechanism, e.g. a Service provider self-care application.1. Consent Info API

[0057] The "Consent Info" API, that is expected to be exposed by a Service Provider's Consent Management function, could support following operations:• [Get Consent Info] An operation that returns the consent data, which has been registered by a certain user for an ASP application.• [Verify] An operation that lets an ASP application compare a data subject identifier, e.g. an MSISDN, with the legal guardian registered for a certain data subject, which is the target of an API call.

[0058] As response to the first operation "Get Consent Info", the Service Provider could share an end-user consent information to ASP's application based on the following information received in API request,• Application IdThis can either be explicitly specified in the request or could be derived by Service Provider based on the client Id of the invoker.• Data Subject IdentifierA data subject identifier could be a MSISDN, or GPSI, or email address or any other identifiers such as Device Identifier as defined in Camara (See [3]).• List of Data Scopes-i- PurposeThis parameter is optional and may contain specific list of purpose and data scopes for which user consent information is to be retrieved. If no data scopes are provided, then consent information will be retrieved for all data scopes the application has registered for.o Example 1 (No purpose specified):dataScopes: [ "scope 1 scope2 scope 3 scope 4"]o Example 2 (Different purpose for dataScope specified):dataScopes: [ "dpv: FraudMgmnt scopel scope4","dpv: useroptimization scope2 scope3"]P112082W002 12

[0059] The response to this consent info request could include for each data scope, • An indicator or decision to highlight whether the application is allowed or not allowed access to the data scope for a certain purpose• If not allowed a cause field to indicate why it is not allowed, such as not allowed because,o user has not given consent yeto or a user has explicitly rejected giving consento or a consent that was previously given has expired• an optional constraint field, which could indicate any constraints that might apply to given consent, such as,o consent is given only when user is in certain regionso consent is given only during working hourso etc.• an optional expiry time field indicating when the shown consent status will expire

[0060] In addition, the response will include:• an indicator on whether the data subject is legally responsible to give consent • optionally contact information of the legal guardian.

[0061] Instead of exposing the information about the legal guardian, the consent info API can alternatively expose a verify endpoint which accepts the data subject identifier I user device identifier and a target data subject / device identifier as input and compare this against the legal guardian contact information of the target data subject registered in the SP's system. Result of the API invocation will be the comparison result (Y / N).

[0062] A sample expected response of "Consent Info" is shown below.("consentRequirements ": [{b{"dataScope": "sim-swap: retrieve-date","purpose": "Enf orceSecurity ","consentstatus": "DISALLOWED","consentcause": "USER_CONSENT_NOT_GRANTED",P112082W002 13" consentExpiry": 1735689599},("dataScope": "number-veri fication: veri fy","purpose": "EnforceSecurity"," consentstatus ": "DI SALLOWED"," consentcause": "USER_CONSENT_ABSENT"},("dataScope": "number-veri fication: device-phone-number: read", "purpose": "ServicePersonalization","userconstraints ": [(},(" key": "TimePeriod","value": {" startTime": " 09: 00","endlime": " 17: 00"}}]," consentstatus ": "DI SALLOWED"," consentcause": "USER CONSENT EXPIRED"

[0063] Sample response when dataSubject is not the legally responsible for providing consent.(" consentRequirements ": [{"dataScope ”: " sim-swap: check","purpose": "EnforceSecurity"," consentstatus ": "ALLOWED","us er Constraints ": [{}]," consentExpiry": 1735689599,"grantConsentByDataSubj ect": "No","legalGuardianldenti fierType": "emailAddres s / MSl SDN / etc., ", "legalGuardianldenti f ier ": " j ohn. smith @email. com"b{"dataScope": " sim-swap: retrieve-date","purpose": "EnforceSecurity"," consentstatus ": "DI SALLOWED"," consentcause": "USER_CONSENT_NOT_GRANTED"," consentExpiry": 1735689599"grantConsentByDataSubj ect": "No","legalGuardianldenti fierType": "emailAddres s / MSl SDN / etc., ", "legalGuardianldenti f ier ": " j ohn. smith@email. com"

[0064] Embodiments of procedures related to the consent info API, especially:• how an ASP application could get access to consent info of an end user, • how consent info could be retrievedwithin the system 100 of Fig. 1 are described below.P112082W002 14access to Consent Info & Consent API via

[0065] Fig. 2A illustrates how an ASP application obtains permission ("consent") to query the application related consent data provided by an end-user. The sequence diagram depicts an API exposure setup, where the application gets access to APIs exposed by SPs via an aggregator. The sequence diagram illustrates one potential flow, an application can implement to register for the consent info I notification API and acquire user consent for calling the API when needed. The sequence diagram is not limiting alternative implementations.

[0066] Depending on what legal basis the "Service Provider" allocates to "Consent Info" data scope, ASP's application access to "Consent Info" API could be automatic or may need an explicit consent from the end-user as shown in the sequence diagram of Fig. 2A.a. If allowed by local regulations, a “Service Provider” could decide that “Consent Info” data scope for certain applications could be allocated with legal basis “Contract” or “Legitimate Interest”. In this scenario, the service provider does not need to have explicit consent from end-user for exposing consent info provided by the user to the application and thus the application will have access to “Consent Info” API and Consent Notification API by default.b. Conversely, if legal basis for accessing the consent info API is set to “Consent”, then the “Service Provider” must get consent from end-user even for sharing consent information. In this scenario, as shown in the sequence diagram, ASP application (via Consent Capture App of Service Provider) would have to request consent from end-user to access the consent information of an end-user. Or alternatively, a user could provide consent to list of apps, app types or app groups to access their consent info directly via Service Provider’s consent capture App (This direct interaction is not shown in the sequence diagram)

[0067] The sequence diagram in Fig. 2A illustrates a potential flow where an application registers for the Consent Info API and / or the Consent Notification API. The application gets optionally informed by the service provider or aggregator, that consent capture for these APIs is or is not needed, such that the application can apply the needed business logic and bring up a consent capture dialog (if needed). The details ofP112082W002 15all the steps are clearly illustrated in Fig. 2A. Below is a description of some of the steps:

[0068] Steps 1 -3 illustrate the application onboarding logic and signing up for the Consent Info I Consent Notification API.

[0069] The responses in step 4-6 respectively 8-10 inform the application whether additional actions are needed before the consent info API I consent notification API can be called or invoked This information can optionally be cached in the application backend (step 7 resp. 11 8t 26). Note that the cache eventually maintained in step 7 or 11 is service provider specific, since no end user is in the picture yet. Once the end user captures consent data, the optional cache (step 26) becomes even end user specific and could be maintained on the application backend or frontend I device as stateful application data.

[0070] When the end-user starts the app on his / her device for the first time or user sign-in to the app for the first time (step 12), the ASP application will check with the ASP app backend whether consent info and / or consent notifications APIS can be invoked from the service provider (step 138t 14 or 15). Step 14 indicates consent is available (if automatic access is provided). Step 15 indicates if end user consent is required to invoke the consent information API / Consent information notification API (Consent notify for short). For simplicity of the flow, it is assumed that the consent capture URL in step 15 is known to the application backend. This URL can also be retrieved from the SP via the aggregator. If necessary, the app can redirect the user to the consent capture page or application, or app plugin provided by the service provider and collect the needed user consent (steps 16-20). In step 21, the ASP application notifies the backend application in the ASP that the consent has been captured. At steps 22 and 23, the application backend may then check the consent status for invoking consent information API and / or consent information notification API at the SP via the aggregator. The check may include checking for consent for other data scopes required by the application such as for example but not limited to location retrieval, sim-swap, etc. At steps 24-25, the SP (consent management module or entity) sends back the consent status to the application backend via the aggregator, which at step 26 caches the updated consent status for invoking or accessing consent information API and / or consent notification API and may also cache any other data scopes required by the ASP application in the consent check.P112082W002 16

[0071] Subsequently the ASP application or ASP application backend may invoke the consent information API via the aggregator or invoke the consent information notification API by subscribing with the service provider via the aggregator to receiving notification to updates of consent information.

[0072] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 2A is shown below:@startumltitle "ASP application getting access to Consent Info and / or Consent Notif icationAPI via aggregator"s kinparam actorStyle awesomes kinparam maxMessageSize 400' hide footboxautonumberactor "End-User" as useractor "ASP admin" as aspadminparticipant "ASP\nApplication" as appparticipant "ASP Application\nBackend" as appbeparticipant "Aggregator" as aggbox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFF' participant "AuthZ Server" as authzparticipant "Application\nRegistry" as appreg #FFFFFF' participant "Subscription Management" as subdb #FFFFFFend boxaspadmin->agg: Onboard ASP Applicationagg->appreg: Onboard ASP Applicationagg->appreg: Order API Product for ASP Application\n (ApiProduct could include Consent Info and / or Consent Notify)alt LegalBasis for "Consent Info / Notify" = "Contract" or "Legitimate Interest"appreg -> agg: LegalBasis=Contract / LegitimateInterest in Response body would indicate about automatic access to requested data scopes i. e., "Consent Info" and / or "Consent Notify"agg->aspadmin: Indicate in onboarding response about automatic access to query "Consent Info / Notify"aspadmin->appbe: Notif y / Conf igure automatic access to query "Consent Info / Notify"appbe->appbe: Cache the consent status to access "Consent Info / Notify" APIselse LegalBasis for "Consent Info / Notify" = "Consent"appreg -> agg: LegalBasis=Consent in Response body would indicate about explicit consent would be needed to access requested data scopes i. e., "Consent Info" and / or "Consent Notify"agg->aspadmin: Indicate in onboarding response that consent is needed to invoke "Consent Info / Notify" APIsP112082W002 17aspadmin->appbe: Notif y / Conf igure consent capture is must to invoke "Consent Info / Notify"appbe->appbe: Cache consent capture requirement for accessing "Consent Info / Notify"enduser->app: Use / Sign-in App for first timeapp->appbe: Check if consent exists for "Consent Info / Notify"alt Consent exists for Consent Info / Notify i. e., LegalBasis= "Contract" or "Legitimate Interest"appbe->app: Indicate in response that consent exists for "Consent Info / Notify"note over app, consent: Continue to invoke Consent Info to check consent status for required Service API data scopes (Example: location-verif y, sim-swap, etc.. )else Consent does not exist for Consent Info / Notify i. e., LegalBasis= "Consent"appbe->app: If consent is needed for "Consent Info / Notify", include in response body, the redirect URL to Service Provider ' s Consent Capture Portal / Appapp->capp: Redirect to "Consent App" for capturing consent for "Consent Info and / or Consent Notify" + any other data scopes that App may need for Application sign-in / f irst time use on user devicecapp->user: Render consent capture showing the consent requirements for the data-scopes required by the Appuser->capp: Provide consent to Application for relevant data-scopes capp->consent: Persist the user provided consent to consent registry capp->app: redirect back to ASP applicationapp->appbe: Notify about consent being capturedappbe->agg: Invoke "Consent Info" to check consent status for "Consent API / Notify" + optionally could include consent check for other data-scopes required by the application (Example: location-verif y, sim-swap, etc.. ) agg->consent: Invoke "Consent Info" to check consent status for "Consent API / Notify" + optionally could include consent check for other data-scopes required by the application (Example: location-verif y, sim-swap, etc.. ) consent-->agg: Respond back with consent statusagg-->appbe: Respond back with consent statusappbe->appbe: Cache the updated consent status for "Consent Info / Notify" API access + any other data-scopes required by App and included in the consent-check (Example: location-verif y, sim-swap, etc.. )note over app, consent: Continue with Application Business Logic @endumlGetting access to Consent Info API directly from API Service Provider

[0073] Fig. 2B illustrates a sequence diagram describing how an ASP application could obtain consent to query application related consent data provided by an end-user when application is onboarded directly with Service Provider.

[0074] As described in the aggregator scenario, here too depending on what legal basis the "Service Provider" allocates to "Consent Info" data scope, ASP's application access to "Consent Info" API could be automatic or may need an explicit consent fromP112082W002 18the end-user as shown in the sequence diagram. The details of all the steps are clearly illustrated in Fig. 2B. Below is a description of some of the steps:

[0075] Steps 1 -2 illustrate the application onboarding logic and signing up for the Consent Info I Consent Notification API. The responses in steps 3-4 respectively 6-7 inform the application whether additional actions are needed before the consent info API I consent notification API can be called or invoked. This information can optionally be cached in the application backend at the ASP (step 5 resp. 88t 21).

[0076] When the end-user starts the app on his / her device for the first time, the application (app) will check with the application backend whether consent info and / or consent notifications APIs can be invoked from the service provider (steps 10 -12). Step 11 describes the ASP application backend indicates to the ASP application that consent is available (if automatic access is provided). Step 12 the ASP determines by having the ASP application backend indicates to the ASP application if end user consent is required to invoke the consent information API / Consent information notification API (Consent notify for short). For simplicity of the flow, it is assumed that the consent capture URL in step 12 is known to the application backend. If necessary, the app can redirect the user to the consent capture page or application, or app plugin provided by the service provider and collect the needed user consent (steps 13-17). Once the ASP application receives the indication that consent has been captured, the ASP application notifies the ASP application backend that consent has been captured by the SP. At steps 19 and 20, the application backend may then check the consent status for invoking consent information API and / or consent information notification API at the SP (consent management entity at the SP). The check may include checking for consent for other data scopes required by the application such as for example but not limited to location retrieval, sim-swap, etc. At step 20, the SP (consent management module or entity) sends back the consent status to the application backend, which at step 21 caches the updated consent status for invoking or accessing consent information API and / or consent notification API and may also cache any other data scopes required by the ASP application in the consent check.Subsequently the ASP application or ASP application backend may invoke the consent information API via the aggregator or invoke the consent information notification API byP112082W002 19subscribing with the service provider via the aggregator to receiving notification to updates of consent information.

[0077] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 2B is shown below:@startumltitle "ASP application getting access to Consent Info and / or Consent Notification APIs directly from Service Provider"s kinparam actorStyle awesomes kinparam maxMessageSize 400autonumberactor "End-User" as useractor "ASP admin" as aspadminparticipant "ASP\nApplication" as appparticipant "ASP Application\nBackend" as appbebox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFFparticipant "Application\nRegistry" as appreg #FFFFFFend boxaspadmin->appreg: Onboard ASP Applicationaspadmin->appreg: Order API Product for ASP Application\n (ApiProduct could include Consent Info and / or Consent Notify)alt LegalBasis for "Consent Info / Notify" = "Contract" or "Legitimate Interest"appreg -> aspadmin: LegalBasis=Contract / LegitimateInterest in Response body would indicate about automatic access to requested data scopes i. e., "Consent Info" and / or "Consent Notify"aspadmin->appbe: Notif y / Conf igure automatic access to query "Consent Info / Notify" & no further steps neededappbe->appbe: Cache the consent status to access "Consent Info / Notify" APIselse LegalBasis for "Consent Info / Notify" = "Consent"appreg -> aspadmin: LegalBasis=Consent in Response body would indicate about explicit consent would be needed to access requested data scopes i. e., "Consent Info" and / or "Consent Notify"aspadmin->appbe: Notif y / Conf igure consent capture is must to invoke "Consent Info / Notify"appbe->appbe: Cache consent capture requirement for accessing "Consent Info / Notify"enduser->app: Use / Sign-in App for first timeapp->appbe: Check if consent exists for "Consent Info / Notify"alt Consent exists for Consent Info / Notify i. e., LegalBasis= "Contract" or "Legitimate Interest"appbe->app: Indicate in response that consent exists for "ConsentInfo / Notify"P112082W002 20note over app, consent: Continue to invoke Consent Info to check consent status for required Service API data scopes (Example: location-verif y, sim-swap, etc.. )else Consent does not exist for Consent Info / Notify i. e., LegalBasis= "Consent"appbe->app: If consent is needed for "Consent Info / Notify", include in response body, the redirect URL to Service Provider ' s Consent Capture Portal / Appapp->capp: Redirect to "Consent App" for capturing consent for "Consent Info and / or Consent Notify" + any other data scopes that App may need for Application sign-in / f irst time use on user devicecapp->user: Render consent capture showing the consent requirements for the data-scopes requested by the Appuser->capp: Provide consent to Application for relevant data-scopes capp->consent: Persist the user provided consent to consent registry capp->app: redirect back to ASP applicationapp->appbe: Notify about consent being capturedappbe->consent: Invoke "Consent Info" to check consent status for "Consent API / Notify" + optionally could include consent check for other data-scopes required by the application (Example: location-verif y, sim-swap, etc.. ) consent-->appbe: Respond back with consent statusappbe->appbe: Cache the updated consent status for "Consent Info / Notify" API access + any other data-scopes required by App and included in the consent-check (Example: location-verif y, sim-swap, etc.. )note over app, consent: Continue with Application Business Logicend@endumlGetting Consent Info of an end-user via aggregator

[0078] Fig. 3A illustrates a sequence diagram describing the usage of "Consent Info" API by application via an aggregator to check if consent exists and if not, to redirect to Service Provider's consent capture App to get the required consent. The details of all the steps are clearly illustrated in Fig. 3A. Below is a description of some of the steps:

[0079] Steps 1 -3 illustrate internal application logic, where upon the ASP application is accessed by the end user (step 1), the ASP application checks for potentially cached consent information on NW APIs. The application at step 2 for example checks any available end-user consent info for service API data-scopes, the request includes datasubjectidentifier and optionally a list of of one or more data-scopes. Fig. 3A shows the ASP application checks with the application backend, but this is for illustrative purposes only and not limiting any alternative implementations, e.g. the consent cache could also be maintained on the application frontend. The consent cache on application backend level is fully optional and will be SP specific since no enduser information is available yet. Once an end user consent is captured, the cached data becomes end user specific.P112082W002 21If the application detects that consent information is missing but consent exists to invoke the consent information API, it will invoke (via the application backend) the consent info API to retrieve this consent information required for the application. The consent Info API invocation should be secured via oAuth protocol (steps 5-8).If calling the consent info API is permitted (by default or explicitly by the end-user) then the consent data is returned to the application. If the results returned indicate that user consent is missing for certain data scopes and purposes, the application can bring up a consent capture dialog (after step 10).If calling the consent info API is not permitted, this can be due to the fact that consent has not been acquired from the user yet or the user has denied permission. In the first scenario, the application can bring up a consent capture dialog to obtain end user consent for calling NW APIs including the consent info API it has registered for (after step 10).

[0080] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 3A is shown below:@startumltitle "ASP application backend getting Consent Notification via aggregator"s kinparam noteFontColor autos kinparam actorStyle awesomes kinparam maxMessageSize 350autonumberactor "End-User" as userparticipant "ASP Application\nBackend" as appbeparticipant "Aggregator" as aggbox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFFend boxnote right user #black"Consent Notifcation" Api Product has been ordered for ASP application as described in 2. 7. 1.1end notenote right user #black: End-User has granted consent to ASP application for "Consent Notification" as described in 2. 7. 1.1=== Subscription to Consent Status Change Notification ==appbe -> agg: Subscribe to consent status Notif ications\n (applicationld, [Opt. ] List of data-sub j ects, [Opt. ] List of data-scopes, app_backend_call_back_url )P112082W002 22agg -> consent: Subscribe to consent status Notifications \n (applicationld, [Opt. ] List of data-sub j ects, [Opt. ] List of data-scopes, aggregator_call_back_url or app_backend_call_back_url)consent --> agg: 200 OK (Notif icationSubscriptionld, Subscriptionstatus, For each datascope & dataSubj ect [Consent status on notification] ) agg --> appbe: 200 OK (Notif icationSubscriptionld, Subscriptionstatus, For each datascope & dataSubj ect [Consent status on notification] )=== Consent Status Update ==alt End-user updates the consentuser -> capp: Update consent status of one or more Network API data-scopescapp ->consent: Persist Consent status update done by the end-user note over user, capp #GrayFor legibility reasons, different Consent capture mechanisms or detailed steps are not shown hereend noteelse Consent status gets updated without end-user actionnote left consent #GraySome of the scenarios where consent status might be updated without direct end user intervention:1. Consent might expire2. Contract changes might invalidate previously provide consent. Such as, - end-user closing contract and moving to a new Service Provider - legal basis may change if customer moves to a different contract under same service provider3. An update to legalbasis / legaltext in privacy policy will also invalidate previously provided consents4...end noteendconsent -> consent: Consent Status change=== Consent Status update notifications ==consent -> consent: Check subscriptions that exists for\n consent status notificationsalt call_back_url = aggregator_call_back_urlconsent -> agg: Notify on consent status change\nPOST <aggregator_call_back_url provided during notification subscription> \n (applicationld, dataSubject, dataScope, consentstatus )agg -> appbe: Notify on consent status change \nPOST <app_call_back_url provided during notification subscr iption>\n (applicationld, dataSubject, dataScope, consentstatus )else call_back_url = app_backend_call_back_urlconsent-> appbe: Notify on consent status change \nPOST <app_backend_call_back_url provided during notification subscription>\n (applicationld, dataSubject, dataScope, consentstatus ) end@endumlGetting Consent Info of an end-user directly from API Service Provider

[0081] Fig. 3B illustrates a sequence diagram describing the usage of "Consent Info" API by application via application backend to check if consent exists and if not, toP112082W002 23redirect to Service Provider's consent capture App to get the required consent. The details of all the steps are clearly illustrated in Fig. 3B. Below is a description of some of the steps:Steps 1 -3 illustrate internal application logic, checking for potentially cached consent information on NW APIs. This is for illustrative purposes only and not limiting any alternative implementations, e.g. the consent cache could also be maintained on the application frontend.If the application detects that consent info is missing, it will invoke the consent info API to retrieve this information. The API invocation will be secured via oAuth protocol (step 5 & 6).If calling the consent info API is permitted (by default or explicitly by the end-user) then the consent data is returned to the application. If the results returned indicate, that user consent is missing, the application can bring up a consent capture dialog (after step 8).If calling the consent info API is not permitted, this can be due to the fact that consent has not been acquired from the user yet or the user has denied his permission. In the first scenario, the application can bring up a consent capture dialog to obtain end user consent for calling NW APIs including the consent info API, it has registered for (after step 8).

[0082] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 3B is shown below:@startumltitle "ASP application backend getting Consent Notification directly from Service Provider"s kinparam noteFontColor autos kinparam actorStyle awesomes kinparam maxMessageSize 350autonumberactor "End-User" as userparticipant "ASP Application\nBackend" as appbebox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFFend boxnote right user #blackP112082W002 24"Consent Notifcation" Api Product has been ordered for ASP application as described in 2. 7. 1.1end notenote right user #black: End-User has granted consent to ASP application for "Consent Notification" as described in 2. 7. 1.1=== Subscription to Consent Status Change Notification ==appbe -> consent: Subscribe to consent statusNotif ications\n (applicationld, [Opt. ] List of data-sub j ects, [Opt. ] List of data-scopes, app_backend_call_back_url)consent --> appbe: 200 OK (Notif icationSubscriptionld, Subscriptionstatus, For each datascope & dataSubj ect [Consent status on notification] )=== Consent Status Update ==alt End-user updates the consentuser -> capp: Update consent status of one or more Network API data-scopescapp ->consent: Persist Consent status update done by the end-user note over user, capp #GrayFor legibility reasons, different Consent capture mechanisms or detailed steps are not shown hereend noteelse Consent status gets updated without end-user actionnote left consent #GraySome of the scenarios where consent status might be updated without direct end user intervention:1. Consent might expire2. Contract changes might invalidate previously provide consent. Such as, - end-user closing contract and moving to a new Service Provider - legal basis may change if customer moves to a different contract under same service provider3. An update to legalbasis / legaltext in privacy policy will also invalidate previously provided consents4...end noteendconsent -> consent: Consent Status change=== Consent Status update notifications ==consent -> consent: Check subscriptions that exists for\n consent status notificationsconsent-> appbe: Notify on consent status change \nPOST <app_backend_call_back_url provided during notification subscription>\n (applicationld, dataSubject, dataScope, consentstatus ) @enduml2. Consent Notification API

[0083] The "Consent Notification" API, that is expected to be exposed by a Service Provider's Consent Management function, could support following operations:• [Create Subscription] An operation that lets an ASP application subscribe to consent status change events issued for one or more end-users on consent status changesP112082W002 25• [Read Subscription] An operation that lets an ASP application to read information about subscription to notifications• [Unsubscribe Subscription] An operation that lets an ASP application to unsubscribe to notifications• [Update Subscription] An operation that lets an ASP application to update the notification subscription (example: add / remove data Subjects)• [Notify Consent status change] An operation that notifies ASP application about any change in consent status of an end-user

[0084] Consent notifications could be modeled as separate API or included as additional end points and data scopes into the consent info API. An application could alternatively subscribe for all end-users consent status changes when subscribing to the consent info API, e.g. by placing an Api Productorder on the consent info API via TMF 931 Operate API Suite, and specifying a callback uri for notifications.The subsequent figures describe the realization as separate API, even though this not meant to limit the realization options.to consent status notification

[0085] The notification subscription request in its request body could include information about,• Application IdThis can either be explicitly specified in the request or could be derived by Service Provider based on the client Id of the API invoker• List of data subjectsThis will be optional and may contain one or more data subjects identified by the data subject identifier. A data subject identifier could be a MSISDN, or GPSI, or email address or any other identifiers such as Device Identifier as defined in Camara (See [3]); if not provided, the notification subscription will be applicable to all data subjects• List of Data ScopesThis will be optional and may contain specific list of data scopes for which application wants to be notified when the data-scopes consent status changes either by manual update by end-user approval / revocation or byP112082W002 26expiry / inactivation do different reasons such as time period expiry or end-user contract changes, etc.If no data scopes are provided, then notification will be subscribed for consent status changes of all data scopes that are relevant for the Application (as determined from the Application Registry)• Notification Callback endpoint / URL (along with any necessary credential) Address where notification must be delivered.

[0086] The response to this consent status notification subscription could include for each data scope,• An Id to identify the unique notification subscription instance• An indicator informing that subscription has been registered• An indicator informing if end-user consent is needed for notifying the application and if yes, an indicator to inform if end-user (s) has approved or rejected to notify the Applications about their consent statusRead Subscription on Consent Status Notification

[0087] This operation could include following details in the request,• Subscription Id (Optional)The subscription ID returned from the [Create Subscription] operation• Application Id (Optional)The Application which has subscribed for consent status change notifications Either subscription Id or Application Id must be provided.• List of data subjects (Optional)List of data subjects for which the Application might be subscribed• List of data scopes (Optional)List of data scopes for which the Application might be subscribed

[0088] The response will include a list of notification subscriptions against the data scope, and for each data scope,• Subscription Id• An indicator informing that subscription has been registered• An indicator informing if end-user consent is needed for notifying the application and if yes, a status indicator about end-user’s consent status for notifications such as “approved” or “rejected” or “has not yet given consent”.P112082W002 27Delete Consent Status Notification Subscription

[0089] This is simple delete operation done against the subscription Id.It will remove the notification subscription that would have been created against a data-scope.Update Consent Status Notification Subscription

[0090] This operation could be used to optionally add or remove a data subject whose consent status changes needs to be notified.

[0091] This operation could include following details in the request,• Subscription Id (Mandatory)The application ID and data-scope could be derived from this notification subscription ID and need not be explicitly specified• And for each data subject,o Data subject Identifier, that identifies the data subjecto Action, indicating whether data subject is to be included or excluded

[0092] Response could be a plain 200 success message indicating successful update.Notify consent status change operation

[0093] This would be the POST operation from Service Provider to call back URL registered by the application while it subscribes to consent status changes of end-users. The notification could include the following details,• ApplicationApplication for which the consent was change by the end-user• dataSubjectdataSubject whose consent data was changed• dataScopeThe data scope for which the consent was updated• consentstatusThe new consent status after the update was madeGetting access to Consent Notification API via aggregator

[0094] Depending on what legal basis the "Service Provider" allocates to "Consent Notification" data scope, ASP's application access to "Consent Notification" API could be automatic or may need an explicit consent from the end-user.P112082W002 28

[0095] The sequence diagram provided in Fig. 2A for the Consent Info API is also applicable for the Consent Notification API and describes how an ASP application could obtain consent to get notifications about changes to the consent data, which are provided an end user and relate to the application.access to Consent Notification API directly from API Service Provider

[0096] As described in the aggregator scenario, here too depending on what legal basis the "Service Provider" allocates to "Consent Info" data scope, ASP's application access to "Consent Notification" API could be automatic or may need an explicit consent from the end-user as shown in the sequence diagram.

[0097] The sequence diagram provided in Fig. 2B for the Consent Info API is also applicable for the Consent Notification API and describes how an ASP application could obtain consent to get notifications about changes to the consent data, which are provided an end user and relate to the application.Consent Notification sequence via an Aqqreqator

[0098] Fig. 4A illustrates a sequence diagram describing how an ASP application can subscribe through an aggregator and subsequently get notified from Service Provider whenever there is an event resulting in change of the consent status given by an enduser to a data-scope.

[0099] Consent status may be changed explicitly by the end-user either by granting or revoking a previously provided consent.

[0100] Consent may also change without direct end-user action on the consent. Some of the scenarios that will result in this are:1. A given consent might expire automatically after a certain time period 2. Some contract changes might invalidate previously provide consent. Such as,i. End-user closing contract and moving to a new Service Provider ii. If an end-user moves to a different contract under same service provider, then the legal basis based on which consent might have been given could change resulting in invalidating previously provided consent data.3. An update to legal basis and / or legal text in privacy policy will also invalidate previously provided consent data.P112082W002 29

[0101] As a prerequisite, the application must have signed up for the consent API product. The aggregator or application callback URL must have been provided to the SP and registered on the Consent Notification API product instance.

[0102] The application now uses the consent notification API to subscribe to consent changes optionally specifying a list of data subject and / or list of data scopes. This subscription is forwarded to the SP via the aggregator (steps 1-4).Once the consent status changes due to end user action or implicitly (e.g. due to expiry) (steps 5-7), the consent management posts a notification to the registered callback URL, which could be the aggregator URL or the application backend directly (steps 9 & 11). In case the aggregator URL has been registered, it is the responsibility of the aggregator to inform the application backend (step 10).

[0103] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 4A is shown below:@startumltitle "ASP application retreiving end user consent info via aggregator" s kinparam actorStyle awesomes kinparam maxMessageSize 350autonumberactor "End-User" as userparticipant "ASP\nApplication" as appparticipant "ASP Application\nBackend" as appbeparticipant "Aggregator" as aggbox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFFparticipant "Application\nRegistry" as appreg #FFFFFFend boxuser->app: Use applicationapp->appbe: Check enduser consent info status for Service API data-scopes ( such as location-retrieval, sim-swap, etc. ) \n (Request must include dataSubjectIdentifier and opt. list of data-scopes )appbe->appbe: Check cached consent for permission to invoke Consentinfo APIalt Consent does not exists for Consent Infoappbe->app: Respond with Consentcapture App / Portal redirect Url to capture end-user consentnote over app, capp: Start user consent capture process for Service API data scopes such as location-retireval, sim-swap, etc.else Consent exists for Consent Infoappbe->agg: POST / consent-info / check\n ( appld as registered with aggregator, dataSubject, list of L3 / L2 data-scopes )note over agg, consentP112082W002 30If Aggregator has built an L3 / L2 API made up of different LI APIs, then aggregator would have to translate those L3 / L2 data-scopesinto LI datascopes that is understandable by Service Provider Similarly, the AppID as registered on Aggregator may have different Appld ' s when aggregator subsequently onboards these App on different API Service Providers.end noteagg->consent: POST / consent-info / check\n ( appld as registered with API Service Provider, dataSubject, list of LI data-scopes )consent->agg: 200 OK \n (consentRequirements [LI-dataScope, purpose, consentstatus, consentcause, userconstraints, consentStatusExpiry] ) agg->appbe: 200 OK \n (consentRequirements [L3 / L2-dataScope, purpose, consentstatus, consentcause, userconstraints, consentStatusExpiry] ) alt Consent exists for Service API data-scopes such as location-retrieval, sim-swapappbe->app: Respond to continue with Application functionalitynote over app, agg: User continues with Application usage and Application if required invokes Service API such as location-retireval, sim-swap else Consent does not exist for one or more Service API data-scopes appbe->app: Respond with Consentcapture App / Portal redirect Url to capture end-user consentnote over app, capp: Start user consent capture process for Service API data scopes such as location-retireval, sim-swap, etc.end altend@endumlConsent Notification sequence directly from Api Service Provider

[0104] Fig. 4B illustrates a sequence diagram describing how an ASP application can subscribe directly with an API service provider and subsequently get notified from the Service Provider whenever there is an event resulting in change of the consent status given by an end-user to a data-scope.

[0105] As a prerequisite, the application must have signed up for the consent API product. The aggregator or application callback URL must have been provided to the SP and registered on the Consent Notification API product instance.

[0106] The application now uses the consent notification API to subscribe to consent changes optionally specifying a list of data subject and / or list of data scopes (steps 1-2).Once the consent status changes due to end user action or implicitly (e.g. due to expiry) (steps 3-5), the consent management posts a notification to the registered application callback URL (step 7).

[0107] An example plantuml diagram code for the above sequence diagram as illustrated in Fig. 4B is shown below:@startumlP112082W002 31title "ASP application retreiving end user consent info directly from API Service Provider"s kinparam actorStyle awesomes kinparam maxMessageSize 300autonumberactor "End-User" as userparticipant "ASP\nApplication" as appparticipant "ASP Application\nBackend" as appbebox "Service Provider" #FFFFFFparticipant "Consent Capture\nPortal or App" as cappparticipant "Consent\nManagement" as consent #FFFFFFend boxuser->app: Use applicationapp->appbe: Check enduser consent info status for Service API data-scopes ( such as location-retrieval, sim-swap, etc. ) \n (Request must include dataSubjectIdentifier and opt. list of data-scopes )appbe->appbe: Check cached consent for permission to retrieve Consentinfo alt Consent does not exists for Consent Infoappbe->app: Respond with Consentcapture App / Portal redirect Url to capture end-user consentnote over app, capp: Start user consent capture process for Service API data scopes such as location-retireval, sim-swap, etc.else Consent exists for Consent Infoappbe->consent: POST / consent-info / check\n ( appld as registered with API Service Provider, dataSubject, list of LI data-scopes )consent->appbe: 200 OK \n (consentRequirements [LI-dataScope, purpose, consentstatus, consentcause, userconstraints, consentStatusExpiry] ) alt Consent exists for Service API data-scopes such as location-retrieval, sim-swapappbe->app: Respond to continue with Application functionalitynote over app: User continues with Application usage and Application if required invokes Service API such as location-retireval, sim-swapelse Consent does not exist for one or more Service API data-scopes appbe->app: Respond with Consentcapture App / Portal redirect Url to capture end-user consentnote over app, capp: Start user consent capture process for Service API data scopes such as location-retireval, sim-swap, etc.end altend@enduml

[0108] Figure 5 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. Here, the CSP is a cellular service provider that operates the cellular communications system, and the end user is a subscriber of the cellular service provider. The end user device is a wirelessP112082W002 32communication device (e.g., a UE) via which the end user accesses the cellular communications system operated by the cellular service provider. The consent management function 116 and the application registry 114 (and any other functionality of the CSP or CSP network 104 described above) may be implemented in the cellular network (e.g., in the core network 510).

[0109] The cellular communications system 500 is, for example, a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E-UTRAN) and an Evolved Packet Core (EPC). The cellular communications system 500 may alternatively be a 6G system. In this example, the RAN includes base stations 502-1 and 502-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5G System (5GS) is referred to as the 5GC. The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510.

[0110] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wirelessP112082W002 33communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0111] Figure 6 is a schematic block diagram of a network node 600 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The functionality of the CSP network 104 (e.g., the application registry function 114 and the consent management function 116) may be implemented in the network node 600 or distributed across two or more network nodes or implemented in a cloud computing architecture. The network node 600 may be, for example, a core network node. As illustrated, the network node 600 includes one or more processors 604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 606, and a network interface 608. The one or more processors 604 are also referred to herein as processing circuitry. The one or more processors 604 operate to provide one or more functions of the network node 600 as described herein (e.g., one or more functions of the CSP network 104 described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 606 and executed by the one or more processors 604.

[0112] Figure 7 is a schematic block diagram that illustrates a virtualized embodiment of the network node 600 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 600 in which at least a portion of the functionality of the network node 600 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 600 includes one or more processing nodes 700 coupled to or included as part of a network(s) 702. Each processing node 700 includes one or more processors 704 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 706, and a network interface 708.

[0113] In this example, functions 710 of the network node 600 described herein (e.g., one or more functions of the SP (or CSP) network 104 or ASP network described herein) are implemented at the one or more processing nodes 700 in any desired manner. In some particular embodiments, some or all of the functions 710 of the network node 600 described herein are implemented as virtual components executedP112082W002 34by one or more virtual machines implemented in a virtual environ ment(s) hosted by the processing node(s) 700.

[0114] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 600 or a node (e.g., a processing node 700) implementing one or more of the functions 710 of the network node 600 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0115] Figure 8 is a schematic block diagram of a wireless communication device 512 (e.g., a UE) according to some embodiments of the present disclosure. The wireless communication device 512 is one example of the end user device 102. As illustrated, the wireless communication device 512 includes one or more processors 802 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 804, and one or more transceivers 806 each including one or more transmitters 808 and one or more receivers 810 coupled to one or more antennas 812. The transceiver(s) 806 includes radio-front end circuitry connected to the antenna(s) 812 that is configured to condition signals communicated between the antenna(s) 812 and the processor(s) 802, as will be appreciated by on of ordinary skill in the art. The processors 802 are also referred to herein as processing circuitry. The transceivers 806 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 512 (or UE or end user device 102) described above may be fully or partially implemented in software that is, e.g., stored in the memory 804 and executed by the processor(s) 802. Note that the wireless communication device 512 may include additional components not illustrated in Figure 8 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the wireless communication device 512 and / or allowing output of information from the wireless communication device 512), a power supply (e.g., a battery and associated power circuitry), etc.P112082W002 35

[0116] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 512 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0117] 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 Processor (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 to one or more embodiments of the present disclosure.

[0118] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).Abbreviation:P112082W002 36The following is a list of example claims derived from the one or more embodiments described in the disclosure. Additional claims can be added in subsequent applications.

Claims

P112082W002 37Claims1. A method performed by one or more network nodes of a Service Provider (SP) or an aggregation node for providing end-user consent to an Application Service Provider, ASP, the method comprising:- receiving from an ASP node in the ASP a first message to invoke one or more consent information Application Programming Interfaces (APIs) for an end user for one or more ASP applications; and- in response to the first message, transmitting to the ASP node a second message comprising SP information indicating at least one of whether the one or ASP applications have automatic access to invoke the one or more consent information APIs and whether consent from the end user to invoke the one or more consent information API(s) for one or more ASP applications is required.

2. The method of claim 1, wherein the first message is one of a request for onboarding the one or more ASP applications, or a request to signup for one or more consent information APIs.

3. The method of claim 1, wherein the consent information APIs comprise at least one of an API for requesting consent information for the one or more ASP applications and an API for requesting consent information notification to notify the ASP of any update of consent information.

4. The method of claim 1, wherein when the second message indicates that consent from the end user is required, the second message further includes a Uniform Resource Locator (URL) to a consent capture portal or consent application at the SP.

5. The method of any one of claims 1 to 4, wherein when the second message comprises SP information indicating that consent from the end user to invoke the one or more consent information API(s) for the one or more ASP applications is required, the method further comprises:- receiving a request to trigger by the one or more network nodes at the SP a procedure to capture end user consent for the one or more ASP Applications to invoke the one or more consent information APIs, andP112082W002 38wherein the request comprises a purpose and at least one of zero or more data scopes relevant for the one or more ASP applications for which end user consent is required;- obtaining the end user consent to invoke the one or more consent information APIs for the one or more ASP applications wherein the end user consent is indicated for zero or more data scopes; and- indicating to the ASP node or the aggregator that the end user consent has been captured.

6. The method of claim 5 wherein the captured end user consent is stored in a consent registry at the SP.

7. The method of any one of claims 5 to 6 further comprising sending a response to the request to trigger the consent capture indicating that the end user consent has been captured.

8. The method of any one of claims 1 to 7 wherein the method further comprises:- receiving by the one or more network nodes in the SP from the ASP node or from the aggregator a check request to check consent status as captured by the SP for invoking consent information API(s) for the one or more applications; and- providing the consent status to the ASP node or the aggregator in response to the check request.

9. The method of claim 8, wherein the check request further indicates one or more data scopes for which consent status is to be checked against the end user captured consent.

10. The method of claim 9, wherein the consent status indicates end user consent for the one or more data scopes.

11. The method of any one of claims 9 to 11 wherein the method further comprises obtaining the consent status from a consent management at the SP.P112082W002 3912. The method of any one of claims 1 to 11 wherein the method further comprises:- receiving a POST message to request consent information of the end user for an ASP application, the POST message comprising one or more of an identifier of the ASP application, a data subject identifier associated to the end user, zero or more data scopes; and- sending a response to the POST message, the response comprising the consent information in accordance with the end user consent captured for the ASP application and for the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

13. The method of any one of claims 1 to 11 wherein the method further comprises:- receiving a subscription request to request consent information notification of updates to consent information, the subscription request comprises an identifier of the ASP application, one or more data subject identifiers identifying one or more end users, and zero or more data scopes for which consent information update is requested to be notified; and- sending a subscription response indicating a subscription status in accordance with the end user consent captured for the ASP application and the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

14. The method of claim 13 wherein the subscription response to the subscription request includes for each indicated data scope in the subscription request a consent status for notification of the ASP upon update.

15. The method of any one of claims 13-14 further comprising upon detecting a change in the user consent for invoking the consent information API for an ASP application or for one or more data scope, sending a notification for notifying the ASP of the end user consent status change.P112082W002 4016. A method performed by an Application Service Provider (ASP) node for getting end user consent for one or more ASP applications, the method comprising:- transmitting to an aggregator or to a service provider (SP) network a first message to invoke one or more consent information Application Programming Interfaces (APIs) for an end user for one or more ASP applications; and- receiving a second message in response to the first message, the second message comprising SP information indicating at least one of whether the one or more ASP applications have automatic access to invoke the one or more consent information APIs and whether consent from the end user to invoke the one or more consent information API(s) for one or more ASP applications is required.

17. The method of claim 16, wherein the first message is one of a request for onboarding the one or more ASP applications, or a request to signup for one or more consent information APIs.

18. The method of claim 16, wherein the consent information APIs comprise at least one of an API for requesting consent information for the one or more ASP applications and an API for requesting consent information notification to notify the ASP of any update of consent information.

19. The method of claim 16, wherein when the second message indicates that consent from the end user is required, the second message further includes a Uniform Resource Locator (URL) to a consent capture portal or consent application at the SP.

20. The method of any one of claims 16 to 19 wherein the method further comprises initiating caching of the received SP information including one or more of:- Indication of Automatic consent;- Consent from the end user required;- URL to consent capture portal or a consent application at the SP.P112082W002 4121. The method of claim 20 wherein initiating caching further comprises transmitting a message to an ASP application backend to cache the received SP information.

22. The method of claim 16 further comprising:- receiving a sign-in request for an application from the end user;- checking whether consent to the consent information / consent information notification API(s) is automatic or whether end user consent is required for the application;- when consent is automatic, invoking API for requesting consent information or API for requesting consent information notification at the SP directly or via an aggregator; and- when access requires consent from the end user, redirecting to the consent capture portal or to the consent application for capturing the end user consent.

23. The method of claim 22 wherein in response to redirecting to the consent capture portal or the consent application for capturing the end user consent, receiving information indicating that the end user consent has been captured; and triggering a consent status check to verify consent status for invocation of the one or more consent information APIs for one or more ASP application.

24. The method of claim 23 wherein the consent status check indicates consent status check for one or more data scopes.

25. The method of any one of claims 23 to 24 wherein triggering the consent status check further comprises sending a notification to an ASP application backend to indicate that the end user consent has been captured.

26. The method of any one of claims 16 to 25 wherein the method further comprises:- transmitting to the aggregator or the SP provider network a POST message to request consent information of the end user for an ASP application, the POST message comprising one or more of an identifier ofP112082W002 42the ASP application, a data subject identifier associated to the end user, zero or more data scopes; and- receiving a response to the POST message, the response comprising the consent information in accordance with the end user consent captured for the ASP application and the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

27. The method of any one of claims 16 to 25 wherein the method further comprises:- sending a subscription request to request consent information notification of updates to consent information, the subscription request comprises an identifier of the ASP application, one or more data subject identifiers identifying one or more end users, and zero or more data scopes for which consent information update is requested to be notified; and - receiving a subscription response indicating a subscription status in accordance with the end user consent captured for the ASP application and the zero or more data scopes or in accordance with the consent being automatic for the ASP application and the zero or more data scopes.

28. The method of claim 27 wherein the subscription response to the subscription request includes for each indicated data scope in the subscription request a consent status for notification of the ASP upon update.

29. The method of claim 27 further comprising receiving a notification indicating end user consent status change.

30. A network node configured to perform any one of the method claims 1-29.

31. A network node comprising one or more processors and memory comprising instructions which when executed by the one or more processors enable the network node to perform any one of the method claims 1-29.

Citation Information

Patent Citations

  • Communication method and communication device

    CN117641358A

  • Identity application programming interface

    WO2015061307A1

  • Enablement of common application programming interface framework invocation by user equipment applications

    WO2023150782A1

  • CN2024127292W

  • US63662144P